Archiviazione cluster per piccoli cluster web basati su drbd+ocfs2

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

A chi sarà utile:
Questo tutorial sarà utile per gli amministratori di sistema e chiunque stia considerando un modo per implementare lo storage o desideri provare una soluzione.

Quali soluzioni abbiamo scartato e perché

Spesso ci troviamo nella situazione in cui è necessario implementare uno storage condiviso su un piccolo web cluster con buone performance di lettura e scrittura. Abbiamo provato diverse opzioni per implementare lo storage condiviso nei nostri progetti, ma poche sono state in grado di soddisfarci su più fronti. Ora vi spiegheremo perché.

• Glusterfs non ci ha convinto per le performance di lettura e scrittura; abbiamo riscontrato problemi nella lettura simultanea di un numero elevato di file, con un carico CPU elevato. Il problema della lettura dei file poteva essere risolto accedendo direttamente ai brick, ma non sempre è applicabile e in generale non è corretto.

• Ceph non ci è piaciuto per la complessità eccessiva, che può essere dannosa per progetti con 2-4 server, specialmente se il progetto viene poi gestito. Ci sono, comunque, seri limiti di prestazioni che obbligano a costruire cluster di storage separati, proprio come con glusterfs.

• L'utilizzo di un singolo server NFS per la realizzazione di uno storage condiviso solleva interrogativi sulla resilienza.

• S3 è una soluzione molto popolare per una certa gamma di compiti, ma non è un file system, il che ne limita l'applicazione.

• Lsyncd. Se stiamo parlando di "non-file system", merita menzione questa soluzione popolare. Non solo non è adatta per la sincronizzazione bidirezionale (ma se proprio si desidera, è possibile), ma non funziona nemmeno in modo stabile con un gran numero di file. Inoltre, è un processo a thread singolo. Questo è dovuto all'architettura del programma: utilizza inotify per monitorare gli oggetti di lavoro, che vengono attivati all'avvio e durante la riscanificazione. Per il trasferimento viene utilizzato rsync.

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

Una delle soluzioni più convenienti per noi è stata la combinazione ocfs2+drbd. Ora vi racconteremo come impostare rapidamente uno storage condiviso per due server basato su soluzioni database. Ma prima alcune informazioni sui componenti:

DRBD è un sistema di storage incluso nella distribuzione standard di Linux, che consente di replicare i dati tra i server a blocchi. Il suo uso principale è nella costruzione di archiviazioni ad alta disponibilità.

OCFS2 è un file system che consente l'uso condiviso dello stesso storage da più sistemi. È incluso nella distribuzione di Linux e consiste in un modulo del kernel e strumenti userspace per lavorare con il file system. OCFS2 può essere utilizzato non solo sopra DRBD, ma anche sopra iSCSI con connessione multipla. Nel nostro esempio utilizziamo DRBD.

Tutte le operazioni 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 di blocco virtuale /dev/drbd0:

risorsa 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 interno — usare gli stessi dispositivi a blocchi per la memorizzazione dei metadati
device /dev/drbd0 — usare /dev/drbd0 come percorso per drbd.
disk /dev/vdb1 — usare /dev/vdb1
syncer { rate 1000M; } — utilizzare un gigabit di larghezza di banda della rete
allow-two-primaries — un'opzione importante che consente di accettare 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 informazioni possono essere trovate nella documentazione.
become-primary-on both — imposta entrambi i nodi come primari.

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

Nel nostro esempio, i nomi di rete dei due nodi del cluster sono drbd1 e drbd2. Per il funzionamento corretto, è 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:

Eseguiamo su entrambi i server:

drbdadm crea-md drbd0

modprobe drbd
drbdadm up drbd0
cat /proc/drbd

Otteniamo il seguente:

È possibile avviare la sincronizzazione. Sulla prima nodo è necessario eseguire:

drbdadm primary --force drbd0

Controlliamo lo stato:

cat /proc/drbd

Ottimo, è iniziata la sincronizzazione. Aspettiamo la fine e visualizziamo la situazione:

Passo 3. Avviamo la sincronizzazione sul secondo nodo:

drbdadm primary --force drbd0

Otteniamo il seguente:

Ora possiamo scrivere in drbd da entrambi i server.

Passo 4. Installazione e configurazione di ocfs2.

Utilizzeremo una configurazione piuttosto 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 registrata in /etc/ocfs2/cluster.conf su entrambi i nodi.

Creiamo un FS su drbd0 su un nodo qualsiasi:

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

Qui abbiamo creato un FS 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 

e eseguire su ciascun nodo:

o2cb register-cluster ocfs2cluster

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

systemctl enable drbd o2cb ocfs2
systemctl start drbd o2cb ocfs2

Parte di questo sarà già avviata durante la configurazione.

Passo 5. Aggiungiamo i punti di montaggio in fstab su entrambi i nodi:

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

Directory /media/shared a questo punto deve essere creato in anticipo.

Qui utilizziamo le opzioni noauto, che significano che il FS non verrà montato all'avvio (preferisco montare i file system di rete tramite systemd) e heartbeat=local, che significa utilizzare il servizio heartbeat su ciascun nodo. Esiste anche il heartbeat globale, più adatto per grandi cluster.

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

Fatto! Il risultato è uno storage abbastanza resiliente, con possibilità di scalabilità e buone prestazioni.

Fonte: habr.com