Cisco HyperFlex Hiperkonwergencja od Cisco #3

Marek Sokół

7. czerwca 2018

Reading time: 6 min

Cisco HyperFlex Hiperkonwergencja od Cisco #3

W poprzedniej części artykułu dotyczącej hiperkonwergencji od CISCO skupiliśmy się na wizji rozwoju infrastruktury oraz platformy sprzętowej, którą można znaleźć tutaj, zachęcamy również do przeczytania pierwszej części artykułu. Tym razem w tekście skupimy się na architekturze rozwiązania oraz bezpieczeństwie, zarządzaniu i szacowaniu pojemności.

Architektura rozwiązania

Wszystkie węzły HyperFlex tworzą platformę HX Data, której częścią jest pamięć masową rozproszona pomiędzy poszczególne węzły – można ją skalować poprzez dodawanie dysków w poszczególnych węzłach lub dodawanie węzłów. Współdzielona przestrzeń dyskowa jest dedykowana dla maszyn wirtualnych, zatem w sytuacji wystarczających zasobów dyskowych a braku pozostałych, wymaganych dla maszyn, można platformę skalować serwerami, które będą dostarczać tylko brakujących zasobów, biernie korzystając z przestrzeni dyskowej udostępnianej przez pozostałe węzły.

Zapoznawszy się z budową pojedynczego węzła, ze schematem połączeń w klastrze oraz mając na uwadze, że niedopuszczalne jest, aby pojedyncza awaria mogła doprowadzić do unieruchomienia rozwiązania, przyjrzyjmy się jak działa cała platforma.

Współczynnik replikacji

Pierwszy aspekt, który należy wziąć pod uwagę jest stopień redundancji danych, określany jako Replication Factor (RF), wymagany w środowisku. Domyślnie parametr ten ma wartość trzy, co oznacza minimum trzy węzły w klastrze przechowujące ten sam zestaw danych. W takiej konfiguracji utrata nawet dwóch węzłów nie doprowadzi do utraty danych. Podczas bieżącego utrzymania systemu może zdarzyć się konieczność restartu/wyłączenia jednego z węzłów. W tym czasie nadmiarowość danych w klastrze wynosi tylko dwa, co już wprowadza pewne ryzyko, i zmniejsza odporność na potencjalną awarię. Minimalna wielkość klastra przygotowanego na opisany scenariusz wynosi zatem cztery węzły. Nie każda organizacja jest gotowa ponieść koszty realizacji takich wymagań wysokiej dostępności danych, dlatego dla mniej wymagających klientów dostępna jest trzywęzłowa architektura HyperFlex Edge, a w planach – wspomniana dwuwęzłowa HyperFlex ROBO. Rozwiązanie jest elastyczne w zakresie rozbudowy, którą można przeprowadzić na kilka sposobów, w zależności od potrzeb oraz istniejącego już środowiska. Podstawowym wymaganiem jest, aby każdy węzeł w klastrze miał taką samą konfigurację, nie wspierane są konfiguracje w których są różne ilości dysków w węzłach, różne modele serwerów (1U lub 2U), czy mieszanie węzłów all flash z hybrydowymi.

W sytuacji gdy w klastrze brakuje przestrzeni dyskowej (lub wydajności dla zapisów/odczytów) dodajemy dyski równomiernie do wszystkich węzłów, albo dodajemy nowe węzły.

Gdy mamy dostępne inne pamięci masowe, możemy nimi wesprzeć środowisko – możliwe jest dołączenie zewnętrznych zasobów z infrastruktury optycznej jaki i sieciowej (iSCSI czy NFS). Konwergentne połączenie pomiędzy węzłami oraz Fabric Interconectami pozwalają na dostęp do wspomnianych zasobów bez potrzeby fizycznej instalacji nowych połączeń.

Przy braku tylko zasobów obliczeniowych nie jesteśmy zmuszeni rozbudowywać klastra o kolejny węzeł, możemy podłączyć standardowe serwery Cisco do hiperkonwergentnej przestrzeni dyskowej klastra. Operacja ta wymaga instalacji modułu IO Visor na dodatkowych serwerach ESXi, natomiast dostęp do danych jest całkowicie realizowany przez sieć.

Przechowywanie danych

Trzykrotne utrwalanie tych samych danych na różnych węzłach klastra niesie za sobą spory koszt wykorzystanej przestrzeni – wydaje się, że wykorzystujemy zaledwie jedną trzecią surowej przestrzeni klastra. Z jednaj strony jest to cena bezpieczeństwa danych, z drugiej jednak Cisco zaimplementowało mechanizm deduplikacji i kompresji uruchamiany przy przenoszeniu na dyski warstwy danych. Mechanizm ten optymalizuje wykorzystanie przestrzeni dyskowej poprzez wyszukiwanie powtarzających się bloków danych, a w sytuacji próby zapisu utrwalana jest tylko informacja o takim fakcie, samych danych nie ma potrzeby ponownie zapisywać. Mechanizmem uzupełniającym jest kompresja o zmiennym bloku, co pozwala jeszcze bardziej zoptymalizować wykorzystanie przestrzeni dyskowej w klastrze. Technologia ta jest skuteczna i minimalnie obciąża system, dlatego Cisco zdecydowało, że oba mechanizmy będą zawsze włączone i nie ma możliwości ich wyłączenia. Obowiązuje to w każdej wersji sprzętowej, włączając wersje hybrydowe i all flash.

Oprócz oszczędności miejsca wspomniane mechanizmy przyczyniają się do znacznego przyśpieszenia takich operacji jak klonowanie maszyn wirtualnych, co wynika z tego, że w trakcie pracy mechanizmu deduplikacji operacja klonowania generuje nowe informacje o danych, lecz same dane nie ulegają zmianie. Dzięki własnemu systemowi plików, który realizuje przechowywanie danych, rozwiązanie oferuje możliwość zastąpienia migawek VMware, na mechanizm oferowany przez HyperFlex, który bazuje na wskaźnikach. Mechanizm ten znany jest z rozwiązań producentów macierzy dyskowych i pozwala na wydajniejszy dostęp do danych. Nowe dane wymagające zapisu są w pierwszym kroku dostarczane do wymaganej liczby węzłów (zgodnie ze współczynnikiem RF), po potwierdzeniu zapisu przez wszystkie węzły, zapis jest potwierdzany do maszyny wirtualnej. Wspomniane zapisy trafiają do warstwy buforującej – na dyski SSD. W kolejnym kroku dane te są poddawane deduplikacji i kompresji, by w takiej formie zostały zapisane na dyskach warstwy przechowywania danych. W wersji hybrydowej są to dyski magnetyczne, lecz w wersji all flash są to także dyski SSD.

W przypadku odczytów danych z klastra proces zależy od dysków w warstwie przechowywania danych, jeżeli są to dyski SSD, dane czytane są zawsze bezpośrednio z nich, w przypadku rozwiązań hybrydowych w pierwszym kroku następuje skopiowanie danych do warstwy buforującej, a następnie udostępniane są one maszynie wirtualnej. Taka różnica w realizacji odczytów pokazuje bardzo istotną różnicę w zastosowaniu dysków buforujących – w wersjach all flash buforują tylko zapisy, w wersji hybrydowej buforują także odczyty. Większy bufor zapisu już na etapie architektury wskazuje na większy potencjał wersji opierającej się wyłącznie na dyskach SSD.

width=

Rys. 5 Proces zapisu nowych danych rozpoczyna się od przeprowadzenia równoległej operacji zapisu na wymaganą liczbę węzłów w klastrze, w tej sytuacji są to dwa węzły (RF = 2). Po zapisie danych przez wszystkie węzły na ich dyskach SSD (lub pamięci NVMe), następuje niezależnie proces deduplikacji i kompresji nowych danych. W ostatnim kroku dane trafiają na dyski warstwy przechowywania danych. Zapisy do maszyn wirtualnych potwierdzane są już po zapisie na dyskach SSD, zatem proces deduplikacji i kompresji nie stanowi wąskiego gardła dla operacji zapisu danych. Podobnie jest z szyfrowaniem danych na dyskach, który wykorzystuje napędy ze sprzętowym szyfrowaniem.

Rozwiązanie Cisco nie koreluje miejsca przechowywanie danych z węzłami, na których pracują korzystające z tych danych maszyny wirtualne. Zapisy czy odczyty przez sieć nie są unikane, a nawet preferowane w sytuacji, gdy zdalny węzeł w swojej warstwie buforującej posiada poszukiwane dane, odczyt przez sieć ma mniejszy koszt niż napełnienie bufora kolejnego węzła danymi z warstwy przechowywania. Takie podejście nie wymaga dodatkowej integracji i zabiegów optymalizacyjnych w przypadku przeniesienia maszyn wirtualnych na inny węzeł, bez względu na to czy proces jest ręczny, czy wynika z działania mechanizmu DRS. Dane jednej maszyny wirtualnej są równomierne rozkładane po całym klastrze, zatem nie pojawia się ryzyko powstawanie lokalnych przeciążeń, a dodawanie nowych węzłów do klastra daje potencjał na liniowy wzrost wydajności dla pojedynczej maszyny wirtualnej i dla wszystkich maszyn w klastrze.

Wysoka dostępność

