Fiziksel Sunucu Ne Zaman Gerekir? VDS Yetmiyorsa

"Dedicated sunucu ne zaman gerekir" sorusunu soruyorsanız muhtemelen elinizde çalışan bir VDS var ve o VDS son birkaç aydır sizi rahatsız ediyor: akşam saatlerinde site ağırlaşıyor, veritabanı sorguları eskisi kadar hızlı dönmüyor, paketi bir kademe büyüttünüz ama beklediğiniz sıçrama gelmedi. Türkçe kaynakların çoğu paylaşımlı hosting, VDS ve fiziksel sunucuyu üç sütunlu bir tabloda tanımlayıp bırakıyor; asıl ihtiyacınız olan şey ise tanım değil, eşik. Yani "hangi ölçümü gördüğümde artık VDS beni taşımıyor demektir" sorusunun sayısal cevabı.

Bu yazıda tam olarak onu yapıyoruz. Önce VDS ile fiziksel sunucu arasındaki farkın pazarlama cümlesi değil, çekirdek zamanlayıcısı seviyesinde ne anlama geldiğini açıklıyorum. Sonra kendi sunucunuzda çalıştırabileceğiniz komutlarla ölçülen dört somut geçiş sinyalini (CPU steal time, disk I/O bekleme, bellek baskısı, ağ kuyruğu), sanallaştırmanın lisans veya uyumluluk gereği yasak olduğu durumları, yalnızca fiziksel donanımda mümkün olan senaryoları ve maliyetin ters döndüğü noktayı tek tek geçiyoruz. En sonda da göç etmeden önce yapılması gerekenlerin kontrol listesi var — çünkü yanlış zamanda yapılan bir donanım geçişi, geç kalmış bir geçişten daha pahalıya patlar.

VDS ile Fiziksel Sunucu Arasındaki Gerçek Fark#

Aradaki fark "sanal-gerçek" ikilisi değil, kaynak paylaşımının nerede bittiğidir. Bir VDS'te size ayrılan vCPU, fiziksel bir çekirdeğin zaman dilimidir; hipervizör aynı çekirdeği başka müşterilerin sanal makineleriyle sırayla paylaştırır. RAM genellikle sabit ayrılır ve paylaşılmaz, ama disk ve ağ neredeyse her zaman ortak bir havuzdan gelir. Fiziksel sunucuda ise CPU, RAM, disk denetleyicisi ve ağ kartı tamamen sizindir; aradaki hipervizör katmanı yoktur.

Bu farkın pratikteki üç yansıması vardır:

1. Öngörülebilirlik. VDS'te ortalama performans iyi olabilir ama en kötü durum performansı komşularınıza bağlıdır. Fiziksel sunucuda en kötü durum sizin kendi yükünüzdür.
2. Donanım erişimi. Sanallaştırma katmanı, PCIe kartlarını, özel disk denetleyicilerini, donanımsal dongle'ları ve bazı düşük seviye CPU özelliklerini ya gizler ya da kısıtlar.
3. Sorumluluk. Fiziksel sunucuda snapshot alma, anlık boyut büyütme, farklı bir düğüme canlı taşınma gibi konforlar ortadan kalkar. Yedekleme ve yüksek erişilebilirliği artık siz kurgularsınız.

Sanallaştırmanın mekaniğini daha derinden merak ediyorsanız KVM ile sanallaştırma yazısı bu tabloda "hipervizör" diye geçen katmanın içini açıyor.

Geçiş Sinyali 1: Sürekli Yüksek CPU ve Steal Time#

En net geçiş sinyali, iş yükünüz artmadığı hâlde CPU steal time'ın sürekli %3'ün üzerinde seyretmesidir. Steal time, sanal makinenizin çalışmak istediği ama hipervizörün CPU'yu başkasına verdiği için beklediği süredir. Kendi kodunuzla düzeltebileceğiniz bir şey değildir; komşu yükünün doğrudan ölçüsüdür.

Ölçmek için:

# Anlık: top çıktısında %st sütunu
top -bn1 | head -3

# Zaman serisi: 1 saniyede bir, 30 örnek
vmstat 1 30

