🥇 Magazyn LINSTOR i jego integracja z OpenNebula

Nie tak dawno temu zespół LINBIT zaprezentował swoje nowe rozwiązanie SDS - Linstor. To w pełni otwarte przechowywanie danych, które opiera się na sprawdzonych technologiach: DRBD, LVM, ZFS. Linstor łączy w sobie prostotę i dobrze przemyślaną architekturę, co pozwala osiągnąć stabilność i imponujące wyniki.

Dziś chciałbym opowiedzieć nieco więcej o nim i pokazać, jak łatwo można zintegrować go z OpenNebula, korzystając z linstor_un - nowego sterownika, który opracowałem specjalnie w tym celu.

Linstor w połączeniu z OpenNebula pozwala zbudować szybkie i niezawodne chmury, które można bez problemu wdrożyć na własnej infrastrukturze.

Architektura Linstor

Linstor nie jest ani systemem plików, ani samodzielnym blokowym magazynem; Linstor to orkiestrator, który zapewnia warstwę abstrakcji, umożliwiającą automatyzację tworzenia wolumenów w LVM lub ZFS i ich replikację za pomocą DRBD9.

Łamiemy stereotypy

Ale poczekaj, DRBD? - Po co go automatyzować i jak to w ogóle może działać?

Przypomnijmy sobie przeszłość, kiedy DRBD8 cieszył się dużą popularnością. Jego standardowe użycie zakładało tworzenie jednego dużego urządzenia blokowego i dzielenie go na wiele małych kawałków, przy pomocy LVM. Coś jak mdadm RAID-1, ale z replikacją przez sieć.

Takie podejście ma swoje wady, dlatego wraz z nadejściem DRBD9 zasady budowy magazynu uległy zmianie; teraz dla każdej wirtualki tworzy się oddzielne urządzenie DRBD.

Podejście z niezależnymi urządzeniami blokowymi pozwala lepiej wykorzystywać przestrzeń w klastrze, a także dodaje szereg dodatkowych możliwości. Przykładowo, dla każdego z takich urządzeń można określić liczbę replik, ich lokalizację i indywidualne ustawienia. Łatwo je tworzyć/usuwać, robić migawki, zmieniać rozmiar, włączać szyfrowanie i wiele więcej. Warto zauważyć, że DRBD9 wspiera również quorum, co pozwala uniknąć sytuacji split-brain.

Zasoby i backendy

Tworząc nowe urządzenie blokowe, Linstor umieszcza potrzebną ilość replik na różnych węzłach w klastrze. Każdą z takich replik będziemy nazywać zasobem DRBD.

Zasoby występują w dwóch typach:

Zasób danych — reprezentują urządzenie DRBD umieszczone na węźle w puli LVM lub ZFS.
Obecnie istnieje wsparcie dla kilku backendów, a ich liczba stale rośnie. Dostępne są LVM, ThinLVM i ZFS. Ostatnie dwa umożliwiają tworzenie i korzystanie ze snapshotów.
Zasób bezdyskowy — to urządzenie DRBD umieszczone na węźle bez backendu, ale pozwalające na traktowanie go jak zwykłego urządzenia blokowego, wszystkie operacje odczytu/zapisu będą przekierowywane na zasoby danych. Najbliższym odpowiednikiem zasobów bezdyskowych są LUN iSCSI.

Każdy zasób DRBD może mieć do 8 replik, i tylko jedna z nich może być domyślnie aktywna — Primary, wszystkie pozostałe będą Secondary i ich użycie będzie niemożliwe, dopóki jest przynajmniej jeden Primary, co oznacza, że po prostu będą replikować dane między sobą.

Montując urządzenie DRBD w systemie, automatycznie staje się ono Primary, w ten sposób nawet zasób bezdyskowy, w terminologii DRBD, może być Primary.

Więc po co potrzebny jest Linstor?

Powierzając wszystkie zasobożerne zadania rdzeniowi, Linstor w zasadzie jest zwykłą aplikacją Java, która umożliwia łatwą automatyzację tworzenia zasobów DRBD.
Przy tym każdy zasób utworzony przez Linstor będzie niezależnym klastrem DRBD, który działa samodzielnie, niezależnie od stanu kontrolera i innych zasobów DRBD.

Linstor składa się z dwóch komponentów:

Linstor-controller — Główny kontroler, który zapewnia API do tworzenia i zarządzania zasobami. Komunikuje się również z satelitami, sprawdzając wolne miejsce na nich, oraz wysyła zadania do tworzenia i usuwania nowych zasobów. Uruchamiany w pojedynczej instancji i korzysta z bazy danych, która może być wewnętrzna (H2) lub zewnętrzna (PostgreSQL, MySQL, MariaDB)
Linstor-satellite — Instalowany na wszystkich węzłach storage i dostarcza kontrolerowi informacje o wolnej przestrzeni, a także wykonuje zadania otrzymane od kontrolera w celu tworzenia i usuwania nowych woluminów oraz urządzeń DRBD na ich podstawie.

Linstor operuje na następujących kluczowych pojęciach:

Węzeł — fizyczny serwer, na którym będą tworzone i używane zasoby DRBD.
Pula pamięci masowej — Pula LVM lub ZFS utworzona na węźle, w której będą przechowywane zasoby DRBD. Istnieje również możliwość utworzenia puli bezdyskowej — jest to pula, w której będą przechowywane tylko zasoby bezdyskowe.
Definicja zasobu — Definicja zasobu, w zasadzie jest to prototyp, który opisuje nazwę i wszystkie jej właściwości.
Definicja wolumenu — Definicja wolumenu. Każdy zasób może składać się z kilku wolumenów, a każdy wolumen musi mieć rozmiar.
Zasób — Utworzony egzemplarz bloku urządzenia, każdy zasób musi być umieszczony na określonym węźle i w jakimś storage pool.

Instalacja Linstor

Jako system rekomenduję użycie Ubuntu, ponieważ istnieje dla niego gotowe PPA:

add-apt-repository ppa:linbit/linbit-drbd9-stack
apt-get update

Lub Debian, gdzie Linstor można zainstalować z oficjalnego repozytorium dla Proxmox:

wget -O- https://packages.linbit.com/package-signing-pubkey.asc | apt-key add -
PVERS=5 && echo "deb http://packages.linbit.com/proxmox/ proxmox-$PVERS drbd-9.0" > 
    /etc/apt/sources.list.d/linbit.list
apt-get update

Kontroler

Tutaj wszystko jest proste:

apt-get install linstor-controller linstor-client
systemctl enable linstor-controller
systemctl start linstor-controller

Węzły storage

W chwili obecnej w jądrze Linux dostarczany jest moduł jądra in-tree DRBD8, niestety nie jest odpowiedni i musimy zainstalować DRBD9:

apt-get install drbd-dkms

Jak pokazuje praktyka, większość trudności wynika z tego, że w systemie załadowany jest moduł DRBD8, a nie DRBD9. Na szczęście można to łatwo zweryfikować, wykonując:

modprobe drbd
cat /proc/drbd

Jeśli zobaczysz wersja: 9 — oznacza to, że wszystko jest w porządku, jeśli wersja: 8 — to znaczy, że coś poszło nie tak i musisz podjąć dodatkowe kroki w celu ustalenia przyczyn.

Teraz zainstalujemy linstor-satellite i drbd-utils:

apt-get install linstor-satellite drbd-utils
systemctl enable linstor-satellite
systemctl start linstor-satellite

Tworzenie klastra

Storage pools i węzły

Jako backend weźmiemy ThinLVM, ponieważ jest najprostszy i obsługuje migawki.
Zainstaluj lvm2, jeśli jeszcze tego nie zrobiono, i stwórzmy ThinLVM pool na wszystkich naszych węzłach storage:

sudo vgcreate drbdpool /dev/sdb
sudo lvcreate -L 800G -T drbdpool/thinpool

Wszystkie dalsze czynności można wykonać bezpośrednio na kontrolerze:

Dodajmy nasze węzły:

linstor node create node1 127.0.0.11
linstor node create node2 127.0.0.12
linstor node create node3 127.0.0.13

Stwórzmy storage pools:

linstor storage-pool create lvmthin node1 data drbdpool/thinpool
linstor storage-pool create lvmthin node2 data drbdpool/thinpool
linstor storage-pool create lvmthin node3 data drbdpool/thinpool

Teraz sprawdźmy utworzone pule:

linstor storage-pool list

Jeśli wszystko zostało wykonane poprawnie, powinniśmy zobaczyć coś takiego:

+-------------------------------------------------------------------------------------------------------+
| StoragePool | Node  | Driver   | PoolName          | FreeCapacity | TotalCapacity | SupportsSnapshots |
|-------------------------------------------------------------------------------------------------------|
| data        | node1 | LVM_THIN | drbdpool/thinpool |       64 GiB |        64 GiB | true              |
| data        | node2 | LVM_THIN | drbdpool/thinpool |       64 GiB |        64 GiB | true              |
| data        | node3 | LVM_THIN | drbdpool/thinpool |       64 GiB |        64 GiB | true              |
+-------------------------------------------------------------------------------------------------------+

Zasoby DRBD

Teraz spróbujmy stworzyć nasz nowy zasób DRBD:

linstor resource-definition create myres
linstor volume-definition create myres 1G
linstor resource create myres --auto-place 2

Sprawdźmy stworzone zasoby:

linstor resource list

