Posts Tagged ‘Fault Tolarance’

Windows Server 2012 R2 Hyper-V vs Vmware 5.5 – Yüksek Erişilebilirlik ve Felaket Kurtarma Senaryoları

Written by Ertan Gülen. Posted in Sanallaştırma

Bu yazı dizisinde olabildiğince tarafsız duruş ile özellik karşılaştıracağız desek de üreticilerin sunduğu onlarca teknolojiden hangisini ele alırsanız ona göre farklı bir tarafı öne çıkarmış olabiliyorsunuz. Yine de en çok soru gelen yada en ilgi çeken veya ihtiyaç olduğu düşünülen başlıklar ile hareket etmek sağlıklı olacaktır.

6 başlık altında toplanacak olan bu seride sırası ile;

  1. Lisanslama
  2. Sanallaştırmanın Sınırları
  3. Yüksek Erişilebilirlik ve Felaket Kurtarma Senaryoları
  4. Veri Depolama
  5. Network
  6. Sanal Makine Desteği

başlıklarınin inceleneceğini aktarmıştır Giriş yazımızda. Şimdi ise sıradaki başlığımız ile devam edelim

3. Yüksek Erişilebilirlik ve Felaket Kurtarma Senaryoları

Günümüz IT yapılarında hizmetlerin devamlılığı ve tabiki bunun yanında olağan üstü durumlara hazırlıklı olma en önemli konulardan biri halini almaya başladı. Teybe yedek alışkanlığından vazgeçilmesi, sanallaştırmanın brden fazla sunucu üzerinde çalışması, Exchange ve SQL gibi kiritk uygulamaların birden çok sunucu ile hizmet vermesi gibi bir çok örnek sayabiliriz.

Buradan konu “Bulut Bilişim” kavramına da kayabilir ki Azure ile ilgili düzenlemeye başladığım yazı dizisinde bolca bahsediliyor bu senaryolardan. Bulut ile ne alakası var derseniz de sizi yine o çok sevdiğiniz arama motorlarında Office 365 ve Microsoft Azure gibi teknolojileri araştırmaya davet edebilirim.

Fakat konumuz şuan bulut bilişimden ziyade on-premise yani fiziksel binalarımız içinde çalışan altyapılar. Hal böyle olunca da elle tutulur gözle görülür daha geleneksel sistemlerden bahsetmek gerekiyor. Bu sistemin sağlık durumundan ve erişilebilirlik seviyesinden hatta felaket halinde ne gibi çözümler üretildiğinden.

Yüksek erişilebilirlik denince bazı yerlerde bol 9’lu oranlar görebilirsiniz kısaca bu oranları açıklayıp ne demek istendiğini anlayalım

 

Erişilebilirlik % Yıl içinde Hizmet Kesintisi Ay içinde Hizmet Kesintisi Hafta içinde Hizmet Kesintisi
90%  (tek dokuz) 36,5 gün 72 saat 16,8 saat
95% 18,25 gün 36 saat 8,4 saat
97% 10,96 gün 21,6 saat 5,04 saat
98% 7,30 gün 14,4 saat 3,36 saat
99% (çift dokuz) 3,65 gün 7,20 saat 1,68 saat
99,9% (üç dokuz) 8,76 saat 43,8 dakika 10,1 dakika
99,95% 4,38 saat 21,56 dakika 5,04 dakika
99,99% (dört dokuz) 52,56 dakika 4,32 dakika 1,01 dakika
99,999% (beş dokuz) 5,26 dakika 25,9 saniye 6,05 saniye
99,9999% (altı dokuz) 31,5 saniye 2,59 saniye 0,605 saniye

Kabaca özetlemek gerekir ise tabloyu ne kadar 9 o kadar az sistem kesintisi yani bir yıl icinde sisteminiz %99,95 erişilebilir ise kesintiniz toplam 4,38 saattir. Bunun mesai saati dışına denk gelmesini de hesapladığınızda bence mesai içinde en fazla 2 saat kesinti yaşanır :) Bu arada sistem ayakta ama erişilemez olduğu durumlarda vardır ki genelde “not work” denen bileşenlerden kaynaklanır ;) (Not work= çalışmayan network)

