A.4.1 Configurazione iniziale

Configurare l'hardware di computer, rete e memorizzazione, i sistemi operativi, gli account utente e altre risorse di base del sistema in funzione dei requisiti specificati per Sentinel e di quelli locali del cliente. Sottoporre i sistemi a prova per verificare che funzionino correttamente e siano stabili.

A.4.2 Configurazione della memorizzazione condivisa

Configurare la memorizzazione condivisa e verificare che sia possibile montarla in ciascun nodo del cluster. Se si utilizza Fibre Channel e un SAN, potrebbero essere necessari collegamenti fisici e altre configurazioni. La memorizzazione condivisa verrà utilizzata per il database e i dati degli eventi di Sentinel; deve quindi essere di dimensioni appropriate per le esigenze dell'ambiente del cliente sulla base della frequenza eventi prevista e delle policy di conservazione dei dati.

Un'implementazione tipica potrebbe includere un SAN veloce collegato mediante Fibre Channel a tutti i nodi del cluster e un RAID di grande capacità per la memorizzazione dei dati locali degli eventi. Per la memorizzazione in rete più lenta si potrebbe utilizzare un nodo NAS o iSCSI separato. Se il nodo del cluster consente di montare la memorizzazione locale come dispositivo di blocco normale, è possibile utilizzarlo per la soluzione. La memorizzazione in rete può essere montata anche come dispositivo di blocco, oppure può essere un volume NFS o CIFS.

La soluzione esemplificativa utilizzerà destinazioni iSCSI configurate in una macchina virtuale SUSE Linux. La macchina virtuale è storage03 come elencato in Configurazione iniziale. È possibile creare dispositivi iSCSI utilizzando qualsiasi file o dispositivo di blocco; tuttavia, per ragioni di semplicità, in questo caso è stato utilizzato un file creato a tale scopo.

Eseguire la connessione a storage03 e avviare una sessione della console. Per creare un file vuoto delle dimensioni desiderate per la memorizzazione locale di Sentinel, utilizzare il comando dd:

dd if=/dev/zero of=/localdata count=10240000 bs=1024

In questo caso è stato creato un file di 10 GB contenente degli zeri (copiato dal pseudo-dispositivo dev/zero). Per dettagli sulle opzioni della riga di comando, vedere le informazioni o la pagina del manuale relativa al comando dd. Ad esempio, è possibile creare "dischi"di dimensioni diverse. Le destinazioni iSCSI trattano questo file come se fosse un disco ma, naturalmente, si può utilizzare anche un disco vero e proprio.

Per creare un file per la memorizzazione in rete, ripetere la procedura:

dd if=/dev/zero of=/networkdata count=10240000 bs=1024

In questo esempio sono stati utilizzati due file ("dischi") delle stesse dimensioni e con le medesime caratteristiche prestazionali. Per l'installazione in un ambiente di produzione, la memorizzazione locale può essere collocata in un SAN veloce, mentre quella in rete in un volume iSCSI, NFS o CIFS più lento.

Configurare i file come destinazioni iSCSI:

Nella procedura precedente sono illustrate due destinazioni iSCSI nel server all'indirizzo IP 10.0.0.3. Verificare in ciascun nodo del cluster che sia possibile montare il dispositivo di memorizzazione condivisa per i dati locali. È inoltre necessario formattare (una volta) i dispositivi:

Ripetere i passaggi da 1 a 15 della procedura precedente per verificare che la memorizzazione condivisa locale possa essere montata in ciascun nodo del cluster. Sostituire l'IP del nodo indicato al passaggio 5 con un diverso IP (ad esempio node02 > 10.0.0.2).

A.4.3 Installazione di Sentinel

Per installare Sentinel è possibile utilizzare due metodi: installazione di tutti i componenti nella memorizzazione condivisa (utilizzando l'opzione --location per ridirigere l'installazione di Sentinel nell'ubicazione in cui è stata montata la memorizzazione condivisa) oppure collocazione dei soli dati variabili dell'applicazione nella memorizzazione condivisa.

Per questa soluzione esemplificativa è stato scelto il secondo approccio, cioè l'installazione di Sentinel in ciascun nodo del cluster che può ospitarlo. La prima volta che si installa Sentinel è necessario eseguire un'installazione completa che includa i file binari dell'applicazione, i file di configurazione e tutti gli archivi dei dati. Le installazioni successive negli altri nodi del cluster includeranno soltanto l'installazione dell'applicazione, presupponendo che i dati di Sentinel saranno disponibili successivamente (ad esempio dopo il montaggio della memorizzazione condivisa).

Sentinel verrà installato in ciascun nodo del cluster, mentre nella memorizzazione condivisa verranno memorizzati solo i dati variabili dell'applicazione. In questo modo i file binari dell'applicazione e di configurazione vengono memorizzati in ubicazioni standard, che permettono di verificare gli RPM e anche di supportare l'applicazione a caldo delle patch in alcuni scenari.

Ripetere l'istallazione negli altri nodi:

Il programma di installazione iniziale di Sentinel crea un account utente a disposizione del prodotto, che utilizza l'ID utente successivo disponibile al momento dell'istallazione. Le installazioni successive in modalità automatica avverranno tentando di utilizzare il medesimo ID utente per la creazione degli account, ma esiste la possibilità che si generino conflitti (se i nodi del cluster non sono identici al momento dell'istallazione). Si consiglia di eseguire una delle operazioni seguenti:

Al termine della procedura Sentinel dovrebbe essere installato in tutti i nodi, ma è probabile che funzioni correttamente soltanto nel primo nodo fino a quando non verrà eseguita la sincronizzazione di varie chiavi durante la configurazione delle risorse del cluster.

A.4.4 Installazione del cluster

Installare il software del cluster in ciascun nodo e registrare questi ultimi in Cluster Manager. Le procedure per eseguire questa operazione variano a seconda dell'implementazione del cluster, ma al termine del processo tutti i nodi del cluster devono apparire nella console di gestione.

Per questa soluzione esemplificativa si installerà SUSE Linux High Availability Extension, a cui verranno sovrapposti i Resource Agent specifici di Sentinel:

Se per il monitoraggio di Sentinel non si utilizza il Resource Agent OCF, si dovrà probabilmente sviluppare una soluzione di monitoraggio analoga per l'ambiente cluster locale. Il Resource Agent OCF di Sentinel è un semplice script di shell che esegue una vasta gamma di controlli per verificare che Sentinel funzioni correttamente. Se si desidera sviluppare una soluzione personalizzata, utilizzare Resource Agent come esempio (Resource Agent è memorizzato in sentinel-ha.rpm all'interno del pacchetto di download di Sentinel).

Esistono varie possibilità per eseguire la configurazione di un cluster SLE HAE, ma in questo esempio si utilizzeranno opzioni volte alla semplicità. La prima operazione da eseguire è l'installazione del software principale di SLE HAE; la procedura è descritta dettagliatamente nella documentazione di SLE HAE. Per informazioni sull'installazione dei componenti aggiuntivi di SLES, vedere la Guida per la distribuzione.

È necessario installare SLE HAE in tutti i nodi del cluster, node01 e node02 in questo esempio. Il componente aggiuntivo installerà il software principale per la gestione del cluster e le comunicazioni, nonché vari Resource Agent utilizzati per monitorare le risorse del cluster.

Dopo l'installazione del software del cluster, è necessario installare un ulteriore RPM per rendere disponibili i Resource Agent del cluster specifici di Sentinel. RPM è disponibile in novell-Sentinel-ha-7.1*.rpm nel download normale di Sentinel, che è stato decompresso per installare il prodotto.

Copiare il file novell-Sentinel-ha-7.1*.rpm nella directory /tmp di ciascun nodo del cluster, quindi:

cd /tmp

rpm -i novell-Sentinel-ha-7.1*.rpm

A.4.5 Configurazione del cluster

Per registrare ciascun nodo come membro del cluster, è necessario configurare il software del cluster. Durante questa configurazione è possibile impostare anche le risorse di fencing e STONITH, al fine di garantire la coerenza del cluster.

Per la soluzione esemplificativa si utilizza la configurazione più semplice senza ridondanza aggiuntiva o altre funzioni avanzate. Inoltre, si è scelto di utilizzare un indirizzo unicast (invece dell'indirizzo multicast preferibile), in quanto richiede una minore interazione con gli amministratori di rete ed è sufficiente per eseguire una prova. Infine, viene configurata una semplice risorsa di fencing basata su SBD.

Si utilizzeranno indirizzi IP privati per le comunicazioni all'interno del cluster e la modalità unicast per evitare di richiedere un indirizzo multicast all'amministratore di rete. La soluzione utilizzerà inoltre una destinazione iSCSI configurata nella stessa macchina virtuale SUSE Linux in cui risiede la memorizzazione condivisa e che funge da dispositivo SBD per il fencing. Come nel caso precedente, è possibile creare dispositivi iSCSI utilizzando qualsiasi file o dispositivo di blocco; tuttavia, per ragioni di semplicità, in questo caso è stato utilizzato un file creato a tale scopo.

La procedura di configurazione seguente è molto simile a quella illustrata in Configurazione della memorizzazione condivisa:

Configurazione di SBD

Eseguire la connessione a storage03 e avviare una sessione della console. Per creare un file vuoto delle dimensioni desiderate, utilizzare il comando dd:

dd if=/dev/zero of=/sbd count=1024 bs=1024

In questo caso è stato creato un file di 1 MB contenente degli zeri (copiato dal pseudo dispositivo /dev/zero).

Configurare il file come destinazione iSCSI:

Questa procedura dovrebbe esporre una destinazione iSCSI per il dispositivo SBD nel server all'indirizzo IP 10.0.0.3 (storage03).

Configurazione del nodo

Eseguire la connessione a un nodo del cluster (node01) e aprire una finestra della console:

Eseguire la connessione a ciascun nodo aggiuntivo (node02) e aprire una finestra della console:

In alcuni casi la comunicazione con il cluster non viene inizializzata correttamente. Se il cluster non si avvia (il servizio openais non viene avviato):

In alcuni casi lo script potrebbe non essere completato perché il servizio xinetd non aggiunge correttamente il nuovo servizio csync2. Tale servizio è necessario affinché l'altro nodo possa eseguire la sincronizzazione dei file di configurazione del cluster fino a questo nodo. Se si rilevano errori del tipo csync2 run failed, potrebbe essersi verificato questo problema. Per risolverlo, eseguire: kill -HUP `cat /var/run/xinetd.init.pid e avviare nuovamente lo script sleha-join.

A questo punto dovrebbe essere possibile eseguire il comando crm_mon in ciascun nodo del cluster e verificare che il cluster funzioni correttamente. In alternativa è possibile utilizzare la console Web Hawk (le credenziali di default per il login sono 'hacluster / linux').

In questo esempio sono presenti altri due parametri che devono essere regolati; la loro applicazione al cluster di produzione del cliente dipende dalla configurazione specifica:

A.4.6 Configurazione delle risorse

Come anticipato per l'installazione del cluster, questa soluzione include un Resource Agent di tipo OCF che monitora i servizi principali in SLE HAE e, se lo si desidera, è possibile creare delle alternative personalizzate. Il software dipende anche da numerose altre risorse per cui vengono forniti di default alcuni Resource Agent inclusi in SLE HAE. Se non si desidera utilizzare SLE HAE, le risorse aggiuntive seguenti dovranno essere monitorate utilizzando un'altra tecnologia:

Esistono anche ulteriori risorse aggiuntive, come ad esempio MongoDB utilizzato per la funzione Security Intelligence e il bus dei messaggi ActiveMQ. Per il momento esse vengono monitorate nell'ambito dei servizi principali.

Si utilizzeranno versioni semplici delle risorse necessarie, come ad esempio il Resource Agent del file system. È possibile utilizzare anche risorse cluster più sofisticate, quali cLVM, cioè una versione del file system con volume logico.

La soluzione esemplificativa include uno script crm che facilita la configurazione del cluster. Tale script recupera le variabili necessarie per la configurazione dal file per l'installazione in modalità automatica generato durante l'installazione di Sentinel. Se non è stato generato il file di configurazione o se si desidera cambiare la configurazione delle risorse, è possibile modificare lo script secondo necessità.

Eseguire la connessione al nodo originale in cui è stato installato Sentinel (deve essere il nodo in cui è stata eseguita l'istallazione completa) ed eseguire le operazioni seguenti (<SHARED1> è il volume condiviso creato precedentemente):

mount /dev/<SHARED1> /var/opt/novell

cd /usr/lib/ocf/resource.d/novell

./install-resources.sh

Potrebbero verificarsi dei problemi noti relativi alle nuove risorse che compaiono nel cluster; in questo caso eseguire /etc/rc.d/openais restart in node02.

Lo script install-resources.sh richiederà un paio di valori, più precisamente l'IP virtuale che si desidera venga utilizzato per l'accesso a Sentinel e il nome del dispositivo usato per la memorizzazione condivisa, quindi creerà automaticamente le risorse di cluster necessarie. Si noti che per l'esecuzione dello script il volume condiviso deve già essere stato montato e il file dell'istallazione in modalità automatica (/tmp/install.props) creato durante l'installazione di Sentinel deve essere presente. Non è necessario eseguire questo script in altri nodi oltre a quello installato per primo, in quanto tutti i file relativi alla configurazione verranno sincronizzati automaticamente con gli altri nodi.

Se l'ambiente del cliente è diverso da quello di questa soluzione esemplificativa, è possibile modificare il file resources.cli (nella stessa directory) e cambiare le definizioni originarie dalla stessa ubicazione. Ad esempio, la soluzione esemplificativa utilizza una semplice risorsa file system, ma è possibile utilizzare anche una risorsa cLVM maggiormente capace di riconoscere il cluster.

Dopo aver eseguito lo script di shell, è possibile inviare un comando di stato crm e il risultato dovrebbe essere analogo a quello riportato di seguito:

crm status

Last updated: Thu Jul 26 16:34:34 2012
Last change: Thu Jul 26 16:28:52 2012 by hacluster via crmd on node01
Stack: openais
Current DC: node01 - partition with quorum
Version: 1.1.6-b988976485d15cb702c9307df55512d323831a5e
2 Nodes configured, 2 expected votes
5 Resources configured.

Online: [ node01, node02 ]
stonith-sbd    (stonith:external/sbd):    Started node01
 Resource Group: sentinelgrp
     sentinelip    (ocf::heartbeat:IPaddr2):    Started node01
     sentinelfs    (ocf::heartbeat:Filesystem):    Started node01
     sentineldb    (ocf::novell:pgsql):    Started node01
     sentinelserver    (ocf::novell:sentinel):    Started node01

A questo punto è necessario configurare nel cluster le risorse per Sentinel. È possibile analizzare come vengono configurate e raggruppate nello strumento di gestione del cluster, ad esempio eseguendo un comando di stato crm.

A.4.7 Configurazione della memorizzazione in rete

L'ultima operazione di questa procedura riguarda la configurazione della memorizzazione in rete, affinché Sentinel possa eseguire la migrazione delle partizioni degli eventi in dispositivi di memorizzazione meno costosi. Questa operazione è facoltativa e, in effetti, la memorizzazione in rete non deve essere configurata per l'alta disponibilità così come il resto del sistema. È possibile utilizzare una directory qualsiasi (montata o meno da un SAN) o un volume NFS o CIFS.

Fare clic su Memorizzazione nella barra superiore dei menu, selezionare Configurazione e successivamente uno dei pulsanti di scelta di Memorizzazione in rete corrispondente a un dispositivo non configurato.

Si utilizzerà una semplice destinazione iSCSI come ubicazione di rete per la memorizzazione condivisa, praticamente con la stessa configurazione della memorizzazione locale. Nelle implementazioni di produzione è probabile che le tecnologie di memorizzazione utilizzate siano di tipo diverso.

Per configurare la memorizzazione in rete affinché Sentinel possa utilizzarla, eseguire la procedura seguente:

La soluzione esemplificativa utilizza versioni semplici delle risorse necessarie, quali ad esempio il semplice Resource Agent del file system; i clienti possono scegliere anche risorse di cluster più sofisticate, come ad esempio cLVM (una versione del file system con volume logico).