🥇Hiperkonwergentne rozwiązanie AERODISK vAIR. Podstawa — system plików ARDFS

Cześć, czytelnicy Habra. Tym artykułem otwieramy cykl, który będzie opowiadać o opracowanym przez nas hiperkonwergentnym systemie AERODISK vAIR. Początkowo chcieliśmy w pierwszym artykule opisać wszystko, ale system jest dość skomplikowany, dlatego będziemy jeść słonia po kawałku.

Rozpoczniemy opowieść od historii powstania systemu, zagłębimy się w system plików ARDFS, który stanowi podstawę vAIR, a także nieco porozmawiamy o pozycjonowaniu tego rozwiązania na rosyjskim rynku.

W kolejnych artykułach szczegółowo opowiemy o różnych komponentach architektonicznych (klaster, hipernadzorca, serwer równoważący obciążenie, system monitorowania itp.), procesie konfiguracji, poruszymy kwestie licencjonowania, osobno pokażemy testy wytrzymałościowe i, oczywiście, napiszemy o testowaniu obciążenia i sizingu. Osobny artykuł poświęcimy wersji community vAIR.

AERODISK — czy to historia o systemach pamięci masowej? A może po co w ogóle zaczęliśmy zajmować się hiperkonwergencją?

Początkowa idea stworzenia własnej hiperkonwergencji przyszła do nas gdzieś w okolicach 2010 roku. Wtedy jeszcze nie było ani AERODISK, ani podobnych rozwiązań (komercyjnych, gotowych systemów hiperkonwergentnych) na rynku. Naszym zadaniem było następujące: z zestawu serwerów z lokalnymi dyskami, połączonych interkonektami przez protokół Ethernet, trzeba było stworzyć rozproszone magazynowanie i jednocześnie uruchamiać maszyny wirtualne i sieć programową. Wszystko to musiało być zrealizowane bez systemów pamięci masowej (ponieważ na systemy pamięci masowej i ich otoczenie po prostu nie było pieniędzy, a własnego systemu pamięci masowej jeszcze nie wynaleźliśmy).

Wypróbowaliśmy wiele rozwiązań open source i w końcu rozwiązaliśmy to zadanie, ale rozwiązanie było bardzo skomplikowane i trudno było je powtórzyć. Ponadto rozwiązanie to było z rodzaju „Działa? Nie ruszaj!”. Dlatego, rozwiązując ten problem, nie postanowiliśmy dalej rozwijać idei przekształcania efektów naszej pracy w pełnoprawny produkt.

Po tym doświadczeniu odeszliśmy od tej idei, ale nadal nie opuszczało nas wrażenie, że zadanie to jest całkowicie wykonalne, a korzyści z takiego rozwiązania są więcej niż oczywiste. W późniejszym czasie wydane przez zagraniczne firmy produkty HCI tylko potwierdziły to wrażenie.

W połowie 2016 roku wróciliśmy do tego zadania w ramach tworzenia kompleksowego produktu. Wówczas nie mieliśmy jeszcze żadnych relacji z inwestorami, więc musieliśmy kupić stoisko deweloperskie za nasze dość niewielkie pieniądze. Zbierając używane serwery i przełączniki na Avito, zabraliśmy się do pracy.

Głównym zadaniem na początku było stworzenie własnego, choć prostego, systemu plików, który byłby w stanie automatycznie i równomiernie rozdzielać dane w postaci wirtualnych bloków na n-liczbie węzłów klastra, które były połączone interkonektami przez Ethernet. Przy tym system plików powinien być dobrze i łatwo skalowalny oraz niezależny od systemów sąsiednich, tzn. wydzielony z vAIR w formie „po prostu magazynu”.

Pierwsza koncepcja vAIR

Zdecydowanie zrezygnowaliśmy z używania gotowych rozwiązań open source do organizacji rozproszonego magazynu (ceph, gluster, lustre i podobne) na rzecz własnego rozwiązania, ponieważ mieliśmy z nimi wiele doświadczenia projektowego. Oczywiście te rozwiązania same w sobie są doskonałe i do pracy nad Aerodyskiem zrealizowaliśmy z nimi nie jeden projekt integracyjny. Jednak co innego – zrealizować konkretne zadanie jednego klienta, wyszkolić personel i być może wykupić wsparcie dużego dostawcy, a co innego – stworzyć łatwo reprodukowalny produkt, który będzie używany do różnych zadań, o których my, jako dostawca, być może nawet sami nie będziemy wiedzieć. Do drugiego celu istniejące produkty open source nie pasowały, dlatego postanowiliśmy samodzielnie rozwijać rozproszony system plików.
Po dwóch latach prac kilku deweloperów (którzy łączyli pracę nad vAIR z pracą nad klasycznym systemem macierzy Engine) osiągnęliśmy określony wynik.

Do 2018 roku napisaliśmy najprostszy system plików i uzupełniliśmy go niezbędnym otoczeniem. System łączył fizyczne (lokalne) dyski z różnych serwerów w jeden płaski pul i „ucinał” je na wirtualne bloki, a następnie z tych wirtualnych bloków tworzone były urządzenia blokowe o różnym stopniu odporności na awarie, na których za pomocą hipernadzorcy KVM tworzone i uruchamiane były maszyny wirtualne.

Nie skupialiśmy się zbytnio na nazwie systemu plików, nazwa została zwięźle określona jako ARDFS (zgadnijcie, co to znaczy))

Ten prototyp wyglądał dobrze (nie wizualnie, oczywiście, wizualizacja wtedy nie istniała) i wykazywał dobre wyniki pod względem wydajności i skalowalności. Po pierwszych realnych rezultatach przeszliśmy do realizacji tego projektu, organizując już pełnoprawne środowisko deweloperskie oraz oddzielny zespół, który zajmował się wyłącznie vAIR-em.

Właśnie wtedy dojrzała ogólna architektura rozwiązania, która do dziś nie uległa poważnym zmianom.

Zanurzamy się w system plików ARDFS

ARDFS stanowi podstawę vAIR, zapewniając rozproszone, odporne na awarie przechowywanie danych całego klastra. Jedną z (ale nie jedyną) wyróżniających cech ARDFS jest to, że nie wykorzystuje żadnych dodatkowych dedykowanych serwerów podsystemów i zarządzania. Tak zaplanowano na początku, aby uprościć konfigurację rozwiązania i zwiększyć jego niezawodność.

Struktura przechowywania

Wszystkie węzły klastra ARDFS organizują logiczny pul z całej dostępnej przestrzeni dyskowej. Ważne jest zrozumienie, że pul to jeszcze nie dane i nie sformatowana przestrzeń, a jedynie mapowanie, tzn. jakiekolwiek węzły z zainstalowanym vAIR-em, po dodaniu do klastra, automatycznie dołączają do wspólnego pulu ARDFS, a zasoby dyskowe stają się automatycznie wspólne na cały klaster (i dostępne do przyszłego przechowywania danych). Takie podejście pozwala na dodawanie i usuwanie węzłów w locie bez jakiegokolwiek poważnego wpływu na już działający system. Tzn. system jest bardzo łatwy do skalowania „cegłami”, dodając lub usuwając węzły w klastrze w razie potrzeby.

Na pul ARDFS dodawane są wirtualne dyski (obiekty przechowywania dla maszyn wirtualnych), które budowane są z wirtualnych bloków o wielkości 4 megabajty. Na wirtualnych dyskach bezpośrednio przechowywane są dane. Na poziomie wirtualnych dysków określa się również schemat odporności na awarie.

Jak można się było domyślić, w celu zapewnienia odporności na awarie w systemie dyskowym nie używamy koncepcji RAID (Redundant Array of Independent Disks), lecz RAIN (Redundant Array of Independent Nodes). Oznacza to, że odporność na awarie jest mierzona, automatyzowana i zarządzana na podstawie węzłów, a nie dysków. Dyski, oczywiście, również są obiektami przechowywania, są monitorowane jak wszystko inne, można na nich wykonywać wszystkie standardowe operacje, w tym tworzyć lokalny sprzętowy RAID, ale klaster operuje na węzłach.

W sytuacji, gdy bardzo zależy nam na RAID (na przykład w scenariuszu obsługującym wiele awarii na małych klastrach), nic nie stoi na przeszkodzie, aby używać lokalnych kontrolerów RAID, a na to budować rozproszone przechowywanie i architekturę RAIN. Taki scenariusz jest jak najbardziej realny i wspierany przez nas, dlatego opowiemy o nim w artykule na temat typowych scenariuszy zastosowania vAIR.

