VxRail – Wstęp

W niniejszym artykule pochylam się na produktem o nazwie VxRail. Przy zagłębianiu się w detale okazuje się, że samego VxRail jest mało, dużo więcej jest natomiast produktu o nazwie vSAN. Przy testach innych rozwiązań hiperkonwergentnych sytuacja jest prosta, jest dedykowany hardware w kilku wersjach, jest konkretny produkt, który się ma kilka wersji licencyjnych, a u podstaw wszystkiego jest VMware vSphere. Łatwo zatem oddzielić testowany element od platformy dla której produkt powstał. Mamy vSphere, maszyny wirtualne i mamy rozwiązanie hiperkonwergentne – storage dla VMware – obiekt testu. W opisywanym przypadku mamy sytuację bardziej skomplikowaną.

Produkt jaki testujemy nazywa się VxRail,  jest to sprzęt oraz dodatkowa maszyna wirtualna, tylko tyle i aż tyle. Co tu zatem testować? Do testów dostaliśmy klaster VxRail, lecz jest to tylko ładne opakowanie, gdyż w środku jest VMware vSAN i to jest właściwy obiekt testu. VxRail to wisienka na torcie, to opakowanie, to krok w kierunku niezdecydowanych, który pewniej się czują mając jednego dostawcę całego stosu technologicznego. To krok do tych, którzy są tak zaabsorbowani swoim biznesem, że nie chcą budować samochodu – wolą go kupić. Mając swoje priorytety i cele, kupują gotowe rozwiązanie, uruchamiają je i nie zastanawiają się jak i dlaczego coś działa, myślą tylko o tym jak szybko mogą jechać…

Odrobina historii

Firma VMware zapoczątkowała rewolucję na rynku serwerów. Wprowadzona wirtualizacja pozwoliła lepiej wykorzystywać pamięć operacyjną jak i zasoby obliczeniowe serwerów. Wprowadzenie klastrów niezawodnościowych w łatwy sposób pozwoliło zwiększyć bezpieczeństwo aplikacji, jednak pamięć dyskowa nie mogła w tym procesie uczestniczyć. Dyski twarde z serwerów nie były współdzielone w ramach klastra, zatem bardzo szybko powiększał się rynek macierzy dyskowych i technologii z nimi związanych. Same macierze budowane były w redundantny sposób, tak aby pojedyncza awaria nie była powodem większego przestoju. Rynek ten, rozwijał się dzięki VMware, ale sama firma nie miała z tego korzyści. Klienci, którzy byli zainteresowany technologią VMware, a chcący zbudować wysoko dostępne środowiska musieli się interesować także zakupem współdzielonej macierzy. Było to dodatkowy koszt, niewspółmiernie większy od lokalnych dysków, które zwykle w serwerze już były, a dokupienie kolejnych było znacznie tańsze. Problemem była jednak potencjalna awaria hosta, która czyniła lokalne dane niedostępnymi. Pierwszą próbą zaadresowanie tych potrzeb i problemów było udostępnienie vSphere Storage Appliance wraz z premierą vSphere 5, w 2011 roku. Rozwiązanie to tworzyło na dwóch lub trzech hostach dodatkowe maszyny wirtualne które wykorzystywały lokalną przestrzeń dyskową hosta, by następnie ją udostępniać, ale już wszystkim serwerom ESXi. Nie miałoby to najmniejszego sensu, gdyby w przypadku awarii hosta pozostałe traciłby dostęp do zasobów prezentowanych z danej maszyny. W celu uczynienia tego rozwiązania odpornym na pojedyncze awarie, owe maszyny wirtualne replikowały między sobą dane. W przypadku awarii potrzebne dane były dostępne z repliki (z innej maszyny). Cały proces przełączenia był automatyczny i transparentny. Powodowało to wprawdzie zmniejszenie użytecznej przestrzeni ale zwiększało niezawodność. Produkt nie był doskonały a rynek oczekiwał więcej. Wychodząc naprzeciw, VMware zdecydowała o zaprzestaniu rozwoju VSA oraz stworzeniu zupełnie nowego bardziej elastycznego produktu, pozbywając się zbędnych warstw loginych w postaci specjalizowanej maszyny wirtualnej na rzecz integracji całej funkcjonalności w jądro hosta ESXi. W ten sposób w 2014 roku wraz z vSphere 5.5 debiut miało rozwiązanie Virtual SAN. Z każdą kolejną wersją vSphere wydawana jest nowa wersja vSAN. Z wielu zmian jakie pojawiały się z kolejnymi wersjami, warto wspomnieć o kilku kluczowych:

• 6.0 obsługę opcji „all flash”, oraz „rack awareness”
• 6.1 „stretched cluster”, „health monitoring”
• 6.2 „deduplication”, „compression”, „erasure coding”
• 6.5 „iSCSI access”, „2-node claster for ROBO site”

Architektura vSAN

Trudno pisać o architekturze vSAN, nic nie wspominając o klastrze VMware, oba produkty są są ze sobą bardzo silnie związane, wręcz vSAN jest modułem czy opcją, klastra VMware. Nie wchodząc w szczegóły budowania klastrów VMware, przyjrzyjmy się różnicom. W klasycznym podejściu potrzebujemy współdzieloną pamięć dyskową oraz interfejsy komunikacyjne w hoście ESXi, (karta sieciowa lub karta HBA FC). W małych środowiskach być może dałoby się połączyć te dwa elementy bezpośrednio, lecz bardzo szybko pojawia się potrzeba posiadania portów sieciowych lub światłowodowych, w przełącznikach, pozwalających na uwspólnianie interfejsów macierzy. Dyski twarde i cała funkcjonalność opracowana przez producenta zawarta jest w macierzy, a host ESXi występuje tylko jako bierny użytkownik tej technologii. W klastrze vSAN nie ma współdzielonej macierzy, dyski twarde znajdują się w hostach ESXi a hosty komunikują się pomiędzy sobą celem zapewnienia dostępności danych w przypadku wystąpienia awarii. Do komunikacji potrzebne są interfejsy sieciowe. W przypadku użycia interfejsów 1 Gbit, wymagane są dedykowane interfejsy dla ruchu klastra vSAN, jeśli dysponujemy jednak interfejsami 10 Gbit, mogą być one współdzielone. W takiej architekturze za wszystkie funkcje oferowane przez współdzieloną przestrzeń dyskową odpowiada klaster hostów VMware. Nie ma tu dedykowanej maszyny wirtualnej czy modułu, cała funkcjonalność vSAN jest zaszyta w jądrze systemu ESXi.W wyniku pełnej integracji vSAN z dotychczasowym rozwiązaniem VMware, zarządzanie odbywa się z konsoli web udostępnianej przez vCenter, za pomocą której zarządzany jest cały klaster. Taka integracja jest naturalna i wygodna, nie wymaga także nauki nowych interfejsów.Elementami niezbędnymi dla uruchomienie vSAN na konkretnym hoście są:

• dysk (pojedynczy lub w RAID), ewentualnie pamięć flash gdzie jest zainstalowany hyperwizor
• jeden dysk SSD (bufor odczytu i zapisu)
• dyski HDD lub SSD (przechowywanie danych)
• kontroler dysku będący w stanie wyżej wymienione dysku udostępnić indywidualne (RAID 0 lub pass through)
• dedykowane lub współdzielone interfejsy sieciowe dla komunikacji vSAN

Dysk SSD oraz dyski magnetyczne tworzą grupę. Awaria dysku SSD jest jednoznaczna z awarią całej grupy.

W standardowej konfiguracji każdy dysk maszyny wirtualnej zapisany jest na dwóch hostach ESXi. Zapisy odbywają się synchronicznie celem uniknięcia utraty danych w przypadku awarii.O ilości kopii danej maszyny wirtualnej decydujemy za pomocą przypisanej do niej polityki.

W ramach konfiguracji polityk mamy dostępnych wiele opcji (rysunek 2) w szczególności warto zwrócić uwagę na:

• Liczbę tolerowanych awarii – ustawienie definiuje ile pojedynczych awarii (w tym całych hostów) może wystąpić nie zakłócając pracy maszyny wirtualnej
• Na ile fragmentów powinien być podzielony jeden dysk wirtualny (celem zwiększenie wydajności operacji zapisu/odczytu). Jeden fragment może mieć maksymalnie 255 GB, zatem w przypadku większych dysków wirtualnych podział następuje automatycznie.

