Windows Server 2016 ile birlikte Hyper-V Teknolojisinin 6.0 sürümünü kullanmaya başladık. İlk sürüm olan Hyper-V 1.0 ‘dan itibaren birçok özelliği güncelleştirildi ve günümüz teknolojisine uyum sağlamak ve kurumların ihtiyaçları karşılamak için birçok yeni özelliği bünyesine dahil etti. Web Günlüğüm üzerinde #discovery hyper-v 2016 etiketi ile paylaşmaktayım.

Hyper-V Teknolojisini ilk günden beri kullanmaktayım ve danışmanlık hayatım içinde birçok projesini gerçekleştirdim. Bu zaman içinde birçok yanlışlıklarla yapılandırılmış konfigürasyonlar gördüm, zaman-zaman desteğini verebildim ve zaman-zaman ise yanlış yapılandırma sonrasında problemlere karşı çaresiz kaldım.

Bu makale içinde aşağıdaki başlıkları inceleyeceğiz ve daha sağlıklı, daha güvenli bir Hyper-V Platformuna sahip olabilmeniz için neler yapabileceğimizi paylaşacağım.

• • Hypervisor Footprint Boyutları
  • Hyper-V Mimarisi
  • Hypervisor Mimarilerinin Karşılaştırılması
  • Free Hyper-V Server Kurulumu
  • Hyper-V Services Kurulumu (Nano Server)
  • Hyper-V Services Kurulumu (Windows Core Server)

Hypervisor Footprint Boyutları

Windows Server 2008 ile birlikte Windows Core ile tanışmıştık. İlk günden itibaren Microsoft’ un önerisiydi Hyper-V servisinin Windows Core platformu üzerine kurulmasıydı. Şimdi ise Windows Server 2016 ile birlikte Nano Server üzerine kurulmasını önermekte. Ama hiçbir zaman Grafik ara yüzüne sahip bir Windows Sunucu işletim sistemi üzerine kurulmasını önermemiştir.

Grafik ara yüzüne sahip işletim sistemi üzerine kurulmuş Hyper-V Servisi hiçbir zaman için önerilmedi ve hiçbir zaman için Windows Core Platformuna sahip Hyper-V Servisi kadar güvenilmedi, hızlı çalışmadı… Şimdi ise Nano Server en güvenilen ve en hızlı kalesi. Nedeni mi?

Windows Server 2016 Platform Seçimi ve Gereksinimleri bölümü içinde Windows Server işletim sistemini kurabileceğimiz platformlardan, Nano Server ve Windows Core sürümünden, aralarındaki farklardan bahsetmiştik.

İlk inceleme Footprint boyutlarından gelsin. Aşağıda bahsedecek olduğum rakamlar nelerin rakamlarıdır.

Yukarıdaki ekran görüntüsü doğru bir bilgi değildir ama Footprint boyutunu kıyaslayabilmek adına paylaşabileceğim bir ekran görüntüsüdür. Yukarıda resimde bulunan bütün sanal disklerin içinde Hyper-V servisi yüklü durumda ve Hyper-V teknolojisi kullanılmak üzere hazır durumdadır. Sanal disklerin boyutlarını kontrol ederseniz en düşük boyuta sahip durumda bulunan kurulum platformu Nano Server üzerine kurulmuş durumda olan Hyper-V Platformu. Sadece 650 MB gibi bir disk alanı Nano Server üzerine kurulmuş Hyper-V için yeterli durumda. Diğer platformların boyutları resim içinde görülmektedir. Full Grafik arabirimine sahip Hyper-V için boyut bilgisi vermedim ki tahmin edersiniz ki bu boyutlardan çok daha fazlasını isteyecektir.

Footprint; İşletim sisteminin donanım kaynaklarında yani veri depolama alanı üzerinde kaplamış olduğu alandır. Kısaca bahsedecek olduğum rakamlar, kurulum ve yama yüklenmesi sonrasında ilgili işletim sisteminin ulaşmış olduğu disk alanı üzerinde kaplamış olduğu boyuttur.

• Windows Server 2008 Server Core üzerinde çalışan Hyper-V rolü için ihtiyaç Footprint boyutu 2 GB.
• Hyper-V Server için ihtiyaç duyulan Footprint boyutuda 2 GB.
• Windows Server 2008 Server Grafik arabirimi üzerinde çalışan Hyper-V rolü için ihtiyaç duyulan Footprint boyutu ise 10 GB.

Yukarıdaki rakamlara bakıldığı zaman Grafik arabirimine sahip bir Windows işletim sistemi üzerine yüklemiş olduğunuz ve kullanmayacak olduğunuz özelliklerle birlikte toplam boyut 8 GB. Grafik arabirimi ile birlikte İhtiyaç duyulmayan bileşenleri yüklemiş oluyorsunuz, veri depolama alanı üzerinde bu kadar alanı işgal etmiş oluyorsunuz ve Hyper-V sistemini daha yavaş çalıştırmış oluyorsunuz.

VMware tarafında ise bu boyut ise 70 MB. Evet yanlış okumadınız megabayt…

İkinci rakamlar Footprint Yama boyutlarından gelsin.

• Windows Server 2008 Server Core üzerinde çalışan Hyper-V rolü için 26 yama yayınlandı ve toplam yama boyutu 408 MB boyutuna ulaştı.
• Windows Server 2008 Server Grafik arabirimi üzerinde çalışan Hyper-V rolü için 32 yama yayınlandı ve toplam yama boyutu 82 MB boyutuna ulaştı.
• Hyper-V Server için rakamlar Windows Core üzerinde çalışan Hyper-V ile aynıdır.

VMware ESXi 3.5 içim toplam 13 yama yayınlandı ve toplam yama boyutu 2.7 GB boyutunda. Evet yanlış okumadınız, Gigabyte…

Microsoft tarafından yayınlanan bu yamalar 1 Ocak 2008- 30 Haziran 2009 Tarihleri arasındadır. 18 Aylık çalışma sonrasında ulaşılan boyutudur.

VMware tarafından yayınlanan bu yamalar 30 Haziran 2008- 30 Haziran 2009 Tarihleri arasındadır. 12 Aylık çalışma sonrasında ulaşılan boyutudur.

Görülen o ki, VMware Microsoft’ dan daha fazla çalışmış.

70 MB ile başlanılan temel işletim sistemi 1 sene içinde 13 tane yama alıyor ve yamalarla birlikte 2,7.7 GB boyutuna ulaşıyor. Benim anladığım, İşletim sistemi piyasaya sürüldükten sonra yeniden yazılmış gibi. Doğru bir tabir mi bilmiyorum ama VMware’ nin bakış açısı “Kervan yolda düzülür veya düzelir” mantığını gütmeye devam etmekte. Neden mi, buyurun Sunucu Sanallaştırma Platformlarında Bellek Özelliklerinin Karşılaştırılması bölümü içinde bu benzetmeye yakışan bir örnek daha var.

VMware ile birlikte VMware uzmanları ve danışmanları da çalışmalarını sürdürüyor.  Her yamanın yüklenmesi için ayrı bir efor ve yama yüklenmesi sonrası yamanın uygulana bilmesi için ayrı bir hizmet kesintisi.

Detaylar için üç bölümden oluşan Hypervisor Footprint Debate Part 1 UPDATE: Microsoft Hyper-V Server 2008 & VMware ESXi 3.5 makalesini inceleyebilirsiniz.

Microsoft’un dün Windows Core üzerine kurulmasını önerdiği, bugün ise Nano Server üzerine kurulmasını önerdiği Hyper-V nin gerçek boyutları yukarıda bahsetmiş olduğumuz değerlerdedir.

Sizler, Hyper-V Servisini Windows Grafik Ara yüzüne sahip bir Windows işletim sistemi üzerinde çalıştırıyorsanız bu rakamlar zaten sizler için geçerli değildir. Çünkü sizler önerilmeyen ve güvenilmeyen bir platforma sahip olmaktasınız. Hyper-V servisinin kullanmadığı, ihtiyaç duymadığı Sunucu/Storage kaynaklarını gereksiz yere kullandırmış oluyorsunuz. Hyper-V servisinin kullanmadığı, ihtiyaç duymadığı yamaları yüklemekte ve gereksiz yere kesintiler vermiş oluyorsunuz. Hyper-V sahip olduğu mimari gereği zaten yavaş bir Kernel’a sahip iken yanlış platform kurulumu sonrası daha da yavaşlatıyorsunuz. Neden yavaş olduğu konusunda Hyper-V Mimarisi bölümünü incelemenizi bekliyorum.

Geçmişte, VMware tarafından yapılmakta olan footprint karşılaştırmaları genellikle Windows Grafik arabirimine sahip Windows işletim sistemi içindir ve elma ile elmanın kıyaslanmamasıdır. Elma ile elmayı kıyaslamak istiyorsanız Windows Core Platformu üzerine yüklü bulunan veya ücretsiz sürüm olan Hyper-V Server ile kıyaslama yapmanız gerekmektedir.

Güncel Footprint boyutlarını kurulum sonrasında sizler ile paylaşacağım.

Footprint ile ilgili bir benzetme yapacağım ve bu benzetmeyi birçok yerde yapmaktayım. Bir generalsiniz ve elinizin altında üç farklı profilde asker var. Bu üç profildeki askerde aynı yetenekte ve aynı kabiliyete sahip durumda. Aralarındaki tek fark boyutları. Biri büyük, diğeri daha büyük ve bir diğeri daha-daha büyük. Hangisini seçersiniz. Elbette en düşük boyutta olan askeri seçersiniz.

• Büyük olan asker küçük olan askere göre daha fazla besine ihtiyaç duyacak (sunucu ve veri depolama kaynakları için konuşabiliriz)
• Büyük olan asker küçük olan askere göre daha fazla hedef olabilecek (ihtiyaç duyulan yamalar, güvenlik açıkları için konuşabiliriz)

Tercih sizin…

Ben gerçek hayattan bir benzetme yapmak istiyorum. Japonların, II. Dünya Savaşı sırasında savaşmış oldukları Malaya Cephesindeki savaş stratejilerinden örnek vermek istiyorum. Yarımada üzerinde bisikletle donatılmış piyadeler uzun süre besin bulamayacakları için en az besine ihtiyaç duymuş askerlerden seçilmişlerdir.

Hyper-V Mimarisi

