Bilindiği gibi vMotion, VMware cluster’daki sanal makinelerin çalışır durumdayken ESXi host’lar arasında kesintisiz bir şekilde taşınmasını sağlayan teknolojidir. Burada “kesintisiz” kelimesini kullanıyoruz ama, taşıma sırasında çok ufak da olsa bir ping kaybı yaşanabiliyor. Özellikle, büyük kaynakları olan sanal makinelerin taşınmasında bu durum biraz daha hissedilebilir olabiliyor. vSphere 7 ile birlikte, bu büyük iş yükleri için geliştirmeler yapıldı. Bu yazıda bunları anlatmaya çalışacağım.

Yukarıdaki resimde vMotion teknolojisinin gelişimini görebiliyoruz.

Büyük Sanal Makinelerin vMotion ile Taşınmasındaki Zorluklar

vSphere üzerinde Monster VM’ler olarak da adlandırılan büyük sanal makineleri rahatlıkla barındırabiliyoruz. Sanal makine başına maksimum kaynak olarak 256 vCPU’ya ve 6 TB bellek ayarlanabilir. Bununla birlikte, büyük VM’lerin çalıştığı ortamlarda bu sanal makinelerin canlı olarak taşınması konusunda bir çekince olabiliyor. Bunun nedeni, vMotion işlemi sırasında iş yükü performansı üzerinde potansiyel bir etki ve çok uzun süren geçiş (stun) süresiydi.

Örneğin, çok sayıda I/O yapan veritabanı platformlarında, best practices’lerde belirtilen kaynakların atanmış olmasına rağmen, vMotion ile taşıma sırasında performans düşüşü yaşanabilir. VSphere 7’deki geliştirilmiş vMotion, tüm bu zorlukların üstesinden gelir ve performans veya kullanılabilirlik üzerinde önemli bir etkisi olmadan büyük iş yüklerini canlı olarak taşımamızı sağlar.

Memory Pre-copy Optimizasyonları

vMotion işlemi sırasında, bir VM için değiştirilen tüm bellek sayfalarını izlememiz gerekir. Bu bir canlı geçiş olduğundan, VM içindeki guest işletim sistemi vMotion sırasında belleğe veri yazmaya devam edecektir. Bir vMotion sırasında üzerine yazılan bellek sayfalarını izlememiz ve yeniden göndermemiz gerekir.

vMotion işlemi, sanal makine üzerindeki tüm vCPU’lara bir page tracer (sayfa izleyici) yükler. Böylece, vMotion hangi memory page (bellek sayfası) üzerine yazıldığını bilir. Bu, page tracer işlemi sırasında “page fire” olarak adlandırılır. İzleme işlemi, canlı olarak taşınan sanal makine için tüm vCPU’lara dağıtılır.

Page tracer’ı kurmak ve page fire’ı işlemek için vCPU’lar kısa bir süre için durdurulur. Bu durdurma işlemi mikrosaniyeler seviyesindedir, ancak tüm vCPU’ları durdurmak iş yükünü olumsuz etkileyebilir. Bir sanal makinenin kaynaklarını artırmak, vMotion işleminin etkisini artırır. Page tracer için vCPU’ları durdurduktan sonra, tüm memory Page Table Entries (PTE) (bellek Sayfa Tablosu Girişleri) read only olarak ayarlanır. Translation Lookaside Buffers (TLB) vuruşlarından korunmak ve vMotion sürecinin tam olarak anlaşılması için TLB temizlenir. Bu şekilde, hangi bellek sayfalarının üzerine yazıldığı görülür. Burada açıklanan yönteme “Stop-based Page Trace Install” denir.

vSphere 7’de nasıl çalışıyor

vMotion’ın en büyük etkisi, page trace işlemi için tüm vCPU’ları durdurmak zorunda kalmasıdır. Tüm vCPU’ları durdurmadan Page tracer’ları yükleyebilirsek ne olur? Bu durumu aşmak için vSphere 7 ile birlikte “Loose Page Trace Install” yöntemi kullanılmaya başlandı. Bu şekilde, sayfa izleme yöntemi çoğunlukla aynı kalır, fakat tüm vCPU’ların kullanılması yerine, page tracer işlemini gerçekleştirmek için sadece bir vCPU kullanılır.Diğer tüm vCPU’lar sanal makine için kesintisiz olarak çalışmaya devam ederler.

Page tracer, talep edilen bir vCPU’ya yüklenir ve PTE (Page Table Entries)’leri read only olarak ayarlanır. TLB (Translation Lookaside Buffers), vCPU’ya özgüdür, bu nedenle her vCPU’nun yine TLB’sini temizlemesi gerekir. Bu durum, etkiyi minimuma indirmek için farklı zamanlarda gerçekleşir. Bu yöntem, page tracer için yalnızca bir vCPU kullanıldığından çok daha etkilidir.

Page Table Ayrıntı Düzeyi

VMware, izleme maliyetini düşürdü ama daha da verimli hale getirmek için çalışmalara devam etti. Belleği read only olarak ayarlaa şekli optimize edildi. Bu da, daha az çalışma, daha çok verimlilik anlamına geliyor. vSphere 7’den önce belleğin read only olarak ayarlanma şekli 4KB sayfa ayrıntı düzeyindeydi. Tüm ayrı 4KB sayfalarının salt okunur erişime ayarlanması gerekiyordu.

VSphere 7’den itibaren, Virtual Machine Monitor (VMM) işlemi, read only flag’i 1 GB’lik sayfalarda çok daha büyük bir ayrıntı düzeyinde ayarlanmaya başladı. Bir page fire durumu oluşursa, 1GB PTE (Page Table Entries) 2MB ve 4KB sayfalarına bölünür. VMware mühendisleri, bir sanal makinenin vMotion işlemi sırasında standart olarak tüm belleğine dokunmadığını gördüler. Bir vMotion sırasında işlenen bellek boyutu tipik olarak sadece % 10-30 civarındadır. VMotion süresi boyunca daha fazla bellek kullanılırsa, maliyet verimliliği daha az olacaktır.

Switch-over Geliştirmeleri

Şimdiye kadar anlatılan tüm geliştirmeler, izlemenin gerçekleştiği bellek ön kopyalama aşamasında yapılır. Neredeyse tüm bellek hedef ESXi host’a kopyalandığında, vMotion hedef ESXi ana bilgisayara geçiş yapmaya hazırdır. Bu son aşamada, kaynak ESXi host üzerindeki VM suspend edilir ve denetim noktası verileri hedef ESXi host’a gönderilir. Burada geçiş süresinin (stun time) 1 saniye veya daha az olmasını istenmektedir. Büyük VM’ler için bu, zaman içinde artan iş yükü boyutları nedeniyle bir zorluk haline gelmiştir.

Geçiş aşamasında, kontrol noktası verilerini ve bellek bitmapini göndeririz. Bellek bitmap’i bir VM’nin tüm belleğini izlemek için kullanılır. Hangi sayfaların üzerine yazıldığını bilir ve yine de hedef ESXi host’a iletilmesi gerekir. vMotion son bellek sayfalarını aktarırken, hedef ana bilgisayardaki VM açılmaya başlar. Ancak yine de iletim için kalan son sayfalara ihtiyaç duyabilir. Hedefteki bu sayfaları tanımlamak için, kaynaktan aktarılan bitmap kullanılır. Eğer memory overcommit yapılmışsa, değiştirilen sayfalar isteğe bağlı olarak swap (takas) bitmap’inde izlenir.

Bellek bitmap’i dolu değildir. Son bellek sayfalarını ve VM tarafından kullanılan tüm bellek sayfalarının bilgilerini içerir. 1 GB belleğe sahip bir VM için bellek bitmap’inin boyutu 32 KB’dir. 32KB aktarımı yalnızca milisaniye sürer, bu da sorun değildir.

vSphere 7’de Nasıl Çalışır

6 TB bellek (veya gelecekte daha da fazla) çalıştıran VM’lerde bitmap zaten 192 MB’dir. Geçiş süresinin 1 saniyesinin altında kalmak için, 192 MB’tan fazla gönderim bir saniye veya daha uzun sürebileceğinden, bitmap’in daha küçük olması gerekir. VMware mühendisleri, bitmap’i sıkıştırabilir ve yalnızca gerçekten ihtiyaç duyulan bilgileri gönderebilirsek ne olur diye düşünmüşler.

Bu aşamada, bellek sayfalarının çoğu zaten kopyalandı, bu nedenle yalnızca son kalan bellek sayfalarının gönderilmesi gerekiyor. Sıkıştırılmış bellek bitmap’i kullanan vMotion, büyük VM’ler için milisaniye içinde bitmap’ler göndererek stun time’ı önemli ölçüde azaltır.

Performans Geliştirmeleri

VSphere 7’deki vMotion’daki bu geliştirmeler, bir vMotion sırasında neredeyse hiç performans düşüşü olmadan iş yüklerinin canlı olarak taşınmasına olanak tanır. Aşağıdaki şema, vSphere 7’deki potansiyel performans kazanımlarını gösteren bir sınama örneğidir. Test için kullanılan ortam, bir HammerDB iş yükü çalıştıran büyük bir sanal makinedir (72 vCPU / 512 GB).

Bu test sırasında vSphere 7’de, vSphere 6.7 ile karşılaştırıldığında aşağıdaki üç nokta öne çıkmakta:

• Artık sayfa izleme (page trace) aşamasında performans etkisini yaşanmıyor.
• Stun time, bir saniyenin altında kalıyor.
• Toplam live migration süresi yaklaşık 20 saniye daha kısadır.

Yukarıdaki grafikten de anlaşıldığı üzere, vSphere 7’de vMotion için önemli geliştirmele yapılmış. Tabi bu örnek bir test. Sizin ortamınızda durum biraz farklı olabilir.

Kaynak: https://blogs.vmware.com/vsphere/2020/03/vsphere-7-vmotion-enhancements.html