Resource Pool ekranında yüksek Shares değerine sahip bir uygulamanın mutlaka yüksek CPU kullanacağını düşünmek yanıltıcıdır. Shares, kaynak sıkışıklığında göreli önceliği ifade eder; Reservation belirli miktarda kaynağın garanti edilmesiyle, Limit ise üst sınırla ilişkilidir. Yanlış Limit ayarı hostta boş kapasite bulunsa bile VM'nin performansını kısıtlayabilir. Bu üç kavramı aynı anda anlamak, özellikle üretim ve test VM'lerinin ortak cluster kullandığı ortamlarda önemlidir.
Shares neden tek başına kapasite değildir?
İki Resource Pool düşünün: Üretim pool'una yüksek, geliştirme pool'una normal Shares verildi. Hostlarda yeterli boş CPU varsa iki pool da ihtiyacı kadar işlemci zamanına erişebilir. Sıkışıklık başladığında Shares oranları devreye girer. Bu nedenle 'High' Shares seçmek işlemci artırımı değildir; rekabet anındaki göreli dağıtımı etkiler. Parent/child pool hiyerarşilerinde hesaplama üst kaynak grubunun sınırlarından etkilenebilir.
Reservation, belirlenen CPU veya bellek miktarının kullanılabilir olması gerektiğini ifade eder. Birden çok pool'a gereğinden büyük Reservation vermek, toplam kaynakların yeni VM kabulünü zorlaştırabilir. Limit ise tavan olduğundan, yanlışlıkla küçük girilen bir değer uygulamanın yükselen talebini bastırabilir. Sadece grafik ortalamasına bakarak Limit varlığını gözden kaçırmak hatalı rightsizing kararlarına yol açar.
Sorun yaşayan VM'de nasıl bakılır?
Önce VM'nin içinde bulunduğu Resource Pool'u bulun. Üst pool zincirini, CPU ve memory Shares, Reservation ve Limit değerlerini not edin. VM'nin kendisinde ayrıca kaynak sınırı tanımlı mı kontrol edin. Sonra host CPU ve bellek sıkışıklığı, CPU Ready ve bellek ballooning gibi göstergeleri iş yükünün sorun yaşadığı saatlerle eşleştirin. Üstte Limit varsa içerideki VM'nin konfigürasyonu geniş olsa da beklenen kapasiteye çıkamayabilir.
Üretimde kaynak grubu paylaşımını değiştirirken komşu pool'lardaki uygulamaları da değerlendirin. Geliştirme pool'unun Limit değerini kaldırmak, kaynak sıkışıklığında üretimin erişebildiği payı dolaylı etkileyebilir. Bu yüzden yalnızca sorunlu VM'yi test etmek yetmez; cluster toplam talebini ve diğer pool'ların beklenen korumasını da izleyin.
Değişiklik ve doğrulama
Önce ilgili pool ile VM ayarlarının ekran çıktısını veya dışa aktarımını saklayın. Darboğazın gerçekten Resource Pool politikasıyla ilişkili olduğuna dair kanıt arayın. Kontrolsüz CPU veya bellek eklemek yerine küçük kapsamlı değişiklik yapıp yük altında yeniden ölçün. İş bittiğinde diğer uygulamaların performansına da bakın.
Geri dönüş için eski Shares, Reservation ve Limit değerlerini bire bir kaydedin. Ortamda otomatik iş yükü yerleştirme ürünü varsa o ürünün de bu sınırlara göre karar verebileceğini unutmayın. Kaynak tahsisi ekranındaki sayılar ile gerçek tüketim metrikleri farklı soruları yanıtlar.
Kaynak
- Broadcom vSphere Resource Management belgeleri: https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0.html
