Netapp HCI #4
Po instalacji klastra oraz zapoznaniu się z interfejsami zarządzania rozpoczynamy pracę z NetApp HCI. Przetestujemy jak rozwiązanie zachowuje się w praktyce podczas standardowych czynności administracyjnych jak i podczas tych rzadziej wykonywanych.
Po zapoznaniu się z architekturą i możliwościami klastra, uruchomieniu i zapoznaniu się z interfejsami zarządzania, przyszedł czas na rozpoczęcie pracy ze środowiskiem. W nowo zainstalowanym klastrze do wszystkich serwerów ESXi zamontowane są dwa datastory udostępniane przez SolidFire. W NetApp HCI każdy wolumin musi mieć zdefiniowane parametry QoS, za pośrednictwem polityki lub indywidualnie.
Rysunek 1 Domyślna konfiguracja QoS dla utworzonego podczas instalacji woluminu, parametry konfiguruje się dla bloku 4 kB. Przy wyświetlaniu tych polityk, zdefiniowane wartości przeliczane są także na inne wielkości bloków. Podawany jest także maksymalny transfer wynikający z ilości operacji IO.
Parametr Max IOPS, przyjmuje maksymalną wartość 15000 IOPS, w razie potrzeby dostarczenie do środowiska większej ilości operacji należy założyć dodatkowe wolumeny. Praca z maszynami wirtualnymi w środowisku NetApp, niczym się nie różni od klasycznych środowisk z centralną macierzą, jako że hosty ESXi nie dostarczają zasobów dyskowych do klastra, nie jest konieczne przestrzeganie wobec nich żadnych dodatkowych wytycznych przy ich restartach, czy wprowadzaniu w tryb serwisowy. Przy tworzeniu nowych maszyn wirtualnych należy tylko pamiętać, że polityki QoS przypięte do wolumenów będą zwiększać stopień rywalizacji o zasoby maszyn tam umiejscowionych. Nie zostaną też automatycznie przeskalowane po dodaniu nowego węzła. Przy szczególnych wymaganiach warto zatem rozważyć tworzenie dedykowanych datastorów lub aktywację VVol. Jedna z pierwszych rzeczy, którą moglibyśmy być zainteresowani w kontekście pracy w maszyną wirtualną, to wykonanie snapshota. Można go wykonać dla woluminu lub grupy woluminów, definiując harmonogram wykonania oraz czas, po którym snapshot zostanie automatycznie skasowany. Definiując harmonogram należy zdefiniować czas ważności migawki, gdyż maksymalnie może być ich 32 dla woluminu, a po osiągnięciu tej liczby kolejne nie będą się wykonywać. Pojawi się natomiast stosowny komunikat błędu, zarówno w natywnym interfejsie, jak i w sekcji alarmów vCenter.
Pewną niedogodnością jest brak w interfejsie graficznym możliwości szybkiego kasowania większej ilości snapshotów oraz brak informacji o tym, ile danych jest zakleszczonych w danym snapshocie. W przypadku drugiego problemu wydaje się, że włączona deduplikacja i kompresja powinna niwelować ten problem, jednak w trakcie testów wygenerowaliśmy dane niepoddające się algorytmom deduplikacji, wykonaliśmy snapshot, następnie skasowaliśmy dane w maszynie wirtualnej i wygenerowaliśmy nowe. W wyniku tej operacji tracimy dostęp do przestrzeni zajmowanej przez skasowane dane. Podobny problem mógłby się pojawić przy próbie przechowywania snapshota przed długi okres czasu, gdyż nawet dla danych zmieniających się w wolnym tempie, np. po roku, ilość unikalnych danych zakleszczonych w snapshocie była trudna do pominięcia przy analizie wykorzystywanego miejsca. W domyślnej konfiguracji brak jest również jakiejkolwiek integracji dla mechanizmu wykonywania spójnych aplikacyjnie snapshotów. W wyniku czego otrzymujemy snapshoty, których wykonywania maszyny wirtualnie nie są „świadome”, zatem nie następują żadne operacja wyciszania w systemie operacyjnym, co w skrajnych przypadkach może prowadzić do otrzymania danych niemożliwych do późniejszego wykorzystania. Sytuacja ponownie się zmienia przy aktywacji mechanizmu VVol, dzięki integracji jako daje ten mechanizm, snapshoty wykonane na poziomie VMware, zapisywane są jako snaphoty macierzowe. Zatem maszyny wirtualne mogą być odpowiednio wyciszone, a otrzymany snapshot dawałby większą pewność spójności aplikacji w nim zawartych. Niestety nawet w tym scenariuszu nie dowiemy się ile unikalnych danych zawiera dany snapshot, co każe unikać zbyt długiego ich przechowywania. Wracając do kwestii kasowania dużej ilości wykonanych snapshotow, to NetApp oferuje dla swojego rozwiązania narzędzia pozwalające na automatyzację działań zarówno przez REST API, jaki i za pomocą PowerShell (rys 2).
Rysunek 2 Dostępne dla platformy Solidfire rozszeszania do języka Powershell pozwalają automatyzować wiele czynności, szczególnie te których wykonanie z graficznego interfejsu byłoby bardzo uciążliwe.
W kolejnym kroku przyjrzeliśmy się zachowaniu klastra w trakcie wypełniania go danymi. W tym celu rozpoczęliśmy generację danych niepoddających się deduplikacji. Po przekroczeniu wartości ostrzegawczej w interfejsach pojawia się informacja o dużym wypełnieniu klastra. Przy dalszym wypełnianiu klastra ostrzeżenia zamienią się w błąd, informujący o utracie możliwości odbudowy wymaganej nadmiarowości danych w przypadku utraty jednego z węzłów klastra.
Rysunek 3 W wyniku dużego wypełnienie danymi, w razie awarii jednego węzła, klaster nie będzie w stanie przywrócić wymaganej nadmiarowości danych, jest to sytuacja grożąca utratą danych, dlatego generuje ona krytyczne alarmy w środowisku.
Po całkowitym wysyceniu klastra danymi, wszystkie datastory przechodzą w tryb „tylko do odczytu”, a środowisko przestaje być dostępne. W tej sytuacji jest już za późno, aby skasować pojedynczą maszynę wirtualną, z błędu możemy wyjść tylko na trzy sposoby:
– dodać nowy węzeł storage
– usunąć snapshoty zajmujące sporo danych
– usunąć cały wolumin
Dodanie nowego węzła właściwie nie jest możliwe w rozsądnym czasie, usuwanie snapshotów (o ile je mamy) jest strzałem w ciemno, gdyż nie wiadomo ile miejsca odzyskamy, pozostaje tylko skasowanie jednego z wolumenów, dobrze jest wówczas mieć jakiś względnie mały, który można poświęcić – a maszyny z niego później odzyskać z backupu.
Praca z mechanizmem QoS udostępnianym przez NetApp, jest bardzo intuicyjna i nie nastręcza żadnych problemów. Jedyne o czym należy pamiętać to to, że wartości IOPS prezentowane na wykresach nie są wartościami znormalizowanymi do bloku 4kB, lecz są to wartości dla bloków danych będących w użyciu. Bardzo pomocne w rozeznaniu się w sytuacji są przeliczniki prezentowane przy okazji wyświetlania właściwości woluminów oraz ich szczegółowych wykresach. Prezentowane tam są informacje o wielkościach bloków danych operacji wejścia wyjścia, aktualnie przetwarzanych w środowisku. Na podstawie tych danych łatwo dobrać odpowiednie wartości, a po ich zmianie, środowisko bardzo szybko reaguje. Maszyny wirtualne, które bardzo intensywnie wykorzystywały dyski, po zmianie konfiguracji (mającej na celu ograniczenie operacji IO), niemal natychmiast zmuszane są do zmniejszenia wykorzystania dysków, dostosowując się do nowych ustawień wydajności woluminu zdefiniowanego przez QoS.
W przypadku potrzeby usunięcia jednego węzła storage, należy z interfejsu graficznego usunąć z klastra wszystkie należące do niego dyski. Po czasie niezbędnym na synchronizację danych można usunąć z klastra cały węzeł, by w dalszym etapie usunąć go fizycznie z obudowy jeżeli jest taka potrzeba. Dodanie nowego węzła do klastra także nie nastręcza problemów, po fizycznym podłączeniu, należy za pomocą przeglądarki otworzyć adres udostępniany przez każdy z węzłów storage i przejść przez dostępny tam kreator.
Rysunek 4 Przykładowy ekran z kreatora dodawania nowego węzła do NetApp HCI.
Rozwiązanie samodzielnie wykryje dostępne do dodania węzły obliczeniowe lub dostarczające przestrzeń dyskową, pozwalając wybrać, które dodać (jeżeli byłoby wykrytych więcej), w kolejnym kroku należy podać konfigurację sieciową dla nowego węzła, a po przejrzeniu wprowadzonych ustawień rozpocząć proces dodawania nowego węzła.
Odnośniki do poprzednich części serii:
What I recommend
Cloud Field Day 21: Too many clouds