Truedoc

[[TracNav(TOC)]]

h1. Configurazione di un Cluster HA

In questo caso per _Cluster HA_ si intende un sistema composto da due macchine (dette nodi) in configurazione attivo/passivo, su cui viene gestita automaticamente la sincronizzazione dei dati attraverso DRBD, e lo _switch_ automatico dei servizi in caso di crollo del nodo attivo con l'uso di _heartbeat_.

h2. Predisposizione delle due macchine del Cluster

Per un buon funzionamento del cluster è quantomeno opportuno poter disporre di una interfaccia di rete in più, dedicata alla comunicazione diretta fra i due nodi; questo è importante anche per evitare errori nella rilevazione di un crollo (che normalmente viene fatta tramite una connessione di rete, anche se è possibile usare un collegamento seriale) qualora ad andare giù fosse lo _switch_ e non un singolo nodo. Disponendo dell'hardware necessario (interruttori controllabili da remoto) si può installare _stonith_ per assicurarsi dello spegnimento dell'altro nodo in caso di _switch_.

<pre>

Per poter utilizzare la sincronizzazione dei dati con DRBD occorre predisporre i dischi delle due macchine riservando lo spazio opportuno. Per questo occorrono due partizioni su ciascuna macchina (in realtà si potrebbe fare tutto con una sola, ma questo comporta che gli ultimi 128Mb della partizione devono essere lasciati liberi ed il filesystem presente su di essa opportunamento ridimensionato). La prima partizione sarà quella su cui si mantengono i dati, la seconda deve essere di almeno 128Mb e serve per i metadati usati da DRBD, la partizione dei dati deve essere approssimativamente della stessa dimensione su entrambe le macchine.

h2. Configurazione di DRBD

<pre>

<pre>

<pre>

<pre>

resource r0 {

  protocol C;

  incon-degr-cmd "echo '!DRBD! pri on incon-degr' | wall ; sleep 60 ; halt -f";

  startup {

    degr-wfc-timeout 120;    # 2 minutes.

  }

  disk {

    on-io-error   detach;

  }

  net {

  }

  syncer {

    rate 10M;

    group 1;

    al-extents 257;

  }

  on servint1 {

    device     /dev/drbd0;

    disk       /dev/md3;

    address    192.168.234.1:7788;

    meta-disk  /dev/hda7r0;

  }

  on servint2 {

    device    /dev/drbd0;

    disk      /dev/hda5;

    address   192.168.234.2:7788;

    meta-disk /dev/hda7r0;

  }

}

</pre>

<pre>

<pre>

<pre>

<pre>

<pre>

modprobe drbd

drbdadm up all

</pre>

<pre>

<pre>

servint1:~# cat /proc/drbd

version: 0.7.10 (api:77/proto:74)

SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07

 0: cs:Connected st:Secondary/Secondary ld:Inconsistent

    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0

 1: cs:Unconfigured

</pre>

che ci dice che le due macchine si vedono fra loro, ma anche che lo stato di DRBD è inconsistente ed che i dischi sono entrambi classificati come secondari. A questo punto si potrà definire quale dei due dischi è il primario (quello che deve essere copiato sul secondario), ed iniziare la sincronizzazione dei dispositivi con il comando:

<pre>

drbdadm -- --do-what-I-say primary all

</pre>

<pre>

<pre>

servint1:~# cat /proc/drbd

version: 0.7.10 (api:77/proto:74)

SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07

 0: cs:SyncSource st:Primary/Secondary ld:Consistent

    ns:360356 nr:0 dw:0 dr:361240 al:0 bm:21 lo:135 pe:36 ua:221 ap:0

        [>...................] sync'ed:  0.6% (69265/69617)M

        finish: 1:44:47 speed: 11,252 (10,288) K/sec

 1: cs:Unconfigured

</pre>

<pre>

A questo punto si tratterà solo di attendere il tempo necessario perché venga eseguita la sincronizzazione via rete (la prima volta può essere piuttosto lungo), ed una volta che questa sarà completata avremo sul nodo primario qualcosa del tipo:

<pre>

servint1:~# cat /proc/drbd

version: 0.7.10 (api:77/proto:74)

SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07

 0: cs:Connected st:Primary/Secondary ld:Consistent

    ns:71288320 nr:0 dw:0 dr:71288320 al:0 bm:4352 lo:0 pe:0 ua:0 ap:0

 1: cs:Unconfigured

</pre>

mentre sul nodo secondario avremo qualcosa del tipo:

<pre>

servint2:~# cat /proc/drbd

version: 0.7.10 (api:77/proto:74)

SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07

 0: cs:Connected st:Secondary/Primary ld:Consistent

    ns:3028 nr:0 dw:0 dr:3028 al:0 bm:15 lo:0 pe:0 ua:0 ap:0

 1: cs:Unconfigured

</pre>

e come si può notare i ruoli dei dispositivi sono invertiti.

<pre>

<pre>

h2. Configurazione di heartbeat

<pre>

<pre>

cd /usr/share/doc/heartbeat

zcat ha.cf.gz > /etc/ha.d/ha.cf

zcat haresources.gz > /etc/ha.d/haresources

</pre>

<pre>

<pre>

logfacility     local0

keepalive 2

deadtime 30

bcast  eth1

auto_failback on

node servint1 servint2

</pre>

<pre>

<pre>

servint1 IPaddr::10.10.0.2/16/eth0 drbddisk::r0 Filesystem::/dev/drbd0::/shared::ext3

</pre>

<pre>

<pre>

cp authkeys /etc/ha.d/

chmod 600 /etc/ha.d/authkeys

</pre>

e qui andrà specificata la modalità di autenticazione ed inserita la password, con qualcosa del tipo:

<pre>

auth 2

2 sha1 unabellapasswordbellalungaemoltocomplicata

</pre>

se si connettono le macchina con un cavo cross allora tutto questo è

sostanzialmente inutile, e si potrà usare molto più semplicemente qualcosa del

tipo: 

<pre>

auth 1

1 crc

</pre>

A questo punto si potrà avviare _heartbeat_ direttamente con lo script di avvio lanciando il comando:

<pre>

/etc/init.d/heartbeat start

</pre>

<pre>

h2. La configurazione dei servizi

<pre>

<pre>

for i in samba slapd nfs-kernel-server nfs-common dhcp3-server cupsys bind9 apache2

do

  update-rc.d -f $i remove

done

</pre>

(si tenga conto che nell'upgrade di un pacchetto l'attivazione dei servizi viene in genere ripristinata su tutti i runlevel, si verifichi sempre che le cose siano a posto).

<pre>

<pre>

mkdir -p /shared/var/lib

for i in dhcp3 ldap ldap-account-manager nfs samba slapd

do

  mv /var/lib/$i /shared/var/lib

  ln -s /shared/var/lib/$i /var/lib/$i

done

</pre>

<pre>

<pre>

mkdir -p /shared/var/cache

for i in bind cups samba

do

  mv /var/cache/$i /shared/var/cache

  ln -s /shared/var/cache/$i /var/cache/$i

done

mkdir -p /shared/var/spool

for i in cups samba slurpd

do

  mv /var/spool/$i /shared/var/spool/

  ln -s /shared/var/spool/$i /var/spool/$i

done

</pre>

<pre>

<pre>

<pre>

mkdir -p /shared/var/www

mv /var/www /shared/var

ln -s /shared/var/www /var/www

</pre>

<pre>

Si tenga conto poi che essendo i servizi attivi sul cluster, essi verranno acceduti con l'indirizzo generico di quest'ultimo, per cui occorrerà configurarli in maniera identica su entrambi i nodi, e fare in modo che, dove richiesto, per il nome a dominio compaia sempre quello del cluster e non del singolo nodo e lo stesso per l'indirizzo IP.

<pre>

<pre>

postrotate

       [ -f /var/run/cups/cupsd.pid ] || invoke-rc.d --quiet cupsys restart > /dev/null && sleep 10

endscript

</pre>

<pre>

Per la configurazione di LDAP si rammenti di usare gli stessi certificati (e CA) su entrambe le macchine, si abbia anche cura di creare i certificati in modo che il _commonName_ in essi inserito corrisponda al nome a dominio assegnato all'indirizzo pubblico del cluster, altrimenti non si riuscirà ad accedervi con SSL. Sarà comunque utile inserire nei _subjectAltName_ anche i valori degli indirizzi IP del cluster e dei singoli nodi.

<pre>

<pre>

INTERFACES="eth0"

</pre>

<pre>

<pre>

server-identifier 10.10.0.2;

server-name servint;

</pre>

<pre>

<pre>

   netbios name = SERVINT

   interfaces = 10.10.0.2

   bind interfaces only = yes

</pre>

<pre>

<pre>

net getlocalsid

</pre>

e poi impostare il valore ottenuto sul nodo secondario con qualcosa del tipo:

<pre>

net setlocalsid S-1-5-21-3442639467-1470014585-3232117252

</pre>

<pre>

<pre>

<pre>

servint1 IPaddr::10.10.0.2/16/eth0 drbddisk::r0 Filesystem::/dev/drbd0::/shared::ext3 slapd samba bind9 dhcp3-server cupsys apache2

</pre>