Cluster di tre server in HA + LB con drbd Parte 1

Premessa. Per utilizzare questo sistema sono necessari tre server, fisici o virtuali. Uno sarà lo smistatore di traffico e lo chiamerò balancer, due saranno i nodi su cui sarà smistato il traffico dal blanacer e li chiamerò relay-01 e relay-02. Il balancer deve avere un ip pubblico e un ip privato, i relay possono avere solo l’ip privato. Tutti e tre i server è meglio che siano dislocati dallo stesso provider, risiedano sulla stessa sottorete e siano sullo stesso rack, interconnessi tra loro in fibra (chiedete al vostro fornitore questi dettagli), ma il tutto può funzionare abbastanza bene anche se i server sono dislocati lontani, geograficamente parlando e se sono connessi con una normale rete 100 Mb. Per lo scopo di questa guida, balancer ha ip pubblico 1.2.3.4 e ip privato 10.0.0.10, relay-01 ha ip privato 10.0.0.21 e relay-02 ha ip privato 10.0.0.22. Si userà drbd come sistema raid e ocfs2 come file system per la partizione da tenere sincronizzata. /data è la partizione che sarà sincronizzata e montata sui due relay. Come sistema operativo si utilizzerà Ubuntu server 10.04 LTS su tutti e tre i server. Su tutti e tre i server si comincia installando il sistema operativo base, con solo ssh installato (solo successivamente si installeranno i pacchetti necessari). Inizialmente configureremo i due relay. Nel mio caso ho partizionato i dischi con LVM per avere un po’ di flessibilità aggiuntiva

UUID=6c0cb2ff-14ea-49b7-910c-276dae634220 — 228 MB /boot /dev/mapper/relay–01-root — 1700 GB / /dev/mapper/relay–01-swap — 1000 MB swap /dev/mapper/relay–01-drbd — 150 MB unmounted /dev/mapper/relay–01-dati — 3000 MB unmounted

ma si può procedere con un normale partizionamento come il seguente

/dev/sda1 — 100 MB /boot (primary, ext3, Bootable flag: on) /dev/sda5 — 5000 MB / (logical, ext3) /dev/sda6 — 1000 MB swap (logical) /dev/sda7 — 150 MB unmounted (logical, ext3) (conterrà i meta dati di DRBD) /dev/sda8 — 26 GB unmounted (logical, ext3) (conterrà la directory /data)

Ovviamente è possibile variare le dimensioni e i nomi dei device per adattarsi al proprio disco. L’importante è che /dev/sda7 (nel mio caso /dev/mapper/relay–01-drbd) abbia una dimensione di almeno 128Mb (150 consigliati, non serve usare una dimensione maggiore di 200 Mb) e che sia /dev/sda7 che /dev/sda8 (nel mio caso /dev/mapper/relay–01-drbd e /dev/mapper/relay–01-dati) abbiano identica dimensione su ambo i relay. Inoltre è importante che queste due partizioni NON siano montate. Ricordate che se il vostro partizionamento è del tipo /dev/hda1, /dev/hda5 eccetera, nel proseguo di questa guida dovete tenerne conto! E’ fondamentale che ambo i relay abbiano l’orario perfettamente sincronizzato. A tale scopo è necessario installare un client NTP su entrambi relay-01/relay-02

apt-get install ntp ntpdate

A questo punto passiamo all’installazione di DRBD (gli headers potrebbero già essere installati. Installate se necessario quelli corretti per il vostro kernel: uname -r). relay-01/relay-02

apt-get install linux-headers-2.6.32-22-generic drbd8-utils

Ora configuriamo drbd. Con vi (o nano o l’editor che preferite) editate il file /etc/drbd.conf su ambo i relay e rendetelo come il seguente

# You can find an example in  /usr/share/doc/drbd…/drbd.conf.example include “drbd.d/global_common.conf”; include “drbd.d/*.res”;

Il file /etc/drbd.d/global_common.conf deve essere come questo (sempre su ambo i relay)

global { usage-count yes; # minor-count dialog-refresh disable-ip-verification } common { protocol C; handlers { pri-on-incon-degr “/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f”; pri-lost-after-sb “/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f”; local-io-error “/usr/lib/drbd/notify-io-error.sh; /usr/lib/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ; halt -f”; # fence-peer “/usr/lib/drbd/crm-fence-peer.sh”; # split-brain “/usr/lib/drbd/notify-split-brain.sh root”; out-of-sync “/usr/lib/drbd/notify-out-of-sync.sh root”; # before-resync-target “/usr/lib/drbd/snapshot-resync-target-lvm.sh -p 15 — -c 16k”; # after-resync-target /usr/lib/drbd/unsnapshot-resync-target-lvm.sh; } startup { # wfc-timeout degr-wfc-timeout outdated-wfc-timeout wait-after-sb; degr-wfc-timeout 120; outdated-wfc-timeout 100; become-primary-on both; } disk { # on-io-error fencing use-bmbv no-disk-barrier no-disk-flushes # no-disk-drain no-md-flushes max-bio-bvecs on-io-error detach; } net { # snd‐buf-size rcvbuf-size timeout connect-int ping-int ping-timeout max-buffers # max-epoch-size ko-count allow-two-primaries cram-hmac-alg shared-secret # after-sb-0pri after-sb-1pri after-sb-2pri data-integrity-alg no-tcp-cork allow-two-primaries; after-sb-0pri discard-zero-changes; after-sb-1pri discard-secondary; } syncer { # rate after al-extents use-rle cpu-mask verify-alg csums-alg rate 10M; al-extents 257; } }

Questo file contiene la configurazione generale di default di drbd. Alcune informazioni riguardo i vari settaggi. “protocol C” indica il tipo di sincronizzazione che drbd attuerà. C indica Synchronous replication protocol. Le scritture locali sul nodo primario sono considerate complete dopo che ambo i nodi, locale e remoto, hanno confermato la scrittura. Come risultato, la perdita di un singolo nodo garantisce che non ci sia perdita di dati. Ovviamente è inevitabile che si possa verificare una perdita di dati anche con questo protocollo di replicazione se AMBO i nodi (o il loro sistema di storage) è irrimediabilmente corrotto nello stesso momento. “become-primary-on both” indica che alla partenza del sistema drbd, su entrambi i nodi, drbd stesso diventerà primario. Insieme alla direttiva “allow-two-primaries” è importantissima, perchè ci permetterà in seguito di poter lavorare indifferentemente sui dati, più precisamente sulla partizione drbd montata, di relay-01 o di relay-02 senza perdere in sincronismo e soprattutto ci permette, appunto, di montare la partizione drbd su ambo i nodi. Le altre impostazioni possono essere lasciate come sono. Se volete approfondire, leggete questa documentazione. E’ importantissimo che sia questo file che il successivo che andremo a creare siano perfettamente identici su ambo i relay! Ora dobbiamo creare la configurazione per i nostri due nodi. Sempre con vi creiamo il file /etc/drbd.d/relay.res (sempre su ambo i relay) che conterrà le seguenti righe

resource r0 { on relay-01 {                                # ** EDIT ** inserire l’host name del server 1 (uname -n) device     /dev/drbd0;                # disk       /dev/relay-01/dati;      # ** EDIT ** la partizione data del server 1 address    10.0.0.21:7788;         # ** EDIT ** IP privato del server 1 meta-disk  /dev/relay-01/drbd[0];          # ** EDIT ** la partizione da 128MB per DRBD sul server 1 } on relay-02 {                                # ** EDIT ** inserire l’host name del server 2 (uname -n) device    /dev/drbd0;                 # disk      /dev/relay-02/dati;              # ** EDIT ** la partizione data del server 2 address   10.0.0.22:7788;          # ** EDIT ** IP privato del server 2 meta-disk /dev/relay-02/drbd[0];           # ** EDIT ** la partizione da 128MB per DRBD sul server 2 } }

Ricordatevi di adattare sia i percorsi che gli ip in base alla vostra situazione! E’ il momento di far partire drbd e di sincronizzare i dati. relay-01/relay-02

modprobe drbd drbdadm up all

Potrebbe essere necessario inizializzare i dati, se vi appare questo errore:

Failure: (119) No valid meta-data signature found. ==> Use ‘drbdadm create-md res’ to initialize meta-data area. <== Command ‘drbdsetup 0 disk /dev/relay-02/dati /dev/relay-02/drdb 0 –set-defaults –create-device –on-io-error=detach’ terminated with exit code 10

Diamo quindi, solo in caso di un errore come quello sopra descritto, i seguenti comandi

drbdadm down all drbdadm create-md all

Solo sul secondo relay, indipendentemente dalla presenza o meno dell’errore, eseguiamo questo comando

drbdadm — –discard-my-data connect r0

Se si verificassero errori del tipo “detach first” e simili, eseguite sul relay relativo

drbdadm down all

e poi rieseguite il comando di discard Ultimo passaggio da eseguire sul primo relay

cat /proc/drbd

Quest’ultimo comando dovrebbe darvi un output simile a questo

0: cs:SyncSource st:Primary/Primary ld:Consistent ns:13441632 nr:0 dw:0 dr:13467108 al:0 bm:2369 lo:0 pe:23 ua:226 ap:0 [==========>………] sync’ed: 53.1% (11606/24733)M finish: 1:14:16 speed: 2,644 (2,204) K/sec

Quando la sincronizzazione è terminata invece l’output dovrebbe essere simile al seguente

0: cs:Connected st:Primary/Primary ld:Consistent ns:37139 nr:0 dw:0 dr:49035 al:0 bm:6 lo:0 pe:0 ua:0 ap:0

Per finire, al termine della sincronizzazione, anche il relay-02 deve diventare primario, quindi su ambo i relay, per sicurezza, eseguiamo quest’ultimo comando

drbdadm primary all

Terminati tutti questi passaggi, i due relay sono in “cluster” con i dati delle due partizioni (/dev/mapper/relay–01-dati e /dev/mapper/relay–02-dati) che si sincronizzano in background. Allo stato dell’arte attuale non è ancora possibile lavorare realmente sui dati perchè non abbiamo ancora creato nè il mount point condiviso nè tantomeno abbiamo creato un file system sulle partizioni. Vediamo come procedere con i passaggi finali. Cluster in High Availability e Load Balancing – parte 2

---

Introduzione: Cluster in High Availability e Load Balancing (concetti di base) Parte uno: Cluster in High Availability e Load Balancing – parte 1 (DRBD) Parte due: Cluster in High Availability e Load Balancing – parte 2 (ocfs2) Parte tre: Cluster in High Availability e Load Balancing – parte 3 (cosa e come condividere)

---