# Çekirdek başına ayrıntı (sysstat paketi)
mpstat -P ALL 2 10

vmstat çıktısındaki son sütun st'dir:

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 8  1      0 412880  91240 2210448    0    0    12    88 4210 9840 61 12  9  3 15

Buradaki st 15, CPU zamanınızın %15'inin hipervizör tarafından başkasına verildiği anlamına gelir. Bu tablodaki r sütunu (çalışmayı bekleyen süreç sayısı) de 8 ve çekirdek sayınızdan büyükse, sunucu sürekli kuyruk yönetiyor demektir. Yorumlama eşikleri şöyle:

• %0–2: Normal. Her paylaşımlı ortamda bir miktar steal olur.
• %3–8: Dikkat. Yoğun saatlerde gözle görülür yavaşlama yaparsınız.
• %8 ve üzeri, üç günden uzun süreyle: Bu VDS artık size yetmiyor. Ya sağlayıcıdan daha az yoğun bir düğüme taşınma isteyin ya da fiziksel sunucuyu konuşun.

Steal time düşük ama us (kullanıcı alanı CPU) sürekli %85 üzerindeyse durum farklıdır: sorun komşularınız değil, kendi uygulamanızdır. Önce profil çıkarın; çünkü kötü yazılmış bir sorguyu fiziksel sunucuya taşımak onu düzeltmez, sadece faturayı büyütür. Yük ortalamasını doğru okumak için Linux load average anlamak ve süreç izleme ps top htop yazılarına bakın.

Geçiş Sinyali 2: Disk I/O Darboğazı ve iowait#

Disk kaynaklı geçiş kararının eşiği, iowait değerinin sürekli %10'un üzerinde olması ve disk gecikmesinin (await) tek haneli milisaniyelerden çıkmasıdır. Paylaşımlı depolamada bu, çoğu zaman CPU'dan önce duvara toslanan yerdir.

# Genişletilmiş disk istatistikleri, 2 saniyede bir
iostat -x 2 5

# Hangi süreç ne kadar okuyor/yazıyor
iotop -oPa

# Çekirdek seviyesinde basınç göstergeleri (PSI)
cat /proc/pressure/io
cat /proc/pressure/cpu

iostat -x çıktısında bakacağınız üç sütun şunlardır: r_await/w_await (istek başına ortalama bekleme, ms), aqu-sz (kuyruk derinliği) ve %util. NVMe tabanlı bir sistemde w_await değerinin 1 ms civarında olmasını beklersiniz. Sürekli 20–40 ms görüyorsanız ve %util %90'ın üzerindeyse, ya kendi yazma deseniniz kötüdür ya da havuzu paylaştığınız komşular diski doyuruyordur.

/proc/pressure/io çıktısı işi kesinleştirir:

some avg10=48.21 avg60=44.90 avg300=41.03 total=98211234
full avg10=31.77 avg60=29.55 avg300=27.12 total=61220441

full avg300 değerinin sürekli 20'nin üzerinde olması, sistemin zamanının beşte birinden fazlasını disk beklerken tamamen durdurduğu anlamına gelir. Bu, "biraz yavaş" değil, yapısal bir darboğazdır. Kendi disk kullanımınızı temizlemek işe yarayacak mı diye bakmak için disk kullanımı df du ncdu yazısındaki adımları uygulayın; sorun doluluk değil de eşzamanlı erişimse, fiziksel diskin tek kullanıcısı olmak tek çözümdür.

Geçiş Sinyali 3: Bellek Baskısı ve Swap Kullanımı#

RAM tarafındaki eşik basittir: swap'e düzenli olarak yazıyorsanız ve RAM'i artırmak için VDS paketinde bir üst kademe kalmadıysa, fiziksel sunucu gündemdedir. VDS paketlerinde RAM, üst kademelerde en pahalı bileşendir; 128 GB ve üzeri ihtiyaçlarda sanal paket fiyatı fiziksel makineyi geçmeye başlar.

free -h
# swap'e yazma/okuma hızını görün: si ve so sütunları
vmstat 5 12
# Hangi süreç ne kadar bellek tutuyor
ps -eo pid,comm,rss --sort=-rss | head -15

vmstat çıktısındaki si/so sütunları sıfırdan farklıysa ve bu sürekliyse, sistem aktif olarak takas yapıyor demektir. Tek seferlik bir yedekleme işinden sonra swap dolu kalması normaldir; sürekli akış anormaldir. Geçici çözüm için swap alanı oluşturma yazısına bakabilirsiniz ama swap bir çözüm değil, bir amortisördür.

Bellek tarafında fiziksel sunucuyu zorunlu kılan ikinci bir durum daha vardır: ECC bellek ihtiyacı. Finansal hesaplama, uzun süre çalışan bilimsel işler ve büyük in-memory veritabanları için bit hatalarının donanım seviyesinde düzeltilmesi gerekir. Sanal paketlerde bu bir seçenek olarak sunulmaz; fiziksel sunucuda ise sunucu sınıfı anakartın standardıdır.

Sanallaştırmanın Yasak veya Sorunlu Olduğu Durumlar#

Bazı geçişlerin performansla hiç ilgisi yoktur; lisans veya uyumluluk zorunluluğu vardır. Türkçe içeriklerde neredeyse hiç geçmeyen ama gerçek hayatta en sık karşılaştığım kalemler şunlardır:

• Çekirdek bazlı lisanslanan kurumsal yazılımlar. Bazı veritabanı ve ERP lisansları, sanal ortamda "makinedeki tüm fiziksel çekirdekler" üzerinden ücretlendirme yapar. 4 vCPU'luk bir VDS, altındaki 64 çekirdekli düğüm üzerinden lisanslanmak zorunda kalabilir. Fiziksel bir makinede ise çekirdek sayısını siz belirlersiniz ve lisans bedeli öngörülebilir olur.
• Donanım kilidi (dongle) gerektiren yazılımlar. Muhasebe, CAD ve bazı sektörel programlar USB dongle ister. Sanal sunucuya USB takamazsınız; fiziksel sunucuda takarsınız.
• Sanallaştırma platformu çalıştırma ihtiyacı. Kendi içinde VM barındıran bir yapı kuracaksanız (Proxmox, VMware, Hyper-V), iç içe sanallaştırma performansı ciddi biçimde düşürür ve her sağlayıcı buna izin vermez. Nested destekli özel paketler bu boşluğu doldurur ama tam performans isteyen üretim yükleri için fiziksel makine doğru cevaptır.
• Uyumluluk ve denetim gereksinimleri. Bazı denetim çerçeveleri, verinin fiziksel olarak izole bir donanımda tutulduğunun kanıtlanmasını ister. "Aynı fiziksel makinede başka müşteri yok" ifadesini sözleşmeye yazdırabilmeniz gerekir.
• Yüksek çekirdek sayılı, uzun süreli tek iş. Video kodlama, derleme çiftlikleri, simülasyon gibi işler CPU'yu saatlerce %100'de tutar. Bu profil, paylaşımlı düğümlerde hem sizin hem komşularınızın canını sıkar ve çoğu sağlayıcının adil kullanım politikasına takılır.

Donanım hızlandırma gerektiren yapay zekâ ve render işleri ayrı bir kategoridir; onlar için GPU sunucu kiralama rehberi yazısındaki kriterler geçerlidir.

Ağ Tarafı: Bant Genişliği mi, Paket İşleme mi#

Ağ darboğazı iki farklı şekilde gelir ve ikisinin çözümü aynı değildir. Birincisi bant genişliği doyumu: hattınız dolar, transfer yavaşlar. İkincisi paket işleme (pps) darboğazı: bant genişliği boş görünür ama saniyedeki paket sayısı yüksektir ve CPU kesme (interrupt) işlemekten uygulamaya vakit bulamaz. İkincisi özellikle küçük paketli API trafiğinde ve saldırı anlarında görülür.

# Arayüz istatistikleri, hata ve düşen paket sayıları
ip -s link show eth0

# Saniyelik pps ve bant genişliği
sar -n DEV 1 10

# Yumuşak kesme yükü: si sütunu
mpstat -P ALL 1 5

