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

14.02.2010 | 00:01 Hyper-V , VMWare 42 Yorum

Son zamanlarda VMWare bloglarında, global news’larda ve forum’larda Hyper-V hakkında myth (söylenti, efsane) postlarına oldukça sık rastlamaya başladık. (Esx vs. Hyper-v) Bu postlarda ve comparison chart’larda dikkatimi çeken nokta ise VMWare’ın kendi ürünlerini Hyper-V ile kıyaslarken eksik veya yanlış bilgiler veriyor olmasıydı. Global ortamda bu söylentilere gerekli yanıtlar zaten verildi. Bu post ile ben de konuyu Türkçe olarak ele almak istedim.

Öncelikle VMWare’in bu yaklaşımının arkasında iki temel neden olabileceğini düşünüyorum.

  1. VMWare artık iyiden iyiye Hyper-V’nin nefesini ensesinde hissetmeye başladı  ve tenik açıdan giderek kapanan farkı bu şekilde açmaya çalışıyor.
  2. VMWare Hyper-V’yi tanımıyor, üründeki gelişmeleri yeterince takip etmiyor.

Nedenler bunlar, daha fazlası, belki de hiçbiri! Bu nokta biraz da kişisel yoruma kalmış. Ama ortada bir gerçek var ki o da dolaşan söylentilerin gerçeği yansıtmadığı :)

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. Ayrıca yazının sonunda Neden Hyper-V Tercih Etmeliyim konusunda kafanızda bir fikir oluşacağından eminim.

1. Güvenlik ve Disk Footprint

Vmware, Hyper-V Disk Footprint ’e takmış durumda.

Footprint ’i ürünün disk üzerinde kapladığı alan (yani total code base, toplam kod miktarı) olarak düşünebilirsiniz.

VMWare derki; Hyper-V Windows Server 2008 işletim sistemiyle çalıştığını için disk footprint ’i büyüktür (2.6GB –  Server Core + Hyper-V) 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 arttırmakta, stabilite için risk teşkil etmekte, önemli güvenlik riskleri oluşturmakta ve performance overhead yaratmaktadır.

ESX Hyper-V Karşılaştırması

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. (bu yazıda bu noktalara girmiyoruz)

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ı? ve bunları kapatmak için harıl harıl güncelleştirme geçildiğini biliyor musunuz?

ESX 3.5 için 168 adet güncelleştirme geçildi (ki bu rakam artmış durumda) ve bu güncelleştirmelerin toplamı yaklaşık 3GB kadar.

Windows Server 2008 Core + Hyper-V için son 18 ayda geçilen güncelleştirme sayısı ise sadece 19 ve toplam boyut 80 mb. :)

Peki 32MB’lık bir sisteme 168 adet (3GB) patch geçilmesi sizce normal mi? Bir anda ESX disk footprint 96 katına çıktı ve neden sürekli critical update?

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 start edilemedi,  VM suspend konusunda sıkıntılar yaşandı 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 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.

Açığın etkileri: Provides administrator access, Allows complete confidentiality, integrity, and availability violation; Allows unauthorized disclosure of information; Allows disruption of service.

Açık ile ilgili makale: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1244

Peki şimdi sormak istiyorum. Teorik olarak 19 yama geçilmiş bir sistem mi yoksa 168 yama geçilmiş bir sistem mi daha stabil ve güvenlidir? Pratik ise zaten ortada.

Hyper-V Ş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 daha kritik olan noktanın footprint değil bu yazılımlarda ne kadar açık ortaya çıktığı ve ne hızda kapatıldığıdır.

Yorumu size bırakıyor ve devam ediyorum.

2. Bellek Yönetimi (Memory Management)

Vmware derki; 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 her fırsatta 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 atanıyor 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 atanabilir. Bu durumda teorik olarak toplam memory miktarı 16GB olması gerekir ama arka planda fiziksel memory miktarı 10GB’tır. İşte bu noktada memory overcommitment devreye girer ve memory kullanımını 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.

