Cisco HyperFlex Hiperkonwergencja od Cisco #7

Dzisiejszy wpis dotyczący testów odporności na awarię jest już ostatnim wpisem z serii Cisco HyperFlex Hiperkonwergencja od Cisco. Po przyjrzeniu się możliwościom oferowanym przez HyperFlex w zakresie obsługi obciążeń, przyjrzymy się, jak reaguje na awarie różnych komponentów. Przed awariami obciążamy klaster generacją danych, zastosowaną wcześniej do testów skalowalności klastra, w wyniku czego zajętość klastra rośnie w trakcie testu, a odnotowana średnia zajętość pojedynczego dysku w klastrze wynosi 20 GB.

Awaria podzespołów

Pierwsza awaria to wyjęcie jednego dysku z warstwy danych z pierwszego węzła. Odpowiednie alarmy niezwłocznie pojawiają się zarówno w konsoli vCenter, jak i HyperFlex Connect. Pomimo trwających problemów klaster raportuje zdolność do zniesienia kolejnej pojedynczej awarii – Replication Factor skonfigurowany na wartość trzy oznacza dostępność każdej porcji danych w trzech kopiach, a utraciliśmy jedną kopię. Po ośmiu minutach sytuacja wraca do normy, wymagana nadmiarowość jest przywrócona, klaster oznaczany jest jako zdrowy, a wyjęty dysk zgłaszany jako niesprawny.

Wyjmujemy kolejny dysk, tym razem z drugiego węzła, by klaster już po czterech minutach zaraportował wymaganą nadmiarowość danych w klastrze. Powtarzamy operację dla dysku w czwartym węźle, by po trzech minutach ponownie uzyskać pełną gotowość na kolejne awarie! Istotne jest to, że w wyniku kolejnych awaria raportowana jest coraz mniejsza całkowita dostępna pojemność klastra.

Wkładamy wszystkie wyjęte dyski i przechodzimy do kolejnej awarii polegającej na awarii czterech dysków z warstwy przechowywania danych w pierwszym węźle. Po jedenastu minutach klaster zgłasza przywrócenie wymaganej nadmiarowości danych. Następna awaria polegała na wyjęciu dwóch dysków SSD z kolejnych węzłów. W wyniku takiej awarii nie nastąpiła utrata dostępu do danych, maszyny wirtualne w dalszym ciągu były w stanie kontynuować pracę. Rolę utraconych dysków przejęły pracujące na pozostałych węzłach.

Awaria sieci

W dalszym etapie przyjrzymy się scenariuszom z awarią sieci. W testowym środowisku sieć kliencka, do której podłączone były Fabric Interconnecty zrealizowana była połączeniami 1 GbE. W wyniku rozłączania połączeń sieciowych od serwerów nie nastąpiła utrata danych, szybko pojawiały się odpowiednie komunikaty o braku jednego z połączeń sieciowych, wart odnotowania jest natomiast fakt, że FI nie realizują przełączania pomiędzy VLAN-ami, a komunikacja pomiędzy nimi ogranicza się do synchronizacji konfiguracji, zatem w sytuacji awarii kilku połączeń ruch pomiędzy węzłami dochodzi do przełączników LAN. Łatwo wywołać taki scenariusz, odłączając dwa serwery od pierwszego FI, a dwa kolejne od drugiego FI. Po wykonaniu takiej operacji prędkość zapisu danych w klastrze spadła ze 100 MBps do 20 MBps, a opóźnienia dla trwających operacji skoczyło z 6 ms do 50 ms.

Test ten pokazuje odporność rozwiązania na awarie sieci, jednocześnie ukazując, jak istotny jest aspekt istniejącej sieci klienta, która domyślnie nie jest dostarczana razem z klastrem hiperkonwergentnym. Po przywróceniu prawidłowej łączności sieciowej sprawdzimy, jak się zachowa klaster w przypadku niedostępności większej liczby węzłów. Odłączenie od sieci jednego węzła niewiele zmienia, maszyny wirtualne pracują, dane są dostępne, awarią mogą być dotknięte tylko maszyny pracujące na niedostępnym węźle – musi tu zadziałać mechanizm HA będący częścią technologii VMware.

Odłączenie drugiego węzła powoduje całkowicie odmienne zachowanie – klaster przechodzi w tryb tylko do odczytu, pracujące maszyny wirtualne zostają zamrożone, hosty ESXi zgłaszają niedostępność współdzielonego datastore. Można by pomyśleć, że nastąpiła poważna awaria lub niewłaściwe zachowanie klastra, jednak zachowanie jest jak najbardziej prawidłowe, zgodnie z opisem w poprzedniej części artykułu: do prawidłowej pracy klastra wymagana jest ponad połowa węzłów, w przypadku niespełnienia tego warunku klaster wstrzymuje udostępnianie danych. Pozostałe dwa węzły w klastrze nie stanowią ponad połowy wszystkich węzłów, zatem zachowanie jest zgodnie z zaprogramowanym działaniem. Po ponownym podłączeniu węzłów w ciągu kolejnych pięciu minut sytuacja wraca do normy. Klaster jest zdrowy, zamrożone maszyny wirtualne wznawiają pracę, a wyłączone dają się włączyć. Ostatnim testem jest rozłączenie połączeń pomiędzy Fabric Interconnectami, prowadzące do rozdzielenia pojedynczej warstwy logicznej, jaką one tworzą. Można by założyć, że takie działanie może znacznie zakłócić pracę klastra, jednak nic takiego się nie dzieje. FI komunikuję się ze sobą poprzez pozostałe interfejsy, które służą do transmisji danych, a całe rozwiązanie nawet w tym przypadku działa stabilnie.

 Podsumowanie

Rozwiązanie Cisco HyperFlex bazuje na silnych podstawach, na które składają się: sieciowy rodowód Cisco, zebrane doświadczenie na rynku serwerów oraz platforma Springpath będąca sercem systemu software defined storage. Przeprowadzone testy ukazały przyjazne procedury instalacji klastra, prostotę oraz przejrzystość interfejsów zarządzających, spore możliwości związane z wirtualizacją i zapewniające odporność na sytuacje awaryjne. Podczas testu nie udało się doprowadź do destabilizacji pracy klastra czy utraty danych. Godna uwagi jest stabilność i przewidywalność zachowania rozwiązania, szczególnie uwidoczniona przy porównaniu klastra hybrydowego z all flash. Nie bez znaczenia ma tu rozkładanie nawet pojedynczego obciążenia na wszystkie komponenty klastra, co czyni wydajność przewidywalną i minimalizuje ryzyko powstania elementów bardziej obciążonych od pozostałych. Zarówno łatwość zarządzania całością, jak i pojedynczy punkt wsparcia dla całego rozwiązania są kolejnymi atutami, gdyż minimalizują ryzyko pojawienia się problemów wynikających ze stosowania produktów różnych dostawców. W sytuacji wzrostu zapotrzebowania na miejsce łatwo i szybko można rozbudować klaster o nowe węzły hiperkonwergentne, jeśli brakuje tylko wydajności procesorów, równie łatwo można rozbudować go węzłami wyłącznie korzystającymi ze współdzielonej przestrzeni dyskowej, które same natomiast dostarczają zasoby CPU czy RAM. Tempo rozwoju omawianej platformy jest bardzo duże, co każe oczekiwać kolejnych funkcjonalności udostępnianych dla obecnych i nowych klientów. Organizacje, które utrzymują i rozwijają lokalne centra przetwarzania danych, stosując technologie hiperkonwergentne, mają szansę dotrzymać kroku tym, które stawiają na rozwój swoich systemów w chmurze publicznej.

Zalety:

  • Duża oraz przewidywalna wydajność dzięki udziałowi wszystkich dysków w klastrze w obsłudze nawet pojedynczej maszyny wirtualnej,
  • Elastyczność w rozbudowie klastra, wykorzystaniu klasycznych rozwiązań storage oraz łatwość udostępniania zasobów do węzłów niebiorących udziału w przechowywaniu danych,
  • Zawsze włączona deduplikacja i kompresja,
  • Wysoka odporność na awarie,
  • Bardzo dobra integracja z vCenter, przejrzysty i wygodny w obsłudze interfejs HyperFlec Conect,
  • Prosty model licencyjny – jeden poziom licencji,
  • Pełna integracja, kontrola i wsparcie na całość rozwiązania sprzętowo programowego jednego dostawcy
  • Możliwość uruchomienia szyfrowania danych bez obniżenia wydajności.

Wady:

  • Brak możliwości regulacji operacji IO dla maszyn wirtualnych z poziomu klastra HyperFlex oraz brak możliwości „przypięcia” wybranych maszyn wirtualnych do warstwy buforującej dla wersji hybrydowej,
  • Specyficzna integracja migawek macierzowych, niedająca pełnej i łatwej kontroli procesu,
  • Replikacja do zdalnego klastra udostępnia tylko najnowsze wersje maszyn wirtualnych oraz nie jest możliwa do uruchomienia pomiędzy klastrem all flash i hybrydowym,
  • Brak pełnej wymienności konsol zarządzających vCenter oraz HyperFlex Connect,
  • Zawsze włączona deduplikacja i kompresja.

AUTOR

Autor jest administratorem systemów IT. Zajmuje się infrastrukturą sieciowo-serwerową, pamięciami masowymi oraz wirtualizacją. Posiada tytuły VCP, MCP oraz CCNA.

Artykuł został opublikowany na łamach IT Professional.

Poniżej znajdą Państwo linki do wcześniejszych artykułów: