Merhabalar,
Bildiğiniz gibi vSphere vMotion teknolojisi, sanal sunucuların, çalışır durumdayken kesintisiz şekilde başka bir ESXi sunucu üzerine taşınmasını sağlayan teknolojidir. vSphere 7 sürümünde vMotion özelliği, büyük ölçüde geliştirildi. Bu geliştirmeler ile, hem canlı geçişler sırasında performansa negatif etkileri düşürülmüş hem de sanal makinenin, geçiş/switch-over süreleri iyileştirilmiştir.(Stun time) Özellikle büyük kaynaklara sahip iş yükleri üzerinde ciddi gelişmeler mevcut.
Daha önce incelemediyseniz, aşağıdaki linkten, vSphere 7 için yeni özelliklere ilk bakış makalesini inceleyerek de ön bilgi edinebilirsiniz.
Yıllara göre vSphere vMotion teknolojisinin gelişimini de aşağıdaki şekilde görebilirsiniz.
Büyük VM vMotion Zorlukları
vSphere, çok yüksek kaynaklara sahip sanal makinelerin de kurulabilmesine izin veren mükemmel bir platform. Ancak, büyük kaynaklara sahip sanal sunucu çalıştıran kuruluşlar, bu sanal makineleri canlı olarak taşımaktan bazen çekinmekteler ve özellikle mesai dışı saatlerde bu işlemi yapmak istemekteler. Bunun nedeni, vMotion işlemi sırasında iş yükü performansı üzerinde potansiyel bir etki ve çok uzun süren geçiş süresinden kaynaklanmaktadır.
Örneğin, çok sayıda G / Ç ile ilgilenen büyük ve yoğun işlemsel veritabanı platformları, kesin etkisi büyük ölçüde iş yükünün özelliklerine ve boyutlandırmasına bağlı olmasına rağmen, bir vMotion işlemi sırasında performans düşüşü yaşayabilir. vSphere 7’deki vMotion için geliştirilmiş mantık, 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 işlem canlı bir geçiş işlemi olduğundan, VM içinde koşmakta olan Guest işletim sistemi, vMotion sırasında belleğe veri yazmaya devam edecektir. Dolayısıyla vMotion sırasında, üzerine yazılan bellek sayfalarını izlememiz ve yeniden göndermemiz gerekir.
vMotion işlemi, VM için yapılandırılmış tüm vCPU’lara bir page tracer (sayfa izleyici) yükler. Bunu yaparak, vMotion hangi memory page (bellek sayfalarının) üzerine veri yazıldığını anlar. Bu olay, sayfa izleme işlemi sırasında “page fire” olarak adlandırılır. İzleme çalışması, canlı olarak taşınan sanal sunucu için tüm vCPU’lara dağıtılır.
Page tracer kurmak ve Page Fire işlemini başlatmak için, vCPU’lar kısa bir süre için durdurulur. Bu işlem yalnızca mikrosaniye mertebesinde gerçekleşir, ancak tüm vCPU’ları durdurmak da iş yükünü bozar. Bir VM’nin kaynaklarını artırmak, vMotion işleminin etkisini de artırır. İzleme işlemi için vCPU’ları durdurduktan sonra, tüm bellek Page Table Entries (PTE-Sayfa Tablosu Girişleri) salt okunur olarak ayarlanır. Translation Lookaside Buffers (TLB) vuruşlarından kaçınmak ve page table yürütmeye zorlamak için Translation Lookaside Buffers (TLB) temizlenir. Böylece vMotion işlemi, hangi bellek sayfalarının üzerine yazıldığından da haberdar olur. Bu yönteme, “Stop-based Page Trace Install“ (Dur Tabanlı Sayfa İzleme Yüklemesi) denir.
vSphere 7 de ise şöyle yapılır…
En büyük etki, sayfa izleme için tüm vCPU’ların durdurulmak zorunda kalınması olduğunu yukarıda açıkladım. Peki ya sayfa izleyicileri, tüm vCPU’ları durdurmaya gerek kalmadan yükleyebilirsek ne olur? İşte vSphere 7 ile “Loose Page Trace Install” yöntemi sunulmaya başlanmıştır.
Sayfa izleme yöntemi çoğunlukla aynı kalır, ancak tüm vCPU’ları kullanmak yerine, şimdi tüm izleme işlemini gerçekleştirmek için yalnızca 1 vCPU için talepte bulunulur. Diğer tüm vCPU’lar, iş yükünü kesintisiz olarak çalıştırmaya devam eder.
Sayfa izleyici, talep edilen 1 vCPU’ya yüklenecek ve tüm PTE’leri salt okunur olarak ayarlayacaktır. TLB vCPU’ya özgüdür, bu nedenle her vCPU’nun, TLB’sini yine temizlemesi gerekir. Ancak bu, etkiyi en aza indirmek için farklı zamanlarda olur. Genel olarak bu yöntem, sayfa izleme için yalnızca 1 vCPU kullanıldığından çok daha etkilidir.
Page Table Ayrıntı Düzeyi
İzleme maliyeti düşmüş oldu, ama daha da verimli hale getirebilirsek nasıl olur? Belleği salt okunur olarak ayarlama şeklimizi optimize ettik, dolayısıyla bu kısımda artık daha az işimiz var. Daha az çalışma, daha fazla verimlilik anlamına gelir. vSphere 7’den önce, belleğin salt okunur olarak ayarlanma şekli 4KB sayfa ayrıntı düzeyindedir. Her bir 4KB sayfalarının salt okunur erişime ayarlanması gerekiyordu.
vSphere 7’den itibaren, Sanal Makine Monitörü (VMM) işlemi, read-only flag’i 1 GB’lık sayfalarda ve çok daha büyük bir ayrıntı düzeyinde ayarlayacaktır. Bir page fire oluşursa (bellek sayfasının üzerine yazılır), 1GB PTE, 2MB ve 4KB sayfalarına bölünür. VMware mühendisleri, bir VM’nin bir vMotion işlemi sırasında tipik olarak tüm belleğine dokunmadığını gördüler. Bir vMotion işlemi sırasında işlenen bellek boyutu tipik olarak sadece % 10-30 arasında bir değerdir. vMotion süresi boyunca daha fazla bellek kullanılırsa, maliyet verimliliği daha az olacaktır.
Switch-over/Geçiş Fazı Geliştirmeleri
Şimdiye kadar açıkladığımız tüm bu geliştirmeler, izlemenin gerçekleştiği bellek ön kopyalama aşamasında yapılır.(memory pre-copy phase) Neredeyse tüm bellek hedef ESXi sunucuya kopyalandığında vMotion, hedef ESXi sunucuya geçmeye hazır durumda olur. Bu son aşamada, kaynak ESXi sunucudaki VM askıya alınır ve denetim noktası verileri hedef ESXi sunucuya gönderilir. Geçiş süresinin (stun time) 1 saniye veya daha az olmasını istediğimizi unutmayın. 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. Bitmap, hangi sayfaların üzerine yazıldığını ve yine de hedef ESXi ana bilgisayarına iletilmesi gerektiğini bilir. vMotion son bellek sayfalarını aktarırken, hedef ESXi sunucudaki 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’i kullanırız. Eğer kullanıcılar hafızayı aşarsa (memory overcommit), değiştirilen sayfalar isteğe bağlı bir swap bitmap’inde izlenir.
Bellek bitmap’i her zaman full 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’in boyutu 32 KB’dir ve 32KB aktarımı yalnızca milisaniye sürer.
vSphere 7 şöyle yapar:
Örneğin 6 TB bellek (veya gelecekte daha da fazla) çalıştıran VM’lerde bitmap 192 MB’dir. Geçiş süresinin 1 saniyesinin altında kalması için, 192 MB’tan fazla gönderim bir saniye veya daha uzun sürebileceğinden, bitmap’in daha küçük olması gerekir. Peki ya bitmap’i sıkıştırabilir ve yalnızca gerçekten ihtiyacımız olan bilgileri gönderebilirsek ne olur?
Bu aşamada, bellek sayfalarının çoğunu zaten kopyaladık, 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 süreleri içinde bu bitmap’leri göndererek geçiş süresini önemli ölçüde azaltır.
Performans geliştirmeleri
vSphere 7 vMotion’daki bu geliştirmeler, bir vMotion işlemi 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 testin örneğidir. Test yatağı, bir HammerDB iş yükü çalıştıran büyük bir VM’dir (72 vCPU / 512 GB).
vSphere 7’deki bu test sırasında, vSphere 6.7 ile karşılaştırıldığında fark edilen birkaç önemli madde:
- Artık sayfa izleme aşamasında, performans etkisini yaşamıyoruz.
- Geçiş süresi birden fazla saniye almak yerine 1 saniye içinde kalır.
- Toplam canlı göç süresi yaklaşık 20 saniye daha kısadır.
Bu değerler, vMotion ağ yapılandırmalarına ve VM boyutlarına bağlı olarak değişebilir, ancak bu vMotion iyileştirmelerinin potansiyel faydalarını göstermek için örnek kabul edilebilir.
Gördüğünüz gibi vSphere 7 versiyonunda, vMotion kullanımı daha da keyifli olacak gibi görünüyor. 🙂
Yararlı olması dileğiyle.
Yusuf İşleyen