Dedicated sunucu ne zaman gerekir sorusunun cevabı, çoğu zaman sanıldığından daha geç gelir. Sanal sunucular son yıllarda o kadar güçlendi ki orta ölçekli bir e-ticaret sitesi, bir SaaS uygulaması veya birkaç yüz oyunculu bir oyun sunucusu VDS üzerinde rahatlıkla çalışır. Ancak belirli bir noktadan sonra sanallaştırmanın kendisi bir maliyet hâline gelir ve fiziksel sunucuya geçmek hem performans hem bütçe açısından doğru karar olur. Bu yazıda o noktayı gösteren somut işaretleri, erken geçişin bedelini ve geçiş sırasında dikkat edilecekleri anlatıyoruz.
Önce sanal sunucunun sınırının nerede başladığını netleştirelim. VPS ve VDS’te bir fiziksel makine hipervizör ile bölünür; işlemci, bellek ve disk size ayrılır ama donanımın kendisi paylaşımlıdır. Bu modelin iki yapısal sınırı vardır. Birincisi kaynak paketlerinin üst sınırıdır: sağlayıcının en büyük sanal paketi belirli bir çekirdek ve bellek miktarında biter. İkincisi sanallaştırma katmanının kendisidir: disk ve ağ işlemleri hipervizörden geçer, komşu sanal makinelerin davranışı ve ana makinenin bakım takvimi sizi dolaylı olarak etkiler. VDS’te çekirdekler tahsisli olduğu için işlemci tarafında bu etki küçüktür; ama disk ve ağ tarafında tamamen ortadan kalkmaz. VPS ile VDS arasındaki farkı bu yazıda ayrıntılı anlattık; dedicated, o eksenin bir sonraki adımıdır.
İşaret 1: Kaynak grafiği tavana yaslanmış
En net işaret budur. Sunucunuzun bir haftalık işlemci ve bellek grafiğine bakın. İşlemci kullanımı günün büyük bölümünde yüzde 70’in üzerinde seyrediyorsa, bellek sürekli doluysa ve takas alanı (swap) kullanılıyorsa, bir sonraki sanal pakete geçmek kısa süreli rahatlama sağlar. Sanal paketlerin üst sınırına geldiyseniz veya iki paket üstü de birkaç ay içinde dolacaksa, fiziksel sunucuya geçmek tekrar tekrar paket büyütmekten ucuzdur. Önemli bir uyarı: yük anlık sıçramalardan oluşuyorsa (günde iki saat yoğunluk, gerisi boş) sorun kapasite değil uygulamadır; önce o kısmı düzeltin. Grafiği okurken ortalamaya değil yoğun saatlere bakın; ortalama yüzde 40 görünen bir sunucu akşam saatlerinde iki saat boyunca yüzde 100’de kalıyor olabilir ve oyuncu ya da müşteri tam o saatlerde içeridedir.
İşaret 2: Disk gecikmesi ve giriş/çıkış darboğazı
Veritabanı ağırlıklı işlerde işlemci boşta görünürken sistem yavaş kalabilir. Bunun nedeni genelde disk bekleme süresidir (iowait). Sanal sunucuda disk, hipervizör üzerinden ve çoğunlukla ağ bağlantılı bir depolama katmanından gelir; yoğun yazma işlemlerinde gecikme sıçrar. Dedicated sunucuda doğrudan makineye takılı NVMe diskler, RAID yapılandırmasını kendinizin belirlemesi ve disk kuyruğunun yalnızca size ait olması bu darboğazı ortadan kaldırır. Yoğun veritabanı, büyük log işleme, video dönüştürme ve oyun sunucusu veritabanları bu kategoriye girer. Oyun tarafındaki darboğazları ayrı bir yazıda ele aldık; orada anlattığımız "her tıklamayı veritabanına yazma" hatası, donanımdan önce düzeltilmesi gereken bir örnektir.
İşaret 3: Komşu etkisi ve tutarsız performans
Performans ölçümleriniz gün içinde, siz hiçbir şey değiştirmeden dalgalanıyorsa ve sağlayıcınız "ana makinede bakım vardı" türünden açıklamalar yapıyorsa, sanallaştırmanın paylaşımlı doğasıyla karşı karşıyasınız demektir. VDS bunu büyük ölçüde azaltır; ama ağ kartı, disk denetleyicisi ve ana makinenin kendisi hâlâ ortaktır. Gecikmenin kritik olduğu işlerde (gerçek zamanlı oyun, finansal işlem, canlı yayın) tutarlılık, ham güçten daha değerlidir. Fiziksel sunucuda performans eğrisi düzdür; dün ölçtüğünüz değer yarın da aynıdır. Tutarsızlığı ölçmenin basit yolu, aynı sorguyu veya aynı işlemi gün içinde farklı saatlerde çalıştırıp süreleri karşılaştırmaktır; fark yüzde 30’u geçiyorsa sorun büyük olasılıkla sizin kodunuzda değildir.
İşaret 4: Donanım üzerinde denetim ihtiyacı
Bazı ihtiyaçlar sanal ortamda ya hiç karşılanmaz ya da pahalı karşılanır:
- Özel çekirdek (kernel) modülleri, kendi hipervizörünüzü kurma veya iç içe sanallaştırma
- GPU, çok büyük bellek (256 GB ve üzeri) veya özel ağ kartı gereksinimi
- RAID düzenini, disk sayısını ve disk tipini kendinizin belirlemesi
- Lisanslamanın fiziksel çekirdek sayısına bağlı olduğu yazılımlar
- Verinin yalnızca sizin denetiminizdeki donanımda tutulması gereken sözleşme veya uyumluluk şartları
Bu maddelerden biri sizin için geçerliyse, sanal sunucuyla uğraşmak yerine doğrudan fiziksel sunucuya geçmek zaman kazandırır.
İşaret 5: Maliyet eşiği aşıldı
Büyük sanal paketlerin aylık bedelini toplayın ve aynı kaynakları sunan bir dedicated sunucunun bedeliyle karşılaştırın. Belirli bir ölçekten sonra fiziksel sunucu, aynı çekirdek ve bellek için sanal paketten daha ucuza gelir; çünkü sağlayıcının sanallaştırma, yönetim ve esneklik payını ödemezsiniz. Aynı şekilde birden fazla sanal sunucunuz varsa ve bunlar tek bir fiziksel makineye sığıyorsa, o makineyi kiralayıp kendi sanallaştırmanızı kurmak toplam maliyeti düşürür. Bunun ters tarafı da var: tek bir küçük uygulama için dedicated kiralamak, kullanılmayan kapasiteye para ödemektir. Hesaba trafik bedelini de katın; bazı sağlayıcılar sanal paketlerde trafik sınırı koyarken fiziksel sunucuda daha geniş kota verir.
Dedicated sunucunun bedeli: dürüst bir liste
Fiziksel sunucu her şeyin çözümü değildir; şu bedelleri bilerek geçmek gerekir. Kaynak büyütmek sanal sunucudaki gibi birkaç dakikalık iş değildir; bellek veya disk eklemek fiziksel müdahale ve kesinti ister. Donanım arızası sizin sorununuzdur; disk veya güç kaynağı bozulduğunda sağlayıcının yedek parça süresi kadar beklersiniz, bu yüzden RAID ve düzenli yedek zorunludur. Tek makineye bağımlı kalırsınız; yüksek erişilebilirlik istiyorsanız ikinci bir makine ve yük dağıtımı gerekir. Son olarak yönetim yükü artar: işletim sistemi, güvenlik, izleme ve yedekleme bir sistem yöneticisinin işidir; ekibinizde bu kişi yoksa yönetimli dedicated paketi veya dışarıdan sunucu yönetimi hizmeti düşünün. Bu yüzden geçişi tek adımda değil, önce veritabanı gibi en çok kaynak isteyen bileşeni taşıyarak yapmak çoğu projede daha güvenlidir; sanal sunucu bir süre web katmanını taşımaya devam eder.
Geçiş öncesi kontrol listesi
- Son 30 günün işlemci, bellek, disk bekleme ve ağ grafikleri çıkarıldı mı?
- Yük, kapasite sorunu mu yoksa uygulama sorunu mu; yavaş sorgular ve zamanlayıcılar incelendi mi?
- Hedef sunucunun çekirdek frekansı, bellek ve NVMe/RAID yapısı iş yüküne göre seçildi mi?
- Lokasyon hedef kitleye yakın mı; ağ kapasitesi ve DDoS koruması dahil mi?
- Yedekleme ve izleme, taşınmadan önce yeni sunucuda kuruldu mu?
- Taşıma planı ve geri dönüş senaryosu yazıldı mı; DNS geçişi için düşük TTL ayarlandı mı?
- Donanım arızasında parça değişim süresi sözleşmede yazıyor mu?
Özetle: kaynak grafiği tavana dayanmışsa, disk gecikmesi işlemciden önce tıkanıyorsa, performans tutarsızsa, donanım üzerinde denetim gerekiyorsa veya sanal paketlerin toplamı fiziksel sunucudan pahalıya geliyorsa geçiş zamanı gelmiştir. Bu işaretlerden en az ikisi sizde varsa dedicated sunucu seçeneklerimize bakabilir, mevcut grafiklerinizi paylaşarak doğru yapılandırmayı birlikte belirleyebiliriz.