Buradan bakınca güzel görünüyor ama bu özelliğin background’unda neler olup bitiyor? ve işler yukarıdaki çerçevenin dışına çıktığında süreç nasıl işliyor? Bu konulara az sonra geleceğim.

Öncelikle bahsetmek istediğim konu memory overcommitment’in VM performansını olumsuz yönde etkileyebiliyor olması. Özellik dışarıdan güzel 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, 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 konu yani sanal 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 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 sahip çü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ı vermez. Ö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 firma üzerinden Vmware’in Türkiye distribütorlerinden biri ile toplantı yaptık ve ESX’i dinledik. Toplantı sonrasında bazı konular ile birlikte özellikle memory overcommitment konusunda bir mail trafiğim oldu ve distribütor tarafındaki uzman arkadaşlarımızın yorumlarını aynen 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 uzman arkadaşın cevabı.

“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 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 nedeni ile 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 %120 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 adminlerinin 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.

Gelelim bu özellik için Hyper-V tarafındaki duruma?

Evet, şu an Hyper-V üzerinde memory overcommitment yok. Hyper-V üzerinde memory 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 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 çok 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 yaşayacağımızı düşünüyor ve bir sonraki versiyonu bekliyoruz.

Ha bu arada 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 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 derki; Hyper-V üzerinde Linux Guest OS desteği kısıtlıdır.

Hmm.. Galiba öyle ama bu destekten ne anladığımıza göre de değişiyor. Sanırım Vmware uzmanları Supported Guest OS listelerini alıp “iki resim arasındaki 7 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 Ubuntu

Hyper-V üzerinde CentOS

Hyper-V üzerinde CentOS

Hyper-V üzerinde CentOS 2

Hyper-V üzerinde Debian

Hyper-V üzerinde Debian

Hyper-V üzerinde OpenBSD

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 distrosu 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. Official 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. Redhat support’u için daha önce kısa bir duyuru yapmıştım. Şuradan ulaşabilirsiniz. Aynı durum Suse Linux için de geçerlidir.

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 community’lerine yönlendirir. Büyük Support, yersen :)

Bir de şöyle bir trajikomik olay var. Vmware, üreticisi olan Microsoft’un bile uzun zaman önce destek vermeyi kestiği Windows 98, Windows NT gibi sistemler için supported diyor. 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 listeden çıkartıldığında, Microsoft’un Supported Guest OS listesiyle başa baş bir durum ortaya çıktığını açıkça görebilirsiniz.

Hyper-V üzerinde Resmi olarak desteklenen Guest OS listesi aşağıdaki bağlantıda yer alıyor.

http://www.microsoft.com/windowsserver2008/en/us/hyperv-supported-guest-os.aspx

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) (Bu konu ile ilgili şurada bir duyuru yapmıştım).

Artık Linux geliştiricileri bu driver’ları alıp OS’lerin içine gömebilecek ve distroları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’i kullanan linux distroları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ı.

HA için temel Failover Cluster senaryolarına aşağıdaki linkten ulaşabilirsiniz.

http://www.serhatakinci.com/?p=943

Makalede anlatılan senaryoların dışında 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. Ha bu arada, 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 platform OS bedelidir (yani Windows Server 2008 R2). Ama Hyper-V Server 2008 R2 kullanıyorsanız (yani %100 free olan sürüm) herhangi bir ücret ödemeden 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.

Vmware ve Microsoft Clustered File System ’leri arasındaki farklar.

Vmware - Microsoft Clustered File System

5. FT Fault Tolerance

Vmware bu özelliği ile öyle bir övünüyor ki bir an hayatın sırrını keşfettiklerini ve bunu ESX’e özellik olarak eklediklerini düşündüm :)

Vmware derki; 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 available olması sağlanabiliyor.  Evet teoride güzel bir özellik ama maalesef canlıda aynı tadı vermiyor. Güzel bir adım ama bu özelliğin gelişime ihtiyacı olduğu açık. Bunu 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.

Bu liste uzar gider..

Sonuç olarak FT için erken çünkü henüz emekliyor.. Global’da referansı var mı bilemiyorum ama Türkiye de bu özellik için referans bile yok.

Bu arada FT, Guest OS üzerindeki services/application sorununu tolere edemez. VM üzerindeki application’da meydana gelen sorun aynı şekilde diğer node üzerindeki kopyaya da sync olur. Yani bir Guest Cluster güvenilirliği yoktur.

6. Maliyet (Cost)

Vmware derki; Biz pahalı olduğumuzu biliyoruz :) (Sonunda Vmware ile hemfikir olduğum bir nokta buldum)

Hyper-V – ESX ve ürünlerin management/maintenence maliyetlerini karşılaştırmaya gerek var mı bilmiyorum :) Bilgi tazelemek adına aşağıda bazı comparison chart’lara yer vermek istiyorum.

ESX vs Hyper-V Karşılaştırma Tablo 1

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 chart 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.

ESX vs Hyper-V Karşılaştırma Tablo 2

Aşağıdaki chart ise Vmware vSphere ile Hyper-V v2 + SC Management çözümlerinin core feature’larını ele alıyor.

ESX vs Hyper-V Karşılaştırma Tablo 3

Management yazılımlarının cost’ları ve yetenekleri:

ESX vs Hyper-V Karşılaştırma Tablo 4

Gördüğünüz gibi Microsoft Virtualization ürünleri hala çooooook daha ucuz çözümler :)

Kaynaklar:
http://www.microsoft.com/virtualization/
http://blogs.technet.com/virtualization/
http://www.vmware.com/pdf/vi_performance_tuning.pdf
http://www.vmware.com/

Yazı Etiketleri: , ,

Sayfa Başı ▲

