Sanallaştırmada Hyper-V Tercihi İçin 6 Önemli Neden

Son zamanlarda VMware blog’larında, global news’larda ve forumlarda Hyper-V hakkında söylenti/efsane içeriklere oldukça sık rastlamaya başladık. Bu postlarda ve karşılaştırma tablolarında dikkati çeken nokta ise VMware’ın kendi ürünlerini Microsoft sanallaştırma çözümleriyle kıyaslarken eksik ya da hatalı bilgiler veriyor olması. Global ortamda bu söylentilere gerekli yanıtlar verildi. Bu post ile ben de konuyu Türkçe olarak ele almak istedim. Bu yazıda VMware tarafından Hyper-V için söylenmiş ve gerçek olmayan bazı konuları ve bu konuların doğrularını bulacaksınız.

1. Güvenlik ve Disk Footprint

Vmware, Hyper-V disk footprint’e takmış durumda. Disk footprint’i bir yazılımın depolama sistemi üzerinde kapladığı alan yani bir nevi total code base (toplam kod miktarı) olarak düşünebilirsiniz. VMware der ki Hyper-V Windows Server 2008 işletim sistemiyle çalıştığını için disk footprint’i büyüktür (Server Core + Hyper-V = 2.6GB) ve bu değer ESXi disk footpirnt’ten (32MB) 80 kat daha büyüktür. Bu nedenle 2.6GB’lık disk footprint atak yapılabilecek yüzeyi teorik olarak artırmakta, stability için sorun teşkil etmekte, önemli güvenlik riskleri oluşturmakta ve performance overhead yaratmaktadır.

VMware her fırsatta bu konunun altını çiziyor ve Hyper-V’yi güvensiz ilan ediyor ancak bir sistemin güvenli olup olmadığını sadece disk footprint’e bağlamak çok doğru bir yaklaşım değil. Güvenlik çok yönlü bir kavramdır ve birçok farklı noktadan ele alınması gerekir. ESX’in daha düşük disk footprint’e sahip olduğu doğru (ki boyutları yukarıda görebiliyorsunuz). Peki 80kat daha düşük footpirnt ile çalışan ESX üzerinde ortaya çıkan kritik güvenlik açıklarından haberiniz var mı? ESX 3.5 için yakın zamana kadar toplamda 168 adet güncelleştirme geçildi ve bu güncelleştirmelerin toplamı yaklaşık 3GB. Windows Server 2008 Core ile çalışan Hyper-V için ise son 18 ayda geçilen güncelleştirme sayısı sadece 19 ve toplam boyut 80MB. Peki 32MB’lık bir sisteme 168 adet (3GB) patch geçilmesi sizce normal mi? Bir anda ESX disk footprint 96 katına çıkmış oldu. Devam edelim…

VMware’in Ağustos 2008’de yayınladığı Update2 güncelleştirmesi içinde unuttuğu bir timebomb bug’ı yüzünden VM’ler geçici süreyle start edilemedi ve çalışır durumdaki VM’ler için vMotion kullanılamadı. Bu sorun yüzünden VMware CEO’su Pual Maritz official blog üzerinden tüm müşterilerden özür diledi. Aşağıda ilgili özür yazısını ve konunun ayrıntılarını bulabilirsiniz.

• http://blogs.vmware.com/console/2008/08/index.html

Bu olanlardan sonra Kasım 2009’da vSphare (ESX4) için yayınlanan 800MB büyüklüğündeki Update1 güncellemesi özellikle HP Insight Manager yüklü olan sunucularda sistemi kullanılmaz hale getirdi. Bu olay üzerine güncelleme geri çekildi ve Aralık ayı içinde düzeltilip yeniden yayınlandı. Aşağıda bu konunun detaylarını bulabilirsiniz.

• http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1016070

Vmware üzerindeki bir başka önemli güvenlik sorunu ise Nisan 2009’da ortaya çıktı. Bu kritik açık US-CERT/NIST tarafından duyuruldu ve bu açığı kullanan saldırganlar Guest OS yani VM üzerinden host sistemde (ESX çekirdeği) kod çalıştırabildiler

• http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1244

Peki şimdi soralım. 19 yama geçilmiş bir sistemin mi yoksa 168 yama geçilmiş bir sistemin mi geçmişi daha stabil ve güvenlidir? Hyper-V platformu Şubat 2008’den beri yaygın kullanımda ve Hyper-V spesifik ilk güvenlik açığı daha geçen hafta yayınlandı. Açık Microsoft tarafından duyuruldu ve aynı gün ilgili yama da yayınlanarak kapatıldı. 2 yılda tek bir kritik güvenlik açığı. Bu bir anlam ifade etmiyorsa şunu söyleyelim: Hyper-V Common Criteria yani endüstrideki en saygın güvenlik sertifikalarından birine sahiptir ve Alman hükümetinin güvenlik gereksinimlerini tam olarak karşıladığı belgelenmiştir. Dahası da var, güvenliği neredeyse paranoya haline getirmiş kurumlardan biri olan İsrail ordusu da Hyper-V kullanmaktadır. Bu Örnekleri çoğaltmak mümkün.

Güvenlik ve güvenilirlik footprinte indirgenebilecek kadar basit konular değiller. Burada asıl önemli olan gerek Hyper-V’nin gerekse ESX’in hata yapabilecek insanlar tarafından geliştirildiği ve asıl kritik olan noktanın disk footprint değil bu yazılımlarda ne kadar açık ortaya çıktığı ve ne hızda kapatıldığıdır. Yorum sizin.

2. Bellek Yönetimi (Memory Management)

VMware der ki Hyper-V memory overcommitment (dinamik bellek yönetimi) yapamıyor.

Evet Hyper-V’de şimdilik memory overcommitment yok. VMware ise dynamic memory yönetimi yapabiliyor. Bu yetenek memory overcommitment olarak geçiyor ve VMware’in altını çizdiği özelliklerden birisi. Öncelikle bu özellik ne işe yarıyor bir göz atalım. ESX Server (host) üzerinde 10GB fiziksel memory olduğunu düşünelim. Bu host üzerinde 4 adet VM çalışıyor ve her biri için 2’şer GB sanal memory verdik. Bu durumda 8GB memory’i VM’ler, 2GB memory’i host kullanıyor gibi düşünebiliriz. Memory overcommitment özelliği sayesinde VM’lere toplam fiziksel memory miktarından daha fazla sanal memory atanabiliyor ve arka plandaki fiziksel memory kullanımı dinamik olarak yönetilebiliyor. Örneğin bu özellik sayesinde 4 VM için 4’er GB sanal memory atamak mümkün. Bu durumda toplam memory miktarı en az 16GB olması gerekir ama arka planda fiziksel memory miktarı 10GB’tır. İşte bu noktada memory overcommitment devreye girer ve memory kullanımını bir havuz mantığıyla dinamik olarak yönetir ve o an kullanılmayan fiziksel memory kaynağını ihtiyacı olan VM’in kullanımına sunabilir. Görünen en temel avantaj boşta bekleyen memory kaynağının bir VM’e dedicate edilmiyor olması ve dinamik olarak ihtiyacı olan VM’lerin kullanımına sunuluyor olmasıdır.

Öncelikle bahsetmek istediğim konu memory overcommitment’in VM performansını olumsuz yönde etkileyebiliyor olması. Özellik dışarıdan harika görünüyor ama performans tarafındaki eksiler VMware tarafından da üstü kapalı olarak kabul ediliyor. Aşağıda VMware ESX Server Performance Tuning Best Practices dokümanını bulabilirsiniz.

• http://www.vmware.com/pdf/vi_performance_tuning.pdf

Bu dokümandan bir paragraf:

Avoid frequent memory reclamation. Make sure the host has more physical memory than the total amount of memory that will be used by ESX plus the sum of the working set sizes that will be used by all the virtual machines running at any one time. Due to page sharing and other techniques, ESX Server can be overcommitted on memory and still not swap. However, if the over-commitment is large and ESX is swapping, performance in the virtual machines is significantly reduced.

Neden böyle bir performans sorunu olduğunu anlamak için özelliğin arka planına bakmak lazım. Az önceki senaryo üzerinden gidelim. Hatırlarsanız VM’ler için fiziksel memory’den daha fazla miktarda sanal memory atamıştık ve bunu memory overcommitment sayesinde olabildiğini söylemiştik. Bu senaryoda VM’lerin memory kullanımı bir şekilde fiziksel memory miktarını geçerse şayet, VM’ler üzerinde performans sıkıntısı yaşanmaya başlar ki bu ihtimal her zaman vardır. ESX üzerinde memory overcommitment ile çalışan VM’lerin sanal memory kullanımı fiziksel memory miktarını aşarsa öncelikle devreye Ballooning driver girer ve boşta olduğu düşünülen fiziksel memory alanını ihtiyacı olan VM’e göndermeye çalışır. Eğer bu şekilde ihtiyacı karşılayamazsa olay swapping’e taşar (virtual swap) ve gerekli memory ihtiyacı disk üzerinden karşılanır (bir nevi page file). Bu durumda VM performansı düşer çünkü Guest OS memory işlemlerinin bir kısmı fiziksel memory’den karşılanırken diğer kısmı disk üzerinden karşılanır ve bu noktada bellek performansı bir nevi disk okuma/yazma hızına bağlanır.

Vmware’in bu konudaki savunması ise şöyle: ESX’in default olarak kullanılan özelliği Transparent Memory Sharing’dir ve bu performansı düşürmez. Evet Transparent Memory Sharing, Ballooning ve Virtual Swapping gibi performansı düşürmüyor olabilir ama güvenlik tarafında risk yaratan bir arka plana sahiptir çünkü bu özellik virtualization layer’ın o host üzerinde çalışan tüm VM memory page’leri taraması prensibine dayanıyor. Yani tamamen izole olması gereken VM’lerin arka planda izole olmadığını ve memory page’lerin ortak bir işleme tabi olduğunu görüyoruz.

Bir başka önemli nokta da şu. ESX üzerinde süper olduğu düşünülen bir özellik (Transparent Memory Sharing) her Guest OS için aynı tadı veremez. Özellikle Windows Vista, Windows 7, Windows Server 2008 R2 gibi yeni jenerasyon işletim sistemleri ASLR (Address Space Layout Randomization) olarak adlandırılan bir güvenlik özelliğine sahiptir. Bu özellik Guest OS boot esnasında runtime sistem dosyalarının rastgele bellek adreslerinde çalıştırılmasını ve memory alanının saldırılara karşı korunmasını sağlar (sadece guest os’e özgü bir özellik değildir, fiziksel ortamda çalışan os’ler için de geçerlidir). Bu sırada sanal makinelerin memory page yapıları farklılaştığı için Guest OS’ler Transparent Memory Sharing’den tam anlamı ile faydalanamazlar.

Geçenlerde çalıştığım şirket üzerinden VMware’in Türkiye distribütorlerinden biri ile toplantı yaptık ve şirketimiz adına ESX’i dinledik. Toplantı sonrasında bazı konular ile birlikte özellikle memory overcommitment konusunda bir mail trafiğimiz oldu ve distribütor tarafındaki uzman arkadaşlarımızın yorumlarını olduğu gibi aktarıyorum:

VMware de memory management ozelligi Serhat’in gosterdigi gibi yapiliyor. Eger ki sanal makinelerin memory kullanimi fizikselde olan degeri asarsa tabi ki sanal makinelerin performansi azalacaktir. Burada once Balooning daha sonra da Virtual Swap kullanimi devreye girer

Fakat VMware’in memory managemet ozellikleri her zaman kullanilabilecek bir ozelliktir ki VM lerde kullanilan memory miktarinin her zaman fizikselden saglanmasini tavsiye ederiz. Burada default olarak kullanilan ozellik Transparent Memory Sharing ozelligidir ve performansi dusurmez.

Bu arada eger istenirse sanal makine bazinda balooning ve transparent page sharing ozelligi disable edilebilir ki Microsoft un biz daha performansliyiz dedigi seviyeye ulasabiliriz :)))

Bir diğer yanıt:

Memoryovercommit özelliği 2001 senesinden beri bizde olan bir özellik. Bu özellik istenilirse kullanılmayabilir, o zamanda MSin yetenekliyiz dediği noktaya, biz kendi özelliğimizi disable ederek gelmiş oluruz ki buda trajı komik bir olay olacaktır

Cevaplar güzel ama gözden kaçan bir nokta var. Bir özelliği kapatarak (memory overcommitment) performans sağlanıyorsa, o özelliğin performansı olumsuz yönde etkilediği fikrimiz zaten kendini kanıtlamış olmuyor mu? Ayrıca her iki cevapta da istenirse bu özelliğin kullanılmayabileceğinden bahsediliyor ve zaten ESX Best Practice Tuning dokümanında da üstü kapalı olarak tavsiye edilmediğini görüyoruz. Peki performans ve güvenlik endişeleri nedeniyle devre dışı bırakılması söz konusu olan bir özellik ürün seçiminde dikkate alınması gereken bir özellik midir? Memory overcommitment teknolojileri Gartner verilerine göre ortalama %20 seviyesinde kullanılmaktadır. Yani müşteriler bu özelliği kullanmadıkları duruma göre %20 daha fazla VM density elde etmektedirler. Ürünü yakından tanıyan global müşterilerin bir çoğunun bu özelliği test ve geliştirme ortamlarında kullandığını yine araştırma raporları ile gördük. Türkiye de ise ESX admin’lerin bu konu üzerine fazla kafa yorduğunu sanmıyorum. Distribütör tavsiyesi ile açalım memory overcommit’i bakalım keyfimize diyorlar sanırım.

Şu an Hyper-V üzerinde memory overcommitment yok. Hyper-V üzerinde memory daima VM’e allocated durumdadır. VM’lere fiziksel memory miktarından daha fazla virtual memory atayamayız. VM’in 4GB virtual memory’si varsa, fiziksel olarak 4GB memory o VM’e mutlaka ayrılmış demektir. Yapıda herhangi bir memory sharing ya da overcommitment özelliği yoktur. Doğal olarak bu özelliklerin yukarıda saydığımız dezavantajları da yoktur. Microsoft’un dynamic memory management konusundaki çalışmaları devam ediyor ve bu özellik Hyper-V üzerine eklendiğinde, özellikle güvenlik tarafında konuştuğumuz sıkıntıları ortadan kaldıran daha farklı bir background ile gelmiş olacak. Hatırlarsanız Windows Server 2008 R2 Beta’da bu işi yapan bir özellik vardı ve bir süre test etme şansımız olmuştu ancak RTM sürümde gelmedi. Benzer bir durum Live Migration için de yaşanmıştı. Windows Server 2008 Beta + Hyper-V üzerinde Live Migration özelliği varken, RTM sürümde yer almadığını gördük. Daha sonra Windows Server 2008 R2 ile Live Migration support edildi. Aynı süreci memory overcommitment teknolojileri için de yaşayacağımızı düşünüyor ve bir sonraki versiyonu bekliyoruz.

Ha bu arada dynamic memory’e mi ihtiyacınız var? VMware ve Microsoft çözümleri arasındaki maliyet farkı gayet açık. Hyper-V ortamındaki sunuculara fazladan bellek eklemek ve hatta bazı durumlarda ortama komple yeni sanallaştırma sunucuları koymak hala çok daha ucuz bir çözümdür :)

3. Linux Desteği (Guest OS Support)

Vmware der ki Hyper-V üzerinde Linux Guest OS desteği sınırlıdır.

Evet ilk bakışta galiba öyle gözüküyor ancak bu “destekt”en ne anladığımıza göre de değişir. Sanırım VMware ekibi Supported Guest OS listelerini alıp “iki resim arasındaki farkı bulun” şeklinde bir karşılaştırma yapıyor.

Şu an için Hyper-V üzerinde resmi olarak support edilen 2 adet Linux dağıtımı var:

• Suse Linux Enterprise 10/11
• Redhat 5.2/5.3/5.4

Peki diğerleri? Ubuntu, Debian, BSD, CentOS, Feadora vs.. Öncelikle Hyper-V üzerinde çalışan VM’lerden birkaç ekran görüntüsü paylaşalım.

Hyper-V üzerinde Ubuntu

Hyper-V üzerinde CentOS

Hyper-V üzerinde Debian

Hyper-V üzerinde OpenBSD

Yani neymiş? Hyper-V üzerinde çalışan Linux Guest OS’ler sadece Redhat ve Suse Linux ile sınırlı değilmiş. O halde neden sadece bu iki Linux dağıtımı support ediliyor sorusu aklınıza gelebilir. Bu konuyu anlamak için Microsoft’un support politikasına bakmak gerekiyor. Microsoft için bir Linux dağıtımının Hyper-V üzerinde support ediliyor olması demek, o Guest OS’in her noktası ile support ediliyor olması demektir. Ör Redhat officially supported bir Guest OS’tir. Yani siz Hyper-V üzerinde çalışan Redhat Guest OS’te herhangi bir sorun yaşarsanız (işletim sistemi seviyesinde dahi) bu konu ile ilgili Microsoft çağrı merkezine ulaşıp destek talep edebilirsiniz. Microsoft ise ilgili OS üreticisi ile ortak çalışıp oluşan problem için çözüm üretir. Yani arka tarafta vendor’lar arası bir iş birliği söz konusudur. Aynı durum Suse Linux için de geçerli.

Peki VMware tarafındaki Linux Guest OS desteği nasıldır? VMware, ESX üzerinde boot olabilen her işletim sistemi için supported der :) Ama o OS için bir problem yaşadığınızda sizi OS üreticisine paslar ya da Linux teknik topluluklarına yönlendirir. Asıl trajikomik olay ise şöyle: VMware, üreticisi olan Microsoft’un bile uzun zaman önce destek vermeyi kestiği Windows 98, Windows NT gibi sistemler için supported der. Peki VMware üzerinde çalışan bir Windows NT Guest OS’de sorun yaşandığında acaba VMware Windows NT için hotfix mi yazmaktadır? Bunu yapabilmek için ürünün koduna ve kullanma hakkına sahip midir? Böyle bir durum olamayacağından VMware müşteriyi Microsoft’a yönlendirecek ve müşteri de Microsoft tarafında bu desteğin bittiği bilgisini alacaktır. VMware listesine bu şekilde bakıp üreticisi tarafından artık desteklenmeyen ya da sadece community support modeliyle işleyen Guest OS’ler çıkartıldığında Microsoft’un Supported Guest OS listesiyle başa baş bir durum ortaya çıktığını açıkça görebilirsiniz.

Bildiğiniz gibi Linux Guest OS’lerin Hyper-V üzerinde çalışıp sentetik sürücülerden faydalanması için Linux ICs paketi kullanıyoruz. Bu paket ilgili sentetik sürücüleri içeriyor ve bunları Linux OS içine entegre ediyor. Geçtiğimiz aylarda Linux ICs GPLv2 lisansı ile dünyaya açıldı (yani open source hale geldi). Artık Linux geliştiricileri bu driver’ları alıp OS’lerin içine gömebilecek ve dağıtımlarını Hyper-V üzerinde çalışır hale getirebilecekler. Önümüzdeki aylarda çok değişik Linux temelli OS’lerin Hyper-V üzerinde koştuğunu görebileceksiniz. Belki tamamı resmi olarak Microsoft tarafından support edilmeyecek ama bu OS Vendor’lardan SVVP programına başvurup geçerli olanlar resmi olarak support ediliyor olacak. Bu konudaki bir diğer güzel gelişme de şu: Hyper-V Linux ICs, 2.6.32 Linux Kernel içerisinde yerini aldı. Artık bu kernel’ı kullanan Linux dağıtımlarını Hyper-V üzerinde direkt boot edebileceksiniz.

4. HA ve Live Migration

Hyper-V’nin bu konuda ESX’ten herhangi bir eksiği yoktur ki zaten artık VMware da bu konuda konuşmayı bıraktı.

Windows Server 2008 R2, Failover Cluster, CSV, System Center Virtual Machine Manager 2008 R2 ve Operation Manager entegrasyonu ile maximum available bir ortam, hem de VMware çözümlerinden çok daha düşük maliyetle inşa edilebilir. Live Migration ise Windows Server 2008 R2 ile supported durumda. ESX üzerinde Live Migration (yani vMotin) ücretli bir özelliktir. Microsoft ise bu özelliği ücretsiz olarak sunuyor. Eğer Windows Server 2008 R2 + Hyper-V kullanıyorsanız maliyetiniz sadece platform OS bedelidir. Örneğin Hyper-V Server 2008 R2 kullanıyorsanız (yani tamamen ücretsiz olan sürüm) herhangi bir maliyet oluşmadan bu özelliği ve Failover Cluster gibi diğer bir çok özelliği kullanabilirsiniz. Aşağıda ise Live Migration’ının zemininde yatan teknolojilerden olan CSV dosya sistemi Clustered File System’in VMware VMFS3 ile karşılaştırmasını görebilirsiniz.

5. FT / Fault Tolerance

Vmware der ki biz FT yaptık sizde var mı?

Hayır, Hyper-V tarafında FT’e karşılık gelen bir özellik yok. Peki nedir bu FT? FT ile bir VM’in kopyası diğer ESX node üzerinde tutulabiliyor. İlk node herhangi bir nedenden ötürü down olduğunda VM’in ikinci node üzerinde anında ve kesintisiz şekilde up olması sağlanabiliyor. Evet harika bir özellik ama maalesef gerçek hayatta kullanım senaryosu çok az. Sebebini anlamak için FT’nin bazı dezavantajlarına bakmak yeterli.

• Her şeyden önce FT enabled bir VM üzerinde tek bir sanal işlemci kullanabiliyorsunuz yani vSMP desteklenmiyor. Bence bu durum bile özellik için henüz erken olduğunu görmek adına yeterli. Tek bir sanal işlemci ile production’da koşan kaç tane VM’iniz var?
• Bu özellik için fiziksel işlemci yeteneği olan EPT ve RVI gibi yeni nesil teknolojilerin disable olması gerekiyor. Ayrıca Hyper-Threading’in de disable edilmesi tavsiye ediliyor.
• FT enabled VM’lerde RDM (Raw Device Mapping) desteklenmiyor.
• FT enabled VM’ler için storage vmotin desteklenmiyor.
• FT enabled VM’ler için HotAdd virtual device’lar desteklenmiyor.
• FT enabled VM’lerde DRS, HA ve Power Management yetenekleri desteklenmiyor.
• FT enabled VM’lerde diskler Thick olmak zorunda.
• FT enabled VM’lerde Snapshot desteklenmiyor.
• FT enabled VM’lerde NPIV desteklenmiyor.

Sonuç olarak FT için henüz çok erken çünkü hala emekliyor. Bu arada FT, Guest OS üzerindeki service/application sorununu tolere edemeyecektir. VM üzerindeki application’da meydana gelen bir sorun aynı şekilde diğer node üzerindeki kopyaya da sync olur. Yani bir Guest Cluster güvenilirliği yoktur.

6. Maliyet (Cost)

Vmware der ki biz pahalı olduğumuzu biliyoruz :)

Hyper-V & ESX ve ürünlerin management/maintenence maliyetlerini karşılaştırmaya gerek var mı bilmiyorum.

Yukarıdaki tablo her iki vendor’ın %100 free olan ürünlerini karşılaştırıyor. Dikkat ederseniz Hyper-V Server 2008 R2 ile Live Migration ve Failover Cluster (HA) özelliklerine de ücretsiz olarak sahip oluyorsunuz. VMware dünyasında bu yetenekler ücretlidir. Aşağıdaki tabloda ise VMware ve Microsoft tarafındaki komple sanallaştırma çözümlerinin (hypervisor+management) karşılaştırmasını görüyorsunuz. Bu tablo her iki ürün için de 2’şer cpu’lu 5 Host ve 2 yıllık support baz alınarak hazırlanmıştır.

Aşağıdaki tablo ise VMware vSphere ile Hyper-V + System Center yönetim çözümlerinin core feature’larını ele alıyor.

Management yazılımlarının maliyet ve yetenekleri:

Gördüğünüz gibi Microsoft sanallaştırma ürünleri hala çook daha ucuz çözümler.