vCenter 5.5 Best Practices – Kurulum & DB Maintenance

Daha önce ki bir yazımda vCenter için JVM Heap Size best practice’lerinden bahsetmiştim. Bu yazımda ise vCenter’ın ilk kurulum ve DB ile ilgili kısımlarına eğilmek istiyorum.

High Level Architecture And Sizing

Tasarım:

Öncelikle vCenter’ınız ister sanal isterseniz de fiziksel(kişisel tecrübelerimden yola çıkarak fiziksel bir kurulumun sanal bir kuruluma göre bariz bir üstünlüğüne rastlamadım) bir OS üzerinde olsun yapmanız dikkat etmeniz gereken ilk nokta vCenter veri tabanını ve vCenter servislerini iki ayrı sunucuda barındırılmasıdır. vCenter 5.5 ile birlikte önemi gittikçe artan Web arayüzü ve vCOP,vCO,vCAC gibi servisler sebebiyle de vCenter servislerine(Web,Tomcat,Inventory Service,SPS,API) eskiye nazaran daha çok yük binmektedir;normal şartlar altında bile çok yoğun yük altında olan DB ile aynı sunucu üzerinde olması hem esnekliğinizi azaltır hem de performans sorunlarına sebep olacaktır.

Eğer sanal bir ortamda yukarıda ki önerime uyup veri tabanı ve servisleri ayırırsanız aşağıda bahsettiğim iki noktaya dikkat etmeniz gerekmektedir.

Uygulama sunucusu ve DB sunucusunun Affinity rule ile mutlaka aynı host üzerinde bulunması sağlanmalı.
Her iki sunucunun bir birleriyle iletişime geçmek için kullandıkları NIC’lerin aynı subnet üzerinde olması

Sizing:

Sizing konusu hali hazırda çalışan bir ortam olmadan ön görülmesi bir konu olmakla beraber Vmware’in konu hakkında yayınladığı KB iyi bir başlangıç olmaktadır. Kurulum esnasında size sunduğu JVM ve tahmini kaynak ihtiyacı sadece envanter sayınız baz alınarak önerilmektedir.Sizing konusunda size başlıca önerim vCenter’ın loglama seviyesi, günlük işlem seviyesi, envanteriniz, vCenter ile entegre çalışan öteki servisler ve vCenter servislerini kullanım yoğunluğunuza göre bir tunning işlemi yapmanız ve belli aralıklarla sizing’i tekrardan değerlendirmenizdir.

JVM ayarları:

Sanırım üzerine en çok tartıştığım konulardan birisi budur. Doğru bir JVM heap size ayarı sık kullandığınız vCenter servislerinin performansını artırırken kullanılmayan veya ihtiyaç duyulmayan servislerin gereksiz kaynak tüketimini engeller. Örnek vermem gerekirse bir çok sistem yöneticisi 5.5 versiyonunda hala vSphere Client’ı Web arayüzüne tercih etmektedirler, az kullanılacak bir servisin çalışma esnasında ayıracağı minimum kaynak miktarını düşürmemiz bizim yararımıza olacaktır.

JVM içerisinde iki temel ayar bulunmaktadır maksimum ayırabileceği memory ve servis başlatıldığı anda minimum ayırabileceği memory miktarı. Bu ayar standart bir vCenter kurulumunda sorun çıkartmamakla beraber vCOP,vCO ve SRM servislerini yoğun olarak kullanan firmalar için ihtiyaca göre değişiklik yapılması önerilmektedir.

Kullanılmayan servislerin minimum allocation seviyelerini düşürebiliriz.
Web GUI 5.1 versiyonuna göre tam 2 katı memory harcamaktadır.
Inventory servisi DB için bir cache servisi olarak çalışmaktadır. Bu sebepten vCenter’dan yoğun olarak bilgi alan servisler(vCOPS) bu servis üzerinden veri toplamaktadır. Burada toplam iteam ve alarm sayımıza göre bir değerlendirme yapılmalıdır.

Inventory Service:

Inventory servisi vCAC,vCOPS gibi bilgi toplayan veya bu bilgiler üzerinden anlık karar veren sistemler için kritik bir hal almıştır. Bu servisin tek başına yoğun bir vCenter üzerinde 2-3K kadar yaptığı bilinmektedir. Bu servis üzerinde ki yükü azaltmak için

Uygun heap size
DB performans ayarları(bir sonraki bölüme bakabilirsiniz)
İnventory servisi gömülü bir DB olduğu için onu ayrı bir diske(SSD) almanın performansa katkısı bulunmaktadır.

DB Yapısı ve Önerileri

vCenter DB yapısında iki temel tablo türü vardır. Inventory tabloları ve SEAT(Statistics,Events,Alarms & Tasks), bu tablolardan inventory toplam size’ın %10-15’ini oluştururken geri kalan kısmı SEAT tabloları tarafından oluşturulmaktadır. Bu sebepten dolayı sizing ve optimizasyon çalışmalarında odak noktamız SEAT olmalıdır.

Doğru stat seviyesi belirlemek çok önemlidir. vCenter üzerinde 4 adet stat seviyesi var. Bu seviyelerin loglama detaylar aşağıda ki gibidir. Ön tanımlı stat seviyesi level 1 olarak gelmektedir.

Level 2’nin yarattığı log sayısı Level 1’e göre 4 kat Level 3’ün seviyesi 24 kat Level 4’ün seviyesi 32 kattır. Sadece troubleshoot ve önemli durumlar halinde Stat seviyesi yükseltilmelidir.

Highly-Volatile tabloların günde bir kere recompute edilmesi önerilmektedir. Inventory ve vCOPS gibi servisler buralardan veri okumaktadır.
VPX_Property_Bulletin
VPX_TOPNN*

vCenter DB’si write ağırlıklı çalışan bir veri tabanıdır. Bu sebepten dolayı DB ve Storage optimizasyonu buna göre yapılmalıdır.
Redo Logs ve Tempdb için ayrı bir disk bulundurulmalıdır. Tempdb’nin orta ölçekli bir IT için(1000-2000 VM) ön görülen tahmini boyutu 2GB-5GB arasındadır.
Tablo ve indexleri ayrı bir tablespace/filegroup üzerinde ayırmamız önerilmektedir.
Tablo ve index istatisliklerini her 4 saatte bir güncelleyen zamanlanmış görevin tanımlanması
vCenter DB retention policy tanımlanmalıdır. Bir çok veriyi vCOP üzerine almaktayız. vCenter üzerinde tuttuğumuz STAT verisinin azaltılması growth ve performans konusunda bize kontrol sağlayacaktır. Retention policy için ilgili yazıyı inceleyebilirsiniz.
Rahatlıkla Truncate edebileceğimiz event/task tabloları aşağıda ki gibidir. Aynı zamanda okumanızı önerdiğim KB

Okuduğunuz için çok teşekkür ederim. Yazımı sonlandırmadan önce mutlaka okumanızı önerdiğim son yazıysa yukarıda yazdığım noktaları daha detaylı olarak bulabileceğiniz bir kaynaktır.