Hyper-V hakkında en çok bilinmeyenler cont’d

Artk Hyper-V sunucularini pek standalone görmüyoruz. Failover Clustering ile sanal makinelerimizi highly available yapmamiz mümkün oluyor. Yani bir VM i, bir hipervisörde sorun olusursa otomatikman baska bir hipervisörde çalistirabilmek harika bir özellik. Daha ötesi, bir parent partitionda örnegin güncelleme amaçli reboot yapmadan önce sanal makineleri diger hipervisöre canli tasiyabilmek belki daha da kullanisli bir özellik.

Live Migration ama ne Failover Clustering, ne de Hyper-V teknolojisidir. Tamamen kendi koduna sahip bagimsiz bir teknolojidir. Bundan dolayi requirementleri de farkli olabilmektedir. Örnegin Failover Clustering sadece nodelarin donanimlarinin logo test edilmis olmasini ve validation un komple yesil olmasini sistemin desteklenebilirligi için kosul koyarken, Live Migration mesela her ne kadar processor ayari ile esneklik verilse de, processor konusunda nodelar arasi daha fazla benzerligi requirement olarak istemektedir.

https://support.microsoft.com/kb/943984 The Microsoft Support Policy for Windows Server 2008 or Windows Server 2008 R2 Failover Clusters (Söz konusu olan iki nokta disinda baska requirementlar yoktur. Complete solution certification clusterlar için Windows Server 2003 den sonra kaldirilmistir. Ama yinede donanimsal ve yazilimsal nodelarin mümkün oldugunca esit olmalarini öneririz.)

Windows Server 2008 R2 Hyper-V Live Migration white paper: https://download.microsoft.com/download/5/B/D/5BD5C253-4259-428B-A3E4-1F9C3D803074/LiveMigrationWhitepaper_Final.docx

Basitçene Quick Migration ile VM lerin state tini bir node da save edip, baska bir node da restore ederiz; ve Move ile VM leri shutdown edip, baska bir node da boot ederiz. Live Migration sadece manüel bir opsiyondur. Yani otomatik devreye girmez. Bir nodeda herhangi bir nedenden dolayi bir VM i çalistirmamiz artik mümkün degilse, muhtemelen o senaryoda Live Migration da imkansizdir. Live Migration sanal makinenin fiziki bellegindeki sayfalari dirty olarak isaretleyip dondurarak kilitlemeye baslar ve bunlari diger hipervisöre aktarmaya baslar. Grup grup aktarimlardan sonra son aktarima karar verilir ve fiziki disk veya disk üstü veri ersimi de diger node da verildikten sonra ve networksel tasimada sonlandirildiktan sonra sanal makine yeni hipervisörde çalismaya devam eder. Yani bellegi canli klonlanir ve sonra bütün geri kalan kaynaklari sadece devredilir. Bellek aktarimi asla 15 islemi geçmez. Live Migration için Cluster Shared Volume bir requirement degildir, ancak CSV olmasi islemin daha hizli olabilmesini mümkün kilabilir. En nihayetinde CSV ise, storage persistent reservation i bir node dan digerine verirken geçen zamandan kazanmis oluyoruz. Shared Persistent Reservation zaten alinmis oluyor ve klasör seviyesinde erisim yönetiliyor.

SAN controller lar arasi Geographically Dispersed Cluster larda kullanilan host based replication emplementasyonlarinda da Live Migration mümkündür. Ancak LUN un bir site dan diger site a replike olup kullanima serbest birakilmasi da, doanimsal olsa da Live Migration un bir parçasi olur. Kisaca Live Migration performansi düsebilir. Yapilmis olan yatirima ve konfigürasyona göre Live Migration esnasinda sanal makineyi pinglerseniz, bazi pong larin eksik olduklarini görebilmeniz muhtemeldir. Ondan, site lar arasi Live Migration planlaniyorsa sanal makinelerin networksel bakis açisi gözarda edilmemeli.

Geo cluster ve network demisken: çok kisi geo cluster da Windows tarafinda yazilimsal degisikliklerin veya konfigürasyon detaylarin yapilmasi gerektigini düsünmektedir. Bu tamamen yanlistir. Clustering in geo tarafi tamamen donanimsaldir. Kolaycana: Failover Cluster geo olup olmadigini bilmez. Ancak nodelar arasi mesafe artinca network delayler hassas high availability sisteminde sorunlara neden olmaya baslayabilir. Ondan Cluster in network tarafi bu komutlar ile daha tolerant yapilabilir. Bu degerler defaultun degerlerinin iki katlaridir ve ayni zamanda mümkün olan maksimum degerlerdir: cluster /prop SameSubnetDelay=2000, cluster /prop SameSubnetThreshold=10, cluster /prop CrossSubnetDelay=2000,cluster /prop CrossSubnetThreshold=10. Bu heartbeat komutlarin bir nodeda girilmesi yeterlidir ve baska reboot/restart islemleri gerekmemektedir. Diger node lardan her heartbeat için beklenen heartbeat delayi 2 saniyeye ve bu diger node un sorunlu olarak görülmeye baslanmasi anlayisinin ardarda 2 saniye üstünde gelen 10 heartbeat e çikarilmistir. Kisaca 20 saniye boyunca düzgün ritimde heartbeat gelmezse diger node dan süphelenmeye baslariz. Bunun disinda Windows tarafinda spesifik geo cluster a yönelik yapilabilecek baska bir sey mevcut degildir.

Highly available sanal makinelerin backuplanmasi ayri, ama çok önemli bir konu. Burada hersey CSV ile baslamakta; daha dogrusu CSV basina kaç VM çalistirildigi ile. Yani CSV kullaniliyor mu ve her CSV üstünde kaç tane VM/.vhd mevcut? Bütün bu konfigürasyonlara göre backup senaryolari çok degisiyor.

Ilk durum hiç CSV kullanilmamasi ve bir LUN da bir VM olmasi. Burada yaygin herhangi bir backup yöntemini uyarlayabilirsiniz. Bu ayni sekilde passthrough diskden boot eden veya data disk için kullanan VM ler için de geçerlidir; ancak unutmayin, Primary Partitiondan klasik bir sekilde o zaman VM/o diskdeki datayi i backuplayamazsiniz, çünkü o LUN sadece o VM için erisebilir olur.

Elbette o LUN u CSV de yapabilirsiniz, ama o zaman asagidaki durumlara dokunmaya basliyor olabiliriz. Ve elbette passthrough disk ile CSV yapilamaz.

Microsoft önermese de, LUN u CSV yapmadan da kendisi bir den fazla VM barindirabilir. VM ler o zaman LUN ile hareket etmek zorunda kalirlar ve bagimsiz olmazlar. Herneyse, backup açisindan yukaridaki durum yine geçerli olur.

Ikinci durum, yaygin kullanilan bir CSV de birden fazla VM olmasi. Bu senaryoda dikkat edilmesi gereken durumlar olabilir.

Burada ilk durum ile en büyük farki olusturan sonuç ortada bir çeliskinin olmasi. Bir tarafta, disk ayni anda klasör seviyesinde birden fazla sunucuya bagli; ‘’klasör seviyesi’’, yani o diskin root una hiçbir sunucu erisemiyor. Eger bütün node lar ayni anda diske normal baglaniyor olsalardi, muhtemelen diskde corruption olusurdu. Bütün isletim sistemlerin dosya sistemleri, herhangi bir anda, bir diskin tek bir isletim sistemi erisimi için tasarlanmislardir. Ntfs.sys de bu sekilde çalisir ve o LUN da ‘’yalniz’’ çalistigini varsayar. Burada kolaylik için bir SQL analojisi çizebilirsiniz: bir sqldb üzerinde bir sql instance i çalisir ve böylece db integrity korunur. Ayni anda birden fazla sql ayni db üzerinde çalisabiliyor olsaydi, bilgi kirliligi olusmasi muhtemel olurdu.

Yani harf/drive letter limitasyonunu asabilmek için (Hyper-V de SQL gibi harfli path ister) ve LUN basina bir VM limitasyonunu saglikli asabilmek için CSV ye variyoruz. Böylece bir LUNu kullanan resource lari da Failover Cluster da birbirinden bagimsiz nodelar arasi tasiyabiliyoruz. (Ancak bu sadece Hyper-V için desteklenmekte).

Peki bunu nasil yapiyoruz? Küçük bir hile ile J .Mantigini merak ediyorsaniz: ortak LUN da her VM için bir klasör yapiyoruz. Sonra C:\ altina da her node da bir klasör koyuyoruz. Sonra LUN daki klasörleri her node un C:\ in altindaki klasörün altina yeni klasörler olarak mount ediyoruz . Analoji olarak mountpoint düsünebilirsiniz: bir diski baska bir diskin üstündeki klasöre mount etmek. Yalniz CSV de, iki disk üstünde bulunan klasörleri birbirine mount ediyoruz ve bunun üstüne, bir diskdeki klasörleri birkaç baska sunucusunun C:\ root altindaki klasöre mount ediyoruz. Sonuçta örnegin C:\Clusterstorage\Volume1\VM1 ve C:\Clusterstorage\Volume1\VM2 olusuyor. C:\Clusterstorage C: deki ‘’mountpoint umuz’’, Volume ler CSV LUN lar ve VM lerde gerçekten CSV de bulunan VM ler. Windows Server 2008 R2 öncesinde bir diske bir anda sadece bir node tamamen erisebilirken, simdi bütün node lar ayni anda bir diske erisebiliyor ve ama corruption i da önleyebilmek için, isletim sistemlerinin simültane erisimlerini disk seviyesinde degil de, klasör seviyesinde bölüyoruz. Yani bir klasöre/VM e bir anda sadece bir node tamamen erisebiliyor. Hep tamamen diyiyoruz çünkü, eskiden o diskin içerigini de sadece aktif node görebilirken, simdi bütün nodelar da kullanicilarin haklari oldugu süre ayni klasörleri içerini görebilmekteler.

Neden bütün bunlari özetliyoruz? Çünkü yukaridaki güzellikleri yaptiktan sonra, bir çeliski yaratmis oluyoruz ve backup almak bir sorun oluyor. Neden çeliski? Yukaridaki yapida nodelara root seviyesinde yani, diskin kendisine ntfs seviyesinde tamamen erisim vermiyoruz. Eh peki ayni seviyede çalisan volsnap.sys siz VSS nasil diskin backup ini alacak? Yani herkesi drive letter, ‘VM sayisi=LUN sayisi’ ve diskbazinda Cluster failover dan CSV ile kurtardiktan sonra, backup sorununa yakaliyoruz.

Burada da elbette çok güzel bir çözüm mevcut: CSV yi redirected access mode una alabiliyoruz. Yani sadece bir node a LUN un komple erisimini veriyoruz ve bu node root a erisiyor ve bu node VSS islemlerini de düzgün yapabiliyor. O CSV de olan VM leri çalistiran diger node lar da ‘redirected’, yani erisimi olan node üzerinden VMlerine/CSV ye erismeye devam ediyorlar. CSV ye erisimini tamamen almis olan node, diger node lara erisimi network üzerinden SMB/ CIF kullanarak sagliyor.

Ayrica redirection da bir tarz failback imkani olabiliyor. Backup olmasa da, bir node storage baglantisini kaybederse, baska bir node üzerinden storage a erismeye devam edebiliyor. Böylece failover olmuyor ve siz ne zaman isterseniz VM leri istediginiz yere ve istediginiz sekilde canli tasiyabiliyorsunuz. Kisaca tek HBA nizdaki bir devre yandigi için, o node daki bütün VM ler clusterinizda gezmeye baslamiyorlar.

