Netapp HCI #2

Spojrzenie na SolidFire

SolidFire, który był projektowany pod kątem pracy wyłącznie z dyskami SSD, nie ma żadnych kompatybilności wstecznych dla dysków obrotowych, dodatkowo dzięki przewidywalności wydajności dysków SSD NetApp gwarantuje ilość operacji IO, jakie dostarcza pojedynczy węzeł – w testowym środowisku było to 50 tys. IOPS dla bloku 4k na jeden węzeł, zatem testowany klaster jest w stanie dostarczyć 200 tys. IOPS. Kolejna unikalna funkcjonalność to QoS, w ramach którego deklaruje się minimalną, maksymalną, oraz tymczasową (z ang. burst) wartość IOPS dla wolumenów. Funkcjonalność pozwala panować nad zróżnicowanym obciążeniem mogącym znaleźć się w klastrze, gwarantując wydajność tam, gdzie jest to potrzebne. Funkcjonalność ta umożliwia lepsze panowanie nad pracą środowiska oraz planowanie jego wzrostu. W ramach optymalizacji wykorzystania zasobów dyskowych klastra, włączona jest deduplikacja, jak i kompresja. Optymalizacje te nie tylko mają na celu zwiększenie użytecznej pojemności klastra, lecz jednocześnie zmniejszają częstość zapisów danych na dyskach SSD, czym przyczyniają się do przedłużenia ich żywotności. Proces zapisu danych do klastra wygląda następująco:

– węzeł obsługujący dany wolumen dzieli otrzymaną porcję danych na bloki wielkości 4 kB i następnie je kompresuje

– skompresowane bloki trafiają do pamięci NVRAM węzła oraz są synchronicznie replikowane do innego węzła w klastrze

– potwierdzenie zapisu danych do maszyny wirtualnej jest wysyłane dopiero po potwierdzeniu zapisu bloków w pamięci NVRAM przez oba węzły SolidFire, do których zostały przesłane żądania zapisu

– obliczany jest hash z zapisanych danych i następuje sprawdzenie czy taki blok już w klastrze istnieje

– jeżeli blok istnieje, zapisywane w klastrze są tylko informacje w obszarze metadanych, a sam blok jest kasowany

– jeżeli jest to nowy blok, następuje jego zapis na dwóch węzłach klastra

Liczba kopii w jakich przechowywane są dane w klastrze nie jest konfigurowalna. SolidFire udostępnia dane za pomocą protokołu iSCSI, unikalna właściwość tego protokołu pozwala na zapewnianie równoważenia obciążenia oraz odporność na awarie węzła. W klastrze, węzeł, który pełni rolę mastera udostępnia na wirtualnym adresie IP dostęp do zasobów wspomnianym protokołem iSCSI. Rozpoczyna się proces negocjacji połączenia, w którym klient wskazuje adres wolumenu, do którego chce się połączyć. Po ustaleniu niezbędnych szczegółów klient otrzymuje komunikat target temporaty moved oraz nowy, właściwy adres IP. Następnie ponawia logowanie do nowego węzła, który obsługuje ruch do danego woluminu. Jeżeli dany węzeł jest przeciążony i inny przejmie ruch danego woluminu, następuje wylogowanie klienta, ten wraca do wirtualnego adresu mastera (gdyż komunikacja z danym węzłem z założenie była tymczasowa, zatem nie następuje ponowna próba logowania do niego). Tam uzyskuje informacje o nowym węźle, do którego powinien się udać. Podobny scenariusz następuje w przypadku awarii węzła, klient po upływie wymaganego czasu nie ponawia próby komunikacja z węzłem, który przestał odpowiadać tylko wraca do węzła master, który w między czasie wyznacza nowy węzeł odpowiedzialny za wolumin. Wykorzystanie standardowych możliwości protokołu pozwala w łatwy sposób udostępniać zasoby klastra na zewnątrz środowiska, co ważne, nie wymaga to instalacji dodatkowych sterowników ani komponentów.

W najnowszej wersji NetApp HCI (1.4), pojawiła się funkcjonalność domen protekcji, wymaga ona przynajmniej trzech obudów, równomiernie wypełnionych serwerami, a w każdej obudowie wymagane są przynajmniej dwa węzły storage. Zaletą tej funkcji jest zabezpieczenie przed awarią całej obudowy, w tym wszystkich serwerów w niej zawartych. W poprzedniej wersji możliwe było, że obie kopie porcji danych mogą się znaleźć na dwóch serwerach w jednej obudowie. W dużych środowiskach mogą natomiast się pojawić potrzeby uodpornienia się na awarie całej szafy rack.

Możliwości

Dla wygodnego zarządzania środowiskiem, do interfejsu webowego vCenter jest doinstalowana wtyczka dająca bardzo szerokie możliwości konfiguracji Solidfire. Dodatkowo w środowisku znajduje się dodatkowa maszyna wirtualna (mNode) odpowiedzialna za:

– wtyczkę NetApp HCI do vCenter

– agenta monitorującego SolidFire

– kolektor danych przekazywanych do Active IQ – portalu odpowiedzialnego za zbieranie i przetwarzanie danych z systemów klientów

– zestawienie tunelu VPN dla wsparcia SolidFire

– aktualizację środowiska

Oprócz zarządzania z vCenter, SolidFire udostępnia swój interfejs, do którego można się zalogować celem zarządzania rozwiązaniem.

W ramach zarządzania środowiskiem, rozwiązanie udostępnia możliwość wykonywania snapshotów dla pojedynczych wolumenów, jak i dla kilku jednocześnie. Wspomnianą migawkę można wywołać ręcznie lub utworzyć harmonogram. Posiadając kilka klastrów SolidFire można skonfigurować replikację pomiędzy nim. Obsługiwane rodzaje replikacji to synchroniczna, asynchroniczna, oraz replikacja snapshotów. W przypadku posiadania innych produktów NetApp, istnieje możliwość skonfigurowania replikacji snapshotów pomiędzy SolidFire a ONTAP. W ramach konfiguracji wolumenów niezbędne jest zdefiniowanie polityki QoS do niego przypisanej, wartość minimalna IOPS nie może przekroczyć 15 tys. – ograniczenie producenta. W przypadku umieszczenia na woluminie większej ilości maszyn wirtualnych, będą one rywalizować ze sobą o zasoby, aby zatem zagwarantować maksymalną wartość IOPS dla jednej maszyny, należy utworzyć dla niej dedykowane wolumin.

Trudno oprzeć się wrażeniu, że zarządzanie na poziomie woluminów może być nie efektywne, gdyż to maszyny wirtualne są głównym użytkownikiem tych zasobów. Nie ma jednak potrzeby tworzyć osobnych woluminów dla każdej maszyny, w środowiskach gdzie potrzebujemy takich funkcjonalności wystarczy aktywować mechanizm VVol dostępny w SolidFire. Po jego aktywacji (nie można już go potem wyłączyć) i utworzeniu wymaganego kontenera, politykami QoS zarządzamy przez polityki VVol definiowane w vCenter. Od tego momentu zarządzanie snapshotami i politykami QoS następuje na poziomie pojedynczej maszyny wirtualnej, co prowadzi nas do środowiska konfigurowanego pod kątem maszyny wirtualnej. Jeżeli jednak ktoś woli klasyczne zarządzanie, nadal jest to możliwe, nic nie stoi na przeszkodzie aby w ramach jednego klastra SolifFire część maszyn było umieszczonych w kontenerze VVol, a część na klasycznych datastoreach. Zarządzanie nie jest ograniczone do interfejsów graficznych, udostępnione są moduły do PowerShell, którymi możemy automatyzować operacje, dla bardziej wymagających środowisk, można wykorzystać do automatyzacji REST API.

Ostatnim elementem wartym wspomnienia jest monitorowanie wskaźników wydajnościowych ze środowiska. Standardowo w ramach interfejsu dostępne są statystki za ostatnie minuty, lecz nie pozwolą one na analizę zmiany obciążenia w środowisku za dłuższy okres. Jedną z możliwości jest przesyłanie statystyk do serwisu Active IQ, gdzie można monitorować trendy. W sytuacji gdzie nie możemy z tego serwisu korzystać, lub dostępne tam statystyki wydają się niewystarczające, możemy wykorzystać HCICollector. Na stronach NetAppa można znaleźć szczegółową instrukcję jak korzystając z tego otwartego oprogramowania przygotować monitorowanie klastra SolidFire.

Podsumowanie

Na tym kończymy opis możliwości i architektury rozwiązania dostarczonego przez NetApp, godny uwagi jest sposób rozwiązania problemów wydawałoby się nierozerwalnie związanych z HCI, jakim jest wykorzystywanie zasobów (głównie CPU) na potrzeby obsługi współdzielonej pamięci masowej. Podejście pozwalające wykorzystywać uniwersalny serwer, a w razie potrzeby dokupować dodatkowe zasoby, pozwala sądzić, że przyjęło się na rynku. Jednak głównym katalizatorem jego adaptacji jest uproszczenie, nawet kosztem „transakcji wiązanych” podczas rozbudowy. Być może dotychczasowy model operacyjny HCI, za kilka lat rzeczywiście zostanie nazwany pierwszą generacją, podczas gdy model proponowany przez NetApp stanie się obowiązującym. Na tym etapie trudno wyrokować, a ewentualna analiza musiałaby zawierać bardzo wiele czynników, od czasu zespołów operacyjnych i architektów, przez koszt nieoptymalnych rozbudów klastra, kończąc na wygenerowanych zakupami infrastruktury, dodatkowe koszty licencji w warstwie maszyn wirtualnych. Inną przeszkodą jest potencjalne wyjście z rozwiązań HCI, które zostały niedawno już zakupione. Rozstrzygający głos wydaje się należeć do klientów, którzy nie weszli jeszcze na ten rynek, to ich wybory w dużej mierz będą decydować czy wspierany będzie klasyczny model HCI, czy może ten proponowany na bazie platformy SolidFire.

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

Część I

Część II

Część III

Część IV

Część V