Mevcut altyapımızda çalışan sistemlerimiz bir bakıma pamuk ipliğine bağlıdır zira donanımın yedeklenmesi, networkün, elektriğin ve uygulamaların yedeklenmesi gerekir ki bol 9’lu erişilebilirlik sağlayalım. Ne kadar yedekli yapı o kadar maliyet demek diğer biryandan da.

İşte bu para mı erişilebilirlik mi ikilemi içinde sanallaştırma çözümleri yeri geldiğinde donanımın yeri geldiğinde yazılımın hatalarına karşı bizlere koruyabilir hem de ilk başlarda bahsettiğimiz avantajlı sahip olma imkanları ile. Daha az donanım maliyeti daha sıkısık ama duzenli ve yonetilen bir sanallastırma yapısı ile maliyeti düşürdükçe erişilebilirliği arttırma şansına sahip oluyoruz.

Üreticilerin Yüksek Erişilebilirlik adına sundukları teknolojileri kısaca neden ihtiyacımız var paragraflarından sonra aşağıdaki tabloda bulabilirsiniz. Sonrasında da yine öne çıkan başlıkları incelememiz gerekir.

 

Özellik Microsoft Vmware Notlar
Canlı Aktarım Live Migration vMotion  
Eş Zamanlı Canlı Aktarım Sınırsız Kısmen 1 Gbps network üzerinde 4 sanal makine
Ortak Depolama Alanı Olmaksızın Canlı Aktarım Shared Nothing Live Migration Enhanced vMotion  
Canlı Aktarım Esnasında Sıkıstırma Compressed Live Migration Yok  
RDMA Desteği ile Canlı Aktarım SMB-Direct Live Migration Yok Bu özelliğe sahip kartlar ile 10 kata kadar daha hızlı sanal makine aktarımı
Kümeleme İçindeki Sanal Makinelerin Aktarımı Var Yok Cluster içindeki sanal makine de taşınabilir olmalı.
Yüksek Erişilebilirlik Önceliklendirme Var Var  
Yüksek Erişilebilirlik Kuralları Var Var  
Sanal Makine İçi Servis İzleme Var – tüm servisler Var (Apache, IIS, SQL, Sharepoint gibi kısıtlı hizmetler)  
Sanal Makineler için Yük Dengeleme Dynamic Optimization DRS  
Sanal Makineler İçin Güç Dengeleme Power Optimization DRS  
Asenkron Replikasyon Hyper-V Replica vSphere Replication 30 saniye ile 15 Dakika bir olabilir mi
Sanal Makine İçin 3. Kopya Oluşturma Hyper-V Replica Yok  
Küme Üzerinde Toplu Güncelleme Cluster Aware update Kısmen  

Geldik yine can alıcı yorum kısmına; benim için burada önemli olan ve fark yaratan ana özellik Hyper-V Replica, devamında ise Servislerin izlenmesi ve Cluster Aware Update kritik diyebileceğimiz noktalar.

Hyper-V replica Windows Server 2012 ile gelen bir özellikti ve kabaca bir sanal makinenin network üzerinden 5 dakikada bir farklı bir Hyper-V sunucusu üzerine kopyalanması anlamına geliyordu. Sanal makinelerin küme içinde olması yada hedef Hyper-V sunucunun bir küme üyesi olması ise hiç önemli değildi. Network üzerinden yapılan aktarım hem sıkıstırma teknolojisi barındırıyor hem de sadece değişen datayı aktarıyordu yani işin kısa ve türkçe hali: ADSL ile dahi çalışabiliyordu. Saatte ortalama 200 MB yeni data üreten bir makine 1 mbps network ile 20 dakika gibi bir sürede kopyalanabiliyordu.

Windows Server 2012 R2 ile ise durum daha da can alıcı hale geldi: Artık 3 kopya barındırabiliyor ve süreleri 30 saniye, 5 dakika yada 15 dakika olarak belirleyebiliyoruz. Yine sıkıstırma yine değişen datanın kopyalanması mevcut. Düşünün ki aynı kampüs içinde replikasyon yapıyorsunuz fiziksel sorunlara yada binada oluşabilecek sorunlara karşı, aradaki network bağlantısı gayet hızlı mesela 300 mbps. Böyel bir durumda 30 saniye bir kopya almanın inanılmaz cazibesinin farkında mısınız :) Bu kopyayı da isterseniz Olaganüstü Durum Merkezi olarak kullanmakta olduğunuz başka şehir yada ülkedeki datacenterınıza da ister 5 dakika ister 15 dakikada bir kopyalamaya devam edin.

Failover Cluster özelliği ile zaten 64 sunuculu küme oluşturup bir sanal makinenin mevcut sunucusundan 63 farklı sunucuya taşınmasına imkan sağlayabilirsiniz. Bir de bu erişilebilirliği felaket önleme adına 30 saniyede bir yan binaya oradan da 5 dakikada bir diğer sehirdeki Hyper-V sunucuya kopyalayın. Güzel ama pahalı bir çözüm gibi duruyor sanırım fakat unutmamak gerekir, Hyper-V ve bu özellikleri aslında Windows Server lisansı içinde geken tıpkı DNS server rolü gibi bir rol yani: Ücretsiz!

64 sunucu ile kurulan bir kümeden bahsederken bu yapıyı güncel tutmanın zorluklarından da bahsetmeden geçmek olmaz. Normal şartlarda Vmware olsun Microsoft olsun kim olursa olsun her üretici belirli dönemlerde güvenlik yamaları yayınlar ki yayınlanma sıklığı üç aşağı beş yukarı bellidir (kaynak kodu çaldıracak kadar basiretsiz bir firma değilseniz). Bu dönemlerde sunucuların güncellenmesi genellikle yüksek erişilebilir yapıda oldukları için kolaydır. Mesela vSphere ortamında vMotion ile sanalları taşır ESXi sunucuyu boşa çıkarır günceller yükü geri alır ve sırası ile devam edersiniz. Yada bir Windows Server Lisansı daha alır ve Update Management Server kurarsınız ki o da 5 host ve 50 VM içindir. Üstüne çıkarsanız SQL de gerekir.

Ben güncelleme yapmıyorum diyenleri duyar gibiyim ve sizleri sevdiğimi belirtmek isterim zira elimdeki kaynak kodu bir gün kullanılabilir hale getirirsem daha da yakından sevmek isterim sizi :)

Bu durum hep aynı rutin tekrarlar şeklinde gerçekleşir her ne kadar 3 ayda 1 yapıyorum deseniz de, peki bu durumu otomatize edecek bir sürece sahip olsanız daha iyi olmaz mıydı? Bu soruyu sorarken cevabını da biliyordum ve paylaşmak istedim : Cluster Aware Update. Microsofr Failover Cluster üzerinden tüm sunucularınızı kontrollü ve otomatik bir güncelleme mekanizması sunuyor sizlere. Sırası ile yapmanız gereken adımları kendi gerçekleştiriyor, live migration, host maintaince mode update/restart tekrar live migration gibi. Updateleri ister SCCM’den ister WSUS’dan alsın 64 sunucuyu da otomatize bir şekilde güncellesin.

3. Bölüm Özeti:

Sayılarla uğraşarak kolay hesap yapabileceğimizden bahsetmiştim ya, işte 64 sunuculu bir küme aynı anda sınırsız sanal makine taşıma ve 15 dakika yerine 30 saniyede bir replikasyon aslında tercih yaparken nasıl yönlenebileceğimizi bize anlatıyor sanırım. Hani puanlama yapıp bir tarafa kocaman bir 0 (yazıyla sıfır) vermek geçiyor içimden.

Windows Server 2012 R2 Hyper-V vs Vmware 5.5 – Sanallaştırmanın Sınırları

Written by Ertan Gülen. Posted in Sanallaştırma

Bu yazı dizisinde olabildiğince tarafsız duruş ile özellik karşılaştıracağız desek de üreticilerin sunduğu onlarca teknolojiden hangisini ele alırsanız ona göre farklı bir tarafı öne çıkarmış olabiliyorsunuz. Yine de en çok soru gelen yada en ilgi çeken veya ihtiyaç olduğu düşünülen başlıklar ile hareket etmek sağlıklı olacaktır.

6 başlık altında toplanacak olan bu seride sırası ile;

  1. Lisanslama
  2. Sanallaştırmanın Sınırları
  3. Yüksek Erişilebilirlik ve Felaket Kurtarma Senaryoları
  4. Veri Depolama
  5. Network
  6. Sanal Makine Desteği

başlıklarınin inceleneceğini aktarmıştır Giriş yazımızda. Şimdi ise sıradaki başlığımız ile devam edelim.

2. Sanallaştırmanın Sınırları

Çok fantastik bir başlık gibi gelse de sınırlarımızı bilip hareket etmek yönettiğimiz altyapılar için kritik öneme sahiptir.

Bu başlık altında sanallaştırma platformalarında sayılar ile karşılaştırma yapacağız, kac vcpu, kac tb ram, kac host, kaç sanal vb..

En uzağa taş atmak tabirinin belki de can alıcı bir şekilde göründüğü karşılaştırma başlığıdır sayılar ve sınırlar. Üreticiler arasında fark zamanla kapanmış ve hatta ters yönde büyümektedir bugünlerde. Windows Server 2008 ve 2008 R2 varken Microsoft Vmware çözümleri ile neredeyse hiçbir başlıkta bu tarz bir karşılaştırmaya giremiyordu fakat Windows Server 2012 lansmanı ve Hyper-V v3 diye adlandırdığımız (Microsoft bu şekilde adlandırmasa da) sürüm sonrasında bu tablolar görülmeye değer bir hal aldı.

Neden sayılar önemlidir? Gerçekten bahsi geçen kaynaklara ihtiyacımız var mıdır?

Bu soruyu cok uzun uzadıya tartısabiliriz fakat sadece Exchange Server ve SQL Server’ın güncel sürümlerinde ortaya çıkan minimum kaynak ihtiyaçlarını bile analiz ettiğimizde artık 4 core CPU’lar yada 8 GB Ram’lerin yetmediğini görebiliyoruz. Windows Server 2008 R2 üzerinde kurulumu gerçekleştirilmiş bir Exchange Server 2007 yapısını firma ihtiyaçları doğrultusunda genişletmek ve yükseltmek istediğimizde artık 2008 R2’nin sanallaştırma sınırlarının bize yetmediğini görebiliriz. Dag yapısı içinde bir Exchange 2010/2013 yapısı kurmayı düşündüğümüzde Mailbox sunucuları 4 core ile calıstırmak pek de performans anlamında karlı bir durum oluşturmayacaktır. Keza SQL Server icin de aynı sorunlar belirmektedir. SQL 2005 yada SQL 2008 kurup 64 GB ram ile geçinebilirsiniz fakat artık SAP, Sharepoint gibi iş yüklerinde yada System Center Service Manager gibi uygulamalarda ihtiyaç duyulan SQL Server’lar ne 4 core ne de 64 GB Ram gibi sınırlar içinde kalmak istememektedir. SQL ile Datamining/BI çözümleri hayata geçirildiğinde de aynı sorun ile karşılaşmamız kaçınılmazdır.

İşte bu gibi sebeplerle artık sanallaştırma platformlarında kullanılabilir kaynak miktarlarını hayati öneme sahip olmaya başladı. Aşağıdaki tabloda görebileceğiniz özellik karşılaştırmaları üreticilerin sınırlarını gözler önüne sermektedir. Unutulmamalıdır ki bu karşılaştırmayı Hyper-V’nin 2 önceki sürümlerinde yapamazdık şimdi ise Vmware ne zaman yetişir diye tartışıyoruz.

 

