Maxta #3

Marek Sokół
11. września 2018
Reading time: 2 min
Maxta #3

Po przypomnieniu zasad panujących w rozwiązaniach hiperkonwergentnych oraz przybliżeniu rozwiązania firmy Maxta, w aktualnym artykule opiszemy nasze wrażenia z testów samego rozwiązania. W testach skupimy się na aspektach ergonomii oraz niezawodności.

W poprzedniej części wykonaliśmy szczegółową analizę rozwiązania, bazując na dokumentacji oraz innych materiałach producenta. To pozwoliło nam przybliżyć architekturę sprzętową, jak i programową. Pomimo że Maxta deklaruje dostępność swojego rozwiązanie także na platformę RadHat, w analizie skupiliśmy się jednak na platformie VMware. Nie inaczej będzie również w tej części. Do testów otrzymaliśmy trzy węzłowy klaster VMware bazujący na trzech serwerach SuperMicro SYS-1028, wyposażonych w:

  • dwa procesory Intel Xenon E5-2695 16 rdzeni każdy,
  • 256 GB pamięci RAM,
  • karta sieciowa 10 GbE na potrzeby ruchu storage,
  • karta sieciowa 1 GbE dla pozostałego ruchu,
  • 6 dysków HDD 900GB na potrzeby przechowywania danych,
  • 2 dyski SSD NVMe 800GB.

W środowisku, poza klastrem występuje również serwer DNS, NTP oraz vCenter, pracujemy z vSphere w wersji 6.5. W celu uruchomienia procesu instalacji klastra Maxta potrzebujemy maszyny z windows, na której uruchamiamy instalator. Maszyna musi mieć dostęp do serwera vCenter oraz serwerów ESXi. Sam kreator pomimo swojej prostoty nie ma możliwości importu lub eksportu wprowadzonych danych. Zatem gdyby przyszło ponowić instalację na tym samym (takim samym) środowisku, wszystkie dane będziemy musieli wpisać ponownie, samych danych nie jest jednak zbyt dużo. W pierwszym kroku akceptujemy postanowienia licencyjne, zapoznajemy się ze skróconymi wymaganiami do instalacji klastra, by w kolejnym kroku podać dane dostępowe do administracyjnego użytkownika vCenter. Instalator wymaga podania Datacenter oraz klastra, w którym rozwiązanie ma być zainstalowane. W przypadku małych środowisk wybór będzie polegał jedynie na zatwierdzenie pojedynczych elementów na liście. Kolejny krok przedstawiony jest na rysunku 1, w którym podajemy już więcej danych. Większości z nich nie będzie można zmienić po uruchomieniu klastra.

 class=

Rysunek 1 Jeden z ważniejszych ekranów kreatora instalacji Maxta, na którym definiujemy adresy komponentów. Warto zwrócić uwagę, że kontrolery wirtualne w sieci management wykorzystują tylko jeden adres IP. Węzeł, który jest tzw. masterem, nasłuchuje na tym adresie, z innymi węzłami nie można nawiązać łączności w tym segmencie sieci. Każdemu z kontrolerów przydzielany jest  automatycznie adresy IP z zakresu storage. Oprócz konfiguracji adresów IP decydujemy czy będziemy korzystać z funkcji Rack Awareness, wersji All-Flash czy hybrydowej, duplikacji dysków SSD przeznaczonych na bufor czy domyślny rozmiar strony dla przechowywanych danych.

Dalsze kroki wymagają wskazania lokalnych dysków w serwerach ESXi, które będą wykorzystane do budowy współdzielonego zasobu dyskowego. W przypadku wyboru wersji All-Flash musimy wskazać, które dyski SSH będą pracować w warstwie buforującej, a które w warstwie przechowywania danych. Następny krok to podanie interfejsów/vSwitchy dla sieci zarządzającej oraz izolowanej (storage), przeznaczonej dla ruchu pomiędzy kontrolerami Maxta oraz do udostępniania rozproszonego zasobu dyskowego dla hostów ESXi. Jeden z ostatnich kroków wymaga podania danych dostępowych do hostów ESXi. Po walidacji i wyświetleniu podsumowania, można uruchomić proces instalacji, podczas którego zostaną zainstalowane w każdym ESXi kontrolery wirtualne będące podstawą MxSP. Po kilkunastu minutach system jest zainstalowany a rozproszona, wysokodostępna przestrzeń dyskowa gotowa do pracy.

Z poziomu vCenter widzimy dodatkowe maszyny wirtualne zainstalowane na lokalnych dyskach ESXi, które mają podłączone w trybie RDM dyski wskazane w czasie instalacji. Kolejną nową rzeczą jest datestore podmontowany protokołem NFS do każdego hosta.

 class=

Rysunek 2. Szczegóły sprzętowe kontrolera wirtualnego Maxta, z widokiem sposobu dostarczania fizycznych zasobów dyskowych do maszyny wirtualnej.

Mając zainstalowane rozwiązanie, możemy zalogować się do interfejsu graficznego służącego do zarządzania MxSP. Wykorzystujemy w tym celu przeglądarkę internetową oraz adres IP zdefiniowany w procesie instalacji jako Management Server IP. Logujemy się użytkownikiem administracyjnym z vCenter, nie ma potrzeby (ani możliwości) zakładania niezależnych, dedykowanych tylko do interfejsu użytkowników. Widok głównego panelu pokazany jest na rysunku 3.

 class=

Rysunek 3 Główny ekran interfejsu zarządzającego MxSP – MxInsight, zawiera podsumowanie wszystkich najważniejszych parametrów współdzielonej przestrzeni dyskowej, które pozwolą szybko rozeznać się w stanie środowiska i przejść do kolejnych widoków w poszukiwanie bardziej szczegółowych informacji. W środowisku testowym nie zastosowano nadmiarowości sieci w wyniki czego widać stosowne ostrzeżenie na panelu.

W kolejnym wpisie skupimy się na pracy z interfejsem oraz danymi. Poniżej znajdą Państwo linki do wcześniejszych artykułów: