ESXi Kaynak Yönetimi ve Kaynak Grupları

ESXi Kaynak Yönetimi ve Kaynak Grupları

Günümüz işletim sistemleri fiziksel kaynak yönetimi ve kaynakların yazılımlar için etkin bölüştürülmesi konusunda çok iyidir. Kaynakların etkin bir şekilde bölüştürülmesi, performans konusunda ciddi bir izolasyon sağlarken uygulamaların da güvenli bir şekilde çalışmasını garanti eder.

VMware ESXi ile sanallaştırılmış bir ortamda ESXi (hypervisor), etkin bir fiziksel bölüştürme sağlayarak sanal makinelerin ihtiyaç duyduğu kaynağa en iyi şekilde erişimini mümkün kılar. Bu durum aynı fiziksel ortamı(host) kullanan sanal makinelerin(birden fazla) birbirini etkilememesini sağlamaktadır.

ESXi fiziksel kaynak yönetimini, resource grupları ile hiyerarşik bir yapı ile sağlamaktadır. Bu durum RAM ve CPU için geçerli olup vSphere ürünlerinde görmüş olduğumuz resource pools yapısı ile neredeyse birebir benzeşmektedir. Kaynaklar hiyerarşik bir tree (ağaç) yapısı ile haritalanmış olup manuel olarak ayarlanabildiği gibi tamamen yazılım kontrolüne de bırakılabilir.
Yukarıda bahsetmiş olduğum kaynak yönetimi ve bölüştürme için geçerli en temel üç tane nitelik bulunmaktadır. Bunlar : reservation, reservation limit ve shares’dır.

İyi yapılanmış bir datacenter ortamında bu üç niteliği efektif bir şekilde kullanmak ve iyi bir bölüştürme yapmak performans darboğazlarına engel olacak, bununla birlikte performansı doruk noktaya taşıyacaktır.

Bir örnek vermek gerekirse 2TB pRAM sahibi bir host düşünün. Bu host üzerinde memory yönetimi 2 parçalı yapılmakta ve 1’er TB X,Y olmak üzere 2 kaynak grubu oluşturulmuş. Elimizde 2 tanede A ve B olmak üzere VM mevcut. Bu VM’lerin her biri 680GB vRAM payı ile rezerve edilmiş. Bu senaryoda A VM’i X, B VM’i Y grubunda çalıştırılırsa bir sorun oluşmayacaktır. Ancak A VM’i X grubunda power-on edildikten sonra B VM’i de X grubunda power-on edilmeye çalışıldığında istenen kaynak hiç bir zaman sağlanamayacağı için asla power-on olmayacaktır. Kaynak bölüştürülmesini sanırım en basit haliyle bu şekilde anlatabilirim.

Peki ESXi hypervisor’ün bu duruma yaklaşımı nedir?

ESXi memory yönetimi için iki parametreyi göz önünde bulundurmaktadır: Host bazında ve VM bazında. VM bazında kaynak grupları CPU ve memory yönetimi için reservation, limit ve shares niteliklerini bize sunarken, Host bazında kaynak grupları hiyerarşik ağaç yapısına ve hypervisor kontrolünde otomatik bir akış şemasına sahiptir.
Bu makalede VM bazında kaynak yönetimine değinirken, daha çok Host bazında kaynak gruplarına (Memory) değinmeye özen göstereceğim. Şuanda konuyu anlatmak için VMware tarafından sunulmuş olan bazı grafikleri kullanmak zorundayım 🙂

Hiyerarşik Ağaç Yapısı Nedir?

Fiziksel RAM ve CPU ESXi hypervisor tarafından bir ağaç yapılandırması ile gruplandırılmaktadır. Bu yapılandırma kaynak ağacı (resource tree) olarak adlandırılmakta ve kaynak organizasyonu ve bölüştürülmesi için hayati önem arzetmektedir. Öyle ki yanlış yapılandırılmış bir kaynak ağacı tüm sistemin yanıt veremez duruma düşmesine sebep olabilmekte, işleri içinden çıkılmaz bir hale sokabilmektedir. Genel olarak teoriden bahsetmek istememe rağmen bazı durumlarda ESXi host üzerinde kaynak gruplarına müdahale etmemiz gerekebilir. Bu konu içinde makalenin devamında gerekli teknik altyapıyı sağlıyor olacağım. Kaynak Ağacının neye benzediğine gelecek olursak :

Yukarıda ki görselde kök dizinden(G0) başlayarak kaynak gruplarının genel konseptini görebilirsiniz. Kök dizinden başlamak üzere Parent ve Child grupları bulunmaktadır. Örnekte G0 parent G2 child olarak nitelendirilebilir. Bu kaynak gruplarının dışında User world ve VM’lerde ESXi tarafından kaynak grubu kategorisinde sayılmaktadır ve kaynak ağacında leaf olarak özel container yaratmaktadır. Burada Mavi renkte belirtilmiş olan kaynak grupları ve VM, User World arasındaki temel fark, VM ve UW memory kullanırken resource gruplar hiçbir şekilde memory tüketmez veya stoklamaz. VM ve UW’lerden canavar olarak bahsedeceğim.

Görselde belirtilen 4 nitelik: mem.resv, mem.limit, mem.shares ve mem.resvLimit kullanıcı tarafından değiştirilebilen niteliklerdir ve müdahale edilmediği takdirde ESXi tarafından default olarak dağıtılmaktadır. Bunları tek tek açıklamak gerekirse

mem.resv : bu nitelik ilgili kaynak grubu altındaki memory kullanan herkese dağıtılacak toplam garanti miktarı temsil etmektedir. Burada memory kullanan canavarlar VM’ler ve UW’lerdir. Garanti edilen miktar tamamıyla kaynak tüketenler için önceden ayrılmaz. Burada verilen mem.resv değeri, canavarlar ihtiyaç duyduğunda hiyerarşiye göre başka yerlerden kaynak alınmasını garanti etmektedir.

mem.limit : Grup altındaki canavarların toplamda kullanabileceği maksimum memory miktarını temsil etmektedir. Eğer olurda canavarlar verilen limiti geçerse ESXi devreye girip bunu engelleyecek ve niteliklere göre dengeyi koruyacaktır. Bir kaynak grubu için mem.limit her zaman mem.resv’e eşit veya ondan büyük olmalıdır.

mem.shares : Grup altındaki canavarların öncelik tespiti için verilen niteliktir. Örneğin 1TB memory için yarışan 2 VM mevcut, ilk VM 1000 pay ve ikinci VM 4000 pay sahibi ve herbir VM’e 1TB vRAM verilerek memory overcommit edilmiş. Bu durumda ikinci VM her zaman toplam fiziksel memory’nin 80%’ine erişim önceliğine/payına sahip olacaktır.

mem.resvLimit : Bu nitelik mem.resv niteliğinin üst sınırı gibi çalışır. mem.resv minimumu temsil ederken mem.resvLimit maksimum sınırdır.

Yukarıda açıkladığım nitelikler VM bazlı kaynak grupları için geçerli iken host bazlı kaynak grupları içinde aynı anlamı teşkil etmektedir. Ek olarak aynı nitelikler CPU içinde aynı anlamları ifade etmektedir.

Host Bazlı Kaynak Ağacı nasıldır?

Durumu host bazında incelediğimizde karşımıza 4 Temel grup çıkar. Bunlar : VIM, SYSTEM, USER ve IDLE gruplarıdır. Her grup içerisinde kendi ayrışmasına sahiptir ve ekstrem durumlar dışında izole bir yapıdadır. Burada tüm powered-on VM’ler USER kaynak grubu altında toplanmakta ve VM haricinde memory tüketimi olan UW’ler ESXi tarafından diğer kaynak grupları altında çalıştırılmaktadır.

Bu görselde user grubunda sonradan elle oluşturulan veya otomatik olarak atanan VM’lere ayrılan kaynak grubu temsil edilmektedir. Yani oluşturduğumuz bir resource pool bu grup altına konuşlanacaktır. Bunun dışında host servisleri ve kernel modülleri içinse SYSTEM grubu altında bir tanımlama yapabiliriz. Konuyu netleştirmek için canlı bir ortamdan örnekler vereceğim:
Mevcut yapılandırmanızı ve çok daha detaylı bilgilerin reservation gruplarını görmek için öncelikle hosta SSH ile bağlanalım.

Shell’e düştükten sonra şu komutu çalıştıralım :

esxcfg-resgrp -l |less

Aşağıdaki gibi bir ekranla karşılaşacağız. Burada kök dizin Group Name kısmında belirtilen host grubudur ve diğer tüm gruplar bu grubun cocuklarıdır. Memory allocation ve CPU allocation kısımlarına dikkatli bakılırsa mevcut kaynakların tümü bu grup için rezerve edilmiştir. Temel amaç bu grubun fiziksel kaynakları child gruplara dağıtabilmesini sağlamaktır. Parent gruplarda tepeden inme bir kısıtlama yapmak pek mantıklı değildir. Burada Host 5GB RAM ve 2vCPU sahibi.

Diğer grupları incelemek gerekirse : SYSTEM grubu Host grubunun child grubudur. Yani host System’a parent’dır.

USER grubu Host grubunun child grubudur. Yani host USER’a parent’dır.

VIM grubu Host grubunun child grubudur. Yani host VIM’e parent’dır.

Kernel grubu System grubunun child grubudur. Yani SYSTEM Kernel’a parent’dır.

Bunların dışında birçok USER World Grupları bulunmaktadır. Aslında burayı anlatmamdaki temel amaç mevcut hiyerarşiye farkındalık yaratmak, bununla birlikte ESXi üzerinde third-party script calıştırmak istediğinizde host ve management servislerinin bu scriptin yaratabileceği potansiyel sorunlardan izole olmasını sağlayabilmenizi amaçlamamdır. VPXA, HOSTD, WATCHDOG, SYSLOG gibi core servislerin her zaman ihtiyaç duydukları memory, cpu miktarına ulaşabilmesini garanti etmemiz sorun yaşamamamız için hayatidir.