Możemy także dokonywać rezerwacji miejsca dla cienkich dysków, czy rezerwacji na dyskach buforujących (którymi zawsze są dyski SSD), a także ustalać limity operacji IOPS. Opcjami znacznie oszczędzającymi zużycie miejsca na dyskach jest kompresja i deduplikacja. Dodatkowo deduplikacja znacznie przyśpiesza wykonywanie klonów maszyn wirtualnych. Niestety opcje te są dostępne w wersji opierającej się wyłącznie na dyskach SSD (All-Flash).

Kolejną opcją pozwalającą oszczędzać miejsce (niestety także dostępną tylko w konfiguracji All-Flash) jest Erasure Coding, w trybie RAID5 oraz RAID6. Tryb ten całkowicie eliminuje duplikację danych. W RAID5 tworzone są trzy paski z danymi oraz czwarty z sumą kontrolną. W takiej konfiguracji pomimo braku dodatkowych kopii danych, klaster w dalszym ciągu jest odporny na pojedyncze awarie.

Quality of service – jest to jedna z polityk możliwych do zdefiniowania dla klastra vSAN, pozwalająca ograniczyć liczbę operacji dyskowych jakie mogą wykonywać maszyny wirtualne. Pozwala to zabezpieczyć przed zbyt aktywnym systemem, pozostałe maszyny w klastrze.

Failure domains – funkcjonalność ta pozwala na wskazanie grupy węzłów na które mają być rozkładanie kopie danych. Opcja doskonale sprawdzi się wobec potrzeby zabezpieczenia przed wyłączeniem jednej szafy rack, gdy wszystkie węzły rozmieszczone są np. w dwóch szafach.

W razie potrzeby zapewnienie dostępności danych w zdalnych lokalizacjach istnieje możliwość skonfigurowania rozciągniętego klastra w trybie active-active. Taka konfiguracje wymaga skorzystanie z trzeciej lokalizacji gdzie powinien być zainstalowany świadek, który będzie rozstrzygał o miejscu awarii i decydował, który ośrodek przetwarzania danych ma kłopoty z dostępnością, a przez to który powinien przejąć wszystkie obciążenia.

Konfiguracja rozciągniętego klastra wymaga wykorzystanie trzech lokalizacji oraz szybkich łączy pomiędzy nimi. W przypadku mniej wymagających użytkowników, asynchroniczną replikację można uruchomić z wykorzystaniem modułu vShere Replication, który w połączeniu z vSAN pozwala na uzyskanie czasu RPO rzędu pięciu minut.

Nowością w wersji 6.5 jest możliwość udostępnienie zasobów poza klaster vSAN, za pośrednictwem protokołu iSCSI.

W sytuacji awarii dowolnego komponentu, klaster rozróżnia dwa typy zdarzeń: Absent, oraz Degraded. W sytuacji zdarzenia absent nie podejmowanie są żadne akcje, gdyż zakłada się, że problem jest czasowy i ustąpi. Po domyślnym czasie sześćdziesięciu minut rozpoczynają się operacje przywracania wymaganej nadmiarowości danych, który były na niedostępnym elemencie klastra. Przykładem zdarzeń tego typu są: wyjęcie dysku twardego, niedostępność sieci, problem z kartą sieciową oraz niedostępność hosta. Pozostałe awarie wywołują natychmiastowe działanie mające na celu odtworzenie wymaganej nadmiarowości danych.

Ciekawą własnością takiej architektury jest odporność na wiele pojedynczych awarii, które następują w odstępach pozwalających na odtworzenie stanu w którym mamy wszystkie dane przynajmniej w dwóch kopiach. W klasycznej grupie RAID-5 awaria drugiego dysku w dowolnym czasie zawsze spowoduje niedostępność wszystkich danych. W opisywanej architekturze, awaria dowolnego komponentu może doprowadzić do zmniejszenie całkowitej pojemności klastra. Wymaga to przywrócenia wymaganej nadmiarowości danych kosztem dostępnej wolnej przestrzeni. Po czasie niezbędnym do obudowy, dane ponownie są w chronione zgodnie ze skonfigurowaną polityką a klaster gotowy na kolejną awarię. Wyjątkiem będzie tylko sytuacja gdy ilość danych zapisanych w klastrze, jest bliska maksymalnej pojemności, wówczas może nie być wolnego miejsca aby odtworzyć wymaganą nadmiarowość danych.