Nadmiarowość danych w klastrze zapewnia ich bezpieczeństwo oraz dostępność w sytuacji pojedynczych awarii dowolnego komponentu. Domyślnie tak długo, jak długo dostępna jest chociaż jedna kopia danych, te są udostępniane – tryb ten jest nazywany lenient i jest wykorzystywany przez firmy które preferują dostępność danych nawet kosztem ryzyka pracy na ich pojedynczej kopii. Dla firm nie akceptujących takiego ryzyka dostępny jest tryb strict, w którym klaster przechodzi w tryby tylko do odczytu w sytuacji braku możliwości zapewnienia wymaganej nadmiarowości danych.

Niezależne od tryby lenient działa w klastrze mechanizm wymaganej dostępności większości węzłów w klastrze. Dla klastrów pięciowęzłowych utrata dwóch węzłów nie jest problemem, gdyż większość czyli trzy nadal jest dostępna, lecz dla klastrów czterowęzłowych utrata dwóch węzłów powoduje przejście w tryb tylko do odczytu. Takie podejście pokazuje, że producent kładzie bardzo duży nacisk na bezpieczeństwa przechowywanych danych. Należy jednak pamiętać, że dla najmniejszych, czterowęzłowych klastrów, wyłączenie jednego węzła dla celów administracyjnych oraz wystąpienie awarii w kolejnym węźle spowoduje wstrzymanie pracy wszystkich maszyn w klastrze.

W przypadku awarii dysku twardego z warstwy przechowywania danych, po upływie minuty, rozpoczyna się proces odbudowy wymaganej nadmiarowości danych w klastrze. Odbudowie podlegają dane zawarta na uszkodzonym dysku, a w procesie uczestniczy cały klaster. Odbudowa jest znacznie szybsza niż w klasycznych konfiguracjach RAID, gdzie następuje na zapasowy/wymieniony dysk i obejmuje cały obszar dysku, bez analizy ile faktycznie danych się na nim znajdowało.

Warto zwrócić uwagę na scenariusz, w którym w odstępie jednej godziny następują kolejne awarie dysków w klastrze – jak długo w klastrze jest wolne miejsce na dyskach, kolejne awarie nie będą wpływać na bezpieczeństwo danych. W sytuacji gdy awarii ulega dysk SSD z warstwy buforującej, rolę tego dysku przejmują dyski z innych węzłów w klastrze, natomiast gdy jest to dysk wymagany do pracy kontrolera wirtualnego, wówczas tracony jest dostęp do wszystkich lokalnych danych. Pracujące na danym węźle maszyny wirtualne nadal uzyskują dostęp do swoich dysków poprzez pozostałe węzły w klastrze. Najpoważniejsza w skutkach jest awaria całego hosta ESXi, gdyż maszyny wirtualne, które na nim działały muszą być uruchomiane na innych węzłach. Niedostępność węzła może wynikać z prac administracyjnych, dlatego odbudowa wymaganej nadmiarowości danych, domyślnie następuje po dwóch godzinach. W wyniku awarii może dojść do nierównomiernego rozmieszczenia danych w klastrze, co może mieć wpływ na wydajność dostępu do danych, lecz wyrównanie rozmieszczenia jest także bardzo obciążające dla klastra, dlatego proces ten jest uruchamiany w porze najmniejszego obciążenie klastra, ewentualnie może być uruchomiony ręcznie.

Bezpieczeństwo, zarządzanie i szacowanie pojemności

W sytuacji gdy wymagane jest szyfrowanie danych, a następowałoby ono na poziomie maszyn wirtualnych, utracone zostałyby korzyści z mechanizmu deduplikacji i kompresji, dlatego jeśli wymagamy tego typu zabezpieczeń możemy uruchomić szyfrowanie na poziomie dysków twardych. Zastosowanie dysków twardych, które samodzielne szyfrują dane, nie prowadzi do spadku wydajności całej platformy, jednak powoduje wzrost kosztów. Po implementacji tego typu rozwiązania pojawia się potrzeba zarządzania kluczami szyfrującymi. Mamy tu do dyspozycji dwie możliwości: klucze można przechowywać lokalnie, co może być trudne w utrzymaniu, lub za pomocą oprogramowania firm trzecich. Takie oprogramowanie stanowi, niestety, dodatkowy koszt, lecz bezpieczeństwo i łatwość zarządzania może go rekompensować.

