Per alta disponibilità si intende una metodologia di progettazione che mira a mantenere un sistema disponibile all'uso per il maggior tempo possibile. L'obiettivo è quello di ridurre al minimo il tempo di fermo, ad esempio i guasti di sistema e la manutenzione, e di minimizzare il tempo necessario per rilevare e risolvere gli eventi di guasto che si verificano. In pratica, sono necessari meccanismi automatizzati in grado di rilevare e risolvere i guasti, poiché si devono raggiungere livelli di disponibilità superiori.
Sentinel è un'applicazione complessa e articolata su più livelli, che utilizza e fornisce una vasta gamma di servizi, oltre a integrare numerosi sistemi esterni di terze parti per la raccolta e la condivisione dei dati, nonché per la risoluzione dei casi. La maggior parte delle soluzioni ad alta disponibilità permette a chi le implementa di dichiarare le dipendenze fra i servizi che devono garantire un'elevata disponibilità e quelli dipendenti, ma tale possibilità si applica solo ai servizi eseguiti nel cluster stesso. I sistemi esterni a Sentinel, quali ad esempio le origini eventi, devono essere configurati separatamente affinché la loro disponibilità soddisfi le esigenze dell'organizzazione e in modo che possano gestire correttamente le situazioni in cui Sentinel non è disponibile per un certo periodo di tempo, ad esempio in caso di failover. Se i diritti di accesso prevedono limitazioni rigide, ad esempio se si utilizzano sessioni autenticate per inviare/ricevere i dati fra un sistema di terze parti e Sentinel, il sistema terzo deve essere configurato affinché accetti le sessioni o le avvii in qualsiasi nodo del cluster (in questo caso Sentinel deve essere configurato con un IP virtuale). NetIQ non è in grado di garantire un livello specifico di alta disponibilità fra il proprio prodotto e sistemi di terze parti fuori dal suo controllo.
Tutti i cluster ad alta disponibilità necessitano di un qualche tipo di memorizzazione condivisa, affinché sia possibile spostare rapidamente i dati dell'applicazione da un nodo a un altro in caso di errore nel nodo di origine. Anche la memorizzazione deve essere ad alta disponibilità e in genere questo requisito si soddisfa utilizzando la tecnologia SAN (Storage Area Network) connessa ai nodi del cluster mediante una rete Fibre Channel. Altri sistemi utilizzano tecnologie NAS (Network Attached Storage), iSCSI o altre tecnologie che consentono il montaggio in remoto della memorizzazione condivisa. Il requisito fondamentale della memorizzazione condivisa consiste nella possibilità di spostare con precisione la memorizzazione da un nodo guasto a un nuovo nodo dello stesso cluster.
NOTA:per iSCSI si deve utilizzare l'unità MTU (Message Transfer Unit) più grande supportata dall'hardware in uso. L'uso di unità MTU di grandi dimensioni migliora le prestazioni di memorizzazione. Nel caso in cui la latenza e/o la larghezza di banda verso l'unità di memorizzazione siano più lente dei valori consigliati, si potrebbero verificare dei problemi in Sentinel.
Per la memorizzazione condivisa, in Sentinel è possibile utilizzare due approcci di base. Il primo prevede l'ubicazione di tutti i componenti (file binari dell'applicazione, file di configurazione e dati degli eventi) nella memorizzazione condivisa. In caso di failover, la memorizzazione viene smontata dal nodo primario e spostata nel nodo di backup, che carica l'intera applicazione e la configurazione dalla memorizzazione condivisa. Il secondo approccio prevede invece la memorizzazione dei dati degli eventi nella memorizzazione condivisa, mentre i file binari dell'applicazione e i file di configurazione risiedono nel rispettivo nodo del cluster. In caso di failover, viene eseguito lo spostamento nel nodo di backup dei soli dati degli eventi.
Ciascuno di questi due approcci presenta vantaggi e svantaggi, ma il secondo consente di utilizzare i percorsi di installazione standard conformi a FHS, di effettuare la verifica dei pacchetti RPM, di applicare a caldo le patch e di eseguire la riconfigurazione per ridurre al minimo i tempi di fermo.
Questa soluzione illustra una procedura dettagliata mediante un esempio di installazione in un cluster che utilizza la memorizzazione condivisa iSCSI e colloca i file binari dell'applicazione e di configurazione nel rispettivo nodo del cluster.
Uno dei fattori essenziali di un ambiente ad alta disponibilità è l'utilizzo di un metodo affidabile e coerente per monitorare le risorse che devono avere una disponibilità elevata e le eventuali risorse da cui esse dipendono. SLE HAE utilizza un componente denominato Resource Agent che esegue questo monitoraggio. La funzione di Resource Agent consiste nel comunicare lo stato di ciascuna risorsa e, quando richiesto, nell'avviare e arrestare la risorsa stessa.
Al fine di evitare tempi di fermo non necessari, i componenti Resource Agent devono comunicare lo stato delle risorse monitorate in modo affidabile. I falsi positivi (cioè i casi in cui una risorsa viene giudicata in condizione di guasto ma in realtà è in grado di ripristinarsi autonomamente) possono causare la migrazione non necessaria di servizi (con relativi tempi di fermo), mentre i falsi negativi (cioè i casi in cui Resource Agent segnala che una risorsa è in funzione anche se non sta operando correttamente) possono impedire l'uso corretto del servizio. D'altro canto, il monitoraggio esterno di un servizio può risultare alquanto difficoltoso: la porta di un servizio Web potrebbe rispondere ad un semplice ping, ad esempio, ma non essere in grado di fornire dati corretti in risposta a una vera e propria interrogazione. In molti casi le funzionalità di autodiagnosi devono essere integrate nel servizio stesso affinché forniscano valori precisi.
Questa soluzione integra in Sentinel un Resource Agent di tipo OCF, in grado di monitorare gli errori principali di hardware, sistema operativo o sistema Sentinel. Al momento le funzionalità esterne di monitoraggio per Sentinel sono basate sui controlli delle porte IP ed esiste la possibilità che si verifichino falsi positivi e falsi negativi. Per migliorare la precisione di questo componente è stata pianificata per il futuro l'ottimizzazione sia di Sentinel che del Resource Agent.
In un cluster ad alta disponibilità, i servizi critici vengono costantemente monitorati e riavviati automaticamente in altri nodi in caso di errore. Questo tipo di automazione può, però, creare dei problemi, in caso di difficoltà di comunicazione con il nodo primario; nonostante il servizio eseguito nel nodo appaia in stato di errore, in effetti continua a funzionare e a scrivere i dati nella memorizzazione condivisa. In questo caso l'avvio di un nuovo set di servizi in un nodo di backup potrebbe con tutta probabilità danneggiare i dati.
Per evitare che si verifichi questa situazione, i cluster utilizzano numerose tecniche, generalmente definite fencing, fra le quali Split Brain Detection (SBD) e Shoot The Other Node In The Head (STONITH). L'obiettivo principale è quello di evitare il danneggiamento dei dati nella memorizzazione condivisa.