Maxta #2
Po zapoznaniu się z architekturą rozwiązania przyjrzyjmy się funkcjonalnościom, jakie mamy do dyspozycji w kontekście maszyn wirtualnych oferowane z poziomu MxInsight.
- Dla poszczególnych maszyn wirtualnych: definicji liczby replik danych (dwie lub trzy), priorytet odbudowy wymaganej nadmiarowości danych, wykorzystanie „rack awareness” przy rozmieszczaniu danych maszyny (jeśli funkcja jest włączona na poziomie klastra), wielkość wykorzystywanego bloku danych oraz rodzaj kompresji dla dysków wirtualnych, możliwość rezygnacji z wykorzystania bufora odczytów znajdującego się na dysku SSD dla wersji hybrydowej,
- Snapshoty, dzięki pełnej kontroli nad warstwą przechowywania danych, Maxta udostępnia funkcjonalność snapshotów bazujących na „redirect-on-write” (przekierowanie przy zapisie), dzięki czemu czas wykonania snapshotu, jest bliski zeru, a sam snapshot w chwili jego wykonania nie zajmuje miejsca. Dodatkowo można wykonać snapshot spójny aplikacyjne, wówczas maszyna wirtualne jest dodatkowo wyciszana za pomocą VSS,
- Snapshot Policy, harmonogram wykonywania snapshotów umożliwiający automatyczne zabezpieczenie stanu maszyny wirtualnej, wg zdefiniowanego planu. Możliwe jest także określenie czasu, po jakim snapshot zostanie automatycznie skasowany. Dla MxSP nie ma limitu wykonanych snapshotów, a dodawanie kolejnych nie zmniejsza wydajności pracy rozwiązania, zatem określenie takiego harmonogramu może być traktowane jako dodatkowe krótkoterminowe zabezpieczenie maszyn wirtualnych na wypadek nie przewidzianych problemów,
- Klonowanie maszyn wirtualnych, funkcjonalność ta jest niejako rozwinięciem opisanych już snapshotów zawierających dodatkowy krok, w którym snapshot jest rozdzielany na dwie linie – pierwsza oryginalna maszyna, druga jej klon. Takie zastosowanie pozwala na błyskawiczne klonowanie nawet bardzo dużych maszyn,
- VAAI, powyżej opisane snapshoty i klonowanie dostępne jest z interfejsu MxInsight, po zainstalowaniu VAAI powyższe funkcjonalności mogą być wykorzystanie w tle pomimo ich wywołania ze standardowego interfejsu vSphere. W sytuacji instalacji VAAI oraz braku snapshotów wykonanych z poziomu VMware, wywołanie takowego z poziomu interfejsu vSphere ostatecznie zakończy się wykonaniem stapshotu Maxta. W sytuacji występowania snapshotów VMware lub klonowanie na zasób dyskowy poza MxSP zostanie wykorzystany mechanizm VMware. Pojawia się tu zatem wymóg dla administratora VMware zrozumienie tego procesu, gdyż wykonujące teoretycznie tę samą czynność ostatecznie otrzymujemy inny efekt,
- Kompresja jest domyślnie włączona przy instalacji klastra, w wyniku czego przechowywane dane mają szansę zajmować mniej miejsca. Dla indywidualnych maszyn można zmienić przypisane ustawienia, dostosowując je do środowiska,
- Thin provisioning – domyślnie włączona jest funkcjonalność oszczędzania miejsca poprzez zakładanie wszystkich dysków jako tak zwane cienkie,
- Rack awareness – w przypadku większych organizacji chcących chronić się przed utratą całej szafy rack, czy serwerowni, dostępna jest funkcja replikacji danych uwzględniająca fizyczne położenie węzłów z klastra. Dzięki temu możemy uniknąć sytuacji, gdzie wszystkie kopie danych maszyny wirtualnej znajdują się „blisko” siebie i stają się niedostępne z powodu rozleglejszej awarii.
Rysunek 3. Dla uruchomienia rack awareness potrzebujemy trzeciego miejsca instalacji, w którym znajduje się świadek, wymagany do rozstrzyganiu w scenariuszach utraty łącz danych pomiędzy lokalizacjami. Nawet dla większych odległości wymagane jest zapewnienie odpowiedniego pasma pomiędzy lokalizacjami oraz niskiego opóźnienia – wymaganie te podyktowane są synchronicznymi zapisami kopii danych w drugiej lokalizacji. Wystąpienie wąskich gardeł w tym obszarze będzie miało wpływ na spadek wydajności całego rozwiązania.
Podsumowanie
Przedstawione rozwiązanie firmy Maxta jest godne uwagi, wpisuje się w pewną niszę rynkową, gdzie skupia się na dostarczeniu tylko oprogramowania. Dzięki przyjętej architekturze wydaje się nie mieć zależności sprzętowych innych niż te, jakim podlega hyperwizor, na którym rozwiązanie działa. Administratorzy platformy serwerowej przy aktualizacjach wszelkich komponentów wydaję się, że nie muszą zwracać szczególnej uwagi na wymagania Maxta, gdyż tu wystarcza kompatybilność VMware względem sprzętu. Maxta deklaruje dostępność swojego rozwiązania także na platformie RedHat, co oprócz uniezależnienia od platformy sprzętowej wprowadzą pewną elastyczność w wyborze platformy softwareowej, w której Maxta funkcjonuje. Pomimo bycia noszowym graczem na rynku hiperkonwergencji, ma ambicje stawić czoła bardziej rozpoznawalnym markom. Aktualne podejście może bardzo dobrze się sprawować wobec klientów, którzy nie chcą wymieniać platformy serwerowej z powodu wdrażania rozwiązań hiperkonwergentnych, a wymiana taka stanowi spory próg wejścia – w nowych serwerach zgodnych z wymaganiami innych producentów znajdują się komponenty stosunkowo drogie, włączając interfejsy 10 GbE, które to pociągają za sobą koszty odpowiednich switchy. Oddanie większej elastyczności klientowi w kwestii budowy platformy sprzętowej jednocześnie zmniejsza zakres gwarantowanej wydajności dostarczonego rozwiązania. Jest to jednak coś, co klientom otwartym na nowe rozwiązania z pewnością pasuje, gdyż mając tego świadomość, mogą budować samodzielnie nowoczesne elastyczne rozwiązanie. Mając pełen wachlarz możliwości w kwestii rozbudowy pojemności czy wydajności – wymiany czy dokładanie dysków, wymiany i rozbudowy węzłów – co w przypadku innych dostawców mogłoby być niemożliwe do realizacji z powodu ścisłych zależności sprzętowych i ograniczeń wynikających z innych mniej zrozumiałych czynników.
Takie podejście nie wszystkim odpowiada, niektóre firmy będą oczekiwały gwarancji wydajności, wówczas Maxta poprzez partnerów może zarekomendować właściwą platformę sprzętową ze wszystkimi komponentami. Nawet w takim scenariuszu mamy w późniejszym czasie dowolność w kwestii ingerencji w hardware i aktualizacje hiperwizora. Pomimo wszystkich zalet rozwiązanie Maxta ma obszar do usprawnień, np. brak pełnej integracji w webową konsolą vSphere, a zarządzanie środowiskiem wymaga użycia dedykowanej konsoli MxInsight, brak też do niej granularnej kontroli dostępu. Wydaje się, że integracja z VMware wymaga udostępnienie dla Maxta użytkownika z najmocniejszymi uprawnieniami, a w konsoli MxInsight także brak możliwości ich ograniczenia. W sytuacji gdy, z konsoli Maxta możemy wykonywać operacje na maszynach wirtualnych (tworzenie, kasowanie), realny wydaje być zapotrzebowanie na udostępnienie konsoli w ograniczonym zakresie. Brak kontroli uprawnień plus brak dostępu do informacji o ilości miejsca zakleszczonego w snapshotach może być czymś, co niektórym firmom nie pozwoli rozwiązania wdrożyć produkcyjnie. Na takich aspektach skupimy się jednak w części opisującej testy samego rozwiązania. Tymczasem analizując możliwości wdrożenia rozwiązań hiperkonwergentnych, można dopisać Maxta do listy analizowanych czy testowanych rozwiązań.
Poniżej znajdą Państwo linki do wcześniejszego artykułu: