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

Reseller planlarından dedicated sunucuya geçiş, çoğu ekipte “sorun başlayınca” yapılan bir karar olmamalı. Doğru zamanda geçmek; performans dalgalanmasını azaltır, kaynak kısıtlarını aşar ve güvenlik/erişim kontrolünü netleştirir. Bu rehberde ne zaman dediğimiz anı somut eşiklerle tanımlayacağız; ayrıca geçiş öncesi ölçüm, geçiş planı ve kontrol listesi paylaşacağız.

Reseller vs Dedicated: Farkı asıl belirleyen 5 faktör

Reseller ile dedicated arasında “daha pahalı = daha iyi” şeklinde ilerlemek doğru değil. Kararı belirleyen şey; aynı web uygulaması için ihtiyaç duyduğunuz kaynağın ne kadarının garantili geldiği ve altyapıdan kaynaklanan darboğazların nasıl yönetildiği.

1) Kaynak paylaşımı (multi-tenant etkisi)

Reseller altyapısında CPU/RAM ve disk IO çoğu zaman fiziksel makineyi paylaşan diğer kullanıcılarla aynı havuza entegredir. Bu durum iki senaryoda görünür: - Trafik piklerinde uygulama yanıt süresi artar. - Aynı paket içinde “benim limitim dolmadı” deseniz bile performans düşer.

Dedicated tarafında ise kaynaklar tek müşteriye ayrılır. Bu sayede performans ölçümlerinde daha öngörülebilir sonuç görürsünüz.

2) Disk I/O ve veri tabanı (DB) yükü

Reseller’da disk performansı çoğu zaman paylaşımlı katmandan etkilenir. Özellikle şu yükler I/O hassastır: - Sık yazan veritabanı (MySQL/MariaDB, PostgreSQL) - Logların yoğun üretilmesi - Dosya yükleme/işleme (resim/video dönüşümü)

Dedicated’a geçişte beklenen kazanım, aynı DB yükünde daha stabil gecikme değerleridir.

3) Sunucu seviyesi erişim ve kontrol

Reseller’da çoğu yönetim kontrol paneli (ör. cPanel/DirectAdmin benzeri) üzerinden yürür. Dedicated’da ise sistemin tamamına erişim, çekirdek/ayarlar ve ağ katmanı yapılandırması belirgin hale gelir.

Bu özellikle şunlarda önem kazanır: - TLS (SSL) ve sertifika rotasyonu - Fail2ban/iptables/nftables gibi güvenlik katmanı - Uygulama servislerinin (PHP-FPM, Node.js, queue worker) tuning’i

4) SLA ve sorumluluk sınırları

Reseller planlarda SLA çoğu zaman “platform/servis” seviyesinde kalır; sorun yaşandığında hızla hangi katmanda aksiyon alındığı belirsiz olabilir. Dedicated’da ise sağlayıcı ve müşteri sorumlulukları daha net tanımlanır.

5) Ölçekleme hızı ve planlama

Reseller’da limit aşımlarında “paket büyütme” çoğu zaman hızlı çözüm gibi görünür. Ancak büyütme her zaman aynı performans kararlılığını sağlamaz. Dedicated’da ölçekleme (CPU/RAM/disk) daha doğrudan ve ölçülebilirdir.

Reseller’dan dedicated’a geçiş zamanı: net eşikler

Aşağıdaki göstergeler, geçişin “gereksiz” değil “mantıklı” olduğu anları işaret eder. Tek bir madde değil, bir kaçını aynı anda görmeniz karar kalitesini artırır.

Hız/performans eşikleri

• Son 30 günde ortalama yanıt süresi %30’dan fazla artış gösterdi.
• Aynı dönemde en yüksek trafikte (CPU/DB yükünün zirve yaptığı saatler) sayfa açılış süresi 2 saniyeden uzun kalıcı hale geldi.
• Uygulama “cache” ile iyileşmiyor veya cache sonrası bile DB sorguları darboğaz olarak kalıyor.

Kaynak ve limit eşikleri

• Kontrol paneli tarafında CPU/RAM kullanımın “limit”e yaklaşması yanında, limit dolmadan da yavaşlama yaşıyorsunuz.
• Veritabanında buffer/cache ayarları ve indeks optimizasyonlarına rağmen yavaşlama sürüyor.
• Log disk dolumu veya yüksek IO bekleme süreleri (örn. storage latency) tekrarlı hale geldi.

Uptime/SLA ve operasyon eşikleri

• Kritik servislerde 1-2 saatlik arızalar haftalık/aylık tekrar ediyor; kök neden (root cause) net şekilde platformdan kaynaklı kalıyor.
• Sağlayıcı “paylaşımlı kaynak” etkisini açıkça kabul ediyor ya da çözüm için dedicated öneriyor.
• Gecikme/hatada “sistem seviyesinde” inceleme yapmadan çözüm üretemiyorsunuz.

Güvenlik ve erişim eşikleri

• Daha güçlü izolasyon ihtiyacı: tek kiracı (single-tenant) mantığı.
• WAF/CDN kullanılsa bile uygulama katmanında daha ayrıntılı güvenlik hardening (ör. egress kısıtları, servis bazlı erişim) gereksinimi.
• İleri düzey log/izleme ve olay müdahalesi (incident response) için sistem erişimi şart oluyor.

Geçiş öncesi ölçüm: “geçelim” demeden önce 7 kontrol

Dedicated’a geçmeden önce veriyi toplamak, yanlış kapasite seçimini engeller. Aşağıdaki ölçümler kararınızı sayısallaştırır.

