🥇Storage cluster per piccoli web-cluster basati su drbd+ocfs2

Di cosa parleremo:
Come implementare rapidamente uno storage condiviso per due server basato su soluzioni drbd+ocfs2.

A chi sarà utile:
Questo tutorial sarà utile agli amministratori di sistema e a chiunque stia valutando un modo per implementare uno storage o voglia provare una soluzione.

Da quali soluzioni ci siamo allontanati e perché

Spesso ci troviamo nella situazione in cui dobbiamo implementare uno storage condiviso ad alte prestazioni di lettura e scrittura su un piccolo cluster web. Abbiamo provato diverse opzioni per implementare uno storage condiviso per i nostri progetti, ma poche sono state in grado di soddisfarci in base a più criteri. Ora spiegheremo il perché.

Glusterfs non ci ha soddisfatti in termini di prestazioni di lettura e scrittura, si verificavano problemi nella lettura simultanea di un grande numero di file e l'elevato carico sulla CPU. Il problema della lettura dei file poteva essere risolto accedendo direttamente ai brick, ma ciò non è sempre applicabile e, in generale, è scorretto.

Ceph non ci è piaciuto per l'eccessiva complessità, che può essere dannosa su progetti con 2-4 server, specialmente se il progetto viene poi gestito. Anche in questo caso, ci sono seri limiti di prestazioni che costringono a costruire cluster storage separati, come con glusterfs.

L'uso di un singolo server nfs per implementare uno storage condiviso solleva domande in termini di tolleranza ai guasti.

s3 è una soluzione eccellente e popolare per alcune tipologie di compiti, ma non è un file system, il che ne limita l'applicazione.

lsyncd. Se abbiamo già iniziato a parlare di "non-file system", vale la pena esaminare anche questa soluzione popolare. Non solo non è adatta per lo scambio bidirezionale (ma se si desidera ardentemente, si può fare), ma non funziona nemmeno in modo stabile con un gran numero di file. Un'aggiunta piacevole a tutto ciò è che è a thread singolo. La ragione è nell'architettura del programma: utilizza inotify per monitorare gli oggetti di lavoro, che vengono attivati all'avvio e durante la riesaminazione. Come mezzo di trasmissione viene utilizzato rsync.

Tutorial: come implementare uno storage condiviso basato su drbd+ocfs2

Una delle soluzioni più comode per noi è stata l'accoppiamento ocfs2+drbd. Ora vi spiegheremo come implementare rapidamente uno storage condiviso per due server sulla base dei dati delle soluzioni. Ma prima un po' sui componenti:

DRBD — un sistema di storage standard in Linux che consente di replicare i dati tra server in blocchi. L'applicazione principale consiste nella costruzione di storage ad alta disponibilità.

OCFS2 — un file system che consente l'uso condiviso dello stesso storage da più sistemi. Incluso nella distribuzione di Linux, è costituito da un modulo del kernel e da strumenti userspace per lavorare con il file system. OCFS2 può essere utilizzato non solo sopra DRBD, ma anche sopra iSCSI con connessioni multiple. Nel nostro esempio utilizzeremo DRBD.

Tutte le azioni vengono eseguite su ubuntu server 18.04 in configurazione minima.

Passo 1. Configuriamo DRBD:

Nel file /etc/drbd.d/drbd0.res descriviamo il nostro dispositivo a blocchi virtuale /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 — usare gli stessi dispositivi a blocchi per memorizzare i metadati
device /dev/drbd0 — utilizzare /dev/drbd0 come percorso per drbd.
disk /dev/vdb1 — usare /dev/vdb1
syncer { rate 1000M; } — usare la banda di un gigabit
allow-two-primaries — un'opzione importante che consente l'accettazione delle modifiche su due server primari
after-sb-0pri, after-sb-1pri, after-sb-2pri — opzioni che determinano le azioni del nodo in caso di split-brain. Maggiori dettagli possono essere trovati nella documentazione.
become-primary-on both — imposta entrambi i nodi su primari.

Nel nostro caso abbiamo due VM identiche, con una rete virtuale dedicata con una capacità di 10 gigabit.

Nel nostro esempio, i nomi di rete dei due nodi del cluster sono drbd1 e drbd2. Per un corretto funzionamento, è necessario mappare i nomi e gli indirizzi IP dei nodi in /etc/hosts.

10.10.10.192 drbd1
10.10.10.193 drbd2

Passo 2. Configuriamo i nodi:

Su entrambi i server eseguiamo:

drbdadm create-md drbd0

modprobe drbd
drbdadm up drbd0
cat /proc/drbd

Otteniamo quanto segue:

Ora possiamo avviare la sincronizzazione. Sulla prima nodo bisogna eseguire:

drbdadm primary --force drbd0

Controlliamo lo stato:

cat /proc/drbd

Ottimo, la sincronizzazione è iniziata. Attendiamo la fine e vediamo il risultato:

Passo 3. Avviamo la sincronizzazione sul secondo nodo:

drbdadm primary --force drbd0

Otteniamo quanto segue:

Ora possiamo scrivere in drbd da entrambi i server.

Passo 4. Installazione e configurazione di ocfs2.

Utilizzeremo una configurazione abbastanza banale:

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

Deve essere registrato in /etc/ocfs2/cluster.conf su entrambe le nodi.

Creiamo il filesystem su drbd0 su uno qualsiasi dei nodi:

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

Qui abbiamo creato un filesystem con etichetta testVol su drbd0, utilizzando i parametri predefiniti.

In /etc/default/o2cb è necessario impostare (come nel nostro file di configurazione)

O2CB_ENABLED=true 
O2CB_BOOTCLUSTER=ocfs2cluster

ed eseguire su ciascun nodo:

o2cb register-cluster ocfs2cluster

Dopo di che, abilitiamo e aggiungiamo all'avvio automatico tutte le unità necessarie:

systemctl enable drbd o2cb ocfs2
systemctl start drbd o2cb ocfs2

Parte di questo sarà già in esecuzione durante la configurazione.

Step 5. Aggiungiamo i punti di montaggio in fstab su entrambe le nodi:

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

La directory /media/shared deve essere creata in anticipo.

Qui utilizziamo l'opzione noauto, che significa che il filesystem non sarà montato all'avvio (preferisco montare i filesystem di rete tramite systemd) e heartbeat=local, che indica l'uso del servizio heartbeat su ciascun nodo. Esiste anche heartbeat globale, più adatto per cluster di grandi dimensioni.

Successivamente, è possibile montare /media/shared e controllare la sincronizzazione dei contenuti.

Fatto! Di conseguenza, otteniamo uno storage abbastanza tollerante ai guasti con possibilità di scalabilità e prestazioni decenti.

Fonte: habr.com