Hva vi vil fortelle om:
Hvordan raskt sette opp et felles lager for to servere basert pÄ lÞsninger drbd+ocfs2.
Hvem dette vil vĂŠre nyttig for:
Tutorialen vil vĂŠre nyttig for systemadministratorer og alle som velger en metode for Ă„ implementere lager eller Ăžnsker Ă„ prĂžve lĂžsningen.
Hvilke lĂžsninger vi har avvist og hvorfor
Ofte stĂ„r vi overfor situasjonen der vi mĂ„ implementere et felles lager med god ytelse for lesing â skriving pĂ„ en liten web-klynge. Vi har prĂžvd ulike varianter av felles lager for prosjektene vĂ„re, men lite har vĂŠrt i stand til Ă„ tilfredsstille oss umiddelbart pĂ„ flere kriterier. NĂ„ vil vi fortelle hvorfor.
- Glusterfs tilfredsstilte ikke vÄre krav til lesing og skriving, det oppsto problemer med samtidig lesing av et stort antall filer, og det var hÞy belastning pÄ CPU-en. Problemet med Ä lese filer kunne lÞses ved Ä gÄ direkte til brick-ene, men dette er ikke alltid praktisk og generelt sett feil.
- Ceph falt i utvalg pÄ grunn av sin unÞdvendige kompleksitet, som kan vÊre skadelig i prosjekter med 2-4 servere, spesielt hvis prosjektet senere skal vedlikeholdes. Igjen er det betydelige ytelsesbegrensninger som tvinger fram oppbygging av separate lagringsklynger, akkurat som med glusterfs.
- Bruk av en enkelt nfs-server for implementering av felles lager reiser spÞrsmÄl om feiltoleranse.
- s3 â en utmerket populĂŠr lĂžsning for visse oppgaver, men det er heller ikke et filsystem, noe som begrenser bruksomrĂ„dene.
- lsyncd. Hvis vi allerede har begynt Ä snakke om «ikke-filsystemer», bÞr vi ogsÄ ta en gjennomgang av denne populÊre lÞsningen. Ikke bare passer den ikke for toveis utveksling (men hvis man virkelig Þnsker det, kan det gjÞres), men den fungerer ogsÄ ustabilt med et stort antall filer. En annen ulempe er at den er entrÄdet. à rsaken ligger i programmets arkitektur: den bruker inotify for Ä overvÄke objekter i drift, som den smetter inn ved oppstart og ved ny skanning. Rsync brukes som overfÞringsmiddel.
Tutorial: hvordan sette opp et felles lager basert pÄ drbd+ocfs2
En av de mest praktiske lÞsningene for oss ble kombinasjonen ocfs2+drbd. Vi vil nu fortÊlle, hvordan man hurtigt kan oprette en delt lagerlÞsning for to servere baseret pÄ datalÞsninger. Men fÞrst lidt om komponenterne:
DRBD â en lagringssystem fra standardleverancen af Linux, der gĂžr det muligt at replikere data mellem servere i blokke. Den primĂŠre anvendelse er i opbygningen af fejltolerante lagre.
OCFS2 â et filsystem, der muliggĂžr deling af den samme lagerlĂžsning mellem flere systemer. Det indgĂ„r i leverancen af Linux og bestĂ„r af en kernelmodul og userspace vĂŠrktĂžj til at arbejde med filsystemet. OCFS2 kan bruges ikke kun oven pĂ„ DRBD, men ogsĂ„ oven pĂ„ iSCSI med flere forbindelser. I vores eksempel bruger vi DRBD.
Alle handlinger udfÞres pÄ ubuntu server 18.04 i en minimal konfiguration.
Trin 1. Konfigurer DRBD:
I filen /etc/drbd.d/drbd0.res beskriver vi vores virtuelle blokenhed /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 â bruge de samme blokenheder til at lagre metadata
device /dev/drbd0 â brug /dev/drbd0 som sti til drbd.
disk /dev/vdb1 â brug /dev/vdb1
syncer { rate 1000M; } â bruge en gigabit bĂ„ndbredde pĂ„ kanalen
allow-two-primaries â en vigtig mulighed, der tillader ĂŠndringer at blive accepteret pĂ„ to primĂŠre servere
after-sb-0pri, after-sb-1pri, after-sb-2pri â muligheder, der beskriver nodens handlinger ved opdagelse af splitbrain. Du kan finde flere oplysninger i dokumentationen.
become-primary-on both â sĂŠtter begge noder som primĂŠre.
I vores tilfÊlde har vi to helt identiske VM'er, med et dedikeret virtuelt netvÊrk med en bÄndbredde pÄ 10 gigabit.
I vores eksempel er netvĂŠrksnavnene for de to noden i klyngen drbd1 og drbd2. For korrekt funktion skal du matche navne og IP-adresser i /etc/hosts.
10.10.10.192 drbd1
10.10.10.193 drbd2Trin 2. Konfigurer noderne:
PĂ„ begge servere udfĂžrer vi:
drbdadm create-md drbd0 
modprobe drbd
drbdadm up drbd0
cat /proc/drbdVi fÄr fÞlgende:

Vi kan starte synkroniseringen. PĂ„ den fĂžrste node skal du udfĂžre:
drbdadm primary --force drbd0Tjek status:
cat /proc/drbd 
Perfekt, synkroniseringen er startet. Vi venter pÄ, at det afsluttes, og ser resultatet:

Trin 3. Starter synkronisering pÄ den anden node:
drbdadm primary --force drbd0
Vi fÄr fÞlgende:

Nu kan vi skrive til drbd fra to servere.
Trin 4. Installation og konfiguration af ocfs2.
Vi bruger en ganske triviel 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
Den skal skrives til /etc/ocfs2/cluster.conf pÄ begge noder.
Opretter FS pÄ drbd0 pÄ en hvilken som helst node:
mkfs.ocfs2 -L "testVol" /dev/drbd0
Her har vi oprettet FS med etiketten testVol pÄ drbd0 ved at bruge standardindstillingerne.

I /etc/default/o2cb skal der sĂŠttes (som i vores konfigurationsfil)
O2CB_ENABLED=true
O2CB_BOOTCLUSTER=ocfs2cluster og udfÞre pÄ hver node:
o2cb register-cluster ocfs2clusterDerefter aktiverer vi og tilfĂžjer til automatisk opstart alle nĂždvendige enheder:
systemctl enable drbd o2cb ocfs2
systemctl start drbd o2cb ocfs2En del af dette vil allerede vĂŠre startet under konfigurationen.
Trin 5. TilfÞjer monteringspunkter i fstab pÄ begge noder:
/dev/drbd0 /media/shared ocfs2 defaults,noauto,heartbeat=local 0 0Biblioteket /media/shared skal oprettes pÄ forhÄnd.
Her bruger vi indstillingerne noauto, hvilket betyder, at FS ikke vil blive monteret ved opstart (jeg foretrÊkker at montere netvÊrksfiler gennem systemd) og heartbeat=local, hvilket betyder brugen af heartbeat-tjenesten pÄ hver node. Der findes ogsÄ en global heartbeat, som er bedre egnet til stÞrre klynger.
Derefter kan vi montere /media/shared og kontrollere synkroniseringen af indhold.
FÊrdig! Som resultat fÄr vi et mere eller mindre fejltolerant lager med mulighed for skalering og anstÊndig ydeevne.
Kilde: habr.com