Konuşmacı olduğum Windows Server 2016 Teknik Lansmanı sunumu içinde Hyper-V mimarisinden bahsetmiş ve Hyper-V nin en güvenilen sanallaştırma platformu olduğunu söylemiştim. Hypervisor Footprint Boyutları bölümü içinde bu söylemi rakamlar ile doğruladığımı düşünüyorum. Şimdi ise mimariye bakalım.

Hyper-V Teknolojisinin yetenekleri zaman içinde gelişti, yenilendi ve değişen zamana ayak uydurdu. Fakat değişmeyen tek özelliği belki de Hypervisor mimarisi. Hypervisor mimarilerini inceleyeceğiz ama şunu şimdiden belirtmeliyim Hyper-V nin sahip olduğu mimarisi sunucu sanallaştırma teknolojileri arasında en güvenli teknoloji olmuş olsa bile atası olarak adlandıracağımız Virtual Server’ in devamı olarak görüldüğü için bu güvenli sıfatı bir beden büyük gelmekte. Yanlış bilinenleri yanlış yorumladığımız sürece daha güvenli sıfatı Hyper-V ye bir beden büyük gelmeye devam edecek…

Yukarıda görülen Type2 Hypervisor topolojisi içinde Hyper-V nin atası olarak bildiğimiz Virtual Server topolojisini görebilmektesiniz. Katmanlara dikkatli bir şekilde bakarsanız eğer Host hardware katmanı üzerinde Operating System bulunmaktadır. Bu operating system Hypervisor katmanı ile donanım arasında kalan sanallaştırma katmanıdır. Yani Hyper-V teknolojisinin atası olarak adlandırdığımız Virtual Server’ in sahip olduğu mimari.

Bu mimaride Sanallaştırma desteği olan bir donanım ve bu donanım üzerine çalışan bir işletim sistemi ve işletim sistemi üzerine yüklenmiş durumda bulunan bir sanallaştırma katmanı bulunmaktadır. Hyper-V den önce Microsoft’un sunucu sanallaştırma teknolojisinde bulunan teknolojisi Virtual Server bu mimariye sahipti. Bu mimaride en büyük handikap, işletim sisteminde yaşanılacak bir problem sanallaştırma katmanını ve sanallaştırma katmanının misafir etmiş olduğu bütün sanal makinelere etki etmekteydi.

Çok şükür artık bu şekilde çalışan bir sanallaştırma teknolojisi kalmadı…

Hyper-V servisini Windows grafik ara birimi üzerinde çalıştıran kurumlarda bu mimariye sahip değillerdir. Bu nasıl oluyor diye bilirsiniz. Evet, Grafik ara birimi üzerine yüklenen Hyper-V Servisi de Windows işletim sistemi üzerine yüklü durumda değildir.
Şimdi bu durumu açıklayalım.

Yukarıda görmüş olduğunuz topoloji bilinen bir Windows işletim sisteminin mimarisi. En alt katmanda sahip olduğumuz 64 Bit platforma sahip bir donanım ve onun üzerine yüklenmiş olan Windows işletim sistemi bulunmakta.

Windows server 2008’den Windows server 2016’a kadar olan bütün işletim sistemleri Bara-Metal olarak donanım üzerine yüklenmektedir. Yüklemiş olduğumuz bu Windows işletim sistemini Hyper-V Host olarak çalıştırmadığımız sürece topolojimiz bu şekilde çalışacaktır. Donanım ve donanım üzerinde çalışan işletim sistemi. İşletim sistemi arada herhangi bir katman olmadan fiziksel sunucumuzun kaynaklarına erişim sağlayacaktır.

Sahip olduğumuz bu sunucu üzerine Hyper-V Servisini yüklemek istediğimiz zaman işlemler birazcık karışıyor.

Dikkat ettiniz mi bilmiyorum ama bunu hemen hemen her eğitimimde ve proje toplantı/kurulumlarımda dile getiriyor. Windows Server Platformu üzerine Hyper-V servisini kurmaya başladıktan sonra fiziksel sunucu iki sefer yeniden başlatılır. İlk yeniden başlatma işlemi, Windows Kernel’ in yukarıdaki resimde olduğu gibi Parent Partition olarak dönüşümü sırasında gerçekleşmektedir.

İlk resimde gördüğünüz topoloji üzerinde Windows işletim sistemi bara-Metal olarak donanım üzerine yüklü durumda çalışırken Hyper-V Rolünün yüklenmesi ile birlikte bu işletim sistemi Parent Partition olarak dönüşüme uğruyor.

Parent Partition bölümü içinde dikkatli bir şekilde bakarsanız Virtual Machine Services diye bir servis geldi. İşte bu servis Hyper-V rolünün kullanmış olduğu servistir.

Parent Partiton bir Windows Kernel’a sahip durumda ve bu katmanda ise VMBus ve VPS servisleri bulunmaktadır.

Yukarıdaki topolojide görüldüğü gibi VSP (Virtual Service Provider) servisi sadece Parent Partiton içinde çalışmaktadır. Sanal makinelerin fiziksel katmanda bulunan donanım gereksinimlerini karşılamak üzere çalışan servistir. Sanal makinelerimizin üzerinde sanal sürücüler bulunduğu için bu gereksinim Parent Partiton üzerinde tanımlı bulunan sürücüler tarafından VSP servisi tarafından sanal sunuculara aktarılmaktadır.