Inną funkcją pozwalającą zwiększyć bezpieczeństwo przechowywanych danych jest możliwość uruchomienia replikacji pomiędzy klastrami HyperFlex. Podstawowym wymaganiem jest taka sama architektura klastrów – nie jest możliwa replikacja klastra hybrydowego do all flash i odwrotnie. Oferowana replikacja jest asynchroniczna i bazuje na migawkach maszyn wirtualnych przekazywanych do drugiego centrum przetwarzania danych, minimalna częstotliwość wynosi 15 minut, a dostępna jest zawsze tylko najnowsza kopia maszyny wirtualnej. W celu automatyzacji procesu możliwa jest integracja z oprogramowaniem firm trzecich.

Produkty dobrze integrujące się z rozwiązaniem VMware udostępniają możliwości zarządzania z konsoli webowej vCenter. Nie inaczej jest w tym przypadku. Niestety, klient VMware wciąż wymaga technologii Flash, a nowa wersja klient bazująca na technologii HTML5, nie jest jeszcze w pełni funkcjonalna. Integracja z konsolą VMware jest ważna, jednak w pewnych sytuacjach lepiej się sprawuje konsola dedykowana – HyperFlex Connect. Z funkcji dostępnych tylko z poziomu konsoli HyperFlex można wymienić konfigurację replikacji, szyfrowania, powiadomień producenta oraz uprawnień. Istnieją jednak funkcje dostępne tylko z konsoli vCenter i jest to zarządzanie migawkami macierzowymi oraz praca na wielu klastrach. Pozostałe opcje dostępne są za pomocą obu konsol. Integracja macierzowych migawek maszyn wirtualnych jest bardzo głęboka i zastępuje ona mechanizm VMware, rozwiązanie takie rodzi potencjalne problemy, gdyż wykonując migawkę nie mamy możliwości wyboru technologii, przez co w chwili wykonanie me ma pewności, który mechanizm jest wykorzystany. Do klonowania maszyn wirtualnych można użyć standardowego mechanizmu VMware lub skorzystać z dedykowanego menu pozwalającego wykonywać masowe klonowanie maszyn.

W przypadku klientów zainteresowanych oszacowaniem wymaganej wielkości klastra dla własnych potrzeb Cisco przygotowało odpowiedni narzędzia dostępne pod adresem hyperFlexsizer.cloudapps.cisco.com (wymagana rejestracja). Jeżeli chcielibyśmy zebrać statystyki z własnego środowiska uruchamiamy w nim moduł profiler, z którego dane możemy wprowadzić do modułu sizer. Taka analiza pozwoli oszacować potencjalną wielkość środowiska HyperFlex będącego w stanie obsłużyć to aktualnie uruchomione. Jeżeli nie możemy uruchomić analizy w środowisku, możemy wykorzystać standardowe szablony obciążeń do oszacowania rozmiaru, jednak wyniki te powinny być traktowane jedynie jako wstępny szacunek.

Dostawcy dostępnych na rynku rozwiązań hiperkonwergentnych domyślnie zakładają, że sieć jest odpowiednio skonfigurowana i działa z maksymalną wydajnością. Sami nie dostarczają sprzętu sieciowego ani narzędzi głęboko integrujących ich produkty z rozwiązaniami sieciowymi. Może to prowadzić do minimalizacji korzystania z transmisji sieciowych na rzecz lokalnych operacji na węźle lub innych optymalizacji mających na celu uniknięcie potencjalnych problemów z siecią. Cisco – firma z sieciowym rodowodem oferująca serwery USC – jest w stanie zaproponować rozwiązanie kompleksowe, zawierające serwery, sieć oraz odpowiednie oprogramowanie do budowy rozproszonej pamięci, nie obarczone ryzykiem pracy w niezarządzanym obszarze. System HyperFlex dostępny na rynku niecałe dwa lata spotyka się z dużym zainteresowaniem, a bardzo szybki rozwój i udostępniane nowe możliwości pozwalają sądzić, że nie zatrzyma się on nagle w miejscu. Można mieć nadzieję, że w niedługim czasie udostępnione zostaną kolejne funkcje, zaspokajające potrzeby jeszcze niezdecydowanych użytkowników. Szybki rozwój tego segmentu rynku jest podyktowany rosnącymi wymaganiami firm, które z różnych powodów nie chcą migrować do infrastruktury chmury publicznej, a poszukujących rozwiązań, które pozwolą pozostawać równie elastycznymi i szybkimi w nowych wdrożeniach. Z powyższych powodów możemy spodziewać się bardzo szybkiej rozwoju tego obszaru technologii, dlatego warto ją monitorować. Każda duża zmiana w infrastrukturze, warto aby była skonfrontowana z architekturą hiperkonwergentną – być może już czas zmienić podejście przy budowaniu własnego centrum przetwarzania danych.

Artykuł został opublikowany na łamach IT Professional.

Poniżej znajdą Państwo linki do wcześniejszych artykułów: