Nutanix – bliższe spojrzenie po latach

Rozpoczynając cykl “Nutanix – 6 lat później” przyglądnąłem się pozycji na rynku oraz zmianom, które (wciąż) zachodzą w samym rozwiązaniu. Tym razem biorę pod lupę bazę rozwiązań oferowanych przez naszego bohatera cyklu.

Pojedynczym komponentem Nutanix jest serwer fizyczny z wirtualizatorem. Natomiast zacznijmy od tego, że za najbardziej rozpoznawalnego dostawcę rozwiązań do wirtualizacji, uznawana jest marka VMware ze swoim serwerem do hostowania maszyn wirtualnych ESXi. Poza tym, oprócz produktów innych dostawców, jak Hyper-V czy XenServer, także Nutanix wprowadził swój serwer do obsługi wirtualizacji – AHV (Acropolis Hypervisor).

W procesie wirtualizacji zasoby procesora czy pamięci RAM, są nietrwałe i wykorzystuje się je w ramach doraźnych potrzeb, ale nic nie jest w nich utrwalane. Dlatego w przypadku awarii fizycznego serwera bardzo łatwo uruchomić maszynę wirtualną na innym serwerze.

To co stanowi maszynę wirtualną (szczególnie gdy jest wyłączona), są jej dane – ich utrata lub uszkodzenie, mają wpływ na jej dostępność i pracę.

Przechowywanie tych danych w jednej kopii na lokalnych dyskach serwera zawsze było obarczone ryzykiem. Aby te ryzyka minimalizować pojawiły się możliwości łączenia dysków w grupy (RAID). Oczywiście to nie rozwiązuje wszystkich potencjalnych problemów, stąd w tym obszarze bardzo rozwinął się rynek pamięci masowych. To znowu doprowadziło do specjalizacji administratorów, pojawienia się dedykowanych zespołów i w konsekwencji – spowolnienia procesów.

Dyski wracają do serwerów

W dobie rosnących potrzeb biznesu, ciągłych oczekiwań dostarczania nowych rozwiązań w krótkim czasie, historia zatoczyła koło i dyski wróciły do serwerów.

Tym razem dyski tworzą grupy, nie w ramach serwera, ale w ramach grupy serwerów, dzięki czemu nawet awaria jednego fizycznego serwera nie powoduje utraty dostępu do danych. Nowe podejście było możliwe dzięki nieustannemu wzrostowi prędkości urządzeń sieciowych. W efekcie, mając standardowe serwery, podłączone tylko do sieci Ethernet, można budować wysoce dostępne rozwiązanie, dużo łatwiejsze w utrzymaniu dla zespołu operacyjnego.

Taka architektura jest łatwiejsza w skalowaniu, a logika zaszyta w oprogramowaniu łatwa do aktualizacji i wprowadzania ulepszeń.

Kolejne węzły wg potrzeb

Elastyczność rozwiązania Nutanix pozwala dodawać kolejne węzły wg potrzeb, nie ma wymogu, aby wszystkie węzły miały taką samą konfigurację. W przypadku zwiększonego zapotrzebowania na pojemność przy braku potrzeb na procesor czy RAM, możliwe jest dokładanie węzłów typu Storage heavy (bardzo zwiększona pojemność dyskowa węzła) lub Storage Only (zwiększona pojemność dyskowa), a CPU i RAM na poziomie minimalnym z założeniem, że nie będą na nim uruchamiane żadne maszyny wirtualne. Możliwe jest mieszanie w ramach klastra węzłów dyskami SSD w warstwie pojemności (all-flash) z węzłami zaopatrzonymi w dyski HDD (hybrydowymi).

Zwykle takie kompozycje nie są dozwolone. Nutanix po raz kolejny pokazuje swoją elastyczność.

Inna ciekawa konfiguracja, to użycie węzłów typu Storage Only, bazujących na AVH, udostępniających zasoby węzłom pracującym z innym systemem operacyjnym np. ESXi. Przykład ciekawy, a jednocześnie zaczyna przypominać klasyczne rozwiązania trójwarstwowe, w których dane do klastra VMware (lub innej firmy) są dostarczane z macierzy poprzez NFS lub iSCSI. Widać tu ogromną elastyczność, a praktyczne jego zastosowanie prawdopodobnie przyda się na czas migracji lub dotrwanie do końca cyklu życia starych serwerów, aby chronić już poniesione inwestycje.

Technicznie jest jednak możliwe, aby kupić rozwiązanie Nutanixa i używać go tylko do roli rozproszonej macierzy, być może byłoby to uzasadnione kosztowo, lecz ujawniłaby się tu strata wynikająca np. z braku wykorzystania algorytmów lokalności danych, czy ujednoliconego zarządzania maszynami wirtualnymi i danymi.

Elastyczność kontenerów

Innym przykładem elastyczności jakie daje zastosowana architektura, jest możliwość decydowania o poziomie zabezpieczenia danych poprzez definiowanie ilości kopii każdej porcji danych. Odbywa się to bardzo kosztem pojemności, ale ma zastosowanie dla krytycznych procesów. Dobrym przykładem dla rezygnacji z dodatkowych kopii danych mogą być kontenery, będące częścią aplikacji, nie przechowujące lokalnie trwałych danych. Utrata jednego kontenera nie będzie problemem, gdyż odporność na taką utratę często jest wpisana w system do zarządzania konteneryzacją.

W scenariuszu, gdy wydajność jest odrobinę mniej ważna, można zastosować zapis typu RAID5 lub RAID6 (Erasure Coding). Pozwala to w dalszym ciągu zachować odporność na jedną czy dwie awarie dowolnego komponentu, a do tego pozwala bardzo oszczędne gospodarowanie dostępną przestrzenią na dane.

Snapshoty maszyn wirtualnych są kolejnym przykładem, gdzie architektura przechowywania danych przynosi spory zysk.

Bonusy pojawiają się, gdy zaczynamy korzystać z wewnętrznego mechanizmu migawek oferowanego przez Nutanix w porównaniu do standardowych mechanizmów, w których korzysta tylko wirtualizator. Pozwala to przekierowywać zapisy nowych bloków danych. W wyniku takiej operacji, możemy łatwo sięgnąć do całego obrazu dysku przed migawką lub stanu aktualnego. Jedynie system musi tylko użyć odpowiedniej tablicy wskazań do danych. Wprowadzone grupy konsystencji pozwalają zgrywać w czasie wiele maszyn wirtualnych, co może być istotne dla serwerów wchodzących w skład jednej aplikacji.

Podstawowa idea, założenia i pomysł Nutanixa na hiperkonwergentne rozwiązanie są niezmienne, co potwierdza, że powstał na bardzo dobrze przemyślanym i odpornym na ząb czasu założeniu. Z biegiem lat pojawiają się optymalizacje i nowe funkcje, które wprowadzają kolejne usprawnienia tak oczekiwane przez użytkowników.

W kolejnym artykule przyjrzymy się jak praca Nutanix z AVH wygląda w praktyce.

  Partner artykułu: S4E & Nutanix