Peki problemler ne olabiliyor?

Backup almada mantiksal hatalar olabiliyor. Örnegin A node unda 1 nolu VM çalisiyor ve B node unda 2 nolu VM çalisiyor. 1 ve 2 nolu VM ler ayni CSV üzerinde. Simdi A node un daki backup client backup i baslatiyor. CSV yi tamamen aliyor, redirection yapiyor, B node unda redirected access basladi diye bir hata mesaji düsüyor (bu normal). B node u 2 nolu VM e, A node u üzerinden network üzerinden erismeye devam ediyor. Simdi A node un da 1 nolu VM i backup liyoruz ve sorun olmuyor. Ne durumda zaman sorun olabiliyor? A node u baska node üzerinde çalisan 2 nolu VM i de backup lamaya çalistiginda veya B node u bu asamada daha basit bir yazilim ile 2 nolu VM i backuplamaya çalistiginda. VSS lokal çalisiyor ve ondan zaten redirected access e girmemiz gerekiyor. Ancak bu senaryoda 2 nolu VM iki node da backup lanabilmek için gerçekten disk seviyesinde lokal çalismiyor, çünkü root a erisip çalisabilen VSS A node unda, ama VSS ile backuplanmak istenilen canli veri, yani VM, B node unda. Yani, VM lerin online olduklari node dan backuplanmalari tavsiye edilir.

Backup almada performans sorunlari olabiliyor. Redirection, diski almis node un storage ve network baglantilarinin trafigini yogunlastirir. Eger 4 node da birer VM bir CSV de çalisiyorsa, backup esnasinda redirection da bütün 4 VM in disk IO su bir node un storage baglantisi üzerinden yapilir ve bu 4 VM den 3ünün bu IO su ayrica o bir node un networküne da yansir. Kisaca, CSV yi alan node ciddi is yükü artisina mahruz kalabilir. Ayrica bu durum diger node larin disk erisimini (redirected) çok yavslatiyor olabilir. Buradan bir çok farkli sorunlar doguyor olabilir. Örnegin 4 node, 4 CSV ve her CSV de 4 VM. Toplam 16 VM ve her node da 4 VM tane çalisiyor olsun. Simdi bir de bunu hayal edin: Her CSV deki VM ler 4 node a esit dagitilmis çalisiyorlar. Yani ilk CSV deki 4 VM i 4 node a dagitiyorsunuz, sonra diger CSV ler deki VM ler ile ayni seyi yapiyorsunuz. Simdide 4 node da ayni anda backup baslatiyorsunuz ve her node bir CSV ye sahipleniyor. Bu yükü kaldirabilecek donanima muhtemelen sahip degilsiniz, yada o cluster daha çok fazla VM çalistirabilmek için tasarlanmis. Bütün cluster in disk IO trafigi direk o cluster in networküne yansiyacak.

Eger backup politikaniz herhangi bir anda, bir node dan, bir csv deki, bir VM i backuplanmasi ise, hiçbir sorun olusmaz. Ancak yüksek VM sayisinda bu yavas olabilir, ama buradan baslamak en mantikli. Eger sorunlar olusmaz ise, parallel backup islemlerini artirabilirsiniz ve farkli schedulingleri emplemente etmeye baslayabilirsiniz.

