VxRail – Testy odporności na awarie

Po fizycznej instalacji oraz po uruchomieniu klastra VxRail można przyjrzeć się innym aspektom pracy rozwiązania. W tej części skupimy się na odporności rozwiązania na możliwe awarie a w szczególności czy istnieje możliwość utraty danych lub braku stabilności.W testowanym egzemplarzu, w ramach jednej obudowy znajdują się cztery serwery oraz dwa zasilacze. Awaria zasilaczy (lub brak informacji o problemach z zasilaczami) będzie skutkował problemami ze wszystkimi serwerami w obudowie. Wyjmujemy zatem pierwszy zasilacz, następnie drugi (wkładając wcześniej pierwszy). Awaria zasilania jest zgłaszana zarówna w konsoli vCenter, VxRail Managera, jak i przez każdy z węzłów w jego interfejsie IPMI. Jest to oczekiwane zachowanie, gdyż potencjalny problem ma minimalne szanse pozostać niezauważony.

Rysunek 1 Widok z VxRail Managera sygnalizującego problem z zasilaczem obudowy. Awaria zasilania jest propagowana na poszczególne węzły, dzięki czemu każdy z nich niezależnie może zgłosić problem.

Rysunek 2 Widok z Web Client, w którym problemy ze wspólnymi zasilaczami są zgłaszane przez każdy z węzłów

W kolejnym teście sprawdzimy jak się zachowa środowiska w sytuacji utraty większości węzłów. Należy tutaj zwrócić uwagę, że vCenter jak i VxRail Manager znajdują się wewnątrz klastra którym zarządzają. Przy problemie z całym klastrem, który zakłóci pracę maszyn wirtualnych, utracimy możliwość monitorowania środowiska jak i zarządzania nim. Chcąc się ustrzec przed takimi problemami należałoby maszyny zarządzające umieścić poza klastrem. W procesie instalacji środowiska wybraliśmy opcję umieszczenia serwera vCenter wewnątrz klastra. Nie chcąc jednak poświęcać zbyt dużo czasu potrzebnego na wyjęcie vCenter ze środowiska, skorzystamy z dużej elastyczności którą daje klaster vSAN – otóż jeden z lokalnych dysków węzła „wyjmiemy” z klastra, tworząc z niego lokalny datastore. W kolejnym kroku możemy przenieść na niego maszyny wirtualne służące do zarządzania środowiskiem. W wyniku tych działań mamy maszyny wirtualne zależne do jednego hosta ESXi, lecz jednocześnie niezależnego od innych. Pomimo przewidywanych problemy z dostępnością klastra, będziemy cały czas w stanie monitorować sytuację w środowisku.

Przygotowani do awarii, wyłączamy kolejne serwery, z wyjątkiem tego na którym jest vCenter. Sytuacja bardzo szybko się zmienia. Maszyny wirtualne na pracującym węźle doświadczają „zamrożenia” z powodu braku dostępu do datastore na którym są ich pliki, natomiast maszyny uruchomione na pozostałych węzłach mają status disconnected z powodu niedostępności ich danych jak i hosta na którym były zarejestrowane.

Rysunek 3 Awaria klastra generuje dużą liczbę alarmów w środowisku.

W następnym kroku włączamy serwery. Po zakończeniu procedury startu, klaster vSAN wznawia swoje działanie. Maszyny wirtualne które były zamrożone wznawiają pracę, pozostałe natomiast zostają uruchomione. Po ustabilizowaniu się klastra nie odnotowano problemów z dostępnością maszyn wirtualnych czy utraty danych.

Rysunek 4 W wyniku braku dostępności węzłów klastra, zmniejszała się dostępna przestrzeń. Wykres bardzo dobrze obrazuje elastyczność rozwiązania – gdy jest dostępny chociaż jeden węzeł, jego przestrzeń może być wykorzystana na potrzeby przechowywania danych, lecz już bez gwarancji odporności na awarie. Gdy kolejne węzły wracają do klastra, dostępna przestrzeń ponownie się zwiększa.

W przypadku awarii pojedynczych dysków twardych, rozwiązanie zachowuje się równie elastycznie, dane z utraconego dysku są odbudowywane na innym. Oczywiście tylko wówczas gdy dane te nie były jedyną kopią. Czas odbudowy zależy od ilości danych, które się na dysku znajdowały, co teoretycznie zawsze jest szybsze niż w klasycznych konfiguracjach RAID, gdzie należy odbudować cały dysk – nawet jeśli nie ma tam danych tylko pusta przestrzeń. Można zatem sobie wyobrazić sytuację w której w odstępie kilku godzin ulegają awarii kolejne dyski a klaster jest dalszym ciągu w pełni funkcjonalny – do momentu gdy wykorzystanie danych w klastrze nie zrówna się z dostępną przestrzenią (które się zmniejsza w wyniku kolejnych awarii). Analogiczna sytuacja ma miejsce w przypadku awarii całego węzła, lub komponentu będącym pojedynczym punktem awarii danego serwera – pozostałe serwery w klastrze odtwarzają wymaganą nadmiarowość danych kosztem pozostałego wolnego miejsca.

Wyniki z przeprowadzonego testu nie dają podstaw do obaw o bezpieczeństwo przechowywanych danych, w pewnych natomiast sytuacjach, bezpieczeństwo jest większe niż w przypadku klasycznych macierzy dzięki odtwarzaniu wymaganej nadmiarowości danych jeszcze przed wymianą wadliwych komponentów. W klasycznych rozwiązaniach pełne bezpieczeństwo przechowywanych danych jest przywracane po wymianie wadliwego dysku twardego i ewentualnej odbudowie struktur danych. Modułowa konstrukcja testowanego rozwiązania hiperkonwergentnego umożliwia łatwą rozbudowę w przypadku wzrostu zapotrzebowania na zasoby a w szczególności większą elastyczność w przypadku awarii.