🥇Administrator bez rąk = hiperkonwergencja?

To mit, dość powszechny w dziedzinie sprzętu serwerowego. W praktyce jednak rozwiązania hiperkonwergentne (gdy wszystko jest w jednym) są potrzebne do wielu zastosowań. Historycznie rzecz biorąc, pierwsze architektury zostały opracowane przez Amazon i Google na potrzeby ich usług. Wtedy ideą było stworzenie farmy obliczeniowej z identycznych węzłów, z których każdy miał swoje dyski. Wszystko to łączyło się w pewnym systemowym oprogramowaniu (hiperwizorze) i dzieliło na maszyny wirtualne. Głównym celem jest minimalny wysiłek w utrzymaniu pojedynczego węzła oraz minimalne problemy przy skalowaniu: po prostu kupujemy jeszcze tysiąc lub dwa takie same serwery i podłączamy obok. W praktyce to jednak jednostkowe przypadki, a znacznie częściej mówimy o mniejszej liczbie węzłów i nieco innej architekturze.

Jednak zaletą pozostaje ta sama - niesamowita prostota skalowania i zarządzania. Minusem jest to, że różne zadania różnie konsumują zasoby, w niektórych przypadkach będzie dużo lokalnych dysków, w innych mało pamięci RAM i tak dalej, czyli przy różnym typie zadań wykorzystanie zasobów będzie spadać.

Okazuje się, że płacisz o 10-15% więcej za wygodę konfiguracji. To właśnie spowodowało mit z tytułu. Długo szukaliśmy, gdzie technologia będzie używana optymalnie i znaleźliśmy. Rzecz w tym, że Cisco nie miało własnych macierzy dyskowych, ale chciało zdominować pełen rynek serwerowy. I stworzyli Cisco Hyperflex - rozwiązanie z lokalnymi magazynami na węzłach.

A z tego nagle powstało bardzo dobre rozwiązanie dla awaryjnych centrów danych (Disaster Recovery). Dlaczego i jak - teraz opowiem. I pokażę testy klastra.

Gdzie jest potrzebne

Hiperkonwergencja to:

Przeniesienie dysków do węzłów obliczeniowych.
Pełna integracja podsystemu przechowywania danych z podsystemem virtualizacji.
Przeniesienie/integracja z podsystemem sieciowym.

Tego rodzaju połączenie pozwala na realizację wielu funkcji macierzy dyskowych na poziomie wirtualizacji, wszystko z jednego okna zarządzania.

W naszej firmie projekty dotyczące projektowania rezerwowych centrów danych cieszą się dużym zainteresowaniem, a często wybiera się właśnie hiperkonwergentne rozwiązanie ze względu na mnóstwo opcji replikacji (aż do metroklastera) w zestawie.

W przypadku zapasowych centrów danych zwykle mówimy o zdalnym obiekcie w innej części miasta lub nawet w innym mieście. Umożliwia to przywrócenie krytycznych systemów w przypadku częściowej lub całkowitej awarii głównego centrum danych. Dane z produkcji są tam stale replikowane, a ta replikacja może odbywać się na poziomie aplikacji lub na poziomie jednostki blokowej (macierzy dyskowej).

Dlatego teraz opowiem o budowie systemu i testach, a później - o kilku scenariuszach rzeczywistego zastosowania z danymi dotyczącymi oszczędności.

Testy

Nasz egzemplarz składa się z czterech serwerów, z których każdy ma 10 dysków SSD o pojemności 960 GB. Jest dedykowany dysk do buforowania operacji zapisu oraz do przechowywania maszyny wirtualnej serwisowej. Rozwiązanie to jest czwartą wersją. Pierwsza była wyraźnie surowa (sądząc po opiniach), druga była jeszcze dość surowa, trzecia była już wystarczająco stabilna, a tę można nazwać wydaniem po zakończeniu testów beta w szerokim gronie. Podczas testów nie zauważyłem żadnych problemów, wszystko działa jak w zegarku.

Zmiany w v4Naprawiono mnóstwo błędów.

Początkowo platforma mogła działać tylko z hyperwizorem VMware ESXi i obsługiwała niewielką liczbę węzłów. Proces wdrażania nie zawsze kończył się pomyślnie, czasami konieczne było ponowne uruchamianie niektórych kroków, występowały problemy z aktualizacją ze starszych wersji, dane w GUI nie zawsze były wyświetlane poprawnie (choć wciąż nie jestem zachwycony wyświetlaniem wykresów wydajności), czasami pojawiały się problemy na styku z wirtualizacją.

Teraz wszystkie dziecięce choroby zostały naprawione, HyperFlex obsługuje zarówno ESXi, jak i Hyper-V, a ponadto możliwe jest:

Tworzenie rozproszonego klastra.
Tworzenie klastra dla biur bez użycia Fabric Interconnect, od dwóch do czterech węzłów (kupujemy tylko serwery).
Możliwość współpracy z zewnętrznymi macierzami dyskowymi.
Wsparcie dla kontenerów i Kubernetes.
Tworzenie stref dostępności.
Integracja z VMware SRM, jeśli wbudowana funkcjonalność nie jest wystarczająca.

Architektura niewiele różni się od rozwiązań głównych konkurentów, nie stworzono od nowa roweru. Wszystko działa na platformie wirtualizacji VMware lub Hyper-V. Sprzętowo umieszczone jest na serwerach zaprojektowanych przez Cisco UCS. Są tacy, którzy nienawidzą tej platformy za względną złożoność początkowej konfiguracji, liczne przyciski, nietrywialny system szablonów i zależności, ale są też tacy, którzy zaznali zen, zrozumieli ideę i już nie chcą pracować z innymi serwerami.

Rozważymy rozwiązanie dla VMware, ponieważ zostało ono pierwotnie stworzone dla tej platformy i ma większą funkcjonalność, a Hyper-V zostało poprawione w toku, aby nie ustępować konkurencji i odpowiadać oczekiwaniom rynku.

Istnieje klaster serwerów, wypełnionych dyskami. Są dyski do przechowywania danych (SSD lub HDD – według twojego gustu i potrzeb), jest jeden dysk SSD do cache'owania. Podczas zapisu danych na datastorze dane są przechowywane na warstwie cache'ującej (dedykowany dysk SSD i RAM maszyny wirtualnej). Równolegle blok danych jest wysyłany do węzłów w klastrze (liczba węzłów zależy od czynnika replikacji klastra). Po potwierdzeniu przez wszystkie węzły pomyślnego zapisu, potwierdzenie zapisu jest wysyłane do hypervisora, a następnie do maszyny wirtualnej. Zapisane dane w tle są deduplikowane, kompresowane i zapisywane na dyskach magazynowych. Przy tym na dyski magazynowe zawsze zapisuje się duży blok i sekwencyjnie, co zmniejsza obciążenie dysków magazynowych.

Deduplikacja i kompresja są włączone na stałe i nie można ich wyłączyć. Odczyt danych odbywa się bezpośrednio z dysków magazynowych lub z pamięci RAM cache. Jeśli używana jest hybrydowa konfiguracja, odczyt również znajduje się w pamięci cache na dysku SSD.

Dane nie są powiązane z bieżącą lokalizacją maszyny wirtualnej i są równomiernie rozdzielane między węzłami. Takie podejście pozwala na równomierne obciążenie wszystkich dysków i interfejsów sieciowych. Nasuwa się oczywisty minus: nie możemy maksymalnie zmniejszyć opóźnienia odczytu, ponieważ nie ma gwarancji lokalnej dostępności danych. Jednak uważam, że to niewielka ofiara w porównaniu z uzyskanymi korzyściami. Tym bardziej, że opóźnienia w sieci osiągnęły takie wartości, że praktycznie nie wpływają na ogólny wynik.

Za całą logikę działania dyskowej podsystemu odpowiada specjalna usługa VM Cisco HyperFlex Data Platform controller, która jest tworzona na każdym węźle pamięci. W naszej konfiguracji usłudze VM przydzielono osiem vCPU i 72 GB RAM, co nie jest mało. Przypomnę, że sam host dysponuje 28 fizycznymi rdzeniami i 512 GB RAM.

Usługa VM ma dostęp do fizycznych dysków bezpośrednio poprzez przesyłanie kontrolera SAS do VM. Komunikacja z hipernadzorcą odbywa się za pośrednictwem specjalnego modułu IOVisor, który przechwytuje operacje wejścia-wyjścia, oraz za pomocą agenta, który umożliwia przesyłanie poleceń do API hipernadzorcy. Agent odpowiada za pracę z migawkami i klonami HyperFlex.

W hipernadzorze zasoby dyskowe są montowane jako udziały NFS lub SMB (w zależności od typu hipernadzorcy, zgadnij, który gdzie). A pod maską to rozproszony system plików, który pozwala dodać funkcje pełnowartościowych macierzy dyskowych: cienkie przydzielanie wolumenów, kompresję i deduplikację, migawki według technologii Redirect-on-Write, synchronizowaną/asynchronizowaną replikację.

Usługa VM udostępnia dostęp do interfejsu WWW zarządzania podsystemem HyperFlex. Istnieje integracja z vCenter, a większość codziennych zadań może być wykonana z niego, ale datastory, na przykład, wygodniej jest konfigurować z oddzielnej strony internetowej, jeśli już przeszedłeś na szybki interfejs HTML5, lub korzystać z pełnoprawnego klienta Flash z pełną integracją. W serwisowej stronie internetowej można zobaczyć wydajność i szczegółowy status systemu.

Istnieje również inny typ węzłów w klastrze — węzły obliczeniowe. Mogą to być serwery szafowe lub blade bez wbudowanych dysków. Na tych serwerach można uruchamiać VM, których dane są przechowywane na serwerach z dyskami. Z punktu widzenia dostępu do danych nie ma różnicy między typami węzłów, ponieważ architektura zakłada abstrahowanie od fizycznej lokalizacji danych. Maksymalne proporcje węzłów obliczeniowych do węzłów pamięci to 2:1.

Wykorzystanie węzłów obliczeniowych zwiększa elastyczność przy skalowaniu zasobów klastra: nie musimy kupować dodatkowych węzłów z dyskami, jeśli potrzebujemy tylko CPU/RAM. Ponadto możemy dodać szafkę blade’ową i uzyskać oszczędności na rozmieszczeniu serwerów w szafie.

Ostatecznie mamy hiper-konwergentną platformę z następującymi funkcjami:

Do 64 węzłów w klastrze (do 32 węzłów pamięci).
Minimalna liczba węzłów w klastrze to trzy (dwa dla klastra Edge).
Mechanizm redundancji danych: mirroring z czynnikiem replikacji 2 i 3.
Metro-klaster.
Asynchroniczna replikacja VM do innego klastra HyperFlex.
Orkiestracja przełączania VM do zdalnego centrum danych.
Natywne migawki przy użyciu technologii Redirect-on-Write.
Do 1 PB pojemności użytecznej przy czynniku replikacji 3 i bez uwzględniania deduplikacji. Czynnik replikacji 2 nie jest uwzględniany, ponieważ nie jest to rozwiązanie dla poważnej sprzedaży.

Kolejna ogromna zaleta — prostota zarządzania i wdrażania. Wszystkie trudności w konfiguracji serwerów UCS bierze na siebie wyspecjalizowana VM, przygotowana przez inżynierów Cisco.

Konfiguracja testowego stendu:

2 x Cisco UCS Fabric Interconnect 6248UP jako kontroler klastra i komponenty sieciowe (48 portów, działających w trybie Ethernet 10G/FC 16G).
Cztery serwery Cisco UCS HXAF240 M4.

Charakterystyka serwerów:

CPU

2 x Intel ® Xeon ® E5-2690 v4

RAM

16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2v

Sieć

UCSC-MLOM-CSC-02 (VIC 1227). 2 porty 10G Ethernet

HBA magazynu

Cisco 12G Modular SAS Pass through Controller

Dyski magazynowe

1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB

Więcej opcji konfiguracjiOprócz wybranego sprzętu, obecnie dostępne są następujące opcje:

HXAF240c M5.
Jeden lub dwa CPU od Intel Silver 4110 do Intel Platinum I8260Y. Dostępne drugie pokolenie.
24 sloty pamięci, moduły od 16 GB RDIMM 2600 do 128 GB LRDIMM 2933.
Od 6 do 23 dysków dla danych, jeden dysk podręczny, jeden systemowy i jeden dysk startowy.

Dyski pojemnościowe

