Edukacja vSphere - Jakie są wady konfigurowania maszyn wirtualnych z * zbyt * dużą ilością pamięci RAM?

Zarządzanie pamięcią VMware wydaje się być trudnym zadaniem równoważącym. Dzięki pamięci RAM w klastrze, pulom zasobów, technikom zarządzania VMware (TPS, balonowaniu, zamianie hosta), wykorzystaniu RAM gościa, zamianie, rezerwacji, udziałów i limitów istnieje wiele zmiennych.

Jestem w sytuacji, gdy klienci używają dedykowanych zasobów klastra vSphere. Jednak konfigurują maszyny wirtualne, jakby były na sprzęcie fizycznym. To z kolei oznacza, że ​​standardowa kompilacja VM może mieć 4 vCPU i 16 GB lub więcej pamięci RAM. Pochodzę ze szkoły rozpoczynania od małej (1 vCPU, minimalna pamięć RAM), sprawdzania rzeczywistego użycia i dostosowywania w razie potrzeby. Niestety, wiele wymagań dostawców i osoby niezaznajomione z wirtualizacją wymagają więcej zasobów niż to konieczne ... Jestem zainteresowany oszacowaniem wpływu tej decyzji.

Kilka przykładów z klastra „problemowego”.

Podsumowanie puli zasobów - wygląda na zbyt zawyżoną 4: 1. Zwróć uwagę na dużą ilość balonowej pamięci RAM.

Alokacja zasobów - kolumna Alokacja najgorszego przypadku pokazuje, że te maszyny wirtualne miałyby dostęp do mniej niż 50% skonfigurowanej pamięci RAM w ograniczonych warunkach.

Wykres wykorzystania pamięci w czasie rzeczywistym dla największej maszyny wirtualnej z powyższej listy. 4 przydzielone vCPU i 64 GB pamięci RAM. Średnio używa poniżej 9 GB.

Podsumowanie tej samej maszyny wirtualnej

• Jakie są wady nadmiernego zaangażowania i nadmiernej konfiguracji zasobów (szczególnie pamięci RAM) w środowiskach vSphere?

• Zakładając, że maszyny wirtualne mogą pracować w mniej pamięci RAM, jest to sprawiedliwe, by powiedzieć, że tam na górze do konfiguracji maszyn wirtualnych z większą ilością pamięci RAM niż rzeczywiście potrzebne?

• Jaki jest kontrargument: „jeśli maszyna wirtualna ma przydzielone 16 GB pamięci RAM, ale używa tylko 4 GB, jaki jest problem? ”? Np. Czy należy informować klientów, że maszyny wirtualne nie są tym samym co sprzęt fizyczny?

• Jakie konkretne metryki należy zastosować do pomiaru zużycia pamięci RAM. Śledzenie szczytów „Aktywności” w funkcji czasu? Oglądasz „Zużyty”?

Aktualizacja: Użyłem vCenter Operations Manager do profilowania tego środowiska i uzyskania szczegółowych informacji na temat statystyk klastra wymienionych powyżej. Podczas gdy rzeczy są zdecydowanie nadmiernie zaangażowane, maszyny wirtualne są tak nadmiernie skonfigurowane z niepotrzebną pamięcią RAM, że rzeczywisty (mały) ślad pamięci nie wykazuje rywalizacji o pamięć na poziomie klastra / hosta ...

Moja na wynos jest to, że maszyny wirtualne powinny być naprawdę odpowiedniej wielkości z odrobiną bufora do buforowania na poziomie systemu operacyjnego. Nadmierne zaangażowanie z powodu ignorancji lub „wymagań” dostawcy prowadzi do przedstawionej tutaj sytuacji. Balonowanie pamięci wydaje się być złe w każdym przypadku, ponieważ ma to wpływ na wydajność, więc dobranie odpowiedniego rozmiaru może temu zapobiec.

Aktualizacja 2: Niektóre z tych maszyn wirtualnych zaczynają się zawieszać z:

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

VMware opisuje to jako przejaw nadmiernego zaangażowania pamięci . Myślę, że to odpowiada na pytanie.

Raport „Ponadwymiarowych maszyn wirtualnych” vCops ...

Wykres „Reclaimable Waste” vCops ...

Zarządzanie pamięcią w vSphere jest całkiem przyzwoite, chociaż używane terminy często powodują wiele zamieszania.

Zasadniczo należy unikać nadmiernego zatwierdzania pamięci, ponieważ stwarza to dokładnie ten rodzaj problemu. Są jednak chwile, kiedy nie da się tego uniknąć, więc uprzedzony jest uzbrojony!

Jakie są wady nadmiernego zaangażowania i nadmiernej konfiguracji zasobów (szczególnie pamięci RAM) w środowiskach vSphere?

Główną wadą nadmiernie angażujących się zasobów jest to, że jeśli będziesz się spierać, twoi gospodarze będą zmuszeni do balonowania, zamiany lub inteligentnego planowania / usuwania duplikatów za kulisami, aby zapewnić każdej maszynie wirtualnej potrzebną pamięć RAM.

W przypadku balonowania vSphere napompuje „balon” pamięci RAM w wybranej maszynie wirtualnej, a następnie przekaże tę balonową pamięć RAM gościowi, który jej potrzebuje. To nie jest tak naprawdę „złe” - maszyny wirtualne kradną sobie pamięć RAM, więc nie następuje zamiana dysku - ale może to prowadzić do błędnie uruchomionych alertów i zniekształconych danych, jeśli polegają one na analizie wykorzystania pamięci RAM maszyny, ponieważ pamięć RAM wygrała nie będą oznaczone jako „balonowe”, tylko że jest „w użyciu” przez system operacyjny.

