Netapp HCI #1

Kontynuujemy serię o hiperkonwergencji, trendzie w centrach danych mającym na celu uproszczanie infrastruktury, poprzez eliminację pamięci masowych. Wszystkie dotychczas opisywane na blogu rozwiązania HCI były obciążone tak zwanym „podatkiem HCI”. NetApp przygotował rozwiązanie, które opodatkowane nie jest…

Aktualnie na ryku produktów dla centrów przetwarzania danych coraz głośniej jest o hiperkonwergencji. Coraz trudniej jest spotkać osobę z branży, która nie wie czym jest vSAN czy inne rozwiązania HCI. Różnego rodzaju analizy odnotowują znaczny wzrost tego rynku oraz przewidują dalsze wzmocnienie tego trendu. Wspomniany wzrost został zauważony także przez firmę Gartner publikującą znane w środowisku kwadranty –  w lutym 2018 opublikowała pierwszą analizę poświęconą wyłącznie rynkowi HCI. Kolejna taka analiza pojawiła się w już listopadzie tego samego roku.

Rysunek 1 Oprócz kosmetycznej zmiany w kwadrancie liderów jaką jest odsunięcie na osi kompletności wizji Dell EMC od VMware, pojawia się tam firma Cisco, sklasyfikowana tuż obok HPE. Zniknęły takie firmy jak Stratoscale czyi HTBase, Pojawiły się natomiast: Red Hat, Maxta, StarMagic i StarWind.

 

We wspomnianej analizie w sekcji wyróżnień pojawia się NetApp HCI, któremu poświęcony jest ten artykuł. Gartner wskazuje NetAppa jako globalnego gracza. NetApp HCI rywalizuje z dostawcami innych rozwiązań hiperkonwergentnych lecz nie spełnia ono funkcjonalnej definicji HCI stosowanej przez Gartnera, w wyniku czego produkt ten jest wykluczony z porównania. Bardzo prawdopodobne, że wynika to ze wspomnianego we wstępie braku podatku HCI – w rozwiązaniu tym węzły z hiperwizorem nie posiadają lokalnych dysków, z których tworzony jest współdzielony zasób.

Historia

NetApp w ramach powiększania portfolio swoich produktów, dążąc do jak najlepszego zaadresowania potrzeb swoich klientów  na początku 2016 roku zakupił formę SolidFire specjalizującą się z w rozproszonych, skalowalnych systemach pamięci masowych typu All-Flash. Bazując na funkcjonalnościach nowego produktu powstał Natapp HCI – oficjalnie ogłoszony w październiku 2017 roku. Oficjalną nazwą komponentu dostarczającego pamięć masową został „NetApp SolidFire Element OS”, w miesiącu premiery wydana została wersja 10 tego systemu. W kolejnym miesiącach były wydawane kolejne mniejsze aktualizacje, by w listopadzie 2018 roku została wydana wersja systemu oznaczona numerem 11.

Architektura

Rozwiązania HCI są alternatywą dla firm pozostających we własnym centrum przetwarzania danych pragnących jednak zachować elastyczność i szybkość rozbudowy jaką daje infrastruktura chmury publicznej. Oczywiście chmura publiczna to znacznie więcej niż tylko maszyny wirtualne, składa się na nią zestaw dodatkowych warstw abstrakcji i automatyzacji. Wiele firm korzysta z lokalnych serwerowni, jak i z usług chmurowych. NetApp widząc te trendy, może oferować swoim klientom dodatkowe produkty do integracji z chmurą publiczną, jak i usprawniania lokalnej infrastruktury.

Rysunek 2 Podstawą rozwiązania NetApp HCI jest Storage node z systemem operacyjnym NetApp SolidFire Element OS oraz Compute Node, serwer z VMware ESXi. Oba systemy są integrowane w vCenter za pomocą dodatkowej maszyny wirtualnej mNode, jej zadaniem jest dostarczanie do konsoli vCenter wszelkich informacji i alarmów z warstwy Solidfire. W wyższej warstwie elementy opisane jako Integrated Data Services stanowią integralną funkcjonalność SolidFire. Kolejne elementy – Data Fabric Services oraz Third-Party Services są opcjonalne. Całość jest spinana poprzez element NDE – NetApp Deployment Engine moduł odpowiedzialny za wdrażanie klastra oraz zmiany jak np. dodawanie nowych węzłów.

 

Rozwiązanie HCI jest oferowane jako solidna i elastyczna podstawa, na której można zbudować kolejne warstwy usług, zabezpieczeń i automatyzacji. Przyjrzyjmy się zatem z jakich elementów fizycznych składa się najmniejsza realizacja omawianej hiperkonwergencji.

Rysunek 3 Skład minimalnego zestawu NetApp HCI.

 

