vCenter Server Servisleri ve Dinamik Memory Yönetimi

vCenter servisleri ve dinamik memory yönetimi konusunu derinlemesine inceleyeceğim bu yazıma hoş geldiniz. Öncelikle belirtmek isterim ki vCenter servislerinin her biri vSphere ortamınızın saglıklı çalışması adına kritik roller üstlenmekte VMware Support önerisi haricinde servisler uzerinde oynama ve özellestirme yapılması önerilmemektedir. Bu uyarıyı bir köşede tutarak yazımıza devam edersek vCenter Server for windows ve vCenter server appliance (linux) için vSphere ortam yönetimi açısından fark bulunmadığını cepte tutmak gerekir. Windows sürümünün 6.7 versiyonundan sonra bir devamı olmayacağını ve Appliance için kolların sıvanması gerektiğini de belirtmek isterim.

vCenter Server Servisleri :

vCenter Servislerini incelemeden önce deployment tiplerinden kısaca bahsetmek gerekiyor çünkü yapmış olduğunuz deployment tipine göre bu servislerin toplandığı nokta farklılaşıyor.

1. vCenter Server with Embedded Platform Services Controller:

vCenter Server’i embedded PSC(platform services controller) ile kurduğunuzda PSC’ye ait olan tüm servisler vCenter servisleri ile birlikte tek bir makine üzerinde toplanmakta ve Single Sign-on’da aynı makine üzerinde oluşmaktadır. 6.5u2 ve öncesi versiyonlarda çok tercih edilmeyen bu deployment tipinin tercih edilmemesinin ana nedeni birden fazla vCenteri tek bir ortamdan yönetmek istediğimizde (enhanced link mode) gerekli desteğin sağlanmamasıydı. Ancak 6.5u2 ve 6.7’nin tüm sürümlerinde artık bu yapı embedded deploymentda desteklenmekte ve link mode kurulabilmektedir.

Aynı VM üzerinde iki platform

Embedded Kurulumun avantajları nedir?:

• vCenter Server ve PSC arasında network bağlantısına ihtiyaç olmadığından network altyapısından kaynaklanabilecek sorunları yaşama ihtimaliniz ve zaman senkronizasyonu tarzı sorunları daha az yaşamanız olağandır.

• Eğer windows üzerine kurulum yapıyorsanız daha az lisans gereksiniminiz olacaktır. (Appliance versiyonunda OS için lisans gerekmez)

• Daha az VM ile sorumlu olacaksınız.

Not: Embedded kurulum ihtiyaç olması durumunda external kuruluma döndürülebilir.

     2. vCenter Server with External Platform Services Controller:  

Bu deployment tipinde önce bir yada daha fazla PSC kurulur site’lar oluşturulur sonrasında vCenter server kurulan PSC’ye point edilerek sistemin çalışması sağlanır. External bir yapıda yönetim ve upgrade/update süreçleri zorlaşsa da Highly available bir ortam için mantıklıdır. Ve özellikle 6.5u2 sürümüne kadar enhanced link mode için bir zorunluluktu. Bugünkü yapıda ise bu tip bir kurulum zorunluluk olmamakla birlikte çoğu durumda servis izolasyonu ve kaynak dağıtımı açısından mantıklı görülmektedir. Aşağıya örnek bir yapı paylaşıyorum ve şunu belirtmek istiyorum ki windows ya da linux olması farketmez farklı tip psc/vcenter birbiri ile konuşabilir.

vCenter Server Servisleri Kim neye yarar:

applmgmt : Appliance ortamları için API endpoint ve Appliance yönetimi için gereklidir. Bu calışmazsa 5480 portundan yönlendirilen login istekleri çalışmaz.
lwsmd : likewise service manager hostların Active directory katılımı ve user authentication için gereklidir.
vmafdd: Authentication Framework servisidir ve client tarafına sunulacak sertifikaları sağlar her durumda çalışması gereklidir.
vmonapi: vCenter servislerinin durdurulup başlatılması için API servis sağlığını kontrol eder. Çalışmazsa third party üzerinden servisler için API call ve CLI işlemlerini gerçekleştiremezsiniz.
vmware-analytics: VMware Analytics Service CEIP’e katıldıysanız anonim datanın toplanmasını ve VMware Cloud’a gönderilmesini sağlar.
vmware-cm : Component Manager : Componentlerin vc’ye register edilmesi ve lookup işlerini yapar.
vmware-content-library : Bu servis content library özelliklerini ve vCenter instance’ları arasındaki senkronizasyonu kontrol eder.
vmware-eam : ESX agent manager servisi third party entegrasyonları ve OVF deployment için gereklidir. NSX tarzı bir uygulama için hayatidir.
vmware-perfcharts: Performance Charts servisi vCenter server içerisindeki objeler için performans datasının toplanmasını grafik arayüzü ile sunulmasını sağlar.
vmware-rhttpproxy : vSphere API’ya yapılan istekleri karşılamakla sorumludur. Ayrıca managed object browser (MOB)’da bu servis tarafından karşılanır.
vmware-sca : Servis konfigürasyonlarını kontrol eder. Service-control CLI’ı servisleri tek tek konfigüre etmek için kullanabilirsiniz.
vmware-sps : vSphere Profile-Driven Storage Service storage profillerini yönetebilmek için gerekli olan servistir.
vmware-statsmonitor : Appliance monitoring service olarakda adlandırılır ve appliance OS’in kaynak kullanımını izler.
vmware-updatemgr : Update Manager servisidir. Update manager kullanabilmeniz için çalışmalıdır. Update manager arayüzünde hata alırsanız durdurup çalıştırın.
vmware-vapi-endpoint : vAPI için bağlantı noktasıdır. vSphere ortam otomasyonu için olmazsa olmaz. 
vmware-vmon : vCenter servislerinin durdurulup başlatılması işlemlerini gerçekleştirir.
vmware-vpostgres: vPostgres servisidir ve Appliance sürümlerinde vCenter Database postgresql üzerinde tutulur. Çalışmazsa vCenter fonksiyonelliğini kaybeder.
vmware-vpxd : ESXi hostlarla konuşan ve yöneten en hayati servistir. 6.0 ve öncesinde UI bağlantısı da bu servise bağlıydı.
vmware-vsan-health : vsan health monitoring servisidir. vSAN kullanmıyorsanız gereksizdir.
vmware-vsm :VM ve vApp’ler için sanal servis yapılandırmasını kontrol eder.
vsphere-client: Yeni sürümlerdeki flash arayüzü sağlayan servistir.
vsphere-ui: Yeni HTML5 web arayüzü için kullanılan servistir.
vmcam : vSphere authentication proxy olarak geçer ve ESXi hostları AD’ye alırken proxy gibi davranir. Her hostta tek tek AD bilgisi girmemiz gerekmez.
vmware-imagebuilder : Image Profilleri oluşturmanızı ve düzenlemenizi sağlar. Kritik değildir.
vmware-mbcs : VMware Message Bus Configuration Service. ESXi hostların RabbitMQ konfigurasyonunu vCenter üzerinden yapabilme yeteneği sağlar. Default olarak kapalıdır.
vmware-netdumper: Netdumper servisi ESXi host DUMP düşürdüğünde mevcut makineye değilde network üzerinden vCenter server’a yönlenmesini sağlar. Bu sayede PSOD gibi durumlarda DUMP analiz için korunmuş olur.
vmware-rbd-watchdog: VMware vSphere Auto Deploy Waiter auto deploy özelliğinin kullanılabilmesi için gerekli servistir.
vmware-vcha : vCenter HA kurulduğunda kontrol bu servis aracılığıyla yapılır. HA yoksa çalışmasına gerek yoktur.
vsan-dps : VMware VSAN Data Protection Service

vCenter Servisleri Memory Yönetimi :

