Klastrujące przechowywanie dla małych web-klastrów opartych na drbd+ocfs2

O czym będziemy mówić:
Jak szybko wdrożyć wspólne przechowywanie dla dwóch serwerów na rozwiązaniach drbd+ocfs2.

Dla kogo to będzie przydatne:
Ten poradnik będzie przydatny dla administratorów systemów i wszystkich, którzy wybierają sposób realizacji przechowywania lub chcą wypróbować to rozwiązanie.

Z jakich rozwiązań zrezygnowaliśmy i dlaczego

Często spotykamy się z sytuacją, gdy musimy wdrożyć na niewielkim klastrze webowym wspólne przechowywanie z dobrą wydajnością w odczycie i zapisie. Próbowaliśmy różnych opcji realizacji wspólnego przechowywania dla naszych projektów, ale mało co potrafiło satysfakcjonować nas od razu pod wieloma względami. Teraz opowiemy, dlaczego.

• Glusterfs nie spełnił naszych oczekiwań pod względem wydajności w odczycie i zapisie, występowały problemy z równoległym odczytem dużej liczby plików, obciążenie CPU było wysokie. Problem z odczytem plików można było rozwiązać, sięgając po nie bezpośrednio do bricków, ale to nie zawsze jest praktyczne i w ogóle nie jest poprawne.

• Ceph nie przypadł nam do gustu ze względu na nadmierną złożoność, która może być szkodliwa w projektach z 2-4 serwerami, szczególnie jeśli projekt jest później obsługiwany. Ponownie, istnieją poważne ograniczenia wydajności, które zmuszają do budowy odrębnych klastrów przechowywania, tak jak w przypadku glusterfs.

• Wykorzystanie jednego serwera nfs do realizacji wspólnego przechowywania rodzi pytania dotyczące odporności na awarie.

• s3 — doskonałe popularne rozwiązanie do pewnych zadań, ale nie jest systemem plików, co zawęża jego zastosowania.

• lsyncd. Jeśli już zaczęliśmy mówić o „nie-systemach plików”, warto również wspomnieć o tym popularnym rozwiązaniu. Po pierwsze, nie nadaje się do dwustronnej wymiany (choć jeśli bardzo chcesz, to jest to możliwe), a także nie działa stabilnie przy dużej liczbie plików. Miłym dodatkiem do całości jest to, że działa w jednym wątku. Powód tego jest w architekturze programu: wykorzystuje inotify do monitorowania obiektów roboczych, które załącza podczas uruchamiania i podczas ponownego skanowania. Jako środek transmisji używa rsync.

Poradnik: jak wdrożyć wspólne przechowywanie na bazie drbd+ocfs2

Jednym z najwygodniejszych rozwiązań dla nas stała się kombinacja ocfs2+drbd. Teraz opowiemy, jak szybko wdrożyć wspólne przechowywanie dla dwóch serwerów na bazie rozwiązań. Najpierw jednak kilka słów o komponentach:

DRBD — system przechowywania dostarczany w standardzie w Linux, który pozwala na replikację danych między serwerami blokami. Podstawowe zastosowanie polega na tworzeniu odpornych na awarie magazynów.

OCFS2 — system plików, umożliwiający współdzielenie tego samego magazynu przez wiele systemów. Wchodzi w skład dostawy Linuxa i składa się z modułu jądra oraz zestawu narzędzi dla użytkownika do pracy z systemem plików. OCFS2 można wykorzystać nie tylko na DRBD, ale także na iSCSI z wieloma połączeniami. W naszym przykładzie korzystamy z DRBD.

Wszystkie działania wykonujemy na ubuntu server 18.04 w minimalnej konfiguracji.

Krok 1. Konfiguracja DRBD:

W pliku /etc/drbd.d/drbd0.res opisujemy nasze wirtualne urządzenie blokowe /dev/drbd0:

resource drbd0 {
    syncer { rate 1000M; }
    net {
        allow-two-primaries;
        after-sb-0pri discard-zero-changes;
        after-sb-1pri discard-secondary;
        after-sb-2pri disconnect;
    }
    startup { become-primary-on both; }
    on drbd1 {
        meta-disk internal;
        device /dev/drbd0;
        disk /dev/vdb1;
        address 10.10.10.192:7789;
}
    on drbd2 {
        meta-disk internal;
        device /dev/drbd0;
        disk /dev/vdb1;
        address 10.10.10.193:7789;
}
}

