LINSTOR-lagring och dess integration med OpenNebula

Nyligen presenterade grabbarna från LINBIT sin nya SDS-lösning - Linstor. Det är en helt fri lagring som bygger på beprövad teknik: DRBD, LVM, ZFS. Linstor kombinerar enkelhet med en väl genomarbetad arkitektur, vilket möjliggör stabilitet och ganska imponerande resultat.

I dag skulle jag vilja berätta lite mer om det och visa hur enkelt det kan integreras med OpenNebula med hjälp av linstor_un - en ny drivrutin som jag har utvecklat speciellt för detta ändamål.

Linstor i kombination med OpenNebula gör det möjligt att bygga en snabb och pålitlig molnplattform som enkelt kan implementeras på egen infrastruktur.

Linstors arkitektur

Linstor är varken ett filsystem eller en blocklagring i sig, Linstor är en orkestrator som erbjuder ett abstraktionslager för att automatisera skapandet av volymer i LVM eller ZFS och replikera dem med hjälp av DRBD9.

Bryter stereotyper

Men vänta, DRBD? - Varför automatisera det och hur kan det överhuvudtaget fungera?

Låt oss minnas det förflutna när DRBD8 var väldigt populärt. Dess standardanvändning innebar att skapa en stor blockenhet och dela upp den i många små bitar med hjälp av samma LVM. En slags mdadm RAID-1 men med replikering över nätverket.

Denna metod har sina nackdelar, och därför med införandet av DRBD9 ändrades principerna för lagringslösningar, nu skapas enskilda DRBD-enheter för varje virtuella maskin.

Metoden med oberoende blockenheter möjliggör en bättre utnyttjande av utrymmet i klustret, och ger också en rad ytterligare möjligheter. Till exempel kan för varje sådan enhet definieras antalet replikat, deras placering och individuella inställningar. De är enkla att skapa/tas bort, göra snapshots, ändra storlek, aktivera kryptering och mycket mer. Det är värt att notera att DRBD9 också stöder quorum, vilket förhindrar split-brain-situationer.

Resurser och backend

Vid skapandet av en ny blockenhet placerar Linstor det nödvändiga antalet replikat på olika noder i klustret. Varje sådan replik kommer vi att kalla en DRBD-resurs.

Resurser finns i två typer:

• Dataresurs representerar en DRBD-enhet som är placerad på en nod i LVM- eller ZFS-pool.
  För närvarande finns det stöd för flera backend och deras antal ökar ständigt. Det finns stöd för LVM, ThinLVM och ZFS. De två sista möjliggör skapande och användning av snapshots.
• Diskless-resurs representerar en DRBD-enhet som är placerad på en nod utan backend, men som tillåter att behandlas som en vanlig blockenhet, alla läs-/skrivoperationer kommer att dirigeras till data-resurser. Närmaste analog till diskless-resurser är iSCSI LUN.

Varje DRBD-resurs kan ha upp till 8 repliker, och endast en av dem kan som standard vara aktiv— Primär, alla andra kommer att vara Sekundär och deras användning kommer att vara omöjlig så länge det finns minst en Primär, det vill säga de kommer helt enkelt att replikera data mellan varandra.

Genom att montera DRBD-enheten i systemet blir den automatiskt Primär, vilket innebär att även en Diskless-resurs, enligt DRBD-terminologin, kan vara Primär.

Så varför behövs Linstor?

Genom att lita på alla resursintensiva uppgifter till kärnan, fungerar Linstor i grund och botten som en vanlig Java-applikation som enkelt möjliggör automatisering av skapandet av DRBD-resurser.
Varje resurs som skapats av det kommer att vara en oberoende DRBD-kluster som fungerar självständigt, oavsett status för kontrollplanet och andra DRBD-resurser.

Linstor består endast av två komponenter:

• Linstor-controller – Den huvudsakliga kontrollern som tillhandahåller ett API för att skapa och hantera resurser. Den kommunicerar också med satelliterna, kontrollerar tillgängligt utrymme på dem, och skickar uppdrag för att skapa och ta bort nya resurser. Körs i en enskild instans och använder en databas som kan vara antingen intern (H2) eller extern (PostgreSQL, MySQL, MariaDB)
• Linstor-satellite – Installeras på alla storage-noder och ger kontrollern information om ledigt utrymme, samt utför uppgifter mottagna från kontrollern för att skapa och ta bort nya volymer och DRBD-enheter ovanpå dem.

Linstor arbetar med följande nyckelbegrepp:

• Node – en fysisk server på vilken DRBD-resurser kommer att skapas och användas.
• Storage Pool – LVM eller ZFS pool, skapad på en nod där DRBD-resurser kommer att placeras. Det är också möjligt att ha en diskless-pool – en pool där endast diskless-resurser kommer att placeras.
• Resursdefinition — Definitionen av resursen, i grund och botten är det en prototyp som beskriver namnet och alla dess egenskaper.
• Volymdefinition — Definition av volym. Varje resurs kan bestå av flera volymer, varje volym måste ha en storlek.
• Resurs — En skapad instans av ett blockenhet, varje resurs måste placeras på en viss nod och i någon lagringspool.

Installation av Linstor

Jag rekommenderar att använda Ubuntu som system, eftersom det finns ett färdigt PPA:

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

Eller Debian, där Linstor kan installeras från det officiella lagret för 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

Controller

Det är enkelt här:

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

Lagringsnoder

För närvarande levereras en in-tree kärnmodul i Linux DRBD8, tyvärr passar den inte för oss och vi behöver installera DRBD9:

apt-get install drbd-dkms

Som erfarenheten visar uppstår de flesta komplikationerna just på grund av att DRBD8-modulen är laddad i systemet, snarare än DRBD9. Lyckligtvis är det enkelt att kontrollera genom att köra:

modprobe drbd
cat /proc/drbd

Om du ser version: 9 — är allt i ordning, om version: 8 — betyder att något har gått fel och du måste vidta ytterligare åtgärder för att ta reda på orsaken.

Nu ska vi installera linstor-satellite och drbd-utils:

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

Skapa en kluster

Lagringspooler och noder

Som backend tar vi ThinLVM, eftersom det är den enklaste och stöder snapshots.
Installera lvm2, om du inte har gjort det ännu, och låt oss skapa en ThinLVM-pool på alla våra lagringsnoder:

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

Alla framtida åtgärder kan utföras direkt på kontrollern:

Vi lägger till våra noder:

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

Vi skapar lagringspooler:

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

Nu kontrollerar vi de skapade poolerna:

linstor storage-pool list

Om allt är rätt utfört bör vi se något i stil med:

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

DRBD-resurser

Nu låt oss försöka skapa vår nya DRBD-resurs:

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

Låt oss kontrollera de skapade resurserna:

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

Utmärkt! — vi ser att resursen skapades på de första två noderna, vi kan också försöka skapa en disklös resurs på den tredje:

linstor resource create --diskless node3 myres

På noderna kommer du alltid att hitta den här enheten som /dev/drbd1084 eller /dev/drbd/by-res/myres/0

Så här fungerar Linstor, du kan få mer information från den officiella dokumentationen.

Nu ska jag berätta hur man integrerar det med OpenNebula

Inställning av OpenNebula

Jag kommer inte att gå in på djupet om installationsprocessen för OpenNebula, eftersom alla steg är detaljerat beskrivna i den officiella dokumentationen, som jag rekommenderar att du vänder dig till, jag kommer bara att berätta om integrationen av OpenNebula med Linstor.

linstor_un

För att lösa detta problem har jag skrivit en egen drivrutin — linstor_un, för närvarande är den tillgänglig som en plugin och behöver installeras separat.

Hela installationen sker på frontend OpenNebula-noderna och kräver inga ytterligare åtgärder på compute-noderna.

Först måste vi se till att vi har jq och linstor-client:

apt-get install jq linstor-client

Team linstor node list borde visa en lista över noder. Alla compute-noder i OpenNebula borde vara tillagda i Linstor-klustret.

Låt oss ladda ner och installera plugin:

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

Nu behöver vi lägga till den i OpenNebula-konfigurationen, för detta utför vi de enkla stegen som beskrivs här.

Därefter kommer vi att starta om OpenNebula:

systemctl restart opennebula

Och vi lägger till våra datalager, systemets:

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

Och bildlagret:

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

• Parameter AUTO_PLACE anger antalet data-replikat som kommer att skapas för varje ny bild i OpenNebula.
• Parameter CLONE_MODE anger hur bilder kommer att kopieras vid skapandet av nya virtuella maskiner, snapshot — kommer att skapa en snapshot av bilden och rulla ut den virtuella maskinen från snapshoten, copy — kommer att göra en fullständig kopia av bilden för varje virtuell maskin.
• I BRIDGE_LIST det rekommenderas att ange alla noder som ska användas för att utföra kloningsoperationer av bilder.

En fullständig lista över stödda parametrar finns i README för projektet.

Nu är inställningen klar, och nu kan vi ladda ner en appliance från den officiella OpenNebula Marketplace och skapa virtuella maskiner från den.

Länk till projektet:
https://github.com/OpenNebula/addon-linstor_un

Källa: habr.com