|
|
VmWare Sanal Makine Seçimi
|
|
|
Ana sayfa
Kütüphane
Ürün dokümanları
VMware
1 - Giriş:
Bu dokümanın amacı VmWare sunucu konsolidasyon projesi için bir sanal makine seçerken kullanılan genel kriterleri açıklamaktır. Hiçbir doküman tüm olası sunucu ve sanal makine konfigürasyonunu içermezken, bu dokumanın niyeti VmWare kullanıcılarını, potansiyel bir sanal makine sunucusu analiz ederken dikkate alınması gereken farklı kriterler hakkında eğitmektir!
Bu doküman boyunca okuyucuyu VmWare sunucu konsolidasyon araçlarını kullanıyor (veya kullanmayı düşünüyor) olarak farz edeceğiz. Bu aklımızın bir kenarında, işimiz birden fazla sanal sunucuyu tek bir fiziksel sunucu üzerinde konsolide etmek ile ilişkili olduğundan, sunucu/sanal makine kullanımı ve gereksinimlerine yoğunlaşacağız. Felaket kurtarma, iş sürdürme amaçları, Windows işletim sistemi sınırlamaları ile karşılaşıldığında doğrusal olarak donanım ölçeklemesi, VmWare teknolojisinin, sunucunun bir önceki haline getirilmesi için kullanması gibi diğer VmWare stratejileri bu dokümanın konuları arasında olmayacaktır.
2 - Sanal Makine Seçim Süreci
Teknik mimarlar, VmWare'i sunucu konsolidasyon stratejisinin bir parçası olarak kullanırken genellikle "hangi sunucular VmWare ile uyum sağlar?" sorusu ile karşılaşır. Standart cevap, "eksik faydalanılan sunucular" olmasına rağmen, bu tüm hikayeyi anlatmaz. Doğru cevap, şirketinizin VmWare için olan stratejisine bağlıdır.
Eğer stratejiniz VmWare'i eksik faydalanılan (donanım tarafından) sunucuları konsolide etmekte kullanmak ise, bu cevap iyidir. Fakat genellikle ikinci bir soru "eksik faydalanılan nedir" sorusu peşinden gelir. Bunun teknik cevabı, VmWare'deki "çekirdek dörtlü"ten herhangi biri üzerindeki kaynaklardan %100'ün altında fayda sağlayan her şeydir. (Çekirdek Dörtlü: İşlemci, Bellek, Disk ve Ağ). Elbette cevabınız teknik olarak doğru iken, VmWare sunucularının optimal kullanımı sağlanamayabilir ve bu olduğunda çok az bir kazanım için lisanslamaya çok fazla para ödersiniz.
İlerleyen bölümlerde "ideal sanal makine"lere yoğunlaşacağız. Bu bölümler ideal sanal makineyi sunucu konsolidasyonu bakışı açısından (VmWare hakkındaki çoğu şüpheleri alarak) açıklayacak ve umut ederiz ki size sunucularınızı değerlendirmeye başlarken kullanacağınız bir temel kurallar seti verecektir.
2.1 - VmWare ESX Ürününe Kısa Bakış
VmWare ESX ürünü, tek bir fiziksel sunucu üzerinde birden fazla sanal işletim sistemi çalıştırmaya izin veren sanal bir donanım platformu yaratır. Her bir sanal makine, içinde x86 işletim sistemlerinin çoğunun çalıştırılabildiği sanal bir donanım platformunu temsil eder. Fiziki sunucu donanımının bu şekilde sanallaştırılması, bir şirkete "eksik faydalanılan sunucuların" aynı donanım kaynaklarını kullanmasına izin vererek, donanım kaynaklarının maksimum kullanımını sağlar.
Bu doküman, sunucu konsolidasyonunda kullanılırken VmWare ESX ürünü için potansiyel sanal işletim sistemlerini seçerken kullanılabilecek kriterleri açıklar.
2.2 - İdeal Sanal İşletim Sistemine Kısa Bakış
Hangi sunucuların VmWare ortamı içinde yer alacağına karar vermek, bir parça basit kaynak hesaplamaları egzersizi ve tecrübesidir. Sunucu altyapınızın incelenmesinde verilmesi gereken bir karar sunucunun fiziksel olarak mı, sanal bir makineye geçirileceğini mi veya yapılandırılacağımı konusundadır. Bu karar iki faktör üzerine dayanır:
- Sunucu için fiziksel kaynak gereksinimlerine
- Sunucunun ne kadar sayıda kullanıcıyı veya ne kadar büyüklükteki aktiviteyi destekleyeceğine
Çoğu zaman bu iki faktör çok fazla ilişkilidir ve genellikle aynı anda azalıp artarlar. Buna iyi bir örnek basit bir veritabanı sunucusu olabilir: Bir veritabanı olmak başlı başına VmWare içinde bulundurulması anlamına gelmez. Eğer veritabanı sunucusu az sayıda kullanıcı (40 ya da 50) için inşa edilecekse (veya edildiyse) donanım gereksinimlerinin son derece düşük olacağı varsayılır (olası olarak standart tek veya çift işlemcili sunucunun sağladığı kaynaktan daha düşük). Bu durumda sunucu ideal bir VmWare adayı olabilir.
Bu örneği 40 ya da 50 kullanıcı ile başlayacak fakat sonunda yüzlerce ya da binlerce eşzamanlı kullanıcıya hizmet verecek olan bir veritabanı sunucusuna çevirelim. Bu sunucunun/uygulamanın gereksinimleri standart bir çift işlemcili sunucunun başa çıkabileceğinden daha fazla işlemci gücü veya bellek gerektirebilir. Bu durumda sunucuyu sanal bir ortam içine taşımanın temel yararı (sunucu kaynaklarının birden fazla sunucu tarafından paylaşılmasına izin vererek, donanıma harcanan parayı düşürmek) baltalanır çünkü aday sunucunun büyük olasılıkla tek bir fiziki sunucu bilgisayarın kaynaklarının büyük kısmını diğer sanal makineler için çok az bir boşluk bırakarak tüketmesi olasıdır.
"İdeal" aday daha az kaynak (işlemci, bellek, disk, vb) gerektiren sunucu/uygulama'dır. Fakat şu unutulmamalıdır ki, sanal makine üzerinde taşıdığı uygulamanın mantıksal olarak başka bir sunucu ile kendi uygulamasını (servislerini) paylaşmamalı ve tek başına bir sunucusu olmalıdır. Sunucunun doğru kaynak gereksinimlerine bakarak, tek bir fiziksel sunucunun sağladığı donanım kaynaklarının daha azını mı (normal şartlarda) kullanacağını belirleyebilirsiniz. Birçok durumda fiziksel sunucular büyümeye izin vermek amacıyla (veya sadece mevcut teknolojiyi satın alabildiğinizden, örneğin: mevcut işlemci hızları) yüksek mühendislik teknolojisine sahiptir. Bu yüksek mühendislik genellikle işlemciyi, diski, belleği ve ağı da içine alan tüm kaynaklara uygulanır. VmWare ile bu yüksek mühendislik gerekli değildir, çünkü kaynaklar maksimize edilebilir ve kaynak paylaşım tahsisi sunucu gereksinimleri farklılaştıkça değişir. Böylece tüm donanımınızın kullanımını maksimize edilirsiniz.
İdeal sanal sucuyu uygulama türünden ziyade iş yükleri belirler. Vmware'de temel hedef farklı iş yüklerini aynı makineye toplayarak konsolidasyon yapmaktır. Aşağıdaki grafikte aday değil diye gösterilen çok uygulama bir çok müşteride production ortamında gayet başarılı çalışmaktadır. Burda önemli nokta iş yükü ve sunucu yükü arasındaki orandır.
Hangi sunucuların sanallaştırma için uygun olduğuna karar vermek her zaman kolay olmaz. Verimlilik üzerine bazı en iyi endüstri deneyimlerine ve varsayımlarına dayanan, Chicago RapidApp Inc.'den Ron Oglesby yukarıdaki tabloyu geliştirdi. Bu tablo sunucu tipleri için pratik bir kural oluşturur. Açıkçası her kuralın hataları vardır, fakat kullanıcı sayısı ve donanım kaynaklarının kullanımı temel prensipler dahilinde her bir sanal makine adayı için uygulanır.
2.3 - Sanal Makine Seçimi Kriterleri
Bir sunucunun sanal olup olmayacağı ya da sanal sunucuya taşınıp taşınmayacağı konusunda bir karar vermek gerektiğinde birkaç kriter göz önünde bulundurulmalıdır. Dokümanın bu bölümü bu türde kararlar verirken göz önünde bulundurulması gereken, seçilmiş kriterleri açıklar.
Açıkça bazı sunucu kararları neredeyse zor olacaktır. Test ya da geliştirme sunucularının büyük bir çoğunluğu VmWare ile mükemmel uyum sağlar. Bunun için iyi bir örnek, yeni uygulama kodunun üzerinde az sayıda yazılımcı tarafından denendiği bir Windows geliştirme sunucusu isteği olabilir.
Spektrum'un ters ucunda, büyük ölçekli (enterprise) sınıfı mesajlaşma sunucuları (örneğin: 1000 ve üzeri mail kutusu barındıran Exchange sunucuları) genellikle VmWare sunucu konsolidasyonu için kullanıldığında uygun olmaz.
Her iki durumda kullanım miktarı, potansiyel donanım faydalanması, kullanıcı sayıları ve diğer özel donanım gereksinimleri bir karar vermeden önce gözden geçirilmelidir.
2.3.1 - Desteklenen Sanal İşletim Sistemleri
Bakılması gereken ilk kriter potansiyel işletim sisteminin bir sanal makine olarak (VM) desteklenip desteklenmediğidir. Bu dokümanda daha önce belirtildiği gibi, VmWare fiziksel donanımı sanallaştırılmış bir katman aracılığı ile sunar. Bu donanımın katmanlaştırılmasına rağmen, özel sürücüler ve işlevsellik gerektirir (dışarıdaki herhangi bir donanım gibi).
VmWare desteklediği belli sayıda işletim sistemi için kendi sanal donanımlarına sürücü sağlar.
ESX 2.5.2 için desteklenen işletim sistemleri:
Windows 2003 Service Pack 1
Windows 2003 (tüm sürümleri)
Windows 2000 (tüm sürümleri) Service Pack 3 ve 4
Windows XP (Pro) Service Pack 1 ve 2
Windows NT 4.0 (sunucu sürümleri ve çalışma istasyonu) Service Pack 6a
NetWare Server 6.5 Service Pack 2
NetWare Server 6.0 Service Pack 5
NetWare Server 5.1 Service Pack 7
RedHat Linux Enterprise 3.0 Update 5
RedHat Linux Enterprise 3.0
RedHat Linux Enterprise 2.1 Update 7
RedHat Linux Enterprise 2.1
RedHat Linux Advanced Server 2.1
RedHat Linux 9.0
RedHat Linux 8.0
RedHat Linux 7.3
RedHat Linux 7.2
SuSE Linux Enterprise Server 9.0 Service Pack 2
SuSE Linux Enterprise Server 8.0 Service Pack 3
SuSE Linux Professional 9.3
SuSE Linux Professional 9.2
SuSE Linux Professional 9.1
SuSE Linux 9.0
SuSE Linux 8.2
Free BSD 4.10
Novell OES Service Pack 1
VmWare 2.5.2, 64bitlik fiziki sunucu makinelerde 32bit olarak çalışır ve 64bitlik işletim sistemlerini desteklemez. ESX 3.x 64bit desteğine sahip olacaktır.
VmWare ESX x86 sunucu tabanlı bir çözüm olduğundan, desteklediği işletim sistemlerinde bir eğilim gözünüze çarpacaktır. Listedeki tüm işletim sistemleri doğuştan (saf) x86 tabanlı işletim sistemleridir. Native X86 olmayan işletim sistemleri X86 için recompile edildiğinde sorunsuz çalışacaktır. Plan9 ve Solaris bunlara örnektir.
2.3.2 - "Çekirdek Dört" Kaynak Kullanımı
Göz önünde bulundurulması gereken ikinci şey ise, potansiyel sanal işletim sisteminin belirlendiğinden, sanal makine tarafından ihtiyaç duyulacak olan fiziksel kaynakların miktarıdır. Bu bölümde VmWare perspektifinden "Çekirdek Dört"ün görünümü üzerine yoğunlaşacağız. Kullanılan kaynaklara focus olunduğunda bu çekirdek dörtlü çok doğru bir yaklaşımdır ama göz ardı edilmemesi gereken çok fazla interrupt yapan uygulamalar sistemin çok fazla beklemesine neden olacağından sistem performansını olumsuz etkileyip anlam verilemeyen gecikmelere neden olmaktadır. Özellikle peripheral kullanan uygulamalar ya bu tür ortamlardan izole edilmeli yada network attached peripheral'a dönüştürülmelidir.
Açıklanması gereken ilk kaynaklar, işlemci, bellek, disk ve ağ gereksinimleridir. Herhangi bir x86 sunucuda VmWare için genel dar boğazlar işlemci ve bellektir. En genel darbogaz disk I/O'dur. Sonrasında memory I/O ve kapasiteyi sayabiliriz ama disk ve network I/O en düşük darbogazlardır. Tekbir sunucu üzerindeki işletim sistemlerinin sayısına bağlı olarak, potansiyel bir sanal makinenin ortamdaki etkisinin tetkik edilmiş olması mecburidir. Kaynak gereksinimlerinin kestiriminde erken davranmak, potansiyel sanal makinenin VmWare modeline uyup uymayacağının belirlenmesine olanak sağlar. Bunun yanında, VmWare yöneticisine her bir ESX sunucu üzerindeki sanal makinelerde düşük ve yüksek faydalanmada optimumu yakalamak amacıyla, hangi fiziki sunucunun (host) sanal makineyi destekleyeceğini belirlemesine olanak tanır (Kısaca, sanal makineler kurulmadan önce kaynak gereksinimleri incelenmelidir). Burada iki yaklaşım vardır, tümden gelim yada tüme varım yaklaşımı gibi, müşterinin verecegi stratejik karar önemli, kimi müşteriler Vmware'e geçmeden her türlü kapasite planlaması ve yer alanı çalışmasını yapıp ona göre sunucu seçebileceği gibi, mevcut örneklerdeki best practice denilen model sunuculardan seçip izle ve optimize et mantığıyla aşama aşama sunucularınıda taşıyabilir. Her iki yolda yoğun kullanılmakta ve tercih nedeni müşterinin Vmware'e stratejik yaklaşımındadır.
2.3.2.1 - İşlemci
Daha önce anlattığımız gibi, ESX sunucu üzerindeki fiziksel işlemciler, tüm sanal işletim sistemleri arasında paylaştırılır. Varsayılan (default) olarak, kaynaklar tüm sanal makineler arasında eşit olarak paylaştırılır. Bu, tüm sanal makinelerin eşit miktarda işletim zamanına ihtiyacı olduğu varsayımı altında (çoğu zaman bu gerçekleşmez) VmWare'in mevcut tüm işletim zamanının tüm sanal makinelere eşit olarak bölmesine olanak tanır. İşlemciyi gereksiz yere bekleten IRQ'lerden arınma konusuna değinmekte yarar var. İşlemci ne kadar çok çalışırsa değil ne kadar az beklerse o kadar verimli olur.
Neredeyse tüm ortamlarda sanal makineler sunucu'dan sunucu'ya, saniyeden saniyeye farklı miktarlarda işletim zamanlarına ihtiyaç duyarlar. Bir sanal makine işlemci zamanı talep ettiğinde, fiziki sunucu (host) bunu sistem üzerindeki mevcut işlemci kaynaklarından tahsis eder. Mevcut boş işlemci zamanının (idletime) var olduğu varsayılarak işlemci istekleri (processor cycles) o anda yapılır. Eğer fiziki sunucu (host) üzerindeki işlemciler %100 kullanılıyorsa, fiziki sunucu hangi sanal makineye öncelikli olarak cevap vereceğin belirlemek için "sanal makine kaynak payları" ayarlarına başvurur. Bu ayarlama sanal makineye tahsis edilen payın miktarına göre (varsayılan olarak eşittir), istenilen kaynakta çakışma olduğunda hangi sanal makinenin "daha önemli" olduğunu belirler.
Pay/kaynak tahsisi bu dokümanın alanı dışındadır, fakat bir sanal işletim sistemi seçerken kaynakların temel paylaştırılma yolunu anlamak önemlidir.
Bir adayın, sanal makine (Virtual Machine) olup olmayacağını belirlerken, işlemci tarafından gelecek olan gerçek gereksinimlerin tahmin edilmesi önemlidir. Tahmin edilmesi gereken en önemli parametre işlemcinin çalışma saatlerinde ortalama kullanım zamanıdır. İkinci en önemli parametre ise kullanım zamanının değişkenliği veya kullanım esnasındaki tepe değerinin miktarı ve süresidir.
Daha sonra bu bölümde karar sürecinde kullanmak üzere iki örnek yaratacağız fakat şimdilik aşağıdaki tabloya dayanan genel bir kural oluşturacağız.
Bu şeklin gösterdiği gibi, bir fiziki sunucu'nun işlemcisinin(lerinin) en etkin biçimde kullanılması, sanal makinelerin kendilerine ait mevcut işlemci kaynakları yüzdelerini kullanmasını ile oluşur. Bu işlem, fiziksel bir sunucunun işlemcisinin hızı ile ESX sunucusunun işlemcisinin hızını 1'e 1 olarak kabul eder. Bu değerlendirme, eğer fizikselden sanala geçiş gerçekleştiriliyorsa ve fiziksel sunucu daha eski donanım kullanıyorsa göz önünde bulundurulmalıdır.
Örneğin, çift 550 MHz işlemcili bir aday makinenin olduğunu varsayın. Ek olarak, bu aday çalışma saatlerinde işlemcinin ortalama %80'ini kullansın. ESX sunucu'nun 2.8 GHz işlemci gücü kullandığını varsayarsak, bu aday aşağıdaki eşitliği kullanarak "işlemci kaynağını etkin kullanan sanal makine modelini" gerçekleştirebiliyor. Vmware SAN ile kullanıldığında tek başına çalışan (standalone) sunuculardan çok daha iyi bir I/O kapasitesine sahip olacağından, CPU gereksiz I/O beklemeleri ve page fault için daha kısa süreli cevaplardan kurtulacağından sanal makine ESX üzerinde daha verimli bir cpu kullanım karakteristiği gösterir.
Yukarıdaki hesaplamada FSB hızı göz önüne alınmamıştır, CPU performansında FSB'nin performansı çekirdek hızından daha önemlidir. Gördüğünüz gibi, bu çift işlemcili sunucu %80 kullanılmasına rağmen, daha hızlı işlemcilerle düzgün bir biçimde karşılaştırıldığında bugünün hızıyla tek işlemcinin %31'ine karşılık geliyor. Tabi ki bu basit bir yaklaşımdır ve çoklu işlemci desteği (SMP) kullanımını, ön bellek (cache) değişimlerini ve işlemci mimarisini hesaba katmaz, fakat yine de bir adayı tanımlamada ve bu adayın ESX ortamı içindeki yerini belirleme de yardımcı olur.
Sunucu konsolidasyonu için kullanılan iyi bir temel baş parmak (nası yani?) kuralı, işlemci başına ortalama 4-5 sanal makine varsaymaktır. Bu, çalışma saatlerinde her sanal makine fiziki sunucunun işlemcisinin %20-25'ini kullanmalıdır (varsayılan ve mükemmel bir dünyada). Gerçekte sanal sunucunun kullanımı tıpkı normal bir sunucuda olduğu gibi yukarı aşağı dalgalanır. Bu normal dalgalanma, sunucuların gün boyunca tepe yapmasına ve ihtiyaç olduğunda kaynakların kullanımına ve daha sonra diğer sanal makinelere vermeye veya onlarla paylaşmaya olanak tanır. Vmware'e göre işlemci başına 8 sanal makine öngörmektedir ama zamanla CPU hızlarındaki gelişme iş yüküne göre asimetrik geliştiği için böyle öngörüler değerini yitirecektir
Bir sunucunun işlemci kullanımındaki dalgalanmanın miktarı ikinci ele alınması gereken yöndür. Makinenin gün boyunca çalışma ortalaması size referans değerleri verebilir fakat tüm meseleyi açıklamaz. Günlük tabanda ortalaması %30 olan bir sunucunun referans değerlerini örnek olarak kullanırsak, VmWare ile mükemmel uyum sağladığını varsayabiliriz (diğer tüm kaynakların hali hazırda kullanıma hazır olduğunu varsayarsak). Fakat ortalamayı, 10 dakika %100 kullanım gerçekleştiren, bir saatlik %20'lik kullanımdan türetirsek bir problemle karşı karşıya kalabiliriz. Normal operasyonlarda sunucular kendi işlemcilerini kısa süreler için en tepe noktada kullanabilirler; bu normaldir ve bir problem olarak düşünülmez. Bir sanal ya da potansiyel sanal makinenin sürekli olarak işlemcinin mevcut zamanının tamamını kullandığı gözlenirse bu VmWare ortamı ve uygulamalar için uygun bir şey değildir veya iş yükü daha yakından incelenmelidir.
2.3.2.2 - Bellek
İşlemcilere oldukça benzer şekilde, fiziki sunucu'nun belleği sanal işletim sistemleri arasında paylaştırılır. İşlemcilerden farklı olarak ise bellek, işlemci kaynaklarında olduğu kadar dinamik şekilde paylaştırılmaz. Bellek paylaşımında iki boyut vardır. Biri belleğe erişim süresi ki bu CPU kadar dinamik derecede paylaştırılır diğeri ise bellek kapasitesi, her bir sanal makine kendi fiziksel adresine ulaştığını sanarken, Vmware ona VMM'den atadığı adres boşluklarına yerleştirme için offset adresleri ekler) ESX sunucuda her sanal makineye belli miktarda bellek, sanal işletim sistemi tarafından kullanılması için atanır. Sanal makinenin açılması (boot) esnasında sunulan bellek direkt olarak ESX sunucu üzerindeki fiziksel belleğe adreslenir (map). Sanal işletim sistemi çalışmaya başladıktan sonra, ESX belleği dağıtmaya başlar (bu süreç "transparent page sharing" olarak adlandırılır). Fiziksel bellek ve hafıza paylaşımına (page sharing) ek olarak, ESX sunucu sanal makinelerinizin aşırı bellek ihtiyacına olanak tanımak için bir geçiçi alan (swap space) oluşturur.
Performansın kritik olduğu bir ürün ortamında, bu geçiçi alanın (swap space) kullanımını; sanal makineler için hazırlanmış bellek sayfalarına (memory pages) ihtiyaç olduğunda, fiziksel bellek yerine, geçiçi alan (swap space) ile değiştirilmesi şeklinde sınırlandırmak isteyebilirsiniz. Bu değiştirme süreci tüm sanal makine performansını mahvedebilir.
Bellek paylaşımı kavramı önemlidir çünkü sanal makine başına düşen bellek ihtiyacını daha gerçekçi olarak kestirmemize olanak tanır. Temel kavram işletim sistemlerinin bellekte büyük miktarda özdeş veri bulundurmalarıdır. Bu özdeş veriler (ya da özdeş sayfalar) sanal makineler arasında paylaştırılabilir. Genel veri tipinin çoğunlukta 0'lardan oluştuğunu varsaydıktan (bellek sayfaları henüz yazılmadığından/kullanılmadığından) sonra her sanal makine (en azından açılış esnasında) belleği paylaşabilir. Ek olarak, fiziki sunucu üzerindeki sanal makineler ne kadar tutarlı (bellek ayarları) olursa bellek onlar arasında o kadar iyi paylaştırılır.
Vmware'in hafıza yönetim mekanizması zaman zaman tüm hafıza sayfalarını tarayarak aynı alan sayfaları bulup, bu sayfaları adresleyen tüm sanal makinelere sadece bir tanesini gösterip diğerlerine boşaltmaktadır. Bu sayede ESX Sunucusu üzerinde çalışan benzer işletim sistemleri ve benzer uygulamalar kaç tane çalışırsa çalışsın hafızada sadece bir kopya yer kaplar.
Genelde bunun sayesinde en düşük %5 en yüksek %40 bellek kaybının engellendiğini göreceksiniz. ESX sunucu için iyi bir kural, kayıp engellemelerin ortalama %20 civarında olmasıdır.
Bir potansiyel sanal makinenin bellek gereksinimlerini analiz ederken DOĞRU bellek gereksinimlerini bulmak önemlidir. İşlemcilerde olduğu gibi, mühendisler sunucun ihtiyacı olduğunda daha fazla bellek edinmeyi ve kurulumunu istemediklerini (a) ve bu gibi güncellemelerin (upgrade) işletim sistemi ile bazı problemler ortaya çıkaracağını (b) varsaydıklarından aralıksız bellek inşasına niyetliler. Bu iki varsayımı kullanan mühendisler sonraki zamanlarda güncelleme (upgrade) ihtiyacını engellemek amacıyla fiziksel sunucuların inşasında aralıksız çalışmaktadırlar çünkü basitçe "bellek ucuzdur".
Genellikle ESX sunucuda bellek kısıtlı bir kaynaktır. En genel ESX ortamı konsolidasyon darboğazı bellektir. Bu aklımızın bir kenarındayken bir sanal makine veya potansiyel sanal makine aşağıdakiler için olan ihtiyaçlarının belirlenmesi için incelenmelidir:
Bu sayılar bazı mühendislere düşük gelebilir. Bunun sebebi mühendislerin inşa ettikleri sunucuların çoğunda aşırı mühendislik kullanmalarıdır. Bu tüm sunucuların bu kalıba sığacağı anlamına gelmez fakat büyük bir çoğunluğu böyledir. Bu şekildeki sunucular potansiyel VmWare adaylarıdır.
Sunucunuzun ne gerektirdiğini doğru anlamak için (eğer önerilen sanal makine gibi hiç bir fiziksel sunucunun bulunmamasından ötürü kestirim yapmak zorundaysak) yazılım şirketinin kendi uygulaması için minimum tavsiyelerini belirlemek zorundasınız. Bundan sonra büyüme için biraz boşluk (room) tahmini yapın ve adayın bellek ihtiyacının 1.5-2.0GB altında olup olmadığını belirleyin. Eğer değilse ve sunucu kesin olarak 2 veya daha çok fiziksel GB Ram kullanacaksa, o halde sunucu çok fazla miktarda kaynak kullanacak ve olası olarak kendisinin bir sanal makine olmasını engelleyecektir.
Çoğu VmWare tasarımındaki varsayım her sanal makinenin 512MB ile 1.5GB Ram arasında ayarlanacağıdır. ESX'deki diğer tüm kaynaklar gibi, mimarinin paylaşma yönü bize, fiziksel sunucu üzerinde olan ve bazı sunucularda bu ortalamadan daha yukarı çıkabilen kaynakların aşırı tahsisine (over allocate) olanak tanır. Bu, 16GB Ram'e sahip bir sunucunun olası şekilde, VmWare geçici alan (swap) dosyasına (bu dosya içinde %20 bellek kaybı engellemeleri kuralı ve konsol işletim sistemi tarafından kullanılan bellek tasvir edilir) dokunmadan her biri ortalama 1GB Ram'e sahip 19 sanal makineye host olabileceği anlamına gelir. ESX'te fiziki sunucu sistemi belleğinin (ram) 2 katı kadar memory sanal makinelere tanımlanabilir. Bu 2 kat tanımlamaya rağmen swap gerekmeyebilir bunu sanal makinelarin hafıza operasyonları belirler.
Bir sanal makineyi sürekli olarak inşa halinde olmanıza gerek olmadığını fark etmek önemlidir. Bir sanal makine üzerindeki belleğin miktarını artırabilme yeteneği mevcuttur ve çok basit bir süreçtir. Sanal makine üzerindeki değişimin basit bir konfigürasyon işlemi olmasını sağlamak amacıyla gereken tek şeyin sanal makinenin yeniden başlatılmasıdır. Sanal makine açıldığında yeni bellek işletim sistemine sunulur ve fiziksel bellekten tahsis edilir. Yüksek mühendisliğe gerek yoktur.
2.3.2.3 - Disk
Çekirdek Dört'ün üçüncü kaynağı ise disk ya da veri ambarı alt sistemidir (subsystem). Çoğu zaman disk bir adayı reddetmez fakat bunun yerine bazı özel konfigürasyonlar gerektirir. Disk kullanımı bir endişe olabilir fakat genellikle sınırlama faktörü disk IO'su için değil, bunun yerine sunucu tarafından gereksinim duyulan sürücü tipi (ide, sata, raid, scsi) ya da boşluk miktarıdır içindir. Disk altsisteminin tipi fiziki sunucu için önemlidir ama sanal makine seçiminde önemli değildir. Sanal makine seçiminde tek önemli faktör ihtiyaç duyulan disk I/O kapasitesidir. Mevcut sunuculardaki disk I/O kapasiteleri bile bir sunucu için yetmeyebilirken birden fazlayı birleştirirken en önemli nokta birim zamanda ihtiyaç duyulan en az I/O kapasitesidir.
ESX diski sanal makinelere BusLogic ya da LSILogic SCSI ara yüzü olarak sunar. Bu ara yüz aracılığı ile sanal makineler, gerçek bir .vmdk dosyası olan kendi, benzeri olmayan sürücü'lerine ulaşırlar. Bu dosya (normalde yüksek hızlı bir SAN içinde saklanır) sanal işletim sisteminin kendi diskleri ve bölüm'leri (partition) olarak ne görüyorsa onları içerir. Sanal makinedeki işletim sistemi ve uygulamalar gerçekte bu VMDK dosyası içine kaydedilirler. Yaptığımız pratik testlerden VMFS'in transparent bir FS olduğu görülüyor bu durumda vmdk dosyalarının başlangıcı ve bitişi pointer adres gibidir.
Genelde depolama miktarı sunucuyu kullanan kullanıcı miktarını oransal olarak artırır. Ek olarak, belli bir sunucuya giriş yapan kullanıcıların sayısı, sunucunun tüm kullanımını artırır.
Kullanımın (işlemci ve bellek) normalden fazla olduğunu fakat yine de bir sanal makine için kabul edilebilir olduğunu varsaydığınızda, bu sunucu için depolama (storage) gereksinimlerini tekrar gözden geçirmelisiniz. Yapılan disk I/O'dan kaçınmak için cache mekanizmasının yararının olup olmayacağı aday sanal makine için önemli bir kriterdir.
Genellikle konsolidasyon tasarımlarında, her sanal makineye belli bir disk büyüklüğü verilir. Bu büyüklük genelde 8-16GB aralığındadır. Eğer yüksek miktarda disk I/O'suna sahip olabilecek büyük ölçekli bir sunucu (enterprise class server) oluşturuyorsanız, sanal makinenin performansından ve olası bir SAN disk maliyetinden dolayı VmWare tek başına çözüm getiremeyebilir. Eğer sanal makinede varsayılanın (default) üzerindeki SAN/veri alanı, mevcut sunucu maliyeti içinde belirtilmişse, bu adayın, tüm kriterleri karşıladığını varsayarak sanal makine yapmaya gerek yoktur.
2.3.2.4 - Ağ
Eğer işlemci ve bellek tüketimi en sık rastlanılan darboğazlarsa, ağ bağlantısı (ESX sunucuda) en az rastlanandır. Diğer tüm "Çekirdek Dört" kaynakları gibi, Ağ ara yüzleri sanal makineler arasında paylaştırılır. Çoğu konsolide edilmiş ortamlarda tasarım her gigabit ağ bağlantısı başına 8-10 sanal makine varsayar. Sanal makinelerin ağ ara yüzleri üzerinde eşit pay ve zaman almalarına izin vermek, her bir sanal makinenin 100Mbit ağ bağlantısı bulunduğu bir ortam yaratır. Bununla beraber 1Gbit eşittir 10 tane 100Mbit yaklaşımı doğru değildir. Gigabit network'te bir ethernet frame 12 mikro saniyede teslim edilir. 100Mbit'te ise bu süre 120 mikro saniyedir. Bu aradaki fark sistem kaynakları ve network buffer'ın daha boş olması anlamına geleceği için direk 8-10 makine gibi bir oran vermek doğru değildir. Yoğun ortamlarda bile ortalama backup ve kopyalama haricinde kullanılan bant genişliği 15-20Mbit'i geçmez. Bunun çakışma ihtimalide düşük olursa gigabit network çok daha büyük iş yükleri için kullanılabilir.
Bu aklımızın bir köşesinde, potansiyel sanal işletim sistemi büyük miktarda bant genişliği gerektirmemelidir. Burada büyük miktarda bant genişliği 200, 300 ya da belki de 400Mbit'den bile daha fazla ağ bağlantısıdır. Bu miktarda bant genişliği bir adayın sanal makine olmasını engellemez fakat bu sanal makineyi, daha düşük bant genişlikleri isteyen birkaç sanal makinenin bulunduğu bir ESX sunucu üzerine kurmanızı gerektirir.
2.3.3 - Diğer Donanım Gereksinimleri / Sunucu Görevleri
Bir sunucunun işlev veya görevleri, tek başına bir adayın VmWare ile iyi uyum sağlayıp sağlamayacağını belirlememesine rağmen, konu belli tiplerdeki sunucuların özel donanım gereksinimleri olduğunda bazı temel kurallar vardır. Bunun iyi bir örneği faks sunucusudur. Faks sunucuları genelde PCI tabanlı faks kartları gibi özel donanıma ihtiyaç duyarlar. ESX donanımı birçok kullanıcıya sunan ve paylaştıran sanal ortamı desteklediğinden, bir ESX sunucu içinde bir Faks kartı için destek iyi bir fikir değildir. Çok düşük hızlarda saat darbesiyle çalışan ve IRQ yapan aygıtlar ESX sunucuda çok daha etkin kullanılabilecek CPU kaynağını heba edeceği için desteklenmemiştir.
Bu düşüncede sanal makine sunucusunun her özel aracı (device) veya ek parçayı (peripheral) incelemeniz gerekir. Bu bölümde özellikle IDE sürücü'ler, USB ve Firewire araçlar, Paralel/Com bağlantı noktalası (port) araçları ve tabi ki PCI araçlar üzerine yoğunlaşacağız.
IDE Sürücü'ler
IDE sürücü gerektiren (bunun dışında CD'nin kullanılabilir hale getirilmesi hariç) sunucular büyük olasılıkla VmWare'e uymaz. ESX sunucu DSK (vmfs ve vmkcore) dosyalarının depolanmasında ya da sanal işletim sistemlerinin direkt ulaşımı için IDE sürücü'leri desteklemez. IDE teknolojisi fiziki sunucu ve sanal donanımda sadece optik medya (dvd/cdrom) için desteklenmiştir sanal makineler çalışırken gerekmedikçe cd'nin "connected" olmaması gereksiz IRQ üretmesini engellemek için iyi bir tercihtir.
USB/Firewire Araçlar
Varsayılan (default) olarak USB ve Firewire araçların çoğu VmWare ESX üzerindeki sanal işletim sistemleri tarafından desteklenir. Eğer bir sunucu bir USB aksesuara ihtiyaç duyuyorsa veya USB araç lisanslaması kullanıyorsa, bu büyük olasılıkla onun bir VmWare adayı olarak çalışmasını engellemez. Vmware ESX üzerinde USB aygıtlar desteklenmez. Bunun yerine "network attached usb server"lar tavsiye edilir. Kernel'in kullanması için aktif edilebilir olsada buda performansı çok düşüreceği için tavsiye edilmez.
USB araçlar sanal makine tarafından belli şartlar altında kullanılabilir. Bir USB aracını bir VmWare sanal makinesi ile kullanılabilmesi için, bu aracın bir ağ USB "hub"ına takılmış (attached) olması zorunludur. Bu araçlar, bir ağa bağlanmış olan basit bir "hub"a USB çevre birimlerinin sırasıyla bağlanmasına olanak sağlamak amacıyla üretilmişlerdir. Genelde "hub"a ve dolayısıyla son araca ulaşmak için sanal makine üzerinde üreticinin sürücüsünün yüklenmiş olmasını gerektirirler. Bu konfigürasyon optimal olmamasına rağmen, mümkündür ve potansiyel sanal makine sanallaştırması kararı verirken incelenmesi gerekir.
Paralel/Seri Bağlantı Noktası (port) Araçları
VmWare sanal işletim sisteminin paralel ya da seri aracını sunucunun fiziksel aracına adresleme (mapping) yeteneğine sahiptir. Buradaki sakınca bir fiziki sunucu üzerinde bu araçlardan sınırlı sayıda bulunmasıdır. Belli bir sanal makine için (örneğin bir uygulama için güvenlik ya da lisans girişi "dongle") bu araç için olan gereksinim potansiyel sanal makineyi sanal dünya dışında bırakmaz, mevcut araçların fiziksel sınırlandırılması göz önünde bulundurulması gereken bir konudur. Vmware default olarak paralel ve seri port'u sanal makinelere açık tutmaz ancak kernel parametreleri ile aktif edilebilir. Bunun nedeni bu aygıtların çalışması durumunda sistem performansının dramatik olarak düşeceğidir.
PCI Araçlar
Bazı sunucular tarafından talep edilen özel PCI araçlar VmWare içinde desteklenmiyor olabilir. Bu tür desteklenmeyen araçların önde gelenleri PCI kartları ve Faks sunucu'larıdır. Genel bir kural olarak, özel fonksiyonlar için özel bir PCI kart gereksinimi olan sunucu sanallaştırma için iyi bir aday değildir. PCI veriyoluna takılacak kartlar performansı kötü etkilemeyecek olsada Vmware'in "virtualization layer"da çok daha farklı iş yükleri gerektireceği için desteklenmez. Vmware sadece çekirdek dörtlü olan kaynaklara focus olmuştur.
İyi uyum sağlayabilecek diğer PCI araçları ise Raid/SCSI kartlar ve Ağ kartları olabilir. VmWare ESX sanal işletim sisteminin bir Raid/SCSI araca direkt olarak ulaşmasına izin verir. Bu destek, ara yüzlerin ESX uyumlu sunucuya, normalde sanal sürücü yerine Raid/SCSI sürücüsüne "görme" (connect) izni verebiliyor olmalıdır.
Ek olarak, bir sanal makineye özel bir ağ kartına "bağlanma" (pinned) ya da bir ağ kartının belli bir sanal makineye gelen veya giden trafiğe izin verilmesi amacıyla izole edilmesi izni verilebilir. Bu, süregelen paylaşım miktarını sınırlamasından dolayı optimal olmamasına rağmen bir sanal makine büyük çapta bant genişliğine ihtiyaç duyduğunda veya güvenlik gereksinimleri dikte ettiğinde kullanılabilir.
3 - Sonuç
Görebileceğiniz gibi, bir adayın sanal dünya ile uyum sağlayıp sağlamayacağını belirlemek her zaman kolay bir iş değildir. Bunu büyük bir çoğunluğu eksik faydalanılan çok sayıda fiziki sunucuyu incelerken anladık. İşlemcinin %5'ini ve 256MB RAM kullanıyorlardı diyemeyiz fakat %20-30'un altında işlemci gücü ile çalışan ve belleğinin yarısından azını kullanan sunucular için az rastlanır denilemez. Bu tür durumlarda bu doküman içindeki temel prensipler takip edildiğinde hangi sunucuların "uyumlu" ya da olmadığını belirlemek mümkündür.
"Çekirdek Dört"ü incelemek ve bazı temel genel görüşleri takip etmek çoğu IT yöneticisine ve mimarına neredeyse her ortam içinde VmWare konsolidasyonu için çalışma durumları ve sağlam tasarımlar oluşturmasına olanak tanır.
Çeviri ve Eklemeler: MNG Holding - BİM, v.1.03
Önermeler: Mustafa KAYER
Kaynak: http://www.vmguru.com/modules.php?name=Downloads&d_op=getit&lid=2
27/12/2005 |
|
|
|