meta-disk internal — wykorzystować te same urządzenia blokowe do przechowywania metadanych
device /dev/drbd0 — wykorzystać /dev/drbd0 jako ścieżkę do drbd.
disk /dev/vdb1 — wykorzystać /dev/vdb1
syncer { rate 1000M; } — wykorzystać gigabitową przepustowość kanału
allow-two-primaries — istotna opcja, pozwalająca na akceptację zmian na dwóch serwerach primary
after-sb-0pri, after-sb-1pri, after-sb-2pri — opcje odpowiadające za działania węzła w przypadku wykrycia splitbrain. Więcej można znaleźć w dokumentacji.
become-primary-on both — ustanawia obie węzły jako primary.

W naszym przypadku mamy dwie identyczne maszyny wirtualne, z wydzieloną wirtualną siecią o przepustowości 10 gigabitów.

W naszym przykładzie nazwy sieci dwóch węzłów klastra to drbd1 i drbd2. Dla poprawnej pracy należy powiązać w /etc/hosts nazwy i adresy IP węzłów.

10.10.10.192 drbd1
10.10.10.193 drbd2

Krok 2. Konfiguracja węzłów:

Na obu serwerach wykonujemy:

drbdadm create-md drbd0

modprobe drbd
drbdadm up drbd0
cat /proc/drbd

Otrzymujemy następujące:

Można uruchomić synchronizację. Na pierwszym węźle należy wykonać:

drbdadm primary --force drbd0

Sprawdzamy status:

cat /proc/drbd

Świetnie, synchronizacja się rozpoczęła. Czekamy na zakończenie i widzimy obraz:

Krok 3. Uruchamiamy synchronizację na drugim węźle:

drbdadm primary --force drbd0

Otrzymujemy następujące:

Teraz możemy pisać w drbd z obu serwerów.

Krok 4. Instalacja i konfiguracja ocfs2.

Użyjemy dość trywialnej konfiguracji:

cluster:
     node_count = 2
     name = ocfs2cluster

node:
     number = 1
     cluster = ocfs2cluster
     ip_port = 7777
     ip_address = 10.10.10.192
     name = drbd1

node:
     number = 2
     cluster = ocfs2cluster
     ip_port = 7777
     ip_address = 10.10.10.193
     name = drbd2

Należy zapisać to w /etc/ocfs2/cluster.conf na obu węzłach.

Tworzymy system plików na drbd0 na dowolnym węźle:

mkfs.ocfs2 -L "testVol" /dev/drbd0

Tutaj stworzyliśmy system plików z etykietą testVol na drbd0, używając domyślnych parametrów.

W /etc/default/o2cb należy ustawić (jak w naszej konfiguracji pliku)

O2CB_ENABLED=true 
O2CB_BOOTCLUSTER=ocfs2cluster 

i wykonać na każdym węźle:

o2cb register-cluster ocfs2cluster

Następnie uruchamiamy i dodajemy do autostartu wszystkie potrzebne nam jednostki:

systemctl enable drbd o2cb ocfs2
systemctl start drbd o2cb ocfs2

Część z tego będzie już uruchomiona w trakcie konfiguracji.

Krok 5. Dodajemy punkty montowania w fstab na obu węzłach:

/dev/drbd0 /media/shared ocfs2 defaults,noauto,heartbeat=local 0 0

Katalog /media/shared musi być wcześniej utworzony.

Tutaj używamy opcji noauto, co oznacza, że system plików nie będzie montowany przy starcie (wolę montować systemy plików przez systemd) i heartbeat=local, co oznacza korzystanie z usługi heartbeat na każdym węźle. Jest też global heartbeat, który lepiej nadaje się do większych klastrów.

Następnie można zamontować /media/shared i sprawdzić synchronizację zawartości.

Gotowe! W rezultacie otrzymujemy w miarę odporną na awarie przestrzeń magazynową z możliwością skalowania i przyzwoitą wydajnością.

Źródło: habr.com