Maxta #4
W tej części zajmiemy się tematem pracy z interfejsem oraz danymi, jak również wymianą fizycznych komponentów.
Mając gotowe do pracy rozwiązanie przyjrzyjmy się możliwościom interfejsu. W najwyższej jego części widoczny jest pasek nawigacyjny prezentujący nazwę klastra, a po jego kliknięciu szczegóły takie jak adres vCenter czy wersję MxSP. Wyświetlana jest liczba alarmów, która po kliknięciu przenosi nas na stronę szczegółowo przedstawiającą alarmy w środowisku. Na końcu wyświetlana jest nazwa użytkownika vCenter za pomocą, którego jesteśmy zalogowani. Poniżej dostępny jest pasek menu, a w nim główne opcje:
- Dashborad – główny ekran przedstawiony na rysunku 3;
- Monitoring – w ramach, którego mamy dostęp do statystyk i wykresów dotyczących danych w klastrze, jak i samego klastra, schodząc nawet na poziom poszczególnych dysków. Kolejne dostępne informacje to alarmy, zlecone zadania i zdarzenia oraz informacje o resynchronizacjach maszyn wirtualnych. Resynchronizacja jest procesem balansowania rozmieszczenia danych w klastrze lub przywracaniem wymaganej nadmiarowości danych maszyny wirtualnej w przypadku jej utraty np. w wyniku awarii jakiegoś komponentu;
- Configuration – uzyskujemy dostęp do zarządzania maszynami wirtualnymi, zaczynając od ich tworzenia i modyfikowania czy definiowania polityk migawek, na ręcznym wykonywaniu migawek kończąc;
- Administration – daje dostęp do parametrów klastra, licencji czy logów możliwych do zebrania ze środowiska i przekazania do działu wsparcia, gdyby takie okazało się potrzebne.
MxSP „koncentruje” się na maszynach wirtualnych, zatem nie dziwi fakt, że pewnie ustawienie są wykonywane w ich kontekście. Warto pamiętać, że w przypadku tworzenia maszyny wirtualnej z interfejsu vCenter, pewne parametry maszyny przybiorą domyślne wartości klastra MxSP, aby już w trakcie tworzenie maszyny zdefiniować wartości jak liczba replik, rodzaj kompresji dysków maszyny czy wielkość bloku danych, należy taką maszynę utworzyć z interfejsu Maxta. Zdefiniowanie polityki migawek i wykonanie migawek czy klonów maszyn, także zrobimy tylko z tego interfejsu. Wyjątkiem jest system z zainstalowaną wtyczką VAAI, lecz jak już pisaliśmy w poprzedniej części niesie to za sobą pewne ryzyko utraty kontroli nad tym co się dzieje w środowisku. Jest to szczególnie istotnie w przypadku klonowanie maszyny wirtualnej. Maszyny klonowane w ramach możliwości Maxta, współdzielą dane bazowe, a zmiany w każdej z nich są utrwalane w ramach mechanizmu „redirect-on-write”. Dla takich maszyn nie mamy kontroli nad ich rozmiarem w klastrze, ani nie możemy dla nich edytować polityki dysku (ilość kopii danych, czy rodzaj kompresji). Dla migawek (snapshotów) największą bolączką jest brak informacji i ilości danych w nich zakleszczonych. W scenariuszu, w którym generujemy w maszynie 1 TB danych, robimy z niej klona, następnie w obu klonach kasujemy ów 1 TB danych i generujemy nowe dane takiej wielkości, zakleszczamy pierwotny 1 TB i nie mamy żadnego sposobu tego sprawdzić. W sytuacji posiadania wielu maszyn oraz zdefiniowania polityk migawek dla każdej z nich, szybko może się okazać że nie wiadomo którędy „wycieka” nam wolne miejsce. Dostępność tylko kilku parametrów konfiguracji mogło by powodować ciągłą potrzebę przełączanie się pomiędzy interfejsami, być może właśnie dlatego w MxInsight możemy tworzyć, kasować, włączać i wyłączać maszyny wirtualne czy dodawać do nich dyski, nie pomijając otwarcia konsoli. Sama rekonfiguracja polityk dla dysków jest możliwa dla wyłączonej maszyny, lecz same dane są reorganizowane dopiero po jej włączeniu.
W obszarze monitorowania środowiska bardzo przydatny może się okazać wykres obciążenia współdzielonego datastore w zakresie ilości operacji IO, opóźnień i ilości przetwarzanych danych przy odczycie i zapisie. W sytuacji, gdy chcemy analizować głębiej, możemy obserwować wspomniane parametry dla pojedynczego węzła, a nawet dysku. Niestety nie ma odróżnienia danych generowanych przez maszyny wirtualne, od danych generowanych przez wewnętrzne mechanizmy rozwiązania (np. resynchronizacje). Interfejs napisany jest w HTML5 dzięki czemu monitorując dane na bieżąco, odświeżają się one automatycznie, nie wymagając żądnej akcji ze strony administratora. Animacja odświeżania danych jest bardzo ładna i dynamiczna. Niestety odświeżanie, a co za tym idzie odrysowywanie danych następuje nawet, gdy wybieramy dane historyczne (które się nie zmieniają), po kilku takich operacjach można odczuć zirytowanie. Granularność próbkowania i wyświetlania danych wynosi dwie minuty, nawet w widoku „ostatnie pół godziny”, co jak łatwo policzyć na całym wykresie daje nam tylko 15 punktów danych. Analiza bieżącej sytuacji, mogąca wymagać szybkich reakcji, w środowisku gdy dane odświeżanie są co dwie minuty jest trudna.
Rysunek 4 Bardzo ładne i wygodne do analizy wykresy oferowane przez interfejs MxInsight, pozwalają wiele dowiedzieć się o środowisku, na poziomie całego klastra, pojedynczego węzła czy nawet dysku.
Kolejną rzeczą wymagającą przyzwyczajenie się jest nazewnictwo i kolejność wyświetlania wirtualnych kontrolerów. Otóż hosty ESXi w środowisku nazywały się esxi01, esxi02, esxi03 i w takiej kolejności są wyświetlane w vCenter, nie znamy przyczyna dla której kontrolery wirtualne ponumerowane zostały z wykorzystaniem cyfr 1, 4, oraz 7, co więcej na esxi01 wylądował kontroler z numerem 7. W samym interfejsie Maxta wspomnienie hosty ESXi również nie są sortowane alfabetycznie, z jakiegoś powodu zawsze jako pierwszy wyświetlany jest ten z numerem 3, potem 1, a na końcu listy jest nr 2.
Wymiana fizycznych komponentów
W przypadku awarii dysków lub całych węzłów, Maxta w swojej dokumentacji dostarcza szczegółowych informacji jak należy wykonać taki proces. Sama wymiana nie zamyka się tylko w scenariuszach awarii, szczegółowe procedury są przygotowane w sytuacji potrzeby dodania nowych dysków do serwerów lub ich wymiany na egzemplarze o większej pojemności. W skrócie procedura wymiany uszkodzonego dysku wygląda następująco:
- Po wykryciu awarii dysku, następuje procedura odtworzenia wymaganej nadmiarowości danych, które znajdowały się na uszkodzonym dysku,
- Po zakończeniu procedury sygnalizowanej w interfejsie można włożyć do serwera nowy dysk na miejsce uszkodzonego,
- W MxInsight należy odnaleźć węzeł z problemami i wybrać opcję Add Disk, co zainicjuje odpowiednie zmiany w ramach mapowania RDM,
- Zalogować się do kontrolera wirtualnego poprzez SSH lub konsolę i wydać zestaw czterech poleceń, w wyniku których nowe dyski dołączą do współdzielonej przestrzeni dyskowej.
W sytuacji awarii całego węzła, usuwamy go z klastra odpowiednim poleceniem wydanym poprzez SSH na kontrolerze, by kolejne kroki wykonać już z interfejsu graficznego, gdzie uruchomimy kreator dodawania nowego węzła do klastra. Nowy węzeł oczywiście musi mieć zainstalowany i wstępnie skonfigurowany system operacyjny.
W kolejnym wpisie skupimy się na pracy z klastrem. Poniżej znajdą Państwo linki do wcześniejszych artykułów: