Reseller’dan Dedicated’a Ne Zaman Geçilmeli? Net Kriterler

Reseller hosting ile başlamak, maliyeti düşük tutarak büyümeyi hızlandırır. Ancak trafik, uygulama sayısı ve güvenlik gereksinimleri belirli bir noktayı geçtiğinde aynı ortamda ilerlemek maliyet ve risk yaratır. Bu rehberde Reseller’dan dedicated (tam sunucu) ortamına geçişi ne zaman yapmanız gerektiğini somut sinyallerle anlatıyorum. Ayrıca geçiş zamanı geldiğinde doğru sunucu tipini seçmek için ölçüm planı ve kontrol listesi veriyorum.

Reseller ile dedicated arasındaki temel fark: karar sinyalleri nereden gelir?

Reseller planlarda fiziksel sunucunun kaynakları çoklu müşteriler arasında paylaşılır. Dedicated sunucuda ise CPU/RAM/Storage tamamen size ayrılır ve altyapı kontrolü artar. Bu fark, geçiş kararını “hissettirerek” değil “ölçerek” almanız gerektiğini söyler.

Hangi metrikler karar verir?

Geçişi haklı çıkaran sinyaller genellikle aşağıdaki alanlarda netleşir: - Performans: Yanıt süresi (TTFB), CPU kullanımı, yoğun saatlerde eş zamanlı istek sayısı. - Kaynak kısıtı: Limit uyarıları (inode, disk I/O, RAM), burst kapasitenin tükenmesi. - Operasyon: Yedekleme frekansı, log saklama süresi, güvenlik hardening (kapan/ayar) ihtiyacı. - Güvenlik: WAF/anti-DDoS katmanları yetmez hale geldiğinde, izole ağ ve kapsamlı kural yönetimi ihtiyacı. - Uyumluluk ve taahhüt: SLA (Service Level Agreement) ve öngörülebilirlik beklentisi.

Ne zaman geçiş yapmalısınız? Reseller’dan dedicated’a net eşikler

Aşağıdaki maddeler “tek başına” kesin karar verdirmez; ancak birlikte görüldüğünde geçişin zamanı gelmiştir. Her birini kendi ölçümünüzle doğrulayın.

1) Uygulamanız yoğun saatte yanıt süresini tutturamıyor

Reseller ortamında yoğun saatlerde gecikme artışını aşağıdaki şekilde doğrulayın: - Son 30 gün verisinde p95/p99 TTFB (Time To First Byte) sürekli yükseliyor. - Önbellek (cache) stratejisi uygulanmasına rağmen sayfalar gecikiyor. - Aynı saatlerde diğer sitelerde de benzer yavaşlama gözleniyor (paylaşımlı altyapı sinyali).

Pratik eşik: p95 TTFB değeriniz 2–3 katına çıkıyorsa ve bunun nedeni kod/DB değilse (profiling ile doğrulanabiliyorsa) dedicated’a geçiş değerlendirilmelidir.

2) Kaynak limiti uyarıları tekrar eden bir problem

Reseller’da sık görülen “sessiz” kısıtlar şunlardır: - Disk kota/IO limit uyarıları - Apache/Nginx worker limitleri - MySQL/MariaDB bağlantı sayısı tıkanması - PHP-FPM havuzu tükenmesi - Aynı host üzerinde başka hesapların yükünün sizin performansı etkilemesi

Eğer limitler yılda birkaç kez değil, ayda bir veya daha sık “tetikleniyorsa”, dedicated daha öngörülebilir bir yol olur.

3) Veri tabanı ölçekleme etkisiz kalıyor

MySQL master/replication, indeks optimizasyonu, sorgu iyileştirme gibi adımlar faydalıdır; ancak aşağıdaki durumda dedicated’a geçiş daha anlamlı olur: - DB bağlantıları artıyor ve mevcut altyapıda kaynaklar paylaşım nedeniyle geride kalıyor. - Storage (özellikle disk I/O) darboğaz yaratıyor. - Disk üzerinde büyüyen log/temporary tablolar performansı ciddi bozuyor.

