GlusterFS - krótki opis + przykład.

Coraz bardziej rozbudowane usługi i aplikacje wymagają zwykle sychronizacji pewnych elementów miedzy serwerami. W miarę małych środowiskach jest to proste. Możemy wpiąć sobie po iscsi lub fc zasób macierzowy, udostępnić go wszystkim nodom i po sprawie. Rzecz komplikuje się gdy nie chcemy, lub też nie możemy rozwiązać sytuacji w ten sposób. Jakie alternatywy znajdujemy, aby zrobić wspólny zasób dla wielu serwerów? NFS? Rsync? A gdyby tak połączyć obie te techniki, dodatkowo dać możliwość budowy wirtualnych raidów składających z zasobów udostępnianych z samych serwerów? Takie możliwości ma zaoferować GlusterFS.


GlusterFS to dystrybuowany na licencji opensorce, dystrybucyjny system plików o dużej skalowalności. Autorzy gwarantują, że sam system potrafi się zeskalować do rozmiarów kilku petabajtów, cały czas będąc dostępny z pojedynczego punktu montowania. Sam Gluster, jest wyższą wartstwą abstrakcji w stosunku do fizycznych systemów plików, tu cały czas używamy zwykłych filesystemów takich jak ext3, ext4 czy xfs.

Logo Glusterfs: http://www.gluster.org/

Fizycznie, na każdym z nodów glusterFS to ścieżka, w której przechowywane są metadane systemu plików - tu autorzy zalecają użycie dowolnej scieżki, na partycji różnej root. Sformatowanej i zamontowanej jak wyżej - jako część naszego systemu, oraz właściwy punkt montowania (poleceniem mount.glusterfs), który staje się naszym punktem dostępowym do danych trzymanych na "glasterze".

W zależności od rezultatu jaki chcemy osiągnąć, mamy do wyboru jeden z trzech podstawowych naszego trybów glastera.

1. Distributed - klasyczny tryb klient serwer, w którym nody łączą się z jedną maszyną udostępniającą zasób. Ze zwgledu na brak redundancji - najmniej dla nas interesujący.

2. Replicated - Zawartość voluminu w trybie rzeczywistym replikuje się pomiędzy wszystkie nody, nazywane w przypadku glustera - bricks. Zapewnia to pełną redundancję plików. Każdy z nodów posiada pełną replikę danych.

3. Striped - tryb analogiczny do raid0 dane rozrzucane są po dyskach nodów w zależności na których były tworzone lub wykorzystywane. Nie zapewnia redundacji, w porownaniu do Distributed - mniejsza czas dostępu do danych, gdyż pasek który znajduje się na lokalnym dysku nie musi być zaczytywany ze zdalnej lokalizacji. Pozwala spinać w jeden moutpoint bardzo duże ilości danych rozrzucone na wiele nodów.

W przypadku specyficznych zastosowań, możemy też stworzyć (od wersji 3.3) rozwiązania hybrydowe typu Stripe + Replicate lub Replicate ( + Distribute )

Przejdźmy do rzeczy i zaimplementujmy glusterFS na naszym serwerze :)

Założenia:

• 3x CentOS 6.
• 192.168.20.10 nod1
• 192.168.20.11 nod2
• 192.168.20.12 nod3
• Chcemy zbudować replike.
• Każdy ma zamontowany zasób /www-metadata (ext) 

Instalacja pakietów

Dodajemy repozytorium glustera:

wget -P /etc/yum.repos.d http://download.gluster.org/pub/gluster/glusterfs/LATEST/CentOS/glusterfs-epel.repo

Instalujemy pakiety:

yum -y install glusterfs glusterfs-fuse glusterfs-server

Dodatkowo, jeśli nie macie, należy też zainstalować daemona fuse, z repozytorium base centosa.

Uruchamiamy glusted

/etc/init.d/glusterd start
chkconfig glusterd on

W tym momencie, jeśli nie wystąpiły jakieś błędy, etap instalacji mamy zakończony. Musimy wykonać go na wszystkich nodach. Teraz czas na dodanie nodów do klastra.

Komunikacja w klastrze następuje domyślnie po protokole tcp, warto więc zwrócić uwagę na tym etapie na ustawienia firewalla, szczególnie portów: 111, 24007, 24008, 24009–24012, 34865–34867.

Kolejnym ważnym elementem jest wrzucenie informacji o wszystkich nodach do pliku /etc/hosts tych nodów, tak wiec w naszym przypadku w pliku /etc/hosts każdego z nodów powinno byc:

192.168.20.10 nod1
192.168.20.11 nod2
192.168.20.12 nod3

Na pierwszym z nodów piszemy:

gluster peer probe nod2
Probe successful
gluster peer probe nod3
Probe successful
gluster peer status
Number of Peers: 2

W tym momencie nasz 3 nodowy klaster jest już złożony, upewnijmy się poleceniem:

gluster peer status
Number of Peers: 2
Hostname: nod2
Uuid: b65874ab-4d06-4a0d-bd84-055ff6484efd
State: Peer in Cluster (Connected)
Hostname: nod3
Uuid: 182e3214-44a2-46b3-ae79-769af40ec160
State: Peer in Cluster (Connected)

Klaster gotowy, złóżmy więc nasz pierwszy replikowany zasób - załóżmy, że bedzie to /var/www

gluster volume create rep-volume replica 3 nod1:/www-metadata nod2:/www-metadata nod3:/www-metadata
Creation of volume rep-volume has been successful. Please start the volume to access data

Kolejną czynnością jest wystartowanie zasobu:

gluster volume start rep-volume

Jeśli wszystko się udało, sprawdzamy poprawność założonego voluminu:

gluster volume info rep-volume
Volume Name: rep-volume
Type: Replicate
Volume ID: 0dcf51bc-376a-4bd2-8759-3d47bba49c3d
Status: Started
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: nod1:/www-metadata
Brick2: nod2:/www-metadata
Brick3: nod3:/www-metadata

Zasób złożony - i aktywny... ostatnim elementem jest jego zamontowanie na nodach:

mount.glusterfs nod1:/rep-volume /var/www

Finalnie zyskujemy /var/www na każdym z nodów które replikuje się w czasie rzeczywistym :-)

Po wstępnych testach naszego redundantnego zasobu, pozostaje jedynie utrwalenie osiągniętego efektu, w postaci odpowiedniego wpisu do /etc/fstab, składnia:

nod1:/rep-volume /var/www glusterfs defaults,_netdev 0 0

To byłoby na tyle, jeśli chodzi o pierwszy klaster - proste prawda? Całość zajmuje mniej niż 10 minut i już możemy testować nasz zasób. Oczywiście to tylko ułamek możliwości glustera (do ktorych zaliczają się klastry hybrydowe, szyfrowanie ssl w przypadku geoklastrów, czy wsparcie dla RDMA :-) Mam nadzieję, że w jakiś sposób zachęciłem Was do przyjrzenia się bliżej temu rozwiązaniu, w przypadku waszego zainteresowania, postaram się kolejne, bardziej skomplikowane przypadki wykorzystania glustera, ująć w kolejnych wpisach na tym blogu.