W dzisiejszym artykule kontynuujemy serię o hiperkonwergencji, czyli o uproszczeniu architektury serwerowej, w ramach której integrujemy macierze dyskowe z posiadanymi już serwerami. Nowe podejście do tej architektury zyskuje coraz większą popularność, co potwierdza nowy typ raportów Gartnera opublikowany w 2018 roku, poświęcony wyłącznie tej dziedzinie technologii.
Obecny świat zmienia się w tempie, za jakim mało kto jest w stanie nadążyć. Wielkie firmy technologiczne się łączą, czasem dzielą czy sprzedają jakąś cześć, która nie przynosi spodziewanych zysków. Doświadczamy wysypu startupów, gdzie ludzie pełni pasji ze świeżymi pomysłami chcą zbudować coś nowego, często rewolucyjnego a czym żadna wielka firma zająć się nie chciała. Często dochodzi do wykupów owych debiutantów, gdy okazuje się, że pomysł i realizacja jest na tyle dobra, że mogłaby z czasem doprowadzić do pojawienia się nowej konkurencji. Może także taki wykup wynikać z sytuacji, gdy ktoś zaspał, rynek poszedł w nowym kierunku, a nie ma czasu na samodzielny rozwój nowej gałęzi produktów – zakup nowej obiecującej firmy także pomoże nadgonić konkurencję. Nie wszystkim startupom się udaje utrzymać, nie co dzień dochodzi do transakcji na miliony dolarów, gdy technologiczny gigant kupuje taki nowy biznes. Czasami, giganci świadomi swojej skostniałej struktury i małej elastyczności same wspierają takie nowe prężne firmy w poszukiwaniu świeżości. Nowe firmy potrafią być tak skuteczne dzięki skupieniu się na swojej wizji i wykorzystywaniu energii tylko dla jej realizacji, wszelkie inne zasoby czy usługi są wykorzystywane w postaci gotowej, często nawet ładnie opakowanej usługi. W tej elastyczności bardzo pomagają dostawcy usług chmury publicznej umożliwiający wykorzystanie tylko niezbędnych zasobów w czasie gdy są one potrzebne, naliczając opłaty tylko za ten okres, gdy były wykorzystywane. Gdy jakieś usługi przestają być potrzebne, można z nich zrezygnować i przestać ponosić za nie koszty. Scenariusz trudny do realizacji przy zakupie jakiejkolwiek infrastruktury lokalnej – jak oddać pół serwera?
Lecz gdy firmy urosły wcześniej, przeszły okres młodości i burzliwego rozwoju, osiągnęły stabilność, zminimalizowały wszelkie możliwe ryzyka operacyjne, a teraz czują na plecach oddech młodych wilków, zwinniejszych, elastyczniejszych, śmiało podejmujących walkę z większymi. Walka wydawałoby się nie równa, z góry skazana na porażkę, lecz wszyscy nie muszą zwyciężać, wystarczy jeden, który zachwieje istniejący status quo. Skupiając się na infrastrukturze serwerowej i pamięciach masowych, pomimo wdrożonych rozwiązaniach do wirtualizacji nadal są obszary, które można uprościć. Słowo uproszczenie jest tu bardzo istotne, gdyż nie jest ono równoznaczne z lepsze, wydajniejsze, czy nawet tańsze. Prostota oznacza mniejszy stopień skomplikowania, który przekłada się na szybkość realizacji zmian. Jeśli aktualna infrastruktura macierzowa, oparta na sieciach światłowodowych, jest wyśrubowana pod kątem wydajności, a systemy ją wykorzystujące są stosunkowo niezmienne, to trudno tu coś zoptymalizować kosztowo. Spoglądając jednak szerzej, biorąc pod uwagę koszt miejsca w centrum danych, koszt klimatyzacji, prądu, utrzymania kontraktów serwisowych dla macierzy, jak i switchy światłowodowych, dokładając do tego konieczność rozbudowy macierzy do obsługi dodatkowych danych, okazuje się, że utrzymanie aktualnego stanu wymaga całkiem sporo wysiłku, czasu i pieniędzy. Dodając jeszcze fakt, że każda aktualizacja firmware musi być przetestowana na wszystkich komponentach, a w sytuacji, gdy aktualne macierze przestają być wspierane przez producenta i trzeba zaplanować migracje wszystkich danych na nowe „lepsze” modele, przestaje dziwić fakt niechęci do zmian w zespołach odpowiedzialnych za utrzymanie środowiska. Wracając zatem do uproszczenia, jakie oferuje hiperkonwergencja, nie oferuje ona niższej ceny czy większej wydajności – to, co oferuje to elastyczność, zmniejszenie zależności między komponentami, oraz co jest chyba najbardziej charakterystyczne – skrócenie czasu wdrażania zmian w takim środowisku. Wszystko to jest realizowane poprzez jeden komponent powtarzany wielokrotnie – serwer z lokalnymi dyskami. Dyski ze wszystkich serwerów tworzą logiczny byt zapewniający większą wydajność niż jeden nośnik danych oraz odporność na awarię jednego lub więcej dysku twardego czy serwera.
Oprócz opisanych i znanych szeroko w środowisku liderów na rynku hiperkonwergencji są firmy, które liderami mają szansę zostać w najbliższej przyszłości. Jedną z takich firm jest Maxta, założona w 2009 roku, od 2016 działająca w Europie, z siedzibą w Santa Clara. Nie jest zaliczona do firm wymienianych w raporcie Gartnera dla rynku HCI, lecz w 2015 została nazwana „Cool vendor” w raporcie „Cool Vendors in Storage, 2015” przygotowanym właśnie przez Gertnera. Premiera produktu Maxta Storage Platform (MxSP) miała miejsce w 2013 roku. W 2014 została wydana wersja druga, która dodawała funkcje takie jak, automatyczna ochrona danych, „rack awareness”, integracja w VSS. Trzecia generacja produktu została udostępniona w 2016 roku i wprowadzała takie nowości jak: nowy interfejs użytkownika, zarządzanie ochroną danych na poziomie maszyny wirtualnej, ujednolicone zarządzanie dla VMware. Produkt jest intensywnie rozwijany, na przełomie lipca i sierpnia b.r. spodziewana jest kolejna wersja, w której zaprezentowana zostanie kompatybilność z KVM z platformy RedHat. Firma aktualnie zatrudnia ponad 100 osób, corocznie podwajając przychody oraz liczbę klientów.
Maxta stawia na wolność wyboru platformy sprzętowej przez klienta, a podstawowym wymaganiem jest zgodność z VMware HCL (Hardware Compatibility List), dodatkowo potrzebna jest przestrzeń dyskowa na kontroler wirtualny (maksymalnie do 100 GB, dopuszczalne jest skorzystanie z dysku na którym zainstalowany jest ESXi), oraz dyski które zostaną dołączone do MxSP – SSD dla warstwy buforującej, oraz dyski dla warstwy przechowywania danych. Istotne jest czy budujemy klaster typu All-Flash czy hybrydowy, gdyż w warstwie przechowywania danych mogą być dyski tylko jednego rodzaju. Jeżeli wybierzemy dwa dyski SSD do warstwy buforującej, wówczas możliwe jest uruchomienie wykonywania repliki jednego na drugi, co pozwoli zabezpieczyć się sprzed awarią tego dysku a tym samym przed utratą całego węzła w kontekście dostępu do danych. W implementacjach hybrydowych część dysku SSD jest wykorzystywana jako bufor odczytu, obszar do zapisu metadanych oraz dziennik zapisów dla warstwy przechowywania danych. W konfiguracji All-Flash nie ma potrzeby utrzymywać tych bytów poza warstwą docelową, gdyż dostęp bezpośrednio do dysków SSD z warstwy przechowywania danych nie stanowią wąskiego gardła. Unikatowy dla Maxta, w odróżnieniu od innych producentów rozwiązań hiperkonwergentnych jest sposób podłączania dysków do kontrolera wirtualnego, tutaj jest wykorzystany RDM (Raw Device Mapping) w trybie fizycznym. W innych rozwiązaniach zdarza się, że do kontrolera wirtualnego podłączany jest kontroler dysków w trybie passthrough, co wymaga „umiejętności obsługi” wspomnianego kontrolera. W podejściu Maxta, kontroler jest cały czas obsługiwany przez ESXi – jest to powód dla którego to rozwiązanie może być sprzedawane w wersji „tylko oprogramowanie”. Klient musi zadbać o kompatybilność serwera z VMware, a dzięki temu kompatybilność z Maxta jest już zapewniona automatycznie. Warto dodać, że dla klientów pragnących kupić rozwiązanie razem z serwerami, Maxta może dostarczyć rekomendowane konfiguracje sprzętowe wybranych producentów.
Rysunek 2 Architektura Maxta zakłada współdzielony przez wszystkie węzły w klastrze logiczny zasób dyskowy, lecz maszyny wirtualne czy kontenery mają zdefiniowaną indywidualnie wielkość bloku danych czy ochronę przed utratą danych (RF – liczba replik danych). W każdym węźle, w przypadku hostów ESXi znajduję się maszyna wirtualna – kontroler Maxta, odpowiedzialna za zarządzanie lokalnymi dyskami by z pozostałymi kontrolerami współtworzyć współdzielony zasób dyskowy. Wirtualny kontroler aby działać potrzebuje fizycznych zasobów – dla tej maszyny wirtualnej przydzielone jest 28GB RAM oraz 4vCPU.W optymalnym wariancie na potrzeby ruchu pomiędzy kontrolerami przydziela się dedykowane interfejsy sieciowe 10GBE.
W ramach wymagań sieciowych Maxta również jest elastyczna. Wymagany jest osobny segment na potrzeby ruchu storage, w ramach której kontrolery wirtualne wymieniają się danymi oraz udostępniają je dla węzłów klastra jako zasób NFS. W optymalnej konfiguracji rekomendowane są dwa dedykowane interfejsy 10 GbE, lecz w przypadku współdzielenie interfejsów fizycznych czy ich wolniejszych wersjach rozwiązanie nadal będzie funkcjonować prawidłowo (choć z mniejszą wydajnością). Dla zwiększenia wydajności dane są dzielona ma paski wielkości 1MB (maksymalnie osiem pasków) i zapisywane w możliwie najbardziej rozproszony sposób. Oprócz zwiększenie wydajności znacznie zmniejsza się ryzyko powstania dużego obszaru „gorących danych”, które mogę stanowić wąskie gardła. Dostęp do współdzielonego zasobu dyskowego możliwy jest tylko z zalicencjonowanych hostów dołączonych do klastra. Wprawdzie można dodawać hosty bez lokalnych zasobów dyskowych, które będą wyłącznie korzystać w danych udostępnianych przez inne węzły, (tak zwany „compute node”), lecz i tak wymaga on wykupienia standardowej licencji i dołączenia do klastra MxSP. Nie ma rozróżnienia na wersje licencyjne co znacznie upraszcza model. Samo oprogramowania wykupujemy w modelu własnościowym plus corocznie odnawiane wsparcie. Licencja na węzły nie jest w żaden sposób przypisywane do sprzętu, zatem przenoszenie licencji pomiędzy hostami w przypadku ich wymiany nie powinno sprawiać żadnego problemu. Podstawowe zarządzanie rozwiązaniem odbywa z interfejsu MxInsight, dostępnego przez przeglądarkę i udostępnianego z jednego kontrolera wirtualnego. W sytuacji jego niedostępności inny kontroler przejmuje funkcję udostępniana interfejsu.
Dziękujemy firmie Maxta (https://www.maxta.com) i Connect Distribution (https://connectdistribution.pl/pl/) za sprzęt i pomoc w testach.
Poniżej znajdą Państwo linki do kolejnego artykułu: