Merhabalar,
Bu makalede, sistem altyapıları için olmazsa olmaz özelliklerden biri olan vMotion işleminin ne olduğu ve hangi aşamalardan oluştuğunu teknik detaylarıyla paylaşmayı düşündüm. Birçok sistemci, bu özelliği kullanmakta ve aslında arka planında neler olduğunu çok da düşünmemekte. Açıkçası işlerin yoğunluğu dolayısıyla, zaten her yaptığımız işin, arka planında neler oluyor diye de düşünmüyoruz değil mi normal olarak? 🙂 İşte bu makalede, çokça kullandığımız bu işlem sırasında neler olduğunu anlatmaya çalışacağım.
vSphere vMotion teknolojisi, sanal sunucuların, çalışır durumdayken kesintisiz şekilde, başka bir ESXi sunucu üzerine taşınmasını sağlayan teknolojidir.
Böylece :
- Genel donanım kullanımını iyileştirir
- Programlı şekilde donanımların kapalı kalma sürelerini karşılarken sanal makinelerin sürekli olarak çalışmasına imkan sağlar
- VMware vSphere® Distributed Resource Scheduler™ ile sanal sunucular ESXi sunucular arasında taşınarak yük dengelemesi yapılır
vSphere 7 sürümünde vMotion özelliğinin, büyük ölçüde geliştirildiğini ve ne gibi yenilikler olduğunu, daha önceki makalemde yayınlamıştım. İlgili makaleye aşağıdaki linkten ulaşabilirsiniz.
Yıllara göre vSphere vMotion teknolojisinin gelişimini de aşağıdaki şekilde görebilirsiniz.
Ayrıca 2 tip vMotion olduğunu da ekleyeyim.
- vMotion : Bu makalede anlatılan, ESXi sunucular arasında sanal sunucuları canlı olarak taşıma teknolojisi.
- Storage vMotion : Sanal makine dosyalarının, başka bir LUN/Datastore üzerine canlı şekilde taşınması işlemi.
Migration işlemi sırasında aşağıdaki seçenekler ile kolayca istenen işlem gerçekleştirilebilmektedir. İstersek sadece Change Compute Resource only ile vMotion yani sadece ESXi sunucu değiştirebilir, istersek Change Storage only seçeneği ile sadece Storage vMotion yani datastore değişimi, istersek de her ikisini aynı anda yapmayı seçebiliriz. Bu kadar kolay…
Elbette ki bu işlemin yapılabilmesi için, kaynak ve hedef ESXi sunucuların, ortak paylaşımlı bir alandaki sanal sunucuya erişebilir olması gerekmektedir.
Peki bu kadar kolay bir işlemin arka planında neler oluyor acaba? Şimdi vMotion işleminin detaylarını incelemeye başlayalım.
vMotion işlemi
Bir sanal makine için vMotion işlemi başlatıldığında, ilk adım olarak bir uyumluluk kontrolü yapılır. Sanal makinenin, hedef ESXi sunucuda çalıştırılmasının mümkün olup olmayacağı kontrol edilir. Çünkü bu canlı geçişi önleyebilecek birtakım kısıtlamalar olabilir.
Sonraki adım ise, kaynak ve hedef ESXi sunuculara, aralarında ne gibi bir işlemin gerçekleştiğinin anlatılması adımıdır.
Bunun için aşağıdaki bilgileri içeren bir kontrol seti oluşturulur:
- Canlı olarak taşınan sanal makine
- Sanal makine konfigürasyonu (virtual hardware, VM options vs)
- Kaynak ESXi sunucu
- Hedef ESXi sunucu
- vMotion network detayları
vCenter sunucu tarafından, geçiş işlemini başlatmak ve işlemin başarılı olmasını sağlamayı garanti altına almak amacıyla, bu kontrol setinde bulunan tüm bilgiler kaynak ve hedef ESXi sunucular arasında paylaşılır.
vCenter Sunucusu, ESXi sunucuları üzerinde çalışmakta olan Virtual Provisioning X Agent (VPXA) ve Virtual Provisioning X Daemon (VPXD) vasıtasıyla bu ESXi sunucularıyla iletişim kurar. VPXA, VPXD’den gelen bildirimleri dinler, geçiş spesifikasyonunu alır ve bunu hostd aracılığıyla VMX sürecine aktarır. Host Daemon (hostd), VMstate gibi sanal makine telemetrisi dahil olmak üzere ESXi sunuculara özgü bilgileri alarak yönetim sağlar. Taşıma başlatıldığında, hostd sanal makineyi ara duruma getirir, böylece sanal makine taşıma sırasında, var olan yapılandırması değiştirilemez.
Sanal Makine İzleyicisi (VMM) işlemi, sanal makine belleğini yönetmekten sorumludur ve sanal makinenin, depolama ve ağ G / Ç isteklerini VMkernel’e aktarır. Performans açısından kritik olmayan diğer tüm G / Ç istekleri, VMM tarafından VMX’e iletilir.
Sanal Makine Uzantısı (VMX) işlemi, VMkernel’de çalışır ve performans için kritik olmayan cihazlarda G / Ç işlemlerinden sorumludur.
VMM’nin taşıma sırasında yalnızca kaynak ESXi sunucularda kullanıldığını unutmayın, çünkü sanal makinenin etkin belleği burada bulunur.
Bu yapıldıktan sonra, kaynak ESXi sunucu üzerindeki VMkernel taşıma modülü, hedef ESXi sunucuyla iletişim kurmak için vMotion etkinleştirilen ağdaki soketleri açar.
Pre-Copy aşamasına hazırlık
Artık tüm işlemler ve iletişim yolları, canlı geçişin başlaması için hazırdır. Hazırlama aşaması, hedef ESXi sunucunun, taşınacak sanal makine için compute kaynaklarını önceden ayırmasını sağlamakla ilgilidir. Ayrıca bu aşamada, ilgili sanal makine hedef ESXi sunucu üzerinde oluşturulur, ancak maskelenir. Sanal makine konfigürasyonuyla ilgili tüm bilgiler, geçiş özelliğine dahil olduğu için zaten bilinir durumdadır.
Hazırlama aşaması tamamlandığında, belleğin kaynaktan hedef ESXi sunucusuna aktarıldığı pre-copy aşamasına geçilir. Kaynak ESXi sunucu üzerinde, tüm sanal makine bellek sayfalarının izlenmesi gerekir. Böylece vMotion işlemi, taşıma sırasında hangi bellek sayfalarının üzerine yazıldığını bilir ve bu sayfaları dirty pages olarak adlandırır, çünkü bu bellek sayfalarını hedef ESXi sunucuya yeniden göndermesi gerekir.
Page Tracing
Pre-Copy (Kopyalama öncesi) aşamada, sanal makine tarafından kullanılan vCPU’lar sayfa izleyicileri yüklemek için çok kısa bir süre duraklatılır. VMkernel geçiş modülü, artık VMM’nin sanal makinenin memory page table (bellek sayfası tablosu) durumuna sahip olduğundan, sayfa izlemenin başlatılmasını ister. Aşağıdaki şema, guest işletim sisteminin, bir vMotion işlemi sırasında belleğe veri yazarken ne olacağını göstermektedir:
Memory Pre-Copy
Sayfa izleme, sürekli bir döngüdür. Birden çok yineleme kullanarak bellek ön kopya işlemi devam edecektir.
- İlk yineleme (precopy phase-1), sanal makine belleğini kopyalar.
- Sonraki yineleme (precopy fazı 0 ila n) dirty page bellek sayfalarının kopyalanması yapılır.
n sayıda demek şu anlama gelir: memory’de kaç defa durum değişikliği olduğudur.
Bir örnek vermek gerekirse şöyle açıklayalım:
24 GB belleğe sahip bir sanal makineyi canlı olarak taşırken yinelemelerin şöyle göründüğünü düşünelim:
Phase -1 : 24 GB sanal makine belleği ve izleme sayfaları kopyalanır. Belleği gönderirken, 8 GB dirty page oluşursa aşağıdaki gibi devam eder.
Phase 0 : Dirty 8 GB tekrar iletilir. Bu aşamada, bellek başka bir 3 GB dirty halde tutarsa aşağıdaki gibi devam eder.
Phase 1 : Dirty 3 GB tekrar gönderilir. Bu aşamada, bellek başka bir 1 GB dirty halde tutarsa aşağıdaki gibi devam eder.
Phase 2 : Geri kalan 1 GB dirty de gönderilir.
Bellek sayfaları kaynaktan hedef ESXi sunucuya kopyalandığından, tüm belleğin hedefine ne zaman kopyalanacağını belirlememiz gerekir. VMM, VMkernel’e, her yinelemeden sonra ön kopyalama işleminin sonlandırılıp sonlandırılamayacağını sorar. Bu yalnızca, tüm bellek değişiklikleri (kirli sayfalar) hedef ana bilgisayara kopyalandığında mümkündür. Yinelemeli bellek ön kopyalama algoritmasının bir aşaması da, tüm hedef bellek sayfalarını, kaynaktaki ile uygun hale getirmektir.
Maksimum veya son bellek sayfa numarasına kadar sıfırdan başlayarak, tüm bellek sayfaları, hedef sayfaların kaynak sayfalarla senkronize olup olmadığını görmek için sırayla kontrol edilir.
Ön kopyalamayı sonlandırıp sonlandıramayacağımızı belirlemek için, son bellek sayfasının kopyasını <500 ms’lik zamanda tamamlayıp tamamlayamayacağımızı doğrulamamız gerekir. Aşağıdaki bilgiler analiz edilerek hesaplamalar yapılır:
- Migration iletim hızı: hangi hızda (GbE) ESXi suncular arasındaki bellek verilerini kopyalıyoruz?
- Dirty sayfa oranı (GB / s): Guest işletim sistemi tarafından kaç bellek sayfası üzerine yazılıyor?
- Hedef ESXi sunucuya iletmek için kaç sayfa kaldı?
Kirli sayfa oranı, Migration iletim hızından yüksekse ne olur? Durum böyleyse, başka bir yineleme yapmanın bir anlamı yoktur, çünkü bellek ön kopya yakınsamasına asla ulaşamayız ve taşıma durur. Bu nedenle, vSphere 5.0 ile birlikte Stun During Page Send (SDPS-Sayfa Gönderme Sırasında Sersemletme) teknolojisi tanıtılmıştı. Temel olarak SDPS, VMkernel için VMM’ye programlanmış talimatları çalıştırmamasını değil, gerçekten kısa bir ‘uyku hali’ eklemesini söylemenin bir yoludur. Bu, iş yükü performansı üzerinde bir etki gibi görünebilir, ancak çok hassas bir düzeyde gerçekleşir. Mikrosaniyeler seviyelerinden bahsetmekteyiz. Bununla ilgili yenilikleri ve uyarlamaları, makalemin başında verdiğim linkte detaylıca açıklamıştım. Bu makaleyi de kontrol edebilirsiniz.
Kirli sayfa hızı> gönderme hızı olduğu sürece, her bir yinelemeyle SDPS işlemi de yürütülür. Bu şu anlama geliyor: memory’de ne kadar değişiklik yapılırsa, her bir değişiklik için SDPS de işletilir. Böylece SDPS ile, sonraki yinelemelerde daha az dirty page’ler oluşması için ortam sağlanır.
SDPS, o iş yükü tarafından fark edilmez. Zaten buradaki amaç da, Guest işletim sistemini, vMotion işleminden hiçbir zaman haberdar olmayacağı şekilde tutmaktır.
Switchover
VMM tarafından bellek ön kopya geçişi sonlandırıldığında, tüm bellek sayfaları hedef ESXi sunucu üzerine atılmış durumdadır. VMM artık VMX’e, kaynak sanal makineyi askıya alabileceği bir uzaktan yordam çağrısı (RPC) gönderebilir. VMX, sanal makineyi askıya aldığı ve kontrol noktası verilerini hedef ESXi sunucuya gönderdiği, kontrol noktası aşamasına girecektir.
İşlem sırasında, hedef ESXi sunucudaki sanal makinenin maskeleri kaldırılacak ve sanal makinenin durumu, denetim noktası verileri kullanılarak geri yüklenecektir. Temelde yapılan işlem, hedef ESXi sunucu üzerindeki sanal makinenin power-on edilmesidir, tabi ki bu aşamada boot işlemi yarıda kesilir ve kaynak ESXi ana bilgisayarından geçirilen bellek sayfalarına bu sanal makine yönlendirilir. Bütün bunlar normalde 100-200 ms’lik bir zaman diliminde gerçekleşir.
Bütün bu işlemler sırasında, sanal makine üzerinde sadece 1 ping kaybı olur. Bunun nedenini, bu yazıyı okuyan sizlere ödev olarak veriyorum. 1 ping kaybının anlamı nedir? 🙂
Genel olarak bir vMotion işlemi sırasında bu aşamalar gerçekleşir. vSphere 7 üzerinde bu teknolojideki değişimleri ve geliştirmeleri de daha önce yayınladığım ve yazımın başında verdiğim linkteki makalemde bulabilirsiniz.
Yararlı olması dileğiyle.
Yusuf İşleyen