Kontynuujemy zapoznawanie Państwa z systemem hiperkonwergentnym Cisco HyperFlex.
W kwietniu 2019 roku firma Cisco ponownie organizuje serię demonstracji nowego hiperkonwergentnego rozwiązania Cisco HyperFlex w regionach Rosji i Kazachstanu. Można zapisać się na demonstrację za pomocą formularza kontaktowego, klikając w link. Dołączcie do nas!
Wcześniej opublikowaliśmy artykuł na temat testów obciążeniowych przeprowadzonych przez niezależne laboratorium ESG Lab w 2017 roku. W 2018 roku charakterystyki rozwiązania Cisco HyperFlex (wersja HX 3.0) znacznie się poprawiły. Co więcej, konkurencyjne rozwiązania również nieustannie się rozwijają. Dlatego publikujemy nową, bardziej aktualną wersję porównawczych testów obciążeniowych od ESG.
Latem 2018 roku laboratorium ESG przeprowadziło ponowne porównanie Cisco HyperFlex z konkurencją. Uwzględniając współczesne tendencje w zakresie wykorzystania rozwiązań zdefiniowanych programowo, do analizy porównawczej dodano również producentów podobnych platform.
Konfiguracje testowe
W ramach testowania HyperFlex porównano z dwoma w pełni programowymi systemami hiperkonwergentnymi, które są instalowane na standardowych serwerach x86, a także z jednym rozwiązaniem hybrydowym. Testy przeprowadzono z użyciem standardowego oprogramowania dla systemów hiperkonwergentnych – HCIBench, które wykorzystuje narzędzie Oracle Vdbench i automatyzuje proces testowania. W szczególności, HCIBench automatycznie tworzy maszyny wirtualne, koordynuje obciążenie między nimi i generuje wygodne i czytelne raporty.
Stworzono 140 maszyn wirtualnych na klaster (35 na węzeł klastra). Każda maszyna wirtualna korzystała z 4 vCPU i 4 GB RAM. Lokalny dysk VM wynosił 16 GB, a dodatkowy dysk 40 GB.
W testowaniu wzięły udział następujące konfiguracje klastrów:
- klaster składający się z czterech węzłów Cisco HyperFlex 220C 1 x 400 GB SSD na pamięć podręczną i 6 x 1.2 TB SAS HDD na dane;
- klaster konkurenta Vendor A składający się z czterech węzłów 2 x 400 GB SSD na pamięć podręczną i 4 x 1 TB SATA HDD na dane;
- klaster konkurenta Vendor B składający się z czterech węzłów 2 x 400 GB SSD na pamięć podręczną i 12 x 1.2 TB SAS HDD na dane;
- klaster konkurenta Vendor C składający się z czterech węzłów 4 x 480 GB SSD na pamięć podręczną i 12 x 900 GB SAS HDD na dane.
Procesory i pamięć operacyjna wszystkich rozwiązań były identyczne.
Test na liczbę maszyn wirtualnych
Testowanie rozpoczęto z obciążeniem mającym na celu emulację standardowego testu OLTP: zapis/odczyt (RW) 70%/30%, 100% FullRandom z docelową wartością 800 IOPS na jedną maszynę wirtualną (VM). Test przeprowadzono na 140 VM w każdym klastrze przez trzy do czterech godzin. Celem testu jest utrzymanie opóźnień przy zapisie na jak największej liczbie VM na poziomie 5 milisekund lub niżej.
W wyniku testu (zobacz wykres poniżej) HyperFlex okazał się jedyną platformą, która zakończyła ten test z początkowymi 140 VM i przy opóźnieniach poniżej 5 ms (4,95 ms). Dla każdego z innych klastrów test został powtórzony, aby doświadczalnie dopasować liczbę VM do docelowego opóźnienia 5 ms w kilku iteracjach.
Vendor A pomyślnie poradził sobie z 70 VM ze średnim czasem reakcji 4,65 ms.
Vendor B zapewnił wymagane opóźnienia na poziomie 5,37 ms tylko przy 36 VM.
Vendor C zdołał utrzymać 48 maszyn wirtualnych ze czasem reakcji 5,02 ms.
Emulacja obciążenia SQL Server
Następnie ESG Lab emulował obciążenie SQL Servera. W teście używano różnych rozmiarów bloków i proporcji odczytu/zapisu. Test przeprowadzono również na 140 maszynach wirtualnych.
Jak pokazano na rysunku poniżej, klaster Cisco HyperFlex niemal dwukrotnie przewyższył pod względem IOPS dostawcę A i B, a dostawcę C ponad pięciokrotnie. Średni czas reakcji Cisco HyperFlex wyniósł 8,2 ms. Dla porównania, średni czas reakcji dostawcy A wyniósł 30,6 ms, dostawcy B — 12,8 ms, a dostawcy C — 10,33 ms.
Ciekawą obserwację poczyniono podczas wszystkich testów. Vendor B wykazał znaczny rozrzut średniej wydajności w IOPS na różnych VM. Obciążenie było rozdzielane w niezwykle nierówny sposób, niektóre VM działały ze średnim wynikiem 1000 IOPS+, a niektóre – ze wynikiem 64 IOPS. Cisco HyperFlex w tym przypadku wydawał się znacznie stabilniejszy, wszystkie 140 VM otrzymywały średnio 600 IOPS od systemu pamięci masowej, co oznacza, że obciążenie między maszynami wirtualnymi zostało rozdzielone bardzo równomiernie.
Warto zauważyć, że takie nierównomierne rozdzielenie IOPS pomiędzy maszynami wirtualnymi u dostawcy B obserwowano przy każdej iteracji testowania.
W rzeczywistych warunkach produkcyjnych takie zachowanie systemu może być dużym problemem dla administratorów; w zasadzie, poszczególne maszyny wirtualne losowo zaczynają „zawieszać się” i praktycznie nie ma sposobu na kontrolowanie tego procesu. Jedynym, niezbyt skutecznym sposobem wyrównywania obciążenia, przy użyciu rozwiązania od dostawcy B, jest stosowanie pewnych realizacji QoS lub balansowania obciążenia.
Wnioski
Zastanówmy się, co oznacza 140 maszyn wirtualnych w Cisco Hyperflex na 1 fizyczny węzeł w porównaniu do 70 lub mniej w innych rozwiązaniach? Dla firm oznacza to, że aby utrzymać tę samą liczbę aplikacji na Hyperflex, potrzeba o połowę mniej węzłów niż w rozwiązaniach konkurencyjnych, co sprawia, że cała system będzie znacząco tańszy. Jeśli dodamy do tego jeszcze poziom automatyzacji wszystkich operacji związanych z zarządzaniem siecią, serwerami i platformą przechowywania HX Data Platform, staje się jasne, dlaczego rozwiązania Cisco Hyperflex tak szybko zdobywają popularność na rynku.
Ogólnie rzecz biorąc, laboratoria ESG potwierdziły, że hybrydowe Cisco HyperFlex w wersji HX 3.0 zapewniają wyższą i bardziej stabilną wydajność niż inne podobne rozwiązania.
Hybrydowe klastry HyperFlex wyróżniały się także na tle konkurencji pod względem wskaźników IOPS i latencji. Nie mniej ważne jest to, że wydajność HyperFlex została osiągnięta przy bardzo dobrze rozłożonym obciążeniu w całym magazynie.
Przypominamy, że rozwiązanie Cisco Hyperflex można już zobaczyć na własne oczy i przekonać się o jego możliwościach. System jest dostępny do demonstracji dla wszystkich chętnych:
Źródło: habr.com
