Uygulamanız sanal sunucuda çalışıyor ve zaman zaman açıklanamayan yavaşlamalar yaşıyorsunuz. İşlemci kullanımı düşük, bellek bol, disk boş, ama yanıt süreleri dakikalarca iki katına çıkıp sonra normale dönüyor. Kodda bir sorun bulamıyorsunuz çünkü sorun kodda değil: aynı fiziksel makineyi paylaştığınız başka bir müşteri o anda ağır bir iş çalıştırıyor. Bare metal sunucu ne zaman gerekir sorusunun en dürüst cevabı burada başlıyor; sanallaştırmanın sağladığı esnekliğin, bazı iş yükleri için ödediğiniz görünmez bir bedeli var.
Bu yazıda bare metal kararını duygusal değil ölçülebilir hale getireceğiz. Önce bare metal, dedicated ve bulut kavramlarını netleştireceğim. Sonra sanallaştırmanın gerçekte neye mal olduğunu, steal time gibi somut metriklerle nasıl ölçeceğinizi göstereceğim. Ardından bare metal'in gerçekten zorunlu olduğu senaryoları ve tam tersine gereksiz olduğu durumları ayıracağız. Sonunda karar tablosu, melez yaklaşımlar ve bu geçişte en sık yapılan hatalar var.
Bare Metal, Dedicated ve Bulut Arasındaki Fark#
Terimler pazarlama dilinde iç içe geçtiği için önce netleştirelim.
Bare metal, üzerinde hipervizör olmayan fiziksel bir sunucudur. İşletim sisteminiz doğrudan donanımda çalışır; arada bir soyutlama katmanı yoktur. Donanımın tamamı sizindir ve isterseniz kendi hipervizörünüzü de kurabilirsiniz.
Dedicated sunucu pratikte aynı şeyi anlatır; sektörde bare metal terimi genellikle saatlik veya otomatik sağlanan fiziksel sunucular için, dedicated ise aylık kiralanan klasik fiziksel sunucular için kullanılır. Teknik olarak ikisi de "hipervizör yok, donanım sizin" demektir.
Sanal sunucu (VDS/VPS) ise bir hipervizör üzerinde çalışır. İşlemci çekirdekleri, bellek ve disk fiziksel bir makineden bölünerek size ayrılır. Bulut sunucu bunun üzerine dakikalar içinde sağlama, anlık görüntü ve otomatik ölçekleme gibi yetenekler ekler.
| Konu | Bare metal | Sanal sunucu | Colocation |
|---|---|---|---|
| Hipervizör | Yok | Var | Yok |
| Donanım paylaşımı | Yok | Var | Yok |
| Sağlama süresi | Saatler | Dakikalar | Günler |
| Donanım sahipliği | Sağlayıcıda | Sağlayıcıda | Sizde |
| Anlık ölçekleme | Sınırlı | Yüksek | Yok |
| Performans öngörülebilirliği | En yüksek | Değişken | En yüksek |
Sanal ve fiziksel arasındaki genel karşılaştırmayı bulut sunucu mu VDS mi yazısında, dedicated tarafının ticari ve operasyonel yönünü ise dedicated sunucu ne zaman gerekir yazısında ele aldım; bu rehber özellikle sanallaştırma katmanının teknik maliyetine odaklanıyor.
Sanallaştırmanın Görünmeyen Maliyeti#
Modern hipervizörler çok verimlidir; işlemci ve bellek erişiminde donanım desteği sayesinde ek yük tek haneli yüzdelere iner. Yani "sanallaştırma yavaştır" cümlesi genel olarak yanlıştır. Gerçek maliyet başka üç yerde birikir.
Birincisi kaynak rekabeti. Fiziksel makinedeki çekirdekler birden fazla sanal makineye paylaştırılmıştır. Sizin sanal işlemciniz çalışmak istediğinde fiziksel çekirdek başka bir misafirle meşgulse beklersiniz. Bu bekleme süresi Linux'ta steal time olarak ölçülür ve doğrudan görünür.
İkincisi gecikme değişkenliği. Ortalama performans iyi olsa bile en kötü yüzde bir dilim (p99 gecikme) bare metal'e göre belirgin biçimde daha kötü olabilir. Toplu iş yüklerinde bu önemsizdir; gerçek zamanlı işlem yapan sistemlerde belirleyicidir.
Üçüncüsü donanıma doğrudan erişim eksikliği. Hipervizör bazı yetenekleri ya hiç sunmaz ya da kısıtlı sunar: CPU çekirdeği sabitleme, NUMA yerleşimi kontrolü, büyük sayfa (huge page) yönetimi, NVMe cihazına doğrudan erişim, GPU aktarımı ve iç içe sanallaştırma bunların başında gelir.
Ölçüm: Karar Vermeden Önce Neye Bakmalı#
Bare metal'e geçmeden önce sorunun gerçekten sanallaştırmadan kaynaklandığını kanıtlayın. Aksi halde daha pahalı bir sunucuda aynı yavaş uygulamayı çalıştırırsınız. İzlenecek sıra şu:
- Steal time'a bakın. Bu, hipervizörün sizi beklettiği süredir ve doğrudan gürültülü komşu göstergesidir.
- Gecikme dağılımına bakın, ortalamaya değil. Ortalama iyi ama p99 kötüyse değişkenlik sorunu vardır.
- Disk gecikmesini ölçün. Paylaşımlı depolamada saniyedeki işlem sayısı sınırlanmış olabilir.
- Uygulamayı profilleyin. Darboğaz gerçekten altyapıda mı, yoksa indekssiz bir sorguda mı?
Steal time'ı görmek için:
# vmstat çıktısındaki "st" sütunu: hipervizörün çaldığı zaman yüzdesi
vmstat 1 10
# Çekirdek başına ayrıntılı görünüm (sysstat paketi)
mpstat -P ALL 1 5
# Anlık bakış: top çıktısındaki %Cpu(s) satırında "st" değeri
top -bn1 | head -5
Yorumlama basittir: sürekli yüzde 1'in altındaki steal time normaldir ve göz ardı edilebilir. Yüzde 5 civarına yerleşmişse fark edilir bir kayıp yaşıyorsunuz. Yüzde 10'un üzerinde süreklilik gösteriyorsa, işlemci gücünüzün onda birinden fazlasını hiç kullanamıyorsunuz demektir ve bu, sunucu değiştirmek için nesnel bir gerekçedir.
Hangi ortamda olduğunuzu da doğrulayın; bazen fiziksel sandığınız makine aslında sanaldır:
# Sanallaştırma tipini söyler: kvm, vmware, none (fiziksel) ...
systemd-detect-virt
# İşlemci bilgisinde hipervizör satırı ve çekirdek/soket düzeni
lscpu | grep -Ei 'hypervisor|model name|socket|numa'
Disk tarafında gerçek gecikmeyi ölçmek için sentetik bir test kullanın; ağ tarafında ise gerçekten ne kadar bant genişliğine ihtiyacınız olduğunu bant genişliği hesaplayıcı aracımızla hesaplayın. Erişilebilirlik hedeflerinizi somutlaştırmak için de uptime SLA hesaplayıcı işinizi görür; tek fiziksel sunucunun yedeksiz çalıştığında hangi yıllık kesinti süresine karşılık geldiğini görmek, kararı gerçekçi kılar.
Bare Metal'in Gerçekten Gerektiği Senaryolar#
Ölçümleriniz sanallaştırmayı işaret ediyorsa ya da aşağıdaki durumlardan birindeyseniz bare metal makul bir karardır.
Kararlı ve öngörülebilir gecikme gerektiren sistemler. Finansal işlem sistemleri, gerçek zamanlı oyun sunucuları, düşük gecikmeli veri işleme hatları. Burada belirleyici olan ortalama değil, en kötü durumdur ve komşu belirsizliği kabul edilemez.
Yoğun ve sürekli işlemci kullanımı. Video kodlama, derleme çiftlikleri, bilimsel hesaplama, büyük veri işleme. Sanal sunucuların çoğunda uzun süreli tam yük altında kısıtlama uygulanır; sürekli tam yükte çalışacaksanız fiziksel makine hem daha öngörülebilir hem genellikle daha ekonomiktir.
Donanıma doğrudan erişim gerektiren işler. GPU ile eğitim ve çıkarım iş yükleri, özel ağ kartları, doğrudan NVMe erişimi, donanımsal şifreleme modülleri. Ayrıca kendi hipervizörünüzü kurmak istiyorsanız iç içe sanallaştırmaya bağımlı kalmamak için fiziksel makine gerekir.
Çok diskli depolama mimarileri. Birden fazla fiziksel diske doğrudan erişip kendi havuzunuzu kurmak istiyorsanız bunu ancak bare metal üzerinde yapabilirsiniz. Neden önemli olduğunu ZFS nedir ve avantajları yazısında anlattım: donanımsal RAID kartının ya da hipervizörün arkasındaki tek sanal disk, dosya sisteminin bozuk bloğu onarmasını engeller.
Lisanslama ve uyumluluk kısıtları. Bazı yazılımların lisansı fiziksel çekirdek ya da soket sayısına göre hesaplanır; sanal ortamda lisanslama beklenmedik biçimde pahalıya gelebilir. Bazı düzenlemeler de fiziksel yalıtım ya da veri yerleşimi konusunda somut şartlar koyar.
Kendi ağ topolojinizi kurma ihtiyacı. Switch portunuz üzerinde söz sahibi olmak, kendi VLAN'larınızı tanımlamak istiyorsanız sanal sunucu bunu genellikle sunmaz. Konuyu VLAN nedir ve ağ segmentasyonu yazısında ele aldım; kabinet seviyesinde kontrol için colocation nedir yazısına da bakabilirsiniz.
Bare Metal'in Bedeli#
Kararı dengeli vermek için karşı tarafı da açıkça yazmak gerekir. Bare metal'in üç somut maliyeti var.
Esneklik kaybı. Sanal sunucuda birkaç dakikada işlemci ekleyip çıkarabilirsiniz; fiziksel makinede kaynak değişikliği donanım müdahalesi demektir. Yükünüz mevsimsel olarak dalgalanıyorsa sabit kapasiteye para ödersiniz.
Sağlama ve kurtarma süresi. Yeni bir sanal sunucu dakikalar içinde hazırdır. Fiziksel bir sunucunun hazırlanması saatler alır ve bir donanım arızasında yedek parça takılana kadar geçen süre çok daha uzundur. Anlık görüntü alıp saniyeler içinde geri dönme lüksü de yoktur.
Yedeklilik sorumluluğu sizde. Bulut platformları arıza durumunda sanal makineyi başka bir sunucuda yeniden başlatabilir. Bare metal'de böyle bir mekanizma yoktur; yedekliliği siz kurgularsınız. Tek bir fiziksel sunucuya kritik bir servisi yedeksiz koymak, sanal sunucuya koymaktan daha risklidir.
Bu üç maddeyi hesaba katmadan yapılan geçişler genellikle pişmanlıkla sonuçlanır. Performans kazanırsınız ama işletme yükü artar.
Karar Tablosu ve Melez Yaklaşım#
En sağlıklı yaklaşım genellikle "hepsi bare metal" ya da "hepsi bulut" değil, ikisinin karışımıdır.
| Durum | Öneri |
|---|---|
| Steal time sürekli yüzde 10'un üzerinde | Bare metal ya da ayrılmış kaynaklı sunucu |
| Yük gün içinde 5 kat dalgalanıyor | Sanal / bulut, otomatik ölçekleme |
| GPU, özel donanım veya iç içe sanallaştırma | Bare metal |
| Sürekli tam işlemci yükü | Bare metal, genellikle daha ekonomik |
| Yeni ve yükü belirsiz proje | Sanal sunucuyla başla, ölç, sonra karar ver |
| Çok diskli kendi depolama havuzu | Bare metal |
| Katı yedeklilik hedefi, küçük ekip | Yönetilen sanal altyapı |
| Lisans fiziksel çekirdek bazlı | Bare metal, maliyet hesabı yaparak |
Melez desen şöyle kurulur: kararlı ve ağır çekirdek iş yükünü (veritabanı, kodlama, hesaplama) fiziksel makineye alırsınız; dalgalanan ve durumsuz katmanları (web sunucuları, kuyruk işçileri) sanal sunucularda tutup ihtiyaca göre çoğaltırsınız. İki katmanı özel bir ağ üzerinden birleştirmek için bu bölümdeki mesh ve tünel yaklaşımlarını kullanabilirsiniz.
Bir de ara seçenek var: bazı sağlayıcılarda kaynakları paylaşılmayan, çekirdekleri size ayrılmış sanal sunucular bulunur. Bunlar gürültülü komşu problemini büyük ölçüde çözer ama donanıma doğrudan erişim ihtiyacınızı karşılamaz. Sorununuz yalnızca kaynak rekabetiyse, bare metal'e geçmeden önce bu seçeneği değerlendirin.
Sık Yapılan Hatalar ve Tuzaklar#
Ölçmeden geçmek. En pahalı hata budur. Yavaşlığın kaynağı çoğu zaman indekssiz bir sorgu, yanlış yapılandırılmış bir uygulama sunucusu ya da eksik önbellektir. Daha hızlı donanım bunları gizler ama çözmez; birkaç ay sonra aynı duvara daha yüksek maliyetle çarparsınız.
Yedekliliği unutmak. Fiziksel sunucuda "başka bir makinede yeniden başlat" düğmesi yoktur. Geçiş planınızda ikinci bir makine, düzenli yedek ve test edilmiş bir geri dönüş prosedürü olmalıdır.
Kapasiteyi bugüne göre almak. Fiziksel makinede sonradan kaynak eklemek zordur ve genellikle kesinti gerektirir. Alacağınız yapılandırmayı bugünkü değil, on iki ay sonraki tahmini yükünüze göre seçin.
Tek fiziksel diske güvenmek. Bare metal aldıysanız zaten birden fazla diske erişebiliyorsunuz demektir; bu avantajı kullanın. Tek diskli bir fiziksel sunucu, tek diskli bir sanal sunucudan daha güvenli değildir.
İşletme yükünü hafife almak. Çekirdek güncellemesi, donanım izleme, disk sağlığı takibi, güvenlik yamaları artık tamamen sizin sorumluluğunuzdadır. Küçük ekiplerde bu yük, kazanılan performanstan daha maliyetli olabilir.
Ağı ihmal etmek. İşlemci ve diski konuşurken bant genişliği ve hat kalitesi genellikle unutulur. Yoğun veri aktaran bir iş yükünde darboğaz sıklıkla ağdır, işlemci değil.
Sıkça Sorulan Sorular#
Bare metal ile dedicated sunucu aynı şey mi#
Pratikte evet. İkisi de üzerinde hipervizör bulunmayan, donanımın tamamının size ayrıldığı fiziksel sunucuları anlatır. Sektörde bare metal terimi genellikle otomatik sağlanan ve daha esnek faturalandırılan fiziksel sunucular için, dedicated ise klasik aylık kiralama modeli için kullanılır. Teknik olarak beklentiniz aynıdır: hipervizör katmanı yok, donanım paylaşılmıyor, tam erişim var.
Steal time kaç olursa endişelenmeliyim#
Sürekli yüzde 1'in altındaki değerler normaldir ve göz ardı edilebilir. Yüzde 5 civarında yerleşmiş bir değer, işlemci gücünüzün ölçülebilir bir kısmını kaybettiğinizi gösterir ve sağlayıcınızla konuşmanız için yeterli bir gerekçedir. Yüzde 10'un üzerinde süreklilik gösteriyorsa, ödediğiniz kapasitenin belirgin bir bölümünü hiç kullanamıyorsunuz demektir; bu noktada ayrılmış kaynaklı bir sunucuya ya da bare metal'e geçmek nesnel olarak haklıdır.
Bare metal her zaman daha mı hızlı#
Hayır. Aynı nesil donanımda ve düşük yüklü bir hipervizörde, tipik bir web uygulamasının performans farkı ölçüm hatası seviyesinde kalabilir. Fark, kaynak rekabeti olduğunda, gecikme değişkenliği önemli olduğunda ve donanıma doğrudan erişim gerektiğinde ortaya çıkar. Eski nesil bir fiziksel sunucu, yeni nesil bir sanal sunucudan pekâlâ yavaş olabilir; karşılaştırmayı işlemci nesli ve disk tipi üzerinden yapın.
Sanal sunucudan bare metal'e geçiş ne kadar sürer#
Sağlama süresi genellikle saatlerle ölçülür; donanımın hazırlanması, işletim sisteminin kurulması ve ağ yapılandırması zaman alır. Asıl süreyi belirleyen ise veri taşıma ve kesinti planlamasıdır. Küçük bir uygulama için hafta sonu bir bakım penceresi yeterli olabilirken, büyük bir veritabanı için önceden çoğaltma kurup geçişi kısa bir yönlendirme değişikliğine indirmek gerekir. Geçişi planlarken geri dönüş senaryosunu da hazırlayın.
Küçük bir işletme için bare metal mantıklı mı#
Genellikle hayır, en azından başlangıçta değil. Yeni bir projede yük belirsizdir ve sanal sunucunun esnekliği bu belirsizlikte gerçek bir değerdir; ölçüp öğrendikten sonra karar vermek daha akıllıcadır. Bare metal'i düşünmeniz gereken işaretler bellidir: sürekli tam yük, ölçülebilir steal time, donanım erişimi ihtiyacı ya da lisans kısıtı. Bunlardan biri yoksa sanal altyapıda kalmak hem daha ucuz hem daha az bakım gerektirir.
Bare metal üzerinde sanallaştırma kurabilir miyim#
Evet ve bu yaygın bir kullanım biçimidir. Fiziksel sunucuya kendi hipervizörünüzü kurup üzerinde istediğiniz kadar sanal makine çalıştırabilir, kaynak dağılımını tamamen siz belirleyebilirsiniz. Bu yaklaşım, bulutun esnekliğiyle fiziksel makinenin öngörülebilirliğini birleştirir. Karşılığında hipervizör bakımı, yedeklilik ve kapasite planlaması tamamen size geçer; bu yükü üstlenecek bir ekibiniz varsa oldukça verimli bir modeldir.
Kapanış#
Bare metal kararı bir inanç meselesi değil, ölçüm meselesidir. Aklınızda kalması gereken dört alışkanlık şu: geçişten önce steal time, gecikme dağılımı ve disk gecikmesini ölçüp sorunun gerçekten altyapıda olduğunu kanıtlayın; kapasiteyi bugüne değil on iki ay sonrasına göre seçin; fiziksel makinede yedekliliğin tamamen size ait olduğunu planınıza yazın; ve dalgalanan katmanları sanal, kararlı ağır katmanları fiziksel tutan melez bir desen kurmayı en baştan değerlendirin.
İhtiyacınız ölçüldükten sonra netleşiyorsa dedicated sunucu paketlerimiz tam donanım erişimi sunar, GPU gerektiren iş yükleri için GPU VDS tarafına bakabilirsiniz. Yükünüz henüz belirsizse VDS ya da bulut sunucu ile başlayıp ölçmek daha akıllıca olur; kendi donanımınızı barındırmak istiyorsanız colocation seçeneğimiz var. Geçiş planını ve işletme yükünü sizin yerinize üstlenmemizi isterseniz sunucu yönetimi hizmetimiz devreye girer.