Nutanix – testy

W poprzedniej części przybliżyłem konsolę PRISM, służącą do zarządzania rozwiązaniem firmy Nutanix. W obecnej części opiszę zachowanie klastra podczas pracy, nie będzie to jednak zwykłe użytkowanie klastra, będę robił to czego w produkcyjnych środowiskach się unika lub trzyma kciuki aby nie nastąpiło.

Skoro wiadomo już jak wygląda konsola PRISM, oraz to jak jest przejrzysta i intuicyjna warto wspomnieć, że alarmy i ostrzeżenie które się w niej pojawiają nie zawsze są zgodnie z rzeczywistością – najprościej rzecz ujmując zgłaszane są problemy, które (już) nie występują. Zaobserwowane sytuacje miały miejsce po awariach, gdy środowisko już się ustabilizowało, a problemy ustąpiły. Przykładem takiej sytuacji jest restart maszyny CVM, rozwiązanie zgłasza wówczas krytyczny alarm (rys 1), niestety gdy kolejne wyniki monitorowania środowiska nie zgłaszają już problemów, ogólny alarm nadal występuje.

Rysunek 1 Pomimo, że kontrola dostępności maszyny CVM nie zgłasza już błędu, nadal jest zgłaszany krytyczny błąd dla jednego hosta.

Z jednej strony lepiej aby był zgłaszany alarm gdy go nie ma, niż nie zgłosić alarmu gdy jest to potrzebne, z drugiej jednak strony, administrator przyzwyczajony to takich problemów może zignorować poważny problem w środowisku. Inny podobny przypadek to ostrzeżenie o braku zamontowanego kontenera do wszystkich hostów ESXi (rys 2), podczas gdy wszystko działa prawidłowo.

Rysunek 2 Fałszywy alarm o braku zamontowanego kontenera do wszystkich hostów ESXi

Inna niedogodność do wirtualny adres IP klastra. W chwili niedostępności lidera, który udostępnia interfejs PRISM, musimy poczekać na elekcje nowego lidera, który udostępni interfejs klastra. Może się niestety zdarzyć, że adres wirtualny nie odpowiada, lecz próba wejścia na adres jednej z maszyn CVM jest skuteczna. Stan taki ma miejsce krócej niż 5 minut, lecz w krytycznym momencie każda minuta jest cenna.

Nadmiar nowych danych w klastrze

Pierwszy test jaki przeprowadzony został w środowisku, rzadko wystąpi w produkcyjnym środowisku – jeśli w ogóle. Najprawdopodobniejszy scenariusz to migracja, gdy kopiujemy do klastra nowe dane. W testowanym scenariuszu utworzona została mowa maszyna wirtualna z 4 TB dyskami grubymi (thick). Warte uwagi jest, że klaster jest świadomy takiej konfiguracji i pomimo, że fizycznie miejsce nie jest wykorzystanie (rys. 3) następuje jego rezerwacja (rys. 4), przez co drastycznie spada dostępna przestrzeń na datastore (rys 5).

Rysunek 3 Fizyczna zajętość dysków w klastrze to niecałe 900 GB. W pierwszej kolejności wykorzystywane są dyski SSD.

Rysunek 4 W kontenerze znajduje się dysk gruby (thin). Rozwiązanie jest tego świadome.

Rysunek 5 Od strony VMware widzimy zamontowany datastore o pojemności 5,54 TB, z dostępną przestrzenią 1,46 TB

Takie zachowanie jest dyskusyjne, lecz jego znajomość pozwoli uniknąć nieoczekiwanych konsekwencji wyboru dysków grubych. W trakcie generacji nowych danych w maszynie wirtualnej obciążenie CPU CVM nie przekraczało 50%, szybkośc zapisu danych dochodziła do 140 MBps (rys. 6). Celem testu nie był pomiar wydajności a podane wartości mają za zadanie pomóc w analizie kolejnych testów. Warto zwrócić uwagę, że dla zachowania wysokiej wydajności wszystkie zapisy są kierowane na lokalne dyski SSD, ich kopie natomiast są równomiernie rozkładane na dyskach SSD pozostałych węzłów w klastrze (rys. 3). W wyniku takiego podejścia lokalna przestrzeń kończy się szybciej.

Rysunek 6 Podczas generacji nowych danych, celem wysycenie dysków SSD, uzyskano tempo zapisów do 140 MBps

Proces generacji danych jest kontynuowany, a miejsce na lokalnych dyskach SSD kończy się. Rozwiązanie zaczyna wykonywać zapisy przez sieć na dyskach SSD pozostałych członków klastra, co ostatecznie doprowadzi do równomiernego ich zapełnienia (rys. 7).

Rysunek 7 Lokalne dyski SSD nie są w stanie przyjąć nowych danych. Nowa dane są zapisywane na pozostałych dyskach SSD klastra.

Nowa dane są zapisywane na pozostałych dyskach SSD w klastrze, w dane z lokalnych dysków są migrowane na dyski magnetyczne. Rozwiązanie cały czas pracuje z pełną wydajnością. Taki stan trwa do momentu wysycenie wszystkich dysków SSD w klastrze (rys. 8)

Rysunek 8 Dyski SSD nie są w stanie przyjąć nowych zapisów, niezbędne jest przeniesienie danych na dyski magnetyczne

Po wysyceniu następuje drastyczny spadek wydajności zapisu danych w klastrze (rys. 9), spowodowany koniecznością przeniesienia danych z dysków SSD na HDD. Spadek wydajności trwał około 40 minut.

Rysunek 9 Spadek wydajności trwający około 40 minut (czerwona ramka) wynikający z potrzeby przemigrowania danych z dysków SSD na HDD, w zestawieniu z pierwszym przebiegiem bez przepełnienia dysków SSD.

Rysunek 10 Zestawienie obciążenia klastra w przedziale 24 godzin

Obciążenie klastra było kontynuowane przez kolejne godziny (rys. 10). Po pierwszym wysyceniu dysków SSD około godziny pierwszej, odczuwalny spadek wydajności nastąpił około godziny trzeciej (blok A rys. 10), dochodził on miejscami do 50%, średnia wydajność w tym okresie nie różni się znacząco od tej sprzed wysycenia. Kontynuując testy, w punkcie oznaczonym czerwoną linią z numerem jeden, na rys. 10 wyłączona została deduplikacja na kontenerze. Po imponującym wzroście ilości zapisywanych danych (blok B rys 10), system się ustabilizował (blok C rys. 10). Ciekawe natomiast jest, że w bloku C, znacznie wzrosła ilość mierzonych przez klaster operacji I/O. Pomiędzy blokiem C i D ilość operacji I/O wróciła do „normy” natomiast bardzo spadło tempo zapisu danych. Niestety trudno w tej sytuacji wysnuć wnioski, oprócz jednego – nie bez znaczenie jest trwające wysycenie dysków SSD i konieczność migrowania danych na dyski magnetyczne. Zbliżając się do końca tej fazy testów, wyłączona została kompresja na klastrze (czerwona linia z numerem dwa rys 10). Jest to bardzo ciekawy moment, gdyż klaster mocno zareagował na tą zmianę – znacznie wzrosło tempo zapisu danych oraz (co jest bardzo intrygujące) ilość mierzonych operacji I/O. Dokonane pomiary nie pozwalają na wyciągnięcie jednoznacznych wniosków, a zmiana tak istotnych parametrów klastra jak kompresja czy deduplikacja zadania też nie ułatwiają. W zależności od potrzeb, możemy oszczędzać miejsce lub dążyć do maksymalizacji wydajności. Na rysunku 11 przedstawione przykładowe zyski z kompresji i deduplikacji uzyskane podczas testu.

Rysunek 11 Przykładowe zyski z kompresji i deduplikacji uzyskane podczas testu.

Generalnie wypełnienie dysków SSD powoduje zmianę charakterystyk wydajnościowych rozwiązania Nutanix i trudno precyzyjnie przewidzieć np. wymagany czas na migrację danych do klastra. Warto pamiętać, że jest to rozproszona pamięć masowa, zatem obciążenie generowane przez maszyny wirtualnie nie są jedynymi które pojawiają się w rozwiązaniu. Na rysunku 12 i 13 przedstawiono zestawienie obciążeń od strony maszyn wirtualnych z obciążeniem wewnętrznym rozwiązania w tym samym przedziale czasowym. Małe obciążenie generowanie przez maszyny wirtualne wcale nie oznacza braku obciążenia „wnętrza” klastra.

Rysunek 12 Przykładowe obciążenie kontenera

Rysunek 13 Przykładowe obciążenie Storage Pool

Kasowanie danych

Po wygenerowaniu kilku TB danych, a przed przystąpieniem do kolejnych testów wymagane było zwolnienie miejsca w klastrze. Miejsce zarezerwowane przez dyski grube zostało zwolnione natychmiast (rys 14), jednak pozostałe miejsce było dostępne po około trzech godzinach. Wynika to z rozproszonej architektury systemu i jest spotykane w komercyjnych macierzach np. Netapp z systemem plików WAFL.

Rysunek 14 Skasowanie maszyny wirtualnej (zaznaczone czerwoną ramką) w pierwszej chwili zwalnia rezerwację dysków grubych, przez kolejne trzy godziny trwało fizyczna zwalnianie miejsca w kontenerze.

Snapshoty

Rozwiązanie Nutanixa pozwala na wykonywanie migawek (snapshotów) maszyn wirtualnych, zarówno na poziomie podsystemu dyskowego jak również z udziałem systemu operacyjnego gościa, celem wyciszenia operacji dyskowych w maszynie wirtualnej. Dla wybranych maszyn można zdefiniować polityką wykonywania regularnych migawek. Niestety w przypadku pojawianie się nowych maszyn w środowisku należy pamiętać aby objąć je wymaganą polityką. Bardzo istotne jest, że taka operacja początkowo nie zajmuje dodatkowej przestrzeni. Z upływem czasu gdy pliki maszyny wirtualnej zmieniają się mamy możliwość sprawdzenie ile danych jest zakleszczone w snapshocie i ewentualnie podjąć decyzję o ich skasowaniu jeśli brakuje miejsca w środowisku. Niestety pomimo minimalnego obciążenie środowiska wartości te wyliczały się dwa dni (rys. 15). Wydaje się, że ten czas jest zdecydowanie zbyt długi.

Rysunek 15 Przestrzeń zajmowana przez migawkę maszyny wirtualnej obliczana jest po 48 godzinach.

W sytuacji gdy jest potrzeba odtworzenia maszyny wirtualnej z tak wykonanej kopii możemy to szybko i sprawnie zrobić.

 Testy awarii podzespołów

Ciekawa sytuacja występuje przy niedostępności (nr restart) maszyny CVM. Rożne hosty ESXi inaczej zgłaszają dostępność poszczególnych plików maszyn wirtualnych (rys. 16 i 17), co jednak najważniejsze nie następuje utrata danych a finalnie sytuacja się stabilizuje – wszystkie hosty tak samo „widzą” pliki maszyn wirtualnych.

Rysunek 16 Rozwiązanie potrafi zaprezentować do hostów ESXi zerową wielkość plików maszyn wirtualnych

Rysunek 17 Poszczególnym hostom ESXi wielkości plików maszyn wirtualnych mogą być różnie prezentowane (por. rys. 16).

Rysunek 18 Szczegółowa informacja o elementach klastra wpływających na brak zabezpieczenia danych przed kolejną awarią w klastrze

Podczas restartu maszyny CVM mamy dostęp do szczegółowych informacji o komponentach klastra, które wpływają brak redundancji dla danych w klastrze (rys. 18)

W kolejnym teście wyciągnięto jeden z dysków magnetycznych. W konsoli PRISM szybko pojawił się stosowny alarm, oraz rozpoczęła się procedura zabezpieczania danych które znajdowały się na nim. Po 30 minutach dane były zabezpieczone a klaster gotowy na kolejną awarię. Operację powtórzono jeszcze dwa razy. Tutaj ujawnia się własność self-healing rozwiązania, pomimo, że klaster jest w stanie przetrwać tylko pojedynczą awarię dysku twardego, to jeśli awarie następuję w odpowiednich odstępach czasu – może ich wystąpić więcej. Jak długo ilość danych w klastrze nie przekracza pojemności pozostałych dysków w klastrze – dane pozostają zabezpieczone.

W kolejnym kroku przetestowano awarię zasilania każdego z zasilaczy. Każdorazowo pojawiał się stosowny komunikat w konsoli oraz a z serwera wydobywał się sygnał dźwiękowy oraz na panelu węzła A zaświecała się dioda alarmowa.

Rysunek 19 Widok konsoli po awarii trzech dysków oraz zasilaczy.

Intrygujące jednak był fakt, że awaria zasilacza w konsoli VMware oraz IPMI była sygnalizowana przez węzeł A. Należało zatem sprawdzić co by się stało gdyby podczas trwającej awarii węzła A, nastąpiłaby awaria zasilacza. W ramach kolejnego testu wyjęto z obudowy węzeł A i zasymulowano awarię zasilania. Pojawił się sygnał dźwiękowy, niestety nic więcej – inny węzeł swoją diodą alarmową nie sygnalizował problemu, a w konsolach IPMI, VMware ani PRISM nie pojawiła się stosowna informacja.

Sytuacja jest mało prawdopodobna ale możliwa, a gdyby nastąpiła w środowisku produkcyjnym administrator środowiska miałby bardzo małe szanse szybko zareagować. W tym momencie ujawniła się słabość starej wersji sprzętu Nutanix udostępnionego do testu. Uzyskano zapewnienie, że na nowszym sprzęcie taki problem nie występuje a taka awaria jest prawidłowo raportowana – być może w przyszłości będzie możliwość ponowić ten test, tymczasem pozostaje pewien niedosyt.

Wyjęte wcześniej dyski twarde włożono do obudowy. Nie następuje ich automatyczne dołączenie do klastra – należy zrobić to ręcznie. Tutaj napotkana bardzo dziwny błąd, rozwiązanie sygnalizowało problem z dodaniem dysku (rys. 20)

Rysunek 20 Problem z dodaniem dysku do klastra

Trudno powiedzieć co było jego przyczyną, natomiast aby obejść problem zalogowano się bezpośrednio na adres jeden z maszyn CVM, wówczas dodawanie dysku do klastra nie stanowiło problemu (rys. 21)

Rysunek 21 Procedura dodania dysku twardego do klastra

Następny i ostatni test sprawdzi zachowanie rozwiązania przy najbardziej drastycznej awarii – całkowite odcięcie sieci, którą komunikują się maszyny CVM. Aby móc wykonać ten test przekonfigurowano switche wirtualne aby nie pozwolić maszynom CVM skorzystać z działających interfejsów sieciowych, zapewniając jednocześnie możliwość monitorowania środowiska od strony konsoli VMware (rys. 22).

Rysunek 22 Rekonfiguracja sieci wirtualnej pozwalająca na dostęp do środowiska VMware pomimo odcięcia komunikacji pomiędzy maszynami CVM.

Po rozłączeniu wszystkich interfejsów 10 GBe w konsoli VMware pojawiły się stosowne alarmy, datastore udostępniane przez Nutanix stały się niedostępne (rys. 23), ale pracujące maszyny wirtualne nadal były włączone.

Rysunek 23 Awaria sieci klastra, widok z konsoli VMware

Po zalogowaniu się do pracujących maszyn wirtualnych, okazało się coś niezmiernie ciekawego – maszyny zostały zamrożone, nie reagowały na żadne polecenia (rys. 24)

Rysunek 24 Widok zamrożonej maszyny wirtualnej w wyniku niedostępności datastore na którym się znajdowała.

Stan taki trwał ponad pięć minut. Po ponownym połączeniu interfejsów sieciowych maszyny wirtualne wznowiły pracę bez restartu.

Rysunek 25 Maszyna wirtualne kontynuuje pracę po odzyskaniu dostępu do datestore na którym znajduję się jej pliki

Zamrożenie maszyny wirtualnej nie jest jednak cechą rozwiązania Nutanix lecz VMware. Najważniejszy wynik tego testu to fakt, że nie nastąpiła utrata danych – jest to bardzo ważne, gdyż użytkownik tego rozwiązania może być pewien o bezpieczeństwo danych przechowywanych w klastrze. Po tak poważnej awarii trudno oczekiwać, że rozwiązanie będzie gotowa na kolejne awarie – musi nastąpić synchronizacja metadanych pomiędzy wszystkimi klastrami (rys. 26), jednak inne komponenty zgłaszają gotowość do przetrwania nowych awarii. Możne zatem wysnuć wniosek, że istnieją (odpowiednio dobrane) awarie, które klaster w dalszym ciągu jest w stanie przetrwać. Oczywiście po zakończenia uspójniania danych klaster ponownie staje się w pełni odporny na dowolne awarie.

Rysunek 26 Stan klastra po utracie łączności pomiędzy maszynami CVM

Podsumowanie

Rozwiązanie firmy Nutanix jest bardzo elastyczne, eliminuje konieczność posiadanie dedykowanych pamięci masowych zapewniając bezpieczeństwo przechowywanych danych nawet w skrajnie trudnych sytuacjach. Niestety rozwiązanie nie jest idealne, lecz problemy które się ujawniły absolutnie nie przekreślają tego produktu. Warto dodać, że rozwiązanie bardzo łatwo się aktualizuje za pomocą interfejsu PRISM, nie zakłócając pracy klastra, a częstość wydawanie aktualizacji jest bardzo duża. Być może w chwili pisania tego tekstu część opisanych problemów już nie występuje. W dzisiejszym świecie bardzo szybko zmieniającej się technologii coraz trudniej działom IT jest sprostać wymaganiom biznesu. Firmy, które zainteresują się rozwiązaniem Nutanix będą miały szansę przeznaczyć więcej czasu na spełnianie oczekiwań biznesu, gdyż uproszczony model utrzymania infrastruktury przyczynia się do zmniejszenia obciążenia działu IT jednocześnie dając większa elastyczność i pozwalając szybciej realizować pojawiające się zapotrzebowania na zasoby obliczeniowe i pamięci masowej.