Nutanix – Idea i architektura

Zakończyliśmy serię o Simplivity to teraz czas na kolejną platformę hyperkonwergentą, w związku z czym przed wami pierwszy artykuł o Nutanix… jednak zacznijmy od początku. O wirtualizacji chyba słyszał już każdy kto ma jakikolwiek związek z serwerami, lecz o problemach, które się pojawiają, podczas korzystania z tej technologii, nie każdy słyszał. Ci co słyszeli, często godzą się z problemami, które się pojawiają i działają tak samo od lat. Wyobraźmy sobie sytuację firmy, która posiada serwery, na których uruchomiona jest wirtualizacja oraz zapewniająca wysoką dostępność macierz na dane maszyn wirtualnych.

Wszystko działa świetnie, czasem wymaga jakiejś interwencji, wymiany, aczkolwiek generalnie wszyscy są zadowoleni. Do czasu gdy CEO przychodzi do CIO z pomysłem na nową usługę… Niestety nikt nie potrafi udzielić informacji ile nowych maszyn wirtualnych będziemy chcieli uruchomić, jakiej przestrzeni będą one potrzebować ani jakiej mocy obliczeniowej wymagać, że o obciążeniu podsystemów dyskowych to już nie wspomnę.Należy wówczas przyjąć jakieś szacunki i zaplanować ewentualne zakupy. Prawdziwy problem pojawia się jednak gdy obecna infrastruktura już się wysyca:

• zaczyna brakować mocy procesorów – kupujemy nowe hosty, lub wymieniamy stare
• miejsce na macierzy także się kończy, nie wspominając o wysyceniu operacjami odczytu zapisu – rozbudowujemy zatem macierz
• nowych serwerów nie mamy już gdzie podłączyć – kupujemy przełącznik sieciowy, a właściwie dwa dla utrzymania wysokiej dostępności
• nowa półka macierzy nie wystarczy, musi być zakupiony nowy kontroler, a to znowu wymaga portów w przełącznikach SAN – a tam także nie ma miejsca i znowu zakupy
• Wszystko jest na dobrej drodze, do czasu gdy przyjeżdżają serwery, nowa półka macierzy, przełączniki sieciowe oraz SAN – nie mamy miejsca w szafie/serwerowni… Nie ma problemów, których nie da się rozwiązać, więc i z tym sobie radzimy.

Gdy już wszystko jest zainstalowane w szafie i połączone możemy zacząć konfigurację. Mija kilka dni i po uruchomieniu całości możemy odetchnąć, oraz zacząć rozbudowywać system do backupu, a gdy z nim już skończymy… trzeba rozbudować infrastrukturę w centrum zapasowym. Uff… koniec.

Nareszcie, gdy już gdy wydaliśmy bardzo dużo pieniędzy i spędziliśmy wiele tygodni czekając na sprzęt, kolejnych kilka tygodni go instalując, zadowolony z siebie CIO informuje CEO, że firma jest gotowa zrealizować nowy pomysł. To wspaniale – mówi CEO – bo w między czasie pojawiły się na horyzoncie dwa nowe pomysły do zrealizowania, dokonane inwestycje są wystarczające aby je obsłużyć, prawda? Zgrozo… nie prawda!

W podanym przejaskrawionym przykładzie, pokazuję jak trudno może być IT nadążyć za potrzebami biznesu. W tym miejscu warto się zastanowić czy warto iść dalej tą drogą. Warto mieć na uwadze  jak takie problemy rozwiązały wielkie firmy internetowe np. Google czy Facebook. Instytucje te skupiły się bowiem na prostocie rozwiązania, jeden taki sam element powtarzany wielokrotnie. W tym elemencie zawarta jest w szczególności przestrzeń na usługi/maszyny wirtualne (oczywiście kopiowana do innych elementów calem zabezpieczenia przed awarią). Gdy potrzeba jest więcej zasobów obliczeniowych lub pomięci masowej dokłada się kolejne elementy. Takie podejście doczekało się komercyjnej nazwy hiperkonwergencja.

Prognozy rynkowe

Badanie przeprowadzone przez Enterprise Strategy Group, opublikowane w 2016 roku potwierdzają, że nowy trend (hiperkonwergentnych rozwiązań) będzie przybierał na sile. Firmom które nie dołączą w porę, utracą zwinność i elastyczność przez co nie będą mogły dotrzymać kroku konkurencji.

Rysunek 1 Więcej firm aktualnie stosuje klasyczne podejście do infrastruktury pamięci masowej, jednak zainteresowanie nowym podejściem jest duże.

Badanie opublikowane na portalu Wikibon podają konkretne wartości i daty – do roku 2026 wartość rynku pamięci masowych wzrośnie o 50%, a klasyczne podejście będzie wówczas niszowym (rysunek 3).  

Rysunek 2 Wśród potrzeb wymienianych dla rozwoju firm, dwie (lepsze zarządzanie wydajnością, oraz lepsze planowanie pojemności systemów) są w stanie być zaspokojone przez rozwiązanie hiperkonwergentne.

Natomiast wg Gartnera do roku 2019 architektura hiperkonwergentna będzie stanowiła jedną trzecią wszystkich systemów zintegrowanych.

Rysunek 3 Tradycyjne podejście dominuje, jednak w ciągu kolejnych dziesięciu lat, trend się odwróci – dominować będą rozwiązanie hiperkonwergenten oraz chmurowe.

Kilka słów o Nutanix

Jedną z firm, która wkroczyła na rynek hiperkonwergentnych rozwiązań jest Nutanix. Została ona założona w 2009 roku. Do roku 2011 pracowała nad swoją realizacją wizją hiperkonwergencji.

Pierwszy produkt był dedykowany dla użytkowników VMware a uruchomiony był na sprzęcie Super Micro Computer. Od tego czasu produkt bardzo intensywnie jest rozwijany i do początku 2016 roku wydanych zostało jedenaście aktualizacji. Z ważniejszych warto wspomnieć o:

• 2014 – wsparcie dla Windows serwer 2012R2 Hyper-V, wprowadzenie aktualizacji automatycznych oraz dodatkową opcję ochrony danych w klastrze (RF3), DELL jako kolejny dostawca sprzętu
• 2015 – Wprowadzenie KVM jako trzeciego obsługiwanego wirtualizatora (niedługo potem nazwanego Acropolis), wprowadzenie serii NX-9000, wsparcie dla VMware vSphere 6, Lenovo jako kolejny dostawca sprzętu
• 2016 – Zmiana nazwy z NOS (Nutanix OS) na AOS (Acropolis OS), integracja z Openstack, wprowadzenie Nutanix Guest Tools oraz wiele innych

Dzisiaj spółka jest wyceniana na 16 miliardów dolarów i jest uznawana za lidera rynku w tej dziedzinie rozwiązań.

Rysunek 4 Nutanix w kwadracie liderów wg. Gartnera w kategorii Systemów zintegrowanych. Wg tego samego raportu, systemy hiperkonwergentne uzyskają 35% udział w rynku systemów zintegrowanych.

Rysunek 5 Ostatni dostępny raport IDC pokazuje Nutanix jako lidera, z największym udziałem w rynku rozwiązań hiperkonwergentnych

Wizja Nutanixa

Propozycją Nutanixa na zaobserwowane problemy z pamięcią masową jest architektura hyperkonwergentna.

Rysunek 6 Rozwiązanie Nutanix’a eliminuje cały stos technologiczny pamięci masowych

Elementem wizji nazywanej „Web-Scale” jest uczynienie infrastruktury niewidzialną.

Założenia:

• Brak przywiązanie do producentów sprzętu, w szczególności producentów pamięci masowych
• Wszechstronność uruchamianych aplikacji
• Całość logiki rozwiązania zawarta oprogramowaniu
• Wysoka automatyzacja i bogata analiza środowiska
• Maksymalne rozproszenie

Zyski z zastosowanych założeń

• Liniowa, przewidywalna skalowalność
• Wysoka dostępność systemu
• Automatyczne przywracanie pełnego zabezpieczenia danych przy awarii pojedynczych elementów.
• Łatwość wdrażania innowacji w oprogramowaniu
• Prostota używania
• Niższe całkowite koszty posiadania (TCO)

 Realizacja wizji

Produkt jaki Nutanix oferuje może się składać nawet z czterech węzłów zamkniętych w jednej obudowie, wysokości 2U, nazywanej blokiem.

Rysunek 7 Do czterech węzłów obliczeniowych ze zintegrowaną pamięcią masową zamknięte w obudowie wysokości 2U

Każdy węzeł jest pełnoprawnym serwerem z lokalnymi dyskami. Wspólne dla wszystkich węzłów są zasilacze oraz wentylatory. Jest to wersja o największej gęstości serwerów. Istnieją także serie w których w ramach obudowy 2U jest dwa serwery lub tylko jeden – wszystko zależy od potrzeb klientów.

Rysunek 8 Budowa bloku 2U

Rysunek 9 Przykładowy schemat połączeń sieciowych dla klastra, dla przejrzystości zaznaczono podłączenia tylko dwóch węzłów

Minimalna zalecana konfiguracje wymaga użycia dwóch interfejsów 10GbE na potrzeby ruchu klastra oraz zarządzania wirtualizatorami (DSF network z rysunku 10). Istotne jest, że ten segment sieci nie może być odizolowany od innych, niezbędna jest możliwość skomunikowania się ze znajdującymi się w nim elementami klastra z zewnątrz (chociażby celem zarządzania rozwiązaniem). Minimalna konfiguracja klastra wymaga trzech nodów, pociąga to za sobą potrzebę posiadania switcha z interfejsami 10GbE. Celem zachowania wysokiej dostępności środowiska niezbędne jest posiadanie dwóch switchy 10GbE. W zależności od wymagań dla ruchu maszyn wirtualnych potrzebujemy switchy z interfejsami 1GbE lub 10GbE. Do pełnego zarządzanie środowiskiem wymaganie jest jeszcze podłączenie interfejsów IPMI – nie uwzględnione na rysunku 9.

Rysunek 10 Wszystkie węzły tworzą jedną logiczną przestrzeń dyskową, co eliminuje konieczność wykorzystanie dedykowanych serwerów SAN czy NAS

Platforma sprzętowa

Firma Nutanix dostarcza swoje rozwiązanie bazując na sprzęcie Super Micro, Dell oraz Lenovo. W przyszłości powinni się również pojawić inni producenci. W zależności od potrzeb klientów oferowanych jest pięć serii sprzętu  (w przypadku wyboru sprzętu od Nutanix)

• NX-1000 podstawowa dedykowana dla ośrodków zdalnych
• NX-3000 dedykowana platforma pod wirtualizację serwerów oraz VDI (z dedykowanymi procesorami graficznymi – GPU)
• NX-6000 dedykowana platforma pod aplikacje o zwiększonym zapotrzebowaniu na przestrzeń dyskową (w tym tzw. storage node – pozbawiony zasobów pozwalających na uruchamianie na nim maszyn wirtualnych)
• NX-8000 dedykowane platforma pod aplikacje krytyczne
• NX-9000 seria wyłącznie z dyskami SSD (jako jedyna nie może był dołączana do klastra z innymi seriami)

Przy doborze wersji warto pamiętać, że kontroler CVM potrzebuje od 4 do 8 vCPU (co zmniejsza zasoby obliczeniowe do wykorzystania przez maszyny wirtualne) oraz do 32GB RAM (przy uruchamianiu najbardziej wymagających aplikacji). Jest to jednak konsekwencja architektury hiperkonwergentnej. Inną kwestią na którą warto zwrócić uwagę jest pojedynczy dysk SSD w seriach NX-1000 oraz NX-6000. Zabieg ten wyłącza zdolność rozwiązania do automatycznej naprawy węzła w przypadku awarii tego dysku. Wydaje się to celowe osłabienie własnego rozwiązania dla zmotywowania, świadomych zwiększonego ryzyka, klientów do zakupu droższych serii (przestrzeń na dyski w obudowie nie wydaje się być problemem). Ostatnim punktem wartym uwagi przy analizie dostępnych serii jest pewien brak konsekwencji w opisie konfiguracji sprzętowej. Przy opisie wykorzystanych procesorów zawsze podawana jest sumaryczna ilość rdzeni dla obu procesorów. Natomiast przy opisie wykorzystanych dysków twardych – podawana pojemność jest dla pojedynczego dysku.

Platforma software

Nutanix swoje rozwiązanie kieruje zarówno do użytkowników VMware jaki Hyper-V. Zarządzanie środowiskiem wirtualnym odbywa się narzędziami dedykowanymi pod dane rozwiązanie. Konsola PRISM jest wykorzystywana do zarządzania klasterm Nutanix (udostępniającym wysokowydajną, wysoko dostępną przestrzeń dyskową dla maszyn wirtualnych). Wychodząc naprzeciw oczekiwaniom zmniejszania kosztów, potrzebie ujednolicenia zarządzania całym środowiskiem jak i uniezależnieniu się od dostawców najbardziej znaczących dostawców wirtualizatorów dostępne jest rozwiązanie bazującej na KVM. Ten hyperwizor dostarczany przez Nutanix jest nazwany Acropolis (AHV). Przy wyborze AVH, Nutanix świadczy wsparcie na całe rozwiązanie sprzętowo-programowe, a zarządzanie całym środowiskiem odbywa się z jednej konsoli.

Decydując się na rozwiązanie Nutanix, musimy podjąć jeszcze dwie decyzje w zakresie licencjonowania wersji PRISM, oraz funkcjonalności samego klastra

Wersje PRISM

• Starter – zarządzanie wieloma klastrami, nawet rozproszonymi geograficznie
• Pro – zawiera zaawansowaną analitykę oraz automatykę pozwalającą sprawnie kontrolować środowisko oraz z odpowiednim wyprzedzeniem planować rozbudowę klastra

Wersje Acropolis

• Starter – podstawowa funkcjonalność dla małych firm
• Pro – dla większych firm, potrzebujących wykorzystywać deduplikację, kompresję czy backup do AWS
• Ultimate – dla firm potrzebujących skorzystać z takich funkcjonalności jak: VM Flash Mode – pozwala „przypiąć” maszynę do dysków SSD, celem maksymalizacji jej wydajności, replikacja danych do kilku ośrodków czy Metro klaster

Architektura rozwiązania

Zrozumienie działania całości rozwiązania wymaga poznania architektury pojedynczego węzła. Tym co wyróżnia rozwiązanie od standardowego wirtualizatora jest to, że host nie zarządza lokalnymi dyskami twardymi. Dyski te są  podłączone w trybie passthrough do maszyny wirtualnej będącej sercem całego rozwiązania – Controller VM (CVM). Każdy z dysków jest zarządzany niezależnie – nie są z nich tworzone grupy RAID. Zatem wszelkie operacje odczytu i zapisu generowane przez hyperwizor przechodzą przez CVM.

Rysunek 11 Architektura pojedynczego węzła

Maszyny CVM komunikują się ze sobą poprzez interfejsy 10GbE. Implementacja rozwiązania wymaga zatem przełączników sieciowych 10GbE. Kolejne interfejsy w węźle są przeznaczone dla ruchu maszyn wirtualnych – 1GbE lub 10GbE (rysunek 9).

Rysunek 12 Architektura całego rozwiązania (DFS – Distributed Storage Fabric)

Sam hyperwizor jest zainstalowany na dedykowanej pamięci flash, (która nie jest pokazana na rysunku 11).

Dzięki programowej implementacji rozwiązania, jest ono bardzo elastyczne, a aktualnie dostępne funkcjonalności mogą łatwo być rozbudowane przez aktualizację.

Rysunek 13 Ogólna modułowa architektura CVM, pozwalająca na implementację nowych funkcjonalności

Rysunek 14 Architektura CVM

Modułową architekturę realizowana jest poprzez serwisy działające na każdym CVM (rysunek 14)

• Prism – odpowiada za komunikacje z użytkownikiem za pomocą interfejsu web’owego i API, działa na każdym węźle, jedna instancja wybierana jest na lidera
• Stargate – udostępnia zasoby dyskowe za pomocą odpowiednich protokołów, działa na każdym węźle
• Cassandra – rozproszona pamięć na matadane, działa na każdym węźle tworząc pierścień, utrzymuje wymaganą liczbę kopii danych w klastrze, dostępna przez interfejs zwany Medusa
• Zookeeper – zarządca konfiguracji klastra, działa na trzech węzłach w całym klastrze, jedna z instancji jest liderem. Zookeeper jest dostępny za pośrednictwem interfejsu o nazwie Zeus. Zookeeper, o ile jest to możliwe, jest aktywny na różnych blokach (obudowach 2U)
• Curator – zarządca i koordynator zadań w klastrze, działa na każdym węźle, działanie wszystkich instancji koordynuje Curator Master
• Genesis – uruchomiony na każdym węźle, jest odpowiedzialny za uruchamianie i zatrzymywanie innych procesów, wstępną konfigurację, oraz monitoruje czy Zookeeper jest cały czas uruchomiony
• Chronos – jest odpowiedzialny za wykonywanie zaplanowanych działań, jest uruchomiony na każdym węźle, jest kontrolowany przez Chronos Master, który działa na tym samym węźle co Curator Master
• Cerbero – jest odpowiedzialny za replikację i funkcjonalności Disaster Recovery, planuje snapshot’y, wykonuje ich replikację do zdalnej lokalizacji, działa na każdym węźle. Wszystkie węzły uczestniczą w replikacji do zdalnych lokalizacji.
• Pithos – jest odpowiedzialny za konfigurację dysków wirtualnych, działa na każdym węźle, jest mocno zintegrowany z procesem Cassandra

Dane generowane przez maszyny wirtualne zapisywane są lokalne, oraz wykonywana jest ich replikacja synchroniczna do innego węzła, celem zapewnianie wysokiej dostępności. Domyślnie konfigurowany jest poziom replikacji RF2, co oznacza minimum dwie kopie na różnych węzłach (lub blokach jeśli jest to możliwe). Możliwe jest także ustawienie replikacji RF3, czy wymusza zapis każdej porcji danych na trzech węzłach/blokach. Warto dodać, że kopie danych są zapisywane na wszystkich węzłach, celem równoważenia obciążenia węzłów i zwiększenia wydajność całego rozwiązania. W sytuacji gdy w klastrze są węzły o większej pojemności, są one preferowane do przechowywania danych, celem optymalnego wykorzystania ich przestrzeni dyskowej, jednak nawet wtedy zachowana zostaje odpowiednia liczba kopii danych na różnych węzłach. Optymalizacja rozmieszczenia danych odbywa się w trakcie ich zapisu oraz okresowo po zainicjowaniu przez proces Curatora.

Rozwiązanie preferuje lokalną dostępność danych dla maszyn wirtualnych znajdujących się na danym węźle. W przypadku gdy danie nie są dostępne lokalnie, pobierane są z innych węzłów (ale tylko gdy maszyna wirtualne ich wymaga) i zachowywane. Jest to bardzo ciekawe rozwiązanie, gdyż w przypadku przeniesienie maszyny wirtualnej pomiędzy węzłami, węzeł będzie dążył do lokalnego zapewniania danych dla lokalnej maszyny wirtualnej, co w efekcie zwiększy wydajność operacji odczytu. Operacje zapisu trafiają zawsze na lokalne dyski.

Rozwiązanie Nutanix’a wykorzystuje dwa rodzaje dysków twardych: SSD oraz tradycyjne (HDD). Dyski tradycyjne w głównej mierze służą do przechowywanie „zimnych” danych (Extent Store) oraz w minimalnym stopniu jako przestrzeń dla serwisu Curatora. Dyski SSD natomiast są wykorzystywane do przechowywania następujących danych:

• maszyny CMV (dane replikowane na drugi dysk SSD)
• serwisu Cassandra – metadane
• OpLog – nieulotny bufor
• Unified Cache
• „Gorące” dane (Extent Store)

Rysunek 15 Ścieżki zapisu i odczytu danych

Dzięki takiej architekturze, świeżo zapisywane dane umieszczane są na dysku SSD, a w przypadku potrzeby ich ponownego odczytania są szybciej dostarczane. W przypadku częstego ich wykorzystania mogą zostać przeniesione do części pamięci RAM wykorzystywanej jako bufor. W sytuacji gdy lokalne dyski SSD są pełne, rozwiązanie może się wspomóc dyskami SSD z innego węzła. Dzięki temu nie następuje nagły spadek wydajności w wyniku zapisu nowych danych na dyskach obrotowych.

Rysunek 16 Architektura rozszerzenia mechanizmu Tieringu na cały klaster

Rozwiązanie Nutanix’a w minimalnej konfiguracji wymaga trzech węzłów, w miarę wzrostu potrzeb na kolejne zasoby dodajemy nowe węzły. Wysoka elastyczność tego rozwiązania nie wymaga szczególnych planów w tym zakresie, w każdej konfiguracji możemy dodać (nawet tylko jeden) kolejny węzeł, który pozwoli na liniowy wzrost wydajności. W sytuacji gdy osiągniemy stan w którym dysponujemy trzema blokami (np. po cztery węzły w każdym), w rozwiązaniu włączy się „block awareness”. Dane w klastrze będą wówczas tak rozkładane, aby był on odporny na awarię całego bloku.

W przypadku awarii jednego dysku, w dowolnym węźle, klaster niezwłocznie rozpoczyna procedurę leczenia (self-healing). Bloki danych, które były na utraconym dysku nie są już chronione wymaganą nadmiarowością. Wszystkie węzły, które są w posiadaniu zagrożonych bloków rozpoczynają proces rozpowszechniania ich na kolejne węzły. W wyniku tej operacji, w krótkim czasie, w środowisku uzyskujemy wymaganą redundancję wszystkich bloków danych, a procedura wymiany uszkodzonego dysku przestaje być krytyczna (z wyjątkiem serii NX-1000 oraz NX-6000). W przypadku niedostępności maszyny CVM, uruchamiany jest dostęp do danych maszyn wirtualnych poprzez sieć z innych maszyn CVM. W przypadku awarii całego węzła, pracujące na nim maszyny wirtualne, muszą być uruchomione na innym węźle (zapewnia to np. mechanizm HA VMware), dane maszyn są dostępne na innych węzłach, ale nie są odpowiednio zabezpieczone (analogicznie jak w przypadku awarii jednego dysku). Tutaj także uruchomiony jest proces rozpowszechniania danych, które były na objętym awarią węźle, na inne w klastrze.

Przestrzeń dyskowa jest cenna, a przechowywanie wszystkich danych zabezpieczonych przed awarią, pochłania połowę dostępnej przestrzeni dyskowej (w przypadku wykorzystania zabezpieczenia RF2). Celem ograniczenia tej straty, klaster wykorzystuje kompresję, deduplikację oraz przy wystarczającej liczbie węzłow – Erasure Coding. Ostatnia wymieniona technologia przypomina tworzenie grup RAID (5,6), na segmentach danych. Co w efekcie pozwala skasować nadmiarowe bloki danych. Technologia ta ma swoje wady, gdyż może prowadzić do sięgania do danych przez sieć.

Implementacja klastra DSF wspiera wydajne i efektywne objętościowo klonowanie maszyn wirtualnych jak i wykonywanie ich snapshotów, nie generując przy tym dodatkowego zapotrzebowania na przestrzeń dyskową (przynajmniej w chwili wykonania).

Zaimplementowane są również funkcjonalności wymagane dla zdalnych centrów przetwarzania danych. Replikacja obsługuje topologie Site to Site, Hub and Spoke oraz Full/Partial Mesh. Dla replikacji danych zastosowanie ma globalna deduplikacja, które pozwala przesyłać do zdalnej lokalizacji tylko nowe/zmienione bloki danych, optymalizując tym samym czas replikacji jak i zajętość pasma łączy WAN.

W ramach dodatkowego zabezpieczenia danych można także uruchomić backup do AWS. Ostatnią ważną funkcjonalnością dla centrów zapasowych jest możliwość uruchomienie metro klastra, jednak tylko jeżeli wykorzystywanym hyperwizorem jest ESXi (VMware).

Rozwiązanie nie jest hermetycznie zamknięte i pozwala podłączyć zasoby dyskowe klastra zewnętrznym systemom poprzez iSCSI, NFS czy SMB, co może być bardzo przydatnie w trakcie migracji lub innych specyficznych przypadkach biznesowych.

Podsumowanie

Rozwiązanie hiperkonwergentne oferowane przez Nutanix, jest bardzo zaawansowane i dojrzałe. Większość rynku przejęta przez Nutanix świadczy także o zaufaniu klientów, a bogata dokumentacja zaspokoi dociekliwych. Ciekawy produkt, który trafi już niedługo w nasze ręce a kilka chwil później opis naszych z nim tańców znajdziecie na blogu. Na koniec części pierwszej pragniemy podziękować firmie S4E która udostępniła nam sprzęt.