Schematy odporności na awarie przechowywania

Schematów odporności na awarie wirtualnych dysków w vAIR może być dwa:

1) Współczynnik replikacji lub po prostu replikacja – ta metoda odporności na awarie jest prosta „jak kij i sznur”. Wykonywana jest synchroniczna replikacja między węzłami z czynnikiem 2 (2 kopie w klastrze) lub 3 (3 kopie, odpowiednio). RF-2 pozwala wirtualnemu dyskowi wytrzymać awarię jednego węzła w klastrze, ale „zjada” połowę użytecznej pojemności, a RF-3 wytrzyma awarię 2 węzłów w klastrze, ale zarezerwuje już 2/3 użytecznej pojemności na swoje potrzeby. Ten schemat przypomina RAID-1, to znaczy wirtualny dysk skonfigurowany w RF-2 jest odporny na awarię dowolnego jednego węzła klastra. W takim przypadku dane będą w porządku i nawet operacje wejścia/wyjścia się nie zatrzymają. Kiedy uszkodzony węzeł wróci do działania, zacznie się automatyczna odbudowa/synchronizacja danych.

Poniżej znajdują się przykłady rozkładu danych RF-2 i RF-3 w normalnym trybie oraz w sytuacji awarii.

Posiadamy maszynę wirtualną o objętości 8 MB unikalnych (przydatnych) danych, która działa na 4 węzłach vAIR. Oczywiście w rzeczywistości taki mały wolumen będzie rzadkością, ale w przypadku schematu ilustrującego logikę działania ARDFS, ten przykład jest najbardziej zrozumiały. AB to wirtualne bloki po 4 MB, zawierające unikalne dane maszyny wirtualnej. Przy RF-2 tworzone są dwie kopie tych bloków A1+A2 oraz B1+B2 odpowiednio. Bloki te są „rozkładane” po węzłach, unikając powielania tych samych danych na jednym węźle, co oznacza, że kopia A1 nie będzie znajdować się na tym samym węźle co kopia A2. B1 i B2 są podobnie traktowane.

W przypadku awarii jednego z węzłów (na przykład węzła nr 3, na którym znajduje się kopia B1), ta kopia automatycznie aktywuje się na węźle, na którym nie ma kopii jej kopii (czyli kopii B2).

W ten sposób wirtualny dysk (i VM odpowiednio) bez trudu przeżyje awarię jednego węzła w schemacie RF-2.

Schemat replikacji, mimo swojej prostoty i niezawodności, ma tę samą wadę co RAID1 – mało przydatnej przestrzeni.

2) Kodowanie usuwające (ang. Erasure coding), znane również jako „kodowanie nadmiarowe” lub „kodowanie zerowania”, zostało stworzone, aby rozwiązać powyższy problem. EC to schemat nadmiarowości, który zapewnia wysoką dostępność danych przy mniejszych kosztach przestrzeni dyskowej w porównaniu do replikacji. Zasada działania tego mechanizmu jest podobna do RAID 5, 6, 6P.

Podczas kodowania proces EC dzieli wirtualny blok (domyślnie 4 MB) na kilka mniejszych „kawałków danych” w zależności od schematu EC (na przykład schemat 2+1 dzieli każdy blok 4 MB na 2 kawałki po 2 MB). Następnie proces generuje dla „kawałków danych” „kawałki parzystości” o wielkości nie większej niż jedna z wcześniej podzielonych części. Podczas dekodowania EC generuje brakujące kawałki, odczytując „przetrwałe” dane w całym klastrze.

Na przykład wirtualny dysk z schematem EC 2 + 1, realizowany na 4 węzłach klastra, bez trudu wytrzyma awarię jednego węzła w klastrze, tak jak RF-2. Przy tym koszty ogólne będą niższe, współczynnik efektywnej pojemności przy RF-2 wynosi 2, a przy EC 2+1 wyniesie 1,5.

Mówiąc prościej, istota polega na tym, że wirtualny blok jest dzielony na 2-8 (dlaczego od 2 do 8, patrz poniżej) „kawałków”, a dla tych kawałków obliczane są „kawałki” parzystości o podobnej wielkości.

W rezultacie dane i parzystość są równomiernie rozłożone na wszystkich węzłach klastra. Jak przy replikacji, ARDFS automatycznie rozprowadza dane po węzłach w taki sposób, aby uniemożliwić przechowywanie identycznych danych (kopii danych i ich parzystości) na jednym węźle, by wykluczyć ryzyko utraty danych w przypadku awarii węzła, który przechowuje zarówno dane, jak i ich parzystość.

Poniżej przykład z tą samą wirtualną maszyną o pojemności 8 MB i 4 węzłami, tym razem w schemacie EC 2+1.

Bloki A i B dzielą się na dwa kawałki po 2 MB każdy (na dwa, ponieważ 2+1), czyli na A1+A2 i B1+B2. W przeciwieństwie do repliki, A1 nie jest kopią A2, to wirtualny blok A podzielony na dwie części, to samo dotyczy bloku B. W sumie otrzymujemy dwa zestawy po 4 MB, z których w każdym znajdują się dwa dwumegabajtowe kawałki. Następnie dla każdego z tych zestawów obliczana jest parzystość o objętości nie przekraczającej jednego kawałka (tzn. 2 MB), co daje dodatkowo + 2 kawałki parzystości (A-P i B-P). W sumie mamy 4×2 danych + 2×2 parzystości.

Następnie kawałki są "układane" po węzłach tak, aby dane nie pokrywały się z ich parzystością. Tzn. A1 i A2 nie będą leżały na tym samym węźle co A-P.

W przypadku awarii jednego węzła (na przykład trzeciego) upadły blok B1 zostanie automatycznie przywrócony z parzystości B-P, która jest przechowywana na węźle nr 2, i zostanie aktywowany na węźle, gdzie nie ma parzystości B, tzn. kawałka B-P. W tym przykładzie jest to węzeł nr 1.

Jestem pewien, że czytelnik zadaje sobie pytanie:

„Wszystko, co opisaliście, zostało już dawno wdrożone przez konkurencję i w rozwiązaniach open source, jaka jest różnica waszej realizacji EC w ARDFS?”

A potem przedstawimy ciekawe cechy działania ARDFS.

Kodowanie usunięć z naciskiem na elastyczność

Początkowo przewidzieliśmy dość elastyczny schemat EC X+Y, gdzie X wynosi od 2 do 8, a Y od 1 do 8, zawsze mniejsze lub równe X. Taki schemat jest zaprojektowany dla elastyczności. Zwiększenie liczby kawałków danych (X), na które dzieli się wirtualny blok, pozwala na zmniejszenie kosztów ogólnych, a tym samym zwiększenie pojemności użytkowej.
Zwiększenie liczby kawałków parzystości (Y) zwiększa niezawodność wirtualnego dysku. Im większa wartość Y, tym więcej węzłów w klastrze może ulec awarii. Oczywiście, zwiększenie objętości parzystości zmniejsza pojemność użytkową, ale to cena za niezawodność.

Zależność wydajności od schematów EC jest niemal liniowa: im więcej „fragmentów”, tym niższa wydajność. W tym przypadku potrzebne jest zrównoważone podejście.

Takie podejście pozwala administratorom na maksymalnie elastyczną konfigurację rozciągniętej pamięci. W obrębie puli ARDFS można stosować dowolne schematy odporności na błędy i ich kombinacje, co naszym zdaniem jest bardzo użyteczne.

Poniżej znajduje się tabela porównawcza kilku (nie wszystkich możliwych) schematów RF i EC.

Z tabeli wynika, że nawet najbardziej „zaawansowana” kombinacja EC 8+7, pozwalająca na utratę jednocześnie do 7 węzłów w klastrze, „zużywa” mniej użytecznej przestrzeni (1,875 w porównaniu do 2), niż standardowa replikacja, jednocześnie chroniąc 7 razy lepiej, co sprawia, że ten mechanizm ochrony, choć bardziej złożony, jest znacznie bardziej atrakcyjny w sytuacjach, gdy konieczne jest zapewnienie maksymalnej niezawodności przy braku miejsca na dysku. Należy jednak pamiętać, że każdy „plus” do X lub Y będzie generował dodatkowe obciążenie wydajności, dlatego w trójkącie między niezawodnością, oszczędnością a wydajnością należy dokonywać bardzo ostrożnych wyborów. Z tego powodu poświęcimy oddzielny artykuł do rozmiarowania usuwającego kodowania.

Niezawodność i autonomiczność systemu plików

ARDFS uruchamia się lokalnie na wszystkich węzłach klastra i synchronizuje je za pomocą dedykowanych interfejsów Ethernet. Ważnym punktem jest to, że ARDFS samodzielnie synchronizuje nie tylko dane, ale także metadane związane z przechowywaniem. Podczas pracy nad ARDFS równolegle badaliśmy szereg istniejących rozwiązań i odkryliśmy, że wiele z nich synchronizuje metadane systemu plików za pomocą zewnętrznej rozproszonej bazy danych, którą również wykorzystujemy do synchronizacji, ale tylko konfiguracji, a nie metadanych FS (o tym oraz innych pokrewnych podsystemach w następnym artykule).

Synchronizacja metadanych systemu plików z użyciem zewnętrznej bazy danych to rozwiązanie, które z pewnością działa, ale wówczas spójność danych przechowywanych na ARDFS zależałaby od zewnętrznej bazy danych i jej zachowań (a ta, mówiąc szczerze, bywa kapryśna), co według nas jest złym pomysłem. Dlaczego? Jeśli metadane systemu plików ulegną uszkodzeniu, to także same dane systemu plików będą mogły być uznane za stracone, dlatego zdecydowaliśmy się na bardziej skomplikowaną, ale niezawodną drogę.

Podsystem synchronizacji metadanych dla ARDFS stworzyliśmy sami, a funkcjonuje on całkowicie niezależnie od innych podsystemów. Innymi słowy, żaden inny podsystem nie może uszkodzić danych ARDFS. Uważamy, że to najbardziej niezawodna i poprawna droga, a jak jest naprawdę, czas pokaże. Ponadto taki sposób działania ma dodatkową zaletę. ARDFS można używać niezależnie od vAIR, po prostu jako rozszerzonej pamięci, co z pewnością wykorzystamy w naszych przyszłych produktach.

Ostatecznie, opracowując ARDFS, uzyskaliśmy elastyczny i niezawodny system plików, dający wybór między oszczędnościami na pojemności a pełną wydajnością lub stworzeniem niezwykle niezawodnego magazynu za rozsądne pieniądze, ale przy niższych wymaganiach dotyczących wydajności.

Razem z prostą polityką licencjonowania i elastycznym modelem dostarczania (dla jasności, licencjonowanie vAIR odbywa się na węzłach, a dostarczanie może być realizowane jako oprogramowanie lub paczka) umożliwia to bardzo precyzyjne dopasowanie rozwiązania do różnych wymagań klientów oraz późniejsze łatwe utrzymanie tego balansu.

Kto potrzebuje tego cudu?

Z jednej strony można powiedzieć, że na rynku są już gracze z poważnymi rozwiązaniami w dziedzinie hiperłączności i pytanie, dlaczego my się tam pchamy. Wydaje się, że to twierdzenie jest prawdziwe, ALE…

Z drugiej strony, gdy wychodzimy "w teren" i rozmawiamy z klientami, my i nasi partnerzy widzimy, że wcale tak nie jest. Jest wiele zadań dla hiperłączności, gdzie ludzie po prostu nie wiedzieli, że takie rozwiązania istnieją, w niektórych miejscach wydawało się to drogie, w innych były nieudane testy alternatywnych rozwiązań, a gdzie indziej zakup jest wręcz zabroniony z powodu sankcji. Ogólnie rzecz biorąc, pole okazało się niezaorane, dlatego postanowiliśmy zacząć go uprawiać))).

Kiedy SAN jest lepszy niż HCI?

W trakcie pracy z rynkiem często pytają nas, kiedy najlepiej zastosować klasyczny schemat z macierzą dyskową, a kiedy – hiperłączność? Wiele firm – producentów HCI (szczególnie tych, które nie mają w swoim portfolio macierzy) mówi: „Macierz dyskowa odchodzi w zapomnienie, hiperłącze tylko!”. To odważne stwierdzenie, ale nie całkowicie odzwierciedla rzeczywistość.

