Panoramica sull'High Availability Add-On

Un cluster è costituito da due i più computer (chiamati nodi o membri), che operano insieme per eseguire un compito. Sono presenti quattro tipi principali di cluster:

I cluster di archiviazione (storage) forniscono una immagine uniforme del file system sui server presenti in un cluster, permettendo ai server stessi di leggere e scrivere simultaneamente su di un file system condiviso singolo. Un cluster di archiviazione semplifica l'amministrazione dello storage, limitando l'installazione ed il patching di applicazioni su di un file system. Altresì, con un file system cluster-wide, un cluster di archiviazione elimina la necessità di copie ridondanti di dati dell'applicazione, semplificando il processo di backup e di disaster recovery. High Availability Add-On fornisce uno storage clustering insieme al Red Hat GFS. (parte del Resilient Storage Add-On).

I cluster High-availability forniscono una disponibilità continua dei servizi tramite l'eliminazione dei così detti single points of failure, e tramite l'esecuzione del failover dei servizi da un nodo del cluster ad un altro nel caso in cui il nodo diventi non operativo. Generalmente i servizi presenti in un cluster high-availability leggono e scrivono i dati (tramite un file system montato in modalità di lettura-scrittura). Per questo motivo un cluster high-availability deve essere in grado di garantire l'integrità dei dati, poichè un nodo del cluster può assumere il controllo di un servizio da un altro nodo. La presenza di errori in un cluster high-availability non risulta essere visibile da parte di client esterni al cluster. (I cluster high-availability sono talvolta indicati come cluster di failover.) High Availability Add-On fornisce un clustering high-availability attraverso il proprio componente High-availability Service Management, rgmanager.

I cluster a bilanciamento del carico 'cluster load-balancing' inviano le richieste del servizio di rete a nodi multipli del cluster, in modo da bilanciare il carico richiesto tra i nodi del cluster. Il bilanciamento del carico fornisce una scalabilità molto economica, poichè è possibile corrispondere il numero di nodi in base ai requisiti del carico. Se un nodo all'interno del cluster risulta essere non operativo, il software per il bilanciamento del carico rileva l'errore e ridireziona le richieste ad altri nodi del cluster. Il fallimento di un nodo nel cluster load-balancing non risulta essere visibile da parte dei client esterni al cluster. Il bilanciamento del carico è disponibile attraverso il Load Balancer Add-On.

I cluster High-performance utilizzano i nodi del cluster per eseguire processi di calcolo simultanei. Un cluster high-performance permette alle applicazioni di lavorare in parallelo aumentando così la prestazione delle applicazioni. (I cluster High performance vengono anche identificati come cluster computational o grid computing.)

High Availability Add-On è un set integrato di componenti software il quale può essere impiegato in una varietà di configurazioni idonee per far fronte alle vostre esigenze di prestazione, high-availability, di bilanciamento del carico, scalabilità, file sharing e di risparmio.

High Availability Add-On consiste nei seguenti componenti:

È possibile altresì integrare i seguenti componenti all'High Availability Add-On:

L'infrastruttura del cluster di High Availability Add-On fornisce le funzioni di base per un gruppo di computer (chiamati nodi o membri), in modo da poter operare insieme come un cluster. Una volta formato il cluster utilizzando l'infrastruttura del cluster stesso, è possibile utilizzare altri componenti per far fronte alle esigenze del proprio cluster (per esempio per l'impostazione di un cluster per la condivisione dei file su di un file system GFS2, oppure per l'impostazione del servizio di failover). L'infrastruttura del cluster esegue le seguenti funzioni:

Il Quorum è un algoritmo di voto usato da CMAN.

Un cluster potrà operare correttamente solo in presenza di un accordo tra i membri relativo al loro stato. Quindi, un cluster risulta avere un quorum se la maggior parte dei nodi sono attivi, in comunicazione e conformi ai membri attivi del cluster. Per esempio, è possibile avere un quorum in un cluster a tredici nodi se sette o più nodi sono in comunicazione tra loro. Se il settimo nodo risulta inattivo il cluster perderà il suo quorum e non sarà più in funzione.

Per impedire problematiche di split-brain è necessario avere un quorum. In assenza del quorum si potrà verificare un errore di comunicazione sul cluster a tredici nodi, il quale potrà causare una situazione nella quale sei nodi svolgeranno le proprie funzioni sullo storage condiviso, e altri sei nodi che a loro volta svolgeranno le loro funzioni in modo indipendente. A causa di un errore di comunicazione i due cluster parziali sovrascriveranno aree del disco corrompendo il file system. Forzando l'implementazione delle regole del quorum, solo uno dei cluster parziali potrà usare lo storage condiviso, proteggendo così l'integrità dei dati.

Il quorum non è in grado di impedire situazioni di split-brain, ma è in grado di decidere qual è il membro dominante. Così facendo è possibile avere un funzionamento corretto nel cluster. In presenza di problematiche di split-brain il quorum impedisce qualsiasi attività ad un gruppo (o gruppi) del cluster.

Il quorum del cluster viene determinato per mezzo di una comunicazione tra i nodi tramite Ethernet. Facoltativamente il quorum può essere determinato usando una combinazione di messaggi per mezzo di Ethernet e un quorum disk. Per un quorum usando Ethernet, esso consiste in una maggioranza semplice (50% dei nodi + 1 extra). Nella configurazione di un quorum disk, il quorum consiste nelle condizioni specificate dall'utente.

Un dominio di failover è un sottoinsieme ordinato di membri al quale è possibile assegnare un servizio. I domini di failover, anche se utili per la personalizzazione del cluster, non sono necessari per il normale funzionamento.

Di seguito viene riportato un elenco di semantiche relative alle opzioni in riferimento ai comportamenti di un dominio di failover in base alle diverse opzioni di configurazione.

Ordering, restriction e nofailback sono flag e possono essere usati insieme in vari modi (es. ordered+restricted, unordered+unrestricted, ecc.). Queste combinazioni possono interessare sia l'avvio del servizio dopo la formazione del quorum iniziale, che i membri del cluster che assumono il controllo dei servizi in presenza di un fallimento.

RGManager dispone di tre politiche per il ripristino del servizio personalizzabili dall'amministratore in base al servizio.

<service name="myservice" max_restarts="3" restart_expire_time="300" ...>
  ...
</service>

Quanto di seguito riportato mostra la struttura di un albero delle risorse con un elenco corrispondente il quale definisce ogni area.

    <service name="foo" ...>
        <fs name="myfs" ...>
            <script name="script_child"/>
        </fs>
        <ip address="10.1.1.2" .../>
    </service>

Le seguenti operazioni riguardano sia i servizi che le macchine virtuali, ad eccezione dell'operazione di migrazione che riguarda solo le macchine virtuali.

RGManager gestisce le macchine virtuali in modo diverso da altri servizi non-VM.

RGManager prevede il ritorno dei seguenti valori dagli agent delle risorse:

Il modello DLM locking fornisce un insieme ricco di modalità per il locking e di esecuzioni sincrone e asincrone. Una applicazione è in grado di acquisire un blocco su una risorsa. Un rapporto del tipo one-to-many è presente tra le risorse e i lock: una risorsa può avere lock multipli ad essa associati.

Una risorsa può essere un oggetto, come ad esempio un file, una struttura dati, un database o una routine eseguibile, ma non deve corrispondere necessariamente ad uno di questi elementi. L'oggetto associato con la risorsa del lock determina la granularità del lock stesso. Per esempio, il locking di un intero database è considerato un locking con granularità grossolana. Al contrario, il locking di elementi singoli presenti in un database viene considerato come un locking con granularità più dettagliata.

Il DLM locking supporta:

DLM fornisce i propri meccanismi per il supporto delle funzioni di locking, ad esempio una comunicazione tra i nodi per la gestione del traffico, o i protocolli per riassumere il controllo del lock dopo il fallimento di un nodo o per la migrazione dei blocchi quando un nodo si unisce al cluster. Tuttavia DLM non fornisce alcun meccanismo per la gestione del cluster stesso. Infatti per questo motivo DLM deve operare in un cluster insieme con un secondo ambiente in grado di fornire i seguenti requisiti minimi:

DLM opera con qualsiasi ambiente dell'infrastruttura del cluster in grado di fornire i requisiti minimi sopra riportati. La scelta di un ambiente open source o closed source dipende dalle preferenze dell'utente. Tuttavia il limite principale di DLM è la quantità di prove eseguite con i diversi ambienti.

Lo stato di un lock indica lo stato corrente di una richiesta. Un lock presenta sempre uno dei seguenti stati:

Lo stato di un lock viene determinato dalla rispettiva modalità richiesta e dalle modalità dei lock presenti sulla stessa risorsa.

La gestione del software di Red Hat High Availability Add-On consiste nell'uso dei tool di configurazione per specificare il rapporto tra i componenti del cluster. I seguenti tool di configurazione del cluster sono disponibili con Red Hat High Availability Add-On:

Sia RHEL HA che RHEV forniscono i meccanismi utili per rendere disponibili le macchine virtuali HA (elevata disponibilità). A causa della loro funzionalità fare attenzione nella scelta del prodotto più idoneo a soddisfare le vostre esigenze. Di seguito sono riportate alcune linee guida per la scelta di RHEL HA o RHEV per HA delle VM.

Per il conteggio delle macchine virtuali e degli host fisici:

Utilizzo della macchina virtuale:

RHEL 5 supporta due piattaforme di virtualizzazione. Xen è supportato dalla release RHEL 5.0. KVM è stato introdotto con RHEL 5.4.

RHEL 6 supporta solo KVM come piattaforma di virtualizzazione.

RHEL 5 AP Cluster supporta sia KVM che Xen nelle macchine virtuali in esecuzione, gestite dall'infrastruttura cluster host.

RHEL 6 HA supporta KVM nelle macchine virtuali in esecuzione, gestite dall'infrastruttura cluster host.

Di seguito vengono riportati i diversi scenari attualmente supportati da Red Hat:

Non ha importanza il tipo di macchine virtuali eseguite come risorse gestite. Qualsiasi guest supportato da Xen o KVM in RHEL, potrà essere utilizzato come guest ad elevata disponibilità. Ciò include le varianti di RHEL (RHEL3, RHEL4, RHEL5) e altre variati di Microsoft Windows. Consultare la documentazione di RHEL per l'ultimissimo elenco di sistemi operativi guest supportati con ogni hypervisor.

Questo si riferisce a RHEL Cluster/HA in esecuzione nei guest virtualizzati su una varietà di piattaforme virtualizzate. In questo caso RHEL Clustering/HA viene utilizzato principalmente per l'esecuzione delle applicazioni all'interno dei guest ad elevata disponibilità. Questo scenario è simile all'impiego tradizionale di RHEL Clustering/HA negli host bare-metal. La differenza è che il Clustering viene eseguito all'interno dei guest.

Di seguito viene riportato un elenco di piattaforme di virtualizzazione e il livello di supporto attualmente disponibile per l'esecuzione dei cluster guest utilizzando RHEL Cluster/HA. Nell'elenco i guest di RHEL 6 racchiudono sia High Availability (core clustering) che il Resilient Storage Add-Ons (GFS2, clvmd e cmirror).