Simplivity – testy (nie)zawodnościowe cz. IV

Przed Wami ostatnia część opisu rozwiązania Simplivity Omnicube. Podczas naszych testów spotkaliśmy się z pewnymi elementami, które mogą być uznane za błąd, lub niedopracowanie. Oddając jednak bogu co boskie a cesarzowi co cesarskie należy zaznaczyć, że niektóre z nich zostały już poprawione w nowym wydaniu softu.

Tak, czy inaczej testy przeprowadziliśmy. Robiliśmy wszytko w metodologi “Jak się coś wysypało to zapisane zostało skrzętnie w małym czarnym notatniczku”. Przed wami zatem pewne wnioski z instalacji, krótkotrwałego użytkowania i psucia.

Federacja w akcji

W poprzedniej części uruchomiliśmy federację składającą się z dwóch węzłów. Przyjrzyjmy się pobieżnie, jakie możliwości SimpliVity daje:

Na Poziomie vCenter:

• obsługa backupów, podłączenie do AWS celem utworzenia nowego miejsca przechowywania backupów, utworzenia zgłoszenia do producenta

• Ilość wolnego/zajętego/całkowitego miejsca w federacji, strefa czasowa, wersja rozwiązania, ilość danych przesyłanych do innych Datacenter oraz zdefiniowane polityki backupu

Na poziomie Datacenter:

• Backupy, definicja strefy czasowej, konfiguracja przesyłania e-maili do supportu niezwłocznie po wystąpieniu zdarzeń tego wymagających, przygotowanie danych do przesłania do wsparcia celem ich analizy oraz usuwanie datacenter z federecji

• Informacje o stanie maszyn wirtualnych w kontekście datastore, na którym się znajdują oraz wydajność wszystkich datastore’ów w całej federacji (transfer, operacje I/O, opóźnienie)

Na poziomie pojedynczego hosta ESXi

Dostępne są tu informacje o sprzęcie oraz zdjęcie przodu i tyłu serwera. Zaskakujące jest, że zdjęcie tyłu serwera zawiera opcjonalne 1GbE interfejsy (zaznaczone czerwoną ramką), których fizycznie nie ma zainstalowanych.

Na poziomie maszyny wirtualnej

Pojawiają się opcje backupu w kontekście danej VMki oraz jej klonowanie i przenoszenie. Klonowanie i przenoszenie wykorzystują w pełni i moc rozwiązania. Jeśli to możliwe, z nich należy korzystać zamiast ze standardowych funkcjonalności VMware.

Przedstawiane informacje są proste i przejrzyste, bardzo łatwo się w nich odnaleźć.

Tortury Federacji

Zanim zaczniemy testy wydajnościowe rozwiązania, przyjrzymy się jego niezawodności i odporności na najróżniejsze awarie. Skonfigurowana została funkcja Phone Home – odpowiedzialna za wysyłanie na bieżąco do wsparcia informacji o pojawiających się problemach. Co ciekawe test po skonfigurowaniu przebiega pomyślnie – nawet gdy zdefiniowany serwer SMTP jest niedostępny.

Oczywiście są to testy z rodzaju hardcorowych i nie radzimy tego robić w domu, a tym bardziej na produkcji, gdzie zawsze wypada kontaktować się z supportem.

Awaria jednego z tylnych dysków

Po wyjęciu jednego z tylnych dysków, pojawia się informacja na wyświetlaczach serwera o problemie z dyskiem. Niestety z poziomu konsoli vSphere nie ma żadnych informacji, żadnego alarmu. Jedyna informacja jaką odnajdujemy jest w event logu:

Po włożeniu dysku pojawia się kolejny lakoniczny komunikat. Chcąc uzyskać więcej informacji, musimy zalogować się do iDRAC’a.

Po zebraniu dostępnych tam informacji, zmierzony czas odbudowy RAID wyniósł 30 minut.

Awaria jednego z przednich dysków obrotowych.

