vSphere education - VM'leri * çok * fazla RAM ile yapılandırmanın olumsuzlukları nelerdir?


57

VMware bellek yönetimi zor bir dengeleyici hareket gibi görünüyor. Küme RAM, Kaynak Havuzları, VMware'in yönetim teknikleri (TPS, balonlama, ana bilgisayar takas etme), konuk içi RAM kullanımı, takas, rezervasyon, hisse ve limit gibi birçok değişken vardır.

Müşterilerin özel vSphere küme kaynaklarını kullandığı bir durumdayım. Ancak, sanal makineleri fiziksel bir donanımdaymış gibi yapılandırıyorlar. Bu da, standart bir VM yapısının 4 vCPU'ya ve 16GB veya daha fazla RAM'e sahip olabileceği anlamına gelir. Küçük yaşta başladığım okuldan (1 vCPU, minimum RAM) geliyorum, gerçek dünya kullanımını kontrol ediyorum ve gerekli ayarları yapıyorum. Ne yazık ki, birçok satıcı gereksinimi ve sanallaştırmaya aşina olmayan insanlar gereğinden fazla kaynak talep ediyor ... Bu kararın etkisini ölçmekle ilgileniyorum.


Bir "problem" kümesinden bazı örnekler.

Kaynak havuzu özeti - Neredeyse 4: 1 azami görünüyor. Balonlu RAM'in yüksek miktarına dikkat edin. görüntü tanımını buraya girin

Kaynak tahsisi - En Kötü Durum Tahsisi sütunu, bu VM'lerin kısıtlı koşullar altında yapılandırılmış RAM'lerinin% 50'sinden daha azına erişebileceğini göstermektedir. görüntü tanımını buraya girin

Yukarıdaki listedeki en iyi VM'nin gerçek zamanlı bellek kullanım grafiği. 4 vCPU ve 64GB RAM tahsis edildi. 9GB kullanımın altında ortalamaları. görüntü tanımını buraya girin

Aynı VM'nin özeti görüntü tanımını buraya girin


  • VSphere ortamlarında kaynakların aşırı kullanımı ve kaynaklarının yapılandırılmasının olumsuz yönleri (özellikle RAM) nelerdir?

  • VM'lerin daha az RAM'de çalışabileceğini varsayarsak, sanal makineleri gerçekten ihtiyaç duyduklarından daha fazla RAM ile yapılandırmanın ek yükü olduğunu söylemek doğru olmaz mı?

  • Karşıt argüman nedir: "bir VM'nin tahsis ettiği 16 GB RAM varsa, ancak yalnızca 4 GB kullanıyorsa, sorun nedir? "? Örneğin, müşterilerin VM'lerin fiziksel donanım ile aynı olmadığı konusunda eğitilmeleri gerekir mi?

  • RAM kullanımını ölçmek için hangi belirli metrik (ler) kullanılmalıdır. Zamana karşı "Aktif" doruklarını takip? "Tüketilen" izleniyor mu?


Güncelleme: Bu ortamı profillendirmek ve yukarıda listelenen küme istatistikleri hakkında biraz bilgi almak için vCenter Operations Manager kullandım . İşler kesinlikle aşırı derecede tamamlanmış olsa da, sanal makineler gereksiz RAM ile o kadar fazla yapılandırıldı ki, gerçek (minik) bellek alanı, küme / ana bilgisayar düzeyinde bellek çekişmesi göstermiyor ...

Benim paket servisim, VM'lerin işletim sistemi düzeyinde önbellekleme için biraz tamponla gerçekten doğru boyutta olmaları gerektiğidir. Cehalet veya satıcı "şartlarının" aşırı verilmesi burada sunulan duruma yol açar. Bellek balonculuğu her durumda kötü görünüyor, çünkü performansın bir etkisi var, bu yüzden doğru boyutlandırma bunu önlemeye yardımcı olabilir.

Güncelleme 2: Bu sanal makinelerin bazıları çarpmaya başladı:

kernel:BUG: soft lockup - CPU#1 stuck for 71s! 

VMware, bu konuyu ağır bellek kullanımının bir belirtisi olarak tanımlar . Sanırım bu soruyu cevaplıyor.

görüntü tanımını buraya girin


vCops "Büyük Boy Sanal Makineler" raporu ... görüntü tanımını buraya girin

vCops "Geri Kazanılabilir Atık" grafiği ...