vCenter içerisinde herbir servis için dinamik memory yönetimi mümkündür. vCenter içerisinde cloudvm-ram-size tool’unu barındırmaktadır ve bu tool ile hangi servisin ne kadar memory kullanacabileğini görüntüleyebilir/ayarlayabilirsiniz. Çoğu durumda default olarak gelen bu sizing bazı durumlarda bizi çıkmaza sokabilir ve elle müdahale gerekebilir. Bu yüzden gerektiği durumda nasıl müdahale edilebileceğini göstereceğim. Öncelikle kimde ne var onu öğrenelim.

cloudvm-ram-size -l

Burada gördüğümüz üzere VM’e atamış olduğumuz toplam ram miktarı servisler arasında paylaştırılmış durumda. Buradaki metrikler VM’in memory yetmezliğinde çıkabileceği maksimumu refere eder. Miktarda değişim yapmak için : cloudvm-ram-size -C miktar servis_ismi düzeninde giriş yapılmalıdır. Pekiyi bu artırıma azaltıma neden ihtiyaç duyarım şeklinde bir soru soracak olursanız,
ilk kurulumda vCenter için seçilen ram ve CPU miktarı third-party pluginler olmadan hesaplanan miktardır. Yani vCenter+ESXi için hesaplanmış optimum miktarlardır. Eğer ortamda vSAN, Horizon, NSX, SRM, RP tarzı uygulamalar ile backup monitoring uygulamaları vCenter ile iletişim halinde ve işlerini onun üzerinden gerçekleştiriyorsa standart miktarların üzerine çıkıp tuning yapma ihtiyacı doğacaktır. Bu durumda cloudvm-ram-size toolu ile duruma göre değişimler yapabilir hatta memory’i overcommit edebilirsiniz. Tabi overcommit durumunda swap’a düşebileceğinizi aklınızda bulundurmanız önemli.

Örneğin yukarıdaki ekran görüntüsüne göre HTML5 client için kullanılan vsphere-ui servisinin kullanabileceği miktarı artırmak veya azaltmak istediğimde:

cloudvm-ram-size -C 1846 vsphere-ui

Gördüğünüz üzere HTML5 client için ayrılan miktarı yükselttim. Şimdi vimtop ile mevcut kullanım durumuna bakacak olursak H5 web client 935 MB kadar bir miktar kullanmakta ve hala ciddi bir miktar alanı bulunmakta.

Başka bir yararlı komut olarak cloudvm-ram-size -S kullanabiliriz. Burada da verilen miktarı, max çıktığı miktarı ve şuanki miktarı gösteren bir tablo karşımıza çıkar.

Ek not olarak Appliance sürümlerinde shell’den bu toolu direk kullanabilirken windows kurulumları için şu yolu takip etmek gerekir : C:\ProgramFiles\VMware\vCenter Server\visl-integration\usr\sbin\cloudvm-ram-size.bat 

Sonuç ve Yorumlar: 

vCenter server eski sürümlere göre memory yönetimini çok iyi yapsada bazı durumlarda elle müdahale gerekebiliyor. Örneğin 8GB RAM’lı bir deployment tipinde +1GB eklemek istediğinizde bu miktarı vCenter servisler arasında mevcut paylaşım yüzdesine göre paylaştıracaktır. yani şuanda 30% vpxd servisinin ise eklediğiniz 1GB’ında %30 kadarı vpxde alacaktır ancak vpxd servisinde her hangibir çıkmaz yaşamadığımız halde neden bu miktarı ona atayalım? İşte bu durumda yukarıda anlattığım şekilde modifiye etmek işimize yarayabilir. Bu senaryoda örneğin flash client’dan ram konusunda uyarı alıyorum ve eklediğim 1GB’ın tamamını web client’a vermek istiyorum. cloudvm-ram-size tool’u bu işi yapacak adamın ta kendisidir 🙂

Eksik veya hatalı olduğunu düşündüğünüz noktaları yorum olarak belirtebilirsiniz.

ESXi Kaynak yönetimi için şu makalemi inceleyebilirsiniz : ESXi Kaynak Yönetimi

Teşekkürler.