Project

General

Profile

SetupClusterHA » History » Version 52

Simone Piccardi, 12/21/2010 12:14 PM

1 51 Amministratore Truelite
h1. Configurazione di un Cluster HA
2 1 Amministratore Truelite
3 51 Amministratore Truelite
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_.
4 1 Amministratore Truelite
5
h2. Predisposizione delle due macchine del Cluster
6 51 Amministratore Truelite
7
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_.
8
9 52 Simone Piccardi
Negli esempi seguenti si supporrà allora che ciascuna macchina abbia almeno due interfacce di rete; la prima, @eth0@, connessa alla rete locale, la seconda, @eth1@, connessa direttamente all'altra macchina con un cavo incrociato. Sulla prima interfaccia dovremo configurare l'indirizzo pubblico di ciascuna macchina (nel nostro caso @10.10.0.98@ e @10.10.0.99@) inteso come indirizzo diretto del singolo nodo del cluster, a questo si aggiungerà l'indirizzo del cluster in quanto tale (tenuto sulla macchina che fa da nodo primario, che migrerà sull'altra in caso di switch) che nel nostro caso sarà @10.10.0.2@. Sulla seconda interfaccia metteremo degli indirizzi privati (nel caso dell'esempio @198.168.234.1@ e @198.168.234.2@) usati per la sincronizzazione di DRBD e per il controllo di heartbeat. 
10 51 Amministratore Truelite
11 1 Amministratore Truelite
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.
12
13
h2. Configurazione di DRBD
14 6 Amministratore Truelite
15 52 Simone Piccardi
Il primo passo consiste nell'installazione dei pacchetti necessari, questi nel caso di Debian Sarge sono due: i programmi di gestione di DRBD forniti da drbd0.7-utils, ed i sorgenti del modulo del kernel che gestisce la replicazione dei dati forniti da drbd0.7-module-source. Questo modulo, drbd, può essere installato a mano, nel qual caso si dovrà compilare ed installare dai sorgenti in @/usr/src@, altrimenti si può utilizzare il programma @module-assistant@ che si incaricherà anche di scaricare tutti gli ulteriori pacchetti necessari, di compilare il modulo per il kernel corrente e di installarlo.
16 51 Amministratore Truelite
17 52 Simone Piccardi
Prima di attivare la replicazione dei dati con DRBD occorre eseguirne la configurazione; il file da modificare è @/etc/drbd.conf@, dove dovremo indicare per ciascuna macchina quali sono i dispositivi da usare e su quale indirizzo contattare l'altro nodo; i singoli nodi dovranno essere identificati con il loro hostname (viene sempre usato il risultato del comando @uname -n@), e nel nostro caso saranno servint1 e servint2. Il contenuto finale di @/etc/drbd.conf@ dovrebbe essere allora qualcosa del tipo: 
18 51 Amministratore Truelite
19
<pre>
20 4 Amministratore Truelite
resource r0 {
21
  protocol C;
22
  incon-degr-cmd "echo '!DRBD! pri on incon-degr' | wall ; sleep 60 ; halt -f";
23 27 Amministratore Truelite
  startup {
24 4 Amministratore Truelite
    degr-wfc-timeout 120;    # 2 minutes.
25
  }
26
  disk {
27
    on-io-error   detach;
28
  }
29 1 Amministratore Truelite
  net {
30 4 Amministratore Truelite
  }
31
  syncer {
32
    rate 10M;
33
    group 1;
34 1 Amministratore Truelite
    al-extents 257;
35
  }
36
  on servint1 {
37
    device     /dev/drbd0;
38
    disk       /dev/md3;
39
    address    192.168.234.1:7788;
40
    meta-disk  /dev/hda7r0;
41 51 Amministratore Truelite
  }
42 1 Amministratore Truelite
  on servint2 {
43
    device    /dev/drbd0;
44
    disk      /dev/hda5;
45
    address   192.168.234.2:7788;
46
    meta-disk /dev/hda7r0;
47 4 Amministratore Truelite
  }
48 38 Amministratore Truelite
}
49 1 Amministratore Truelite
</pre>
50
51 52 Simone Piccardi
tenendo conto che su @servint1@ i dati vengono mantenuti sul dispositivo RAID @/dev/md3@ ed i metadati sulla partizione @/dev/hda7@, mentre su @servint2@ i dati sono su @/dev/hda5@ ed i metadati su @/dev/hda7@.
52 1 Amministratore Truelite
53 52 Simone Piccardi
Qualora si vogliano utilizzare più dispositivi occorrerà utilizzare altrettante voci di resource; per ciascuna di esse andrà indicato un diverso device (ad esempio @/dev/drbd1@, @/dev/drbd2@, ecc.) ed ovviamente i rispettivi dischi (o partizioni), si abbia poi cura di usare un diverso valore di address (ad esempio si potrà cambiare la porta con qualcosa del tipo @192.168.234.2:7789@).
54 51 Amministratore Truelite
55 52 Simone Piccardi
Inoltre se questi nuovi dispositivi fanno riferimento agli stessi dischi fisici (ad esempio a diverse partizioni su uno stesso disco) si abbia cura di cambiare il valore della direttiva group nella sezione syncer, poiché la sincronizzazione viene serializzata in ordine crescente di questo valore (e se i dipositivi fanno riferimento agli stessi dischi questo è appunto il comportamento voluto).
56
57
Una volta completata la configurazione di @/etc/drbd.conf@ su uno dei nodi si abbia cura di copiarlo sull'altro perché la configurazione deve essere identica su entrambe le macchine; dopo di che si potrà caricare il modulo @drbd@ ed attivare il servizio con i comandi: 
58
59 51 Amministratore Truelite
<pre>
60 1 Amministratore Truelite
modprobe drbd
61 2 Amministratore Truelite
drbdadm up all
62 51 Amministratore Truelite
</pre>
63 52 Simone Piccardi
64
ripetendo l'operazione su entrambe le macchine. Se si è messo un firewall locale sulle macchine si ricordi di dare accesso alla porta 7788 TCP, o quella che si è specificata nel file di configurazione. Più semplicemente si consenta l'accesso dall'interfaccia eth1. Se tutto è a posto si potrà verificare lo stato di funzionamento di DRBD con:
65
66 1 Amministratore Truelite
<pre>
67
servint1:~# cat /proc/drbd
68 51 Amministratore Truelite
version: 0.7.10 (api:77/proto:74)
69
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
70
 0: cs:Connected st:Secondary/Secondary ld:Inconsistent
71 30 Amministratore Truelite
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0
72 2 Amministratore Truelite
 1: cs:Unconfigured
73 1 Amministratore Truelite
</pre>
74 52 Simone Piccardi
75 2 Amministratore Truelite
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:
76 52 Simone Piccardi
77 51 Amministratore Truelite
<pre>
78 1 Amministratore Truelite
drbdadm -- --do-what-I-say primary all
79
</pre>
80 52 Simone Piccardi
81
che va dato sulla macchina (nel nostro caso @servint1@) che fa da nodo primario. Fatto questo avremo: 
82
83 51 Amministratore Truelite
<pre>
84
servint1:~# cat /proc/drbd
85 1 Amministratore Truelite
version: 0.7.10 (api:77/proto:74)
86
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
87
 0: cs:SyncSource st:Primary/Secondary ld:Consistent
88
    ns:360356 nr:0 dw:0 dr:361240 al:0 bm:21 lo:135 pe:36 ua:221 ap:0
89
        [>...................] sync'ed:  0.6% (69265/69617)M
90
        finish: 1:44:47 speed: 11,252 (10,288) K/sec
91
 1: cs:Unconfigured
92 22 Amministratore Truelite
</pre>
93 2 Amministratore Truelite
<pre>
94 1 Amministratore Truelite
95 51 Amministratore Truelite
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:
96 52 Simone Piccardi
97 14 Amministratore Truelite
<pre>
98 51 Amministratore Truelite
servint1:~# cat /proc/drbd
99 1 Amministratore Truelite
version: 0.7.10 (api:77/proto:74)
100
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
101
 0: cs:Connected st:Primary/Secondary ld:Consistent
102
    ns:71288320 nr:0 dw:0 dr:71288320 al:0 bm:4352 lo:0 pe:0 ua:0 ap:0
103
 1: cs:Unconfigured
104
</pre>
105 52 Simone Piccardi
106 1 Amministratore Truelite
mentre sul nodo secondario avremo qualcosa del tipo:
107 52 Simone Piccardi
108 1 Amministratore Truelite
<pre>
109 12 Amministratore Truelite
servint2:~# cat /proc/drbd
110 1 Amministratore Truelite
version: 0.7.10 (api:77/proto:74)
111
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
112
 0: cs:Connected st:Secondary/Primary ld:Consistent
113 6 Amministratore Truelite
    ns:3028 nr:0 dw:0 dr:3028 al:0 bm:15 lo:0 pe:0 ua:0 ap:0
114 1 Amministratore Truelite
 1: cs:Unconfigured
115 51 Amministratore Truelite
</pre>
116 52 Simone Piccardi
117 1 Amministratore Truelite
e come si può notare i ruoli dei dispositivi sono invertiti.
118 51 Amministratore Truelite
119 52 Simone Piccardi
Adesso potremo verificare il funzionamento del sistema montando (sempre sulla macchina che fa da primario) il dispositivo @/dev/drbd0@, che conterrà quello che era presente sul dispositivo @/dev/md3@, (nel nostro caso un filesystem ext3) oppure utilizzare direttamente il dispositivo stesso per creare (qualora non fosse stato fatto in precedenza come nel nostro caso) un nuovo filesystem.
120 1 Amministratore Truelite
121 52 Simone Piccardi
Una volta completata la sincronizzazione iniziale si potrà attivare o disattivare DRBD direttamente con lo script di avvio @/etc/init.d/drbd@; se per un qualche motivo la sincronizzazione si dovesse perdere, una volta bloccato il servizio si potrà ripetere la procedura precedente per risincronizzare i dispositivi, avendo ovviamente cura di impostare come primario quello che contiene i dati corretti (fare *SEMPRE* un backup prima di una operazione del genere!). 
122 1 Amministratore Truelite
123 30 Amministratore Truelite
h2. Configurazione di heartbeat
124 51 Amministratore Truelite
125 52 Simone Piccardi
Una volta completata la configurazione di DRBD si può configurare @heartbeat@. Il pacchetto da intallare è appunto @heartbeat@, la cui configurazione viene mantenuta in @/etc/ha.d/@. Nel caso di Debian occorre anche copiare due file di configurazione, @ha.cf@ e @haresources@, che di proposito non vengono installati dal pacchetto, ma di cui esiste uno scheletro in forma compressa sotto @/usr/src/doc/heartbeat@. Occorreranno cioè i comandi: 
126 1 Amministratore Truelite
127
<pre>
128 51 Amministratore Truelite
cd /usr/share/doc/heartbeat
129
zcat ha.cf.gz > /etc/ha.d/ha.cf
130
zcat haresources.gz > /etc/ha.d/haresources
131 1 Amministratore Truelite
</pre>
132 51 Amministratore Truelite
133 52 Simone Piccardi
A questo punto si dovranno eseguire le impostazioni che ci servono, i file precedenti sono ampiamente commentati. Per quanto riguarda @ha.cf@ occorre impostare il tempo oltre il quale, in assenza di risposta, si considera un nodo morto (deadtime), la modalità con cui i nodi si verificano (nel caso via rete sull'interfaccia dedicata @eth1@) ed i nomi dei due nodi (anche qui devono corrispondere a quanto restituito dal comando @uname -n@). Il contenuto di questo file (eliminati i commenti) dovrebbe essere qualcosa del tipo:
134
135 1 Amministratore Truelite
<pre>
136
logfacility     local0
137
keepalive 2
138 51 Amministratore Truelite
deadtime 30
139
bcast  eth1
140 7 Amministratore Truelite
auto_failback on
141 6 Amministratore Truelite
node servint1 servint2
142 1 Amministratore Truelite
</pre>
143
144 52 Simone Piccardi
Per quanto riguarda @haresources@ occorre invece indicare quali sono le risorse che dovranno essere gestite da _haertbeat_ in caso di switch; inizieremo soltanto con il volume condiviso, l'IP pubblico del cluster, ed il montaggio del volume, pertanto avremo qualcosa del tipo: 
145
146 51 Amministratore Truelite
<pre>
147
servint1 IPaddr::10.10.0.2/16/eth0 drbddisk::r0 Filesystem::/dev/drbd0::/shared::ext3
148 1 Amministratore Truelite
</pre>
149
150 52 Simone Piccardi
Infine per autenticare la comunicazione fra i due demoni occorre impostare una chiave, questa deve essere immessa nel file @/etc/ha.d/authkeys@; al solito esiste uno scheletro in @/usr/src/doc/heartbeat@ che si può copiare con: 
151
152 1 Amministratore Truelite
<pre>
153 51 Amministratore Truelite
cp authkeys /etc/ha.d/
154 1 Amministratore Truelite
chmod 600 /etc/ha.d/authkeys
155
</pre>
156 52 Simone Piccardi
157 1 Amministratore Truelite
e qui andrà specificata la modalità di autenticazione ed inserita la password, con qualcosa del tipo:
158 52 Simone Piccardi
159 51 Amministratore Truelite
<pre>
160 1 Amministratore Truelite
auth 2
161
2 sha1 unabellapasswordbellalungaemoltocomplicata
162
</pre>
163 52 Simone Piccardi
164
se si connettono le macchina con un cavo cross allora tutto questo è sostanzialmente inutile, e si potrà usare molto più semplicemente qualcosa del tipo: 
165
166 1 Amministratore Truelite
<pre>
167 51 Amministratore Truelite
auth 1
168 35 Amministratore Truelite
1 crc
169 19 Amministratore Truelite
</pre>
170 1 Amministratore Truelite
171
A questo punto si potrà avviare _heartbeat_ direttamente con lo script di avvio lanciando il comando:
172 52 Simone Piccardi
173 51 Amministratore Truelite
<pre>
174 1 Amministratore Truelite
/etc/init.d/heartbeat start
175 51 Amministratore Truelite
</pre>
176 1 Amministratore Truelite
177 52 Simone Piccardi
e (occorre qualche secondo) verificare con @df@ che è stato montato @/dev/drbd0@ (nel nostro caso su @/shared@), e verificare con @ifconfig@ che è stato aggiunto ad @eth0@ l'IP del cluster (nel nostro caso @10.10.0.2@). 
178 42 Amministratore Truelite
179 45 Amministratore Truelite
h2. La configurazione dei servizi
180 17 Amministratore Truelite
181 52 Simone Piccardi
Per la configurazione di un servizio in HA è necessario che questo sia attivato su un solo nodo del cluster; questo significa che gli script di avvio non devono essere chiamati in fase di boot, ma lanciati direttamente da @heartbeat@. Dato che l'installazione standard dei servizi di Debian li attiva su tutti i runlevel occorrerà allora disattivarli. Pertanto utilizzando DHCP, DNS, NFS, CUPS, LDAP, Apache e Samba sarà necessario eseguire una serie di comandi di rimozione con @update-rc.d@, la cosa può essere realizzata in una soluzione unica con qualcosa del tipo: 
182 51 Amministratore Truelite
183
<pre>
184
for i in samba slapd nfs-kernel-server nfs-common dhcp3-server cupsys bind9 apache2
185 42 Amministratore Truelite
do
186 1 Amministratore Truelite
  update-rc.d -f $i remove
187
done
188
</pre>
189 52 Simone Piccardi
190 44 Amministratore Truelite
(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).
191 51 Amministratore Truelite
192 52 Simone Piccardi
Un secondo requisito della gestione dei servizi è che gli eventuali dati interni che essi salvano (in genere sotto @/var/lib@) siano sincronizzati con DRBD cosicché essi possano essere disponibili in caso di passaggio al nodo secondario. Nel nostro caso i servizi attivati sono DHCP, DNS, CUPS, LDAP, Apache e Samba e occorrerà identificare le directory dei dati usate da questi servizi per ricrearle sul disco replicato da DRBD. Questo è stato fatto sul nodo principale con i seguenti comandi: 
193
194 1 Amministratore Truelite
<pre>
195
mkdir -p /shared/var/lib
196 44 Amministratore Truelite
for i in dhcp3 ldap ldap-account-manager nfs samba slapd
197
do
198 1 Amministratore Truelite
  mv /var/lib/$i /shared/var/lib
199
  ln -s /shared/var/lib/$i /var/lib/$i
200 44 Amministratore Truelite
done
201
</pre>
202 52 Simone Piccardi
203
ed analogamente per BIND, i dati temporanei di Samba ed i dati di spool di CUPS e @slurpd@:
204
205 1 Amministratore Truelite
<pre>
206 51 Amministratore Truelite
mkdir -p /shared/var/cache
207
for i in bind cups samba
208 1 Amministratore Truelite
do
209
  mv /var/cache/$i /shared/var/cache
210 42 Amministratore Truelite
  ln -s /shared/var/cache/$i /var/cache/$i
211
done
212 1 Amministratore Truelite
mkdir -p /shared/var/spool
213
for i in cups samba slurpd
214
do
215
  mv /var/spool/$i /shared/var/spool/
216 24 Amministratore Truelite
  ln -s /shared/var/spool/$i /var/spool/$i
217 18 Amministratore Truelite
done
218 34 Amministratore Truelite
</pre>
219 1 Amministratore Truelite
220 52 Simone Piccardi
la stessa operazione si dovrà effettuare anche sul nodo secondario, o alternativamente si dovranno cancellare le stesse directory sotto @/var@ e creati al loro posto i corrispondenti link simbolici, in quest'ultimo caso questi resteranno dangling fintanto che non verrà montato il dispositivo di DRBD (cosa fatta automaticamente da @heartbeat@ in caso di switch, mentre nel primo caso verranno trovati i contenuti originali delle directory ottenuti in fase di installazione. In generale non dovendo essere attivi i servizi sul nodo secondario non cambia nulla, ma qualora essi dovessero partire per sbaglio (o per aggiornamenti che li riavviano anche se non dovrebbero) nel primo caso se non altro il riavvio funzionerebbe.
221
222
Infine se si vuole che le pagine web servite da Apache siano sincronizzate si dovrà spostare anche @/var/www@ (in genere questo è sufficiente, se però si usano altre funzionalità di Apache, che utilizzano altre directory come @/var/cache/apache2@ e @/var/lib/apache2@ andranno spostate anche queste). Questo sul nodo primario si fa, come nel caso precedente, con: 
223
224 51 Amministratore Truelite
<pre>
225 41 Amministratore Truelite
mkdir -p /shared/var/www
226 1 Amministratore Truelite
mv /var/www /shared/var
227
ln -s /shared/var/www /var/www
228 51 Amministratore Truelite
</pre>
229
230 52 Simone Piccardi
mentre sul nodo secondario basterà creare la directory corrispondente. Il problema è però che in genere questo non basta, dato che sotto Apache possono girare una serie di ulteriori applicazioni web, i cui dati a loro volta verranno mantenuti altrove. In particolare qualora si usassere Subversion o Trac sulla macchina sarebbe necessario spostare sul disco condiviso le rispettive directory @/var/svn@ e @/var/trac@. 
231
232 1 Amministratore Truelite
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.
233 30 Amministratore Truelite
234 52 Simone Piccardi
Infine si tenga conto che il sistema di rotazione dei log (@logrotate@) in certi casi esegue il riavvio del servizio, anche se questo non è attivo (trattasi di un problema degli script di configurazione, ma ad esempio questo è quanto avviene con CUPS su Debian Sarge). Il che comporta che occorre assicurarsi che nessuno dei file di @/etc/logrotate.d/@ esegua un riavvio senza prima controllare se il servizio è attivo, questo significa ad esempio modificare le righe seguenti: 
235
236 1 Amministratore Truelite
<pre>
237
postrotate
238
       [ -f /var/run/cups/cupsd.pid ] || invoke-rc.d --quiet cupsys restart > /dev/null && sleep 10
239 51 Amministratore Truelite
endscript
240
</pre>
241 47 Amministratore Truelite
242 52 Simone Piccardi
in @/etc/logrotate.d/cupsys@. Con Debian Etch questo problema non sussiste più. 
243
244 51 Amministratore Truelite
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.
245
246 52 Simone Piccardi
Per il DHCP si abbia cura di usare lo stesso @dhcpd.conf@ su entrambe le macchine, e si controlli anche che @/etc/default/dhcp3-server@ sia identico e che faccia partire il demone specificando l'utilizzo dell'interfaccia corretta (che nel nostro caso è @eth0@) con qualcosa del tipo: 
247
248 30 Amministratore Truelite
<pre>
249 51 Amministratore Truelite
INTERFACES="eth0"
250
</pre>
251 52 Simone Piccardi
252
si abbia cura inoltre di verificare l'esistenza di @/var/lib/dhcp3/dhcpd.leases@. Inoltre occorre indicare ai client di fare riferimento al server con l'indirizzo IP del cluster, questo significa che occorre inserire in @dhcpd.conf@ qualcosa del tipo: 
253
254 51 Amministratore Truelite
<pre>
255
server-identifier 10.10.0.2;
256 40 Amministratore Truelite
server-name servint;
257 51 Amministratore Truelite
</pre>
258
259 52 Simone Piccardi
Per quanto riguarda Samba si abbia cura di impostare manualmente il nome del server in modo che corrisponda a quello del cluster, infatti il default è quello di usare il nome della macchina, che nel nostro caso è quello del singolo nodo. Inoltre si deve indicare a Samba di usare l'indirizzo di rete del cluster; pertanto si dovranno aggiungere alla sezione global di @smb.conf@ le seguenti righe: 
260 40 Amministratore Truelite
261
<pre>
262 51 Amministratore Truelite
   netbios name = SERVINT
263 40 Amministratore Truelite
   interfaces = 10.10.0.2
264 39 Amministratore Truelite
   bind interfaces only = yes
265 51 Amministratore Truelite
</pre>
266
267 52 Simone Piccardi
Inoltre si tenga presente che all'installazione nelle due macchine Samba avrà ottenuto un diverso SID su ciascuna di esse, e che se si sono configurati automaticamente anche gli @smbldap-tools@ (ad esempio con il pacchetto "truelite-fileserver":https://labs.truelite.it/packages/wiki/TrueliteFileServ) questo sarà presente anche nelle rispettive configurazioni, pertanto è sempre opportuno ricavare il SID utilizzato sul nodo principale con: 
268
269 1 Amministratore Truelite
<pre>
270 51 Amministratore Truelite
net getlocalsid
271 1 Amministratore Truelite
</pre>
272 52 Simone Piccardi
273 51 Amministratore Truelite
e poi impostare il valore ottenuto sul nodo secondario con qualcosa del tipo:
274 52 Simone Piccardi
275 51 Amministratore Truelite
<pre>
276 1 Amministratore Truelite
net setlocalsid S-1-5-21-3442639467-1470014585-3232117252
277 51 Amministratore Truelite
</pre>
278 1 Amministratore Truelite
279 52 Simone Piccardi
(si usi il valore restituito dal comando precedente). Detto valore se usato da qualche altro programma (ad esempio in @/etc/smbldap-tools/smbldap.conf@) deve essere identico su entrambe le macchine. 
280
281
Una volta finite le configurazioni di tutti i servizi occorrerà modificare @haresources@ cosicché essi possano essere gestiti da _heartbeat_ in caso di switch. Questo si fa aggiungendo in coda alla riga mostrata in precedenza i nomi degli script di avvio, pertanto avremo qualcosa del tipo: 
282
283 51 Amministratore Truelite
<pre>
284 1 Amministratore Truelite
servint1 IPaddr::10.10.0.2/16/eth0 drbddisk::r0 Filesystem::/dev/drbd0::/shared::ext3 slapd samba bind9 dhcp3-server cupsys apache2
285 51 Amministratore Truelite
</pre>