Özellik Microsoft Vmware Notlar
Fiziksel Sunucu Başına Mantıksal İşlemci 320 320 vSphere 5.5. ile yeni geldi
Fiziksel Sunucu Başına Bellek Miktarı 4 TB 4 TB vSphere 5.5. ile yeni geldi
Fiziksel Sunucu Başına Aktif Sanal Makine Sayısı 1024 512  
Sanal Makine Başına Cpu Miktarı 64 64 Vmware FT ile 1 vCpu ve 64 GB Ram
Sanal Makine Başına Bellek  Miktarı 1 TB 1 TB
Dinamik Bellek Yönetimi Dynamic Memory Memory Ballooning, Memory Overcommit Microsoft Cluster yapılandırılmış sanal makinelerde Memory Overcommit çalışmaz
Guest Numa Desteği Var Var Çok sayıda fiziksel Cpu olan ortamlarda çok çekirdekli sanal makine oluşturulduğunda kritik performans arttırabilir
Küme Başına Fiziksel Sunucu Sayısı 64 32  
Küme Başına Sanal Makine Sayısı 8000 4000  
Ekran Kartı Sanallaştırma (GPU) RemoteFX Virtual GPU  
USB Sanallaştırma Kısmen  USB Pass Through Remote Desktop, Windows To Go uyumlu USBler ve Enhanced Session Mode sayesinde yapılabiliyor

 

Dikkat çekici birkaç noktayı ayrıca tartışmak da fayda görüyorum.

Bir küme içerisinde (cluster da denir) 64 sunucu kime gerekir ki cümleleri çokça duyduğumuz cümleler ancak şuan hosting hizmeti vermeden 28 sunucu ile çalışan firmalar biliyoruz (banka değil) kaldı ki hosting firmalarını siz düşünün. Yada bir küme içerisinde 8000 sanal makine çok diyenler için: Tribula.com’un yayınlandığı sunucu tek bir host uzerindeki 120 sanal makineden sadece biri. Gerçek üretim ortamlarını konuşmuyoruz bile çok basit örnekler ile ilerliyoruz.

Gelelim diğer iki konuya ki biraz daha son kullanıcı işiymiş gibi hissedilen noktalar; EKran kartı sanallaştırma nedir neden gerekir gibi sorular için VDI nedir ne işe yarar gibi bir arama öneriyorum favori arama motorunuzda. USB kısmına gelince ben savunmaya geçeceğim, ne gerek var canım sanal makinede USB’ye. Ama kazın ayağı böyle değil işte. Çok ciddi kullanım alanı olan bazı muhasebe vb uygulamalarında USB token’lar ile kimlik doğrulama yada lisans kontrolü yapılabiliyor yine aynı şekilde bazı uygulamalarda harici cihazlar (usb’den ne çalışırsa düşünün bakalım) da gerekebiliyor.

Hyper-V tarafında çözüm için bazı taklalar atsak da Windows Server 2012 R2 çıkışı ile birlikte hayatımızı kolaylaştıracak yenilikler mevcut. İlki default bir özellik olan ancak disable durumda gelen Enhanced Session Özelliği: Sanal makinenizde network ayarları vb ile bağlantısı olmadan direk Hyper-V Integration Components sayesinde devreye giren bu özellik ile uzak masaüstü deneyimi yaşayabiliyorsunuz. Çok düz mantık hareket ederek uzak masaüstü bağlantısında olduğu gibi USB’leri yazıcıları ve diskleri bağlandığınız ortama aktarabiliyorsunuz. Bu arada kopyala- yapıştır ile dosya transferi de artık mümkün.

Konuşmam gerektiğine inandığım son nokta ise bellek yönetimi: İki üreticinin neredeyse tasarımsal olarak ortak noktası olmadığı icin de bu alanda da pek kesisme sağlanamıyor. Hyper-V bellek yönetimini tek bir teknoloji ile çözerken Vmware, vSphere içerisinde türlü isimler ile türlü taklalar atıyor. Kimine göre o iyi kimine göre bu fakat işin biraz daha derin teknik analizleri yapılmalı bu noktada (hatta CPU kullanımında da aynı şekilde). Eğer daha derin bir araştırma isterseniz http://tribu.la/bj adresinden ulaşabileceğiniz bir yazı mevcut.

İkinci Bölüm Özeti:

Sayılar ile konuşmak her zaman daha kolaydır. Büyük olan döver normalde. ama iş teknoloji ve sayı ilişkisine gelince bazen farklılık gösterebilir. (Vmware FT’nin 1 vcpu ve 64 GB ram ile calısması gibi ;) ) Mevcut özellikler arasında öne çıkanları yukarıdaki paragraflarda konuşmus olsak da teknoloji konusunda tümden gelim taraftarıyımdır yani tek tek karşılaştırma yerine genel baktığınızda sizin için hayati olan özellikleri size kısıtsız ve koşulsuz sunanı tercih etmeliyiz.

Cluster yapıldığı için bellek yönetemiyorsa clusterdan mı vazgeçeceğim kaynakların doğru kullanmasından mı sorusu ile karşı karşıya kalırsanız tercihinizi bizimle de paylaşın lütfen :)

vSphere 5.0 üzerinde ESXi 5.0 Çalıştırma

Written by Ertan Gülen. Posted in vSphere

Bilindiği gibi 24 Ağustos itibari ile vmware firmasının sanallaştırma platformu olan vSphere 5.0 ürün ailesi kullanıma sundu. Lisanslama tarafındaki yenilikler ve daha birçok özelliği ile hakkında bolca konuşulacak gibi dursa da, spekülasyonlardan ziyade test ortamlarında işimize yarayacak ne gibi güzellikleri var kısmı sanırım bizler açısından şuan için daha önemli.

Test ortamlarında çalışanların en büyük derdi cross platform oluşturma yada birden çok sanallaştırma platformunu paralel çalıştırmabilme zorluğudur. (Şahsen benim böyle) ESX 4.x ile birlikte kendi içerisinde kendisini sanallaştırıp çalıştırabiliyorduk ancak bu çalışma sadece 32 bit mimari çerçevesinde kalıyordu yani 64 bit işletim sistemleri desteklenmiyordu. Çok ufak testler için kullanılabilir bir ortamdı yine de. Bunun yanında yine vmware firmasına ait olan vmware workstation da test ortamları için bir alternatif oluyordu. Fakat ne olursa olsun bare metal virtualization ile karşılaştıralamayacak kadar düşük performanslı bir yapıya sahip olunabiliyordu ancak.

ESXi 5.0’n duyurulması ile birlikte bir takım yeniliklerden söz edilirken kendi adıma en çok sevindiğim özellik 64 bit mimarinin de sanallaştırılıp tekrar sanal ortama izin vermesiydi. Yani kısaca Hyper-V ve ESX artık 64 bit ile kurulup kendi içlerinde de 64 bit işletim sistemi desteği sunabiliyor. Bu durumu abartıp ESXi içinde ESXi içinde ESXi a kadar gidilebiliyor ki tek engeliniz ciddi performans kayıpları.
 
Temiz bir kurulumu yapılmış olan ESXi 5.0 hostumuzda 64 bit sanallaştırma mimarilerinin nasıl çalıştırılabileceğine dair adımları kısaca açıklayalım:
 
Öncelikle hostumuz üzerinde bazı komutlar çalıştırmamız gerekiyor bu sebeple, defaultta kapalı gelen SSH özelliğini devreye alarak işe başlıyoruz.
 
SSH’ın aktif edilebilmesi için Configuration tabından Security Profile sekmesine geliyoruz.
 
 
Gördüğünüz gibi Services altında SSH görünüyor ancak aktif olup olmadığını görebilmek ve değilse aktif etmek için Properties seçeneği ile SSH ayarlarına geçiyoruz. Stopped durumda gelen servisi çalıştırmak için SSH seçili iken Options tabından servisin nasıl başlayacağını seçip Start duruma getiriyoruz.
 
 
Servis başladıktan sonra ise yapacağımız gayet basit: Putty yada benzeri favori uzak erişim programınız ile SSH üzerinden ESXi hostumuza bağlanıyoruz. Sadece Ip ve port girilerek bağlantı sağlanıyor.
 
 
Bağlantı kurulduğu anda ise bizden kullanıcı adı ve sifre bilgilerini isteyecektir. Dikkat sifreyi yazarken karakterleri göremezseniz eğer sorun yoktur güvenlik amacı ile gizlidir kaç karakter girildiği bilgisi de.
 
 
Bağlantı sağlandıktan sonra host üzerindeki konfigurasyon dosyasının içeriğini görüntüleyelim.
Bunun için gerekli komut:
 
