Wprowadzenie, czyli jak było do dziś
Wzrost popularności rozwiązań Hiperkonwergentnych w szczególności vSAN oraz Microsoft Storage Spaces Direct doprowadził do wyłonienia niejako nowej filozofii konfigurowania serwerów nazywanych „Ready Node”. Zawsze gdy mamy do czynienia z sytuacją gdy kto inny wyprodukował serwer a kto inny stworzył oprogramowanie, które ma na nim działać – trudno jest potem w przypadku problemów odnaleźć granice odpowiedzialności pomiędzy jednym a drugim producentem.
W czasach sprzed wirtualizacji i hiperkonwergencji sprawa była w miarę prosta – producent serwera deklarowała zgodność i wsparcie dla poszczególnych rodzin systemów operacyjnych. Później wraz z dynamicznym rozwojem systemów wirtualizacyjnych z jednej strony producent serwera nadal deklarował wsparcie dla danych systemów (najczęściej: Microsoft, VMware, Citrix) ale także producenci platform wirtualizacyjnych publikowali i uaktualniali własne tabele kompatybilności serwerów (rysunek 1 na przykładzie VMware) ale też i poszczególnych komponentów (karty sieciowe, kontrolery dysków, karty graficzne, etc. – rysunek 2 na przykładzie listy kompatybilności VMware).
Rysunek 1. Tabela interoperacyjności VMware – przykład platforma Intel S2600BPB
www.vmware.com/resources/compatibility/search.php
Rysunek 2. Tabela interoperacyjności VMware – przykład kontrolera Dell H730
Owe tabele kompatybilności potrzebne są z jednej strony osobom projektującym dane rozwiązanie i konfigurację serwerów (zwłaszcza tych mniej popularnych) lecz z drugiej strony zapewnieniu sobie wsparcia producenta na wypadek problemów z poprawnym działaniem. Zdarzają się przypadki gdy przykładowo po podniesieniu wersji wirtualizatora – jakiś sprawnie działający komponent (np. karta FC) zaczyna sprawiać problemy destabilizując pracę całego hosta.
I w takim lub podobnym momencie zaczyna się historia uzyskania wsparcia dla rozwiązania naszego problemu …..
Jeśli poprosimy bowiem producenta oprogramowania o wsparcie, pierwszym co zostanie zweryfikowane to czy dany, powodujący problem komponent znajduje się na liście wsparcia. Jeśli nie … cóż nasza korespondencja z producentem zakończy się informacją, że Support nie obejmuje takich przypadków i pozostajemy zdani sami sobie.
Producenci serwerów starali się również ze swojej strony zapewnić kompatybilność oferowanych komponentów ze wspieranymi producentami systemów operacyjnych oraz wirtualizatorów dostarczając wymagane sterowniki w tym także ich swoje wersje do produktów firm trzecich jak np. Intel oraz obejmując wszystko swoim wsparciem.
Z punktu widzenia naszego artykułu najważniejszym jest fakt, że wszystkie komponenty producenta serwera objęte były jego wsparciem niezależnie od konfiguracji – o ile cały serwer objęty był jeszcze wsparciem.
Hiperkonwergencja i rosnące wymagania dotyczące konfiguracji
Wraz z pojawieniem się rozwiązań HCI okazało się, że tak projektowane środowiska wymagają większego rygoru w zakresie doboru komponentów oraz konfiguracji. Szczególnego znaczenia dla sprawnego działania środowiska HCI nabrało dobranie takich komponentów jak:
Karty sieciowe – np. rozwiązanie S2D Microsoftu od początku zakładało wykorzystanie technologii RDMA, co także zostało zaimplementowane w nowych wersjach vSANu. Technologia ta realizowana jest tylko przez niektóre, certyfikowane karty i inaczej przez poszczególnych producentów (Intel posiada technlogię iWARP zaś Mellnox RoCE). Oczywiście da się zbudować środowisko bez wykorzystania tego mechanizmu jednak (w szczególności dla S2D) trudno to uznać za środowisko produkcyjne
Dyski – z jednej strony HCI intensywnie korzysta z dysków SSD na potrzeby buforowania zapisu/odczytu danych z drugiej zaś na rynku dostępnych jest cała gama dysków mniejszej lub większej wydajności oraz żywotności. Aby zapewnić sprawne i wydajne działanie swojego środowiska Vmware wymaga dysków z odpowiedniej przetestowanej przez siebie listy kompatybilności. Lista zgodności Vmware szczegółowo określa jaki dysk i w jakiej konkretnie wersji Firmware do czego może zostać użyty w środowisku (jako Cache czy też dysk danych) czego przykład pokazaliśmy na rysunku 3.
Rysunek 3. Lista HCL VMware dla dysku Intel SSD SATA S4500, który z firmware SCV1LU32 może zostać użyty jako dysk Cache w konfiguracji hybrydowej lub jako dysk Danych w konfiguracji All Flash.
Kontrolery dysków – jeden z głównych problemów konfiguracyjnych w rozwiązaniach Ready Node. Do tej pory kontroler dysków lokalnych był pośrednią warstwą realizującą funkcje RAID, cache etc. i prezentował wirtualizatorowi gotową bezpieczną przestrzeń danych oraz zajmował się monitorowaniem stanu samych dysków (funkcje SMART, i inne). Rozwiązania HCI nie potrzebują już tej warstwy i same przejmują funkcje monitorowania dysków oraz replikowania danych. Lecz tym celu wymagają podpięcia dysków w rybie HBA czego z kolei nie oferują znane nam kontrolery RAID. (możliwe jest przestawienie działania niektórych kontrolerów w tryb Pass-Thru, jednak jest to tylko emulacja trybu HBA). Z tego powodu producenci serwerów zaczęli na potrzeby rozwiązań HCI oferować kontrolery typu HBA, które nie realizują już funkcji RAID – a jedynie prezentują podłączone dyski wirtualizatorowi. Na rysunku poniżej przedstawiono przykład opisu kontrolera HBA330 firmy Dell na liście HCL VMware. Jak można zauważyć podobnie jak w przypadku dysków i kart sieciowych weryfikowane są także wersje Firmware kontrolera.
Rysunek 3. Lista HCL VMware dla kontrolera HBA330
Dyski startowe dla wirtualizatora – O ile w klasycznym serwerze mieliśmy dowolność w wykorzystaniu dysków zarówno na potrzeby instalacji wirtualizatora jak i przechowywania maszyn wirtualnych o tyle w przypadku rozwiązań Microsoft S2D i VMware
vSan dyski są w całości przechwytywane na potrzeby klastra Storage. Musimy więc zapewnić odrębną przestrzeń na wirtualizator. Ponieważ stosowany kontroler HBA nie zapewni nam funkcji RAID w miejscu instalacji wirtualizatora musimy zrealizować to w inny sposób. Producenci serwerów najczęściej oferują rozwiązania w postaci zdublowanych kart SD lub osobnego kontrolera RAID na dyski startowe. Przykładowo Dell oferuje karty BOSS w mowa dyskami M.2 (Rysunek 4) umożliwiający instalację wirtualizatora VMware lub Microsoft. Nie wszystkie rozwiązania będą jednak wspierane oficjalnie przez producenta serwera o czym jeszcze powiemy w dalszej części.
Czym więc jest Server Ready Node i jak go skonfigurować ?
Powyższe rozważania pokazują nam więc, że jeśli chcemy zbudować klaster HCI nie wystarczy nam wziąć serwery z dyskami – musimy spełnić szereg innych warunków do uruchomienia środowiska. Jeśli robimy to w celach testowych – faktycznie możemy z dużą szansą powodzenia oprzeć się na prawie dowolnych serwerach z wewnętrznymi dyskami (ewentualnie uzupełniając je do wymaganych konfiguracji) – wymusić tryb emulacji kontrolera, zrezygnować z funkcji RDMA i uruchomić taki klaster. Jeśli sięuda super, jeśli nie coż: producent serwera nam nie pomoże, producent wirtualizatora zacznie od wersyfikacji czy nasze komponenty spełniają warunki konfiguracji i czy są na liście wsparcia ale nie tylko wirtualizatora lecz także klastra HCI.
Przykładowo VMware utrzymuje bazę kompatybilności komponentów dla rozwiązań VSAN READY NODE zwaną jako baza HCL (Hardware Compatibility List). Baza ta jest cyklicznie automatyzowana online ze stron producenta i pobierana przez VSAN z: https://partnerweb.vmware.com/service/vsan/all.json
Możliwe jest także ręczne przejrzenie kompatybilnych komponentów na stronie : www.vmware.com/resources/compatibility/pdf/vi_vsan_guide.pdf
Gdy komponenty naszego środowiska będą się znajdowały na liście kompatybilności HCL mamy niejako pewność, że nasze środowisko jest wspierane i supportowane przez producenta HCI.
Jak to wygląda od strony producentów serwerów ?
Jeszcze do niedawna najwięksi dostawcy serwerów (Dell,HPE, etc) podchodzili do tematu w ten sposób, że do możliwych konfiguracji dokładali komponenty do budowy HCI i pozostawiali integratorowi rolę prawidłowego skonfigurowania serwera. Rolą integratora było więc skonfigurowanie serwera zgodnie z listą HCL. W osiągnięciu tego pomagał też producent wirtualizatora publikując listę serwerów i ich konfiguracji, które są zgodne z Ready Node. Przykładowo VMware udostępnia swój konfigurator VSAN Ready Node na którym możemy wybrać producenta, wstępną konfigurację (All Flash / Hybrid), zakłądaną pojemność i dostaniemy listę kompatyblinych serwerów oraz ich konfigurację
Wersja zbiorczego PDF zawierającego te konfiguracje znaleźć można także tutaj: www.vmware.com/resources/compatibility/pdf/vi_vsan_rn_guide.pdf
Niestety zawsze jak to bywa gdy trzeba wziąć za coś odpowiedzialność producenci serwerów zaczęli certyfikować serwery jako Ready Node na własny sposób. Na potrzeby opisu poniżej skoncentrujemy się na rozwiązaniach firmy DellEMC.
Mamy więc z jednej strony konfiguracje wspierane i opisane przez producenta oprogramowania HCI, z drugiej chcielibyśmy aby rozwiązanie było także certyfikowane i wspierane przez producenta serwera.
Kiedy i czy zawsze można tak zrobić ? i jakie wiążą się z tym ograniczenia – postaramy się uwypuklić poniżej
Zacznijmy od ograniczeń jakie niesie ze sobą rozwiązanie, które ma być certyfikowane przez producenta (w tym wypadku DellEMC):
Pula serwerów jest ograniczona do kilku modeli (4Q2018):
- STORAGE SPACES DIRECT READY NODE R640
- STORAGE SPACES DIRECT READY NODE R640 ROBO
- STORAGE SPACES DIRECT READY NODE R740XD
- VSAN Ready Node C6420
- VSAN Ready Node R440
- VSAN Ready Node R640
- VSAN Ready Node R6415
- VSAN Ready Node R740xd
- VxFlex Ready Node Management (R640-VxFlex-MGMT)
- VxFlex Ready Node R640 Compute Only
- VxFlex Ready Node R640 – Storage/HCI
- VxFlex Ready Node R740xd – Storage/HCI
Z czego najbardziej chyba brakuje modelu R7415 – który umożliwiał by budowę klastra opartego na 1-procesorowych serwerach AMD z możliwością umieszczenia 24 dysków 2.5″ lub 12 dysków 3.5″
Pozostałe ograniczenia (główne):
- Konieczne i możliwe jest użycie wyłącznie kontrolera H330.
- Wymagane jest wybranie kart BOSS jako kart startowych dla esxi, mimo, że możliwe jest także wybranie kart SD
- dostępne są tylko wybrane konfiguracje kart sieciowych
Z kolei w konfiguracjach nie ReadyNode nie ma możliwości wyboru kontrolera H330.
Taki ruch ze strony producenta serwera wydaje się dość logiczny – zawęża to bowiem ilość konfiguracji z którymi potem musiałby ewentualnie borykać się z wieloma mniej lub bardziej egzotycznymi przypadkami.
I jest to słuszna droga dla klientów, którzy kupują nowy klaster serwerów i w/w ograniczenia nie stanowią dla nich przeszkody.
Co jednak w przypadku gdy mamy już jakiś sprzęt, który chcemy użyć ? przykładowo serwer, który ma kontroler PERC H730 ?
Pozostaje nam zweryfikować czy nasz komponenty znajdują się na liście HCL,i ewentualnie dozbroić serwer o komponenty z listy HCL.
Przykładowo wspominany wyżej kontroler H730 znajduje się w bazie HCL:
Gorszą wiadomością jest ta, że na liście tej nie ma już nowych kontrolerów 14 generacji Perc H740.