Inną funkcją, z której może korzystać vSphere, jest przezroczyste udostępnianie stron (TPS) - czyli zasadniczo duplikacja pamięci RAM. vSphere okresowo skanuje całą przydzieloną pamięć RAM, szukając zduplikowanych stron. Po znalezieniu usunie duplikaty i zwolni zduplikowane strony.

Spójrz na vSphere za zarządzanie pamięcią whitepaper (PDF) - specyficznie „Rekultywacja Pamięć w ESXi” (strona 8) - jeśli potrzebujesz wyjaśnienia bardziej szczegółowe.

Zakładając, że maszyny wirtualne mogą działać przy mniejszej ilości pamięci RAM, czy można uczciwie stwierdzić, że konfigurowanie maszyn wirtualnych z większą ilością pamięci RAM jest narzutem?

Nie ma widocznego narzutu - możesz przydzielić 100 GB pamięci RAM na hoście o pojemności 16 GB (nie oznacza to jednak, że powinieneś , z powyższych powodów).

Całkowita pamięć wykorzystywana przez wszystkie maszyny wirtualne to krzywa „Aktywna” pokazana na wykresach. Oczywiście, nigdy nie powinieneś polegać tylko na tej liczbie, gdy obliczasz, ile chcesz przesadzić, ale jeśli masz takie dane historyczne, możesz je przeanalizować i opracować na podstawie rzeczywistego użycia.

Różnica między „aktywną” i „zużytą” pamięcią RAM została omówiona w tym wątku społeczności VMWare .

Jaki jest kontrargument: „jeśli maszyna wirtualna ma przydzielone 16 GB pamięci RAM, ale używa tylko 4 GB, jaki jest problem?” ? Np. Czy trzeba edukować klientów?

Krótka odpowiedź na to pytanie brzmi „ tak” - klienci powinni być zawsze szkoleni w zakresie najlepszych praktyk, niezależnie od dostępnych narzędzi.

Klienci powinni być wykształceni do wielkości ich maszyn wirtualnych zgodnie z tym co oni używać , zamiast tego, co oni chcą . Przez większość czasu ludzie przesadzają ze swoimi maszynami wirtualnymi tylko dlatego, że mogą potrzebować 16 GB pamięci RAM, nawet jeśli historycznie radzą sobie z 2 GB każdego dnia. Jako administrator vSphere masz wiedzę, mierniki i moc, aby rzucić im wyzwanie i zapytać, czy faktycznie potrzebują przydzielonej pamięci RAM.

To powiedziawszy, jeśli połączysz zarządzanie pamięcią vSphere ze starannie kontrolowanymi limitami nadmiernego zaangażowania, rzadko powinieneś mieć problem w praktyce, prawdopodobieństwo wyczerpania pamięci RAM przez dłuższy czas jest stosunkowo niewielkie.

Oprócz tego zautomatyzowane vMotion (zwane przez VMware harmonogramem zarządzania zasobami rozproszonymi ) zasadniczo równoważy obciążenie maszyn wirtualnych - jeśli pojedyncza maszyna wirtualna staje się świnią zasobów, DRS powinien migrować maszyny wirtualne, aby jak najlepiej wykorzystać zasoby klastra.

Jakiej konkretnej metryki należy użyć do pomiaru zużycia pamięci RAM. Śledzenie szczytów „Aktywności” w funkcji czasu?

Przeważnie omówione powyżej - Twoim głównym problemem powinno być „aktywne” użycie pamięci RAM, chociaż powinieneś dokładnie zdefiniować swoje nadmierne progi, aby osiągnąć określony współczynnik ( jest to przyzwoity przykład , choć może być nieco przestarzały). Zazwyczaj z pewnością pozostałbym w granicach 120% całkowitej pamięci RAM klastra, ale to Ty decydujesz, z jakim współczynnikiem będziesz czuć się komfortowo.

Kilka dobrych artykułów / dyskusji na temat nadmiernego zatwierdzania pamięci:

• Nadmiar pamięci w produkcji? TAK TAK TAK
• vSphere - Overcommitting Memory?
• Overcommit pamięci w vSphere

Oprócz doskonałej odpowiedzi Craiga Watsona chciałbym dodać:

Przeładowanie pamięci w VMware nie jest czymś, co powinieneś robić celowo. Ogólnie pokazuje, że zarówno Ty, jak i Twój klient subskrybuje sprzęt.

Jeśli nadmierne zaangażowanie jest jedynym wyborem, zdecydowanie zalecamy egzekwowanie zasad pierwszeństwa. Jeśli ktoś chce dać niekrytyczną maszynę wirtualną 16 GB vRam, gdy potrzebuje ona tylko 4 GB - przynajmniej umieść tę maszynę wirtualną w puli niskich zasobów lub nadaj jej niski priorytet. Naprawdę nie chcesz, aby hiperwizor zamienił krytyczną produkcyjną bazę danych. Wydajność nie tylko spadnie, ale zje również kolejki we / wy względem pamięci wewnętrznej.

Jeśli korzystasz z niesamowicie szybkiej pamięci masowej (FusionIO, skrzypce, lokalne dyski SSD itp.), To zamiana może nie być dużym problemem, ale w przypadku tradycyjnej pamięci masowej SAN ostatecznie wpłyniesz na każdą maszynę wirtualną i host podłączony do tej samej macierzy / kontrolera.