Simplivity – cz. V

Dziś przed Wami artykuł, który jest przedrukiem z magazynu IT Professional opublikowanym oryginalnie w kwietniu 2016 roku. Niektóre dane nie są najświeższe, ale nie chcieliśmy aby tyle dobrego się zmarnowało. Planujemy wraz z SimpliVity odświeżenie cyklu na początku 2017 – nowe modele, funkcjonalności, zarządzanie. tymczasem zapraszamy na lekki powrót do przeszłości. Po zapoznaniu się z historią firmy, architekturze rozwiązaniu i próbach zdestabilizowania rozwiązania SimpliVity przyszedł czas aby jego działanie przetestować w praktyce. Z poprzedniej części wiemy już o innowacyjnym podejściu do architektury, procedurze instalacji, jakie awarie rozwiązanie przetrwa a jakich nie. Co nowego w wersji 3? Zanim przejdziemy do kolejnych testów warto wspomnieć o wydaniu trzeciej wersji Omnistack i kilku nowościach, które się razem z nią pojawiły:

• Deployment Manager oraz auto discovery – do tej pory instalacja systemu, szczególnie, gdy składał się on z wielu węzłów, była mozolna i czasochłonna. Konieczność dodawania węzłów do federacji jeden po drugim, także nie była budziła entuzjazmu. W nowej wersji procedura została uproszczona i zautomatyzowana, co zminimalizowało możliwości popełnienia błędu. Proces został skrócony, dzięki możliwości równoczesnego instalowania wielu węzłów w tym samym czasie. Zniknęła konieczność żmudnej konfiguracji sieci wirtualnej na hostach ESXi. Nowy Deployment Manager samodzielnie skonfiguruje zarówno standardowe, jak i rozproszone przełączniki. W przypadku rozbudowy federacji wymagane czynności administracyjne także zostały zminimalizowane dzięki funkcji auto discovery – federacja samodzielnie wykryje, skonfiguruje i dołączy nowo wykryty węzeł.
• Nowe możliwości zarządzania kopiami bezpieczeństwa – w poprzedniej wersji, aby zmienić politykę backupu, należało najpierw skasować starą i dopiero potem utworzyć nową od podstaw. Teraz można edytować istniejącą. Kolejna nowość to możliwość ustawienia czasu ważności kopii zapasowych (retention time), nawet tych wykonanych samodzielnie – wcześniej tego typu kopie można było kasować tylko ręcznie.
• Przywracanie z backupu pojedynczych plików – wprawdzie Omnistack nie ma problemów z szybkim przywracaniem nawet dużych maszyn wirtualnych, jednak użycie tej funkcji dla odzyskania jednego pliku nie było zbyt ekonomiczne. Teraz, gdy chcemy odzyskać dane o wielkości poniżej 4 GB (dokładnie – poniżej pojemności jednowarstwowej płyty DVD), możemy dla dowolnej maszyny wirtualnej uruchomić kreator Wskazując potrzebny backup, wybieramy odtwarzanie plików/folderów, następnie wskazujemy wymaganie dane. Ostatecznie, wskazane dane są zamontowane do maszyny wirtualnej jako obraz DVD..
• Nowy model CN-1200 – wprowadzono mody nowy model OmniCube przeznaczony dla oddziałów dużych firm, w których wydajność nie jest krytyczna, za to zaimplementowana jest topologia gwiazdy (hub and spoke). Dzięki automatycznemu wykrywaniu topologii, Deployment Managerowi, oraz funkcji auto discovery uruchomienie takiego węzła jest szybkie i nie wymaga dużego nakładu administracyjnego w oddziale.

Specyfikacja techniczna nowego modelu CN-1200

Zastosowanie docelowe	Zdalne biuro, oddziały firmy (do 20 maszyn wirtualnych).
Pojemność RAW	2 × 400 GB SSD, 4 × 1 TB HDD
Pojemność efektywna	3 – 6 TB
CPU	Intel E5-2650v2 CPU (2.6GHz ), 8 rdzeni / gniazdo
Pamięć RAM	50 – 82 GB
Połączenia sieciowe	Dual 1GbE port RJ45 Dual 10GbE port SFP+
Masa	32,4 kg
Wymiary	3,43” x 17,5” x 28,5”
Zasilanie	Podwójne, redundantne, o mocy 750 W

SimpliVity gwarantuje użytkownikom swojego rozwiązania 90-procentową oszczędność przestrzeni dyskowej (w przypadku wykorzystania zintegrowanej funkcji backupu – kopii bezpieczeństwa wykonywanych codziennie, przechowywanych przez 30 dni, przy założeniu 5 procentowej dziennej zmienności danych i miesięcznego przyrostu danych nie przekraczającego 30%) oraz maksymalnie jedną minutę na wykonanie backupu/odtworzenia maszyny wirtualnej z 1 TB danych (jednak bez wykorzystania mechanizmów VSS zapewnianych przez system maszyny wirtualnej).

Storage HA

Każda maszyna wirtualna jest chroniona przez mechanizm Storage HA, zapewnia on aktualność danych w maszynach wirtualnych znajdujących się w węźle zapasowym. Niestety może się zdarzyć, że mechanizm ma „opóźnienie” i przez jakiś czas maszyny nie są chronione. Podczas testów, po sklonowaniu dwóch maszyn wirtualnych, nie były one zabezpieczone mechanizmem Storage HA, niezbędne było ich zsynchronizowanie (rysunek 1). Awaria węzła, który posiada nieaktualne dane, mogłaby doprowadzić do utraty danych. Być może warto aby producent wprowadził mechanizmy, które nie dopuszczałyby do powstawania okresów braku redundancji dla nowych danych w federacji (rys. 1).

Wydajność dyskowa federacji

Wszelkie dane przechowywane przez OmniCube zapisywane są na dyskach twardych (magnetycznych). Dyski SSD służą wyłącznie przyspieszaniu odczytów. Dzięki temu w specyficznej sytuacji, w której wszystkie dane są zbuforowane na dyskach SSD, możemy uzyskać bardzo duże wartości odczytów na sekundę (IOPS). Niestety, dyski SSD przyspieszają wszystkie odczyty, co może doprowadzić do sytuacji, w której bardzo aktywna maszyna wykorzysta całą dostępną na nich przestrzeń, nie pozwalając istotnym (choć mniej aktywnym) systemom na skorzystanie z przyspieszenia operacji odczytu. Oczywiście w takiej sytuacji ważne maszyny lepiej przechowywać w innych węzłach, można także zarządzać przydziałami po stronie VMware… jednak brak takich możliwości po stronie SimpliVity pozostawia pewien niedosyt.

W przypadku operacji zapisu nie możemy liczyć na przyspieszenie, jakie mogą zaoferować dyski SSD, jednak dzięki wbudowanej deduplikacji nie wszystkie dane muszą być zapisywane na dyskach – trafiają tam tylko unikatowe bloki. Dane powtarzające się (w obszarze federacji) nie są zapisywane, zmieniane są tylko metadane z informacjami o nich. Dla zapewnienia wysokiej dostępności danych wszystkie operacje zapisu muszę być przekazanie do drugiego węzła w federacji, w celu ich zabezpieczenia. Każda operacja zapisu wywołana przez maszynę wirtualną obciąża dwa węzły federacji.

Testy wydajności federacji

W przeprowadzonych testach na modelu CN-3400 użyliśmy skryptu, który:

• w pierwszej fazie generuje unikatowe dane, które nie poddają się deduplikacji ani kompresji (rysunek 2, rysunek 4);
• w drugiej fazie kopiuje wygenerowane wcześniej dane (rysunek 2, rysunek 3 oraz rysunek 4);
• w trzeciej fazie generuje dane poddające się kompresji (rysunek 3, rysunek 4).

W fazie (rysunek 2) pierwszej na dyskach twardych zapisywane są dane nie dające się zduplikować. Skutkuje to obciążeniem procesorów OVC w zakresie 25%-50%. Opóźnienie dostępu do dysków utrzymuje się poniżej 10 ms, liczba operacji zapisu waha się z zakresie 500-1100 IOPS. Wynik ten prawdopodobnie odzwierciedla fizyczne możliwości dysków twardych wykorzystanych w tym modelu OmniCube (nie mając dostępu, do wskaźników obciążenie niższych warstw sprzętowych, możemy tak jedynie przypuszczać).

W fazie trzeciej obciążenie procesorów OVC oscyluje w okolicach 75% (rysunek 4), a liczba operacji zapisu w okolicach 1900 IOPS (rysunek 3). W wyniku dostarczania informacji poddających się kompresji, mniej danych wymaga zapisu na dyskach, w wyniku czego są one szybciej zapisywane. Wyższe obciążenie procesorów OVC potwierdza przetwarzanie otrzymywanych danych przez ich fizycznym zapisem.

W fazie drugiej (rysunek 2) opóźnienie odczytu danych utrzymują się poniżej 10 ms, odczyt danych nie sprawia problemu (prawdopodobnie dyski SSD bardzo w tym pomagają), opóźnienie zapisów oscyluje w granicach 30 ms. Obciążenie procesorów OVC potrafiło przekroczyć 90% (rysunek 4), a liczba operacji zapisu przekracza nieznacznie 2000 IOPS. Faza ta jest bardzo ciekawa, gdyż nie następuje tu zapisywanie nowych danych, wszystkie zapisy są duplikatami danych już istniejących. Wydaje się, że większość mocy OVC jest zużywana na odnajdywanie duplikatów i odpowiednie modyfikacje metadanych. Rozwiązanie SimpliVity dysponuje dedykowaną kartą, która zajmuje się akceleracją operacji dyskowych. Zastanawiające jest, że nie jest ona w stanie przejąć całego obciążenia i, niestety, wykorzystywana jest moc obliczeniowa serwera.

