Recenzja urządzenia kontenerowego Diamanti D10

by StorageReview Enterprise Lab on November 15, 2019

Po raz pierwszy poznaliśmy Diamanti dwa lata temu na KubeCon 2017 i byliśmy pod wrażeniem ich wizji: stworzenia platformy kontenerowej bare-metal, stworzonej specjalnie dla mikrousług i środowisk chmurowych, zoptymalizowanej pod kątem Kubernetes, czyli, mówiąc wprost, hiperkonwergentnego urządzenia infrastrukturalnego dla Kubernetes. Uznaliśmy to za interesujące posunięcie i w zeszłym roku, na KubeCon 2018, zaczęliśmy z nimi rozmawiać o współpracy z nami w celu zrozumienia pamięci masowej w Kubernetes oraz sposobów testowania i metodycznego kwantyfikowania pamięci masowej Kubernetes, abyśmy mogli rozpocząć testowanie i dokumentowanie wydajności pamięci masowej Kubernetes.

Współpraca z Diamanti była wspaniała i pozwoliła nam na dogłębne zrozumienie Kubernetesa i pamięci masowej Kubernetesa, niezbędne do stworzenia naszej metodologii testowania. Firma Diamanti została założona przez byłych inżynierów VMware, VERITAS i Cisco, a jej finansowanie pochodzi od Goldman Sachs i innych znanych funduszy venture capital, co jest imponujące. Co więcej, Diamanti wniósł znaczący wkład w rozwój standardów pamięci masowej i sieci (a mianowicie FlexVolume/CSI i CNI), które zostały zaakceptowane w kodzie źródłowym Kubernetesa.

Biznes korporacyjny rozwija się z prędkością światła, a firmy starają się dotrzymać kroku tej ewolucji, wdrażając nowe technologie, aby przyspieszyć cały cykl produkcyjny aplikacji. Kontenery to technologia opracowana w celu przyspieszenia tworzenia i wdrażania aplikacji, ale ich budowanie w oparciu o starszą infrastrukturę może być skomplikowane i szybko staje się istotną przeszkodą w ustrukturyzowaniu w pełni funkcjonalnego stosu kontenerów. Kontenery są niekompatybilne z tradycyjną infrastrukturą pamięci masowej i sieci, dlatego podejście „zrób to sam” (DIY) do budowy środowiska kontenerowego jest wymagające dla działu IT, kosztowne i powolne. Platforma Diamanti Enterprise Kubernetes ma zapewnić architektom infrastruktury, działom IT i właścicielom aplikacji szybkość, prostotę, wydajność i kontrolę potrzebną do uruchamiania stanowych aplikacji kontenerowych na dużą skalę.

Platforma Diamanti Enterprise Kubernetes to platforma kontenerowa typu bare-metal, skoncentrowana na aspektach sieciowych i pamięci masowej, umożliwiająca szybkie uruchomienie, szczególnie w dużych przedsiębiorstwach. Dzięki pełnej integracji Dockera i Kubernetesa z rozwiązaniami open source, a także specjalnie zaprojektowanemu sprzętowi i pełnemu wsparciu dla całego stosu, platforma Diamanti Enterprise Kubernetes to kompletne rozwiązanie kontenerowe, które można wdrożyć w ciągu kilku minut. Firma Diamanti zapewnia niezrównaną wydajność i wykorzystanie swojej platformy Enterprise Kubernetes; sekretem tej wydajności jest wykorzystanie unikalnej, hiperkonwergentnej architektury, zaprojektowanej specjalnie z myślą o sposobie, w jaki kontenery Kubernetes korzystają z zasobów sieciowych i pamięci masowej.

Specyfikacja Diamanti D10

Sieć	4×10 GbE przez pojedyncze połączenie QSFP+ (na węzeł)
Dyski
Przechowywanie danych	Konfiguracja 4 TB (4 dyski SSD NVMe o pojemności 1000 GB na węzeł) Konfiguracja 8 TB (4 dyski SSD NVMe o pojemności 2000 GB na węzeł) Konfiguracja 32 TB (4 dyski SSD NVMe o pojemności 8000 GB na węzeł)
System operacyjny hosta i magazyn obrazów Docker	960 GB (2x 480 GB SATA SSD na węzeł)
obliczać
CPU	2 procesory Intel Xeon z 20 / 32 / 44 rdzeniami (na węzeł)
RAM	192 GB / 384 GB / 768 GB (na węzeł
Fizyczny
Form Factor	1U
Wymiary i waga (na węzeł)	17.25″ szer. x 28″ gł. x 1.72″ wys. / 52 funty. 43.8 cm x 71.1 cm x 4.4 cm / 24 kg
Zasilanie	Podwójne redundantne zasilacze 110/220 V
Środowiskowy	Temperatura robocza: od 50 ° F do 95 ° F (od 10 ° C do 35 ° C)

Budowa i projektowanie

Urządzenie Diamanti to fizyczny element rozwiązania stosu kontenerów Diamanti. Urządzenie to jest oferowane w klastrze co najmniej trzywęzłowym, gdzie każdy węzeł to szafa rack 1U, zapewniająca do 32 TB pojemności pamięci masowej oraz 960 GB na system operacyjny hosta i obraz Dockera.

Przód węzła przedstawia aluminiową osłonę zaprojektowaną z myślą o efektywnym przepływie powietrza, z logiem firmy pośrodku i w lewym górnym rogu mechanizmem blokującym. W prawym górnym rogu znajduje się panel sterowania z włącznikiem zasilania oraz diodami LED informującymi o stanie systemu. Po zdjęciu aluminiowej osłony widoczne są gniazda dysków, a także jeden port VGA i dwa porty USB.

Przechodząc do tyłu urządzenia, widzimy jego porty. Tutaj wyróżniamy dwa niezależne zasilacze po lewej stronie i wentylowany system; a pośrodku/po prawej stronie dwa porty zarządzania: port 10GbE do łączenia węzłów o wysokiej wydajności i niskich opóźnieniach, port QSFP+ (dla 4 portów 10G SFP+) oraz 4 porty USB do podłączenia klawiatury i innych urządzeń peryferyjnych.

Zarząd

Urządzenie jest dostarczane z preintegrowanym, pełnym stosem oprogramowania, obejmującym system operacyjny, Dockera, Kubernetesa i inne usługi konwergencji kontenerów. Udostępnia pulpity nawigacyjne i funkcje raportowania za pośrednictwem przeglądarki, interfejsu wiersza poleceń (CLI) lub interfejsu API REST oraz systemu operacyjnego Diamanti. Platforma Diamanti Enterprise Kubernetes posiada certyfikat K8S; certyfikat opracowany przez organizację CNCF.

Do zarządzania korzystamy z konsoli Diamanti. Po jej otwarciu przechodzimy bezpośrednio do pulpitu nawigacyjnego, który zawiera podstawowe, łatwe do odczytania informacje. Możemy tu sprawdzić liczbę uruchomionych węzłów, kontenerów i podów. Wykorzystanie procesora, pamięci masowej, pamięci i sieci jest również łatwo widoczne w procentach po lewej stronie. Po prawej stronie znajduje się przepustowość w kb/s.

Następną główną zakładką jest „Tworzenie aplikacji”. Gdy użytkownicy mają już aplikacje, które chcą utworzyć, pojawia się podzakładka „Wdrażanie” z ikonką Kubernetes. W tym miejscu użytkownicy muszą wprowadzić takie informacje, jak nazwa, obraz, środowisko, port, montowanie woluminów oraz ilość procesora i pamięci.

Następną główną zakładką są Aplikacje. Pod główną zakładką znajdują się podzakładki: Pody, Kontrolery replikacji, Zestawy replik, Zestawy stanowe, Zestawy demonów, Wdrożenia i Zadania. Pody zapewniają użytkownikom krótkie podsumowanie stanu wybranego poda, a także przypisanych mocy obliczeniowych, sieci i pamięci masowej.

Podzakładka „Zestawy stanowe” umożliwia użytkownikom bardziej szczegółowe przeglądanie zestawów i eksportowanie ich w razie potrzeby. Znajdują się tam podstawowe informacje, takie jak nazwa, przestrzeń nazw, żądany numer, bieżący numer, numer gotowy, wiek oraz opcje dotyczące działań do podjęcia.

Użytkownicy mogą również przeglądać dzienniki Pod, aby przeglądać aktywność i wszelkie potencjalne problemy.

Następną główną zakładką są Konfiguracje K8S. Tutaj użytkownicy mogą zarządzać konfiguracjami aplikacji powiązanych z Kubernetes, takimi jak konta usług, przeglądać sekrety, mapy konfiguracji oraz tworzyć przestrzenie nazw.

Na karcie „Administracja węzłami” użytkownicy mogą przeglądać, dodawać i usuwać węzły, a także monitorować wykorzystanie zasobów węzła. Tutaj również użytkownicy mogą monitorować ogólny stan danego węzła i zasobów: obliczeniowych, sieciowych i pamięci masowej.

Jak sugeruje nazwa zakładki, Administracja pamięcią masową umożliwia użytkownikom przeglądanie wszystkich informacji dotyczących pamięci masowej, w tym woluminów, migawek, dysków, woluminów trwałych, roszczeń do woluminów trwałych, klas pamięci masowej i kopii zapasowych. Na podzakładce Woluminy mamy możliwość utworzenia nowego woluminu lub wyświetlenia podsumowania istniejącego woluminu, w tym jego stanu, przepustowości i wykorzystania.

Podzakładka Dyski umożliwia użytkownikom przeglądanie danych dotyczących wykorzystania dysków fizycznych, takich jak gniazdo, numer seryjny, pojemność surowa, pojemność użytkowa, przydzielona pojemność, oprogramowanie układowe i stan dysku. Z poziomu tej podzakładki można formatować dyski.

Podzakładka Woluminy trwałe umożliwia użytkownikom tworzenie lub eksportowanie woluminów trwałych, a także podawanie informacji, takich jak nazwa, typ, pojemność, dostęp, odzyskiwanie, status, roszczenie, dostępność pamięci masowej, wiek oraz lista działań obejmujących edycję, eksport i usuwanie.

Funkcja Persistent Volume Claims wykonuje tę samą czynność w przypadku PVC.

Naszą kolejną główną kartą jest Administracja siecią. Tutaj użytkownicy mogą tworzyć, usuwać, edytować i eksportować sieci. Znajdują się tu takie informacje, jak nazwa, grupa, czy jest to sieć domyślna, sieć hosta, jej podsieć, brama, adres początkowy, adres końcowy oraz adres IP.

Zarządzanie użytkownikami jest dość proste. Administratorzy mogą tutaj tworzyć użytkowników i grupy oraz konfigurować różne zasady kontroli dostępu.

Ustawienia zaawansowane umożliwiają administratorom tworzenie i dostosowywanie poziomów klastra i wydajności.

Chociaż zazwyczaj omawiamy różne funkcje zarządzania, aby dać czytelnikom ogólne pojęcie, czego mogą się spodziewać podczas ich wykonywania, tym razem robimy coś nieco innego. Przeprowadziliśmy również testy porównawcze, aby zobaczyć, jak interfejs graficzny radzi sobie z większym obciążeniem. W przypadku każdego z tych testów porównawczych będziemy znajdować się w zakładce „Administracja węzła”.

Dzięki naszym podstawowym (losowym i sekwencyjnym) testom można łatwo zobaczyć po prawej stronie wykresy dotyczące obliczeń i wydajności.

Nasz test SQL spowodował stosunkowo niewielkie obciążenie zasobów obliczeniowych i sieciowych, podczas gdy wydajność pamięci masowej osiągnęła prawie 1 milion operacji wejścia/wyjścia na sekundę.

Na koniec podajemy przykład tego, czego można się spodziewać po uruchomieniu testu Oracle.

Wydajność

Analiza obciążenia VDBench

W przypadku testów porównawczych macierzy pamięci masowej, testy aplikacji są najlepsze, a testy syntetyczne plasują się na drugim miejscu. Chociaż testy syntetyczne nie odzwierciedlają idealnie rzeczywistych obciążeń, pomagają one w ustaleniu punktu odniesienia dla urządzeń pamięci masowej, zapewniając powtarzalność, która ułatwia bezpośrednie porównanie konkurencyjnych rozwiązań. Obciążenia te oferują szereg różnych profili testowych, od testów „czterech kątów” i testów rozmiaru transferu baz danych, po przechwytywanie śladów z różnych środowisk VDI. Wszystkie te testy wykorzystują generator obciążeń Vdbench z silnikiem skryptowym do automatyzacji i przechwytywania wyników w dużym klastrze obliczeniowym. Pozwala to na powtarzanie tych samych obciążeń dla szerokiej gamy urządzeń pamięci masowej, w tym macierzy flash i pojedynczych urządzeń pamięci masowej.

Profile:

Losowy odczyt 4K: 100% odczytu, 128 wątków, 0-120% ioratu
4K losowy zapis: 100% zapisu, 64 wątki, 0-120% ioracji
64K Sekwencyjny odczyt: 100% odczytu, 16 wątków, 0-120% ioracji
64K Sekwencyjny zapis: 100% zapisu, 8 wątków, 0-120% ioratu
Syntetyczna baza danych: SQL i Oracle

We wszystkich naszych testach VDBench testowaliśmy urządzenie Diamanti w oparciu o różne wdrożenia, uruchamiając 3, 6, 9 lub 12 podów Vdbench jednocześnie, aby przesunąć granice możliwości urządzenia. Zaczynając od losowej wydajności odczytu 4K, wszystkie pody Vdbench rozpoczęły z opóźnieniem 120 μs; a wydajność wejścia/wyjścia wahała się między 3 podami na poziomie 95 863 IOPS i 12 podami na poziomie 269 208 IOPS. Patrząc na szczytową wydajność, wszystkie konfiguracje utrzymywały się poniżej opóźnienia 600 μs. Przy 3 podach Vdbench zaobserwowaliśmy szczyt 947 619 IOPS przy opóźnieniu 370 μs; przy 6 podach szczyt 1 745 344 IOPS przy opóźnieniu 436 μs; z 9 kontenerami, szczytowa wydajność 2,492019 IOPS przy opóźnieniu 447 μs; a ostatnie wdrożenie, 12 kontenerów, osiągnęło szczytową wydajność 2,753,170 IOPS przy opóźnieniu 554 μs.

Analizując wydajność zapisu 4K, wszystkie wdrożenia testowe rozpoczęły się z opóźnieniem 300 μs, ale szybko wzrosły między 26 ms a 28 ms po osiągnięciu maksymalnej wydajności. Wydajność osiągnęła szczyt dla 3 podów: 13 719 IOPS; 6 podów: 27 747 IOPS; 9 podów: 42 805 IOPS; i 12 podów: 58 559 IOPS. Wykazano stały wzrost wydajności przy dodawaniu kolejnych podów.

Przechodząc do obciążeń sekwencyjnych, analizujemy wydajność odczytu 64 KB urządzenia. Wdrożenie 3 podów rozpoczęło się od 14 560 IOPS, czyli 910 MB/s, z opóźnieniem 297 μs. Wszystkie pozostałe wdrożenia rozpoczęły się od 18 000 IOPS, czyli 1.1 GB/s, z opóźnieniem 227 μs. Jeśli chodzi o szczytową wydajność wdrożeń, wdrożenie 3 podów osiągnęło szczyt na poziomie 143 431 IOPS, czyli 9 GB/s, z opóźnieniem 327 μs. Wszystkie pozostałe wdrożenia osiągnęły niemal ten sam szczyt, 179 000 IOPS, czyli 11.1 GB/s, przy czym wdrożenie 12 podów było jedynym, które przekroczyło próg opóźnienia 1 ms.

W przypadku zapisu sekwencyjnego 64 KB, wszystkie wdrożenia Vdbench rozpoczęły się z opóźnieniem bliskim 350 μs. Wdrożenia osiągnęły szczytowe wartości: 3 pody – 9,693 IOPS, czyli 606 MB/s, z opóźnieniem 4.9 ms; 6 podów – 22 202 IOPS, czyli 1.39 GB/s, z opóźnieniem 4.3 ms; 9 podów – 30 475 IOPS, czyli 1.9 GB/s, z opóźnieniem 4.7 ms; a na koniec 12 podów – 32 052 IOPS, czyli 2.4 GB/s, z opóźnieniem 4.9 ms.

Kolejny zestaw testów obejmuje obciążenia SQL: SQL, SQL 90-10 i SQL 80-20. W przypadku SQL wszystkie wdrożenia rozpoczęły się z opóźnieniem 180 μs. Trzy kontenery rozpoczęły się z wydajnością 26 291 IOPS, a szczytowe wartości IOPS wyniosły 261 573 IOPS, a opóźnienie wyniosło 366 μs. Sześć kontenerów rozpoczęło się z wydajnością 57 061 IOPS, a szczytowe wartości IOPS wyniosły 570 642 IOPS, a opóźnienie wyniosło 336 μs. Dziewięć kontenerów rozpoczęło się z wydajnością 86 197 IOPS, a szczytowe wartości IOPS wyniosły 885 269 IOPS, a opóźnienie wyniosło 332 μs. Wdrożenie 12 kontenerów rozpoczęło się z wydajnością 101 753 IOPS, a szczytowe wartości IOPS wyniosły 1 106 860 IOPS, a opóźnienie wyniosło 346 μs.

W przypadku SQL 90-10 wszystkie wdrożenia rozpoczęły się z opóźnieniem bliskim 200 μs. Wdrożenie 3 kontenerów rozpoczęło się z wydajnością 10 753 IOPS i osiągnęło szczyt 105 877 IOPS z opóźnieniem 904 μs. 6 kontenerów rozpoczęło się z wydajnością 49 361 IOPS i osiągnęło szczyt 245 158 IOPS z opóźnieniem 782 μs. 9 kontenerów rozpoczęło się z wydajnością 80 157 IOPS i osiągnęło szczyt 401 444 IOPS z opóźnieniem 716 μs. Wdrożenie 12 kontenerów rozpoczęło się z wydajnością 55 748 IOPS i osiągnęło szczyt 554 685 IOPS z opóźnieniem 690 μs.

W naszym ostatnim teście SQL, 80-20, zaobserwowaliśmy, że wdrożenia Vdbench również rozpoczęły się z opóźnieniem bliskim 200 μs. Wdrożenia charakteryzowały się następującymi szczytowymi wartościami: wdrożenie 3 kontenerów przyniosło 57 944 IOPS z opóźnieniem 1.6 ms; wdrożenie 6 kontenerów przyniosło 132 384 IOPS z opóźnieniem 1.4 ms; wdrożenie 9 kontenerów przyniosło 217 273 IOPS z opóźnieniem 1.3 ms; a wdrożenie 12 kontenerów przyniosło 305 426 IOPS z opóźnieniem 1.2 ms.

Następnie mamy nasze obciążenia Oracle: Oracle, Oracle 90-10 i Oracle 80-20. W przypadku Oracle wszystkie wdrożenia rozpoczęły się poniżej 210 μs. Tutaj widzimy szczytową wydajność wdrożeń. Trzy kontenery osiągnęły szczytową wydajność 54 844 IOPS z opóźnieniem 2.2 ms. Sześć kontenerów osiągnęło szczytową wydajność 125 633 IOPS z opóźnieniem 1.9 ms. Dziewięć kontenerów osiągnęło szczytową wydajność 206 024 IOPS z opóźnieniem 1.7 ms. Wdrożenie 12 kontenerów osiągnęło szczytową wydajność 290 313 IOPS z opóźnieniem 1.6 ms.

W Oracle 90-10 wdrożenia rozpoczęły się poniżej 200 μs. Wdrożenie 3 podów osiągnęło szczytową wydajność 106 182 IOPS z opóźnieniem 620 μs. 6 podów osiągnęło szczytową wydajność 243 383 IOPS z opóźnieniem 541 μs. 9 podów osiągnęło szczytową wydajność 393 727 IOPS z opóźnieniem 502 μs. Wreszcie, wdrożenie 12 podów osiągnęło szczytową wydajność 544 584 IOPS z opóźnieniem 483 μs.

W przypadku Oracle 80-20 ponownie zaobserwowaliśmy, że wszystkie wdrożenia rozpoczynały się od opóźnienia 210 μs. Patrząc na szczytową wydajność wdrożeń, widzimy, że 3 kontenery osiągnęły szczyt 58 037 IOPS z opóźnieniem 1.1 ms; 6 kontenerów osiągnęło szczyt 132 911 IOPS z opóźnieniem 991 μs; 9 kontenerów osiągnęło szczyt 215 817 IOPS z opóźnieniem 915 μs; i wreszcie, wdrożenie 12 kontenerów osiągnęło szczyt 304 391 IOPS z opóźnieniem 865 μs.

Wniosek

Kubernetes zyskał akceptację mniejszych firm i obecnie dojrzewa do technologii, którą większość, jeśli nie wszystkie firmy z listy Fortune 500, rozważa, a niektóre z bardziej przyszłościowych zaczynają ją wdrażać. Kubernetes istnieje zaledwie od 5 lat, ale przeszedł fazę innowacyjną na krzywej adopcji technologii i zdecydowanie znajduje się w obozie wczesnych użytkowników. To pozycjonowanie na krzywej adopcji technologii ma znaczenie, ponieważ społeczność Kubernetes odkryła, jak uruchomić Kubernetesa i teraz koncentruje się na jego sprawnym działaniu. Mamy nadzieję, że takie testy pomogą użytkownikom Kubernetesa w wyborze dostawców i pomogą im, dając im standard do porównania.

Firma Diamanti stworzyła przekonujące rozwiązanie Kubernetes z urządzeniem kontenerowym D10, oferując przejrzysty i prosty w obsłudze interfejs zarządzania oraz bardzo szybką platformę pamięci masowej back-end do hostowania kontenerów. Ponieważ jest to wciąż rozwijająca się dziedzina, na rynku nie ma zbyt wielu w pełni dopracowanych rozwiązań, ale z tego, co widzieliśmy, D10 spełnia wszystkie nasze oczekiwania wobec rozwiązań pamięci masowej lub HCI. Wydajność jest generalnie fantastyczna, oferując ponad 2.7 miliona IOPS w losowym odczycie 4K z naszego klastra testującego od 3 do 12 kontenerów. Z perspektywy opóźnień zaczęliśmy od nieco ponad 100 mikrosekund i osiągnęliśmy szczyt na poziomie 600 mikrosekund. Pod względem pamięci masowej jest to niezwykle wydajne, a jak na rozwijającą się platformę technologiczną, wręcz niesamowite. Z perspektywy zapisu urządzenie oferowało 50 tysięcy IOPS w losowym odczycie 4K, co wydaje się być jedyną słabością, ale firma powinna być w stanie rozwiązać ten problem za pomocą oprogramowania, a może nawet nośników danych. Sekwencyjna przepustowość zapewniała prędkość odczytu przekraczającą 11 GB/s, co również stanowi bardzo dobrą i użyteczną wydajność, a prędkość zapisu w szczytowych momentach wynosiła 2.4 GB/s.

Ogólnie rzecz biorąc, dla klientów wdrażających Kubernetes w swoim środowisku, urządzenie kontenerowe Diamanti D10 oferuje świetne, gotowe rozwiązanie z perspektywy hostingu i pamięci masowej dla tych, którzy chcą poważnie przyjrzeć się rynkowi szybkich i luźnych kontenerów. Szczerze mówiąc, nie jest to rozwiązanie dla każdego, klaster jest dość specyficzny w swoim przeznaczeniu. Ale jeśli pasujesz do tego celu, Diamanti oferuje dokładnie to, czego chcą ci klienci – jest ono specjalnie zaprojektowane do tego typu pojawiających się obciążeń kontenerowych. Chociaż oczywiście jest całkowicie możliwe wykorzystanie PKS dla VMware lub alternatywnych rozwiązań, które są bardziej zorientowane na przedsiębiorstwa, Diamanti oferuje system o niskiej złożoności i powinien mieć przewagę kosztową nad tradycyjnymi stosami korporacyjnymi. Ze względu na kompletność rozwiązania (ma dobry interfejs graficzny dla odmiany) i bardzo dobry profil wydajności, uznaliśmy D10 za godnego zwycięzcę nagrody StorageReview Editor's Choice Award.