Klyngelager til små webklynger baseret på drbd+ocfs2

Hvad vi vil tale om:
Sådan implementerer du hurtigt delt lager til to servere baseret på drbd+ocfs2-løsninger.

Hvem vil dette være nyttigt for:
Selvstudiet vil være nyttigt for systemadministratorer og alle, der vælger en lagringsimplementeringsmetode eller ønsker at prøve løsningen.

Hvilke beslutninger afviste vi og hvorfor?

Ofte står vi i en situation, hvor vi skal implementere shared storage med god læse-skriveydelse på en lille webklynge. Vi prøvede forskellige muligheder for at implementere delt lagring til vores projekter, men få var i stand til at tilfredsstille os på flere indikatorer på én gang. Nu skal vi fortælle dig hvorfor.

• Glusterfs tilfredsstillede os ikke med læse- og skriveydelse; der var problemer med samtidig læsning af et stort antal filer, og der var en høj belastning på CPU'en. Problemet med at læse filer kan løses ved at få adgang til dem direkte fra mursten, men dette er ikke altid relevant og er generelt forkert.

• Ceph kunne ikke lide den overdrevne kompleksitet, som kan være skadelig på projekter med 2-4 servere, især hvis projektet efterfølgende vedligeholdes. Igen er der alvorlige ydeevnebegrænsninger, der tvinger os til at bygge separate lagerklynger, som med glusterfs.

• Brug af én NFS-server til at implementere delt lagring rejser spørgsmål med hensyn til fejltolerance.

• s3 er en fremragende populær løsning til en vis række opgaver, men det er ikke et filsystem, hvilket indsnævrer dets omfang.

• lsyncd. Hvis vi allerede er begyndt at tale om "ikke-filsystemer", så er det værd at gennemgå denne populære løsning. Ikke nok med at den ikke er egnet til to-vejs udveksling (men hvis du virkelig vil, så kan du), den fungerer heller ikke stabilt på et stort antal filer. En fin tilføjelse til det hele er, at den er enkeltgevind. Årsagen er i programmets arkitektur: det bruger inotify til at overvåge arbejdsobjekter, som det tildeler ved opstart og under genscanning. rsync bruges som overførselsmedie.

Selvstudium: hvordan man implementerer delt lager baseret på drbd+ocfs2

En af de mest bekvemme løsninger for os var linket ocfs2+drbd. Nu vil vi fortælle dig, hvordan du hurtigt kan implementere delt lager til to servere baseret på en løsningsdatabase. Men først lidt om komponenterne:

DRBD - et lagersystem fra standard Linux-distributionen, der giver dig mulighed for at replikere data mellem servere i blokke. Hovedapplikationen er at bygge fejltolerant lagring.

OCFS2 - et filsystem, der giver delt brug af det samme lager af flere systemer. Inkluderet i Linux-distributionen og er et kernemodul og brugerrumsværktøjer til at arbejde med FS. OCFS2 kan bruges ikke kun over DRBD, men også over 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;
}
}

intern meta-disk — brug de samme blokenheder til at gemme metadata
enhed /dev/drbd0 — brug /dev/drbd0 som stien til drbd-volumenet.
disk /dev/vdb1 - brug /dev/vdb1
syncer { rate 1000M; } — brug gigabit-kanalbåndbredde
tillade-to-primærer - en vigtig mulighed, der gør det muligt at acceptere ændringer på to primære servere
efter-sb-0pri, efter-sb-1pri, efter-sb-2pri - muligheder, der er ansvarlige for nodens handlinger, når splitbrain detekteres. Flere detaljer kan findes i dokumentationen.
blive-primær-på begge — indstiller begge noder til primær.

I vores tilfælde har vi to absolut identiske VM'er med et dedikeret virtuelt netværk med en båndbredde på 10 gigabit.

I vores eksempel er netværksnavnene på to klynge noder drbd1 og drbd2. For korrekt drift skal du matche navnene og IP-adresserne på værter i /etc/hosts.

10.10.10.192 drbd1
10.10.10.193 drbd2

Trin 2. Konfigurer noder:

På begge servere kører vi:

drbdadm create-md drbd0

modprobe drbd
drbdadm up drbd0
cat /proc/drbd

Vi får følgende:

Du kan starte synkronisering. På den første node skal du udføre:

drbdadm primary --force drbd0

Lad os se på status:

cat /proc/drbd

Godt, synkroniseringen er startet. Vi venter til slutningen og ser billedet:

Trin 3. Start 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. Installer og konfigurer ocfs2.

Vi vil bruge en ret 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

Det skal skrives ned /etc/ocfs2/cluster.conf på begge noder.

Vi opretter en FS på drbd0 på enhver node:

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

Her oprettede vi et filsystem med etiketten testVol på drbd0, ved at bruge standardparametrene.

I /etc/default/o2cb skal du indstille (som i vores konfigurationsfil)

O2CB_ENABLED=true 
O2CB_BOOTCLUSTER=ocfs2cluster 

og udfør på hver node:

o2cb register-cluster ocfs2cluster

Så tænder vi og tilføjer alle de enheder, vi skal bruge for at køre automatisk:

systemctl enable drbd o2cb ocfs2
systemctl start drbd o2cb ocfs2

Noget af dette vil allerede køre under opsætningsprocessen.

Trin 5. Tilføj monteringspunkter til fstab på begge noder:

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

Vejviser /media/delt det skal være oprettet på forhånd.

Her bruger vi noauto mulighederne, hvilket betyder, at filen ikke bliver monteret ved opstart (jeg foretrækker at montere netværksfiler via systemd) og heartbeat=local, hvilket betyder at bruge heartbeat-tjenesten på hver node. Der er også globalt hjerteslag, som er mere velegnet til store klynger.

Dernæst kan du montere /media/delt og kontroller indholdssynkronisering.

Udført! Som et resultat får vi mere eller mindre fejltolerant opbevaring med skalerbarhed og anstændig ydeevne.

Kilde: www.habr.com