Cat /etc/vmware/config
 
 
Bu döküme benzer bir içerik ile karşılaştıysanız sorun yoktur. Şimdi ise host üzerinde sanal makinenin sanal donanım kullanmadığını düşüneceği ilgili parametreyi girelim.
 
Echo ‘vhv.allow = “TRUE”’ >> /etc/vmware/config
 
 
Komutu girdikten sonraki config dosya çıktısı aşağıdaki gibi olmalıdır, eğer bu dökümü görebiliyorsanız sorun yoktur devam edebiliriz.
 
 
Şuana kadar çalıştırdığımız komutlar ile birlikte ESXi 5.0 hostumuz kendi içerisinde kurulacak sanal makinelerin de sanallaştırma yapmasına imkan sağlar duruma geldi.
Bundan sonraki adımlarda ise Sanallaştırma platformu olacak sanal makinelerin ayarlarına bakacağız. Bu ayarları yapımıza kurmayı planladığımız tüm sanal Hyper-V ve ESXi makineleri için tekrarlamalıyız (Citrix desteğini henüz denemedim yorum yapamıyorum vakit olunca Red Hat, Oracle VM ve Citrix deneyeceğim).
 
Kurulacak sanal makineleri oluştururken standart herhangi bir işletim sistemi seçerek kurabilirsiniz. Örneğin Windows Server 2008 R2 olabilir. Önemli olan kısım sanal makine oluşturulması bittikten sonra başlıyor. Sanal makineyi oluşturduğumuzda power on diyerek başlatmadan önce birkaç ufak ayar gerekiyor.
 
İlk adım olarak Sanal makine içeriside çalışacak işletim sistemini düzenleyelim. Bu değişiklik için yeni oluşturulan sanal makineye sağ tıklayıp edit settings diyoruz. Gelen ekranda ise genel sanal makine donanımı ile pek bir işimiz olmayacak. Bizim işimiz Optios tabında:
 
 
 
 
 
İlk düzenlecek olan ayar Guest Operation System yani sanal makinenin içinde çalışan işletim sistemi versiyonu. Bugüne kadar genel bir yargı olarak burada seçilen işletim sistemi sadece işletim sistemi kurulumu bitince kurulması gereken vmware tools’un uygun modelini seçmek için belirlenir denirdi ancak artık sanallaştırma platformlarını da sanal makine olarak kurabildiğine göre sonrasında detaylı bir teknik analizini yapacağım işletim sistemi versiyonlarının işlemci ve genel donanım kullanımına yönelik etkileri olduğunu biliyoruz. Sanal içinde sanallaştırma yapacaksak kurulu işletim sistemini Other seçeneği altından Vmware ESXi 5.x olarak secmeliyiz. (Hyper-V kurulacak 2008 R2 için de).
Burada bir not düşmeliyiz ki eğer Server 2008 R2 bu değişiklik sonrasında başlamıyorsa öncelikle 2008 R2 kurulumu yapın sonra bu ayarları değiştirin ki kurulum kısmında uyumsuz donanım sorunları cıkmasın.
 
Guest Operation System sekmelerini incelerken eğer karşınıza aşağıdaki gibi bir ekran gelirse şaşırmayın :) Ufak bir süpriz diyelim buna ve kısaca açıklayalım: Microsoft; Windows 8 (hem server hem client) işletim sistemlerinin Windows 7 ve Server 2008 R2’den farklı bir donanım gereksinimi olmayacağını açıkladığı için şimdiden destek veriliyor. (Hyper-V desteklemezsen Windows 8’i biz destekliyorduk derlerse ciddi anlamda gülebilirim bu açıklama için)
 
 
Bir sonraki adımda ise sanal makinenin Cpu ayarlarına müdahale etme vakti gelmiştir. Ekranda görüldüğü gibi Intel işlemci için : CPUID Mask seceneğinden Advanced sekmesine gecip işlemci ayarlarında uzun bir liste gelen satırlardan Level 1 altında ecx satırını bulup :
 
“ —- —- —- —- —- —- –H- —- “ değerini giriyoruz ( toplam 8 adet 4lü grup var)
 
