Capitolo 2. Prima di configurare Red Hat High Availability Add-On

Il numero massimo di nodi del cluster supportati da High Availability Add-On è 16.

Solo i cluster con un solo sito sono completamente supportati. Non sono supportati invece i cluster che si estendono su posizioni fisiche multiple. Per maggiori informazioni sui cluster con siti multipli contattare un rappresentante per il supporto o alle vendite di Red Hat.

Anche se il file system GFS2 può essere implementato in un sistema standalone o come parte di una configurazione del cluster, Red Hat non supporta l'uso del GFS2 come file system con nodo singolo. Red Hat supporta un numero di file system di nodi singoli ad elevate prestazioni ottimizzati per i singoli nodi e quindi con un overhead più basso rispetto ad un file system del cluster. Red Hat consiglia l'uso dei suddetti file system rispetto al GFS2 nel caso in cui si verifichi la necessità di un montaggio del file system da parte del nodo. Red Hat continuerà a supportare GFS2 come file system con un solo nodo per i propri utenti.

Quando configurate un file system GFS2 come file system del cluster assicuratevi che tutti i nodi presenti in un cluster abbiano accesso allo storage condiviso. Configurazioni asimmetriche nelle quali solo alcuni nodi hanno un accesso allo storage condiviso, non saranno supportate. Ciò non richiederà il montaggio da parte di tutti i nodi del file system GFS2.

I cluster possono includere un array dual-controller RAID, canali di rete multipli collegati, percorsi multipli tra i membri del cluster e lo storage, e sistemi un-interruptible power supply (UPS) ridondanti per assicurare che nessun errore singolo possa causare un arresto dell'applicazione o una perdita di dati.

Alternativamente sarà possibile impostare un cluster low-cost in modo da fornire una disponibilità più bassa rispetto ad un cluster no-single-point-of-failure. Per esempio, è possibile impostare un cluster con un RAID array con controllore singolo ed un solo canale Ethernet.

Alcune alternative low-cost, ad esempio i controllori RAID dell'host, di software RAID senza un supporto cluster e configurazioni SCSI parallele multi-initiator non sono compatibili o appropriate per un loro uso come storage del cluster condiviso.

Per assicurare l'integrità dei dati solo un nodo per volta può eseguire un servizio o accedere ai dati relativi al servizio del cluster. L'uso degli interruttori di alimentazione in una configurazione hardware del cluster permette ad un nodo di eseguire un ciclo di alimentazione di un altro nodo prima di riavviare i servizi HA del nodo in questione durante un processo di failover. Tale operazione impedisce a due nodi di accedere simultaneamente ai dati corrompendoli. È fortemente consigliato l'uso dei dispositivi di fencing (soluzioni hardware o software che eseguono una alimentazione remota, l'arresto ed il riavvio dei nodi del cluster) per garantire una integrità dei dati in tutte le condizioni d'errore.

Il quorum del cluster e lo stato del nodo vengono determinati per mezzo di una comunicazione tra i nodi del cluster tramite Ethernet. In aggiunta i nodi del cluster usano Ethernet per una varietà di altre funzioni critiche del cluster (per esempio il fencing). Con Ethernet channel bonding, le interfacce multiple di Ethernet sono configurate in modo da comportarsi come se fossero una, riducendo il rischio di un single-point-of-failure in una connessione tipica di Ethernet tra i nodi del cluster ed altre sezioni hardware.

Con Red Hat Enterprise Linux 6.4 sono supportate le modalità 0, 1, e 2 per il bonding.

High Availability Add-On supporta i protocolli internet IPv4 e IPv6. Il supporto per IPv6 con l'High Availability Add-On rappresenta una nuova funzione con Red Hat Enterprise Linux 6.