Analogicznie do ubywania miejsca w przypadku awarii, można dodawać miejsce w klastrze. Jeżeli jest taka możliwość, można dokładać do poszczególnych węzłów kolejne dyski twarde, lub dodawać nowe węzły. Jest to bardzo łatwy, nie wywołujący przestojów sposób.

Wykorzystanie lokalnych dysków zmienia sytuację gdy musimy wyłączyć host lub tylko przełączyć go w tryb maintenance. Musimy wówczas podjąć decyzję co mamy zrobić z danym znajdującymi się lokalnie, do wyboru mamy:

• nic nie robić – tym samy ryzykując niedostępność danych których jedyna kopia znajduje się na danym węźle
• zapewnić dostępność danych w klastrze, czyli przenosząc jedyne kopie na inne węzły
• zapewnić nadmiarowość danych zgodnie z politykami, co oznacza potrzebę migrowania danych na inne węzły, aby po wyłączeni analizowanego węzła dane w klastrze były w wymaganym nadmiarze.

VSAN jest licencjonowany w trzech wersjach: Standard, Advanced i Enterprise. Od wersji 6.5, tryb All-Flash jest dostępny już w licencji Standard, jak i nowość w tej wersji – udostępniane zasobów poza klaster za pomocą protokołu iSCSI.

W wersji advanced dostępne są takie opcje jak: kompresja i deduplikcja, RAID 5/6. W najwyższej wersji natomiast dostępna są rozciągnięte klastry oraz limitowanie IOPS.

Niedogodności z modelem zrób to sam

Fakt posiadania klastra VMware vSphere (bez licencji vSAN), jest nie wystarczający aby chociażby przetestować taką hiperkonwergencję samodzielnie. Uruchomienie tego rozwiązania (oraz gwarancja wsparcia VMware) wymaga odpowiednio dobranego sprzętu. W internecie dostępny jest VMware Compatibility Guide for VSAN, który pozwoli wybrać sprzęt zatwierdzony przez VMware do pracy z vSAN. Przy samodzielnej konfiguracji sprzętu musimy zdecydować o

• dysku z którego będzie startował system operacyjny
• dysku (lub dyskach SSD)
• dyskach magnetycznych
• kontrolerze RAID
• kartach sieciowych

Wybór powyższych elementów powinien być zgodny z wytycznymi, np.: pojemność dysku SSD powinna stanowić około 10% pojemności dysków magnetycznych (lub dysków SSD wybranych do magazynowania danych). Kolejnym aspektem jest wydajność, niewłaściwy dobór komponentów, będzie głównym powodem słabej wydajności klastra. Nie właściwy kontroler RAID może nie być w stanie obsłużyć wszystkich zainstalowanych dysków, a zbyt mała kolejka poleceń może być wąskim gardłem przy dostępie do danych.

Jeżeli zrezygnujemy z samodzielnego złożenia serwera, możemy wybrać serwer przygotowany przez jednego z producentów sprzętu oferujących serwery przystosowane do pracy z vSAN. Taki wybór daje pewność kompatybilności sprzętu z oprogramowaniem, jednak w przypadku problemów musimy się kontaktować z producentem sprzętu lub VMware. Całość procesu zarządzania cyklem życia serwerów, oraz modernizacja i rozwój platformy serwerowej pochłania pewien czas.

Czas na VxRail

Rozwiązaniem wszystkich problemów wymienionych powyżej jest zakup całej platformy serwerowo softwareowej od jednego dostawcy, przykładem takiej platformy jest VxRail. Rozwiązanie w wersji 3.5, składało się z obudowy wysokości 2U w której są dwa zasilacze. W obudowie natomiast znajdują się cztery niezależne serwery. W przedniej części obudowy znajdują się dyski twarde, maksymalnie po sześć przypadających na jeden serwer.

Przy zakupie należy wstępnie się zdecydować czy operać się będziemy wyłącznie na dyskach SSD czy dopuszczamy ekonomiczne wersje z dyskami magnetycznymi. Wybór jest ważny ze względu na brak możliwości mieszania tych wersji ze sobą. Także w ramach jednej obudowy wszystkie serwery muszą być takie same. Dodatkowo należy pamiętać, że w klastrze wszystkie węzły muszą dysponować interfejsami sieciowymi o takiej samej prędkości.