Niepokojące jest to, że intensywnie pracująca jedna maszyna wirtualna jest w stanie znacznie obciążyć OVC, być może jest to wąskie gardło tego rozwiązania.

Cena wysokiej dostępności danych

Pamiętamy, że rozwiązanie jest wysoko dostępne i wszystkie operacje zapisów są przekazywane do drugiego węzła w federacji, który odpowiedzialny jest za utrzymanie aktualnej kopii danych.

Warto zwrócić uwagę na zbliżoną charakterystykę obciążenie procesorów w fazie pierwszej i trzeciej. Powodem jest to, że przetwarzane były tylko operacje zapisu. Na obu węzłach były wykonywane takie same operacje, zatem obciążenie także było zbliżone. Inny wykres obciążenia w fazie drugiej wynika z tego, że drugie OVC przetwarza tylko operacje zapisów, zatem nasuwa się wniosek, że operacje odczytu danych zajęły nawet 40% mocy procesora (rysunek 5).

Testy skalowalności

Przyjrzyjmy się zatem jak reaguje środowisko przy jednoczesnym obciążeniu dwóch węzłów federacji (rysunek 6,7,8,9).

Porównując oba testy obciążeniowe (rysunek 10), można zauważyć, że drugi węzeł w federacji nie pozwala na dwukrotne zwiększenie liczby operacji zapisu, maksymalna wartość to około 60%. Sytuacja powinna się poprawiać w miarę dodawanie kolejnych węzłów (przy założeniu optymalnego wyboru węzła backupowego), gdyż każdy z nich będzie obciążony własnym zestawem operacji zapisu (wymagających lokalnego przetworzenie oraz przekazanie do węzła zapasowego) oraz jednym zestawem dla których pełni on rolę węzła zapasowego. Zatem jest szansa uzyskać 100-procentowy wzrost wydajności po dodaniu kolejnych dwóch węzłów (rysunek 11 i 12). Niestety testowany system nie pozwalał na empiryczne potwierdzenie tej tezy. Przy dodawaniu kolejnych węzłów do federacji będzie budowana nowa relacja zabezpieczania danych wykorzystująca kolejne węzły (zatem konfiguracja składające się z pięciu węzłów jest niedopuszczalna, analogicznie jak w sytuacji jednego węzła – brak zabezpieczenia danych). Chcąc uzyskać optymalną wydajność w federacji liczba jej węzłów powinna zatem być wielokrotnością liczby 4.

Zastanawiające jest, dlaczego nie budować „pierścieni”składających się z więcej niż czterech węzłów. Takie działanie wynika z rosnącego prawdopodobieństwa jednoczesnej awarii dwóch węzłów – doszłoby wówczas do utraty danych. Każdy projektant systemów prawdopodobnie doszedłby do innych wniosków – SimpliVity w pierwszej kolejności stawia na bezpieczeństwo.

Przy dalszym zwiększaniu obciążenia wysycamy system całkowicie i uzyskujemy potwierdzenie o osiągnieciu maksymalnych możliwości testowanej federacji (rysunek 13,14,15).

Podsumowanie testów

Generowanie danych na dwóch węzłach trwało 22% dłużej niż na jednym, natomiast generowanie danych na czterech maszynach wirtualnych (dwa węzły Federacji) trwało 109% dłużej niż na jednej oraz 71% dłużej niż na dwóch maszynach wirtualnych. Opóźnienia operacji zapisów utrzymywały się na względnie niskim poziomie (gdy nie było operacji odczytu) Jednak w fazie drugiej (intensywnych odczytów i zapisów) opóźnienia zapisów przekraczały 100ms co może być nie akceptowalne dla usług utrzymywanych przez takie maszyny wirtualne.

W przypadku operacji odczytu, które obciążają tylko jeden węzeł będą one skalować się względnie liniowo przy dodawaniu kolejnych węzłów. Owa względność zależy czy dane te będą pochodziły z dysków SSD czy jednak wymagany będzie odczyt z dysków obrotowych, który oczywiście jest znacznie wolniejszy.

Uzyskane wyniki są ciekawe i obiecujące, choć pewien niedosyt budzi zastosowanie dysków SSD tylko jako bufor odczytu danych. Być może uzyskalibyśmy znacznie wyższe wartości dla operacji zapisu gdyby brały w tym udział dyski SSD. Brak możliwości skonfigurowania, które daną są ważniejsze a przez to utrzymywane na dyskach SSD zmusza szukania innych sposobów priorytetyzacji dostępu maszyn wirtualnych do ich dysków. W kolejnej części przyjrzymy się zachowaniu Federacji, ze zdalnym centrum przetwarzania danych.

Artykuł został opublikowany na łamach IT Professional.