Teknik Rehber · Sunucu ve Sanallaştırma
VM CPU Uyumluluğu: Live Migration için Ortak Özellik Kümesi
Bir VM’nin vCPU modeli konuk işletim sistemine görünen komut kümesini belirler. Kaynak host üzerinde bulunan AVX veya başka bir özellik hedefte yoksa çalışan VM’nin taşınması başarısız…
Teknik gözden geçirme:
Mimari ve çalışma modeli
Bir VM’nin vCPU modeli konuk işletim sistemine görünen komut kümesini belirler. Kaynak host üzerinde bulunan AVX veya başka bir özellik hedefte yoksa çalışan VM’nin taşınması başarısız olabilir. Aynı üretici veya aynı çekirdek sayısı uyumluluk kanıtı değildir.
Host-passthrough konukta kaynak CPU’ya çok yakın özellikler sunar; heterojen hostlar arasında taşınabilirliği sınırlar. Ortak model kullanılacaksa BIOS/mikrokod, QEMU ve libvirt sürümleriyle birlikte test edin. Bazı özelliklerin kapatılması uygulama performansını veya güvenlik kabiliyetini etkileyebilir.
CPU modeli değişikliğini çalışan VM’de basit XML düzenlemesiyle etkinleşmiş saymayın. Konuk yeniden başlatması ve yönetim platformunun desteklediği geçiş yöntemi gerekebilir. Hostların tamamında iki yönlü migration ve geri dönüş pilotu yapın.
- 1Host özellikleri
- 2Ortak CPU modeli
- 3Konuk özellikleri
- 4Hedef uyumluluk testi
Tasarım parametreleri
- Taban model
- En eski desteklenen hostun özelliklerini yeni hostlara gereksiz sınır koymadan ortak kümede değerlendirin.
- Sürüm matrisi
- CPU, firmware, mikrokod, hypervisor ve konuk sürümünü tek matriste saklayın.
- İş yükü ölçümü
- Ortak modelin şifreleme ve vektör işlem kullanan uygulamalara etkisini ölçün.
Hesap ve uygulama örneği
Üç hosttan ikisi AVX2 destekli, biri desteklemiyorsa AVX2 kullanan VM’yi üçüncüye canlı taşımayın. Ayrı migration havuzu veya ortak model seçin. Bir uygulama testinde işlem süresi 8 saniyeden 10 saniyeye çıkıyorsa model tercihi yüzde 25 süre artışı getirir; bunu kapasite hesabına yansıtın.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
virsh capabilities
virsh domcapabilities
virsh dumpxml lab-vm
# Compare host CPU descriptions with the commands supported by your libvirt release.Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| CPU incompatible | Konukta hedefin sunmadığı özellik var. | Domain XML ve iki host capability çıktısını karşılaştırın. |
| Migration sonrası uygulama yavaş | Model/NUMA/mikrokod farklılığı. | Aynı veri ve yükte gecikme/CPU sayaçlarını karşılaştırın. |
Kabul ve doğrulama kontrolleri
- Tüm host capability çıktılarını saklayın.
- İki yönlü migration yapın.
- Konuk komut kümesini kontrol edin.
- Yeniden başlatma ihtiyacını planlayın.
- İş yükü performansını karşılaştırın.
- Geri dönüş havuzunu doğrulayı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.
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 backup 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.
Bağımlılık ve geri açılış sırası
Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Geri açılış sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayın.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.