VxRail w wersji 3.5 wykorzystywał sprzęt SuperMicro, charakterystyczne jest, że w każdej wersji bazował na czteroserwerowej obudowie.

Po przejęciu EMC przez Dell, nastąpiło odświeżenie linii sprzętowej. Kolejna wersja – VxRail 4, wniosła sporo nowego sprzętu, aż w pięciu liniach.

• Linia G kontynuuje architekturę do ogólnych zastosowań znaną z poprzedniej wersji VxRail
• Linia E – ekonomiczna dla małych wdrożeń
• Linia V – zoptymalizowana dla środowisk VDI z dodatkowymi modułami GPU, wspomagającymi środowiska graficzne.
• Linia P – zoptymalizowana wydajnościowo
• Linia S – zoptymalizowana do kątem przechowywania danych dla aplikacji typu Microsoft Sharepoint, Exchange czy służących analizie danych

Co oprócz sprzętu?

Tym co spina dedykowany sprzęt i klaster VMware jest dedykowana maszyna wirtualna VxRail Manager, jest ona odpowiedzialna za instalację i aktualizację klastra oraz wsparcie dla sprzętu i oprogramowanie klastra.

Dodatkowo w ramach VxRail udzielana jest licencja na

• Vrealize Log Insight
• EMC Secure Remote Support
• EMC recover Point for Virtual Machines (licencja na 15 maszyn)
• EMC CloudArray – licencja na 1TB lokalnego bufora oraz 10TB danych w chmurze. Należy pamiętać, że samą usługę przechowywania danych w chmurze należy wykupić osobno.

Podsumowanie

Po opisaniu możliwości vSAN, oraz elementów dodatkowych które składają się na produkt VxRail, warto się zastanowić co testowaliśmy.

Sprzętu pod VxRail, jako takiego nie testujemy, a VxRail Manager nie jest podstawą rozwiązania. Wprawdzie ma duże znaczenie przy uruchomieniu całego klastra i oraz przy jego rozbudowie o kolejne wezły, ale w ramach wykonywanego testu nie dało się zauważyć jakiejś jej szczególnej funkcji. W ramach VxRail mamy kilka dodatkowych licencji i funkcjonalności których jednak nie przetestowaliśmy… Co zatem tak naprawdę testowaliśmy? Testowaliśmy Vmware vSAN! Zatem cała trudność jest w określeniu co i jak testujemy. Już nie ma łatwego odróżnienia platformy z maszynami wirutalnymi, od produktu, który testujemy (storage rozproszony), wszystko jest ze sobą bardzo ściśle powiązane i zintegrowane, wszelkie różnice zacierają się. Jak ocenić wpływ jednego środowiska na drugie a drugiego na pierwsze. Nie da się oddzielić platformy testowanej od platformy która jest testowana, tu wszystko przenika się i nie daje się rozdzielić. Ale w tym właśnie jest siła tego produktu.

W dobie automatyzacji, upraszczania i programowego definiowania wszystkiego, vSAN będący częścią produktu vSphere doskonale się wpisuje w obecne trendy rynkowe. Przejęcie funkcji macierzy dyskowych zwiększa elastyczność upraszcza zarządzanie oraz rozbudowę. Nowe funkcjonalności dodawane z każdą wersję czynią rozwiązanie coraz lepszym i ciekawszym. Problemy z platformą sprzętową już nie są przeszkodą, dzięki możliwości zakupu gotowego produktu jakim jest VxRail. Kwestią dyskusyjną jest opłacalność i wymaga przeanalizowania przez każdego indywidualne. Im więcej czynników weźmiemy pod uwagę, w szczególności tych których zwykle się nie dostrzega, tym bym wyraźniej widać dlaczego rozwiązanie hiperkonwergentne tak zyskują na popularności. Jeden dostawca, jeden punkt kontaktu, łatwość zarządzania i rozbudowy te wszystkie czynniki decydują o tym jak szybko użytkownik takiego rozwiązanie może reagować na zmiany na rynku i wdrażać nowe produkty nie czekając na kolejną długotrwałą rozbudowę środowiska.