Aslında bu makaleyi çok uzun zaman önce yazmayı planlıyordum. Ama bu makale diğer makaleler gibi step by step kurulum aşamaları ve ekran görüntüleri yerine, teorik bilgiler ve paragraflardan oluşacağı için biraz fazla zaman ayırmak gerekiyordu ve yeni fırsatım oldu. Sunucu sanallaştırma teknolojilerini anlamak için nasıl çalıştıklarını bilmek önemli çünkü işin sırrı mimaride gizli.
Bu makalede Hyper-V mimarisi, sanallaştırmanın arka planda nasıl gerçekleştiği, bu sırada hangi componentlerin görev yaptığı, processlerin hangi sırada yürüdüğü gibi bir takım bilgiler vererek enterprise-level sanallaştırma dediğimiz hypervisor tabanlı bu teknolojinin, diğer host işletim sistemi tabanlı sanallaştırma ürünlerinden farkını göstermek istiyorum.
Windows Server 2008’in bir özelliği olarak release olan Hyper-V teknolojisi, Bare-metal olarak çalışan 64bitlik bir hypervisor’e sahiptir. Yani hypervisor’ün çalışması için herhangi bir aracı gerekmez ve bu tip hypervisor’ler direkt fiziksel donanım üzerinde çalışabilirler (bare-metal installation).
Küçük bir örnek verelim. Virtual Server 2005 ürünü de temelde bir sunucu sanallaştırma teknolojisidir ve bir noktada hypervisor’e sahipti. Ancak bu yapıda Virtual Server 2005 ürününün ve doğal olarak hypervisor’ün çalışabilmesi için zeminde çalışan host işletim sistemine ihtiyaç vardır. Yani Virtual Server 2005’i kurmuş olduğumuz ve fiziksel donanım üzerinde çalışan bir işletim sistemi. Bu nedenle bu yapıdaki hypervisor direkt donanım üzerinde çalışamaz ve aracı olarak donanım üzerinde çalışan host işletim sistemine ihtiyaç duyar. Bu yapıda çalışan diğer sanallaştırma ürünlerinden birkaç örnek vermek gerekirse; Virtual PC 2007, Vmware Workstation, Vmware Server ve VirtualBox gibi ürünlerden söz edebiliriz.
Hyper-V tarafından da kullanılan bare-metal hypervisor’ler ise, daha önce de söylediğimiz gibi direkt olarak donanım üzerinde çalışabilme yeteneğine sahiptir ve herhangi bir host işletim sistemi durumu yoktur.
Az sonra diagram üzerinde yapıyı incelediğiz. Bu noktada fiziksel sistem mimarisi ile başlayıp, host işletim sistemi tabanlı sanallaştırma mimarisi ile devam edip, Hyper-V mimarisine en son değiniyor olacağız. Eminim bu şekilde daha iyi anlaşılacaktır çünkü farklar net olarak ortaya çıkacak.
Aşağıda fiziksel sistem mimarisini görüyorsunuz.
Görmüş olduğunuz gibi mavi kısım yani Hardware bölümü fiziksel kaynakları temsil ediyor. Yani elimizdeki fiziksel server ve üzerindeki donanımlar (processor, ram, disk, NICs ve üzerindeki diğer fiziksel bileşenler).
Hemen üzerindeki yeşil kısım yani Operating Sistem bölümü ise bu fiziksel donanım üzerinde çalışan işletim sistemini temsil ediyor.
Kırmızı bölümler yani Application ise, işletim sisteminin üzerinde çalışan uygulamaları temsil ediyor.
Şöyle düşünebilirsiniz. Elinizde fiziksel bir sunucu var bu Hardware bölümü.
Bu sunucuyu kullanmak için öncelikle üzerinde bir işletim sistemi olmalı. Örneğin bir Windows server 2003 kuruyorsunuz. Bu Operating System bölümü.
Daha sonra bu işletim sistemi üzerinde ihtiyacınız olan uygulamaları çalıştırıyorsunuz. Örneğin bir ERP yazılımı. Bu da Application bölümü.
Yani hepimizin yapısında bulunun klasik bir server mimarisi.
Peki, bu yapıda process’ler nasıl gerçekleşiyor?
Application (yani örneğimizdeki ERP yazılımı) fiziksel kaynaklara bir process göderdiğinde bu öncelikle işletim sistemine iletilir. Daha sonra işletim sistemi kernel’i ve diver’lar aracılığı ile bu process fiziksel donanımlara iletilir. Dönen cevapta aynı yolu izler.
Aşağıda ise host işletim sistemi tabanlı sanallaştırma mimarisini görüyorsunuz.
Yine en alttaki bölüm fiziksel kaynakları temsil ediyor. Fiziksel donanımın hemen üzerinde yine bir işletim sistemi çalışıyor ve bu işletim sisteminin hemen üzerinde bir application yani uygulama var. Bu uygulama Virtual Server 2005.
Dikkat ederseniz buraya kadar olan senaryo bir önceki fiziksel sistem mimarisi ile birebir aynı. Virtual Server 2005 bir sanallaştırma yazılımı olsa da, altında bulunan işletim sistemi üzerinde çalışmak zorundadır. Yani alttaki işletim sistemi için herhangi bir uygulama konumunda.
Bu senaryoda VM yani sanal makineler Virtual Server 2005 üzerinde çalışır. Sanal makinelerin içlerinde ise sanal işletim sistemleri (Guest OS) ve sanal uygulamalar (Guest Application) yer alır. Yani yapının bir kısmı fiziksel sistem mimarisi ile aynı, Virtual Server 2005 üzerindeki yapı ise biraz farklılık gösteriyor.
Peki bu yapıdaki process’ler nasıl gerçekleşir? ve bu yapının dezavantajları nelerdir?
Şöyle bir senaryo üzerinden gidelim. Virtual Server 2005 üzerinde çalışan sanal makinelerden herhangi biri içerisinde hesap makinesini açıyoruz ve 5+5 toplama işlemini yapmak istiyoruz. Bu process için izlenen yol aşağıda yer alıyor.
Kabaca açıklarsak;
Sanal işletim sistemi (Guest OS) içindeki hesap makinesi yazılımı (Guest Application) üzerinde 5+5 için Topla komutunu verdikten sonra, Guest Apllication bu process’i üzerinde çalıştığı işletim sistemine gönderir. Bu işletim sistemi sanaldır ve process doğal olara Guest OS’e gelir. Guest OS bu processi donanıma iletmek ister çünkü işletim sistemlerinin davranış şekli budur. Kendi kernal’ı ve driver’ı ile donanıma iletir ancak zeminde fiziksel bir donanım olmadığı için bu process Virtual Server 2005 tarafından sağlanan sanal donanıma (Virtual Hardware) gelir. Yani artık process Virtual Server 2005’e gelmiştir.
Virtual Server 2005’te bir işletim sistemi üzerinde çalışıyor ve o da bir uygulama konumunda. Bu durumda 5+5 processi yolculuğuna devam eder çünkü sonucun hesaplanması için fiziksel kaynaklara henüz ulaşılmadı. Virtual Server 2005 kendi servisleri üzerinden bu process’i host işletim sistemine iletir. Host işletim sistemi fiziksel donanım üzerinde çalışan son katmadır ve bu process host işletim sisteminin kernel’i üzerinden fiziksel kaynaklara gönderilir ve 5+5 işlemi gerçekleşir.
Cevabın geri dönüşü ise yine aynı adımlara tabidir ve bu sefer tersten başlayarak cevap process’i Guest Application’a kadar gider ve 10 sonucu ulaşır.
Görmüş olduğunuz gibi çok sayıda adım var ve bu kadar çok adım olması, performans kayıpları başta olmak üzere beraberinde birçok dezavantaj getirmektedir.
Artı olarak process’lerin iletim hızı, host işletim sisteminin durumu ile direkt olarak etkilidir. Host işletim sistemi üzerinde meydana gelebilecek herhangi bir problemde (Virüs sorunu, driver sorunları, başka uygulamaların kaynak tüketmesi vs..), üzerinde çalışan bütün sanal makineler aynı anda bu durumdan etkilenecektir.
Yani bir noktada tüm yapı zeminde çalışan Host işletim sistemine bağımlıdır.
Şunun altını çizelim. Bu mimari sadece Virtual Server 2005 için geçerli değil. Örneğin Virtual PC 2007, Vmware Workstation, Vmware Server ve VirtualBox gibi direkt işletim sisteminin içine uygulama olarak kurduğumuz tüm ürünler temelde bu mimari ile çalışırlar. Aynı zamanda host işletim sistemi de Windows dışında bir işletim sistemi olabilir (VPC/VS ürünleri dışında).
Host işletim sistemi tabanlı sanallaştırma ürünleri kabaca bu şekilde çalışmakta.
Gelelim Hyper-V mimarisine.
Hyper-V’nin kullandığı hypervisor’ün en önemli özelliklerini aşağıdaki gibi sıralayabiliriz.
— Hyper-V için kullanılan hypervisor 64bitlik bir koddur ve 32bitlik hypervisor’lere göre daha performanslıdır.
— Enterprise-level sanallaştırma ürünüdür.
— Bare-metal olarak çalışır.
— Çalışan hypervisor micro-kernelized yapıdadır ve rakiplerine göre daha güvenli ve moderndir.
— Micro-kernelized mimarinin özelliği olarak içinde OS Driver barındırmaz, bu nedenle boyutu oldukça küçüktür ve daha rahat çalışır.
— Özel donanım gereksinimi yoktur. 64bitlik donanımsal-sanallaştırma destekleyen bir processor ve Windows Server 2008’in tanıdığı tüm donanımlar ile kullanılabilir.
— Parent ve Child partition’lar arasındaki driver iletişimi için kendine has VSP/VSC’ler ve VMBus protokolünü kullanır.
Şimdi Hyper-V mimarisine grafik üzerinde göz atalım.
Bildiğiniz gibi Hyper-V teknolojisini kullanmaya başlamadan önce fiziksel sistem üzerine Windows Server 2008 x64 STD, ENT yâda Datacenter ürünlerinden birisini kurmamız gerekiyor. Ve ya tamamen ücretsiz olan Hyper-V Server 2008 ürünü ile Hyper-V kullanabiliyoruz.
Bu makalede Windows Server 2008 ile kullanılan Hyper-V üzeriden gidelim.
Fiziksel donanımın üzerine Windows Server 2008 x64 işletim sistemini kurduktan sonra mimari aşağıdaki gibidir. (henüz Hyper-V etkinleştirilmedi)
Yukarıda görüldüğü gibi yine zeminde fiziksel kaynaklar yani donanımlar bulunuyor. Bu donanımları sunucuyu oluşturan processor, ram, NIC, disk ve diğer bileşenler olarak tanımlamıştık. Hemen üzerinde ise kurmuş olduğumuz Windows Server 2008 x64 Os bulunuyor.
Mimari şu haliyle başta konuştuğumuz fiziksel sistem mimarisi ile birebir aynı.
Eğer yapı bu durumdayken Windows Server 2008 x64 Os üzerine bir Virtual Server 2005 kurarsam, mimari Host işletim sistemi tabanlı sanallaştırma mimarisine döner ve ikinci konuştuğumuz mimari halini alır.
Ancak biz Hyper-V mimarisini görmek istiyoruz ve bu nedenle Windows Server 2008 x64 içerisinden Hyper-V’i enable ettiğimizi var sayıyoruz.
Enable işleminden sonraki ilk restartta Hyper-V yani hypervisor yüklenir ve start olur. Bu andan itibaren fiziksel sunucu açıldığında ilk başlayan hypervisor’dür.
Hatırlarsanız Hyper-V’nin kullanmış olduğu hypervisor’ün bare-metal olduğunu ve direkt donanım üzerinde çalıştığını söylemiştik. Bu nedenle hypervisor, işletim sistemlerinden önce başlayabilir. Daha sonra Parent Partition yani ilk kurmuş olduğumuz Windows Server 2008 x64 işletim sistemi ve varsa diğer sanal makineler (Child Partitions) başlar. Dikkat ederseniz ilk kurmuş olduğumuz Windows Server 2008 x64 Os daha sonra başlıyor çünkü artık o da hypervisor üzerinde çalışıyor.
Bu noktadan sonra mimari aşağıdaki gibidir.
İlk göze çarpan; hypervisor katmanının, donanım ile ilk kurmuş olduğumuz Windows Server 2008 x64 OS (Parent Partition) arasına yerleşmiş olduğudur. Yani artık fiziksel donanımın hemen üzerinde hypervisor yani Hyper-V teknolojisi çalışıyor. Artık yaratacağımız her sanal makine hypervisor katmanı üzerinde konumlanacaktır. Bu mimaride sanal makineler Parent Partition üzerinde çalışmaz. Zaten hypervisor devreye girdikten sonra Parent Partition da kısmen sanal makine durumundadır ve o da hypervisor üzerinde çalışmaya başlar.
Yaratlan sanal makinelerden sonra mimarinin son hali aşağıdaki gibi olur.
Şimdi bu mimari yapıyı inceleyelim.
Mimaride birçok terimin geçtiğini fark etmişsinizdir. Öncelikle bu terimler hakkında küçük bilgiler vermek istiyorum.
Windows Hypervisor: Meşhur kodumuz bu J Windows Server 2008 x64 Os üzerinden Hyper-V enable edildikten sonra, hypervisor olarak adlandırılan kod parçası donanım ile ilk kurmuş olduğumuz Windows Server 2008 x64 Os arasına yerleşir ve burada çalışmaya başlar. Temel görevi üzerindeki partition’ların (sanal makineler) yaratılması ve yönetilmesi için Parent Part. Üzerinden gelen process’lere yanıt vermek ve kaynak kullanımlarını sağlamaktır. (Yukarıdaki mimaride Windows Server 2008 x64 olarak temsil ediliyor)
Partition: Diskler üzerindeki partition ile karıştırmayın. Hyper-V yapısındaki partition kavramı biraz daha farklı. Hypervisor üzerinde birbirinden izole bir şekilde çalışan her parça partition olarak adlandırılır. Parent ve Child olmak üzere iki tipi vardır. Yukarıdaki resimde iki farklı partition tipini de görebilirsiniz. Yaratılmış her sanal makine temelde bir partition dır.
Parent Partition: Bazı yerlerde root partition olarak ta geçebilir. Hyper-V rolünü enable ettiğimiz Windows Server 2008 x64 Os, ilk starttan sonra hypervisor’ün üzerinde çalışmaya başlar. Yani bir noktada o da bir sanal makine konumundadır ve Parent Partition adını alır. Temel görevi Child Partition’ların yaratılması ve yönetilmesi işlemleridir. Ayrıca Child Partition’lardan gelen processor ve memory processleri dışındaki donanım erişim isteklerine aracı olur. Hyper-V enable edilmiş her sunucuda sadece bir adet Parent Partition bulunur. Bu da ilk kurmuş olduğumuz Windows Server 2008 x64 işletim sistemidir. Bu işletim sistemi Parent Guest OS yada Parent OS yada Fiziksel İşletim Sistemi olarak ta adlandırılabilir. (Yukarıdaki mimaride Parent Partition olarak temsil ediliyor)
Child Partition: Parent Partition aracılığı ile yaratılan sanal makinelerdir. Teorik olarak Parent Partition gibidir. Yani hypervisor üzerinde çalışan ve birbirinden izole şekilde duran birimler. Ancak Child Partition’lar hypervisor üzerinde yeni partition yaratamazlar yani hypervisor’e müdahale edemezler. Donanımlara direkt olarak erişimleri yoktur. Parent partition aracılığı ile erişirler. Processor ve memory processlerini direkt hypervisor üzerinden iletebilirler. (Yukarıdaki mimaride Child Partition olarak temsil ediliyor)
Virtualization Stack: Mimaride Sanallaştırma Katmanı olarak tanımlanır ve Parent Partition içinde yer alır. VM Worker Process (Sanal makine işlemleri), VM Services (Sanal makine servisleri), WMI Sağlayıcıları, Kullanıcı ara yüzleri, Yönetim servisleri, Emulated Devices gibi hizmetlerin çalıştığı katmandır. (Yukarıdaki mimaride Parent Partition üzerinde Sanallaştırma Katmanı olarak temsil ediliyor)
Virtual Machine: Mimaride Child Partition olarak tanımlanan ve birbirlerinden izole olarak duran her birim içinde çalışan sanal donanımlar topluluğudur. Yani yaratılan her Virtual Machine (sanal makine) temelde bir child partition dır. Sanal makineler kendi sanal donanımlarına sahiptir. Hyper-V mimarisinde yer alan sanal makineler gerçek donanımlara istek gönderebilmek için, Parent Partition Virtualization Stack üzerinde faal olan hizmetler ve az sonra inceleyeceğimiz VSPs ile etkileşim halindedir. (Yukarıdaki mimaride Parent Partition üzerinde 2003,2008 ve sağ tarafındaki iki bölüm ile temsil ediliyor)
Guest OS (Operating System): Sanal işletim sistemidir. Child Partition olarak adlandırdığımız bölüm içindeki Virtual Machine içinde çalışan sanal işletim sistemidir. (Yukarıdaki mimaride Windows Server 2003,2008 ve sağ tarafındaki iki bölüm ile temsil ediliyor)
Guest OS kavramının dışında birde Host OS kavramı vardır ancak bu kavram İşletim Sistemi Tabanlı Sanallaştırma Mimarisine ve ürünlerine aittir (İkinci olarak incelediğimiz Virtual Server 2005 mimarisi gibi). Hatırlayacak olursanız Virtual Server yada Vmware Server gibi ürünler ile gerçekleştirilen sanallaştırma işlemlerinde Guest OS’ler zemindeki işletim sistemi üzerinde çalışıyordu. İşte bu zeminde çalışan işletim sistemi Host OS olarak adlandırılır.
Hyper-V mimarisinde ise Host OS kavramı yoktur çünkü Guest OS’ler direkt hypervisor üzerinde çalışır. Hatırlarsanız Parent Partition’ın da kısmen sanal olarak çalıştığından bahsetmiştik çünkü o da hypervisor üzerinde çalışır. Parent Partition içinde çalışan bu işletim sistemine Parent Guest OS te diyebiliriz.
VSP (Virtual Service Provider): Sadece Parent Partition üzerinde bulunur ve Child Partition’lardan gelen donanım erişim isteklerinin Parent OS üzerindeki gerçek driver’lar ile yapılabilmesini sağlar. Yani bir noktada sanal makinelerin, parent os üzerindeki sürücüleri kullanarak donanımlara erişmesini sağlar. Tabi aynı ayna birden fazla sanal makineden gelen isteklerinde takibi ve yönetiminden sorumludur. Bu iletişimin nasıl gerçekleştiğini daha sonra inceleyeceğiz (Yukarıdaki mimaride Parent Partition üzerinde VCP olarak temsil ediliyor).
VSC (Virtual Service Client/Consumer): Sadece Child Partitionlar yani sanal makineler üzerinde çalışır. Parent OS üzerindeki VSP (Virtual Service Provider) ile iletişim halindedir. VSC, sanal işletim sisteminden gelen bir I/O Request’i VSP’e iletmekle ve cevabı geri almakla görevlidir.
VMBus: Parent Partition üzerindeki VSP ve Child Partition’lar üzerindeki VSC’lerin birbirleri ile konuşurken kullandığı protokoldür. Memory-base olarak çalışır ve çok hızlı bir protokoldür. Aynı zamanda kanal tabanlıdır yani VMBus mantıksal kanalları üzerinden çok sayıdaki sanal makineye ait VSP-VSC iletişimi eş zamanlı olarak gerçekleşebilir. Bununla birlikte güvenlidir ve sanal makineler birbirlerinin iletişim kanallarına erişemezler.
Evet mimarinin en önemli terimleri hakkında kısa bilgiler verdikten sonra, bu mimaride sanal makine i/o request’lerinin nasıl gerçekleştiğine ve VSP/VSC-VMBus componentlerinin görevlerini nasıl yerine getirdiğine bakalım.
Daha öncede söylediğimiz gibi sanal makineler hypervisor altındaki fiziksel Processor ve fiziksel Memory’e yine hypervisor üzerinden erişebilirler. Yani bu erişimlerde VSP/VSC-VMBus üçlüsü kullanılmaz.
Peki, hangi erişimlerde VSP/VSC-VMBus kullanılır? Memory ve Processor dışındaki i/o’lar VSP/VSC-VMBus üzerinden geçer. Örneğin Disk yada NIC i/o request’leri veya Graphics aksiyonları gibi.
Aşağıda direkt olarak hypervisor üzerinden geçen CPU erişimini görüyoruz.
Gördüğünüz gibi Parent Partition ve Child Partition üzerinden gelen CPU erişim istekleri, işletim sistemi kernel’leri tarafından hypervisor katmanına ve direkt olarak fiziksel CPU’a gidiyor. Yapılan request’e dönen sonuç yine aynı yol ile dönüş yapar. Bu durum memory erişimleri için de geçerli.
Aşağıdaki mimari ise VSP/VSC-VMBus üzerinden geçen bir i/o request’i gösteriyor.
Yine bir örnekle incelersek çok daha iyi anlaşılacağından eminim.
Sanal makine yani child partition da çalışan sanal işletim sistemi üzerindeki herhangi bir uygulamanın diske veri yazmak istediğinizi farz edelim.
Sanal uygulama disk write isteğini öncelikle üzerinde çalıştığı sanal işletim sisteminin kernel’ına gönderir. Eğer bu sanal işletim sistemi Hypervisor-aware dediğimiz, yani zeminde hypervisor çalıştığını bilen bir sistem ise (ör: Sanal olarak çalışan Windows Server 2008 yada Windows Server 2003 işletim sistemleri), bu isteği üzerinde bulunan VSC componentine teslim eder. VSC tarafından bu istek Parent Partition üzerindeki VSP’e iletilir ve bu iletişim VMBus protokolü üzerinden gerçekleşir. Parent Partition tarafına gelen istek, Parent OS üzerinde çalışan gerçek driver’lara gönderilir ve bu driver’lar tarafından fiziksel diske veri yazma işlemi gerçekleştirilir. Dönen cevap yine aynı yol ile geri iletilir.
Toparlarsak; Child Partition üzerindeki VSC, Guest OS üzerinden gelen request’i alıp VMBus protokolü ile Parent Partition üzerindeki VSP’e iletiyor. VSP bu request’i, Parent OS üzerindeki gerçek donanım driver’ına teslim ediyor ve işlem tamamlanıyor.
Görmüş olduğunuz gibi makalemizin başında bahsettiğimiz Virtual Server 2005 ve benzer ürünlerin iletişim yapısına göre oldukça kısa bir yol. Ayrıca VMBus protokolü memory-based olduğu için, bu işlemler çok yüksek hızlarla gerçekleşiyor.
Bu yapıyı yani VSP/VSC-VMBus iletişimini ve Hypepr-V mimarisini, aşağıdaki diagram da daha ayrıntılı görebilirsiniz.
VSCs ve Linux VSCs’lerin yanında /ICs olduğunu görüyorsunuz. Bu Integration Services anlamına gelir. Hyper-V üzerinde çalışan Guest OS’lerin bir takım sentetik sanal donanımlardan ve VMBus nimetlerinden yararlanabilmesi için, sanal işletim sistemlerine Integration Services kurulumu yapmamız gerekiyor. ICs, VSC ile bütünleşerek hızlı ve güvenli driver iletişimi gerçekleştiriyor.
Hyper-V mimarisi ve sanal sistemlerin i/o request’leri genel anlamda bu şekilde gerçekleşiyor. Aslında bu mimarinin derinlerinde yatan farklı mekanizmalar var ancak bunları başka makalede incelemeyi düşünüyorum çünkü gerçekten oldukça derin konular.
Hyper-V mimarisini de kabaca incelemiş olduk.
Son olarak bahsetmek istediğim ise micro-kernelized mimari. Hatırlarsanız yazımızın başında Hyper-V için kullanılan hypervisor’ün micro-kernelized mimaride olduğunu söylemiştik. Peki diğer hypervisor mimarileri nedir?
Temelde iki tip mimariden söz edebiliriz. Micro-kernelized ve Monolithic.
Bu iki mimariyi kullanan iki örnek vermek gerekirse;
Micro-kernelized: MS Hyper-V
Monolithic: Vmware ESX
Tabi bu mimarilerin farklarından da çok kısa bahsetmeden bitirmeyelim. Yalnız şunun altını çizmek istiyorum. Mimarileri karşılaştırırken Micro-kernelized yapının ağır basan yanlarının altını çizeceğim çünkü gerçekten önemli özellikler içeriyor. Amacım sözü “Vmware ESX kötüdür, Hyper-V iyidir”e getirmek değil. Sadece son zamanlarda üzerinde sıkça konuşulan bazı noktalara dikkat çekmek, hepsi bu.
Micro-kernelized yapı moduler olarak tanınır ve birbirleri ile mesajlarla iletişim kuran process’lerden oluşur.
Monolothic yapı ise hepsi bir arada mantığı ile doğmuş ve hardware driver’larını dahi kendi içinde barındırın bir mimaridir. Micro-kernelized’a göre daha basit olduğunu söyleyebiliriz, yani karışık değildir ve rahat çalışır.
Peki bu mimarilerin artı ve eksileri neler? Aşağıdaki diagramı inceleyelim.
Sol tarafta Vmware ESX ve Monolithic yapıda çalışan hypervisor’ü, sağ tarafta Hyper-V ve micro-kernelized yapıda çalışan hypervisor’ü görüyoruz.
ESX’in kullandığı hypervisor katmanının çok büyük olduğu hemen dikkat çekiyor çünkü içerisinde driver’lar yer alıyor. Bu normal bir durum çünkü bunun Monolothic mimarinin bir özelliği olduğunu söylemiştik.
Hyper-V’nin kullandığı hypervisor ise çok daha küçük bir katman ve içinde dirver bulunmuyor. Driver’lar işletim sistemlerinin içinde yer alıyor.
Bu küçük ayrıntı aslında çok önemli sonuçlar doğuruyor.
— ESX için kullanılan hypervisor çok daha fazla satır koddan oluşuyor. Bu nedenle atak yapılabilecek yüzey daha geniş, problem çıkma ihtimali daha yüksek. Kod satır sayısının fazla olması, performans tarafında da bir miktar dezavantaj getirecektir.
— Hyper-V tarafındaki hypervisor çok daha az satır koddan oluşuyor.
— ESX tarafında sanal makinelerin kullandığı driver’lar hypervisor içerisinde gömülü olarak geliyor. Bu nedenle ESX Server’lar üzerinde, üretici tarafından duyurulan uyumlu donanımlar kullanılması gibi bir zorunluluk var. Yani her donanımı alıp kullanamıyoruz çünkü hypervisor’ün içinde bulunan driver’lar tarafından tanınan donanımlar seçilmek zorunda. Bu da maliyet açısından hoş olmayan bir durum. Ayrıca hypervisor’ün içinde bulunan bu driver’lar thirdparty kod demek. Bununla birlikte driver’ların hypervisor içinde bulunuyor olması, hypervisor’ün sanal makinelerden gelen driver isteklerine de yanıt vermek durumunda kalmasına neden oluyor. Bu da yine performans tarafında dez avantaj olarak dikkat çekiyor.
— Hyper-V tarafında hypervisor içerisinde driver yok. Bu nedenle thirdparty kod durumu yok. Yani sürücülerden bağımsız bir mimari. Bununla birlikte Windows Server 2008’in tanıdığı bütün donanımları kullanmaya izin veriyor. Hypervisor sadece üzerinde çalışan sanal makinelere odaklanmış durumda çünkü driver tarafına karışmıyor.
Gelelim en önemli ayrıntıya. Güvenlik!
— ESX için kullanılan hypervisor tüm driver’ları içinde tuttuğu için, üzerinde çalışan tüm sanal makineler ortak driver’ları kullanıyor. Yani her sanal makinenin kendi driver’ı yok. Bu şu demek: ESX Server üzerinde çalışan fiziksel ethernet kartının sürücüsü hypervisor içinde duruyor, ESX üzerinde koşan sanal makineler bu ortak sürücüyü kullanıyor. Peki risk? Risk büyük çünkü her sanal makine sürücüye direkt erişebildiği için değişiklik yapma şansı olabilir. Kötü niyetli bir kişi herhangi bir VM üzerinden yeni bir driver import edip, bunu hypervisor üzerine gönderebilir. Bu driver özel olarak tasarlanmış bir network driver’ı olabilir ve hypervisor içine import edilen bu driver ile diğer sanal makinelerin network trafiği dinlenebilir. Ya da özel tasarlanmış bir klavye driver’ı import edilerek basılan tuşlar yakalanabilir gibi ihtimaller söz konusudur.
Ve ya sanal makinelerden birisi üzerinde sürücüye bulaşan bir virüs, bu sürücüyü kullanan diğer sanal makineleri de etkileyebilir gibi çok farklı senaryolar üretmek mümkün. Bunun nedeni ise monolothic yapıdaki hypervisorde sanal makinelerin, driver tarafında hypervisor’e direkt olarak erişebiliyor olmasıdır.
— Hyper-V tarafında ise driver’lar işletim sistemlerinin içinde durduğu için ve temel i/o işlemleri VSP/VSC-VMBus üzerinden gerçekleştiği için, monolithic yapıdaki güvenlik riskleri bu mimaride söz konusu değil. Sanal makinelerin hypervisor’e müdahale etme şansları yoktur. Herhangi bir sanal makinenin başına bir problem geldiğinde, bu sorun sadece onu etkiler.
Mimari için söyleyeceklerim şimdilik bu kadar. Umarım sunucu sanallaştırma mimarileri ve hypervisor tipleri arasındaki farklar kafanızda şekillenmiştir.
Hepinize iyi çalışmalar dilerim.
Serhat AKINCI – IT Professional