Podstawą fizyczną jest obudowa wielkości 2RU z czterema serwerami wysuwanymi od tyłu oraz dyskami instalowanymi od przodu obudowy. Obudowa zawiera także dwa zasilacza wspólne dla serwerów z danej obudowy. W minimalnej konfiguracji, z czterech slotów na serwery wykorzystywane są trzy, jeden jako węzeł obliczeniowy z VMware ESXi (niebieski serwer z powyższego rysunku), dwa kolejne jako węzły dostarczające przestrzeń dyskową (czerwone). W omawianej konfiguracji wykorzystuje się dwie obudowy, zatem otrzymujemy klaster VMware z dwoma serwerami ESXi oraz czterema serwerami dostarczającymi przestrzeń dyskową. W przypadku potrzeby rozbudowy przestrzeni dyskowej, dokupujemy węzeł storage, gdy natomiast brakuje CPU czy RAM dla maszyn wirtualnych, dodajemy węzeł obliczeniowy. Poznawszy podstawowe założenia tego rozwiązania mogą się pojawić dodatkowe pytania czy zarzuty wynikające z tego, że opisywane dotychczas rozwiązania HCI opierały się na uniwersalnych węzłach, każdy dostarczał CPU, RAM, oraz zasoby dyskowe dla maszyn wirtualnych.

Wspomniana uniwersalność jest jednocześnie tak zwanym „podatkiem HCI”, gdyż serwery ESXi licencjonujemy na procesory, niestety część ich mocy oddajemy do obsługi pamięci masowej dla maszyn wirtualnych, zatem zmniejsza się moc dostępna dla maszyn wirtualnych. W sytuacji gdy nie możemy do istniejących serwerów dodać kolejnych dysków (lub ich zamienić na większe), a potrzebujemy dodatkowej przestrzeni (lub wydajności) dyskowej, musimy wówczas zakupić dodatkowy serwer i zakupić licencję od VMware, jak i na nasze rozwiązanie HCI – jest to kolejny przejaw wspomnianego podatku. Podatek ten się jeszcze zwiększy, jeżeli systemy operacyjne w maszynach wirtualnych będą wymagać zalicencjonowania nowego hosta ESXi. Z powodu wspomnianych ograniczeń. NetApp pozostałe rozwiązania HCI określa mianem pierwszej generacji, a swoją propozycję jako HCI następnej generacji. Bardzo trudno się oprzeć wrażeniu powrotu do klasycznej architektury serwerów i macierzy, ulepszonej jednak w następujących aspektach: węzły storage są bardziej elastyczne w rozbudowie i utrzymaniu; oba rodzaje węzłów instaluje się w takich samych (i tych samych) obudowach; węzły storage ściśle się integrują ze środowiskiem VMware. Lecz właśnie wymienione różnice rozwiązują problemy braku elastyczności klasycznych systemów macierzowych oraz problemy wprowadzane przez systemy HCI pozostałych dostawców. Warto monitorować rynek i wybory klientów, może w niedługim czasie czeka nas przedefiniowanie systemów HCI, a model oferowany NetAppa stanie się dominującym.

Fizyczne komponenty

Rozróżnienie dla węzłów obliczeniowych i przechowujących dane ujawnia się także w fizycznym okablowaniu – węzły obliczeniowe wymagają osobnych interfejsów dla obsługi danych oraz osobnych do obsługi maszyn wirtualnych.

Rysunek 4 Węzeł obliczeniowy, połączenia sieciowe

 

Optymalnie kosztowo jest wykorzystać dwa rodzaje switchy (rys 3 i 4), górne o interfejsach 1 GbE, dolne 10 GbE lub szybsze. Wykorzystane połączenie to:

– pomarańczowy, interfejs IPMI

– zielony, zarządzanie systemem operacyjnym węzła

– żółty, sieć na potrzeby ruchu dostępowego do pamięci udostępnianej przez węzły storage

– fioletowy, ruch maszyn wirtualnych

Rysunek 5 Węzeł udostępniający dane, połączenia sieciowe

 

Opis połączeń węzła storage jest zgodny z węzłem obliczeniowym za wyjątkiem:

– braku połączeń dedykowanych dla ruchu maszyn wirtualnych, gdyż te na nim nie występują,

– zalecenia agregacji połączeń ruchu zarządzającego systemem operacyjnym oraz udostępniających pamięć masową

Opisane wymagania są dla testowanej wersji – NetApp HCI 1.3 (zawierającej NetApp SolidFire Element OS 10.3). W wersji NetApp HCI 1.4 jest możliwość konfiguracji węzła obliczeniowego z wykorzystaniem tylko 3 interfejsów

– 1 x IPMI

– 2 x 10GbE (lub szybszy), które obsługują ruch zarządzający systemem operacyjnym, maszyn wirtualnych, oraz ruch dostępowy do pamięci masowej.

Jako że interfejsy 10 GbE nie należą do najtańszych, zmniejszenie wymaganej ich ilości może zmniejszyć koszty wdrożenia i utrzymania rozwiązania. Dodatkowo w najnowszej wersji możliwy jest zakup switchy Mellanox, do których NetApp udostępnia szczegółową instrukcję konfiguracji.

Odnośniki do pozostałych części serii:

Część II

Część III

Część IV

Część V