Red Hat Gluster Storage
 
Red Hat Gluster Storage jest rozwiązaniem SDS (Software-Defined Storage) firmy Red Hat, które ukierunkowane jest na różne zastosowania w obszarze składowania plików. Najczęściej stosowane jest jako pamięć masowa dla platform do wirtualizacji, gdzie wykorzystywane jest do składowania dysków i obrazów maszyn wirtualnych oraz jako scentralizowany serwer plików. W tym drugim zastosowaniu zastępuje dużą ilość rozproszonych dysków sieciowych, nad którymi nikt nie panuje w obszarze bezpieczeństwa i dostępu do danych, a także kopii zapasowej.
 
 
RHGS (Red Hat Gluster Storage) stosowane jest najczęściej do składowania i przetrzymywania:
  • plików PDF, obrazków, skanów, grafik, nagrań wideo i dźwięku,
  • dokumentów tekstowych, prezentacji i arkuszy kalkulacyjnych,
  • obrazów maszyn wirtualnych (VM) i kontenerów,
  • logów, zdarzeń, kopii zapasowej i archiwów,
  • danych geoprzestrzennych w różnym formacie,
  • dużej ilości strumieni obrazu z kamer,
  • dużych zbiorów danych do analizy (Hadoop, Splunk),
  • wszelkich innych typowych dla serwerów plików danych.

Klaster RHGS może działać na bazie prawie dowolnego sprzętu. My do tego celu preferujemy wykorzystanie serwerów Cisco UCS, ale zdarzało nam się też uruchamiać RHGS na m.in. serwerach Dell/EMC i SuperMicro. Firma Red Hat udostępnia długą listę certyfikowanych przez siebie serwerów tych producentów, a też my jako partner handlowy firmy Red Hat na terenie Polski pomagany dobrać zgodny sprzęt i oferujemy dodatkowe wsparcie, jeżeli rozwiązanie to zostanie zakupione za naszym pośrednictwem.

Red Hat Gluster Storage działa na bazie systemu RHEL (Red Hat Enterprise Linux).

Za naszym pośrednictwem można zakupić Red Hat Gluster Storage. Jesteśmy także w stanie go wdrożyć i potem obsługiwać. Sprzedajemy rozwiązania Red Hat na polskim rynku. Zainteresowanych zapraszamy do This email address is being protected from spambots. You need JavaScript enabled to view it..
Jest to rozwiązanie o otwartym kodzie (ang. Open Source), które umożliwia wygodną rozbudowę klastra zarówno o kolejne dyski w ramach węzłów (ang. scale-up), jak i o kolejne węzły z dyskami (ang. scale-out). Aktualnie Red Hat wspiera klastry do 128-węzłów z dyskami. Większe klastry wymagają wcześniejszego zatwierdzenia w Red Hat.
 
 
RHGS jest w stanie zapewnić odporność klastra i dostęp do danych w przypadku awarii zarówno pojedynczych dysków, jak i całych węzłów. Umożliwia on także równoległy dostęp (zapis i odczyt) do wielu węzłów klastra, co przekłada się na o wiele większą wydajność w odróżnieniu od innych rozwiązań pamięci masowej z jednym lub dwoma kontrolerami, poprzez które przechodzi cały ruch do reszty półek dyskowych.
Dostęp do klastra Red Hat Gluster Storage odbywa się za pośrednictwem protokołów SMB (Server Massage Block) i NFS (Network File System) oraz natywnie za pomocą interfejsu FUSE (Filesystem in User Space). Dodatkowo, za pomocą iSCSI (Internet Small Computer Systems Interface) można udostępniać składowane w formie plików dyski.

Protokół SMB najczęściej stosowany jest w otoczeniu sieciowym komputerów z systemem Microsoft Windows oraz do obsługi dysków sieciowych tych systemów. Dostęp do udziałów za pośrednictwem SMB mogą uzyskiwać także użytkownicy systemów z rodziny GNU/Linux czy Apple Mac OS X.
 
