
- 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).

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.
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.
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.
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.

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.

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.
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.
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
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ć).
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.