HA Admission Control Hakkında

HA Admission Control Hakkında
Adem YETİM tarafından 4 sene önce eklendi. 1,780 kez okundu.

Son zamanlarda vSphere HA Admission control hakkında çok fazla soru maili aldığım için konuyla ilgili bir makale yazmaya karar verdim. Öncelikle Admission control nedir kısaca öğrenelim;

vCenter Sunucusunun failover koruması sağlamak, sanal makine kaynak rezervasyonlarını garanti etmek ve yeterli kaynakların toplandığından emin olmak için admission control kullanır.

Admission control ile ilgili bilmemiz gereken hemen hemen her şey bu basit cümlede bunu biraz daha detaylandıracak olursak;

  • Failover korumasını sağlamak için yeterli kaynakların kümelenmesini garantilemek
  • Kaynak rezervasyonlarını sağlamak

acDikkat edilmesi gereken en önemli noktalardan bir tanesi Admission control, kaynak yönetimi ile ilgili bir özellik değildir.  HA admission control, bir failover ‘a olanak sağlamak için kaynakların rezerve edilmesi ile alakalıdır.

İkincil olarak admission control sanal makinenin powered-on VM kaynak ayrımlarının kullanabilir olmasını garantiler. Bunun nedeni sanal makinenin failover durumunda cluster üzerinde kaynak ayrımlarının açılmasının başarıyla tamamlanması için yeterli miktarda olmasının gerekliliğindendir! Yani eğer siz 5GB memory ayrımı ayarladıysanız sanal makinenin açılması için tekil hostta 5GB açık memory bulunmalıdır (+ rezerve memory overhead). Eğer bu 5GB’lık makine gerçekte 40 GB kullanıyor ise bu durum swapping / paging ile sonuçlanır, çünkü sadece 5 GB’lık rezerve bellek hesaba katılacaktır!

“+ rezerve memory overhead” kavramına dikkat! Her sanal makinenin bir memory overhead’ı vardır. Bu genellikle birkaç yüz MB ile ölçülür. Başarılı bir açılış denemesi için bu memory’i rezerve etmeniz gerekmektedir. Eğer yeterli “rezerve edilmemiş memory kapasitesi” yoksa açma denemesi başarısızlıkla sonuçlanacaktır. Yani gerçekte o 5GB aslında 5.15 GB olabilir.

Burada dikkat etmemiz gereken detaylardan bir tanesi, admission control sadece powered-on VM’lerin kaynak ayrımlarını hesaba katar. Yani eğer powered-off konumda bir geniş memory ayrımlı VM’iniz varsa bu sizin admission control hesaplamalarınızı etkilemeyecektir!

acontroller

Özetleyecek olursak:

Admission Control yük devretmeye olanak vermek için kaynak ayırmayla alakalıdır. Admission Control bir kaynak yönetim aracı değildir sadece powered-on VM’lerin rezerve kapasitelerini hesaba katar.

 

Admission control nedir öğrenmiş olduğumuza göre şimdi Admission control’ün  mevcut 3 ilkesi ile ilgili bilgilere değinebiliriz.

  1. Host failures cluster  tolerates
  2. Percentage of cluster resources reserved as failover spare capacity
  3. Specify a failover host

Bu özelliklerin her birisinin çalışma şekilleri farklıdır.

Host failures cluster tolerates;

En zor açıklanacak olanı bu özelliktir ancak bunu basit anlatmaya gayret göstereceğim. Bu admission control ilkesi en kötü senaryoyu hesaba katar ve bunu sadece “slotları” kullanarak yapar. Bir slot 2 bileşenden oluşur:

  • Memory
  • CPU

Memory için clusterdaki powered-on sanal makineniz ve bu sanal makine için artı memory overhead için en büyük kaynak ayrımını yapar. Yani eğer atanmış 24 GB memory ve bunun dışında 10 GB’ı olan bir sanal makineniz varsa memory için slot büyüklüğü ~10GB’dır (rezervasyon + memory overhead).

CPU için ise clusterdaki herhangi bir powered-on sanal makinesi için en geniş ayrımı yapar veya CPU slot boyutu için 32MHz (5.0 için bu 256MHz) fabrika ayarını kullanır. Eğer atanmış 8 vCPU’lu ve 2 GB rezervasyonlu bir sanal makineniz varsa slot büyüklüğü CPU için 2GHz olacaktır.

HA admission control toplam kaynak miktarına bakar ve toplam memory miktarını “memory slot büyüklüğü”ne bölerek ne kadar memory slot olduğunu görür. Aynısını CPU için de yapar. Bunu her host için hesaplar. Toplam mevcut memory ve CPU slotları miktarından en kötü senaryoyu alır. Yani eğer 80 memory slotunuz ve 120 CPU slotunuz varsa 80 VM çalıştırabilirsiniz ve en çok hosta sahip slotların sayısı da çıkarılır. Bunun anlamı eğer toplam 50 uygun slotunuz yerine 5 hostunuz ve bunların her birinin memory ve CPU için 10 slotu varsa toplam 40 ile sonlanacaktır.

Basitçe unutulmaması gereken formül: rezervasyonlar  >> slot boyutu  >> en kötü durum.

Bu seçeneği kullandığınız zaman  hesaplanan slot bilgisini ve slot durumunu aşağıdaki script ile öğrenebilirsiniz;

Kaynak Kodu

Connect-VIServer <vCenterSunucusu>

$Cluster = Get-Cluster -Name <clusterismi>
$SlotDetails = $Cluster.ExtensionData.RetrieveDasAdvancedRuntimeInfo()
Write-Host -ForegroundColor Green "`n $cluster Slot Bilgisi`
`n Number of vCPUs per slot: $($SlotDetails.SlotInfo.NumvCpus) `
`n MHz per slot: $($SlotDetails.SlotInfo.CpuMHz) `
`n Memory (MB) per slot: $($SlotDetails.SlotInfo.MemoryMB) `
`n Total Slots = $($SlotDetails.TotalSlots) `
`n Used Slots = $($SlotDetails.UsedSlots) `
`n Available Slots = $($SlotDetails.TotalSlots - $SlotDetails.UsedSlots)"

slotsize

 

Percentage of cluster resources reserved as failover spare capacity;

Bunu açıklamakta çokta kolay değil, ama bu özellik pek çok kişi tarafından yanlış anlaşılmaktadır. Her şeyden önce HA elinde ne kadar kaynak olduğunu görmek için tüm mevcut kaynakları toplar. HA şimdi ise hem memory hem de CPU için belirtilen kaynak miktarını çıkartacaktır. Sonrasında ise HA powered-on sanal makineler için hem memory hem de CPU için rezerve olan kaynakların miktarını hesaplayacak. CPU için, 32MHz’den büyük ayrımı olmayan sanal makineler için 32 MHz fabrika ayarı kullanılacak. Memory için eğer ayarlanmış bir rezervasyon yok ise fabrika ayarı olan 0MB +memory overhead kullanılacak. Eğer memory için rezervasyon ayarlandıysa rezervasyon + memory overhead’ı kullanacak.

Ek olarak kaynak kullanımı, tüketim, aktif kaynak v.b.’lerine bakmaz, rezerve kaynaklara bakar, bunu unutmamamız gerekir!

 

Specify a failover host;

Bu admission control ilkesi sadece bir fail-over olması gerektiğinde, kullanılacak 1 host ayırmanıza olanak tanır. Bunun anlamı cluster’a aşırı yüklenilse bile DRS’in onu kullanmayacağıdır. Bu duruma çok gereksinim duyulmamakla beraber spesifik gereklilikleriniz yoksa bu özelliği kullanmanız çok fazla yarar sağlamayacaktır.

 

Admission control ile ilgili tavsiyem her zaman yüzde bazlı admission control ilkesi kullanılması tarafındadır, çünkü bu en esnek ilkedir. Sayıları yuvarlama riskine girmeden her sanal makine rezervasyon temeline göre bir admission control’ü uygular.

 

Admission control ile ilgili sıkça sorulan sorulardan bazılarını aşağıda paylaşıyorum;

Mevcut yapımızda, ağda 4 ESXi Host ve her hostta 4 VM (Tüm VM’ler için aynı CPU ve RAM Rezervasyonlu) var. Admission Control ilkesi ‘Host failure cluster tolerates’ için 1’e ayarlı. Mevcut 12 slotun tamamı açık durumdaki VM’ler tarafından kullanılmıştır, fail-over için ayrılan 4 rezerve slot hariç.

1) Soru : Şimdi 2 ESXi Host sorun yaşarsa ne olur? ( 2 * 4 VM fail-over ihtiyacı duymakta). Sadece 4 slot mevcut olduğu için HA sadece 4VM ile mi yeniden başlayacak? Ve kalan 4 VM’nin yeniden başlatması başarısız mı olur?

Aynı senaryo ama ilke ‘rezerve küme kaynaklarının yüzdesi %’ = 25%” olarak ayarlı. Tüm mevcut %75 kaynak 16 VM tarafından kullanılır, fail-over için ayrılan %25 hariç.

1) Cevap: Bu senaryoda 4 VM yeniden başlatılacak ve 4 VM yeniden başlatılabilir! Dikkat ederseniz “slot büyüklüğü” ilkesi kullanılıyor ve bu da en kötü senaryoya dayalıdır. Yani eğer slotonuz 1GB ve 2GHz ise ama VMniz açılmak için bundan daha azını gerektiriyorsa tüm VMler açılacaktır. Bununla beraber HA 4 VM’nin açılışını garanti etmektedir. Ayrıca HA yapabildiği kadar VM’yi yeniden başlatır sadece memory ve CPU üzerindeki kaynak ayrımını tamamlaması gerekmektedir.

2) Soru : Şimdi 2 ESXi Host sorun yaşarsa ne olur? ( 2 * 4 VM fail-over ihtiyacı duymakta). Kaynakların %25’ini tükettiği için HA sadece 4 VM ile mi yeniden başlayacak? Ve diğer 4 VM’nin yeniden başlaması başarısız mı olur?

2) Cevap: Bunda da HA yeniden başlatmak için elinden gelenin en iyisini yapacak. Tüm “ayrılmamış kapasitesi” kullanılana kadar yeni VM’leri yeniden başlatabilir. HA sadece rezerve kaynakları garantilemek durumundadır. Genellikle bu rezervasyonlar VM düzeyinde yapmadığı için bu durum oldukça nadir bir durumdur.

3) Soru:  HA yeniden başlatma zamanında VM ayrımını (veya diğer bir faktörü) kontrol eder mi?

3) Cevap: Evet kontrol eder. Eğer ortada yeniden başlatmayı denemeden önce kaynak dağılımlarına dönen bir host varsa bunu doğrulayacaktır.

4) Soru: Eğer Host rezerve kaynakları garanti ederse HA sadece bir VM’yi mi yeniden başlatır ? Yeniden başlatma başarısız mı olur?

4) Cevap: Bunu garantileyebildiğinde sadece VM’yi yeniden başlatacaktır. Eğer bu olmazsa sonra HA bu VM için kaynakları bütünleştirmek için DRS’i çağırır.

5) Soru:  Hiçbir VM rezervasyonu VM seviyesini ayarlamazsa ne olur?

5) Cevap: Eğer ortada bir rezervasyon yoksa HA bu VM’ye yerleştirmek için sadece “memory overhead” arar.

6) Soru :  Her VM için konfigüre kaynakları garanti edecek midir?

6)Cevap: Konfigüre kaynakları garanti etmez, HA sanal makineleri yeniden başlatmakla ilgilidir, kaynak yönetimi ile ilgili değil. DRS kaynak yönetimi ile ilgilidir ve kaynaklara erişimi garanti eder.

7) Soru:  Eğer etmeyecekse sadece 4 VM için konfigüre rezerve kaynakları varken HA 8 VM’yi nasıl yeniden başlatır?

7) Cevap: VM’nin talebini karşılamak için yeterli atanmamış kaynak mevcutsa HA sadece VM’yi yeniden başlatacaktır.

8)Soru : Rezerve kaynakları 8 VM arasında paylaştıracak mı ve kaynak kısıdını dikkate almayacak mı veya ilk gelen ilk mi alacak?

8)Cevap: Sanal makine için gerekli olan tüm kaynakların tekil hostta mevcut olması gerekir! Evet, hiçbir rezervasyon tanımlanmadığı sürece kaynaklar tekil bir hostta paylaşılacaktır.

9)Soru:  Admission control’un HA fail-over olayında hiçbir rolü yok mu?

9)Cevap: Hiçbir Admission Control HA failover durumunda rol sahibi değildir. Admission Control vCenter seviyesinde gerçekleşirken, HA failoverlar ESX(i) seviyesinde gerçekleşir.

 

Sorularınız için VMware Türkiye Kullanıcı Grubu sayfasından bana ulaşabilirsiniz.

 

  • Burhan Abdiler: Elinize sağlık Fatih Bey , detaylı incelemeniz konuyu tamamen açıklayıcı nitelikte ....
  • Tufan ULU: Adem kardeşim, tebrik ediyorum ve başarılarının devamını diliyorum,...
  • Rafet Arslanyı lmaz: Adem Hocam, Tebrikler.. Umarım devamıda gelir :)...
  • Serkan ERSAN: Çok başarılı ve güzel bir anlatım olmuş. Emeğinize sağlık, teşekkürler....
  • Adrenalin .: Teşekkürler Adem Bey....

Bu içerik için henüz hiç kimse görüş bildirmemiş. İlk olarak siz yorum yazamaya ne dersiniz ?

Yorum ekleyin

Doğrulama Kodunuz : 39241587

ÖNEMLİ:
Yorumlarınızı eklerken lütfen girmiş olduğunuz bilgilerin size ait olduğundan emin olunuz. Geçersiz posta adresleri iel yapılan yorumlara yanıt vermek istenildiğinde size ulaşamayacağımız için, geçerli / aktif olarak kullandığınız posta adresiniz ile yorum eklemeniz daha sağlıklı olacaktır. Her yorum yazarı tarafından sorumlu tutulur.

Sayfa başı

Güncellemeler, yeni eklenen içeriklerden anında haberdar olmak için mail listemize adınızı soyadınızı ve posta adresinizi yazarak abone olabilirsiniz.

Adınız Soyadınız
E posta adresiniz
Kaydol