görüntü tanımını buraya girin

Yanıtlar:


45

vSphere'in bellek yönetimi oldukça iyi, ancak kullanılan terimler sık ​​sık karışıklığa neden oluyor.

Genel olarak, bu türden bir problemi tam olarak yarattığı için aşırı bellek kullanımından kaçınılmalıdır. Ancak, kaçınılması gereken zamanlar vardır, bu yüzden önceden uyarılmıştır!

VSphere ortamlarında kaynakların aşırı yüklenmesinin ve aşırı yapılandırılmasının olumsuz yönleri (özellikle RAM) nelerdir?

Aşırı bağlı kaynakların en büyük dezavantajı, tartışmalı olmanız durumunda, ev sahipleriniz her VM'ye ihtiyaç duydukları RAM'i vermek için sahne arkasında balon, takas yapmak veya akıllıca programlamak / çoğaltmak zorunda kalacaklardır.

Balonculuk için vSphere, seçilen bir VM içindeki bir "RAM" balonunu şişirecek, daha sonra bu balonlu RAM'i ihtiyaç duyan müşteriye verecektir. Bu gerçekten "kötü" değil - VM'ler birbirlerinin RAM'lerini çalıyorlar, bu yüzden disk takas etmeye devam etmiyorlar - ancak RAM kazandıkça VM'nin RAM kullanımını analiz etmeye dayanırlarsa yanlış ateşlemeli uyarı ve eğri ölçümlere neden olabilir "Balonlu" olarak işaretlenmemiş, sadece işletim sistemi tarafından "kullanımda" olduğu belirtiliyor.

VSphere'in kullanabileceği diğer bir özellik de Sayısal Sayfa Paylaşımıdır (TPS) - ki bu esasen RAM'in çoğaltılmasıdır. vSphere, ayrılan tüm RAM'leri düzenli aralıklarla tarar ve yinelenen sayfalar arar. Bulduğunda, çoğaltılacak ve çoğaltılan sayfaları serbest bırakacak.

Bir göz atın (PDF) vSphere en Bellek Yönetimi whitepaper'da özellikle "ESXi Bellek Islah" (sayfa 8) - - Bir daha derinlemesine açıklama gerekiyorsa.

VM'lerin daha az RAM'de çalışabileceğini varsayarsak, sanal makineleri ihtiyaç duyduklarından daha fazla RAM ile yapılandırmanın ek yükü olduğunu söylemek doğru olmaz mı?

Görülebilen ek yük yok - 16 GB'lık bir ana bilgisayara 100 GB RAM atayabilirsiniz (ancak, yukarıdaki nedenlerden ötürü yapmanız gerektiği anlamına gelmez ).

Tüm VM'leriniz tarafından kullanılan toplam bellek, grafiklerinizde gösterilen "Aktif" eğridir. Tabii ki, ne kadar üstesinden gelmek istediğinizi hesaplarken hiçbir zaman sadece bu şekle güvenmemelisiniz, ancak sahip olduğunuz tarihsel ölçümlere sahipseniz, gerçek kullanıma dayalı olarak analiz edebilir ve çalışabilirsiniz.

"Etkin" ve "Tüketilen" RAM arasındaki fark bu VMWare Topluluğu iş parçacığında ele alınmıştır .

Karşıt argüman nedir: "eğer bir VM'nin tahsis ettiği 16GB RAM varsa, fakat sadece 4GB kullanıyorsa, sorun ne?" ? Örneğin, müşterilerin eğitilmeye ihtiyacı var mı?

Bunun kısa cevabı evet - Müşteriler elindeki araçlardan bağımsız olarak daima en iyi uygulamalarda eğitim almalıdır .

Müşteriler neye göre boyutuna onların VM'lerini eğitilmeli kullanmak yerine onlar olandan, istiyorum . Onlar sırf Çok zaman, insanlar VM'lerini aşırı belirleyecek olabilir onlar tarihsel günden sonra 2 GB gününde birlikte homurdanan olsanız bile, RAM 16 GB gerekir. Bir vSphere yöneticisi olarak, onlara meydan okuma ve tahsis ettikleri RAM'e gerçekten ihtiyaç duyup duymadıklarını sorma konusunda bilgi, metrik ve güce sahipsiniz.

Bununla birlikte, eğer vSphere'in hafıza yönetimini dikkatli bir şekilde kontrol edilen aşırı alım limitleriyle birleştirirseniz, pratikte nadiren bir sorun yaşamanız gerekir, uzun bir süre boyunca RAM'in tükenme olasılığı nispeten uzaktır.

Buna ek olarak, otomatik vMotion ( VMware tarafından Dağıtılmış Kaynak Planlama ) aslında VM'leriniz için bir yük dengeleyicidir - eğer tek bir VM bir kaynak domuzu oluyorsa, DRS kümelerin kaynaklarını en iyi şekilde kullanmak için VM'leri dolaşmalıdır.

RAM kullanımını ölçmek için hangi spesifik metrik kullanılmalıdır. Zamana karşı "Aktif" doruklarını takip?

Çoğunlukla yukarıda ele alınmaktadır - asıl endişeniz "Aktif" RAM kullanımı olmalıdır, ancak aşırı alım eşiklerinizi dikkatli bir şekilde tanımlamanız gerekir, böylece belirli bir orana ulaşırsanız ( bu biraz modası geçmiş olsa da iyi bir örnektir ). Genelde, toplam küme RAM'in% 120'sinde kesinlikle kalırdım, ancak hangi oranda rahat edeceğinize karar vermek size kalmış.

Belleğe aşırı bağlılık konusunda birkaç iyi makale / tartışma:


Anladığım kadarıyla, bir VM'ye tahsis edilen daha fazla RAM'in DRS'nin VM'yi göç etmesinin daha zor olduğu anlamına geliyor; RAM ne kadar çok olursa, DRS’nin özgürce yeteri kadar büyük bir parça bulabilmesi de o kadar düşük. Kümedeki kapasiteyi azaltan bir olayınız (örneğin, donanım arızası) varsa, bu özellikle sıkıntılı olabilir (inanmaya yönlendirildim). Küçük VM'lerin karıştırılması kolaydır ve fazla kesinti farketme olasılığı yüksek değildir, büyük VM'ler aldatıcı olabilir. Doğru şekilde bilgilendirildim mi?
James Polley

2
@James - vMotion sırasında yalnızca aktif (yani kullanımda) bellek taşınır, bu yüzden VM'lere ayırdığınız RAM miktarı o kadar önemli değil. Referans: vmware.com/files/pdf/VMware-VMotion-DS-EN.pdf
Craig Watson 15

Mükemmel cevap. Sorumu bu kümeden daha fazla ayrıntıyla güncelledim. Yine de puanların iyi. Bu kurulumdaki VM'lerin aşırı yapılandırılmış olduğu ortaya çıktı. Aktif RAM kullanımı kümelenmenin fiziksel kaynaklarının çok altında olduğundan, çekişme yok ... Sadece ağır balon / değişim / çirkinlik. Sanal Makinelerin doğru boyutlandırılmasının bu baskıyı azaltacağından şüpheleniyorum.
beyazbeyaz

21

Craig Watson'ın mükemmel cevabına ek olarak, aşağıdakileri de eklemek isterim:

VMware'de aşırı bellek kullanımı, kasıtlı olarak yapmanız gereken bir şey değildir. Genel olarak, sizin veya müşterinizin donanımı abonelikten çıkardığını gösterir.

Aşırı taahhüt tek seçenek ise, öncelikli kuralları uygulamanızı şiddetle tavsiye ederim. Birisi, yalnızca 4GB gerektiğinde kritik olmayan bir VM 16GB vRam vermeye eğilimli ise - en azından bu VM'yi düşük kaynak havuzuna koyun veya düşük bir öncelik verin. Gerçekten kritik bir üretim veritabanının hiper yönetici tarafından değiştirilmesini istemiyorsunuz. Performans sadece boşa gitmeyecek, aynı zamanda arka uç depolamanıza karşı G / Ç sıralarını da tüketecektir.

Hızlı yanan bir depolamada (FusionIO, Keman, yerel SSD'ler vb.) Çalışıyorsanız takas işlemi büyük bir sorun olmayabilir, ancak geleneksel SAN depolaması ile sonunda her bir VM'yi ve aynı diziye / denetleyiciye bağlı ana bilgisayarı etkileyeceksiniz.


4
Değişimin depolanmasına etkisi konusunda iyi gözlem. Bu, gördüğüm VNX performans sorunlarından bazılarını açıklıyor ....
yine de

Parlak nokta, depo IO argümanı almayı hiç düşünmedim,
Dan
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.