ip -s link çıktısında dropped ve overrun sayaçlarının artıyor olması, kartın veya kuyruğun yetişemediğini gösterir. Fiziksel sunucuda ağ kartı kuyruklarını (RSS, RPS) kendiniz ayarlayabilir, kesmeleri belirli çekirdeklere sabitleyebilirsiniz; sanal makinede bu ayarların çoğu hipervizör tarafından belirlenir. Ağ tarafında sorunun sizden mi ara hattan mı kaynaklandığını ayırmak için ağ tanılama ping traceroute mtr yazısındaki yöntemi kullanın.

Maliyet Eşiği: Fiziksel Ne Zaman Daha Ucuz Olur#

Fiziksel sunucu, aylık maliyet grafiğinde başta pahalı görünür ama doğrusal artmaz. VDS paketleri kaynak ikiye katlandıkça fiyatı da yaklaşık ikiye katlar; fiziksel sunucuda ise bir kere makineyi kiraladıktan sonra üzerindeki 12 çekirdeği de 32 çekirdeği de aynı sabit bedelle kullanırsınız. Kesişim noktası genelde şu üç durumda gelir:

1. Aynı iş için üç ve daha fazla orta boy VDS çalıştırıyorsanız. Üç ayrı sanal makinenin toplam bedeli tek fiziksel makineyi geçmeye başlar ve üstelik yönetmeniz gereken üç işletim sistemi vardır.
2. Sürekli %70'in üzerinde kaynak kullanıyorsanız. Sanal paketlerin ekonomisi, ortalama kullanımın düşük olması varsayımına dayanır. Kaynağı sürekli dibine kadar kullanan bir yük, sanal ortamda en pahalı yüktür.
3. Kendi sanallaştırmanızı kurup üzerinde birden çok ortam çalıştıracaksanız. Test, staging ve üretimi tek fiziksel makinede kendi hipervizörünüzle bölmek çoğu zaman en verimli düzendir.

Buna karşılık fiziksel sunucunun görünmeyen maliyetleri vardır ve Türkçe içeriklerde bunlar hiç yazılmaz: yedeklilik artık sizin işinizdir (tek makine = tek arıza noktası), bir disk arızasında kurtarma süresi sanal ortamdaki snapshot geri yüklemesinden uzundur, ve kaynağı büyütmek panelden değil planlamayla olur. Kaba fiyat mantığını sunucu kiralama fiyatları yazısında karşılaştırmalı olarak ele aldım.

Geçiş Öncesi Kontrol Listesi#

Fiziksel sunucuya geçmeye karar verdiyseniz, taşımadan önce şu sekiz maddeyi sırayla tamamlayın. Yıllarca gördüğüm en pahalı hata, ölçüm yapmadan yapılan geçiştir: yeni makinede aynı yavaşlığı gören insan sayısı sandığınızdan fazladır.

1. Mevcut yükün profilini çıkarın. En az yedi gün boyunca CPU, RAM, disk IOPS ve pps değerlerini kaydedin. Zirve saatlerini bilmeden donanım seçemezsiniz. Ölçüm için Netdata ile sunucu izleme yeterlidir.
2. Darboğazı isimlendirin. "Yavaş" bir teşhis değildir. CPU mu, disk mi, bellek mi, ağ mı? Yanlış bileşene para harcamayın.
3. Uygulama tarafında yapılacak iş kaldı mı bakın. İndekssiz bir sorgu, önbelleksiz bir tema veya sıkıştırılmamış görseller donanımla örtülmez.
4. Lisans envanteri çıkarın. Fiziksel makinede çekirdek sayısı lisans bedelini doğrudan etkiler. Sözleşmeleri önce okuyun.
5. Yedekleme planını yazın. Snapshot konforu gidiyor. Tam yedek + artımlı yedek + kurtarma tatbikatı üçlüsünü kurmadan taşımayın. Restic ile yedekleme veya rsync tabanlı bir düzen bunun için yeterlidir.
6. Kurulumu otomatikleştirin. Yeni makineyi elle kurarsanız, bir sonraki arızada aynı işi elle tekrar yaparsınız. Kurulumu koda dökün; Ansible ile sunucu otomasyonu bunun standart yoludur.
7. Geri dönüş planı hazırlayın. Eski VDS'i taşımadan sonra en az iki hafta kapatmayın. DNS TTL değerlerini geçişten 24 saat önce düşürün.
8. Güvenlik temelini ilk gün kurun. Yeni bir IP, saldırı taramalarına yeni bir hedef demektir. Sunucu sertleştirme kontrol listesi ve UFW güvenlik duvarı adımlarını kurulumun ilk saatinde tamamlayın.

Fiziksel Sunucu Seçerken Nelere Bakılır#

Donanım seçiminde ölçtüğünüz darboğaza göre öncelik değişir; herkese uyan tek yapılandırma yoktur.

Bir de sık atlanan üç soru vardır: IPMI/uzak konsol erişimi veriliyor mu (işletim sistemi açılmadığında tek kurtarma yolunuz budur), disk değişimi ne kadar sürede yapılıyor, ve ek IP bloğu alınabiliyor mu. Bu üçünü sipariş öncesi sorun; sonradan sorulduğunda cevabı değiştirmek zordur.

Sıkça Sorulan Sorular#

VDS mi dedicated sunucu mu daha hızlıdır#

Aynı donanım nesli varsayıldığında fiziksel sunucu her zaman daha öngörülebilir, çoğu zaman da daha hızlıdır; çünkü hipervizör katmanı ve komşu yükü ortadan kalkar. Ancak "daha hızlı" ifadesi yanıltıcı olabilir: iyi bir NVMe VDS, eski nesil işlemcili bir fiziksel makineden daha iyi sonuç verebilir. Karar verirken markaya veya sanal/fiziksel etiketine değil, işlemci neslinize, disk tipine ve ölçtüğünüz steal time değerine bakın. Yükünüz düşükse fiziksel sunucuya geçmek hız kazandırmaz, sadece boşta duran kaynak ödersiniz.

Steal time kaç olursa sunucu değiştirmem gerekir#

Üç günden uzun süredir ortalama %8'in üzerinde steal time görüyorsanız değişiklik gerekir. %2'nin altı normal kabul edilir, %3–8 aralığı yoğun saatlerde hissedilir yavaşlama üretir. Ölçümü vmstat 1 30 komutuyla en az bir tam gün boyunca farklı saatlerde alın; tek bir anlık ölçüm yanıltıcıdır. Önce sağlayıcınızdan daha az yoğun bir düğüme taşınma talep edin, sonuç alamazsanız fiziksel sunucuyu değerlendirin.

Fiziksel sunucuda snapshot alınabilir mi#

Hipervizör düzeyinde anlık snapshot alınamaz, ancak dosya sistemi düzeyinde eşdeğer çözümler vardır. LVM anlık görüntüleri, ZFS veya Btrfs snapshot'ları ve blok düzeyi artımlı yedekleme araçları benzer işlevi görür. Farkı şudur: sanal makinede snapshot sağlayıcının altyapısındadır, fiziksel sunucuda ise yedeği aynı makinede tutmak bir işe yaramaz — mutlaka farklı bir konuma kopyalamanız gerekir. Geçiş kararı verirken bu ek işi planınıza dahil edin.

Tek fiziksel sunucu yüksek erişilebilirlik sağlar mı#

Hayır, tek fiziksel sunucu tanım gereği tek arıza noktasıdır. Çift güç kaynağı ve RAID, disk veya güç kaynağı arızasına karşı korur; ancak anakart, işlemci veya ağ kartı arızasında sunucu tamamen durur. Gerçek yüksek erişilebilirlik için ya iki fiziksel makine ve önlerinde bir yük dengeleyici gerekir ya da sanal ortamın canlı taşıma yeteneğinden faydalanmak gerekir. Kesintisizlik önceliğinizse, tek büyük fiziksel makine yerine iki orta boy makineyi değerlendirin.

VDS paketimi büyütmek yerine neden fiziksel sunucu alayım#

Paket büyütmenin işe yaramadığı üç durum vardır: darboğaz CPU değil disk paylaşımıysa, steal time yüksekse, veya bir üst kademe artık maliyet olarak fiziksel makineyi geçiyorsa. Bunların hiçbiri yoksa paketi büyütmek daha doğru karardır — çünkü dakikalar içinde olur, geri alınabilir ve yeni bir işletim sistemi kurmanız gerekmez. Kaba kural şudur: aynı iş için üçüncü VDS'i açmak üzereyseniz, o parayla tek fiziksel makineyi konuşmanın zamanı gelmiştir.

Colocation ile kiralık fiziksel sunucu arasındaki fark nedir#

Colocation'da donanım sizindir, veri merkezi yalnızca alan, elektrik, soğutma ve ağ sağlar; kiralık fiziksel sunucuda donanım da sağlayıcıya aittir. Colocation, elinizde zaten uygun donanım varsa veya çok özel bir yapılandırmaya ihtiyaç duyuyorsanız mantıklıdır. Kiralamada ise arızalı bir diski değiştirmek sağlayıcının işidir ve donanım yenileme döngüsünü siz finanse etmezsiniz. Uzun vadeli, sabit ve büyük ölçekli yükler dışında kiralama çoğu ekip için daha az riskli seçenektir.

Fiziksel sunucuya geçerken kesinti ne kadar sürer#

İyi planlanmış bir geçişte gerçek kesinti birkaç dakikadan uzun sürmez; kötü planlanmışta saatler alır. Yöntem şudur: yeni makineyi kurun, veriyi önceden senkronize edin, geçiş anında yalnızca son değişiklikleri aktarın ve DNS TTL değerini geçişten en az 24 saat önce 300 saniyeye düşürün. Eski sunucuyu hemen kapatmayın; DNS yayılımı tamamlanana kadar iki hafta açık bırakmak, geç ulaşan trafiği kaybetmenizi önler.

Sunucu yönetimini kendim yapamıyorsam fiziksel sunucu almalı mıyım#

Yönetim deneyiminiz yoksa fiziksel sunucu tek başına doğru cevap değildir; yönetilen bir hizmetle birlikte düşünülmelidir. Fiziksel makinede güncelleme, güvenlik duvarı, yedekleme, izleme ve arıza müdahalesi tamamen sizin sorumluluğunuzdadır ve sanal ortamdaki "snapshot'tan geri dön" güvenlik ağı yoktur. Ekipte sistem yönetimi bilgisi yoksa ya yönetilen sunucu hizmeti alın ya da VDS'te kalıp uygulama tarafını optimize edin. Yanlış yönetilen güçlü bir makine, iyi yönetilen küçük bir makineden daha kötü çalışır.

Kapanış#

Fiziksel sunucuya geçiş kararı, ürün karşılaştırma tablosuyla değil, kendi sunucunuzdan aldığınız ölçümlerle verilir. Kısaca özetlersek: sürekli %8 üzeri steal time, /proc/pressure/io değerlerinin uzun süre 20'nin üzerinde kalması, düzenli swap akışı, çekirdek bazlı lisans zorunluluğu, donanım kilidi veya kendi sanallaştırmanızı kurma ihtiyacı — bunlardan biri varsa geçiş konuşulur. Hiçbiri yoksa geçiş, ödediğiniz parayı boşta duran kaynağa çevirmekten öteye gitmez. Ölçün, darboğazı isimlendirin, uygulama tarafında yapılacak iş kaldı mı bakın, sonra donanıma para harcayın.

Elinizdeki ölçümler geçişi işaret ediyorsa donanım seçimini ve teslim sürecini konuşmak için dedicated sunucu sayfasındaki yapılandırmalara bakabilir, henüz o eşikte değilseniz bir kademe yukarısı için VDS paketlerini inceleyebilirsiniz. Kendi donanımınızı veri merkezine yerleştirmeyi düşünüyorsanız colocation, kurulum ve bakım yükünü üstlenmek istemiyorsanız sunucu yönetimi hizmeti bu işi devralır — böylece siz uygulamanızla, işletim sistemiyle ilgilenen başkası olur.