Posts Tagged ‘ESXi nedir’

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. 

 

vSphere 5 Döküman ve Download Linkleri

Written by Ertan Gülen. Posted in vSphere

 Bugün itibari ile download edilebilir durumda olan vSphere 5.0 için tüm kaynaklara aşağıdaki linklerden erişebilirsiniz.

Evaluation Guides:
What’s new whitepapers (Geçtiğimiz ay yayınlananlar):
 

ESX Mimarisine Genel Bakış

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

Vmware’in sanallaştırma platformalarında tarihsel olarak yaşadığı değişimlerden ve bu değişimlerin sebeplerden bahsetmeyi planladığım bu yazıda VMware GSX’den vSphere 5.0’a kadar olan sürecte altyapı tasarım farklılıkları ve sebeplerine değineceğiz.

Aşağıda görselde de fark edilebileceği gibi aslında altyapı mimarisinde 3 farklı tasarım mevcut. esx_mimari_tarihsel surec

1. İlk olarak 2001 yılında bir uygulama olarak tasarlanıp çalışan GSX Server karşımıza çıkıyor. Mevcut bir Windows yada Linux işletim sistemi üzerine kurulan bu uygulama sayesinde sanallaştırma yapılabiliyordur. Bare metal olmayan bu sanallaştırma mimarisi günümüzde de hala kullanılmakta, bir kaç örnek vermek gerekirse MS’in Virtual PC uygulaması, Sun’ın Virtual Box uygulaması ve VMware Workstation uygulamaları bu kategori için bilinen örnekler olabilir. Genellikle günümüzde test ve geliştirme ortamları için tercih edilmekle birlikte tarihsel süreçte evrilerek Windows 7 içerisinde XP Mode olarak gerçekten çok yararlı bir şekilde karşımıza da çıktığını unutmamak lazım. Ancak söylemeden geçemeyeceğimiz bir noktada şu ki bu tür uygulama ile sanallaştırma teknolojisi kullanıldığında mevcut altyapı icin kullanılan işletim sistemi (Linux yada [ki çoğunlukla] windows) de belirli kaynak tüketir ve belirli güvenlik ve yönetim riskleri taşır, daha çok test yada geliştirme ortamlarında tercih edilme sebebi de budur, çalışan işletim sisteminde donanım kaynaklı bir hata sanallaştırma platformu ne olursa olsun haliyle tüm yapıyı etkileyecektir ancak çalışan işletim sisteminde (sanallaştırma uygulamasının üzerinde çalıştığı sistem) güncelleme yada farklı bir uygulama sebebi ile oluşan hata tüm sanallaştırma platformunu da olumsuz etkileyecektir.

2. 2003 yılı itibari ile artık bir işletim sistemine bağımlı olup bu kaynak tüketim sorunlarını aşmak adına ESX bare metal bir sanallaştırma platformu olarak (hypervisor) karşımıza çıktı. Bu kez tasarımda ciddi farklılıklar mevcuttu, donanım üzerine kurulum işletim sistemi aslında sadece sanallaştırma için özelleştirilmiş olan bir Linux çekirdeğiydi, üzerine scriptler koşturulabilir ve ek uygulamalar geliştirilebilirdi. Service Console sayesinde klasik bir Linux işletim sistemi olarak kontrol edilebilir ve konfigure edilebilirdi.

İyi miydi? Evet iyiydi ama hala güvenlik açısından hala yönetim açısından bazı zafiyetleri vardı, örneğin büyük bir işletim sistemi olarak karşımıza çıkıyordu ( 2 gb footprint milyonlarca satır kod.) ve bu da bizim için ne kadar satır kod o kadar saldırılabilecek alan mantığı ile güvenlik sorunu oluyordu. Güncelleme kısmını unutmak mümkün mü? Kod satırı arttıkça güncelleme ve yamalama ihtiyacı da artmaktaydı tabiki.

Ancak bu tasarım bence bir kilometre taşıydı çünkü sanallaştırma için altyapı yine sanallaştırma ürünü olarak lanse edilmişti. Önemliydi zira sanallaştırma altyapısı sadece sanallaştırma yapıyordu artık. Eksileri ise tabiki linux üzerinde olmasıydı (yönetim açısından konuşuyorum, linux’un genel tartışması şeklinde değil) bu kısımda da çözüm olarak artık istemci tarafından yönetim kavramı karşımıza çıktı ki profesyonel anlamda bir ürün kullanıldığını anlamamıza da yardımcı oluyordu Gülümseme Bir diğer eksisi ise kurulumların uzun sürmesi ve zahmet vermesiydi. işte böyle bir sıkıntı yeni ihtiyaç olarak algılandı ve:

3.2007 yılında ESXi mimarisi tasarlandı. Klasik ESX mimarisinden farkları nedir diye sormak burada tasarımın da temel noktalarını bize çok net gösterebilir. ESX dediğimiz gibi linux işletim sisteminin sanallaştırma için optimize edilmiş ve tekrar derlenmiş haliydi fakat hala içinde sanallaştırma için gerekmeyen o kadar çok bileşen vardı ki.. Hem yüksek güvenlik isteği hem de daha hızlı kurulum kolay yönetim gibi arzular, ESX’in çalıştığı ortamı yani linux çekirdeğini küçültmeye sadece sanallaştırma altyapısı için çalışıcak minimal boyuta düşürmeye giden yolda önemli oldu. Nihayetinde 2007 yılında ESX ile aynı kodu kullanan ama sadece ihtiyaç duyulan satırların derlendiği ve 110 MB gibi bir boyutu olan ESXi ortaya çıktı. Donanım üzerinde artık sadece sanallaştırma çekirdeği çalışır oldu ve VMware kendine o kadar güvenir bir hal aldı ki bu çekirdeik için hypervisor yerine VMvisor demeyi daha uygun buldu. Yine bare metal bir sanallaştırma seçeneği olarak sunuldu ve 2011 yılına kadar klasik çekirdek klasik ESX ile birlikte alternatif olarak sunuldu. vSphere 5’in lansmanı ile anladık ki bundan sonra çıkacak tüm sanallaştırma platformları sadece bu özel ve küçük çekirdek üzerinde çalışacak ve ESX mimarisi de GSX gibi tarihe gömülecek.

Meraklısı için ufak bir not; ESX ile ESXi arasındaki farklar:

İki ürün de aynu çekirdek üzerinde endüstri standardı sanallaştırma çözümleri sunmakta ve aynı performans ve genişleyebilirlik seçeneklerine sahip.Ancak fark yönetim kısmında karşımıza çıkıyor. ESX, linux komutları ile service console üzerinden yönetilebilirken, ESXi yönetimi için ise vCLI ve PowerCLI adlı bileşenler ile scripting uzak bilgisayardan yapılır oldu. Yani komutlar ESX’de server üzerinde yazılıp çalıştırılırken ESXi’da uzaktan yazılıp serverda çalışır oldu. Bunun sebebi ise ESX içinde 2 GB yer kaplayan Red Hat Enterprise Linux tabanlı olan service console’un artık olmamasıdır.

Bir diğer fark ise tabiki boyut ile alakalı olarak güvenlik kısmı, disk üzerinde kapladığı yeri düz mantık kod satır sayısı olarak düşünürsek artık ESXi üzerinde hata oluşturacak yada saldırıya açık olabilecek alan ciddi anlamda azalmış oldu, bir diğer balış açısı ile bu noktayı daha az güncelleme ve yama olarak da telaffuz edebiliriz.