Netapp HCI #5
W ostatniej części sprawdzimy jak NetApp HCI reaguje na możliwe w środowisku awarie komponentów rozwiązania, jak i tych składników, od których całość jest zależna.
Wiemy już jak się pracuje z NetApp HCI, pozostało już tylko sprawdzić scenariusze, których nikt nie chciałby doświadczać w produkcyjnym środowisku, szczególnie jeżeli miałby one doprowadzić do utraty danych lub dostępności systemu. Sprawdzimy zatem czy użytkownicy opisywanego systemu mają się czego obawiać.
W pierwszym teście wyłączyliśmy jeden z przełączników, który za pomocą interfejsów 10 GbE zapewnia łączność elementom udostępniającym, jak i korzystającym ze współdzielonej przestrzeni dyskowej. Celem sprawdzenia wpływu na pracujące środowisko, we włączonych maszynach wirtualnych uruchamiamy obciążenia generujące operacje zapisu. Podczas wyłączania sieci, zaobserwowaliśmy krótką przerwę w dostępie do danych, które jednak nie spowodowały żadnych problemów w środowisku.
Rysunek 1 Wygenerowana awaria jednego z przełączników 10 GbE, spowodowała krótkotrwałą niedostępność w środowisku. W prawej części panelu możemy dostrzec cztery alarmy sprzętowe wynikające z zasymulowanej awarii i reprezentujące cztery połączenia sieciowe, z którymi wystąpił problem.
Przy podłączeniu do zasilania wyłączonego switcha, w środowisku nie nastąpiła żadna przerwa w dostępie do danych. W kolejnym teście wyjmowaliśmy dyski twarde z węzłów odpowiedzialnych za dostarczanie pamięci masowej do klastra. Wyjęcie takiego dysku generuje alarmy także na poziomie vCenter, przez co trudno ich nie dostrzec. Węzeł z którego wyjęliśmy dysk posiadał rolę Master, być może rozwiązanie nie dopuszcza, aby węzły doświadczające problemów koordynowały cały klaster, gdyż pierwszym objawem wyboru nowego koordynatora był brak dostępu do interfejsu zarządzania. Dopiero po chwili interfejs był znowu dostępny do pracy, ale był już udostępniany z innego węzła. W wyniku utraty dysku następuje proces przywrócenia danych z wyjętego dysku wymaganej nadmiarowości, wymaga to fizycznego skopiowania danych oraz przebudowy dzienników zdeduplikowanych metedanych (rys. 2)
Rysunek 2 Przykładowy widok zadań mających na celu odbudowę wymaganej nadmiarowości danych w klastrze po awarii komponentu.
Po wymaganych synchronizacjach wyjęliśmy kolejny dysk z innego węzła, klaster ponownie zasygnalizował problem odpowiednimi alarmami oraz rozpoczął proces odbudowy. Czynności te moglibyśmy powtarzać tak długu, jak długo pozostałe w klastrze dyski byłyby w stanie pomieścić wszystkie dane, z zachowaniem wymaganej nadmiarowości. W kolejnym teście zasymulowaliśmy awarię całego węzła storage. Cały proces alarmowania i odbudowy wyglądał podobnie jak w przypadku pojedynczego dysku, tylko trwał dłużej, gdyż wymagał odtworzenia większej porcji danych. Nie czekając na zakończenie procesu odbudowy, wyłączyliśmy kolejny węzeł storage. Po tej operacji wszystkie udostępniane datastory przestały być dostępne, co zostało zaraportowane przez serwery ESXi. Zachowanie takie wynika z faktu, że klaster do pracy wymaga większości węzłów, w przypadku klastra składającego się z czterech węzłów storage, awaria już dwóch powoduje, że pozostałe dwa nie mają wymaganej większości, zatem aby nie doprowadzić do utraty danych, przestają udostępniać dane. Wydaję się zatem, że lepszym rozwiązaniem byłoby posiadanie co najmniej pięciu węzłów storage w klastrze, gdyż awaria dwóch nie unieruchamiałaby całego środowiska. Kontynuując testy wyłączyliśmy trzeci węzeł, po to, by włączać je w tej samej kolejności w jakiej je wyłączaliśmy. Włączenie węzłów w tej kolejności miało szansę doprowadzić do uszkodzenia, czy krytycznego rozsynchronizowania klastra. W sytuacji, gdy już trzy węzły znowu pracowały, alarmy sugerowały poważną awarię oraz konieczność zgłoszenia się do wsparcia producenta. Jednak gdy ostatecznie i czwarty węzeł został włączony, a dane zostały zsynchronizowane, wszelkie alarmy ustąpiły, nie odnotowaliśmy również żadnej utraty danych.
Ostatnim przeprowadzonym testem była awaria zasilania, tutaj także wszystko zadziałało prawidłowo, a awaria została zauważona i zgłoszone przez wszystkie węzły.
Podsumowanie
NetApp w swojej ofercie ma bardzo ciekawy produkt, który klasyfikuje jako hiperkonwergencja następnej generacji. Dyskusyjną kwestią jest, czy to jest rozwiązanie hiperkonwergentne, gdyż składa się z dwóch rodzajów węzłów, klasyczne podejście wymaga jednego rodzaju uniwersalnych węzłów. Podejście klasyczne, choć upraszcza budowę fizycznej struktury, wprowadza pewne niedogodności ze skalowaniem i licencjonowaniem (zarówno w warstwie hiperwizorów, jak i w warstwie aplikacji pracujących w takim klastrze). NetApp wziął to, co najlepsze ze świata klastycznych macierzy, przygotował integrację ze środowiskiem wirtualizacji i oferuje bardzo ciekawy produkt, który w testach wypada bardzo obiecująco. W żadnym scenariuszu nie doszło do utraty danych, a przewidywalna wydajność, dzięki politykom QoS, pozwala lepiej panować nad zróżnicowanym obciążeniem pojawiającym się w środowisku oraz skalowanie w razie rozrostu środowiska. Platforma NetApp HCI nie jest jednak dla wszystkich, minimalna konfiguracja wymaga sześciu serwerów, w tym czterech udostępniających zasoby dyskowe. Nie jest to zatem rozwiązanie dla ROBO (Remote Office/Branch Office) – czyli dla małych firm, czy lokalnych oddziałów. Jest ono natomiast dla dużych centrów przetwarzania danych szukających łatwości w zarządzaniu i rozbudowie oraz przewidywalnej i konfigurowalnej wydajności.
Pewną bolączką jest fakt braku informacji o miejscu zajmowanym przez snapshoty, co w zależności od sposobu pracy ze środowiskiem może być sporym utrudnieniem, lecz jako, że jest to funkcjonalność dostarczana przez oprogramowanie, prawdopodobnie jest to tylko kwestia czasu, gdy zostanie ona zaimplementowana i udostępniona. Inną potencjalnie kłopotliwą sytuacją jest scenariusz, w którym wyczerpuje się miejsca w klastrze, gdy to nastąpi wszystko przestaje działać. Brak jest funkcjonalności jakichkolwiek rezerwacji miejsca dla maszyn wirtualnych czy woluminów, nie można zatem stworzyć woluminów odpornych na zaborcze o przestrzeń dyskową maszyn wirtualnych. Innym, wymagającym indywidualnej analizy, jest aspekt implementacji tylko jednej dodatkowej kopii danych przechowywanych w klastrze. Trudno jednak nie wspomnieć o łatwości usuwania i dodawania węzłów do klastra, ścisłej integracji z vCenter oraz oferowanej integracji z pozostałymi produktami NetApp. Biznesy potrzebujące zabezpieczyć swoje dane w zdalnej lokalizacji mają dostępne możliwości replikacji synchronicznej, asynchronicznej czy kopiowania snapshotów. Łatwość udostępniania zasobów poza środowiska także jest godne uwagi. Także bardzo istotną kwestią jest dostępność narzędzi do automatyzacji środowiska.
Trudno jest wyrokować, w którą stronę pójdzie rynek hiperkonwergencji, czy okaże się, że klasyczny model zostanie zrewidowany i zmieni się jego architektura. Pewne jest natomiast, że NetApp HCI jest produktem, który może wyznaczyć nowy kierunek tego trendu. Oczywiste jest również, że jeszcze nie ma jednego rozwiązania będącego w stanie zadowolić wszystkich konsumentów, dlatego przed podjęciem decyzji o zakupie, warto wcześniej zrobić test, a przygotowując listę rozwiązań do przetestowania warto do niej dopisać NetApp HCI.
Odnośniki do pozostałych części serii:
What I recommend
Cloud Field Day 21: Too many clouds