W ramach kolejnego testu wyjmujemy jeden dysk obrotowy z przodu serwera, na dyskach tych przechowywane są dane maszyn wirtualnych, będących w Federacji. Znowu brak jest alarmów, które mogłyby zwrócić uwagę administratora Jeśli jednak zajrzymy do informacji o stanie OmniCube, znajdziemy tam stosowny komunikat pokazany na rysunku 12 i 13.

W kolejnym kroku wkładamy dysk do serwera, RIAD utworzony z dysków zaczyna się odbudowywać i wreszcie pojawiają się alarmy, których nie sposób nie zauważyć:

Całkowity czas odbudowy RAID wyniósł poniżej sześciu godzin.

Awaria czterech przednich dysków obrotowych.

System jest odporny na awarie dowolnych dwóch dysków obrotowych przeznaczonych do przechowywania danych maszyn wirtualnych, jednak może znieść awarię nawet czterech – odpowiednio wybranych.

W przypadku takiej awarii, system jest na krawędzi katastrofy – awaria kolejnego dysku naturalnie doprowadzi do utraty danych w węźle dotkniętym problemami.

Raportowanie problemów przez system działa dokładnie taks samo jak w przypadku awarii pojedynczego dysku (brak alarmów przy wyjętych dyskach, alarmy w trakcie odbudowy).

Ponowna instalacja dysków rozpoczyna proces odbudowy obu RAIDów, pojawiają się także alarmy krytyczne.

Warto zwrócić uwagę, że dyski są w RAID 6, a odbudowa odbywa się po jednym dysku. Gdy pierwszy z dysków zakończy odbudowę, zaczyna się odbudowa drugiego – wydłuża to całkowity czas odbudowy RAID, który wyniósł 9 godzin, ciekawe jest jednak, że czas ten nie wyniósł dwukrotności czasu odbudowy jednego dysku.

Awaria łączności 10GbE oraz jednego z węzłów.

W ramach przygotowania do kolejnej awarii, jedną z maszyn wirtualnych (Windows 8-clone-4) migrujemy na węzeł drugi. Rozłączamy oba połączenia 10GbE, symulując całkowitą awarię sieci federacyjnej i danych. Wszystkie maszyny pozostają włączone i pracują prawidłowo. Należy tutaj pamiętać, że wspólne zasoby dyskowe dostarczane przez federację zostały rozdzielone, a każdy z hostów ESXi widzi ich niezależną kopię. W tym stanie migracja maszyn wirtualnych pomiędzy węzłami miałaby katastrofalne skutki (docelowy host jest „przekonany” o dostępności wspólnego zasobu NFS), jednak nie ma na to szans, gdyż z utratą sieci, hosty tracą możliwość migracji (sieć vMotion jest z nią powiązana – więcej szczegółów w poprzedniej części artykułu). Uruchomienie maszyn wirtualnych bezpośrednio z hosta jest blokowane przez vCenter, które ma łączność z obydwoma hostami (jakże krytyczna w tym momencie jest niezależność vCenter od środowiska Federacji). Pomimo rozdzielenia zasobów oferowanych przez federację, z pierwszego nie jesteśmy w stanie skasować plików maszyny Windows 8-clone-4, działającej na drugim hoście. Udaje się skasować mniej istotne pliki logów. Po ponownym odzyskaniu spójności plików udostępnianych przez federację, spodziewamy się, że skasowane pliki zostaną przywrócone z drugiego węzła. Gdyby przywrócić teraz połączenie 10GbE, wszystko powinno wrócić do normy, nie chcemy jednak tego robić, zasymulujemy awarię drugiego węzła, na którym działa jedna maszyna wirtualna. W tym celu restartujemy maszynę OVC. Host traci dostęp do plików maszyny wirtualnej i zmienia się jej nazwa na liście maszyn (rys. 19). Co gorsze, tracimy informacje specyficzne dla SimpliVity o wszystkich maszynach – w szczególności o Storage HA (czy kopie maszyn są aktualne na obu węzłach).

Aby rozwiązać problem, restartujemy całego hosta ESXi, co rozwiązuje problem dostępności maszyny oraz informacji o stanie wszystkich maszyn.

Awaria dysków SSD.

