TracNav(TOC)

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.

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.

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>