Vsphere Kaynak Yönetimi Ve Yöntemleri

Bu yazımda daha önce ki iki yazım olan DRS ve sDRS’i tamamlar nitelikte olacak olan vsphere kaynak yönetimi ve yöntemleri üzerine konuşmak istedim.Eğer yüksek bir iş yüküne sahip sanallaştırma ortamınız varsa, VM’lerinizin over-commitment olması çok normaldir. Sanallaştırmanın bize sunduğu bir nimet olan over-commitment kaynak ihtiyacımızı ciddi anlamda azaltmış olsa da her zaman istediğimiz performans ve sonucu alamayabiliriz. Belli servislerde oluşan anlık talepler sürekli kullanılan ve kritik servislerin ihtiyacı olan kaynakları kullanmasının önüne geçebilir.

Vmware vsphere ortamlarında bu durumun önüne geçilmesi için bazı yöntemler uygulanabilir. Bu yöntemler aşağıda ki gibidir.

Reservations
Shares
Limits
Resource Pools

Reservation:

Kaynak rezervasyonu, VM’in çalışabilmesi için gereken minimum fiziksel memory veya işlemci gücünün(mhz cinsinden) sadece bu VM için ayrılmasıdır. Reservation, memory ve CPU için ayrı çalışmaktadır. Eğer bir VM üzerinde memory rezervasyonu varsa bu kaynak ilgili VM için ayrılır ve başkası kullanamaz ama CPU rezervasyonu varsa öncelik VM’e tanınır ama başka VM’lerde kullanabilir. Bildiğiniz üzere bir VM’i başlattığınız zaman(power on) tanımlı memory büyüklüğü kadar bir swap dosyası oluşturur. Peki bir rezervasyon oluşturduğumuzda bu swap dosyası nasıl değişiklik gösterir.

64 GB’lık memory tanımlanmış bir ERP sunucusunda 32GB’ı rezerve ettiğimizi varsayarak:

32GB’ı hali hazırda fiziksel memory üzerinde ayırdığı için yaratması gereken swap dosyası sadece 32GB kadardır.
Eğer bir host üzerinde fiziksel memory olarak 32GB boş alan yoksa VM’i başlatamayız.
32GB yerine 64GB’ı rezerver etseydik swap alanı 0(sıfır) olacaktır.

Yukarıda ki örnekte de görüleceği üzere rezervasyon ilk başta iyi bir fikir gibi gözüküyor olsa da HA, DRS ve vMotion konularında bizi ciddi anlamda sıkıntıya sokmaktadır. Ek olarak bir VM’in kaynak kullanım trendlerini incelerseniz, iş yüklerinin gün içerisinde değişiklik gösterdiğini göreceksinizdir doğal olarak sürekli yüksek bir kaynak kullanımına ihtiyaç duymamaktadırlar eğer kritik uygulamalarınız ciddi anlamda kaynak dağıtımından etkileniyorsa ve over-commitment oranınız çok yükselmişse kullanmanızı öneririm. Aynı zamanda reservation’ı belirlerken mümkün olduğunca memory için tanımlı olan oranın %50’sinden azını rezerve etmenizi önermekteyim.

Limit:

Reservation ve Shares’in aksine bir VM için bir alt limit değil tam tersi üst limiti tanımlamaktadır. Limit tanımlanmış bir VM bu değerin üzerine çıkamaz. Burada dikkat etmemiz gereken en önemli noktaysa limit olarak belirlediğimiz değerin VM’in tanımlı olan memory ve cpu değerlerinden düşük olmamasıdır. Guest OS, esxi üzerindeki limitten haberdar olmadığı için tanımlı olan değerlere göre kaynak optimizasyonu yapmaya çalışacaktır ve doğal olarak sıkıntı yaşatacaktır.

Hem resource pool hem de vsphere cluster’larında uygulanabilen bir yapıdır. Bir VM’in kaynak dağıtımında ki önceliğini belirtir,limit ve rezervasyona göre dinamik bir yapısı vardır. Her VM için ön tanımlı share 1000’dir. Bu sayede ESXI kaynak dağıtımında hepsine aynı önceliği verir ama eğer bir VM için olan share değerini değiştirirseniz VM’in önemide değişeceği için önceliği de değişecektir. Bunu aynen bir şirketin yönetim kurulu gibi hayal edebilirsiniz. Nasıl yönetim kurulunda daha çok hissesi olan kişinin hem kazancı hem de sözü daha çok geçiyorsa aynısı burada da geçerlidir. Rezervasyon ve limit’e göre en büyük farkı sizi belli bir sayıya sınırlamıyor oluşudur, daha güçlü bir donanıma geçerseniz veya cluster’da ki boş kaynakların oranı artarsa Shares yeni duruma göre tekrar kaynak dağıtım yapacaktır.

Reservation, Shares, Limit Nasıl Ayarlanır:

VM’in üzerine gelip sağ tıklayıp gelen menüden “Edit Settings” seçeneğini seçelim ve “Resources” tabına geçelim.

Hangi kaynak üzerine işlem yapmak istiyorsanız buradan onun üzerine gelip istediğiniz gibi değiştirebilirsiniz. Sadece “Disk” için rezervasyon tanımlayamazsınız ama yapabileceği IO için share ve limit koyabilirsiniz.

Burada bahsettiğim 3 yönteminde kendi ait kullanım alanları olsa da dediğim gibi HA ve DRS ile kullanımında bazı sıkıntılar yaşatmaktadırlar. Bunun için alternatif olarak “Resource Pool” denilen 4. bir yöntem bulunmaktadır.

Resource Pool:

Adından da anlaşılacağı üzere bir kaynak havuzu tanımlayıp havuz içerisinde bulunan VM’lerin havuzun kurallarına göre davranmasıdır. Mesela ERP ve CRM sistemleride fazlasıyla kaynak tüketen yapılardır. Eğer bu ikisi için ayrı resource pool’lar tanımlarsak kaynak kullanımlarının bir birilerini minimum etkilemesini sağlayabiliriz. Peki diğer yöntemler yerine neden Resource Pool kullanmalıyız:

Resource Pool içerisinde her VM için tek tek değil bir bütün olarak kaynak ataması yapılır, buda yönetim kolaylığı getirir.
DRS ile kullanıma diğer yöntemlere göre daha uygundur bu sebepten dolayı DRS’in olması Resource Pool için bir ön şarttır.
Resource Pool’u servislere ve onu tanımlayan VM’ler için kullanabilirsiniz bu sayede bir VM’in performansından çok servisin performansını düşünebilirsiniz.
Rezervasyonları Resource Pool için tanımladığımız zaman havuz içerisinde kullanılmayan VM’lerin kaynaklarını yine havuz içerisinde yoğun kaynak kullanımı olan VM’ler tarafından kullanılacaktır böylelikle daha iyi bir kaynak yönetimi sağlanır.

Resource Pool hakkında İnternette veya daha önce denemiş arkadaşlarınız tarafından, performansı olumsuz olarak etkilediği yolunda yorumlara rastlamışsınızdır. Resource Pool’un tam olarak nasıl çalıştığını anlamanız bu tür sorunların önüne geçmek için bire birdir. İlk önce yeni bir Resource Pool yaratma ekranına bir bakalım,

Yukarıda konuştuğumuz Shares, Reservation ve Limit burada da aynı şekilde karşımıza çıkmaktadır. İki farkla, daha önce bahsetmiş olduğum gibi bir değişiklik yaptığımız zaman Resource Pool içerisinde ki VM’ler bundan toptan etkilenir. Öteki farksa Reservation kısmının altında bulunan “Expandable Reservation” seçeneğidir. Hatırlarsanız Reservation için ayrılan kaynak sağlanamıyorsa VM başlatılamıyordu. Eğer bu seçenek seçildiyse Resource Pool içerisinde yeterli boş kaynak olmasa bile bir üstünde bulunan resource pool’da boş kaynak varsa VM başlatılabiliyor.
Peki, Resource Pool neden performans sıkıntısına sebep oluyor ve bunu nasıl çözebiliriz:

İki adet Resource Pool’umuz olduğunu varsayalım bunların adı Test/Dev ve Production olsun. Test/Dev havuzunun Share’ını 1000 yapalım ve içerisine 4 adet VM koyalım. Bu durumda her VM için 1000/4 = 250 share olacaktır.

Production ortamında ise doğal olarak daha yüksek bir Share tanımlayacağız bu değeri de 4000 olarak seçersek ve içerisinde 20 adet VM tutarsak her VM başına 4000/20 = 200 Share kalacaktır.

Gördüğünüz gibi Test/Dev havuzunun share’i daha az olmasına rağmen VM başına düşen Share sayısı Production ortamınınkinden daha fazladır. Unutmayın ki share sabit bir değer değildir sizin toplam fiziksel kaynaklarınız içerisinde bir önceliklendirmek için yapabilmeniz için olan dinamik bir değerdir. Bu durumu düzeltmeniz için yapmanız gereken tek şey Production için yarattığınız Resource Pool’un Share değerini yükseltmektir.