Bu noktada dedicated sunucuda daha yüksek IOPS/SSD planı ve kontrol paneli + servis ayarları daha “kesintisiz” uygulanır.

4) Güvenlik ekipmanı yetmiyor: izolasyon ve ince kural yönetimi gerekiyor

Reseller’da güvenlik genellikle “sağlayıcının sunduğu” kadar sınırlandırılır. Dedicated’a geçiş ihtiyacını şu durumlar doğurur: - Tüm trafiği şirket içi politika ile yönetmeniz gerekiyor (IP bazlı rate limit, özel fail2ban, granular firewall). - Anti-DDoS katmanı sınırlı kalıyor veya kurallarınızı uygulayamıyorsunuz. - Sık sık ağ seviyesi sorun yaşıyorsunuz ve sağlayıcının müdahale süresi uzuyor.

Burada önemli nokta: DDoS tek başına “dedicated” gerektirmez; fakat izolasyon + kural kontrolü + hızlı müdahale birleşince dedicated mantıklı hale gelir.

5) Yedekleme (backup) hedefleriniz artık paylaşımlı ortamın sınırlarını aşıyor

Yedekleme için net bir hedef belirleyin: - RPO (Recovery Point Objective): Kurtarırken geri dönmeyi kabul ettiğiniz maksimum veri kaybı (ör. 15 dk). - RTO (Recovery Time Objective): Hizmeti geri getirme süresi (ör. 1 saat).

Reseller’da sağlayıcı yedeklerini tekrar üretmek veya ayrı saklama yerine disk üzerinde bırakmak RPO/RTO hedeflerinizle çakışabilir. Örneğin günlük yedek yeterli değilse, dedicated ile: - Üretimden ayrık yedek hedefi (harici storage/NAS/başka bölge) - Snapshot + offsite (uzak lokasyon) stratejisi - Log/konfig yedekleri daha düzenli kurulabilir.

6) İş sürekliliği için beklediğiniz SLA’ya resmî güvence gerekiyor

E-ticaret, ödeme işlem süreçleri, kurumsal erişim gibi senaryolarda “saatlik kesintiler” kabul edilemez. Reseller’da kesinti ve kaynak etkileri genellikle daha belirsizdir.

Net eşik: Kendi operasyonunuz için belirlediğiniz SLA ihtiyacı netleştiyse (ör. yıllık %99.9 uptime hedefi) ve sağlayıcıdan yazılı taahhüt alamıyorsanız dedicated’a geçişi planlayın.

Geçiş planı: Ölçmeden karar vermeyin (2 haftalık test taslağı)

Dedicated’a geçiş maliyetlidir; doğru zamanı yakalamak için ölçüm planı çıkarmak gerekir. Aşağıdaki taslak pratik ve hızlıdır.

1) Bugün itibarıyla baseline alın (1-2 gün)

Şunları toplayın: - Uygulama/HTTP erişim metrikleri: p50/p95/p99 yanıt süresi, istek sayısı - Sunucu metrikleri (kontrol paneli varsa): CPU/RAM, disk kullanım trendi - DB metrikleri: aktif bağlantı, yavaş sorgu sayısı - Hata/uyarı: 4xx/5xx, timeout, “max connections reached” benzeri kayıtlar

2) En kritik darboğazı bulun (3-5 gün)

• Cache (sayfa/veritabanı) gerçekten çalışıyor mu?
• DB’de indeksleme ve sorgu planı doğru mu?
• En çok kaynak tüketen endpointleri izole edin.

Bu aşamada “sorun koddan mı, paylaşımlı altyapıdan mı” ayrılır. Paylaşımlı altyapı etkisi baskınsa, dedicated’a geçiş daha net olur.

3) Reseller üzerinde limitleri kontrol edin (2-3 gün)

• Disk I/O ve storage limit davranışı
• Worker limitleri
• PHP-FPM havuzu/konfigürasyon
• Log birikimi ve inode tüketimi

Bu adım “neden” sorusunu somutlar.

4) Dedicated gereksinimini listeleyin (1-2 gün)

Dedicated’a geçerken “aynı şekilde taşımak” yerine hedeflerinizi yazın: - Hedef p95 TTFB - Yedekleme RPO/RTO - Anti-DDoS seviyeleri - Kullanacağınız kontrol paneli (Plesk/cPanel vb.) ya da panel’siz yönetim

Dedicated seçerken doğru mimari: her dedicated aynı işe yaramaz

Geçiş kararından sonra en sık yapılan hata, “daha büyük” sunucu almak ama doğru mimariyi kurmamaktır. Reseller’dan dedicated’a taşınırken aşağıdaki bileşenler kritiktir.

Kontrol paneli ve otomasyon

• Plesk vs cPanel: Lisans maliyeti + eklenti ekosistemi + yönetim alışkanlığı
• Panel kullanacaksanız yedekleme/restore akışını test edin.

Depolama (SSD/NVMe) ve I/O

DB ve loglar için depolama türü ve performansı belirleyicidir. Özellikle: - MySQL geçici tabloları - Dosya yükleme trafiği - Log yoğun uygulamalar

Depolama darboğazı yaşıyorsanız dedicated çözüm olur ama “yanlış storage” ile sonuç alamayabilirsiniz.

Ağ ve IP planı

• Gerekirse ek IP (IP alias) ve güvenlik kural seti
• IPv6 kullanımını hedefliyorsanız destek ve test

Yedek stratejisi

Minimum kabul edilebilir yapı: - Üretimden ayrı yedek hedefi - Otomatik doğrulanabilir restore denemesi - Yedek saklama politikası (ör. 14/30/90 gün)

Reseller’dan dedicated’a geçişin zamanını belirleyen pratik checklist

Aşağıdaki sorulara “evet” sayınız arttıkça geçiş zamanı olgunlaşır.

• Yoğun saatlerde p95/p99 yanıt süresi belirgin kötüleşiyor ve cache/DB optimizasyonuna rağmen düzelmiyor.
• Ay içinde tekrarlayan kaynak limiti uyarıları görüyorum.
• Veritabanı tarafında connection/timeout/yavaş sorgu artışı “paylaşımlı altyapı” etkisini işaret ediyor.
• Güvenlik için daha granular firewall/rate-limit kuralı ve izolasyon ihtiyacı var.
• Yedekleme RPO/RTO hedefime sağlayıcının sunduğu akışla ulaşamıyorum.
• Uptime/SLA tarafında resmî hedefler net ve mevcut planla karşılanmıyor.
• Geçiş olmadan maliyet artışı (ek kaynak satın almak, ek servisler, “yama” çözümler) hızlanıyor.

Ne zaman geçişi ertelemeli? Dedicated her sorunun ilacı değildir

Şu durumlarda önce daha düşük maliyetli adımları tamamlayın: - Sorun temel olarak kod performansı veya sorgu hatasıysa (profiling ile doğrulanabiliyorsa) önce optimizasyon gerekir. - Trafik ani artışı tek seferlikse ve burst sonrası düşüyorsa (örn. kampanya) geçici ölçekleme daha mantıklıdır. - Yedek hedeflerinizi sağlayıcı akışıyla güncelleyebiliyorsanız (offsite hedef, restore testi) dedicated öncesi plan güncellemesi yeterlidir.

Özetle: Dedicated’a geçiş, paylaşımlı altyapının “sınırına” dayandığınızda en hızlı sonuç verir. Sınır değilse, önce darboğazı çözmek daha doğrudur.

Sonuç: Aksiyon önerisi ve karar yöntemi

Reseller’dan dedicated’a geçişi “tahminle” değil, son 30 gündeki p95/p99 performans verisi, tekrarlayan limit/timeout kayıtları, yedekleme RPO/RTO hedefleri ve güvenlik kural ihtiyacıyla karar verin. Eğer bu sinyallerin en az 3-4 tanesi birlikte ortaya çıktıysa, 2 haftalık ölçüm planını tamamlayıp dedicated sunucuyu birincil çözüm olarak devreye alın. En doğru adım, önce baseline alıp darboğazı netleştirmek ve dedicated mimarisini (storage, ağ, yedekleme, kontrol paneli) hedeflerinize göre kurmaktır.