Prawdę mówiąc, rynek macierzy dyskowych rzeczywiście przesuwa się w stronę hiperłącznych rozwiązań, ale zawsze jest „ale”.

Po pierwsze, zbudowane centra danych i infrastruktury IT w klasycznym schemacie z macierzą dyskową nie tak łatwo przebudować, więc modernizacja i rozbudowa takich infrastruktury to jeszcze spadek na 5-7 lat.

Po drugie, te infrastruktury, które obecnie powstają w większości (mowa o Rosji) budowane są w klasycznym schemacie z użyciem macierzy dyskowej, nie dlatego, że ludzie nie wiedzą o hiperłączu, ale dlatego, że rynek hiperłączności jest nowy, rozwiązania i standardy jeszcze nie ustabilizowane, specjaliści IT nie są jeszcze przeszkoleni, doświadczenie jest małe, a budować centra danych trzeba tu i teraz. I ta tendencja jeszcze potrwa 3-5 lat (a potem jeszcze spadek, patrz punkt 1).

Po trzecie, czysto techniczne ograniczenie w dodatkowych opóźnieniach wynoszących 2 milisekundy na zapis (nie wliczając lokalnej pamięci podręcznej, oczywiście), które są ceną za rozproszone przechowywanie.

Nie zapominajmy również o wykorzystaniu dużych fizycznych serwerów, które preferują wertykalne skalowanie systemu dyskowego.

Istnieje wiele potrzebnych i popularnych zadań, w których macierz dyskowa sprawuje się lepiej niż HCI. Oczywiście producenci, którzy nie mają macierzy w swoim portfolio, nie zgodzą się z nami, ale jesteśmy gotowi na rzeczową dyskusję. Naturalnie, jako twórcy obu produktów, w jednym z przyszłych publikacji porównamy macierz dyskową i HCI, gdzie wyraźnie pokażemy, w jakich warunkach lepiej się sprawdzają.

A gdzie rozwiązania hiperłączne będą działały lepiej niż macierz dyskowa?

Na podstawie powyższych tez można wyciągnąć trzy oczywiste wnioski:

Tam, gdzie dodatkowe 2 milisekundy opóźnienia na zapis, które stabilnie występują w każdej produkcji (teraz nie mówimy o syntetyce, w syntetyce można pokazać nawet nanosekundy), są niekrytyczne, hiperłącze będzie odpowiednie.
Tam, gdzie obciążenie z dużych fizycznych serwerów można przekształcić w wiele małych wirtualnych i rozdzielić po nodach, tam również hiperkonwergencja dobrze się sprawdzi.
Tam, gdzie skalowanie poziome jest bardziej priorytetowe niż poziome, tam również GKS sprawdzą się świetnie.

Jakie to rozwiązania?

Wszystkie standardowe usługi infrastrukturalne (usługa katalogowa, poczta, SED, serwery plików, małe lub średnie systemy ERP i BI itd.). Nazywamy to "wspólnym przetwarzaniem".
Infrastruktura dostawców chmurowych, gdzie konieczne jest szybkie i znormalizowane rozszerzanie poziome oraz łatwe "cięcie" dużej liczby maszyn wirtualnych dla klientów.
Infrastruktura wirtualnych pulpitów (VDI), gdzie uruchamiane są małe wirtualne maszyny użytkowników, które swobodnie "dryfują" w jednolitym klastrze.
Sieci filia, gdzie w każdej filii potrzebna jest standardowa, odporna na awarie, ale jednocześnie niedroga infrastruktura z 15-20 maszyn wirtualnych.
Jakiekolwiek rozproszone obliczenia (usługi big data, na przykład). Tam, gdzie obciążenie idzie nie "w głąb", a "w szerz".
Środowiska testowe, gdzie dopuszczalne są dodatkowe małe opóźnienia, ale są ograniczenia budżetowe, ponieważ to są testy.

Na chwilę obecną właśnie w tych zadaniach stworzyliśmy AERODISK vAIR i na nich dokładamy szczególną wagę (jak na razie z sukcesem). Możliwe, że wkrótce się to zmieni, ponieważ świat nie stoi w miejscu.