Klusterlagring för små webbkluster baserat på drbd+ocfs2

Vad vi kommer att prata om:
Hur man snabbt distribuerar delad lagring för två servrar baserat på drbd+ocfs2-lösningar.

Vem kommer detta att vara användbart för:
Handledningen kommer att vara användbar för systemadministratörer och alla som väljer en lagringsimplementeringsmetod eller vill prova lösningen.

Vilka beslut vägrade vi och varför?

Ofta står vi inför en situation där vi behöver implementera delad lagring med bra läs-skrivprestanda på ett litet webbkluster. Vi provade olika alternativ för att implementera delad lagring för våra projekt, men få kunde tillfredsställa oss på flera indikatorer samtidigt. Nu ska vi berätta varför.

• Glusterfs tillfredsställde oss inte med läs- och skrivprestanda, det fanns problem med samtidig läsning av ett stort antal filer och det var hög belastning på CPU:n. Problemet med att läsa filer skulle kunna lösas genom att komma åt dem direkt från brick, men detta är inte alltid tillämpligt och är i allmänhet felaktigt.

• Ceph gillade inte den överdrivna komplexiteten, som kan vara skadlig på projekt med 2-4 servrar, särskilt om projektet sedan underhålls. Återigen finns det allvarliga prestandabegränsningar som tvingar oss att bygga separata lagringskluster, som med glusterfs.

• Att använda en NFS-server för att implementera delad lagring väcker frågor när det gäller feltolerans.

• s3 är en utmärkt populär lösning för ett visst antal uppgifter, men det är inte ett filsystem, vilket begränsar dess omfattning.

• lsyncd. Om vi ​​redan har börjat prata om "icke-filsystem", så är det värt att gå igenom denna populära lösning. Inte nog med att det inte är lämpligt för tvåvägsutbyte (men om du verkligen vill så kan du det), det fungerar inte heller stabilt på ett stort antal filer. Ett trevligt tillskott till det hela är att den är enkelgängad. Anledningen ligger i programmets arkitektur: det använder inotify för att övervaka arbetsobjekt, som det tilldelar vid start och under omsökning. rsync används som överföringsmedium.

Handledning: hur man distribuerar delad lagring baserat på drbd+ocfs2

En av de mest bekväma lösningarna för oss var länken ocfs2+drbd. Nu kommer vi att berätta hur du snabbt kan distribuera delad lagring för två servrar baserat på en lösningsdatabas. Men först lite om komponenterna:

DRBD - ett lagringssystem från standard Linux-distributionen som låter dig replikera data mellan servrar i block. Huvudapplikationen är att bygga feltolerant lagring.

OCFS2 - ett filsystem som tillhandahåller delad användning av samma lagring av flera system. Ingår i Linux-distributionen och är en kärnmodul och användarutrymmesverktyg för att arbeta med FS. OCFS2 kan användas inte bara över DRBD, utan också över iSCSI med flera anslutningar. I vårt exempel använder vi DRBD.

Alla åtgärder utförs på ubuntu-server 18.04 i en minimal konfiguration.

Steg 1. Konfigurera DRBD:

I filen /etc/drbd.d/drbd0.res beskriver vi vår virtuella blockenhet /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;
}
}

intern meta-disk — använd samma blockenheter för att lagra metadata
enhet /dev/drbd0 — använd /dev/drbd0 som sökvägen till drbd-volymen.
disk /dev/vdb1 - använd /dev/vdb1
syncer { rate 1000M; } — använd gigabitkanals bandbredd
tillåt-två-primärer - ett viktigt alternativ som gör att ändringar kan accepteras på två primära servrar
efter-sb-0pri, efter-sb-1pri, efter-sb-2pri — alternativ som ansvarar för nodens handlingar när splitbrain detekteras. Mer information finns i dokumentationen.
bli-primär-på båda — sätter båda noderna till primära.

I vårt fall har vi två helt identiska virtuella datorer, med ett dedikerat virtuellt nätverk med en bandbredd på 10 gigabit.

I vårt exempel är nätverksnamnen för två klusternoder drbd1 och drbd2. För korrekt funktion måste du matcha namnen och IP-adresserna för värdar i /etc/hosts.

10.10.10.192 drbd1
10.10.10.193 drbd2

Steg 2. Konfigurera noder:

På båda servrarna kör vi:

drbdadm create-md drbd0

modprobe drbd
drbdadm up drbd0
cat /proc/drbd

Vi får följande:

Du kan starta synkroniseringen. På den första noden måste du köra:

drbdadm primary --force drbd0

Låt oss titta på statusen:

cat /proc/drbd

Bra, synkroniseringen har börjat. Vi väntar till slutet och ser bilden:

Steg 3. Starta synkronisering på den andra noden:

drbdadm primary --force drbd0

Vi får följande:

Nu kan vi skriva till drbd från två servrar.

Steg 4. Installera och konfigurera ocfs2.

Vi kommer att använda en ganska trivial konfiguration:

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

Det måste skrivas ner /etc/ocfs2/cluster.conf på båda noderna.

Vi skapar en FS på drbd0 på vilken nod som helst:

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

Här skapade vi ett filsystem med etiketten testVol på drbd0, med standardparametrarna.

I /etc/default/o2cb måste du ställa in (som i vår konfigurationsfil)

O2CB_ENABLED=true 
O2CB_BOOTCLUSTER=ocfs2cluster 

och kör på varje nod:

o2cb register-cluster ocfs2cluster

Sedan slår vi på och lägger till alla enheter vi behöver för att köra automatiskt:

systemctl enable drbd o2cb ocfs2
systemctl start drbd o2cb ocfs2

En del av detta kommer redan att köras under installationsprocessen.

Steg 5. Lägg till monteringspunkter till fstab på båda noderna:

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

Katalog /media/delad den måste skapas i förväg.

Här använder vi noauto-alternativen, vilket innebär att filen inte kommer att monteras vid uppstart (jag föredrar att montera nätverksfiler via systemd) och heartbeat=local, vilket innebär att man använder heartbeat-tjänsten på varje nod. Det finns också globala hjärtslag, vilket är mer lämpligt för stora kluster.

Därefter kan du montera /media/delad och kontrollera innehållssynkronisering.

Klart! Som ett resultat får vi mer eller mindre feltålig lagring med skalbarhet och hyfsad prestanda.

Källa: will.com