Bu Konu Neden Önemli?
Live Migration, çalışan sanal makinelerin hizmeti durdurmadan Hyper-V host'ları arasında taşınmasını sağlar; ağ, kimlik doğrulama ve kapasite tasarımı önemlidir.
Karar Verirken Kontrol Edilecek Noktalar
Live Migration için ayrı ağ planlayın.
Kimlik doğrulama yöntemini topolojiye göre belirleyin.
Hedef host kapasitesini önceden doğrulayın.
Bakım senaryolarında migration süresini test edin.
Mimari ve çalışma modeli
Live Migration çalışan VM’nin bellek ve yürütme durumunu başka ana makineye taşır; backup veya DR kopyası değildir. Host uyumu, kimlik doğrulama, ağ ve storage tasarımı gerekir. Yerel diskli ve paylaşımlı depolama senaryolarının aktarım hacmi farklıdır. Yoğun bellek değişimi son geçişi veya toplam taşıma süresini etkileyebilir.
- 1Host ve erişim uyumu
- 2Bellek/veri aktarımı
- 3Kısa yürütme geçişi
- 4Hedefte uygulama kontrolü
Tasarım parametreleri
- Kaynak uyumluluğu
- CPU özellikleri, VM sürümü ve migration yöntemi desteğini eşleştirin; CPU compatibility her mimari farkı çözmez.
- Bellek kirlenme hızı
- Ağ aktarımı çalışan VM’in bellek değişim hızını karşılamalıdır; yoğun yazma geçişi uzatabilir.
- 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
64 GB RAM’li örnek VM’de taşıma sırasında uygulama yazması ve istemci yanıtı ölçülür. Kaynak ve hedefte kapasite rezervi bırakılır. Yönetim yoluna göre Kerberos veya diğer desteklenen kimlik yönteminin gereksinimi doğrulanır; taşıma sırasında storage işini de izlemeden yalnız ağ hızına bakmayın.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Migration ilerliyor ama tamamlanmıyor | Bellek değişim hızı, ağ veya hedef kapasitesi sınır olabilir. | Migration ağı, hedef RAM ve uygulama yükünü aynı zamanda ölçün. |
| 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
- Başarılı taşıma kaydı yanında istemci işleminin kesintisini ve veri yazmasını doğrulayı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
Bant genişliği ve gerçek aktarım
Hat kapasitesi ile uygulamanın taşıdığı yararlı veri miktarı farklıdır. Protokol başlıkları, şifreleme, yeniden iletim, küçük dosyalar ve disk beklemeleri net hızı azaltır. Bit ile byte birimini karıştırmayın: 1 Gbit/s teorik olarak 125 MB/s seviyesindedir; bu bir uygulama performans garantisi değildir. Aktarım süresini veri miktarı / ölçülen net hız şeklinde hesaplayın. Ölçümü aynı anda ağ, kaynak okuması ve hedef yazması üzerinden yaparak sınırlayıcı bileşeni bulun. Ortalama hız kadar kısa süreli düşüşleri ve diğer işlerin rekabetini de değerlendirin.
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.
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.
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
Uygulama tutarlılığı
Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedekleme ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayı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 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.
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