Bu detay ne işe yarar derseniz bunu da bir sonraki makalelerde derinlemesine bir teknik analizde bulabileceksiniz.
 
 
İşlemcimiz sanal içinde sanal çalıştırmaya uygun mimariye yönelmiş olsa da Sanal makinenin kendi içinde de sanallaştırma desteklemesi için sıradaki adımda CPU/MMU Virtualization sekmesinden normalde Automatic gelen seçeneği en alttaki seçeneğe çekiyoruz ki fiziksel makinelerde BIOS üzerinden yaptığımız gibi işlemcinin INTEL VT-x veya AMD-V  (sanallaştırma) desteğini açmış olalım.
 
 
Gayet güzel bir yolda ilerleyerek son adıma gelmiş bulunuyoruz Bu sefer de sanal makinenin genel ileri seviye ayarlarına müdahale edip yine işlemcinin çalışma şekline müdahale edeceğiz ki sanal içinde sanal mimarisi kurulabilmiş olsun. Yapmamız gereken ise aşağıdaki görselde General sekmesinden Configuration Parameters altına gelerek Add Row diyip ekrandaki özellik ismini ve karşılığında “FALSE” değeri girmeliyiz. Bu satır normal şartlarda yoktur el ile eklememiz gerekir, arayıp bulamazsanız sorun yoktur yani.
 
 
Bu yaptığımız tüm değişiklikler ile artık uygun bir platform oluşturmus olduk. Sıra geldi testlerimize: Aşağıdaki ekranda Kuruluma hazir bir ESXi 5.0 görüyorsunuz. Kendisi aslında bir sanal makine.
 
 
Sanal makineye konsol ile bağlanıp kurulum için ISO dosyasını gösterdiğimizde klasik bir kurulum yapıyoruz. Bu kısımlara değinmeye çok gerek yok zaten ESXi nasıl kurulup kısmında sorun yaşıyorsak bu adımlara kadar gelememişizdir :)
Nihayet kurulum bitip sanal makine kendini baştan başlattığında artık aşağıdaki gibi bir ekran ile karşılaşabiliriz. Mutlu son: ESXi içinde ESXi, nereden mi anladık? Vmware INC. Vmware Virtual Platform yazısı bizim için ESXi’nin kurulu olduğu fiziksel platform bilgisini verir, örneğin kurulum bir HP 380 G7 üzerine yapılmış olsa burada bu sunucunun ismini görecektik. 
 
  
 
 
Peki madem kurulum bitti o halde vSphere Client ile yeni kurulan ESXi içinde çalışan ESXi sunucumuza bağlanalım.
 
 
Bağlantı ilgili sertifika uyarısından sonra sağlandığında karşımıza aşağıdaki gibi bir ekran gelmesi gerekir ki bu ekran ile ESXi hostumuzu kullanmaya başlayabiliriz. Örneğin içine yeni sanal makineler açmak gibi.
 
 
 
Nihayetinde elimizde bir ESXi host varsa ve bu host 64 bit mimaride sanal makineler oluşturulmasını destekliyorsa sıradaki adım bu sanal içindeki sanal hostumuza 64 bit bit işletim sistemi kurarak lab ortamımızı tamamlamaktır.
 
 
Kısaca özetlemeye çalıştığım bu işlemleri kesinlikle üretim ortamı yada uzun soluklu test ortamları için düşünmeyin çünkü ciddi performans sorunları yaşarsınız. Ben ESXi kurulumu anlattım ama siz aynı adımlarla Hyper-V de kurabilir ve hatta o Hyper-V hostları içinden live migration yapabilirsiniz. İsterseniz fiziksel bir Hyper-V hostunuza yada sanal içinde çalışan bir Hyper-V hostunuza taşıyabileceğinizi unutmayın J Bu arada Vmware Tools kurulumda yaşanan sorunlardan dolayı ücretsiz olan Hyper-V Server ile GUI’den arındırılmış olan Server Core kurulumlarında sanal içinde host olarak kullanım esnasında sıkıntılar yaşadım bunu da Vmware Tools kuramamaya bağladım ancak kesinlik içermiyor.
Bu kurulumları yapmak ister, uğraşır ve sorun yaşarsanız yazının hemen altından yaşadığınız sorunu yorum olarak yazarak destek alabilirsiniz.