Örnek bir senaryoda 3rd-party bir python scripti VPXA ve HOSTD ile ortak kaynak grubunda çalışır ve bu servislerin ihtiyaç duydukları kaynağa erişimini bir memory açlığı yaratarak kısıtlarsa, karşılaşabileceğimiz en basit sorunlar şunlardır : host yönetilemez olur, inventory görüntülenemez, HA agresif davranıp gereksiz restart verebilir. Sonuç olarak potansiyel kesinti!

Bazende duruma göre grup yapılarında yapılan oynamalar sistem sağlığı açısından yararlı olabilir.

Örnek bir senaryo :

3 Grubumuz var bunlar: IPFIX, DataSectionMgr ve SVGAConsole bu gruplar altında çalışan çeşitli UserWorld’ler mevcut ve 3 Gurubun ortak Parent ID si 60 numaralı INIT grubu.
INIT Memory Max:200MB , Min:200MB
IPFIX Memory Max:unlimited , Min:32MB
DataSectionMgr Memory Max:100MB , Min:32MB
SVGAConsole Memory Max:64MB , Min:0MB

Burada 3 grupta ortak havuzu kullanıyor ancak aralarında birtanesi örneğin IPFIX grubunda bir process çıkıpta kardeşim burada irade benim derse (karşılaşılan bir durumdur) DataSectionMgr ve SVGAConsole altında çalışan birçok process için geçmiş olsun demeye başlayabiliriz. Doğru bir yapılandırmada ya yeni grup oluşturulup özel bir miktar belirtilmeli ya da sorun yaratması muhtemel process’ler sistem sağlığı ve olağan performans açısından doğru limitlerle sınırlandırılmalıdır.

Nasıl Yeni Grup Eklenir veya limitler belirlenir?

— geliyor —

Memory Reserve ve Memory Reserve Limit Senaryoları :

Senaryo açıklamaları : (geliyor…)

Yukardaki görselde “G” grup isimlerini temsil etmektedir. Grup isimlerinin altında görülen değerler ise mem.resv / mem.resvlimit nitelikleridir. Yukarıda bunların ne anlama geldiğini açıklamıştım. G0 grubu için toplam kapasite 100 olarak belirlenmiştir. G0 grubunu hostun toplam memory miktarı olarak değerlendirebilirsiniz. Şimdi senaryoları inceleyelim.

1. a : Bu görsel kaynak ağacının mevcut (başlangıç) durumunu göstermektedir.
2. b : G3 grubunun memory reservation’ı 10 dan 30 değerine çıkartılıyor. Bu durumda parent havuz(G2) toplam rezervasyonu karşılayabileceği için fail olmayacaktır. 10+30=40 (G2 grubunda(parent) reservation limit=40)
3. c : Bu görselde G1 ve G3 gruplarının memory rezervasyon limitleri 80 olarak ayarlanmıştır. Bu senaryoda Memory rezervasyon limiti ne olursa olsun, memory rezervasyonu uygun değerlerde kaldığı sürece bir fail durumu oluşmayacaktır. Görseli detaylı incelersek G1 için 50 G2 için 30 rezervasyon bulunmakta. Bu parent olan G0’ın kapasitesini aşmıyor. Bununla birlikte G3 ve G4 içinde 10 mem.reserv bulunmakta bunlarda parent grupları olan G2’nin limitini aşmamakta.
4. d : Bu görselde G1 50/& G2 30/40 olarak ayarlanmış durumda. G2’nin child gruplarına bakacak olursak G3 40/& ve G4 10/& . Bu senaryoda G2 nin child gruplarında istenilen toplam rezervasyon 40+10 birim ancak ana grup olan G2’nin karşılayabileceği maksimum miktar=40. Bu durumda G2 grubu istenen kaynağı sağlamakta fail olacak ve limiti aşan VM power-on işlemleri ya da UW’ler çalışmayacaktır.
5. e : Bu görselde G2 reserv.limit 80 birim G3 reserv 50 ve G4 10 birim olarak ayarlanmış. G2 grubu 80 birime kadar kapasite artışında fail olmayacaktır. Ancak kök dizinde işler beklediğimiz gibi gitmeyecektir. G3+G4 = 60 birim reserv bulunmakta ve G1=50 reserv edilmiş. Bu durumda kök dizinin maksimum kapasitesi olan 100 birim aşıldığından G0 kaynak yönetiminde fail olacaktır.
6. f : Bu görsel için gerekli rezervasyon işlemleri başarılı olacaktır. Burada nedenini sizlerin takdirine bırakıyoruz. 🙂

Sonuç :

Bu makalede ESXi memory, CPU gibi fiziksel kaynakların yönetimine odaklandım. Boş yerleri kısa sürede doldurmayı planlıyorum. Eksik veya yanlış gördüğünüz yerleri yorum oralarak bana bildirebilir veya LinkedIn’den ulaşabilirsiniz. Daha iyi bir kaynak yönetimi adına. Yaşasın Resource Groups 🙂

İlgilisine kaynaklar : https://labs.vmware.com , https://docs.vmware.com/