Performans demisken. Bir CSV de ne kadar çok VM durursa, VM basina LUN maliyeti de o kadar artmaya baslayabilir. Ama LUN sayisi arttikça da maliyet artabilir. Bir VM çalistiracak bir LUN un peformans ihtiyaci, o VM in fiziki olup, o fiziki ortamdaki donanim performans ihtiyaci kadardir. Burada biraz overhead performans kaybi vardir. Passthrough disk de bu yoktur. Yani bir sunucu fiziki ortamda nasil bir diskde iyi performans sergilerse, bu diske sanal ortamda da ihtiyaci olur. Sadece CPU ve Bellek hipervisör tarafindan sanallastirilir. Simdi o LUN üzerinde iki VM çalistirisaniz, o LUN un performansi en kötü durumda sunucu1+sunucu2 ihtiyaçlarini yerine getirebilecek kadar performansli olmalidir. Elbette bu asamda maaliyet ayni görünmektedir: her iki LUN belki iki diskden olusuyordu ve simdi 4 diskden olusan bir LUN var. Burada önemli nokta, IO un çok daha karisik olmus olmasi. Artik o LUN u iki isletim sistemi parallel kullanmaktadir ve belki birden fazla sunucu o LUN a IO yapmaktadir. Yani yeni 4 diskli LUN un performansi, her isletim sisteminin içinden bakildiginda önceki 2 diskli LUN a göre biraz daha kötü olacaktir. VM sayisi arttikça, 2 VM de belli olmayan küçük fark hizlica büyüyemeye baslar ve LUN lara VM orantisindan daha da fazla disk eklemeye basliyor olabilirsiniz. Ayrica yüksek disk sayisindan olusan LUN lari destekleyen controller lar daha pahali olmaya baslarlar. Ondan yüksek VM sayili CSV yapmak daha maaliyetli olabilir. Örnegin yüz VM i yüz LUN a koyabilirsiniz, ama yüz VM i 4 LUN a da koyabilirsiniz. Ikinci çözüm daha pahali olabilir, çünkü 25VM performansini verebilecek LUN lar oldukça maliyetli olabilirler. Ancak 100 LUN destekleyen storage da 4 LUN destekleyen controller dan daha maaliyetli olabilir. Ondan, fiyat disk basina degil burada controller ve performans da önemli. Bu konfigürasyon önceden tartilmali. Arti 25VM i redirect edebilmek ciddi network performansi ve her node da harika storage baglantisi da arz eder. CSV konfigürasyonu Hyper-V cluster da verilecek en önemli karardir.

Ve tekrar performans demisken, yukarida çok önemli bir tiyo var: Sadece CPU ve Bellek hipervisör tarafindan sanallastirilir. Ve bu Parent Partition için de geçerlidir. Yani Hyper-V sunucusunda task manager da gördügünüz CPU ve Bellek degerleri gerçek fiziki kullanimi göstermezler. Bu gerçek kullanimi ancak hipervisörün içinden görebiliriz ve bu da performans monitörün Hyper-V counterlaridir. IO (disk/network) de hipervisör den geçer ama sadece pass eder.

Peki bu hipervisör ne? Örnegin parent partitiondaki user mode ve Kernel mode u herkes bilir. Kabaca isletim sisteminin sanal adres alaninin yarisini user mode a (örnegin .exe yazilimlarimiz) ve yarisni Kernel mode a veririz (örnegin .sys aygit sürücülerimiz). Bu güvenlik ayirimini CPU da da yapariz. CPU larin en azindan 4 çalisma ringleri olur (0-3) ve bunlardan bir ring sadece usermode kod çalistirir ve bir daha düsük ring sadece Kernel kod. En düsük ring de hipervisör kodu çalistirir. BIOS da açtigimiz snallastirma özelligi aslinda tam bu özel CPU ring ini açar. Ondan da parent partition ayirimi vardir. Parent sadece 2 mode da çalisir. Altinda ve aslinda fiziki entegre olan ayri hipervisör kodu bambaska CPU modunda çalisir. Böylece isletim sistemi iki ayrilmis olur ve bu iki mantiksal yapiyi hipervisör ve parent partition diye adlandiririz. Ondan hipervisör kodu CPU yu ‘’gizli’’ kullandigi için (biraz Kernel in kendisini usermode dan gizlemesi gibi), CPU yu daha yukaridaki kodlar için snallastirmamiz gerekir. Ve Kernel nasil usermode için bellek sanallastirmasi yapiyorsa hipervisör bunu yukaridaki kadman için de yapar. Yani hipervisör gerçekten ayridir ve parent partition dememiz çok mantiklidir.

Basar Güner