Wykorzystanie zasobów RHGS jako dysków sieciowych dla stacji końcowych pozwala pozbyć się z organizacji dużej ilości różnych dysków na USB oraz małych dysków sieciowych czy rozwiązań NAS, nad którymi najczęściej nikt nie panuje oraz których utrzymanie i aktualizacja jest niepraktyczna. Mają one zwykle różne systemy do zarządzania, które są rzadko aktualizowane, a też nikt nie ma kontroli nad tym, kto tak naprawdę uzyskuje dostęp do ich zawartości. Podobnie problematyczne są kwestie związane z ich uszkodzeniem, utratą danych, kopią zapasową czy kradzieżą.
 
Problemy te adresuje i rozwiązuje Red Hat Gluster Storage, który umożliwia zapanowanie nad wszystkimi danymi plikowymi w ramach organizacji. Udostępniane za jego pośrednictwem udziały da się także automatycznie podpinać do kont użytkowników wewnątrz chmury prywatnej Nextcloud Enterprise. W ten sposób można zapewnić wygodny dostęp do wybranych (niekoniecznie wszystkich) zasobów także z urządzeń mobilnych.

Dostęp do takich udziałów może obsługiwać funkcje wysokiej dostępności, dzięki którym klienci są przełączani w przypadku awarii węzła, z którego korzystają. Różne grupy klientów mogą także łączyć się do różnych węzłów, co zapewnia rozkład obciążenia. Dostęp SMB umożliwia wiele ciekawych i przydanych funkcjonalności jak m.in.:
  • możliwość podłączenia antywirusa,
  • możliwość przywracania poprzednich wersji plików i katalogów, nawet samodzielnie przez użytkowników,
  • obsługa kosza na śmieci, do którego mogą trafiać usuwane pliki,
  • WORM (Write Once Read Many), gdzie można ustawić czas po jakim umieszczane pliki staną się niemodyfikowalne,
  • możliwość aktywacji i deaktywacji Microsoft Windows Opportunistic Locking (oplocks level1 & level2),
  • możliwość integracji z Microsoft AD (Active Directory),
  • logowanie informacji na temat wybranych operacji na plikach i katalogach, dzięki czemu widać m.in. kto coś zmienił, stworzył czy usunął,
  • bardzo granularne zarządzanie dostępem w oparciu o POSIX ACLs,
  • obsługa rozszerzeń Apple, która m.in. przyśpiesza działanie na udostępnianych zasobach, obsługę tagów/kolorów dla plików czy integrację z Apple Time Capsule,
  • możliwość wymiany plików z weryfikacją ich integralności i szyfrowaniem.

Najlepiej wydajność całego klastra widać, kiedy jest dużo więcej klientów od węzłów RHGS. Wtedy każda grupa klientów może korzystać z innego węzła, co daje świetne rozwiązanie dla wielu kamer zapisujących jednocześnie obraz czy scentralizowanego w ramach całej organizacji klastra udziałów sieciowych.
 


Microsoft Windows Opportunistic Locking umożliwia buforowanie plików na klientach Microsoft Windows, co przyśpiesza prace odczytu i zapisu, kiedy sieć nie jest szybka. Niemniej ma też negatywny wpływ przy pracy na plikach większych baz danych, gdzie znacząco spada wydajność w przypadku, kiedy uzyskuje do niego dostęp więcej niż jeden klient (za każdym razem wymagana synchronizacja całego pliku, a nie rekordu bazy). RHGS umożliwia aktywację i deaktywację tej funkcji dla każdego z wolumenów.

WORM umożliwia utworzenie zasobu, do którego można zapisywać pliki, które po określonym czasie braku aktywności na nich stają się niemodyfikowalne. Ma to zabezpieczać je przed umyślną, jak i nieumyślną modyfikacją. Przykładem danych dla których uruchamia się WORM są m.in. ważne dokumenty, cenne zbiory i pliki logów. Na specjalne życzenie jesteśmy w stanie także przygotować cały system w taki sposób, że nikt lub tylko osoba od ochrony danych czy bezpieczeństwa informacji będzie w stanie zmienić te ustawienia.

Funkcję WORM czy okresu retencji dla plików można też uruchomić na poziomie całego wolumenu RHGS, wtedy w taki sposób jest on dostępny za pośrednictwem SMB, NFS lub FUSE.

Red Hat Gluster Storage nie sprawia problemów przy migracji dużych i rozbudowanych zbiorów danych, jak inne rozwiązania z którymi mieliśmy styczność. Dla przykładu, OneFS w Dell/EMC Isilon i jego ograniczenie pełnej ścieżki do 1023-oktetów wymuszało nie raz przy migracji zmianę nazewnictwa w dziesiątkach terabajtów danych. Aby zobrazować problem, proszę wyobrazić sobie 50TB danych, na które składają się pliki wielkości około 10MB, a przyjęte nazwy odzwierciedlają hierarchię obiektów, mają określone znaczenie i są powszechnie stosowane w ramach całej organizacji czy w jej dokumentach projektowych i dokumentacjach.

Na takie problemy nie natrafiliśmy z Red Hat Gluster Storage, gdzie długość ta jest aż 4-krotnie większa i wynosi 4095-oktetów dla pełnej ścieżki. Jest to długość pełnej ścieżki, gdzie na nazwę pojedynczego jej obiektu mamy aż 255 oktetów. Kiedy stosowany jest UTF-8 do zapisu nazw takiego obiektu, 1-znak może zawierać od 1 do 4 oktetów. Zatem pesymistycznie maksymalna długość nazwy pliku to 63-znaki. Niemniej należy pamiętać, że zwykłe litery i znaki, z których najczęściej korzystamy zajmują tylko 1-oktet, a polskie litery 2-oktety. Więc tak realnie, z polskimi literami nazwa pliku może posiadać od 125 do 200 znaków. Zależy to bardzo od tego, ile jest w nazwie polskich liter i innych znaków specjalnych. Długa nazwa ścieżki daje większą swobodę w nazywaniu obiektów, która przekłada się na większy porządek oraz możliwość ich dostosowania do bardziej złożonych struktur katalogowych.
Natywny dostęp z użyciem FUSE do zasobów RHGS wykorzystuje algorytm EHA (Elastic Hashing Algorithm), który steruje zapisem i odczytem plików klastra. Dzięki EHA dostęp do zasobów klastra realizowany jest bezpośrednio na podstawie wyniku funkcji haszującej (ang. hash function). Sprawia to, że nie są potrzebne żadne scentralizowane metadane czy dane o dokładnej lokalizacji plików czy ich fragmentów.
 
Ma to szczególne znaczenia przy małych plikach, gdzie wiele rozwiązań nie radzi sobie ze względu na bliski stosunek metadanych do danych. Ponadto, niweluje to pojedynczy punkt awarii czy wąskie gardło, jakim jest scentralizowany dostęp do metadanych na temat lokalizacji właściwych danych.

Natywny dostęp do danych RHGS możliwy jest z różnych systemów z rodziny GNU/Linux oraz bezpośrednio z platformy Red Hat Virtualization. W ten sposób, Red Hat Virtualization może bezpośrednio korzystać z GlusterFS, co przekłada się na bardzo dużą wydajność i wysoką dostępność tej przestrzeni dyskowej.
 

RHV (Red Hat Virtualization) jest w stanie uruchamiać i obsługiwać maszyny wirtualne jednocześnie z wielu różnych węzłów klastra, udostępniających jedną przestrzeń dyskową. Poprawia to wydajność działania całej platformy do wirtualizacji. Dotyczy to także zapisu i modyfikacji, gdzie jest w stanie wprowadzać je jednocześnie na wielu węzłach klastra RHGS. Dlatego bardzo polecamy wykorzystanie RHGS i RHV razem, w ramach jednej infrastruktury do hostowania maszyn wirtualnych.

Najlepiej wydajność platformy do wirtualizacji całego klastra SDS widać, kiedy jest dużo więcej maszyn wirtualnych od węzłów RHGS. Wtedy różne grupy maszyn wirtualnych mogą być ładowane i obsługiwane z różnych węzłów.

Natywny dostęp do klastra wykorzystuje replikację typu AFR (Automatic File Replication), w której to klient wysyła dane bezpośrednio do kilku węzłów klastra i czeka od nich na potwierdzenie. Działa to naprawdę szybko, szczególnie tam, gdzie możemy sobie pozwolić na szybkie karty sieciowe na hostach platformy do wirtualizacji.

Replikacja ta działa inaczej, niż powszechnie znana replikacja z macierzy dyskowych, Red Hat Ceph Storage czy w LINBIT SDS, gdzie klient zapisuje dane tylko do jednego z węzłów pamięci masowej, który to dane te replikuje dalej i dopiero, kiedy się to powiedzie potwierdza klientowi zapis. Wprowadza to nieco większe opóźnienia i nie oddaje tak dużej przepustowości do klastra jak AFR, niemniej metoda ta ma swoich zwolenników, stąd w GlusterFS trwają już od kilku lat testy nowej metody replikacji o nazwie JBR (Journal Based Replication), która realizowana jest podobnie do metod znanych z typowych macierzy dyskowych, Red Hat Ceph Storage czy LINBIT SDS.
 
Zarówno przy AFR, jak i JBR mamy do czynienia z replikacją synchroniczną.
Za naszym pośrednictwem można zakupić Red Hat Gluster Storage. Jesteśmy także w stanie go wdrożyć i potem obsługiwać. Sprzedajemy rozwiązania Red Hat na polskim rynku. Zainteresowanych zapraszamy do This email address is being protected from spambots. You need JavaScript enabled to view it..
RHGS obsługuje też replikację asynchroniczną, zwaną również georeplikacją (ang. Georeplication). Jest ona najczęściej realizowana do oddzielnej lokalizacji, gdzie przechowywane są kopie zapasowe na wypadek DR (Disaster Recovery). Georeplikacja w RHGS nie jest realizowana ciągłym strumieniem, jak w LINBIT DR. Realizowana jest w interwałach co określony czas (np. co 10 sekund lub co 30 minut lub co 24 godziny, itd.). Georeplikacja może być też realizowana do wielu miejsc czy też realizowana w sposób kaskadowy, jak zostało to zobrazowane poniżej.
 
 
W przypadku katastrofy, zasób do którego realizowana jest georeplikacja może zostać aktywowany i udostępniony. Na zasobie do którego realizowana jest georeplikacja można także uruchomić do 256 migawek (ang. snapshots), które mogą reprezentować stan danych z różnych punktów czasu. W ten sposób możemy przywrócić do działania którąkolwiek z dostępnych wersji danych czy też przywrócić z niej pojedyncze pliki.

Migawki danych mogą być wykonywa ręcznie lub automatycznie zgodnie z określonym harmonogramem. Migawki mogą być wykonywane zarówno na normalnych wolumenach, jak i ich replikach. Dzięki nim, da się także udostępnić użytkownikom możliwość samodzielnego przywracania poprzednich wersji plików i całych katalogów.
 
 
Ma te szczególne znacznie w większych organizacjach, gdzie odciąża od takich zadań lokalny personel IT i zapewnia dodatkową ochronę przed ransomware i zaszyfrowaniem danych (poprzednie wersji plików dostępne są w trybie tylko do odczytu). W przypadku wystąpienia takiego incydentu, wystarczy przywrócić poprzednie wersje plików, których ransomware nie może zaszyfrować czy też uszkodzić lub usunąć.
 
Funkcja georeplikacji umożliwia także replikację z zachowaniem usuwanych plików. Może zostać to aktywowane dla wszystkich lub tylko wybranych zasobów z danymi.

Cała georeplikacja, jak i wszelkie połączenia zarządzające pomiędzy węzłami oraz operacje I/O pomiędzy węzłami i klientami mogą być szyfrowane. Nie wymaga to żadnych dodatkowych licencji. W cenie subskrypcji RHGS mamy dostęp do jego wszystkich funkcji, niemniej należy zwracać uwagę na to co dostępne jest w danej wersji, na co jest wsparcie od Red Hat oraz co jest w tak zwanym Tech Preview i będzie miało wsparcie dopiero w przyszłości.
Za naszym pośrednictwem można zakupić Red Hat Gluster Storage. Jesteśmy także w stanie go wdrożyć i potem obsługiwać. Sprzedajemy rozwiązania Red Hat na polskim rynku. Zainteresowanych zapraszamy do This email address is being protected from spambots. You need JavaScript enabled to view it..
Red Hat Gluster Storage radzi sobie także z wykrywaniem uszkodzonych danych (Bit Rot Detection). Funkcję tą warto uruchomić, jeżeli korzystamy z JBOD zamiast RAID. Wtedy, RHGS okresowo skanuje pliki i sprawdza ich sumy kontrolne, informując o niezgodnościach. RHGS posiada także wbudowane funkcje automatycznej korekcji wykrywanych błędów oraz różne mechanizmy do diagnozy, monitorowania i śledzenia wydajności.
Dostęp do zasobów za pomocą protokołu NFS można realizować na wiele sposobów. RHGS obsługuje zarówno tradycyjny serwer NFS na poziomie jądra Linux, jak i nowoczesny i bardziej funkcjonalny serwer w przestrzeni użytkownika o nazwie NFS Ganesha. RHGS obsługuje NFSv3, NFSv4, NFSv4.1 oraz pNFS (Parallel NFS).

NFS Ganesha umożliwia zarówno rozkład obciążenia, jak i zachowanie wysokiej dostępności. W pNFS z natury istnieją role MDS (Meta Data Server) i DS (Data Server), które pełnić może 1-węzeł. Rolę MDS obecnie może pełnić tylko jeden z węzłów, ale wszystkie mogą pełnić rolę DS. Wszystkie operacje I/O od klientów wysyłane są do węzłów DS, a inne operacje do serwera MDS.

Dzięki pNFS możliwe jest zrównoleglenie transmisji i klient może równocześnie korzystać z zasobów wielu węzłów DS. Niemniej należy tutaj pamiętać o wsparciu dla pNFS od strony klienta.
 
Dla przykładu VMware vSphere nie wspiera pNFS, przez co o ile NFS Ganesha będzie w stanie zapewnić mu wysoką dostępność usługi NFS, to ta platforma do wirtualizacji w obecnych wersjach nie będzie w stanie wydajnie z niej korzystać. Dla protokołu NFS platforma VMware vSphere obsługuje tylko tak zwany Session Trunking, który umożliwia zrównoleglenie transmisji do jednego z węzłów RHGS (tylko jednego) czy też jednego serwera NFS, co zostało zobrazowane poniżej. pNFS nie jest również wspierany przez konkurencyjne rozwiązania, jak Dell/EMC Isilon, a przynajmniej te z którymi mieliśmy styczność w dniu tworzenia tego artykułu. Stąd wydajność udostępnianych w stronę systemów GNU/Linux zasobów NFS przez Dell/EMC Isilon będzie niższa.
 


Protokół NFS w RHGS może korzystać z tradycyjnego sposobu dostępu, który umożliwia filtrowanie z użyciem adresów IP czy uprawnień na poziomie plików i katalogów, jak i z Kerberos. Wykorzystanie Kerberos umożliwia uwierzytelnienie i weryfikację integralności lub uwierzytelnienie, weryfikację integralności oraz szyfrowanie.

Do ochrony danych i zapewnienia wysokiej dostępności klastra, RHGS wykorzystuje replikację danych do kilku miejsc lub znany z RAID algorytm EC (Erasure Coding). Dane można także dystrybuować na wiele klastrów realizujących replikację danych lub EC. Umożliwia to łączenie ich w jedną większą przestrzeń na pliki.

Sposób konfiguracji tego wszystkiego jest bardzo granularny. Do tego stopnia, że pojedyncze dyski mogą pełnić funkcję cegiełek (ang. bricks), z których to tworzy się wolumeny (ang. volumes), które dalej udostępniane są w stronę klienta. Pojedynczy klaster RHGS może obsługiwać wiele wolumenów o różnej konfiguracji replikacji i EC.

Przy replikacji, każdy z plików jest zapisywany na minimum dwóch węzłach. Zależy to od wybranej konfiguracji replikacji dla wolumenu. Zaleca się konfigurację replikacji do trzech węzłów. Jeżeli z jakiś powodów niepotrzebny nam aż tak duży poziom redundancji danych, można uruchomić replikację danych do dwóch węzłów oraz samych metadanych do trzeciego węzła zwanego arbitrem. Metadane są niewielkimi informacjami o danych.

Zadaniem arbitra jest rozstrzyganie kolizji oraz dopełnianie kworum (łac. quorum). Arbiter potrzebuje stosunkowo niewielką ilość przestrzeni dyskowej, bo są to tylko ~4KB na każdy składowany plik, bez względu na jego wielkość.