Windows Platformu, Parent Partition olarak dönüşüm gösterdikten sonra Hyper-V rolü kurulum sihirbazı Windows Hypervisor ‘un kurulumuna başlıyor.

Üçüncü resme dikkatli incelerseniz fark edebileceksiniz Windows Hypervisor direk olarak donanım kaynaklarının üzerine konumlanıyor. İlk kurmuş olduğumuz Windows işletim sistemi ise Parent Partition olarak yerini alıyor. Windows Hypervisor kurulum işlemleri ikici yeniden başlatmanın sonrasında tamamlanmaktadır. Aynı sihirbazda iki işlem birden gerçekleştiriliyor.

Grafik arabirimine sahipseniz eğer sunucu üzerinde görmüş olduğunuz Windows Store, Server Manager gibi bütün grafik arabirimleri Parent Partition üzerinden çalışmaktadır.

Ve son olarak kurmuş olduğunuz Hyper-V Server üzerine sanal makine kurmaya başladığınız zaman bu kurmuş olduğunuz her bir sanal makine Child Partitions olarak adlandırılan bölümde çalışmaya başlayacaktır.

Şimdi Partitionlar içinde bulunan ufak kutular içinde gösterilen diğer servisleri inceleyelim. VSP servisi sadece Parent partiton üzerinde çalışırken Child Partition üzerinde bulunan VSC (Virtual Service Client) ise sadece Child Partition üzerinde bulunan sanal makinelerde çalışmaktadır. Sanal makine üzerinde çalışan bu VSC servisinin muhatap olduğu servis Parent Partition üzerinde bulunan VPS servisidir. Bu iki servis karşılıklı iletişim halindedir. Sanal makinenin ihtiyaç duymuş olduğu kaynak kullanımını/gereksinimi VPS ye bildirmekle ve almakla görevli servistir.

VSC sadece Child Partition üzerinde bulunan sanal makinede. VSP ise sadece Parent Partition üzerinde bulunan Windows Kernel içinde çalışmaktadır. Bu iki servisi bir-biri ile konuşturan ve iletişimi sağlayan servis ise Her İki partiton içinde çalışmakta olan VMBus servisidir.

İlk bölümde şunu demiştim.

“Hyper-V yavaş bir Kernel’a sahip iken yanlış platform kurulumu sonrası daha da yavaşlatıyorsunuz. Neden yavaş olduğu konusunda Hyper-V Mimarisi bölümünü incelemenizi bekliyorum.”

İşte yavaşlık buradan kaynaklı durumda. Ama o kadar yavaş bir mimariye sahip değil. Yeterli kaynak planlaması yapıldıktan sonra VMBus servisi bütün gereksinimleri karşılamak üzere dizayn edilmiştir ve bu servis Channel-based olarak çalışmaktadır. Hypervisor Mimarilerinin Karşılaştırılması bölümünde hız ve güvenlik özelliklerini detaylandıracağız.

Diğer teknik terimler için Hyper-V Architecture makalesini incelemenizi öneririm.

Not: Bazı teknik dokümanlar içinde (yukarıda olduğu gibi) Parent Partiton bazen Root Partition olarak adlandırılmaktadır.

Child Partition içinde görmüş olduğunuz Windows sanal makineleri ve Linux Sanal makineleri Hyper-V tarafından desteklenen sanal makinelerdir. Hyper-V tarafından desteklenmesinin nedeni topoloji içinde yazıldığı gibi Enlightened sanal makine olmalarıdır.

Kelime anlamı, öğretilmiştir. Bu terimin açıklaması Hyper-V tarafından Hyper-V integration Services yüklene bilen ve Sunucu Sanallaştırma platformu içinde çalışabilen Sanal Makineye, Sanal Makine bilgisini aktaran servistir. Çok karışık yazdım galiba, biliyorum ama bir türlü toparlayamadım cümleyi. Kısaca integration services yüklene bilen Windows ve Linux işletim sistemlerine bizler Enlightened sanal makine, aydınlatılmış, öğretilmiş sanal makine demekteyiz. Integration Services yüklenemeyen her bir sanal makine unEnlightened sanal makine olarak adlandırılacak ve topolojide göreceğiniz gibi fiziksel kaynak kullanmak istediği zaman sunucu üzerinde bulunan fiziksel kaynaklara gidecek. Bu sanal makineler üzerinde integration services olmadığı için VMBus ve VSC servisleri çalışmayacaktır. Bu sanal makine tipleri çok sınırlıdır. Sanal Makine Sürümlerinin Yükseltilmesi – integration Services, Vmguest.iso bölümünde bu konuyu detaylandırmıştım.

Hyper-V Servisinin, Windows Grafik Ara birimine sahip durumda olan Windows işletim sistemi üzerine yüklenmesinin önerilmediğini söyledik. Gerek geçmişten gelen alışkanlık gerekse yönetimin bir parça zor olması nedeniyle Windows Core Platformu tercih edilmiyordu. Evet, Grafik arabirimine sahip bir Windows üzerine Hyper-V Rolünü yüklediğiniz zaman sistem çalışıyor ama önerilmiyordu. Sizler bu şekilde yapılandırmış olduğunuz bir sunucu üzerine diğer Windows Rollerini yüklediğiniz zaman, yani Hyper-V ile birlikte diğer Windows Rollerini aynı fiziksel sunucu üzerine yüklediğiniz zaman kurmuş olduğunuz bu platform artık NOT-Supported duruma geliyor. Yani desteklenmiyor. Yani bir problem yaşadığınız zaman Microsoft dan ücretli bile olsa destek alamıyorsunuz.

Yüklemiş olduğunuz diğer rollerin her birisi Parent Partiton olarak adlandırdığımız bölüm içinde çalışıyor. Hyper-V Host üzerinde çalıştırabileceğiniz ve destek alabileceğiniz, kısaca Parent Partition üzerine yükleyebileceğiniz rol, features ve ajanlar aşağıdaki gibidir.

• Failover Clustering servisi
• Remote Desktop Virtulization Host (RD Licensing, RD Gateway, RD Web Access, RD Session Host rolleri desteklenmemektedir)
• System Center Yönetim Ajanları

NOT: Üçüncü firmaların yedekleme ve izleme ajanları için önerilen WMI üzerinden çalışan, ajansız uygulamalardır.

Hypervisor Mimarilerinin Karşılaştırılması

Dünya toz bulutuydu ve ilk insanlar hangi Kernel daha hızlı hangi Kernel daha güvenli bunların araştırmasını yapıyor ve kendi ihtiyaçlarına ve kendi düşüncelerine en yakın Kernel mimarisini kullanmaya karar veriyorlardı.
Bu konu çok eski zamanlardan itibaren konuşulan, araştırılan ve tartışılan konuların başında gelmekte ve internet ansiklopedisi içinde farklı türlerde olmak üzere sayısız doğru/yanlış kaynak bulunmakta. Bu sayısız kaynaklar arasında yer almak üzere bende günlüğüme bir yazı bırakmak istedim.
Sunucu sanallaştırma teknolojisinde iki büyük firma var ve bu iki büyük firma iki farklı Kernel türünü ve kendilerine en uygun olanı kullanmakta. Kimilerine göre bunlardan bir tanesi daha hızlı kimilerine göre ise bir diğer daha güvenli.
Hypervisor Mimarileri bölümünde inceleyecek olduğumuz konu Hypervisor mimarilerinin sahip olduğu Kernel türleri.

Monolithic Kernel ve Microkernel mimarilerinin sahip olduğu topoloji görülmekte. Her iki Kernel mimarisi donanım üzerinde bulunan ilk katmanda çalışmakta. Kernel mimarilerini incelediğimiz zaman Monolithic Kernel in sahip olduğu boyut Microkernel mimarisine göre daha büyük gözükmekte. Bu boyut ilk bölüm içinde bahsetmiş olduğum Hypervisor Footprint Boyutları değildir.
Bu büyüklüğün nedeni Microkernel mimarisi içinde minimal Kernel ismi ile adlandırılan ufak bir işletim sistemi ve bu işletim sistemi içinde

• Temel IPC (Inter-Process Communication)
• Virtual Memory
• Scheduling

Işlemleri gerçekleştirilmektedir.

Monolithic Kernel içinde ise Microkernel mimarisi içindeki işlemlerde gerçekleşmekte ve bu işlemlere ek olarak

• Device Drivers,
• File System
• Memory Manager

Bilgiler de yer almaktadır. Yani biraz daha büyüktür.
Çok eski zamanlardan beri tartışılan, konuşulan bir konu olduğunu hatırlatmak istiyorum. Ekşi sözlük içinde yazılmış olan yorumların bazılarını görebilmektesiniz.

Microkernel için yazılan yorumlara ise buradan ulaşabilirsiniz. Fark ettiğiniz gibi her iki mimari için iyi, kötü ve çirkin benzetmeleri bulunmakta ve tartışmalar, araştırmalar uzun senelerden beri yapılmakta.

 VMware firmasının kullanmış olduğu Monolithic Kernel Mimarisi, Microsoft’un kullanmış olduğu Micro Kernel mimarisinden daha büyük ve beraberinde daha fazla koda sahip (topoloji içinde görülen satırlar) ve doğal olarak daha fazla saldırıya açık durumda.

 Micro Kernel daha az koda sahip ve aklınıza ilk gelecek olan daha hızlı olma ihtimali. Hayır, topolojiye baktığımız zaman Micro Kernel daha az koda sahip olduğu için daha hızlı olma ihtimali bulunmuyor. Nedeni için çalışma prensibini hatırlayalım. Microkernel mimarisi sürekli olarak Inter-Process Communication üzerinden mesajlarla iletişim kurduğu için daha yavaş kalıyor. Sürekli olarak mesaj alıp iletiyor.

Monolithic Kernel Mimarisi içinde Device Direver kodlarını görebiliyorsunuz. Bunun anlamı şu oluyor, VMware firmasının imzalamış olduğu donanıma bağımlısınız. İstemiş olduğunuz herhangi bir donanım ile projenizi gerçekleştiremiyorsunuz. Vmware Host üzerinde çalışacak olan RAID Controller, Network kartları gibi birçok donanımın VMware tarafından imzalanmış olması gerekiyor. Geçmiş zamanda bu liste daha sınırlıydı ve imzalanan donanım ve sürücü sayısı çok azdı. Çok şükür bu günlerde desteklemiş olduğu donanım listesi daha fazla. Ama size önerim projeye başlamadan önce VMware Compatibility Guide sayfasını kontrol etmeniz ve yanlış donanıma sahip olmamanız.

Bu sürücü konusunda biraz derine inelim. VMware Host üzerinde bulunan sürücüler Hypervisor Kernel’i içinde saklanıyor ve üzerinde misafir olarak bulunan sanal makinelere bu sürücüler kullanılıyor. Kernel seviyesinde bir sürücüde oluşabilecek bir problem, bir hata, misafir etmiş olduğu sanal makinelere ne kadar etki edecek. Host’un sahip olduğu Kernel seviyesinde oluşabilecek bir saldırı, bir hata, misafir etmiş olduğu bütün sanal makinelerin bundan etkilenmesine neden olacak mı? Evet, durum bu şekilde.

VMware platformu üzerinde bulunan sanal makineler Kernel seviyesinde ortak sürücüleri kullanmaktadır ve doğal olarak daha hızlı çalışmaktadır. Ama beraberinde bir güvenlik açığını oluşturuyorlar. Bu güvenlik açığı, aynı VMware hostu üzerinde bulunan X isimli sanal makinesi aynı VMware hostu üzerinde bulunan Y isimli bir sanal makine ile kernel seviyesinde ortak kullanılan sürücüleri kullanmakta. Ve bu durum, VMware nin mimarisini bilen kötü amaçlı yazılımcılar için iştah kabartmakta. Düşünsenize ayrı amaçlara hizmet eden iki farklı sanal makineden bir tanesi zehirleniyor ve ortak sürücü kullanıldığı için diğer sanal makine ve sanal makineler bu durumdan etkileniyor.

Microsoft’ un kullanmış olduğu Microkernel Mimari içinde sürücüler yer almaz. Yukarıda paylaşmış olduğum Hyper-V high-level architecture topolojisini incelerseniz eğer sürücülerin sanal makine içinde barındığını görebilmektesiniz. Her sanal makine Hypervisor Kernelin’dan bağımsız bir şekilde kendi sürücülerine sahiptir. Microsoft Hyper-V Hostu üzerinde çalışan bir sanal makine zehirlendiği zaman network katmanında gerekli önlemler alındığı sürece bu zehirlenmeden etkilenmeyecektir.

Bu mimariden kaynaklı olarak Hyprer-V ilk sürümlerinde çok sınırlı işletim sistemlerine destek veriyordu. Nedenlerinden bir tanesi Kernel in sahip olduğu bu özellikten kaynaklıydı. Vmware tarafından sürücü desteği Host ile bağlantılıyken Microsoft Hyper-V tarafından sürücü desteği sanal makine ile bağlantılı. Yani sanal makine seviyesinde sürücüler delege edilmişti.

Bilinen klasik soruyu soralım. Yumurtaları aynı sepete koymak ister misiniz yoksa ayrı-ayrı sepetlerde mi taşımak istersiniz.

Monolithic Kernel mimarisi içinde bütün yumurtalar aynı sepet içinde taşınıyor ve daha hızlı yol kat ediliyor. Monolithic Kernel mimarisinin daha büyük olması ilk başta yavaş olacağı düşünülürken Microkernel mimarisindeki bulunan sistem işleyişi yavaşlatıyor.

Bugüne kadar gerçekleştirilen performans testlerinde Monolithic Kernel mimarisi Micro Kernel mimarisinden her zaman için daha performanslı sonuçlar vermiştir. Bugüne kadar gerçekleştirilen sayısız testlerden bir tanesinin sonucunu yukarıda görebilmektesiniz ve benzerlerini internet üzerinden bulabilirsiniz.

Kernel mimarilerini inceleyecek olduğunuz performans testlerinin sonuçlarına ve tarihlerine dikkatli bakmanızı öneriyorum. Söylemiştim “Dünya toz bulutuydu ve ilk insanlar hangi Kernel daha hızlı hangi Kernel daha güvenli” bunun araştırmasını yapmaktaydı. İnceleyecek olduğunuz testler Layer4 işlemci mimarisi öncesi bir test raporuysa, raporlarda %50 e varan bir fark görebileceksiniz. İnceleyecek olduğunuz test raporları Layer 4 işlemci mimarisi ve sonrasıysa aradaki performans farkının %2 kadar olduğunu görebileceksiniz. Elbette yapılan testlerin içerikleri de önemli.

Microkernel mimarisi Monolithic Kernel mimarisine göre daha güvenli olmuş olsa bile sahip olduğu mimari gereği yavaştı ve bu yavaşlık nedeniyle tercih edilmiyordu. Microkernel mimarisinin bir değişime uğraması, bir dönüşüme uğraması zorunluydu, aksi halde tercih edilmeyecekti.

Jochen Liedtke isimli Alman bilgisayar bilimcisi IPC iletişiminin hızlı olması gerektiğini savunuyor aksi durumda kullanılmayacağını ileri sürüyordu. İlk Microrokernel tabanlı sistemler üzerinde araştırma yaptı ve Mach ve Chorus gibi ilk nesil Microkernel sistemleri üzerindeki temel problemi buldu. Performansa etki eden temel problem önbellek problemiydi. 1993 senesinde Improving IPC by Kernel Design çalışması ile birlikte L4 mimarisinde köklü değişiklikler yapılmasına öncülük etti. Bu çalışması ile birlikte işlemcinin, arabelleklerinde bulunan verilere doğrudan erişebilmesini sağladı ve bu teknoloji sayesinde Microkernel mimarisinin sahip olduğu performans problemlerinin azalmasına neden oldu. Yapmış olduğu çalışmalarda iki binli seneleri işaret etti ve L4 işlemci mimarisi ile birlikte performansın yirmi kat daha hızlı olacağını belirtti.

Nitekim söylediği oldu. Sene 2012’i gösterdiği zaman L4 işlemciler çok hızlandı Windows Server 2012 ve Hyper-V 3.0 in gelişimi ile birlikte performans problemleri ortadan kalktı. Aradaki performans farkı %2 seviyelerine düşmesi ile birlikte VMware firması ESXi ürününde %50 oranında indirime gitti ve sürekli güncelleştirmiş olduğu kampanyalarla rekabeti devam ettirmeyi sürdürmekte.

Bu arada bu bölüm içinde bahsetmiş olduğum Kernel Seviyesinde oluşabilecek saldırıların gerçek dünya da olma olasılığının çok düşük olduğunu savunan bir açıklama ve beraberinde Security considerations and disallowing inter-Virtual Machine Transparent Page Sharing (2080735) güncelleştirmesi geldi. İlgili güvenlik güncelleştirmesi incelendiği zaman bu açığın VMware ile ilgili olmadığının altı çizilmekte. Ve makale içinde yazılan bu özelliğin bu güncelleştirme ile birlikte kapatılacağı ve bundan sonraki sürümlerde bu özelliğin kapalı geleceğinin bilgisi aktarıldı. Bu özelliği kullanmak kullanıcı inisiyatifine bırakıldı.

Bu bölümde paylaşmış olduğum bilgiler Virginia Üniversitesi Bilgisayar Bilimleri Profesörü David Evans ‘ ın L4 and Fast Interprocess Communication ve Microkernels sunumlarından derlenmiştir.

Free Hyper-V Server Kurulumu

Bu bölümde Hyper-V Teknolojisinin ücretsiz sürümü olan Hyper-V Server 2016′ nın kurulumunu, kurulum sonrasında yapmamız gerekli olan temel yapılandırma işlemlerini, IP adresinin verilmesi, Hostname bilgisinin verilmesi, uzaktan yönetim ayarlarının yapılması ve etki alanı içine dahil edilmesi işlemlerini inceleyeceğiz.

Bu video içinde herhangi bir komut kullanmadım. Hyper-V Server’ in sahip olduğu SCConfig yönetim ara yüzünde yönlendirmeleri takip ettim ve temel yönetim işlemlerini yerine getirdim.

Hyper-V Services Kurulumu (Nano Server)

Bu bölümde Nano Server üzerine Hyper-V Servisinin kurulumunu gerçekleştireceğiz. Doğru bir cümle olmadı, çünkü Hyper-V Servisini kurmayacağız, Hyper-V Servisini barındıran bir Nano Server imajı hazırlayacağız.

Hyper-V Servisini barındıran bir Nano Server imajı hazırlayabilmek için Nano Server Image Builder aracını kullanacağım ve kullanmış olduğum sürüm 1.0.78 sürümü ve buradan indirebilirsiniz.

Nano Server Image Builder aracını Windows 10, Windows 8, Windows Server 2012 ve Windows Server 2016 işletim sistemi üzerine yükleyebilir ve ihtiyaç duymuş olduğunuz Nano Server imajlarını hazır duruma getirebilirsiniz. Bu araç piyasaya sürülmeden önce bu aracın yapmış olduğu işlemleri Windows Power Shell aracı ile yapabilmekteydik. Nano Server imaj builder üzerinde bir imaj oluşturduğunuz zaman aracın yapmış olduğu bütün işlemler sizlere bir Power Shell çıktısı olarak verilmekte. Power Shell komutunun grafik ara yüzü olarak düşünebilirsiniz.

Nano server Image Builder yazılımını yukarıda belirtmiş olduğum işletim sistemleri üzerine yükleyebilirsiniz. Aracın çalışabilmesi için yüklenmiş olduğu işletim sistemi üzerine Windows ADK yazılımını Windows PE ve Deployment Tools özellikleri ile birlikte yüklemeniz yeterli. Diğer özelliklerin yüklenmesine gerek bulunmamaktadır. Kullanmış olduğum sürüm Windows ADK for Windows 10, version 1607 sürümü ve buradan indirebilirsiniz.

Nano Server Image Builder ile Hyper-V Servisine sahip Nano Server kurulumu ve ilk temel yapılandırma işlemlerini aşağıdaki video içinde paylaştım.

Nano Server kurulum videosu içinde kullanmış olduğum Powershell komutları aşağıdadır.

Yukarıdaki ilk komutu etki alanı sunucu üzerinde çalıştırdım. Nano sunucu için offline domain join blob file dosyasını oluşturdum. Oluşturulan dosya etki alanı sunum üzerinde C dizini altına oluştu. Bu komut aynı zamanda etki alanı içinde nanosrv00 isminde bir tane bilgisayar hesabı oluşturdu.

Sonrasında nano server imaj builder ile nano server vhdx verisi oluşturdum ve bu vhdx verisini Hyper-V üzerinde oluşturmuş olduğum sanal makineye bağladım ve sanal makineyi çalıştırdım. Sanal makine oluşturmuş olduğum nano serverin işletim sistemi ile açıldı.

Powershell komutu içinde yer alan 10.0.1.103 ip adresi, DHCP sunucum tarafından Nano sunucuma atanan ip adresi. Komutu yukarıdaki gibi düzenledim ve etki alanı sunucum üzerinden Remote Powershell ile bağlantı sağladım. Bağlantı sağladıktan sonra çalıştıracak olduğum bütün Powershell komutları Nano Servera etki edecektir.

Yukarıdaki PS komutu ile nano server üzerinde bulunan network kartlarının ID adresini ve Name bölümünü öğreniyorum. Bu bilgiler ışığında sonraki PS komutlarını yapılandıracağız.

Öğrenmiş olduğum network kart ismi ile yukarıdaki PS komutunu çalıştırıyorum ve Ethernet isimli network kartına ip adresini, subnet maskı ve gateway bilgilerini belirliyorum.

Yukarıdaki komut ile Ethernet isimli network kartının index ID 3 ve bu network kartına DNS IP adresi atamasını gerçekleştiriyorum.

Yukarıdaki komut ile nano serverin windows güvenlik duvarını kapalı duruma getiriyorum.

Yukarıdaki komut ile offline domain join komutu ile nano sunucumu etki alanıma dahil ediyorum.

Yukarıdaki komut ile PS yönetimini kapatıyorum ve nano sunucumu yeniden başlatıyorum. Nano sunucum kullanıma hazır durumda. 

Hyper-V Services Kurulumu (Windows Core Server)

Yukarıdaki komut ile PS yönetimini kapatıyorum ve nano sunucumu yeniden başlatıyorum. Nano s

Yukarıda kullanmış olduğum komutlar Windows komut satırı komutlarıdır ve sunucu üzerinde bulunan ip yapılandırmasını görebilmek için kullanmaktayız. Hyper-V sunucumun ortamda bulunan DHCP sunucusu üzerinden kiralamış olduğu ip bilgilerini görebilmek ve aynı zamanda network kartlarının sahip olduğu kurulum sonrası işletim sistemi tarafından atanmış olan index ID bilgisini ve network kart ismini öğrenebilmek için kullanmaktayım. öğrenmiş olduğum bu bilgiler ile diğer komutları şekillendireceğim. 

Yukarıdaki komutlar ile network kart ID si 4 olan network kartımın ip adresini ve etki alanı içine dahil edebilmem için etki alanı yönetici sunucumun DNS bilgilerini network kartıma tanımladım. Bu kart Hyper-V sunucum üzerinde management network kartıdır.

Windows Core işletim sistemi kurulduktan sonra kurulum sırasında benzersiz olarak verilen ve karmaşık olan ismini anlaşılır bir isim ile değiştirmekteyiz.

Windows Core işletim sistemi temel kurulum sonrasında Windows Firewall aktif olarak gelmektedir ve bu özellik yönetimi bir parça zorlaştırmaktadır. Windows Core üzerinde yönetim modülü sınırlı olduğu için Grafik arabirimine sahip bir işletim sistemi tarafından bunu yapmam gerekecektir. Bu sebep nedeniyle Windows Core işletim sistemimde Windows Firewall’ ı kapatıyorum ve isim değişikliğinin de aktif olabilmesi için sunucumu yeniden başlatıyorum.

Sunucum tekrardan açıldıktan sonra değişen, belirlemiş olduğum IP adresi ve Hostname bilgisi ile açılıyor. Yukarıda paylaşmış olduğum komutlar ile sunucumu etki alanımın üyesi durumuna getiriyorum.

Yukarıdaki komutları etki alanım içinde bulunan, grafik ara yüzüne sahip Windows işletim sistemi üzerinde çalıştırıyorum. Bu komutlar ile uzaktan, Windows grafik ara yüzüne sahip olmayan Windows Core sunucumu uzaktan yönetebilir duruma gelmekteyim.

Windows Core sunucuma bağlantıyı gerçekleştirdikten sonra yukarıdaki komut ile Hyper-V Rolünün yüklemesini gerçekleştiriyorum.

Hyper-V Rolü yüklendikten sonra Windows Core sunucum üzerinde yüklü bulunan rolleri kontrol ediyorum. Yüklü olan roller arasında Hyper-V servisini görmemiz yeterli olacaktır.

Bu makale içinde Microsoft Hyper-V teknolojisinin yüklenebilir işletim sistemleri, platformları ve platformlar arasındaki farkı paylaştık. Bu makale içinde paylaşmadığım iki platform daha vardır. Bunlardan bir tanesi Hyper-V Client sürümüdür. Son kullanıcı işlettim sistemimiz üzerine yüklenebilen bir özelliktir. Daha çok test ortamları ve developer unvanına sahip kişiler tarafından kullanılmaktadır. Bir diğeri ise Windows Grafik arabirimi üzerine yüklenilen versiyonudur ki önerilen bir platform olmadığı için makale içinde paylaşmadım. Zaten bir çok günlük içinde grafik arabirimine sahip bir Windows işletim sistemi üzerine Hyper-V nasıl kurulur sorgusunu arattığınız zaman rahatlıkla bulabileceğiniz bir konudur.

Bir sonraki makale konusu olarak Hyper-V Platformlarının yönetilmesini inceleyeceğiz.