Bu Konu Neden Önemli?
Sanallaştırma host sizing; toplam vCPU/RAM hesabından ibaret değildir. CPU overcommit, bellek rezervi, storage IOPS, ağ, HA ve N+1 kapasitesi birlikte planlanmalıdır.
Karar Verirken Kontrol Edilecek Noktalar
Peak CPU ve RAM kullanımını gerçek ölçümlerle belirleyin.
HA senaryosunda kaybedilecek host kapasitesini hesaba katın.
Storage latency ve IOPS'u ayrı boyutlandırın.
Büyüme payını ilk günden planlayın.
Mimari ve çalışma modeli
Host sizing VM toplamlarını toplamakla bitmez. Aynı anda çalışan yük, NUMA, hypervisor rezervi, storage ve N-1 durumu hesabı belirler. Atanan RAM ile tüketilen RAM, vCPU ile fiziksel çekirdek farklı metriklerdir. Ballooning veya swap kapasite açığını gizlerken uygulama gecikmesini büyütebilir.
- 1VM iş yükü profili
- 2Host ve NUMA
- 3N-1 yerleşim
- 4Yoğun yük kabulü
Tasarım parametreleri
- Eşzamanlı kaynak ihtiyacı
- Peak RAM, aktif CPU ve depolama işini aynı zaman aralığında ölçün; VM taleplerini körlemesine toplamayın.
- Bakımda yerleşim
- N-1 yükün hostlara gerçekten yerleşmesini bellek, affinity ve destek koşullarıyla sınayın.
- Yoğun saat iş yükü
- CPU, bellek, disk ve ağ ölçümlerini aynı zaman aralığında toplayın. Bir kaynak yüzdesi tek başına sizing kararı verdirmez.
- N-1 kapasitesi
- Bir bileşen kaybedildiğinde kalan kapasiteyi hesaplayın. Normal durumda boş pay görünmesi arızada yeterli kapasite bulunduğunu kanıtlamaz.
- Uyumluluk zinciri
- CPU, firmware, sürücü, hypervisor ve konuk uygulamaların destek koşullarını birlikte inceleyin.
- İşletim rezervi
- Backup, migration, bakım ve büyüme aynı kaynaklarla yarışır. Rezervi yalnız ortalama yük üzerinden belirlemeyin.
Hesap ve uygulama örneği
Üç adet 256 GB hostta bir host kaybından sonra ham bellek 512 GB kalır. Hypervisor ve işletim rezervi düşülmeden 500 GB VM gereksinimini güvenli kabul etmeyin. Failover yerleşimi, bellek garantisi ve yoğun saat CPU/I/O ölçümü aynı testte değerlendirilmelidir.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Toplam kapasite yeterli ama VM taşınamıyor | Tek host RAM’i veya yerleşim şartı sınırlayıcı olabilir. | En büyük VM’in kalan tek hedefe yerleşimini ve rezervleri kontrol edin. |
| Düşük CPU kullanımına rağmen uygulama yavaş | Depolama, kilit, tek çekirdek veya zamanlama beklemesi toplam CPU değerinde görünmeyebilir. | Uygulama gecikmesini çekirdek, disk ve hypervisor beklemeleriyle eşleştirin. |
| Arıza sonrası host aşırı yükleniyor | Kapasite planı normal dağılım için yapılmış, N-1 durumu dışarıda kalmış olabilir. | Kontrollü arıza testinde kalan RAM, CPU ve depolama gecikmesini ölçün. |
| Değişiklikten sonra performans kötüleşti | Sürücü, firmware, NUMA yerleşimi veya kaynak ataması değişmiş olabilir. | Aynı iş yükünde önce/sonra karşılaştırma yapın; bir değişkeni bir seferde değiştirin. |
Kabul ve doğrulama kontrolleri
- Toplam kapasiteyi değil arıza sonrası kullanılabilir kapasiteyi kabul ölçütü yapın.
- Yoğun saat yükünü ve bakım işlerini birlikte temsil eden test çalıştırın.
- Bir host veya bağlantı kaybında hizmet ve veri yazmasını doğrulayın.
- Konuk işletim sistemi ve uygulama desteğini resmî matriste kontrol edin.
- Yeniden başlatma sonrasında aygıt, servis ve depolama sağlığını doğrulayın.
- Kapasite hesabının ham ve kullanılabilir değerlerini ayrı saklayın.
İlgili kavramlar
NUMA yerelliği
NUMA sistemlerde işlemci, kendisine yakın bellekle uzak düğüm belleğine farklı maliyetle erişebilir. Bir sanal makinenin vCPU ve bellek boyutu, fiziksel düğüm kapasitesi ve hypervisor yerleştirmesiyle birlikte değerlendirilir. Daha fazla vCPU vermek her zaman hız kazandırmaz; yerellik kaybı ve zamanlama beklemesi performansı düşürebilir. Fiziksel topolojiyi, VM içindeki görünen topolojiyi ve gerçek iş yükünün bellek davranışını birlikte kaydedin. Değişikliği aynı yük altında önce/sonra karşılaştırın; yalnız CPU yüzdesi yerine uygulama gecikmesini ve uzak bellek etkisini inceleyin.
Kaynak rekabeti
Kaynak rekabeti, birden fazla iş yükünün aynı CPU, bellek, disk veya bağlantıyı paylaşırken birbirini bekletmesidir. Boş görünen toplam kapasite, tek bir sıcak çekirdek veya tek kuyruk üzerindeki darboğazı gizleyebilir. Aynı anda çalışan backup, antivirüs taraması, indeks bakımı ve kullanıcı trafiğini zaman çizelgesinde karşılaştırın. Kaynak eklemeden önce darboğazın yerini doğrulayın. Testte bir işi tek başına ve diğerleriyle birlikte çalıştırarak paylaşılan kaynağın etkisini ayırın; ortalama kullanım kadar yoğun saatlerdeki gecikmeyi de raporlayın.
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
IOPS ve blok boyutu
IOPS saniyedeki I/O işlem sayısını, MB/s ise taşınan veri miktarını anlatır. Aynı IOPS sayısı farklı blok boyutlarında çok farklı bant genişliği üretir. Örneğin 10.000 işlem/s × 4 KiB yaklaşık 39,1 MiB/s eder. Okuma/yazma oranı, rastgele veya sıralı erişim ve veri koruma mekanizması sonucu değiştirir. Bir benchmark sonucunu üretim uygulamasına doğrudan taşımak yerine gerçek blok dağılımını ve eşzamanlılığı ölçün. Diskin yüksek IOPS göstermesi, uygulama yanıtının iyi olduğu anlamına gelmez; gecikme de birlikte incelenmelidir.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Failover ve failback
Failover, hizmetin başka bir bileşene geçmesidir; failback, tercih edilen konuma geri alınmasıdır. İkisi aynı risk ve işlem sırasına sahip olmayabilir. DNS güncellemesi, yönlendirme, oturumlar, veri geriliği ve uygulama bağımlılıkları kullanıcı kesintisini belirler. Otomatik geçişin hangi koşulda tetiklendiğini, yanlış alarmda ne olacağını ve geri dönüş onayını tanımlayın. Arızayı yalnız sanal makineyi kapatarak test etmek tüm hata türlerini kapsamaz. Ağ, depolama ve yönetim katmanı arızalarının ayrı etkilerini ölçün.
Birincil teknik dokümantasyon
Bu İçerik Nasıl Hazırlandı?
Doz Teknoloji Teknik Ekibi
İçerik, Doz Teknoloji’nin kurumsal BT hizmet alanlarında kullandığı teknik değerlendirme yaklaşımı temel alınarak hazırlanmıştır.
Teknik kriterler + birincil kaynaklar
Konu; üretici dokümantasyonu, standart kuruluşları ve ilgili resmî teknik kaynaklarla çapraz kontrol edilmiştir.
Karar kalitesini artırmak
Amaç, teknik bir terimi yalnız tanımlamak değil; satın alma, tasarım veya işletim kararı verirken hangi kriterlerin birlikte değerlendirilmesi gerektiğini görünür hale getirmektir.
İlgili Hizmet ve Rehberler
Bu Rehberle İlgili Kurumsal Çözümler
Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.
Teknik İhtiyacınızı Birlikte Değerlendirelim
Mevcut altyapınızı, kullanıcı sayınızı veya teknik hedefinizi paylaşın; ürün, lisans veya proje kapsamını ihtiyaca göre netleştirelim.
Teknik Talep Oluşturun