Innym sposobem zapewnienia ochrony danych przy mniejszym zużyciu przestrzeni dyskowej, jest zastosowanie rozpraszania danych (ang. disperse) z EC (Erasure Coding). Dzieli on każdy plik na określoną ilość części N+M i dodaje do nich informacje nadmiarowe, które umożliwiają odtworzenie danych w przypadku awarii M z N cegiełek wolumenu. Dostęp do zasobu jest zawsze możliwy, jeżeli dostępne jest minimum N z N+M części, które razem tworzą wolumen udostępniany w stronę klientów. RHGS obsługuje EC w konfiguracji N+M: 4+2, 8+2, 8+3, 8+4 i 16+4, co zabezpiecza przed awarią odpowiednio około 33%, 20%, 25%, 33% i 20% części wolumenu.


Możliwe jest także rozlokowywanie (ang. distribute) plików na wielu wolumenach z obsługą replikacji lub EC, czy nawet wielu pojedynczych cegiełkach. W ten sposób mogą one sumarycznie prezentować do klienta jedną spójną i większą przestrzeń. Poniżej został zobrazowany przykład rozlokowywania danych.

W obszarze łączenia wolumenów warto też wspomnieć o wolumenach warstwowych (ang. tiering), gdzie wyróżnia się tak zwany Hot Tier, składający się z szybkich dysków oraz Cold Tier, który składa się z wolniejszych, ale o wiele pojemniejszych dysków. Red Hat Gluster Storage jest w stanie samodzielnie przemieszczać pomiędzy nimi pliki w taki sposób, aby te często używane znajdowały się w Hot Tier, a te rzadziej używane w Cold Tier.

Dla każdego udostępnianego katalogu możliwa jest konfiguracja zarówno limitów czy ograniczeń dyskowych (ang. quota), jak i granularnej kontroli dostępu z użyciem POSIX ACLs, co pozwala odtworzyć nawet najbardziej złożone reguły uprawnień, jakie stosowane są w rozwiązaniach Microsoft Windows

Za naszym pośrednictwem można zakupić Red Hat Gluster Storage. Jesteśmy także w stanie go wdrożyć i potem obsługiwać. Sprzedajemy rozwiązania Red Hat na polskim rynku. Zainteresowanych zapraszamy do This email address is being protected from spambots. You need JavaScript enabled to view it..
Nie są to wszystkie możliwości i funkcje Red Hat Gluster Storage, a jedynie te, które uznaliśmy za warte uwagi. Jest to rozwiązanie naprawdę bardzo elastyczne w konfiguracji, którego dodatkowym atutem jest możliwość wykorzystania już dobrze znanych narzędzi do diagnozy, monitorowania i zarządzania, z jakich korzystamy na innych platformach systemów z rodziny GNU/Linux. Sprawia to, że ilość dostępnych rzeczy jakie można zrobić z tym rozwiązaniem jest naprawdę spora, a zdobyta już wiedza z systemów GNU/Linux bardziej przydatna.
 
Jest to ogromna zaleta w stosunku do innych zamkniętych rozwiązań, gdzie kończymy z systemem, w którym wszystko jest dla nas nowe i nieznane. Nie w przypadku Red Hat Gluster Storage, tutaj znane większości osób polecenia linuksowe znajdą swoje zastosowanie i będziemy mogli nadal z nich korzystać.

Niemniej, każde z rozwiązań ma pewne ograniczenia lub realizuje coś nieco inaczej, niż inne. Stąd na koniec warto jeszcze raz przypomnieć, że o ile RHGS nie wymaga żadnych dodatkowych licencji i w cenie jego subskrypcji mamy dostęp do wszystkich funkcjonalności, to należy zwracać uwagę na to co dostępne jest w ramach danej jego wersji, na co jest wsparcie od firmy Red Hat oraz co jest w tak zwanym Tech Preview i będzie miało wsparcie dopiero w przyszłości (niemniej działa i można z tego korzystać).
 
Red Hat Gluster Storage rozwijany jest od 2005 roku w ramach projektu o otwartym kodzie GlusterFS, który został zakupiony przez firmę Red Hat w 2011 roku.

Zapraszamy do kontaktu drogą mailową This email address is being protected from spambots. You need JavaScript enabled to view it. lub telefonicznie +48 797 004 932.