Maxta #5
Ostatnia już część z serii Maxta dotyczyć będzie pracy z klastrem. Poniżej znajdą Państwo linki do wszystkich wcześniejszych artykułów z tej serii.
Po zapoznaniu się ze środowiskiem, jedną z pierwszych rzeczy jakie wykonaliśmy, to utworzenie maszyny wirtualnej, na której zaczęliśmy generować dużą liczbę danych nie poddających się zbytnio kompresji. Klaster bardzo sprawnie przyjmował nowe dane. Jako że operacja trwała dość długo, pozostawiliśmy tak środowisko na kilka godzin. Po ponownym zalogowaniu okazało się, że maszyna wirtualna jest wyłączona, a próba jej włączenia kończy się niepowodzeniem. Powtórzyliśmy ten test dla większej liczby maszyn jednocześnie generujących dane i sytuacja się powtórzyła. Próba restartu czy włączenia maszyn kończyła się różnymi komunikatami błędu w tym takim, o braku wolnego miejsca na datastorze. Było to o tyle dziwne, że zgodnie z dashbordem zajętość klastra wynosiła tylko 80%. Po dalszej analizie zdarzeń w systemie okazuje się, że przyczyną problemów było osiągnięcie na jednym węźle zajętości na poziomie 90%. Zbliżanie się do tej wartości wyzwoliło resynchronizację danych w klastrze celem zbalansowania zajętości dysków w poszczególnych węzłach.
Niestety danych w klastrze przybywało szybciej niż system był sobie stanie z nimi poradzić, co skończyło się zablokowaniem całego klastra i sygnałem dla wszystkich maszyn o braku wolnego miejsca. Analizując dokumentację producenta można znaleźć informację, że klastra nie można wypełnić bardziej niż w 90%. Oznacza to zatem, że w systemie jest niejako cały czas zarezerwowane 10% pojemności, która jest raportowana jako miejsce użyteczne dla maszyn wirtualnych, lecz nigdy nie da się z niego skorzystać. Być może warto, aby producent przeskalował wartości pokazywane przez rozwiązanie, aby zamiast pokazywać dostępność np. 10TB danych, a adminstrator pamiętał, że maksymalnie można wykorzystać 90%, aby w raporcie było dostępne 9TB danych z możliwością osiągnięcia 100% zajętości. Analizując w dalszym ciągu dokumentację można natknąć się na rekomendację, aby nie przekraczać 75% zajętości klastra, gdyż może to powodować spadek wydajności.
Kolejny scenariusz możemy nazwać testem skalowalności, w ramach którego przygotowaliśmy maszynę, generującą dużą ilość danych, lecz za każdym razem o takiej samej charakterystyce pod kątem podatności na kompresje. Jako, że klonowanie mechanizmem Maxta „wiąże” maszyny wirtualne ze sobą, co mogło by mieć negatywny wpływ na uzyskaną wydajność, przygotowaliśmy owe maszyny wykorzystując mechanizm klonowania VMware. W ramach testu uruchomiliśmy najpierw jedną maszynę na jednym węźle, potem dwie na dwóch, trzy na trzech, a na koniec sześć maszyn na trzech węzłach które mamy w klastrze. Przyrost czasu generacji danych wyglądał następująco:
- Generowanie danych przez dwie maszyny wirtualnie (powstało 100% danych więcej) trwało 11% dłużej,
- Generowanie danych przez trzy maszyny wirtualnie (powstało 50% danych więcej) trwało 26% dłużej niż dla dwóch maszyn,
- Generowanie danych przez sześć maszyny wirtualnych (powstało 100% danych więcej) trwało 87% dłużej niż dla trzech maszyn.
Nie trudno sobie wyobrazić, że posiadając klaster składający się z większej liczby węzłów, oraz dzięki zastosowanym w Maxta mechanizmowi rozkładania danych, uzyskalibyśmy jeszcze lepsze wyniki. Podczas zwiększania liczby maszyn, a zatem i generowanych danych, za każdym razem uzyskiwaliśmy sumarycznie lepszy wynik, biorąc pod uwagę całkowitą ilość przetworzonych danych. W środowisku produkcyjnym z mieszanym rodzajem obciążeń, w którym nie następują sytuacje, gdzie wszystkie węzły jednocześnie próbują zapisywać dane, uzyskany efekt skalowalności byłby jeszcze bardziej widoczny. Łatwo zatem potwierdzamy zapewnienia, że wraz ze wzrostem liczby węzłów w klastrze rośnie nie tylko całkowita dostępna pojemność, ale i również sumaryczna wydajność, możliwa do dostarczenia dla wszystkich maszyn wirtualnych. Warto wspomnieć, że nawet podczas testu z sześcioma pracującymi maszynami wirtualnymi obciążenie procesorów poszczególnych kontrolerów wirtualnych wynosiło średnio 50,60 i 70%, a w momentach szczytowych dochodząc do 90%. Wynik ten jest satysfakcjonujący, gdyż potwierdza niewielkie zapotrzebowanie na moc procesora. Fakt jest ten o tyle istotny, że w ramach licencjonowania hostów ESXi kupujemy licencje na procesory, uruchamiając zatem dodatkowe rozwiązania zużywające tą moc, w praktyce obniżamy całkowitą dostępną moc dla produkcyjnego środowiska. Fakt ten jest cechą charakterystyczną wszystkich rozwiązań hiperkonwergentnych i jest elementem, wspomnianego w pierwszej części artykułu, uproszczenia.
Przy okazji powyższego testu kasowaliśmy migawki maszyn wirtualnych czy same maszyny, po takim kasowaniu dane w klastrze odzyskiwane i raportowane jako wolne są w szybkim tempie. Przy braku obciążenia klastra generowaniem nowych danych, rozwiązanie bez problemu uwalnia skasowany 1 TB danych w ciągu kilkunastu minut. Wynik ten jest bardzo dobry, gdyż nie powinniśmy się spodziewać natychmiastowych reakcji klastra na kasowanie danych ze względu na rozproszoną architekturę.
Ostatnim przetestowanym aspektem jest zachowanie się rozwiązania w sytuacji różnego rodzaju problemów prowadzących do niedostępności poszczególnych węzłów w klastrze. W normalniej sytuacji w klastrze są trzy węzły, które składają się na dostępną przestrzeń, wydajność i zapewniają wymaganą nadmiarowość danych, mającą na celu zapewnić odporność na jedną lub dwie awarie (w zależności od polityki przypisanej do maszyny wirtualnej). Podczas tych testów włączone były maszyny generujące dane, aby zasymulować obciążenie. W pierwszym kroku odłączyliśmy sieć storage od jednego z kontrolera. W wyniku tej operacji na kilka minut tracimy dostęp do interfejsu MxInsight. Po ustabilizowaniu się sytuacji widzimy, że awaria została zaraportowana przez rozwiązanie, na dashbordzie widocznie są stosowne alarmy oraz rozpoczął się proces odbudowy wymaganej nadmiarowości dla kilku maszyn.
Jednak nie od razu dostępne są wszystkie dane, np. dane wydajnościowe klastra, dostępne są po kolejnych kilku minutach. Pracujące maszyny wirtualnie nie doświadczają problemów i cały czas działają. W kolejnym kroku odłączamy drugi kontroler wirtualny od obu sieci, klaster tym samym utracił większość, a część danym może być niedostępna ze względu na dwie awarie, które wystąpiły. W takim scenariuszu Maxta przestaje udostępniać dane, aby nie dopuścić ich uszkodzenia. Pracujące maszyny wirtualne ulegają zamrożeniu, a wyłączone mają status innaccessible w vCenter. Następnie wyłączamy maszynę wirtualną – ostatni działający w tym momencie kontroler. Ta operacja nie wiele zmienia, gdyż klaster przestał być już dostępny w poprzednim kroku. Następnie podłączamy sieć do kontrolerów odłączonych w pierwszym kroku, a ostatnio wyłączony pozostawiamy w takim stanie. Po kilku minutach interfejs MxInsight jest dostępny, lecz nie ma w nim jeszcze wszystkich danych. Po stosunkowo krótkim czasie klaster udostępnia współdzielony datestore dla ESXi w trybie do zapisu. W tym czasie kasujemy foldery bezpośrednio na datastore, celem sprawdzenia, czy pojawią się jakieś błędy, gdy włączymy ostatni kontroler, klonujemy także jedną maszynę wirtualną.
Gdy wszystko wydaje się znowu działać, wyłączamy oba pracujące kontrolery. Po ich włączeniu pojawiają się problemy z maszynami wirtualnymi, które działały. Wydaje się, że mogło nastąpić jakieś uszkodzenie ich danych. Po niedługim czasie interfejs jest dostępny, lecz wspomniane maszyny ciągle nie dają się uruchomić. W kolejnym kroku włączamy ostatni kontroler, po kilkunastu minutach maszyny, które wydawały się być uszkodzone, uruchamiają się bez problemu, nie odnotowano w nich utraty danych. W sytuacji, gdy wszystkie trzy kontrolery są dostępne, sytuacja powoli się stabilizuje, a dla wielu maszyn w klastrze aktywne są zadania resynchronizacji. Po ich zakończeniu klaster pracuje normalnie. Po ustabilizowaniu sytuacji w ramach ostatniego testu wykonujemy reset wszystkich hostów ESXi jednocześnie. Także po tym teście, po wymaganym czasie sytuacja się stabilizuje i nie odnotowaliśmy utraty danych.
Podsumowanie
Na tym kończmy testy rozwiązania firmy Maxta, dużym plusem jest łatwość instalacji klastra oraz przyjęta architektura oprogramowania. Brak bezpośrednich zależności ze sprzętem da klientom elastyczność w doborze rozwiązania pod swoje potrzeby, zarówno w momencie zakupu, jak i w trakcie eksploatacji, jeśli pojawi się konieczność rozbudowy klastra – nie konieczne o dodatkowe węzły. Sam interfejs zarządzający jest ładny, responsywny i brak mu zbędnych elementów. Niestety w wyniku braku integracji z interfejsem vCenter, a chcąc w pełni kontrolować środowisko, zawsze będzie trzeba się tu logować, jednocześnie dzięki zarządzaniu w pewnym zakresie maszynami wirtualnymi, rzadziej będziemy musieli korzystać z interfejsu vCenter. Zastanawiające jest również, dlaczego przy wymianie dysków w węzłach należy się jeszcze logować do kontrolerów przez SSH, implementacja tych funkcji w interfejsie nie powinna być problemem, a proces byłby łatwiejszy i szybszy. Można by jeszcze wypomnieć pewne niedogodności interfejsu, lecz ważniejsze jest, jak się pracuje z danymi. Sporym mankamentem jest brak informacji o ilości miejsca zakleszczonego w migawkach, oraz brak dostępności danych, gdy któryś w węzłów osiągał zajętość miejsca na poziomie 90%.
Oczywiście świadomość tych niedoskonałości pozwoli tak zarządzać środowiskiem, aby nie doprowadzać do przestojów, dlatego tak istotne jest testowanie rozwiązań we własnych środowiskach, pod kątem własnych potrzeb. To co jest największą zaletą i siłą Maxta, jest realizacja serca hiperkonwergencji – świadczenie dostępu do rozproszonych danych, przy małym obciążeniu zasobów lokalnych w szczególności procesorów. Świadczone dane są bezpieczne i dostępne w ramach przewidywanych awarii, w sytuacji większych awarii nie nastąpiła utrata danych, a po stosunkowo krótkim czasie od ich ustąpienia rozwiązanie ponownie świadczy usługi dostępu do danych. Dodatkowo jako, że całość rozwiązania oferowana jest jako oprogramowanie, możemy się spodziewać bezproblemowej aktualizacji oraz implementacji nowych funkcji, nie ograniczonych zależnościami ze sprzętem na którym pracuje. Nie da się ukryć, że większość dostawców rozwiązań hiperkonwergentncych, jest w jakimś zakresie uzależniono od sprzętu, na którym rozwiązanie działa, przez co przy aktualizacjach czy wymianach starych serwerów, sprzęt często musi być zamówiony i serwisowany u konkretnego dostawcy. W przypadku Maxta mamy wolność w tym zakresie, dlatego firmy, dla których ten aspekt jest ważny, szczególnie powinny się przyjrzeć temu rozwiązaniu.
Poniżej znajdą Państwo linki do wcześniejszych artykułów: