To mit, który jest dość powszechny w dziedzinie sprzętu serwerowego. W praktyce rozwiązania hiperkonwergentne (kiedy wszystko jest w jednym) są potrzebne do wielu rzeczy. Historycznie rzecz biorąc, pierwsze architektury zostały opracowane przez Amazon i Google na potrzeby swoich usług. Następnie pomysł polegał na stworzeniu farmy obliczeniowej z identycznych węzłów, z których każdy miał własne dyski. Wszystko to zostało zjednoczone przez oprogramowanie tworzące system (hypervisor) i podzielone na maszyny wirtualne. Głównym celem jest minimum wysiłku związanego z obsługą jednego węzła i minimum problemów przy skalowaniu: wystarczy kupić kolejny tysiąc lub dwa takie same serwery i podłączyć je w pobliżu. W praktyce są to przypadki odosobnione i znacznie częściej mówimy o mniejszej liczbie węzłów i nieco innej architekturze.
Ale plus pozostaje ten sam - niesamowita łatwość skalowania i zarządzania. Minusem jest to, że różne zadania w różny sposób zużywają zasoby, a w niektórych miejscach będzie dużo dysków lokalnych, w innych będzie mało pamięci RAM i tak dalej, to znaczy w przypadku różnych typów zadań wykorzystanie zasobów będzie się zmniejszać.
Okazuje się, że za łatwość konfiguracji płacisz 10–15% więcej. To właśnie wywołało mit w tytule. Długo szukaliśmy miejsca, w którym technologia będzie optymalnie zastosowana, i znaleźliśmy ją. Faktem jest, że Cisco nie miało własnych systemów pamięci masowej, ale zależało im na kompletnym rynku serwerów. I stworzyli Cisco Hyperflex - rozwiązanie z lokalną pamięcią masową na węzłach.
I to nagle okazało się bardzo dobrym rozwiązaniem dla zapasowych centrów danych (Disaster Recovery). Powiem ci teraz dlaczego i jak. Pokażę ci testy klastrowe.
Gdzie potrzeba
Hiperkonwergencja to:
- Przesyłanie dysków do węzłów obliczeniowych.
- Pełna integracja podsystemu pamięci masowej z podsystemem wirtualizacji.
- Transfer/integracja z podsystemem sieciowym.
Takie połączenie pozwala na wdrożenie wielu funkcji systemu pamięci masowej na poziomie wirtualizacji i to wszystko z jednego okna kontrolnego.
W naszej firmie projekty projektowania redundantnych centrów danych cieszą się dużym zainteresowaniem, a rozwiązanie hiperkonwergentne jest często wybierane ze względu na szereg opcji replikacji (aż do metropolitalnego klastra) od razu po wyjęciu z pudełka.
W przypadku zapasowych centrów danych mówimy zazwyczaj o odległym obiekcie, położonym na drugim końcu miasta lub w ogóle w innym mieście. Umożliwia przywrócenie krytycznych systemów w przypadku częściowej lub całkowitej awarii głównego centrum danych. Dane sprzedażowe są tam stale replikowane i replikacja ta może odbywać się na poziomie aplikacji lub na poziomie urządzenia blokowego (magazynu).
Dlatego teraz opowiem o projekcie i testach systemu, a następnie o kilku rzeczywistych scenariuszach aplikacji z danymi dotyczącymi oszczędności.
Testy
Nasza instancja składa się z czterech serwerów, z których każdy posiada 10 dysków SSD o pojemności 960 GB. Istnieje dedykowany dysk do buforowania operacji zapisu i przechowywania wirtualnej maszyny usługowej. Samo rozwiązanie jest już czwartą wersją. Pierwsza jest szczerze prymitywna (sądząc po recenzjach), druga wilgotna, trzecia już w miarę stabilna, a tę można nazwać wydaniem po zakończeniu beta testów dla ogółu społeczeństwa. Podczas testów nie zauważyłem żadnych problemów, wszystko działa jak zegar.
Zmiany w v4Naprawiono mnóstwo błędów.
Początkowo platforma mogła współpracować jedynie z hypervisorem VMware ESXi i obsługiwała niewielką liczbę węzłów. Poza tym proces wdrażania nie zawsze kończył się sukcesem, niektóre kroki trzeba było zaczynać od nowa, pojawiały się problemy z aktualizacją ze starszych wersji, dane w GUI nie zawsze wyświetlały się poprawnie (chociaż nadal nie jestem zadowolony z wyświetlania wykresów wydajności ), czasami pojawiały się problemy na interfejsie z wirtualizacją.
Teraz wszystkie problemy z dzieciństwa zostały naprawione, HyperFlex może obsługiwać zarówno ESXi, jak i Hyper-V, a ponadto możliwe jest:
- Tworzenie rozciągniętego klastra.
- Tworzenie klastra dla biur bez użycia Fabric Interconnect, od dwóch do czterech węzłów (kupujemy same serwery).
- Możliwość współpracy z zewnętrznymi systemami pamięci masowej.
- Wsparcie dla kontenerów i Kubernetes.
- Tworzenie stref dostępności.
- Integracja z VMware SRM w przypadku, gdy wbudowana funkcjonalność nie jest zadowalająca.
Architektura niewiele odbiega od rozwiązań głównych konkurentów, nie stworzyli oni roweru. Całość działa na platformie wirtualizacyjnej VMware lub Hyper-V. Sprzęt jest hostowany na zastrzeżonych serwerach Cisco UCS. Są tacy, którzy nienawidzą platformy za względną złożoność początkowej konfiguracji, dużo przycisków, nietrywialny system szablonów i zależności, ale są też tacy, którzy nauczyli się Zen, zainspirowali się pomysłem i nie chcą już do współpracy z innymi serwerami.
Rozważymy rozwiązanie dla VMware, ponieważ rozwiązanie zostało pierwotnie stworzone dla niego i ma większą funkcjonalność; Hyper-V został dodany po drodze, aby dotrzymać kroku konkurencji i sprostać oczekiwaniom rynku.
Istnieje klaster serwerów pełen dysków. Do przechowywania danych służą dyski (SSD lub HDD - według upodobań i potrzeb), jest jeden dysk SSD do buforowania. Podczas zapisywania danych do datastore, dane zapisywane są w warstwie buforującej (dedykowany dysk SSD i pamięć RAM usługi VM). Równolegle do węzłów w klastrze wysyłany jest blok danych (liczba węzłów uzależniona jest od współczynnika replikacji klastra). Po potwierdzeniu ze wszystkich węzłów pomyślnego nagrania, potwierdzenie nagrania jest wysyłane do hypervisora, a następnie do maszyny wirtualnej. Zapisane dane są deduplikowane, kompresowane i zapisywane na dyskach w tle. Jednocześnie duży blok jest zawsze zapisywany na dyskach pamięci masowej i sekwencyjnie, co zmniejsza obciążenie dysków pamięci.
Deduplikacja i kompresja są zawsze włączone i nie można ich wyłączyć. Dane odczytywane są bezpośrednio z dysków magazynujących lub z pamięci podręcznej RAM. Jeśli używana jest konfiguracja hybrydowa, odczyty są również buforowane na dysku SSD.
Dane nie są powiązane z bieżącą lokalizacją maszyny wirtualnej i są równomiernie rozłożone pomiędzy węzłami. Takie podejście pozwala równomiernie załadować wszystkie dyski i interfejsy sieciowe. Istnieje oczywista wada: nie możemy maksymalnie zmniejszyć opóźnienia odczytu, ponieważ nie ma gwarancji lokalnej dostępności danych. Uważam jednak, że jest to niewielkie poświęcenie w porównaniu z otrzymanymi korzyściami. Co więcej, opóźnienia sieciowe osiągnęły takie wartości, że praktycznie nie wpływają na ogólny wynik.
Za całą logikę działania podsystemu dyskowego odpowiada specjalny kontroler usługi VM Cisco HyperFlex Data Platform, który tworzony jest na każdym węźle magazynowania. W naszej konfiguracji usługi VM przydzielono osiem vCPU i 72 GB RAM-u, czyli nie tak mało. Przypomnę, że sam host ma 28 rdzeni fizycznych i 512 GB RAM-u.
Usługowa maszyna wirtualna ma bezpośredni dostęp do dysków fizycznych, przekazując kontroler SAS do maszyny wirtualnej. Komunikacja z hypervisorem odbywa się poprzez specjalny moduł IOVisor, który przechwytuje operacje I/O oraz za pomocą agenta umożliwiającego wysyłanie poleceń do API hypervisora. Agent jest odpowiedzialny za pracę z migawkami i klonami HyperFlex.
Zasoby dyskowe są montowane w hypervisorze jako udziały NFS lub SMB (w zależności od typu hypervisora, zgadnij, który z nich gdzie się znajduje). Pod maską kryje się rozproszony system plików, który umożliwia dodawanie funkcji pełnoprawnych systemów pamięci masowej dla dorosłych: alokacja cienkich woluminów, kompresja i deduplikacja, migawki wykorzystujące technologię Redirect-on-Write, replikacja synchroniczna/asynchroniczna.
Usługowa maszyna wirtualna zapewnia dostęp do internetowego interfejsu zarządzania podsystemu HyperFlex. Istnieje integracja z vCenter i można z niego wykonać większość codziennych zadań, ale np. magazyny danych wygodniej jest wyciąć z osobnej kamery internetowej, jeśli przełączyłeś się już na szybki interfejs HTML5 lub korzystasz z pełnoprawnego klienta Flash z pełną integracją. W kamerze serwisowej możesz zobaczyć wydajność i szczegółowy stan systemu.
W klastrze występuje inny typ węzłów – węzły obliczeniowe. Mogą to być serwery stelażowe lub kasetowe bez wbudowanych dysków. Na tych serwerach można uruchamiać maszyny wirtualne, których dane są przechowywane na serwerach z dyskami. Z punktu widzenia dostępu do danych nie ma różnicy pomiędzy typami węzłów, ponieważ architektura zakłada abstrakcję od fizycznej lokalizacji danych. Maksymalny stosunek węzłów obliczeniowych do węzłów magazynujących wynosi 2:1.
Korzystanie z węzłów obliczeniowych zwiększa elastyczność podczas skalowania zasobów klastra: nie musimy kupować dodatkowych węzłów z dyskami, jeśli potrzebujemy tylko procesora/RAM. Ponadto możemy dodać klatkę na kasety i zaoszczędzić na rozmieszczeniu serwerów w szafie.
W rezultacie mamy platformę hiperkonwergentną o następujących funkcjach:
- Do 64 węzłów w klastrze (do 32 węzłów magazynowania).
- Minimalna liczba węzłów w klastrze to trzy (dwa w przypadku klastra Edge).
- Mechanizm redundancji danych: dublowanie ze współczynnikiem replikacji 2 i 3.
- Klaster metra.
- Asynchroniczna replikacja maszyny wirtualnej do innego klastra HyperFlex.
- Orkiestracja przełączania maszyn wirtualnych do zdalnego centrum danych.
- Natywne migawki wykorzystujące technologię Redirect-on-Write.
- Do 1 PB przestrzeni użytkowej przy współczynniku replikacji 3 i bez deduplikacji. Nie bierzemy pod uwagę współczynnika replikacji 2, bo to nie jest opcja przy poważnej sprzedaży.
Kolejnym ogromnym plusem jest łatwość zarządzania i wdrażania. Całą zawiłością związaną z konfiguracją serwerów UCS zajmuje się wyspecjalizowana maszyna wirtualna przygotowana przez inżynierów Cisco.
Konfiguracja stanowiska testowego:
- 2 x Cisco UCS Fabric Interconnect 6248UP jako klaster zarządzający i komponenty sieciowe (48 portów pracujących w trybie Ethernet 10G/FC 16G).
- Cztery serwery Cisco UCS HXAF240 M4.
Charakterystyka serwera:
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2 V
Sieć
UCSC-MLOM-CSC-02 (VIC 1227). 2 porty Ethernet 10G
Karta pamięci masowej HBA
Modularny kontroler przelotowy SAS Cisco 12G
Dyski magazynujące
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 dostępne są obecnie następujące opcje:
- HXAF240c M5.
- Jeden lub dwa procesory, od Intel Silver 4110 do Intel Platinum I8260Y. Dostępna druga generacja.
- 24 gniazda pamięci, paski od 16 GB RDIMM 2600 do 128 GB LRDIMM 2933.
- Od 6 do 23 dysków z danymi, jeden dysk buforujący, jeden dysk systemowy i jeden dysk rozruchowy.
Napędy pojemnościowe
- HX-SD960G61X-EV 960-calowy dysk SSD SATA klasy korporacyjnej 2.5G o wartości 6 GB (wytrzymałość 1X) SAS 960 GB.
- HX-SD38T61X-EV 3.8 TB 2.5-calowy dysk SSD SATA klasy korporacyjnej 6G (wytrzymałość 1X) SAS 3.8 TB.
- Buforowanie dysków
- HX-NVMEXPB-I375 375-calowy dysk Intel Optane 2.5 GB, ekstremalna wydajność i wytrzymałość.
- HX-NVMEHW-H1600* 1.6 TB 2.5 cala Ent. Perf. Dysk SSD NVMe (wytrzymałość 3X) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400 GB 2.5 cala Ent. Perf. Dysk SSD 12G SAS (wytrzymałość 10X) SAS 400 GB.
- HX-SD800GBENK9** 800 GB 2.5 cala Ent. Perf. Dysk SSD SAS SED 12G (wytrzymałość 10X) SAS 800 GB.
- HX-SD16T123X-EP 1.6 TB 2.5-calowy dysk SSD SAS klasy korporacyjnej 12G (wytrzymałość 3X).
Dyski systemowe/logowe
- HX-SD240GM1X-EV 240-calowy dysk SSD SATA Enterprise Value 2.5G o pojemności 6 GB (wymaga aktualizacji).
Dyski rozruchowe
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Połącz się z siecią za pośrednictwem portów Ethernet 40G, 25G lub 10G.
FI może mieć postać HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Sam test
Do przetestowania podsystemu dyskowego użyłem programu HCIBench 2.2.1. Jest to bezpłatne narzędzie, które pozwala zautomatyzować tworzenie obciążenia z wielu maszyn wirtualnych. Samo obciążenie jest generowane przez zwykłe fio.
Nasz klaster składa się z czterech węzłów, współczynnik replikacji 3, wszystkie dyski to Flash.
Do testów stworzyłem cztery magazyny danych i osiem maszyn wirtualnych. W przypadku testów zapisu zakłada się, że dysk buforujący nie jest pełny.
Wyniki testu są następujące:
100% odczytu, 100% losowego
0% odczytu 100% losowego
Głębokość bloku/kolejki
128
256
512
1024
2048
128
256
512
1024
2048
4K
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 IPOS
8,75 ms 116912 IOPS
17,2 ms 118592 IOPS
8K
0,67 ms 188416 IOPS
0,93 ms 273280 IOPS
1,7 ms 299932 IOPS
2,72 ms 376,484 IOPS
5,47 ms 373,176 IOPS
3,1 ms 41148 IOPS
4,7 ms 54396 IOPS
7,09 ms 72192 IOPS
12,77 ms 80132 IOPS
16 tysięcy
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
32 tysięcy
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
64 tysięcy
1,84 ms 69440 IOPS
3,6 ms 71008 IOPS
7,26 ms 70404 IOPS
11,37 ms 11248 IOPS
Pogrubieniem wskazano wartości, po których nie następuje wzrost produktywności, czasem widoczna jest nawet degradacja. Dzieje się tak dlatego, że ogranicza nas wydajność sieci/kontrolerów/dysków.
- Odczyt sekwencyjny 4432 MB/s.
- Zapis sekwencyjny 804 MB/s.
- W przypadku awarii jednego kontrolera (awaria maszyny wirtualnej lub hosta) spadek wydajności jest podwójny.
- W przypadku awarii dysku magazynującego strata wynosi 1/3. Odbudowa dysku zajmuje 5% zasobów każdego kontrolera.
Na małym bloku ogranicza nas wydajność kontrolera (maszyny wirtualnej), jej procesor jest obciążony w 100%, a gdy blok się zwiększa, ogranicza nas przepustowość portu. 10 Gbps to za mało, aby uwolnić potencjał systemu AllFlash. Niestety parametry dostarczonego stanowiska demonstracyjnego nie pozwalają na przetestowanie pracy z szybkością 40 Gbit/s.
Z testów i studiowania architektury wynika mi, że dzięki algorytmowi umieszczającemu dane pomiędzy wszystkimi hostami uzyskujemy skalowalną, przewidywalną wydajność, ale to też jest ograniczenie przy odczycie, bo dałoby się wycisnąć więcej z dysków lokalnych, tutaj może zaoszczędzić bardziej produktywną sieć, na przykład dostępna jest sieć FI o przepustowości 40 Gbit/s.
Ograniczeniem może być także jeden dysk do buforowania i deduplikacji, tak naprawdę na tym stanowisku testowym możemy zapisywać dane na czterech dyskach SSD. Byłoby wspaniale móc zwiększyć liczbę dysków buforujących i zobaczyć różnicę.
Prawdziwe zastosowanie
Aby zorganizować zapasowe centrum danych, możesz zastosować dwa podejścia (nie rozważamy umieszczania kopii zapasowej w zdalnej lokalizacji):
- Aktywny pasywny. Wszystkie aplikacje są hostowane w głównym centrum danych. Replikacja jest synchroniczna lub asynchroniczna. Jeśli główne centrum danych ulegnie awarii, musimy aktywować zapasowe. Można to zrobić ręcznie/skryptami/aplikacjami do orkiestracji. Tutaj otrzymamy RPO proporcjonalne do częstotliwości replikacji, a RTO zależy od reakcji i umiejętności administratora oraz jakości opracowania/debugowania planu przełączania.
- Aktywny-aktywny. W tym przypadku mamy do czynienia jedynie z replikacją synchroniczną, o dostępności centrów danych decyduje kworum/arbiter zlokalizowany wyłącznie w trzeciej lokacji. RPO = 0, a RTO może osiągnąć 0 (jeśli aplikacja na to pozwala) lub być równe czasowi przełączania awaryjnego węzła w klastrze wirtualizacji. Na poziomie wirtualizacji tworzony jest rozciągnięty klaster (Metro), który wymaga pamięci Active-Active.
Zwykle widzimy, że klienci wdrożyli już architekturę z klasycznym systemem przechowywania danych w głównym centrum danych, więc projektujemy kolejną do replikacji. Jak wspomniałem, Cisco HyperFlex oferuje replikację asynchroniczną i tworzenie klastrów rozciągniętej wirtualizacji. Jednocześnie nie potrzebujemy dedykowanego systemu pamięci masowej klasy Midrange i wyższej z kosztownymi funkcjami replikacji i dostępem do danych Active-Active na dwóch systemach pamięci masowej.
Scenariusz 1: Posiadamy podstawowe i zapasowe centra danych, platformę wirtualizacyjną na VMware vSphere. Wszystkie systemy produkcyjne zlokalizowane są w głównym centrum danych, a replikacja maszyn wirtualnych odbywa się na poziomie hypervisora, co pozwoli uniknąć utrzymywania maszyn wirtualnych włączonych w zapasowym centrum danych. Replikujemy bazy danych i aplikacje specjalne za pomocą wbudowanych narzędzi i utrzymujemy włączone maszyny wirtualne. W przypadku awarii głównego centrum danych uruchamiamy systemy w zapasowym centrum danych. Uważamy, że mamy około 100 maszyn wirtualnych. Gdy podstawowe centrum danych działa, w rezerwowym 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żliwe jest również, że zastosujemy replikację dwukierunkową. Ze sprzętowego punktu widzenia nic się nie zmieni.
W przypadku architektury klasycznej w każdym centrum danych zainstalujemy hybrydowy system przechowywania danych z dostępem przez FibreChannel, tieringiem, deduplikacją i kompresją (ale nie online), 8 serwerów na każdą lokalizację, 2 przełączniki FibreChannel i Ethernet 10G. Do replikacji i zarządzania przełączaniem w klasycznej architekturze możemy wykorzystać narzędzia VMware (Replikacja + SRM) lub narzędzia firm trzecich, które będą nieco tańsze, a czasem wygodniejsze.
Rysunek przedstawia schemat.
Korzystając z Cisco HyperFlex, uzyskuje się następującą architekturę:
W przypadku HyperFlex użyłem serwerów z dużymi zasobami procesora/RAM, ponieważ... Część zasobów trafi do maszyny wirtualnej kontrolera HyperFlex; jeśli chodzi o procesor i pamięć, nawet nieco przekonfigurowałem konfigurację HyperFlex, aby nie bawić się z Cisco i zagwarantować zasoby dla pozostałych maszyn wirtualnych. Możemy jednak zrezygnować z przełączników FibreChannel i nie będziemy potrzebować portów Ethernet dla każdego serwera; ruch lokalny jest przełączany w ramach FI.
W rezultacie otrzymano następującą konfigurację dla każdego centrum danych:
Serwery
Serwer 8 x 1U (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)
SHD
Hybrydowy system pamięci masowej z interfejsem FC (20 TB 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
2x Cisco UCS FI 6332
Licencje
VMware Ent Plus
Replikacja i/lub orkiestracja przełączania maszyn wirtualnych
VMware Ent Plus
Nie dostarczyłem licencji na oprogramowanie do replikacji dla Hyperflex, ponieważ jest ono dla nas dostępne od razu po wyjęciu z pudełka.
W przypadku architektury klasycznej wybrałem dostawcę, który ugruntował swoją pozycję jako producent wysokiej jakości i niedrogi. W przypadku obu opcji zastosowałem standardowy rabat na konkretne rozwiązanie i w efekcie otrzymałem realne ceny.
Rozwiązanie Cisco HyperFlex okazało się o 13% tańsze.
Scenariusz 2: utworzenie dwóch aktywnych centrów danych. W tym scenariuszu projektujemy rozciągnięty klaster w VMware.
Klasyczna architektura składa się z serwerów wirtualizacji, sieci SAN (protokół FC) i dwóch systemów pamięci masowej, które mogą odczytywać i zapisywać na woluminie rozciągniętym między nimi. W każdym systemie przechowywania umieściliśmy użyteczną pojemność do przechowywania.
W HyperFlex po prostu tworzymy klaster rozciągający z tą samą liczbą węzłów w obu lokalizacjach. W tym przypadku stosuje się współczynnik replikacji 2+2.
Rezultatem jest następująca konfiguracja:
architektura klasyczna
hiperfleksja
Serwery
Serwer 16 x 1U (384 GB RAM, 2 x Intel Gold 6132, FC HBA, 2 x karta sieciowa 10G)
16 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)
SHD
2 x systemy pamięci masowej AllFlash (SSD 150 TB)
-
LAN
4 x przełącznik Ethernet 10G 24 portów
-
SAN
4 x przełącznik FC 32/16Gb 24 porty
4x Cisco UCS FI 6332
Licencje
VMware Ent Plus
VMware Ent Plus
We wszystkich obliczeniach nie uwzględniłem infrastruktury sieciowej, kosztów centrum danych itp.: będą one takie same dla architektury klasycznej i rozwiązania HyperFlex.
Pod względem kosztów HyperFlex okazał się o 5% droższy. Warto tutaj zaznaczyć, że pod względem zasobów CPU/RAM miałem skrzywienie w stronę Cisco, gdyż w konfiguracji równomiernie wypełniłem kanały kontrolera pamięci. Koszt jest nieco wyższy, ale nie o rząd wielkości, co jednoznacznie wskazuje, że hiperkonwergencja niekoniecznie jest „zabawką dla bogatych”, ale może konkurować ze standardowym podejściem do budowy centrum danych. Może to zainteresować również tych, którzy posiadają już serwery Cisco UCS i odpowiednią dla nich infrastrukturę.
Wśród zalet dostajemy brak kosztów administrowania systemami SAN i pamięci masowej, kompresję i deduplikację online, pojedynczy punkt wejścia do wsparcia (wirtualizacja, serwery, to też systemy pamięci masowej), oszczędność miejsca (ale nie we wszystkich scenariuszach), upraszczając obsługę.
Jeśli chodzi o wsparcie, tutaj otrzymasz je od jednego dostawcy – Cisco. Sądząc po moich doświadczeniach z serwerami Cisco UCS, podoba mi się to, nie musiałem otwierać go na HyperFlex, wszystko działało tak samo. Inżynierowie reagują szybko i potrafią rozwiązać nie tylko typowe problemy, ale także złożone przypadki brzegowe. Czasami zwracam się do nich z pytaniami: „Czy da się to zrobić, spieprzyć to?” lub „Skonfigurowałem coś tutaj i to nie chce działać. Pomoc!" - cierpliwie znajdą tam potrzebny poradnik i wskażą właściwe działania, nie odpowiedzą: „Rozwiązujemy tylko problemy sprzętowe”.
referencje
- Mój mail - [email chroniony]
Źródło: www.habr.com