Jak wiemy, rozwiązanie wykorzystuje dyski SSD tylko do przyśpieszania odczytów danych, sprawdzimy zatem, jak zachowa się w przypadku ich awarii. Po usunięciu jednego dysku, objawy są dokładnie takie same jak w przypadku dysków tylnych, a właściwie jeszcze gorzej, gdyż rozwiązanie podaje stan tych dysków jak prawidłowy:

Być może dyski SSD nie są w ogóle istotne dla prawidłowej pracy i dlatego nie jest raportowany ich stan. Wyjmijmy zatem wszystkie. Okazuje się, że nic się nie zmienia, maszyny wirtualne działają, a raportowany stan dysków nadal się nie zmienia. Wkładamy zatem dyski ponownie – nadal nic. Otym, że w ogóle coś się stało możemy sprawdzić poprzez iDRAC.

Stan Foreign sugeruje, że dyski nie są dostępne dla systemu operacyjnego. W ramach dalszych testów, restartujemy całego OmniCube’e (któremu wyjmowaliśmy dyski SSD). Maszyny, które były uruchomione na zrestartowanym węźle, uruchamiają się na pracującym – mechanizmy wysokiej dostępności sprawują się bardzo dobrze…

Tragiczny w skutkach Łańcuch zdarzeń….

Zrestartowany host uruchamia się, ale nie uruchamiają się zabezpieczenia maszyn wirtualnych – brak Storage HA. Po uruchomieniu konsoli maszyny OVC, widać komunikat o problemach z dostępem do danych (brakuje dysków SSD, więc nie powinno to dziwić). Ponownie restartujemy serwer, a po pojawieniu się informacji o wykryciu obcej konfiguracji dysków (dyskow SSD), wybieramy zaimportowanie jej. Po tych działaniach OVC uruchamia się prawidłowo, niestety nie uruchamia się Storage HA.

Wygląda na to, że OVC ucierpiała w wyniku zabawy z dyskami SSD i nie działa prawidłowo W tym momencie należałoby skorzystać ze wsparcia producenta, gdyby to było środowisko produkcyjne, warto by było przenieść wszystkie maszyny wirtualne na inny storage (jeśli takim dysponujemy) – obecny jest pozbawiony niezawodności, działamy jednak w środowisku laboratoryjnym i nie zrobimy tego.

Kolejne kroki, które zostały podjęte to:

• Usunięcie OVC
• Próba ponownego zainstalowania maszyny z przygotowanego wcześniej szablonu (nie udana, rozwiązanie „pamięta”, że takie OVC już jest w federacji
• Uruchomienie nowego OVC z innymi parametrami

Niestety nowy OVC także nie zaczyna się synchronizować i nadal nie możemy uzyskać wysokiej dostępności dla danych, podejmujemy kolejne kroki

• Usuwamy nowe OVC z federacji
• Usuwamy uszkodzone OVC z federacji (wymagana zaawansowana znajomość linii poleceń rozwiązania, bez pomocy ze strony SimpliVity nie do wykonania)
• Instalujemy drugie OVC jak w przypadku nowego systemu dodawanego do Federacji

Niestety nadal nie uruchamia się Storage HA. Sytuacja wygląda jak na rysunku 22.

Po raz kolejny prosimy przedstawicieli SimpliVity o pomoc, licząc na zorganizowanie wsparcia technicznego, przy okazji testując szybkość reakcji serwisu, która okazała się na całkiem wysokim poziomie.

Natomiast przypominamy, że przy tak hardcorowym teście nie warto działać na własną rękę… Bo jak w każdym rozwiązaniu dzięki swojej niewiedzy można niechcący narazić się na utratę danych.

Podsumowanie

Rozwiązanie Simplivity ma spory potencjał i czekamy z utęsknieniem na poprawki wykrytych błędów… Oczywiście pewne można wykonać samemu, jak np. w iDRAC można skonfigurować alarmy w przypadku wykrycia problemów z dyskami – trzeba to jednak zrobić na własną rękę – dokumentacje nic o tym nie wspomina. Czekamy na kolejne testy na nowym sofcie, rzekomo dużo się poprawiło… ale o tym już w nowym roku 🙂