Yorumlar (42)

  1. virtualboy

    Serhat abi özlemiştik yazılarını. ama beklediğimize deydi çünkü yine mükemmel bi yazı olmuş tebrik ederim

  2. Volkan

    Bir ESX kullanıcısı olarak konuya hiç bu gözle bakmamıştım. Elinize sağlık, bilgilendirici bir yazı olmuş keyifle okudum. ESX konusunda fazla uzman olmadığım için yorum yapmam zor ama sitenizi takip eden uzman arkadaşlar varsa cevaplarını bekliyoruz :)

  3. Arda Turan

    Güzel yazı olmuş. Bu konuda Vmware’i de dinlemek gerektiğini düşünüyorum. Ama çok iyi noktaları yakalmışsınız tebirk ederim

  4. hakan uzuner

    Çok güzel hazırlanmış bir yazı.. güzel noktaları gün yüzüne çıkarmışsın .. bakalım vmware cephesi ne diyecek.

  5. Hüseyin ERTUGRUL

    Microsoft Hyper-v tarafındaki bir sonraki adımınıda kullanıcılar adına ücretsiz olarak atarsa vmware iyice köşeye sıkışacaktır. Eline sağlık Serhat bey, bu arada anladığım kadarıyla çalıştığınız firmada vmware kullanılıyor.

  6. Serhat AKINCI

    Henüz karar aşamasındayız Hüseyin bey. Hyper-V ve ESX’i değerlendiriyoruz.

  7. Şükrü

    Teşekkürler Serhat Kardeşim. oldukça açıklayıcı ve tatmin edici bir makale yazmışsınız.

  8. Yalçın

    Çok iyi bir inceleme olmuş Serhat hocam çok işime yarayacak

  9. Tayfun DEGER

    Yazılarını okumayı özlemişim Serhat hocam:)

  10. kerem kaplan

    Tebrik ediyorum gerçekten çok iyi

  11. Cemal Tuncel

    Elinize emeğinize sağlık diyerek tebrik etmek istiyorum.
    Affınıza sığınarak, biraz yanlı bir makale olarak gördüğümü belirtmek isterim.
    örneğin ilk aklıma gelen PRO, SMSD, SCCM ve SCVMM lisanslarını ne kadar?, herhangi bir sorunda MS den support ticket almak ne kadar? VCB gibi DPM ile Online backup alabiliyormuyuz, alabiliyorsak DPM2010 un fiyatı ne olacak? daha da çeşitlendirebilirim v.b gibi konularada deyinseydiniz keşke, o zaman biraz tarafsız olurdu.
    Saygılar sunarım.
    Sitebuilders dan atıldık, burdan da kovulmayız inş. :)

  12. Serhat AKINCI

    Cemal bey,

    Son bölümdeki comparison chart’larda geçen SMSD bir suite üründür ve içerisinde SCCM, PRO ve VM yönetimi için SCOM + SCVMM, Online Backup için DPM bulunur. Yani tüm System Center ürünlerine ayrı ayrı para ödemiyorsunuz çünkü tamamı SMSD ile geliyor :) fiyatları da karşılaştırmalı olarak yukarıda yer alıyor. Fiyatlara 2 yıllık support bedeli de dahildir. Aslında bu bilgileri yazıda vermiştim. Tekrar altını çizmiş olduk.

    Bu arada blog her daim herkese açık, kimseyi kovmuyoruz :) dilediğince yazabilirsin.

  13. Barış Yörük

    Merhaba
    Esxi kullanıyorum ve bu konuda çok bilgili olmasam da yazıyı yanlı buldum.
    Şöyleki, her özellik yanlış yada aşırı kullanıldığında yarardan çok zarar getirebilir. Bu durum o özelliği zararlı yapmaz.
    Ancak değerlendirmenizden çıkan sonuç şöyle çikolata iyidir, neşelendirir, bol miktar da şeker almanızı sağlar ama çok yerseniz dişlerinizi çürütür, o halde çikolata kötüdür.
    Sonuca ulaşma şekliniz bu şekilde olmuş.
    Her iki sanallaştırma yazılımının da kendilerine göre artıları yada eksileri mutlaka olacaktır. Ancak ekstra performans sağlamak amacıyla katılmış bir özelliği, sırf aşırı kullanıldığında yada aşırı gereksinim duyulduğunda olumsuz sonuç yaratmasını, bu sanallaştırma yazılımının eksisi olarak görmemek gerekir. Bu durumda boşta duran belleğin boşta durmaya devam etmesi daha iyidir demektir.
    Bu güzel yazı için teşekür ederiz.

  14. Serhat AKINCI

    Barış günaydın,

    Yorumun için tşk. Ancak yazdıkların ile yazdıklarım arasında bir bağlantı kuramadım. Yazıda birçok konuya değindim ama “ESX için şu özelliği çok kullanırsanız zararlıdır, ama az kullanırsanız iyidir” dediğimi göremedim. Bu arada sanırım memory overcommitment’dan bahsediyorsun. Bu özellik performanstan ziyade flexibility amaçlı.

  15. hakan uzuner

    Serhat karıştırdın ortalığı :)

  16. Deniz Yalçın

    Selam. Öncelikle bu yazı için teşekkürler güzel çalışma.ESX 3.5 için 3GB patch geçildiğini söylemişsiniz. Bu ürün biraz eski olduğu için bu rakama ulaşmış durumda. Yeni versiyonda (ESX 4) böyle bir durum yoktur diye düşünüyorum.

  17. Deniz Verman

    Serhat hocam merhabalar şunu sormak istiyorum vmware wokstation üzerinde server 2008 r2 kurup hyperv kullanabilirmiyiz teşekkürler…

  18. Serhat AKINCI

    Selam Deniz: Windows Server 2008 R2 kurabilirsin ancak Hyper-V rolünü ekleyip VM start edemezsin. Çünkü hypervisor, Hardware Virtualization özellikli işlemciye ve birçok donanıma direkt olarak erişmek ister.

  19. delikadir

    vmwarenin vm lerinde 3d destegi var hyper-v de yok ya gödünmü aga hıh :=))

  20. Serhat AKINCI

    ESX’in 3D desteği yoktur!

    “Vmware derki:
    The 3D acceleration feature is not supported is ESX 4.0. There are currently no plans to support 3D acceleration in a virtual machine on ESX.

    This option is available for virtual machines created in products that support 3D acceleration, such as VMware Workstation.”

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

    Sanırım sen Vmware Workstation ile karıştırdın ama o enterprise bir ürün değil ve Hyper-V/ESX ile farklı kulvarlarda. Bu arada yakında Hyper-V üzerindeki VM’ler için 3D’e yakın gelişmiş grafik özellikleri (remoteFX) geliyor.

    Windows Server 2008 R2 için SP1’i bekleyin..

  21. Mehmet Ali

    Virtual machine bağlandığım zaman aşağıdaki hatayı alıyorum neden oluyor olabilir acaba

    The connection to the virtual machine was lost. This can occur when a virtual machine stops unexpectedly, or when network problems occur. Try to connect again. If the problem persists, contact your system administrator

  22. Serhat AKINCI

    Selam Mehmet Ali,

    Sistemin hakkında detay vermemişsin ama muhtemelen Host üzerinde antivirüs kurulu durumda. Eğer böyle ise AV üzerinde vmms.exe ve vmswp.exe process’lerini exclude edersen yani tarama/kontrol dış bırakırsan problem çözülür.

  23. Mehmet TOPÇUOĞLU

    Merhaba Serhat Hocam hyper-v ile ilgili diğer makalelerinizi de okudum bu da diğerleri gibi çok kaliteli olmuş sanallaştırma ile ilgili olan bütün kararlarım değişti açıkçası vmware esx i düşünürken gönlüm hyper-v ye kaymaya başladı :)
    Saygılar,

  24. Arnold Reynolds

    MerhabaEsxi kullanıyorum ve bu konuda çok bilgili olmasam da yazıyı yanlı buldum.Şöyleki, her özellik yanlış yada aşırı kullanıldığında yarardan çok zarar getirebilir. Bu durum o özelliği zararlı yapmaz.Ancak değerlendirmenizden çıkan sonuç şöyle çikolata iyidir, neşelendirir, bol miktar da şeker almanızı sağlar ama çok yerseniz dişlerinizi çürütür, o halde çikolata kötüdür.Sonuca ulaşma şekliniz bu şekilde olmuş.Her iki sanallaştırma yazılımının da kendilerine göre artıları yada eksileri mutlaka olacaktır. Ancak ekstra performans sağlamak amacıyla katılmış bir özelliği, sırf aşırı kullanıldığında yada aşırı gereksinim duyulduğunda olumsuz sonuç yaratmasını, bu sanallaştırma yazılımının eksisi olarak görmemek gerekir. Bu durumda boşta duran belleğin boşta durmaya devam etmesi daha iyidir demektir.Bu güzel yazı için teşekür ederiz.
    +1

  25. Fatih Solen

    Merhaba

    Öncelikle yazı için çok teşekkürler. Yapılan kritik, karşılaştırmalar güzel olmuş ama tüm yazıda “Biz Microsoftcuyuz” havası var. Açıkçası çok objektif gelmedi. (:

    Her iki ürünlede (ESX ve Hyper-V) yüksek/düşük konfigürasyonlu farklı farklı sunucular üzerinde farklı hizmet ve ihtiyaçlar için prod./test ortamlarda çalışma fırsatı buldum.

    Özetle farkettiğim durum;

    VMware ESX kullanıyorsanız yüksek I/O sağlayan bir storage var ise aynı koşullar altında Hyper-V hiç bir konu da performans bakımından ESX’in yakınlarından geçemiyor.

    Eğer storage olarak sunucunuzun düşük performanslı örn. 7200 RPM sata sıradan lokal disklerini kullanıyorsanız Hyper-V bu durumda performansta öne çıkıyor.

    Yıllardır ESX kullanıyorum güvenlik konusunda hiç sıkıntı yaşamadım. 2 Seneye yakın zamandır 1 dakika bile olsa hiç kapanmamış ESX sunucular var. VMware ESX üzerindeki vNetworking’i hyper-v de çok arıyorum ve bu alışkanlıkların dışında. Bana göre Hyper-V nin başta sistem kararlılığı olmak üzere bir çok konuda daha çok yolu var.

    Teoride olanları ve sağda-solda söylenenleri boşverip pratikte, canlıda bir kıyas yapılıp tarafsız olmak gerekirse; Şu an bir tercih yapmam istenilse; benim tercihim şimdilik VMware olmaya devam edecek. (:

    Saygılar.

  26. Serhat AKINCI

    Selam Fatih: Aslında yorumunda geçen her cümle için söylenecek çok şey var. Lütfen bunu yanlış anlama. Sadece ilk izlenimim bu olduğu için yazdım.

    Bu arada sen ve diğer arkadaşlarımızın konu hakkındaki yorumları benim için gerçekten çok değerli çünkü aslında Türkiyede olmayan birşeyi yapıyoruz ve yazıyı okumadan teşekkür etmek yerine konuyu farklı bir boyuta taşıyıp yorumlarla teknik detayları tartışıyoruz. Bence bu çok değerli bir şey çünkü konuya farklı bakış açılarının da dahil olmasını sağlıyor ve bütünüyle bakıldığında ortaya kaliteli ve harika bir tablo çıkıyor :) Bu nedenle ben de yapılan her mantıklı yoruma kendimce yanıt vermeye çalışıyorum. (bu durum her makalem için geçerli)

    Ben sana iki şey sormak istiyorum.

    VMware ESX kullanıyorsanız yüksek I/O sağlayan bir storage var ise aynı koşullar altında Hyper-V hiç bir konu da performans bakımından ESX’in yakınlarından geçemiyor.

    Bu konu için yaptığın analizlerin detaylarını paylaşabilir misin? Birde biz göz atalım.

    Yıllardır ESX kullanıyorum güvenlik konusunda hiç sıkıntı yaşamadım.

    Senin yada farklı birinin güvenlik ile ilgili sıkıntı yaşamamış olması, benim yukarıda resmi linkleri ile paylaştığım güvenlik açıklarının var olduğu gerçeğini değiştirir mi? ne dersin?

    Genel bir bilgi: Yorum yaptığımız bu makale bir ESX & Hyper-V karşılaştırması değildir. Makalenin ana teması, Vmware tarafından Hyper-V için söylenmiş ve aslında sanıldığı gibi olmayan konulardır. Makalenin başındaki paragrafa dikkat etmenizi istiyorum.

    Son zamanlarda vmware bloglarında, global news’larda ve forum’larda Hyper-V hakkında myth (söylenti, efsane) postlarına oldukça sık rastlamaya başladık (Esx vs. Hyper-v). Bu postlarda ve comparison chart’larda dikkatimi çeken nokta ise Vmware’ın kendi ürünlerini Hyper-V ile kıyaslarken eksik veya yanlış bilgiler veriyor olmasıydı. Global ortamda bu söylentilere gerekli yanıtlar zaten verildi. Bu post ile bende konuyu Türkçe olarak ele almak istedim.

    Ve şu da unutulmamalıdır ki Hyper-V için yapılmış bir takım yanlış açıklamaların doğrularını paylaşırken konuya Hyper-V tarafından bakmak (bazı arkadaşlarımızın tabiriyle objektif olmamak) bu tip yazıların doğasında vardır.

  27. Burak A.

    Serhat bey öncelikle bu güzel makale için teşekkürler. Gerçekten çok farklı ve kaliteli bir tarzınız var ve bu kaliteden ötürü sitenizi sürekli takip ediyorum.Son yorumunuz bu düşüncemde ne kadar haklı olduğumu tekrar gösterdi. Emeğinize sağlık.Keyifle takip ediyoruz.

  28. Burak A.

    Bu arada bizde uzun bir değerlendirme sürecinden sonra hyperv tercih ettik ve gayet memnunuz.

  29. zeynep kaleli

    belki konu dışı ama sormak istiyorum birçok video paylaşım sitesinde esx ve hyperv karşılaştırma videoları var ve esx hep önde görünüyor. sizce bu videolara güvenmelimiyiz

  30. Serhat AKINCI

    Selam Zeynep: Bu çalışmaları yayınlayan kişilere şu iki soruyu soruyu yönelt.

    – Hangi test metodolojileri kullanılmış? (bu testler genelde sistemlere bir vm koyup üzerine iki uygulama kurarak yapılır ve testi yapan kişilerin konu hakkında en ufak fikirleri yoktur..)
    – Hangi version’lar kullanılmış? (bu testlerde genelde Hyper-V’nin beta,rc yada ESX’e göre daha alt sürümleri kullanılıyor. Hatta şurada bu konu ile ilgili traji komik bir olaydan da bahsetmiştim.

    Bu testleri yapan arkadaşlar eğer bu iki soruya cevap verebiliyorsa, o zaman ne yaptıklarına bir bakarız..

  31. Aslan

    Alıntı:
    testi yapan kişilerin konu hakkında en ufak fikirleri yoktur..

    Esx in üstün göründüğü bir test sonucunda, yorumunuza göre testi yapan kişilerin konu hakkında en ufak fikirleri yoktur ama Hyper V nin üstün göründüğü bir testi yapan kişiler çok uzman ve kaliteli testlerimi yapıyorlardır acaba?

    Sizin bu yorumunuz bile, çok önyargılı, objektif olmadığınız ve taraflı bir tutum içerisinde olduğunuzun bir göstergesidir. Kişilerin yorumlarına verdiğiniz yazıların bile çok ukalaca olduğunu görüyorum. O nedenle bir kere yazanlar siz yanıt yazdıktan sonra cevaben bir yanıt dahi yazmamışlar.

    Lafla peynir gemisi yürümüyor. Bu yazılarınız ve yorumlarınız sonrasında size yakında kesin Hyper V konusunda MVP yaparlar.

  32. Serhat AKINCI

    Merhaba Aslan: Test konusunda Hyper-V için de benzer durumlar mutlaka vardır. Olmadığını söylediğimi de hatırlamıyorum?

    Eğer ortada bir idda varsa, teknik olarak kanıtta olmalı ki ucu açık kalmasın.. ve bence siz yorumlardan önce yazıyı okumalısınız.

    Bu arada hep söylerim; ünvanlar gelir geçer, kalıcı olan isimdir.

  33. Özgür GÖKGÖZ

    Geçen Wmware’in sayfasında Hyper-V karşılaştırmasını yayınladığı bir video vardı. Buradaki Videyu yu izledim ve kullandıkları materyeller bana saçma geldi. Aradan zaman geçti aynı saçmalığı başkaları da farketmişki videoyu yayından kaldırdılar ve hiçbir açıklama yapmadan. Bu video nun içeriğindeki ESX ile Hyper-V karşılaştırmadaki eksik mataryallerle kıyaslama yapılması Serhat Hocamızı biraz daha doğrulamış oldu. Birşeyi kıyaslarken bana göre enson sürümleri ve aynı ortamda çalıştırılıp test edilmesi gerekir. Bunu Wmware yapıyorsa bizim de yapmamız normaldir.Wmware’in ESX i gerçekten de güzel Hyper-V de aynı şekilde, ancak HYper-V sanki çokta önemli olmayan eksiklerini kapatıyor hızlıca.

  34. Serhat AKINCI

    Özgür selam: Güzel bir noktaya değinmişsin. Geçen sene de benzer bir durum söz konusuydu ve Vmware tarafından alakasız bir karşılaştırma yapılmıştı. Şurada konu ile ilgili bir yazı yazmıştım: http://www.serhatakinci.com/index.php/yanlis-bir-esx-hyper-v-karsilastirmasi.html

    Bu video da bir süre sonra yayından kalktı.

    Vmware için Türkiyede yapılan sunumlarda hala ESX’in 4.0 versionu ile Hyper-V’nin 1.0 versionu karşılaştırılıyor ki ürünün Türkiye distribütörleri ve partner’ları da bu slaytları kullanıyor :) Bu arkadaşlara önerim: Eğer durumun farkında değillerse bir zahmet Hyper-V’nin yeni versionunu incelesinler ve slaytlarını güncellesinler çünkü komik görünüyorlar.. Eğer durumun farkındaysalar dahada üzücü bir tablo çünkü yanlış bilgi aktarıyorlar ve bu doğru birşey değil.

  35. ferhatkt

    Tesekkurler Serhat Hocam Gercekten cok guzel yakalamissiniz. Sirket olarak Vmware kullancaktik, 4 tane server vardi advanced versiyonu icin 16 cpu + support derken 80.000 dolar lisans parasi. Microsoftun charity lisansindan sirket faydalaniyordu, toplam 2000 dolara isi hallettik. Niye daha fazla para odeyelim? Amerikalilarin bi lafi var “SAVE MONEY LIVE BETTER”

  36. Osman

    Elinize sağlık güzel bir yazı olmuş. Benim sormak istediğim. Hyper-v de sanal sistemlerin görüntü desteği. VMware workstation üzerinde sanal sistemler 32 bit görüntü verebilirken (ESXi üzerinde öylemi bilmiyorum) hyper-v üzerinde 16 bit görüntü alabiliyoruz. Açıkçası önemsenebilecek bir durummu bilemiyorum ama hyper-v üzerinde 32 bit görüntü almanın bir yolu mevcutsa anlatabilirseniz sevinirim.

  37. Serhat AKINCI

    Selam Osman:

    Bildiğin gibi Vmware Workstation ile Hyper-V farklı kulvarlardaki ürünler. Vmware Workstation giriş seviyesi masa üstü sanallaştırma için kullanılıyor ve temelde host işletim sistemi üzerinde çalışan bir uygulamadır.

    Hyper-V tarafındaki VM’ler için resmi color depth limit 16bit’tir ve VMBUS driver bu şekilde tasarlanmıştır. Farklı yöntemler ile bu rakamı arttırmak mümkün olabiliyor ancak tasarım 16bit olduğu için elde edebildiğin değerden %100 performans alman mümkün olmayabilir.

    Yinde de bakmak istersen şurada detaylı konuşulmuştu: http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/31318a82-0505-46eb-ba93-f95acdb3f30a

  38. Osman

    Cevabınız için teşekkür ederim.

  39. Serhat AKINCI

    Bu arada henüz kararlı sürüm release olmadı ancak Windows Server 2008 R2 için gelen SP1 paketi ile Remote FX özelliği geliyor. Bu sayede Remote Desktop oturumlarında “display color depth” 32bit’e kadar kullanılabiliyor (gerçek performans ile). Ayrıca bu özellik Hyper-V üzerindeki VM’lere 3D de dahil olmak üzere gelişmiş grafik yetenekleri kazandıracak.

  40. Selçuk

    Gelişmiş grafik yeteneklerinin sanal işletim sisteminde kullanım alanları nelerdir. Bir sitede aero, silverlight ve video izlemek dışında özelliklerden bahsetmemiş.

  41. Serhat AKINCI

    Selam Selçuk: Kullanım alanları kullanacak firmaya/kişiye göre değişir ama bence en önemli artısı VDI gibi son kullanıcı sistemlerinin sanallaştırılması noktasında ortaya çıkıyor. Colud yada basit bir host üzerinde sanal olarak çalışan son kullanıcı işletim sistemlerinde, 3D desteği sayesinde, çok daha gerçekçi ve çok daha kaliteli bir deneyim sunulabiliyor.

  42. Gazi Erdoğan

    Aradığım bilgileri Türkçe dilinde bulmam ayrı bir lezzet kattı.

Yorum Ekle