Ten artykuł został napisany, aby pomóc Ci wybrać odpowiednie dla siebie rozwiązanie i zrozumieć różnice pomiędzy SDS takimi jak Gluster, Ceph i Vstorage (Virtuozzo).
W tekście zastosowano linki do artykułów, w których bardziej szczegółowo opisano niektóre problemy, dlatego opisy będą możliwie zwięzłe, z wykorzystaniem kluczowych punktów, bez zbędnych zbędnych bzdur i informacji wprowadzających, które możesz, jeśli chcesz, samodzielnie uzyskać w Internecie.
Tak naprawdę poruszane tematy wymagają oczywiście tonu tekstu, jednak we współczesnym świecie coraz więcej osób nie lubi dużo czytać))), więc można szybko przeczytać i dokonać wyboru, a jeśli już coś się stanie nie jest jasne, skorzystaj z linków lub wpisz w Google niejasne słowa))), a ten artykuł jest jak przezroczyste opakowanie na te głębokie tematy, pokazując wypełnienie - główne kluczowe punkty każdej decyzji.
Błyszczący
Zacznijmy od Glustera, z którego aktywnie korzystają producenci platform hiperkonwergentnych z SDS opartym na open source dla środowisk wirtualnych i znajdziemy go na stronie RedHat w sekcji pamięci masowej, gdzie do wyboru są dwie opcje SDS: Gluster lub Ceph.
Gluster składa się ze stosu tłumaczy - usług, które wykonują całą pracę związaną z dystrybucją plików itp. Brick to usługa obsługująca jeden dysk, Volume to wolumen (pula), który łączy te cegły. Następna jest usługa dystrybucji plików w grupy za pomocą funkcji DHT (distributed hash table). W opisie nie uwzględnimy usługi Sharding, gdyż poniższe linki opisują problemy z nią związane.
Podczas zapisu cały plik jest zapisywany w cegle i jednocześnie jego kopia jest zapisywana w cegle na drugim serwerze. Następnie drugi plik zostanie zapisany w drugiej grupie dwóch cegieł (lub więcej) na różnych serwerach.
Jeśli pliki są w przybliżeniu tego samego rozmiaru, a wolumin składa się tylko z jednej grupy, wszystko jest w porządku, ale w innych warunkach z opisów pojawią się następujące problemy:
- przestrzeń w grupach jest wykorzystywana nierównomiernie, zależy to od wielkości plików i jeśli w grupie nie ma wystarczającej ilości miejsca na zapis pliku, zostanie wyświetlony komunikat o błędzie, plik nie zostanie zapisany i nie zostanie przesłany do innej grupy ;
- podczas zapisywania jednego pliku IO trafia tylko do jednej grupy, reszta jest bezczynna;
- nie można uzyskać operacji we/wy całego woluminu podczas zapisywania jednego pliku;
- a ogólna koncepcja wygląda na mniej produktywną ze względu na brak podziału danych na bloki, gdzie łatwiej jest zbilansować i rozwiązać problem równomiernego rozkładu, a nie jak teraz cały plik trafia do bloku.
Z oficjalnego opisu mimowolnie dochodzimy do wniosku, że gluster działa jako magazyn plików na klasycznym sprzętowym RAID. Podejmowano próby rozwojowe polegające na cięciu plików (shardingu) na bloki, ale wszystko to jest dodatkiem, który powoduje straty wydajności w już istniejącym podejściu architektonicznym, plus wykorzystanie takich swobodnie dystrybuowanych komponentów z ograniczeniami wydajności, jak Fuse. Nie ma usług metadanych, co ogranicza wydajność i odporność magazynu na błędy podczas dystrybucji plików w blokach. Lepsze wskaźniki wydajności można zaobserwować w przypadku konfiguracji „Rozproszona replikacja”, a liczba węzłów powinna wynosić co najmniej 6, aby zorganizować niezawodną replikę 3 z optymalnym rozkładem obciążenia.
Ustalenia te są również powiązane z opisem doświadczeń użytkownika i w porównaniu z , znajduje się tam także opis doświadczeń prowadzących do zrozumienia tej bardziej produktywnej i niezawodnej konfiguracji
Na obrazku widać rozkład obciążenia podczas zapisywania dwóch plików, gdzie kopie pierwszego pliku są rozłożone na pierwszych trzech serwerach, które są łączone w grupę woluminów 0, a trzy kopie drugiego pliku są umieszczane na drugiej grupie wolumin 1 z trzech serwery. Każdy serwer ma jeden dysk.
Ogólny wniosek jest taki, że można używać Glustera, ale ze świadomością, że wystąpią ograniczenia wydajności i odporności na awarie, które powodują trudności w pewnych warunkach rozwiązania hiperkonwergentnego, gdzie zasoby są również potrzebne do obciążenia obliczeniowego środowisk wirtualnych.
Istnieją również pewne wskaźniki wydajności Glustera, które można osiągnąć pod pewnymi warunkami, ograniczając się do
Cef
Przyjrzyjmy się teraz Cephowi na podstawie opisów architektury, jakie udało mi się znaleźć Istnieje również porównanie między , gdzie można od razu zrozumieć, że wskazane jest wdrożenie Ceph na oddzielnych serwerach, ponieważ jego usługi wymagają wszystkich zasobów sprzętowych pod obciążeniem.
Architektura bardziej złożony niż Gluster i istnieją usługi takie jak usługi metadanych, ale cały stos komponentów jest dość złożony i niezbyt elastyczny, jeśli chodzi o wykorzystanie go w rozwiązaniu wirtualizacyjnym. Dane są przechowywane w blokach, co wygląda bardziej produktywnie, ale w hierarchii wszystkich usług (komponentów) występują straty i opóźnienia przy pewnych obciążeniach i warunkach awaryjnych, na przykład:
Z opisu architektury sercem jest CRUSH, dzięki któremu wybierane jest miejsce przechowywania danych. Następnie przychodzi PG - jest to najtrudniejsza do zrozumienia abstrakcja (grupa logiczna). Aby CRUSH był bardziej skuteczny, potrzebne są PG. Głównym celem PG jest grupowanie obiektów w celu zmniejszenia zużycia zasobów, zwiększenia wydajności i skalowalności. Adresowanie obiektów bezpośrednio, indywidualnie, bez łączenia ich w PG byłoby bardzo kosztowne. OSD to usługa dla każdego pojedynczego dysku.
Klaster może mieć jedną lub wiele pul danych do różnych celów i z różnymi ustawieniami. Pule są podzielone na grupy miejsc docelowych. Grupy rozmieszczenia przechowują obiekty, do których uzyskują dostęp klienci. W tym miejscu kończy się poziom logiczny, a zaczyna poziom fizyczny, ponieważ do każdej grupy rozmieszczania przypisany jest jeden dysk główny i kilka dysków replik (ilość dokładnie zależy od współczynnika replikacji puli). Innymi słowy, na poziomie logicznym obiekt jest przechowywany w określonej grupie rozmieszczenia, a na poziomie fizycznym – na przypisanych do niego dyskach. W takim przypadku dyski mogą być fizycznie zlokalizowane w różnych węzłach lub nawet w różnych centrach danych.
W tym schemacie grupy rozmieszczenia wyglądają jak poziom niezbędny dla elastyczności całego rozwiązania, ale jednocześnie jako dodatkowe ogniwo w tym łańcuchu, co mimowolnie sugeruje utratę produktywności. Przykładowo zapisując dane, system musi je podzielić na te grupy, a następnie na poziomie fizycznym na dysk główny i dyski dla replik. Oznacza to, że funkcja Hash działa podczas wyszukiwania i wstawiania obiektu, ale jest efekt uboczny - są to bardzo wysokie koszty i ograniczenia w odbudowie hasha (przy dodawaniu lub usuwaniu dysku). Kolejnym problemem związanym z mieszaniem jest wyraźnie określona lokalizacja danych, których nie można zmienić. Oznacza to, że jeśli w jakiś sposób dysk jest obciążony, system nie ma możliwości, aby na nim nie zapisywać (wybierając inny dysk), funkcja mieszająca zobowiązuje dane do lokalizacji zgodnie z regułą, niezależnie od tego, jak źle dysk jest, więc Ceph zjada dużo pamięci podczas odbudowy PG w przypadku samonaprawy lub zwiększenia pamięci. Wniosek jest taki, że Ceph działa dobrze (choć wolno), ale tylko wtedy, gdy nie ma skalowania, sytuacji awaryjnych ani aktualizacji.
Istnieją oczywiście opcje zwiększenia wydajności poprzez buforowanie i udostępnianie pamięci podręcznej, ale wymaga to dobrego sprzętu i nadal będą występować straty. Ale ogólnie Ceph wygląda bardziej kusząco niż Gluster pod względem produktywności. Ponadto korzystając z tych produktów należy wziąć pod uwagę ważny czynnik - jest to wysoki poziom kompetencji, doświadczenia i profesjonalizmu z dużym naciskiem na Linuksa, ponieważ bardzo ważne jest prawidłowe wdrożenie, konfiguracja i obsługa wszystkiego, co nakłada na administratora jeszcze większą odpowiedzialność i obciążenie.
Vstorage
Architektura wygląda jeszcze ciekawiej , którego można używać w połączeniu z hiperwizorem w tych samych węzłach, na tym samym , ale bardzo ważne jest, aby wszystko poprawnie skonfigurować, aby osiągnąć dobrą wydajność. Oznacza to, że wdrożenie takiego produktu z pudełka w dowolnej konfiguracji bez uwzględnienia zaleceń zgodnych z architekturą będzie bardzo łatwe, ale mało produktywne.
Co może współistnieć w przypadku przechowywania obok usług hiperwizora kvm-qemu, a to tylko kilka usług, w których znaleziono zwartą, optymalną hierarchię komponentów: usługa klienta montowana poprzez FUSE (zmodyfikowana, nie open source), usługa metadanych MDS (usługa Metadanych), usługa bloków danych usługi Chunk, która na poziomie fizycznym równa się jednemu dyskowi i tyle. Pod względem szybkości oczywiście optymalne jest użycie schematu odpornego na błędy z dwiema replikami, ale jeśli korzystasz z buforowania i logów na dyskach SSD, wówczas kodowanie odporne na błędy (kodowanie kasujące lub raid6) można przyzwoicie podkręcić na dysku schemat hybrydowy lub jeszcze lepiej na wszystkich lampach błyskowych. EC (kodowanie kasujące) ma pewną wadę: przy zmianie jednego bloku danych konieczne jest ponowne obliczenie wartości parzystości. Aby ominąć straty związane z tą operacją, Ceph zapisuje do EC w sposób odroczony, a problemy z wydajnością mogą wystąpić podczas pewnego żądania, gdy na przykład trzeba odczytać wszystkie bloki, a w przypadku Virtuozzo Storage zapisać zmienione bloki odbywa się przy użyciu podejścia „systemu plików o strukturze logu”, co minimalizuje koszty obliczania parzystości. Aby oszacować w przybliżeniu opcje z przyspieszeniem pracy z EC i bez, istnieją – liczby mogą być przybliżone w zależności od współczynnika dokładności producenta sprzętu, ale wynik obliczeń jest dobrą pomocą w planowaniu konfiguracji.
Prosty schemat składowania składników nie oznacza, że składniki te nie wchłaniają się ale jeśli wcześniej obliczysz wszystkie koszty, możesz liczyć na współpracę obok hypervisora.
Istnieje schemat porównywania zużycia zasobów sprzętowych przez usługi przechowywania danych Ceph i Virtuozzo.
Jeśli wcześniej można było porównać Glustera i Cepha na podstawie starych artykułów, wykorzystując najważniejsze z nich wersety, to z Virtuozzo jest to trudniejsze. Nie ma wielu artykułów na temat tego produktu, a informacje można uzyskać jedynie z dokumentacji lub w języku rosyjskim, jeśli weźmiemy pod uwagę Vstorage jako pamięć masową wykorzystywaną w niektórych rozwiązaniach hiperkonwergentnych w firmach takich jak i Acronis.
Postaram się pomóc z opisem tej architektury, więc będzie trochę więcej tekstu, ale samodzielne zrozumienie dokumentacji zajmuje dużo czasu, a istniejącą dokumentację można wykorzystać jedynie jako odniesienie po przejrzeniu tabeli treści lub wyszukiwanie według słów kluczowych.
Rozważmy proces nagrywania w hybrydowej konfiguracji sprzętowej z opisanymi powyżej komponentami: nagranie zaczyna iść do węzła, z którego zainicjował je klient (usługa punktu podłączenia FUSE), ale komponent master Metadata Service (MDS) oczywiście będzie kieruje klienta bezpośrednio do żądanej usługi fragmentów (bloki CS usługi przechowywania), co oznacza, że MDS nie uczestniczy w procesie nagrywania, a po prostu kieruje usługę do wymaganej porcji. Ogólnie rzecz biorąc, można podać analogię do nagrywania z nalewaniem wody do beczek. Każda beczka to blok danych o wielkości 256MB.
Oznacza to, że jeden dysk to pewna liczba takich beczek, czyli objętość dysku podzielona przez 256MB. Każda kopia jest dystrybuowana do jednego węzła, druga prawie równolegle do innego węzła, itd... Jeśli mamy trzy repliki i są dyski SSD na pamięć podręczną (do odczytu i zapisu logów), to potwierdzenie zapisu nastąpi po zapisie log na dysk SSD, a równoległy reset z dysku SSD będzie kontynuowany na dysku twardym, jakby w tle. W przypadku trzech replik rekord zostanie zatwierdzony po potwierdzeniu z dysku SSD trzeciego węzła. Może się wydawać, że sumę prędkości zapisu trzech dysków SSD można podzielić przez trzy i otrzymamy prędkość zapisu jednej repliki, jednak kopie są zapisywane równolegle i prędkość opóźnienia sieci jest zwykle większa niż w przypadku dysku SSD, w rzeczywistości wydajność zapisu będzie zależała od sieci. W związku z tym, aby zobaczyć rzeczywiste IOPS, musisz poprawnie załadować cały Vstorage , czyli testowanie rzeczywistego obciążenia, a nie pamięci i pamięci podręcznej, gdzie konieczne jest uwzględnienie prawidłowego rozmiaru bloku danych, liczby wątków itp.
Wspomniany wyżej log nagrań na dysku SSD działa w ten sposób, że gdy tylko dane do niego dotrą, są one natychmiast odczytywane przez serwis i zapisywane na dysku HDD. Na klaster przypada kilka usług metadanych (MDS), a o ich liczbie decyduje kworum, które działa zgodnie z algorytmem Paxos. Z punktu widzenia klienta punktem podłączenia FUSE jest folder przechowywania klastra, który jest jednocześnie widoczny dla wszystkich węzłów w klastrze, każdy węzeł ma zamontowanego klienta zgodnie z tą zasadą, więc ten magazyn jest dostępny dla każdego węzła.
Dla realizacji któregokolwiek z opisanych powyżej podejść bardzo ważne jest, na etapie planowania i wdrożenia, prawidłowe skonfigurowanie sieci, w której będzie występowało balansowanie ze względu na agregację i prawidłowo dobraną przepustowość kanału sieciowego. Podczas agregacji ważny jest wybór odpowiedniego trybu mieszania i rozmiaru ramek. Istnieje również bardzo wyraźna różnica w stosunku do opisanego powyżej SDS, jest to połączenie technologii szybkiej ścieżki w Virtuozzo Storage. Co oprócz unowocześnionego bezpiecznika, w odróżnieniu od innych rozwiązań open source, znacznie zwiększa IOPS i pozwala nie ograniczać się skalowaniem w poziomie lub w pionie. Ogólnie w porównaniu do architektur opisanych powyżej, ta wygląda na potężniejszą, ale dla takiej przyjemności trzeba oczywiście kupić licencje, w przeciwieństwie do Cepha i Glustera.
Podsumowując, możemy wyróżnić pierwszą trójkę: pierwsze miejsce pod względem wydajności i niezawodności architektury zajmuje Virtuozzo Storage, drugie miejsce Ceph, a trzecie miejsce Gluster.
Kryteria, według których wybrano Virtuozzo Storage: jest to optymalny zestaw komponentów architektonicznych, zmodernizowany dla tego podejścia Fuse z szybką ścieżką, elastycznym zestawem konfiguracji sprzętowych, mniejszym zużyciem zasobów i możliwością współdzielenia z mocą obliczeniową (obliczenia/wirtualizacja), czyli w pełni nadaje się do rozwiązania hiperkonwergentnego, którego jest częścią. Na drugim miejscu znajduje się Ceph, ponieważ jest to architektura bardziej produktywna w porównaniu do Glustera, ze względu na działanie w blokach, a także bardziej elastyczne scenariusze i możliwość pracy w większych klastrach.
W planach jest napisanie porównania vSAN, Space Direct Storage, Vstorage i Nutanix Storage, testowanie Vstorage na sprzęcie HPE i Huawei, a także scenariusze integracji Vstorage z zewnętrznymi sprzętowymi systemami pamięci masowej, więc jeśli artykuł przypadł Ci do gustu, byłoby miło miło jest otrzymać od Ciebie informację zwrotną, która może zwiększyć motywację do nowych artykułów, biorąc pod uwagę Twoje uwagi i życzenia.
Źródło: www.habr.com