HX-SD960G61X-EV 960GB 2.5 inch Enterprise Value 6G SATA SSD (1X endurance) SAS 960 GB.
HX-SD38T61X-EV 3.8TB 2.5 inch Enterprise Value 6G SATA SSD (1X endurance) SAS 3.8 TB.
Dyski podręczne
HX-NVMEXPB-I375 375GB 2.5 inch Intel Optane Drive, Extreme Perf & Endurance.
HX-NVMEHW-H1600* 1.6TB 2.5 inch Ent. Perf. NVMe SSD (3X endurance) NVMe 1.6 TB.
HX-SD400G12TX-EP 400GB 2.5 inch Ent. Perf. 12G SAS SSD (10X endurance) SAS 400 GB.
HX-SD800GBENK9** 800GB 2.5 inch Ent. Perf. 12G SAS SED SSD (10X endurance) SAS 800 GB.
HX-SD16T123X-EP 1.6TB 2.5 inch Enterprise performance 12G SAS SSD (3X endurance).

Dyski systemowe / logi

HX-SD240GM1X-EV 240GB 2.5 inch Enterprise Value 6G SATA SSD (wymaga aktualizacji).

Dyski startowe

HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.

Połączenie z siecią przez porty Ethernet 40G, 25G lub 10G.

Jako FI mogą być HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).

Test

Do testowania subsystemu dyskowego użyłem HCIBench 2.2.1. Jest to darmowe narzędzie, które automatyzuje generację obciążenia z kilku maszyn wirtualnych. Samo obciążenie generowane jest przez standardowe fio.

Nasz klaster składa się z czterech węzłów, czynnik replikacji 3, wszystkie dyski Flash.

Aby przetestować, stworzyłem cztery magazyny danych i osiem maszyn wirtualnych. W testach zapisu przewidziano scenariusz, w którym dysk podręczny nie jest przepełniony.

Wyniki testów są następujące:

100 % Odczyt 100 % Losowy

0 % Odczyt 100 % Losowy

Blok/głębokość kolejki

128

256

512

1024

2048

128

256

512

1024

2048

0,59 ms 213804 IOPS

0,84 ms 303540 IOPS

1,36 ms 374348 IOPS

2,47 ms 414116 IOPS

4,86 ms 420180 IOPS

2,22 ms 57408 IOPS

3,09 ms 82744 IOPS

5,02 ms 101824 IOPS

8,75 ms 116912 IOPS

17,2 ms 118592 IOPS

0,67 ms 188416 IOPS

0,93 ms 273280 IOPS

1,7 ms 299932 IOPS

2,72 ms 376484 IOPS

5,47 ms 373176 IOPS

3,1 ms 41148 IOPS

4,7 ms 54396 IOPS

7,09 ms 72192 IOPS

12,77 ms 80132 IOPS

16K

0,77 ms 164116 IOPS

1,12 ms 228328 IOPS

1,9 ms 268140 IOPS

3,96 ms 258480 IOPS

3,8 ms 33640 IOPS

6,97 ms 36696 IOPS

11,35 ms 45060 IOPS

32K

1,07 ms 119292 IOPS

1,79 ms 142888 IOPS

3,56 ms 143760 IOPS

7,17 ms 17810 IOPS

11,96 ms 21396 IOPS

64K

1,84 ms 69440 IOPS

3,6 ms 71008 IOPS

7,26 ms 70404 IOPS

11,37 ms 11248 IOPS

Pogrubione wartości wskazują na brak wzrostu wydajności, czasami nawet widoczny jest spadek. Jest to związane z ograniczeniami związanymi z wydajnością sieci/kontrolerów/dysków.

Sekwencyjny odczyt 4432 MB/s.
Sekwencyjny zapis 804 MB/s.
W przypadku awarii jednego kontrolera (awaria maszyny wirtualnej lub hosta) spadek wydajności wynosi dwa razy.
W przypadku awarii dysku pamięci masowej spadek wynosi 1/3. Przebudowa dysku zajmuje 5% zasobów każdego kontrolera.

Na małym bloku napotykamy ograniczenia związane z wydajnością kontrolera (maszyna wirtualna), który jest obciążony w 100%. W miarę zwiększania bloku napotykamy ograniczenie przepustowości portów. 10 Gbit/s jest niewystarczające, by w pełni wykorzystać potencjał systemu AllFlash. Niestety, parametry dostępnego stanowiska demonstracyjnego nie pozwalają na sprawdzenie działania przy 40 Gbit/s.

