Cisco HyperFlex Hiperkonwergencja od Cisco #6

W tym wpisie głównym zagadnieniem będzie praca z klastrem. Po zapoznaniu się z możliwościami interfejsów graficznych, przejdziemy do pracy z systemem HyperFlex. Zweryfikowaliśmy zajętość poszczególnych dysków twardych w klastrze, po czym wygenerowaliśmy nowe dane, w ramach jednej maszyny wirtualnej. Zajętość danych wzrosła równomiernie na wszystkich dyskach twardych. Spodziewaliśmy się takiego zachowania, gdyż jest ono zgodne z opisem przedstawionym w poprzedniej części artykułu. Taka architektura zapisu danych w klastrze teoretycznie jest w stanie zapewnić pełną wydajność zapisów i odczytów już dla pojedynczej maszyny wirtualnej.

Generowanie obciążeń

Następny test polegał na uruchomieniu takich samych obciążeń kolejno na jednym, dwóch oraz czterech węzłach w klastrze jednocześnie. Dobrane obciążenia mają na celu maksymalne wysycenie klastra operacjami zapisu i odczytu, przez co nie przypominają obciążeń spotykanych w środowiskach produkcyjnych. Test ma natomiast na celu sprawdzenie jak się zachowuje klaster przy wzroście obciążenia. Testy przeprowadziliśmy na obu dostępnych zestawach: hybrydowym oraz all flash.

Rys. 4. Wykresy obciążenia klastra hybrydowego. Z lewej strony widać fragment obciążenia wygenerowanego przez jedną maszynę wirtualną w środku dwoma, z prawej strony widoczny jest wykres oraz jedna próbka danych z pracy czterech maszyn wirtualnych. Sam test składał się z trzech faz, najpierw generacja unikalnych danych nie poddających się deduplikacji, w drugim etapie miało miejsce kopiowanie danych wygenerowanych w pierwszej fazie, w trzeciej fazie generowany były dane dobrze poddające się kompresji.

Uzyskane podczas testu wyniku są następujące:

• generowanie danych na klastrze all flash w każdym rodzaju testu odbywało się około 1,5 raza szybciej niż w przypadku konfiguracji hybrydowej;
• przy dodawaniu maszyn wirtualnych biorących udział w teście wzrost czasu generowania danych był taki sam dla klastra all flash i hybrydowego, np. czas generowania danych przez dwie maszyny jednocześnie był dłuższy o 25% na obu platformach w stosunku do czasu wymaganego dla jednej maszyny;
• czas generowania danych przez cztery maszyny był dłuższy o 110% w stosunku do czasu jednej maszyny i o 70% w stosunku do czasu dwóch maszyn.

Wyniku testu pokazują, że zastosowana maszyna wirtualna nie była w stanie samodzielnie wysycić całego klastra, prawdopodobnie wynika to z wąskich gardeł na którejś warstwie wirtualizacji. Dopiero zastosowanie większej liczby maszyn pozwoliło zweryfikować maksymalne parametry dla takich charakterystyk obciążenia możliwych do uzyskania na badanym rozwiązaniu. Warta odnotowania jest powtarzalność doświadczenia, jedną z jej przyczyn z pewnością jest udział wszystkich dysków klastra w zapisie danych, w wyniku czego nie dochodzi do sytuacji, gdzie jeden dysk jest intensywniej wykorzystywany od innych. Zastanawiać może to, że klaster typu all flash był szybszy od rozwiązania hybrydowego tylko 1,5 raza. Wynika to najprawdopodobniej z faktu, że większość obciążenia przejmowały dyski SSD z warstwy buforującej, być może jest to kwestia wydajności tych właśnie dysków. Możliwe też, że dyski SSD w klastrze all flash są dla zastosowanego obciążenie właśnie 1,5 raza wydajniejsze od dysków SSD zastosowanych w klastrze hybrydowym.

Kasowanie danych

Po zakończeniu testów skasowano część danych w klastrze, usuwając całe maszyny wirtualne. Pomimo rozproszonego systemu plików operacja ta nie wymagała długich przeliczeń i dodatkowe wolne miejsce na datastore było od razu dostępne.

Klonowanie maszyn i tworzenie migawek

Datastore udostępniany systemom ESXi widoczny jest jako wolumen NFS, a pliki-dyski maszyn wirtualnych można tworzyć jako tak zwane cienkie lub grube. Fakt ten jest monitorowany przez rozwiązanie i odpowiednio raportowany w widoku maszyny wirtualnej.

Przetestowaliśmy mechanizm masowego klonowania maszyn wirtualnych. Wykorzystaliśmy funkcję Ready Clone – zdefiniowaliśmy stukrotne wykonanie kopii maszyny oraz włączenie każdej z nich. Klon setnej maszyny był gotowy, a sama maszyna w pełni wystartowana po upływie niewiele ponad minuty. Tak dobry wynik możliwy jest do uzyskania dzięki mechanizmowi deduplikacji oraz buforowania operacji odczytu. Wart uwagi jest również mechanizm migawek. Bazuje on na technologiach macierzowych i według deklaracji producenta jest wydajniejszy od standardowego mechanizmu VMware. Jest jednak mocno zintegrowany ze środowiskiem VMware i właściwie nie występuje osobno. W celu skorzystania z niego maszyna wirtualna nie może mieć migawek. Następnie należy wykonać pierwszą migawkę dostępną w dedykowanym menu HyperFlex. Migawka ta nosi nazwę <<Sentinel>>. Od tej pory nawet migawki wykonane w tradycyjny sposób będą bazować na mechanizmach Cisco, ważne natomiast jest, że tej pierwszej migawki nie wolno ani skasować (chyba że zamierzamy skasować wszystkie), ani cofać do niej stanu maszyny wirtualnej (tylko do stanu zapisanego w migawkach, które nastąpiły po niej).

Artykuł został opublikowany na łamach IT Professional.

Następny wpis dotyczyć będzie testów odporności na awarię, natomiast poniżej znajdą Państwo linki do wcześniejszych artykułów:

• Cisco HyperFlex Hiperkonwergencja od Cisco #1
• Cisco HyperFlex Hiperkonwergencja od Cisco #2
• Cisco HyperFlex Hiperkonwergencja od Cisco #3
• Cisco HyperFlex Hiperkonwergencja od Cisco #4
• Cisco HyperFlex Hiperkonwergencja od Cisco #5
• Cisco HyperFlex Hiperkonwergencja od Cisco #6
• Cisco HyperFlex Hiperkonwergencja od Cisco #7