1) 30 gün performans panosu çıkarın

Şunları gün bazında kaydedin: - Ortalama ve p95 (95. persentil) yanıt süresi - Error rate (5xx oranı) - DB bağlantı sayısı ve yavaş sorgu (slow query) listesi

2) CPU ve load ortalamalarını birlikte yorumlayın

CPU kullanımına bakmak tek başına yetmez. Dedicated’a geçseniz bile uygulama doğru ayarlanmazsa kazanç sınırlı kalır. Bu yüzden: - CPU kullanım piki ile yanıt süresi piki eşleşiyor mu? - DB yükü ile web yükü aynı anda mı yükseliyor?

3) Disk IO gecikmesi ve dosya sistemi doluluğu

• Disk doluluk yüzdesi
• Log ve temporary (tmp) kullanımının davranışı
• IO wait veya benzeri depolama gecikme göstergeleri

4) Traffic modeli: tek saat mi, gün boyu mu?

• Zirve saatleri dar ise cache/prewarming ve worker ölçekleme ile çözüm denenebilir.
• Zirve bütün güne yayılıyorsa dedicated daha erken gündeme alınır.

5) Uygulama katmanı darboğazı var mı?

Şu adımları tamamlamadan dedicated’a atlamak maliyet yaratır: - Cache stratejisi ve invalidation - DB indeks kontrolü - Uygulama yavaş endpointlerinin profil çıkarımı

6) Yedekleme yaklaşımını netleştirin

Dedicated’a geçişte yedekleme daha esnek hale gelir ama sorumluluk sizde artar. En azından şunları planlayın: - Sunucu imaj/konfig yedeği (image/config backup) - Veritabanı yedekleri - Yedek saklama süresi ve yedeklerin şifrelenmesi

7) Kontrol paneli (varsa) ve servis konfigürasyonu

Reseller’dan dedicated’a geçtiğinizde aynı panelle devam edebilirsiniz; ancak panelin performans maliyeti ve güncelleme yönetimi değişebilir. Önemli olan: - Panel için gerekli disk alanı - Güncelleme penceresi ve değişiklik yönetimi - Otomasyon (örn. deploy/rollback) ihtiyacı

Karşılaştırma: Dedicated’a geçmenin somut faydaları

Aşağıdaki tablo, karar vermeyi kolaylaştıran “beklenen çıktı”ları listelemenin en pratik yoludur.

Ne zaman hangi dedicated tipi seçilmeli?

Dedicated tek seçenek değildir. CPU/RAID/SSD-NVMe seçimi, ağ kalitesi ve yedekleme modeli “fayda”yı doğrudan etkiler.

H3: CPU/çekirdek yoğun iş yükünde

• Video/imaj dönüşümü, yoğun cron işleri, yüksek eşzamanlı işler varsa CPU öncelikli plan seçin.
• Çok çekirdek gerektiren işlerde yalnız “toplam hız” değil çekirdek sayısı ve scheduling davranışı kritiktir.

H3: DB ağırlıklı yükte

• NVMe/SSD tercih edin; DB için I/O gecikmesi belirleyicidir.
• RAID seviyesi ve disk yedekliliği (redundancy) dokümante edilmelidir.

H3: Erişim ve güvenlik odaklı projede

• Kötüye kullanım (abuse) ve uygulama güvenliği için bant, ağ izolasyonu ve destek süreçleri önem kazanır.
• Sunucuya erişim: KVM/IPMI benzeri out-of-band yönetim varsa operasyon riskini azaltır.

Geçiş planı: riskleri azaltan 5 adım

Dedicated’a geçişte asıl hedef, downtime’ı minimize etmek ve veri kaybı riskini sıfıra yaklaştırmaktır.

1) Paralel taşıma stratejisi

• Yeni sunucuda aynı sürümleri ve konfigürasyonları hazırlayın.
• DNS kesimini planlayın; TTL değerini düşürerek kademeli geçiş yapın.

2) Yedek testini “geçişten önce” yapın

Yedek alıp sonra dönüştürmek yerine: - Yedek geri yükleme (restore) senaryosunu test edin. - Veritabanında tutarlılık kontrolü yapın.

3) Trafiği kontrollü artırın

• İlk gün sınırlı trafikte doğrulayın.
• Logları ve hata oranlarını izleyin; p95 yanıt süresi hedefini önceleyin.

4) İzleme ve alarm kurun

En azından şu metrikler: - CPU/RAM kullanım alarmı - DB bağlantı/slow query alarmı - Disk doluluk ve IO gecikmesi

5) Post-mortem dokümantasyonu

Geçiş sonrası: - Başarılı olan ayarları kaydedin. - Sorun çıktıysa “hangi parametre/katman” etkiledi netleştirin.

Sonuç: Reseller’dan dedicated’a geçişi netleştiren aksiyon

Reseller’dan dedicated’a geçişi “hissediyorum” seviyesinden çıkarmanın en iyi yolu, son 30 günde p95 yanıt süresi, DB slow query, disk IO davranışı ve tekrarlı operasyon arızaları verisini yan yana koymaktır. Bu eşiklerden birden fazlası aynı anda görülüyorsa geçiş erteleme değil, maliyet kontrolüdür.

Aksiyon önerisi: Önce NetKıyas üzerinden ihtiyaç profiline (CPU/RAM/disk ve destek/sunum SLA’sı) göre dedicated senaryolarını listeleyin; ardından geçiş öncesi 7 kontrol adımını tamamlayın. Ölçüm netleştiğinde dedicated planı seçmek, hem performans hem de operasyon riskini düşürür.