Z moich doświadczeń z testów i analizy architektury wynika, że dzięki algorytmowi, który rozdziela dane pomiędzy wszystkimi hostami, uzyskujemy skalowalną, przewidywalną wydajność, ale stanowi to również ograniczenie przy odczycie, ponieważ z lokalnych dysków moglibyśmy uzyskiwać więcej. Może to poprawić wydajniejsza sieć, na przykład dostępne są FI na 40 Gbit/s.

Również jeden dysk do pamięci podręcznej i deduplikacji może być ograniczeniem; w tym stanowisku możemy pisać na czterech dyskach SSD. Byłoby świetnie, móc zwiększyć liczbę dysków podręcznych i zobaczyć różnicę.

Rzeczywiste wykorzystanie

Do organizacji zapasowego centrum danych można stosować dwa podejścia (nie bierzemy pod uwagę lokalizacji kopii zapasowej na zdalnej stronie):

Active-Passive. Wszystkie aplikacje są hostowane w głównym centrum danych. Replikacja jest synchronizowana lub asynchronizowana. W przypadku awarii głównego centrum danych musimy aktywować zapasowe. Można to zrobić ręcznie / skryptami / aplikacjami orkiestracyjnymi. Tutaj uzyskujemy RPO, które jest porównywalne z częstotliwością replikacji, a RTO zależy od reakcji i umiejętności administratora oraz jakości opracowania / debugowania planu przełączenia.
Active-Active. W tym przypadku istnieje tylko synchronizowana replikacja, dostępność centrów danych jest określana przez kworum / arbitra, którego umiejscowienie jest ściśle w trzecim miejscu. RPO = 0, a RTO może wynosić 0 (jeśli aplikacja na to pozwala) lub odpowiadać czasowi reakcji na awarię węzła w klastrze wirtualizacji. Na poziomie wirtualizacji tworzony jest rozciągnięty (Metro) klaster, który wymaga Active-Active macierzy.

Zazwyczaj widzimy u klientów już zrealizowaną architekturę z klasyczną macierzą w głównym centrum danych, dlatego projektujemy jeszcze jedną do replikacji. Jak już wspomniałem, Cisco HyperFlex oferuje asynchroniczną replikację i tworzenie rozciągniętego klastra wirtualizacji. Przy tym nie potrzebujemy dedykowanej macierzy klasy Midrange i wyższej z drogimi funkcjami replikacji i Active-Active dostępu do danych na dwóch macierzach.

Scenariusz 1: Mamy główne i zapasowe centra danych, platforma wirtualizacji na VMware vSphere. Wszystkie produkty systemowe znajdują się w głównym centrum danych, a replikacja maszyn wirtualnych odbywa się na poziomie hypervisor, co pozwala na to, aby VM były wyłączone w zapasowym centrum danych. Bazy danych i specjalne aplikacje replikujemy wbudowanymi narzędziami i utrzymujemy VM włączone. W przypadku awarii głównego centrum danych uruchamiamy systemy w zapasowym centrum danych. Uważamy, że mamy około 100 maszyn wirtualnych. Dopóki działa główne centrum danych, w zapasowym centrum danych można uruchamiać środowiska testowe i inne systemy, które można wyłączyć w przypadku przełączenia głównego centrum danych. Możliwa jest również opcja dwukierunkowej replikacji. Z punktu widzenia sprzętu nic się nie zmieni.

W przypadku tradycyjnej architektury w każdym centrum danych zainstalujemy hybrydową macierz dyskową z dostępem przez FibreChannel, tieringiem, deduplikacją i kompresją (ale nie online), 8 serwerów na każde miejsce, po 2 przełączniki FibreChannel i Ethernet 10G. Do replikacji i zarządzania przełączaniem w tradycyjnej architekturze możemy użyć narzędzi VMware (Replication + SRM) lub zewnętrznych narzędzi, które będą nieco tańsze i czasami wygodniejsze.

Na rysunku przedstawiona jest schemat.

W przypadku użycia Cisco HyperFlex otrzymujemy następującą architekturę:

Dla HyperFlex użyłem serwerów z dużymi zasobami CPU/RAM, ponieważ część zasobów pójdzie na maszynę wirtualną kontrolera HyperFlex. W przypadku CPU i pamięci nawet nieco przeszacowałem w konfiguracji HyperFlex, aby nie zaprzedawać się w stronę Cisco i zapewnić zasoby dla pozostałych maszyn wirtualnych. Dzięki temu możemy zrezygnować z przełączników FibreChannel, a porty Ethernet nie będą potrzebne dla każdego serwera, lokalny ruch jest przełączany wewnątrz FI.

W rezultacie uzyskaliśmy następującą konfigurację dla każdego centrum danych:

Serwery

8 x 1U Server (384 GB RAM, 2 x Intel Gold 6132, FC HBA)

8 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)

Macierz dyskowa

Hybrydowa macierz dyskowa z FC Front-End (20TB SSD, 130 TB NL-SAS)

—

LAN

2 x przełącznik Ethernet 10G 12 portów

—

SAN

2 x przełącznik FC 32/16Gb 24 porty

2 x Cisco UCS FI 6332

Licencje

VMware Ent Plus

Replikacja i/lub orkiestracja przełączania maszyn wirtualnych

VMware Ent Plus

Dla Hyperflex nie uwzględniłem licencji na oprogramowanie do replikacji, ponieważ mamy to dostępne z pudełka.

Dla tradycyjnej architektury wybrałem dostawcę, który zdobył renomę jako jakościowy i niedrogi producent. Dla obu opcji zastosowałem standardowe dla konkretnego rozwiązania zniżki, a na końcu uzyskałem rzeczywiste ceny.

Rozwiązanie na Cisco HyperFlex okazało się o 13% tańsze.

Scenariusz 2: utworzenie dwóch aktywnych centrów danych. W tym scenariuszu projektujemy rozwleczony klaster na VMware.

Klasyczna architektura składa się z serwerów wirtualizacji, SAN (protokół FC) oraz dwóch macierzy dyskowych, które potrafią czytać i pisać na tym, co jest rozwleczone między nimi. Na każdej macierzy dyskowej uwzględniamy pojemność użyteczną dla lokalizacji.

W HyperFlex po prostu tworzymy Stretch Cluster z taką samą liczbą węzłów na obu lokalizacjach. W tym przypadku używany jest współczynnik replikacji 2+2.

Uzyskaliśmy następującą konfigurację:

Klasyczna architektura

HyperFlex

Serwery

16 x 1U Server (384 GB RAM, 2 x Intel Gold 6132, FC HBA, 2 x 10G NIC)

16 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)

Macierz dyskowa

2 x AllFlash macierz dyskowa (150 TB SSD)

—

LAN

4 x przełącznik Ethernet 10G 24 porty

—

SAN

4 x przełącznik FC 32/16Gb 24 porty

4 x Cisco UCS FI 6332

Licencje

VMware Ent Plus

Wszystkie obliczenia nie uwzględniały infrastruktury sieciowej, kosztów związanych z centrum danych itp.: będą one takie same zarówno dla klasycznej architektury, jak i dla rozwiązania opartego na HyperFlex.

Koszt HyperFlex był o 5% wyższy. Należy zauważyć, że w przypadku zasobów CPU/RAM miałem dla Cisco nierównowagę, ponieważ w konfiguracji równomiernie zapełniałem kanały kontrolerów pamięci. Koszt jest nieco wyższy, ale nie w dramatycznym stopniu, co wyraźnie wskazuje, że hiperkonwergencja nie musi być „zabawą dla bogatych” i może konkurować z tradycyjnym podejściem do budowy centrum danych. Może to być również interesujące dla tych, którzy już posiadają serwery Cisco UCS oraz odpowiednią infrastrukturę do nich.

Z zaletami otrzymujemy brak kosztów administracji SAN i macierzy dyskowych, kompresję online i deduplikację, jeden punkt kontaktowy dla wsparcia (wirtualizacja, serwery, które są również macierzami dyskowymi), oszczędność miejsca (ale nie we wszystkich scenariuszach), uproszczenie eksploatacji.

Jeśli chodzi o wsparcie, to otrzymujecie je od jednego dostawcy — Cisco. Sądząc po doświadczeniach z serwerami Cisco UCS, które mi się podobają, w HyperFlex nie musiałem interweniować, wszystko działało. Inżynierowie odpowiadają szybko i potrafią rozwiązywać nie tylko typowe problemy, ale także trudne przypadki graniczne. Czasem zwracam się do nich z pytaniami: "Czy można to zrobić, podłączyć to?" lub "Skonfigurowałem coś tutaj i nie chce działać. Pomocy!" — cierpliwie znajdą odpowiedni przewodnik i wskażą właściwe działania, nie odpowiedzą: "Rozwiązujemy tylko problemy sprzętowe".