Capitolo 3. RGManager
RGManager è in grado di gestire e fornire le capacità di failover per la raccolta delle risorse del cluster, ad esempio servizi, gruppi di risorse o alberi di risorse. I gruppi di risorse presentano una struttura ad albero, ed hanno dipendenze genitore-figlio e rapporti di successione all'interno di ogni albero secondario.
RGManager permette agli amministratori di definire, configurare e monitorare i servizi del cluster. In pesenza di un failover di un nodo, RGManager riposizionerà il servizio clusterizzato su un altro nodo cercando di interrompere il meno possibile il servizio. È possibile altresì limitare i servizi su determinati nodi, come ad esempio limitare
httpd ad un gruppo di nodi, mentre mysql può essere limitato ad un insieme separato di nodi.
Sono disponibili vari processi e agent per il funzionamento di RGManager. A tal proposito di seguito viene riportato un elenco.
- Domini di failover - Funzionamento del sistema del dominio di failover RGManager
- Politiche del servizio - Politiche per il ripristino e avvio del servizio di Rgmanager
- Alberi delle risorse - Funzionamento degli alberi delle risorse di rgmanager, inclusa la successione e gli ordini di avvio/arresto
- Comportamenti operativi del servizio - Significati dei vari stati e funzionamento operativo di rgmanager
- Comportamenti macchine virtuali - Comportamenti da considerare durante l'esecuzione delle VM in un cluster rgmanager
- ResourceActions - Le azioni usate da RGManager e la personalizzazione del file
cluster.conf. - Event Scripting - Se le politiche di ripristino e di failover di rgmanager non sono idonee per l'ambiente, sarà possibile eseguire una personalizzazione usando un sottosistema di script.
3.1. Domini di failover
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.
- nodo o membro preferito: Il nodo preferito era il membro indicato per l'esecuzione di un servizio se il membro era offline. È possibile emulare questo comportamento specificando un dominio di failover non ordinato e non limitato di un membro.
- domini limitati: I servizi assegnati al dominio possono essere eseguiti solo sui membri del cluster appartenenti al dominio di failover. Se non è disponibile alcun membro del dominio di failover, il servizio verrà impostato con uno stato "stopped". In un cluster con diversi membri l'uso di un dominio di failover limitato potrà facilitare la configurazioni di un servizio (come ad esempio httpd), il quale necessita di una configurazione identica su tutti i membri che eseguono il servizio. Invece di impostare l'intero cluster per l'esecuzione del servizio, impostare solo i membri nel dominio di failover limitato da associare con il servizio del cluster.
- domini non limitati: Comportamento predefinito, i servizi assegnati a questo dominio possono essere eseguiti su tutti i membri del cluster. Essi possono anche essere eseguiti su un membro del dominio se disponibile. Ciò significa che se un servizio è in esecuzione esternamente al dominio, e un membro del dominio risulta essere online, il servizio eseguirà una migrazione su quel membro a meno che non sia stata impostata l'opzione nofailback.
- dominio ordinato: L'ordine specificato nella configurazione indica l'ordine delle preferenze dei membri all'interno di un dominio. Il membro con la posizione più alta del dominio eseguirà il servizio ogni qualvolta risulta essere online. Ciò significa che se il membro A ha una posizione più alta rispetto al membro B, il servizio eseguirà una migrazione sul membro A, (se in esecuzione sul membro B), solo se il membro A è passato da uno stato offline a uno online.
- dominio non ordinato: Comportamento predefinito, i membri del dominio non presentano alcun ordine di preferenze; qualsiasi membro è in grado di eseguire il servizio. I servizi eseguiranno sempre una migrazione sui membri del dominio di failover quando possibile, tuttavia, in un dominio non ordinato.
- failback: I servizi dei membri di un dominio di failover ordinato devono ritornare sul nodo responsbile per la loro esecuzione iniziale prima del suo fallimento, questa operazione è utile per nodi che falliscono frequentemente. Questa operazione impedisce una interruzione frequente del servizio tra il nodo fallito e quello di failover.
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.
3.1.1. Esempi di comportamento
Cluster composto da un insieme di membri: {A, B, C, D, E, F, G}.
- Dominio di failover limitato, ordinato {A, B, C}
- Con nofailback non impostato: Il servizio 'S' verrà sempre eseguito sul membro 'A' ogni qualvolta il membro 'A' risulta essere online e in presenza di quorum. Se tutti i membri di {A, B, C} risultano essere offline, il servizio non verrà eseguito. Se il servizio è in esecuzione su 'C', e 'A' passa ad uno stato online, il servizio verrà migrato su 'A'.Con nofailback impostato: Il servizio 'S' verrà eseguito sul membro del cluster con la priorità più alta dopo aver formato un quorum. Se tutti i membri di {A, B, C} risultano essere offline, il servizio non verrà eseguito. Se il servizio è in esecuzione su 'C', e 'A' passa ad uno stato online, il servizio resterà su 'C' se 'C' non fallisce, in caso di fallimento verrà eseguito il failover sul membro 'A'.
- Dominio di failover limitato non ordinato {A, B, C}
- Il servizio 'S' verrà eseguito solo in presenza di un quorum e con almeno un membro {A, B, C} online. Se un altro membro del dominio passa online, il servizio non verrà riposizionato.
- Dominio di failover non limitato, ordinato {A, B, C}
- Con nofailback non impostato: Un servizio 'S' verrà eseguito ogni qualvolta è presente un quorum. Se un membro del dominio di failover è online, il servizio verrà eseguito sul membro con la priorità più alta, in caso contrario un membro del cluster verrà selezionato randomicamente per l'esecuzione del servizio. Per riassumere, il servizio verrà eseguito su 'A' ogni qualvolta 'A' è online, seguito da 'B'.Con nofailback impostato: Un servizio 'S' verrà eseguito ogni qualvolta è presente un quorum. Se un membro del dominio di failover è online durante la formazione del quorum, il servizio verrà eseguito sul membro con la priorità più alta del dominio di failover. E quindi se 'B' è online ('A' offline), il servizio verrà eseguito su 'B'. Se in un secondo momento 'A' si unisce al cluster, il servizio non verrà migrato su 'A'.
- Dominio di failover non limitato e non ordinato {A, B, C}
- Chiamato anche come "Insieme di membri preferiti". Quando uno o più membri del dominio di failover risultano online, il servizio verrà eseguito su un membro online non specifico del dominio di failover. Se un altro membro del dominio di failover passa ad uno stato online, il servizio non verrà migrato.
