Sunucu Sanallaştırma çözümleri fiziksel ortamlarda sahip olmadığımız yetenekleri de bizlere sunmaktadır. Kullanmayın önerisini yapmış olduğumuz Ckechpoint (snapshot) özelliği gibi kullanmayın önerisini yapmış olduğumuz dynamic virtual disk özelliği gibi ve kullanmayın demiş olduğumuz Dynamic Memory özelliği gibi.

Sunucu Sanallaştırma çözümlerinin sunmuş olduğu bu ve benzeri bir çok yeteneğe fiziksel ortamlarda sahip değiliz. Bu özellikler sanallaştırma sistemlerinin bizlere sunmuş olduğu bir yetenek gibi gözükse de bir çok dez avantajı olan özelliklerdir. Iş kritik uygulamaya sahip bir çok uygulama tarafından desteklenmeyen , kullanılan sanal makine (virtual machine) de ciddi performans kaybı yaşatan ve bunların ötesinde bütün sanallaştırma ortamında domino etkisi yapabilen bir özelliktir.

Dynamic Memory özelliğinin  nasıl çalıştığını ve mimarisini bu çalışmamız da sizlere paylaşıyoruz.

Geleneksel mimaride oluşturulmuş sunucu sanallaştırma alt yapısını görmektesiniz. Sanallaştırma Mimarisi Microsoft HyperV Server.

HyperV Server 128 GB fiziksel Bellek, 2 Socet fiziksel işlemci ve toplam de 8 adet çekirdeği bulunan bir fiziksel sunucu. HyperV Server 512 Adet çekirdeği ve 24 TB fiziksel belleğe kadar desteklemekte. Ölçeği Küçük tutma amacım konuyu daha sade bir şekilde anlatmak için.

Her bir fiziksel Bellek sıralı bir şekilde DIMM yuvalarına yerleştirilmiş ve fiziksel tasarımda Doğru bir şekilde yapılmış. Dynamic Memory  aktif edildiği sanal makine (virtual machine) özelliklerine bakıyoruz.

Dynamic Memory ayarları, Starttup Bellek 24 GB olarak yapılandırılmış. Yani sanal makine (virtual machine) ilk start edildiği zaman en fazla kullanacak olduğu bellek boyutu 24 GB olarak belirlenmiş. Bizler Dynamic Memory ile HyperV Server ’in ikinci sürümünde tanıştık ve startup bellek ayarı da HyperV server’in üçüncü sürümünde gelen bir özellikti.

Sanal makine (virtual machine) açıldıktan sonra ve işletim sistemi üzerinde ki bütün servisler başladıktan sonra kaynak tüketimi geri çekilecektir. Geri çekilme boyutu olarak da yani minimum Ram ‘I 16 GB olarak belirledik. Bu makinemiz 16 GB altına hiç bir zaman için düşmeyecek.

Bu özellikte Startup özelliği gibi üçüncü sürümde geldi.

Hatırlarsanız HyperV Server ortamlarında ki kaynak ayırma kuralını sizlere paylaşmıştım. Ayrılan bir kaynak, yani işlemci ve bellek, sanal makine (virtual machine) kapatılana kadar ayrılmış olduğu fiziksel kaynak üzerinden geri alınamaz.

Bu kural çerçevesinde 16 GB fiziksel bellek sanal makinenin kullanmış olduğu fiziksel işlemci üzerinden verildi. Yani QPI olarak adlandırmış olduğumuz local memory access ‘I kullanmakta. Ve son ayarımız Maksimum Bellek olarak ‘da 32 GB bellek işaretlendi.

Özet ile sanal makine (virtual machine) ilk açılışta 24 GB bellek kullanacak. Ilk açılma sırasında ki iş yükü tamamlandıktan sonra alışa gelmiş performansa geri çekildiği zaman 8 GB belleği geri verecek. Ve iş yükü artış gösterdiği zaman da 32 GB kadar büyüyecek.

Ve bu değişkenlikler sadece fiziksel bellek üzerinde olmayacak Virtual machine config File (VMRS ve VMCX) dosyasının barınmış olduğu veri depolama havuzu üzerinde de sürekli olarak veri oluşturulacak ve silinecek. Veri depolama havuzunun sahip olduğu toplam performansa da etki edecek olan bir yapılandırma.

Bildiğiniz gibi HyperV’ nin 8 nci sürümünde Vmconfig file dosyası XML ‘den VMCX ve VMRS olarak değiştirildi ve her bir VM config verisi sanal makinenin kullanmış olduğu bellek boyutu kadar oldu.

Dynamic Memory , sanal makine (virtual machine) taleplerine göre değişmekte. Sanal makine fiziksel bellek üzerinden fiziksel bellek ayırırken bir başka iş yükü ve performans kaybı da veri depolama havuzunda yaşanmakta.

Dynamic Memory özelliği veri depolama havuzunun toplam performans değerlerine de etki etmekte. Eğer, veri depolama havuzu üzerinde ayırma işlemlerini, sıcak veri soğuk veri ve ılık veri gibi değerleri vermediyseniz veri depolama havuzu üzerinde ciddi iş yükü oluşacak ve bütün system bundan etkilenecek.

Toplam sunucu sanallaştırma sistemimize bakalım. Hyper Server üzerinden Küçük ve büyük ölçeklerde birden fazla sanal makine (virtual machine) çalışmakta. Her bir sanal makine (virtual machine) sahip olduğu ölçek çerçevesinde fiziksel kaynak üzerine yerleşti ve hizmet vermekte.

Bütün sanal makineler sağlıklı bir şekilde çalışırken Dynamic Memory aktif duruma getirdiğimiz sanal makine (virtual machine) üzerinde ek iş yükü oluştu. Sanal makine kendisi için ayrılan ilave 16 GB ‘lık dinamik belleği HyperV Server ‘dan talep etti. HyperV Server ise Dynamic Memory  aktif edilen sanal makineye birinci fiziksel işlemci üzerinden sanal işlemcileri ve sanal bellekleri vermişti. 16 GB ‘lık sabit bellek birinci işlemci üzerinde sanal makineye ayrılmıştı.

HyperV server, Diğer sanal makinelere de adil bir şekilde davrandı ve sanal makine (virtual machine) taleplerini en uygun şekilde dağıttı. Birinci işlemciye bağlı bulunan bütün fiziksel bellekler kullanılmakta. Sanal makine ise Ek bellek talep etti.

Ana kuralımızı hatırlayalım ve bu senaryo da HyperV Server ‘ın davranışını izleyelim

Ana kuralımız, HyperV server tarafından ayrılan bir fiziksel kaynak sanal makine (virtual machine) kapatılana kadar yada başka bir host a taşınana kadar geri alınmaz. Bu senaryo da bütün sanal makine fiziksel kaynak üzerinde yerlerini almış durumda.

HyperV Server bu durumda yapacak olduğu işlem sanal makine ‘nin istemiş olduğu ek Dynamic Memorydiğer işlemci üzerinden verecek. Local Access Memory Kullanan 16 GB ‘lık bellek %100 değere sahip olurken Remote Access Memory ‘I kullanan bellek %50 ‘ye varan yavaşlıkta çalışacak.

Dynamic Memory sanal makine performansına etki ettiği gibi bütün sanallaştırma sisteminin performansına da etki etmekte. Bazı durumlarda sanal makinenin taşınmasına, yeniden başlatılmasına ve geri yüklemesine neden olmakta.

Fiziksel sunucu üzerinde yeterli fiziksel bellek kalmadığı zaman depolama havuzu da bir sanal bellek (Virtual Machine Smart Paging File) gibi kullanmakta ve bu durumda da başka problemleri oluşturmakta. Bu problemlere ek olarak bir de HyperV Server üzerinde Numa Spanning ayarları yapıldıysa problemleri bulmak samanlıkta iğne aramaktan farksız olmamakta.

Bu senaryolar ile bir çok kez karşılaştık ve bu türden bir performans problemini bulmak uzun iş eforlarına neden olmakta.

Pera Bilgi Sistemleri olarak Proactive Services kapsamında Hyper-V  Server Virtualization özelinde bu çalışmaları yapmakta ve oluşan dar boğazları ve performans kayıplarını kuruma özel raporlar ve iyileştirme planlarıyla sunmaktayız.