+------------------------------------------------------------------------------------------------------+
| Node  | Resource | StoragePool | VolumeNr | MinorNr | DeviceName    | Allocated  | InUse  |    State |
|------------------------------------------------------------------------------------------------------|
| node1 | myres    | data        | 0        | 1084    | /dev/drbd1084 | 52 KiB     | Unused | UpToDate |
| node2 | myres    | data        | 0        | 1084    | /dev/drbd1084 | 52 KiB     | Unused | UpToDate |
+------------------------------------------------------------------------------------------------------+

Świetnie! — widzimy, że zasób został utworzony na dwóch pierwszych węzłach, możemy również spróbować stworzyć zasób bezdyskowy na trzecim:

linstor resource create --diskless node3 myres

Na węzłach zawsze znajdziesz to urządzenie jako /dev/drbd1084 lub /dev/drbd/by-res/myres/0

Tak działa Linstor, możesz uzyskać więcej informacji z oficjalnej dokumentacji.

Teraz opowiem o tym, jak zintegrować go z OpenNebula

Konfiguracja OpenNebula

Nie będę się zbytnio zagłębiać w proces konfiguracji OpenNebula, ponieważ wszystkie kroki są szczegółowo opisane w oficjalnej dokumentacji, do której zalecam się odwołać, opowiem tylko o integracji OpenNebula z Linstor.

linstor_un

Aby rozwiązać ten problem, napisałem własny sterownik — linstor_un, obecnie dostępny jako wtyczka i należy go zainstalować osobno.

Cała instalacja odbywa się na frontendowych węzłach OpenNebula i nie wymaga dodatkowych działań na węzłach obliczeniowych.

Na początku musimy upewnić się, że mamy jq i linstor-client:

apt-get install jq linstor-client

Zespół linstor node list powinno wyświetlić listę węzłów. Wszystkie węzły obliczeniowe OpenNebula powinny być dodane do klastra Linstor.

Pobierzmy i zainstalujmy wtyczkę:

curl -L https://github.com/OpenNebula/addon-linstor_un/archive/master.tar.gz | tar -xzvf - -C /tmp

mv /tmp/addon-linstor_un-master/vmm/kvm/* /var/lib/one/remotes/vmm/kvm/

mkdir -p /var/lib/one/remotes/etc/datastore/linstor_un
mv /tmp/addon-linstor_un-master/datastore/linstor_un/linstor_un.conf /var/lib/one/remotes/etc/datastore/linstor_un/linstor_un.conf

mv /tmp/addon-linstor_un-master/datastore/linstor_un /var/lib/one/remotes/datastore/linstor_un
mv /tmp/addon-linstor_un-master/tm/linstor_un /var/lib/one/remotes/tm/linstor_un

rm -rf /tmp/addon-linstor_un-master

Teraz musimy dodać go do konfiguracji OpenNebula, wykonując opisane proste kroki tutaj.

Następnie uruchomimy ponownie OpenNebula:

systemctl restart opennebula

Dodamy nasze datastores, systemowe:

cat > system-ds.conf <<EOT
NAME="linstor-system"
TYPE="SYSTEM_DS"
STORAGE_POOL="data"
AUTO_PLACE="2"
CLONE_MODE="snapshot"
CHECKPOINT_AUTO_PLACE="1"
BRIDGE_LIST="node1 node2 node3"
TM_MAD="linstor_un"
EOT

onedatastore create system-ds.conf

I repozytorium obrazów:

cat > images-ds.conf <<EOT
NAME="linstor-images"
TYPE="IMAGE_DS"
STORAGE_POOL="data"
AUTO_PLACE="2"
BRIDGE_LIST="node1 node2 node3"
DISK_TYPE="BLOCK"
DS_MAD="linstor_un"
TM_MAD="linstor_un"
EOT

onedatastore create images-ds.conf

Parametr AUTO_PLACE określa liczbę replik danych, które będą tworzone dla każdego nowego obrazu w OpenNebula.
Parametr CLONE_MODE określa sposób, w jaki będą klonowane obrazy podczas tworzenia nowych maszyn wirtualnych, snapshot — będzie tworzył zrzut obrazu i na podstawie zrzutu uruchamiał maszynę wirtualną, copy — będzie robił pełną kopię obrazu dla każdej maszyny wirtualnej.
W BRIDGE_LIST zaleca się wskazać wszystkie węzły, które będą używane do przeprowadzania operacji klonowania obrazów.

Pełna lista obsługiwanych parametrów znajduje się w README projektu.

Na tym koniec konfiguracji, teraz można załadować jakiś appliance z oficjalnego OpenNebula Marketplace i stworzyć z niego maszyny wirtualne.

Link do projektu:
https://github.com/OpenNebula/addon-linstor_un

Źródło: habr.com