Con Geo Clustering è possibile unificare più siti, geograficamente distanti, in un unico cluster locale. Il failover tra tali cluster viene coordinato da un'entità di livello superiore: il manager richiesta del cluster di booth. Questo documento guida l'utente attraverso la configurazione di base di un Geo cluster, mediante gli script di bootstrap Geo forniti dal pacchetto ha-cluster-bootstrap
.
I Geo cluster basati su SUSE® Linux Enterprise High Availability Extension possono essere considerati cluster «overlay» dove ogni sito del cluster corrisponde a un nodo del cluster in un cluster tradizionale. Il cluster overlay è gestito dal manager richiesta del cluster di booth (di seguito denominato booth). Ciascuna delle parti coinvolte in cluster Geo esegue un servizio boothd
che si collega ai daemon di booth in esecuzione negli altri siti e scambia le informazioni di connettività. Per rendere le risorse del cluster altamente disponibili tra i siti, booth si affida agli oggetti cluster denominati richieste. Una richiesta concede il diritto di eseguire determinate risorse su un sito specifico del cluster. Booth garantisce che a ogni richiesta non sia concessa più di un sito alla volta.
Se la comunicazione tra due istanze di booth si interrompe, il motivo può essere un'interruzione di rete tra i siti del cluster o a causa della mancanza di un sito del cluster. In questo caso, occorre un'istanza aggiuntiva (un terzo sito del cluster o un arbitro
) per ottenere consenso sulle decisioni (ad esempio un failover di risorse tra i siti). Gli arbitri sono singoli computer (esterni ai cluster) che eseguono un'istanza di booth in una modalità speciale. Ciascun cluster Geo può avere uno o più arbitri.
Per maggiori dettagli sul concetto, sulla gestione di componenti e ticket utilizzati per i cluster Geo, vedere Chapter 2, Conceptual Overview.
Di seguito, verrà configurato un cluster Geo di base con due siti cluster e un arbitro:
Si suppone che i siti del cluster siano denominati amsterdam
e berlin
.
Si suppone che ciascun sito consista di due nodi. I nodi alice
e bob
appartengono al cluster amsterdam
. I nodi charlie
e doro
appartengono al cluster berlin
.
Il sito amsterdam
ottiene il seguente indirizzo IP virtuale: 192.168.201.100
.
Il sito berlin
ottiene il seguente indirizzo IP virtuale: 192.168.202.100
.
Si suppone che l'arbitro abbia il seguente indirizzo IP: 192.168.203.100
.
Prima di continuare, verificare che siano rispettati i seguenti requisiti:
Sono presenti almeno due cluster esistenti che si desidera combinare in un cluster Geo. (Se occorre configurare prima due cluster, seguire le istruzioni nella Guida rapida di installazione e configurazione (in lingua inglese).
Per ciascun cluster è definito un nome significativo in /etc/corosync/corosync.conf
che ne riflette l'ubicazione.
È stato installato un terzo computer che non fa parte di alcun cluster esistente ed è utilizzato come arbitro.
Per i requisiti dettagliati su ciascun elemento, vedere anche Sezione 3, «Requisiti».
In tutti i computer (nodi cluster e arbitri) che faranno parte del cluster Geo sarà installato il seguente software:
SUSE® Linux Enterprise Server 12 SP5
SUSE Linux Enterprise High Availability Extension 12 SP5
Geo Clustering for SUSE Linux Enterprise High Availability Extension 12 SP5
Gli IP virtuali da utilizzare per ciascun sito del cluster devono essere accessibili sul cluster Geo.
I siti devono essere raggiungibili su una porta UDP e TCP per istanza di booth. Questo significa che firewall o tunnel IPsec compresi devono essere configurati di conseguenza.
Altre decisioni di configurazione possono richiedere di aprire più porte (ad esempio, per replica database o DRBD).
Tutti i nodi del cluster su tutti i siti devono sincronizzarsi con un server NTP esterno al cluster. Per altre informazioni, vedere https://documentation.suse.com/sles-12/html/SLES-all/cha-netz-xntp.html.
Se i nodi non sono sincronizzati, file di log e rapporti del cluster risultano molto difficili da analizzare.
Utilizzare un numero dispari di membri nel cluster Geo. In caso di interruzione della connessione di rete, ciò garantisce che ci sia sempre una maggioranza di siti (per evitare uno scenario split-brain). Se è presente un numero pari di siti del cluster, utilizzare un arbitro.
Il cluster in ciascun sito ha un nome significativo, ad esempio: amsterdam
e berlin
.
I nomi del cluster per tale sito vengono definiti nei rispettivi file /etc/corosync/corosync.conf
.
totem { [...] cluster_name: amsterdam }
Ciò può essere eseguito manualmente (modificando /etc/corosync/corosync.conf
) o con il modulo cluster YaST (passando alla categoria e definendo un ). In seguito, arrestare e avviare il servizio pacemaker
per applicare le modifiche:
root #
systemctl
stop pacemakerroot #
systemctl
start pacemaker
Con ha-cluster-geo-init
, convertire un cluster nel primo sito di un cluster Geo. Lo script preleva alcuni parametri come i nomi dei cluster, l'arbitro e una o più richieste e crea /etc/booth/booth.conf
da loro. Copia la configurazione di booth in tutti i nodi sul sito del cluster corrente. Configura inoltre le risorse del cluster necessarie per il booth sul sito del cluster corrente.
Per informazioni, vedere Sezione 6, «Impostazione del primo sito di un cluster Geo».
Con ha-cluster-geo-join
, aggiungere il cluster corrente a un cluster Geo esistente. Lo script copia la configurazione di booth da un sito del cluster esistente e la scrive in /etc/booth/booth.conf
su tutti i nodi sul sito del cluster corrente. Configura inoltre le risorse del cluster necessarie per il booth sul sito del cluster corrente.
Per informazioni, vedere Sezione 7, «Aggiunta di un altro sito a un cluster Geo».
Con ha-cluster-geo-init-arbitrator
, convertire il computer corrente in un arbitro per il cluster Geo. Lo script copia la configurazione di booth da un sito del cluster esistente e la scrive in /etc/booth/booth.conf
.
Per informazioni, vedere Sezione 8, «Aggiunta dell'arbitro».
Tutti gli script di bootstrap effettuano l'accesso a /var/log/ha-cluster-bootstrap.log
. Consultare il file di registro per eventuali dettagli sul processo di bootstrap. Ogni opzione impostata durante il processo di bootstrap è modificabile in seguito (modificando le impostazioni di booth, le risorse e così via). Per i dettagli vedere il Geo Clustering Guide.
È disponibile un supporto come estensione separata su distanze illimitate per l'utilizzo dei cluster High Availability; tale supporto è denominato Geo Clustering for SUSE Linux Enterprise High Availability Extension.
Per configurare un cluster Geo sono necessari i pacchetti inclusi nei seguenti modelli di installazione:
High Availability
Geo Clustering for SUSE Linux Enterprise High Availability Extension
Entrambi i modelli sono disponibili solo se il sistema è stato registrato presso SUSE Customer Center (o in un server di registrazione locale) e sono stati aggiunti i rispettivi canali di prodotto o supporti di installazione come estensione. Per informazioni su come installare le estensioni, vedere SUSE Linux Enterprise 12 SP5 Deployment Guide (in lingua inglese): https://documentation.suse.com/sles-12/html/SLES-all/cha-add-ons.html.
Per installare i pacchetti da entrambi i modelli tramite riga di comando, utilizzare Zypper:
root #
zypper
install -t pattern ha_sles ha_geo
In alternativa, utilizzare YaST per un'installazione grafica:
Avviare YaST come utente root
e selezionare › .
Fare clic su
› e attivare i seguenti modelli:
High Availability
Geo Clustering for SUSE Linux Enterprise High Availability Extension
Fare clic su
per avviare l'installazione dei pacchetti.I pacchetti software necessari SUSE Linux Enterprise High Availability Extension e Geo Clustering for SUSE Linux Enterprise High Availability Extension non vengono copiati automaticamente nei nodi del cluster.
Installare SUSE Linux Enterprise Server 12 SP5 e i modelli High Availability
e Geo Clustering for High Availability
su tutti i computer che faranno parte del cluster Geo.
Invece di installare manualmente i pacchetti su tutti i computer che faranno parte del cluster, utilizzare AutoYaST per clonare i nodi esistenti. Per ulteriori informazioni, vedere Section 3.2, “Mass Installation and Deployment with AutoYaST”.
Tuttavia, l'estensione del cluster Geo deve essere installata manualmente su tutti i computer che faranno parte del cluster Geo. Il supporto di AutoYaST per Geo Clustering for SUSE Linux Enterprise High Availability Extension non è ancora disponibile.
Utilizzare lo script ha-cluster-geo-init
per convertire un cluster esistente nel primo sito di un cluster Geo.
amsterdam
) con ha-cluster-geo-init
#
Definire un IP virtuale per sito del cluster utilizzabile per accedere al sito. Si suppone di utilizzare 192.168.201.100
e 192.168.202.100
per questo scopo. Non è ancora necessario configurare gli IP virtuali come risorse del cluster. Ciò verrà eseguito dagli script bootstrap.
Definire il nome di almeno una richiesta che concederà il diritto di eseguire determinate risorse su un sito del cluster. Utilizzare un nome significativo che rifletta le risorse che dipenderanno dalla richiesta (ad esempio, ticket-nfs
). Gli script bootstrap richiedono solo il nome della richiesta, è possibile definire i dettagli rimanenti (dipendenze della richiesta delle risorse) in seguito, come descritto nella Sezione 10, «Fasi successive».
Eseguire il login a un nodo di un cluster esistente (ad esempio, al nodo alice
del cluster amsterdam
).
Eseguire ha-cluster-geo-init
. Ad esempio, utilizzare le opzioni seguenti:
root #
ha-cluster-geo-init
\ --clusters1 "amsterdam=192.168.201.100 berlin=192.168.202.100" \ --tickets2 ticket-nfs \ --arbitrator3 192.168.203.100
I nomi dei siti del cluster (come definito in | |
Il nome di una o più richieste. | |
Il nome host o l'indirizzo IP di un computer all'esterno dei cluster. |
Lo script bootstrap crea il file di configurazione del booth e lo sincronizza tra i siti del cluster. Crea inoltre le risorse di base del cluster necessarie per il booth. Il Passo 4 della Procedura 2 determinano le seguenti risorse del cluster e configurazione di booth:
ha-cluster-geo-init
## The booth configuration file is "/etc/booth/booth.conf". You need to # prepare the same booth configuration file on each arbitrator and # each node in the cluster sites where the booth daemon can be launched. # "transport" means which transport layer booth daemon will use. # Currently only "UDP" is supported. transport="UDP" port="9929" arbitrator="192.168.203.100" site="192.168.201.100" site="192.168.202.100" authfile="/etc/booth/authkey" ticket="ticket-nfs" expire="600"
ha-cluster-geo-init
#primitive1 booth-ip IPaddr2 \ params rule #cluster-name eq amsterdam ip=192.168.201.100 \ params rule #cluster-name eq berlin ip=192.168.202.100 \ primitive2 booth-site ocf:pacemaker:booth-site \ meta resource-stickiness=INFINITY \ params config=booth \ op monitor interval=10s group3 g-booth booth-ip booth-site \ meta target-role=Stopped4
Un indirizzo IP virtuale per ogni sito del cluster. È richiesto dai daemon del booth per cui è necessario un indirizzo IP persistente sul sito di ciascun cluster. | |
Una risorsa primitiva per il daemon del booth. Comunica con i daemon del booth sugli altri siti del cluster. Il daemon può essere avviato su qualsiasi nodo del sito, ma per far rimanere la risorsa sullo stesso nodo, se possibile, la rigidità della risorsa è impostata su | |
Un gruppo di risorse del cluster per entrambe le primitive. Con questa configurazione, ciascun daemon di booth sarà disponibile ai propri indirizzi IP, indipendente dal nodo su cui il daemon è in esecuzione. | |
Il gruppo risorse del cluster non viene avviato per impostazione predefinita. Dopo aver verificato la configurazione delle risorse del cluster (e aggiunto le risorse necessarie per completare la configurazione), occorre avviare il gruppo di risorse. Per ulteriori informazioni, vedere Passaggi richiesti per completare la configurazione del cluster Geo. |
Dopo aver inizializzato il primo sito del cluster Geo, aggiungere il secondo cluster con ha-cluster-geo-join
, come descritto nella Procedura 3. Lo script richiede accesso SSH a un sito del cluster già configurato e aggiunge il cluster corrente al cluster Geo.
berlin
) con ha-cluster-geo-join
#
Eseguire il login a un nodo del sito del cluster che si desidera aggiungere (ad esempio, sul nodo charlie
del cluster berlin
).
Eseguire il comando ha-cluster-geo-join
. Ad esempio:
root #
ha-cluster-geo-join
\ --cluster-node1 192.168.201.100\ --clusters2 "amsterdam=192.168.201.100 berlin=192.168.202.100"
Specifica da dove copiare la configurazione del booth. Utilizzare l'indirizzo IP o il nome host di un nodo in un sito del cluster Geo già configurato. È inoltre possibile utilizzare l'indirizzo IP virtuale di un sito del cluster già esistente (come in questo esempio). In alternativa, utilizzare l'indirizzo IP o il nome host di un arbitro già configurato per il cluster Geo. | |
I nomi dei siti del cluster (come definito in |
Lo script ha-cluster-geo-join
copia la configurazione del booth da 1, vedere Esempio 1. Inoltre, crea le risorse del cluster necessarie per il booth (vedere Esempio 2).
Dopo aver configurato tutti i siti del cluster Geo con ha-cluster-geo-init
e ha-cluster-geo-join
, configurare l'arbitro con ha-cluster-geo-init-arbitrator
.
ha-cluster-geo-init-arbitrator
#Eseguire il login al computer da utilizzare come arbitro.
Eseguire il comando seguente. Ad esempio:
root #
ha-cluster-geo-init-arbitrator
--cluster-node1 192.168.201.100
Specifica da dove copiare la configurazione del booth. Utilizzare l'indirizzo IP o il nome host di un nodo in un sito del cluster Geo già configurato. In alternativa, è inoltre possibile utilizzare l'indirizzo IP virtuale di un sito del cluster già esistente (come in questo esempio). |
Lo script ha-cluster-geo-init-arbitrator
copia la configurazione del booth da 1, vedere Esempio 1. Attiva e avvia, inoltre, il servizio di booth sull'arbitro. L'arbitro è così pronto per comunicare con le istanze di booth sui siti del cluster non appena i servizi di booth vi vengono eseguiti.
Per visualizzare entrambi i siti del cluster con le risorse e la richiesta create durante il processo di bootstrap, utilizzare Hawk2. L'interfaccia Web Hawk2 consente di controllare e gestire più cluster e cluster Geo (non in relazione).
Tutti i cluster monitorati dal SUSE Linux Enterprise High Availability Extension 12 SP5.
di Hawk2 devono eseguireSe non è stato sostituito il certificato autofirmato per Hawk2 su ogni nodo del cluster con il proprio certificato (o con un certificato firmato da una Autorità di certificazione ufficiale), eseguire almeno una volta il login ad Hawk2 sul nodo every nel cluster every. Verificare il certificato (o aggiungere un'eccezione nel browser per ignorare l'avviso). In alternativa, Hawk2 non può collegarsi al cluster.
Avviare un browser Web e immettere l'IP virtuale del primo sito del cluster, amsterdam
:
https://192.168.201.100:7630/
In alternativa, utilizzare l'indirizzo IP o il nome host di alice
o bob
. Se sono stati configurati entrambi i nodi con gli script di bootstrap, il servizio hawk
dovrebbe essere in esecuzione su entrambi i nodi.
Eseguire il login all'interfaccia Web Hawk2.
Dalla barra di navigazione sinistra, selezionare
.Hawk2 mostra una panoramica di risorse e nodi sul sito del cluster corrente. Inoltre, mostra eventuali
configurate per il cluster Geo. Se occorrono informazioni sulle icone utilizzate in questa vista, fare clic su .amsterdam
) #Per aggiungere un dashboard per il secondo sito del cluster, fare clic su
.
Immettere il berlin
.
Immettere il nome host completamente qualificato di uno dei nodi del cluster (in questo caso, charlie
o doro
).
Fare clic su
. Hawk2 mostra una seconda scheda per il nuovo sito del cluster aggiunto con una panoramica dei relativi nodi e risorse.Per visualizzare maggiori informazioni per un sito del cluster o gestirlo, passare alla scheda del sito e fare clic sull'icona della catena.
Hawk2 apre la vista
di tale sito in una nuova scheda o finestra del browser, da cui è possibile amministrare questa parte del cluster Geo.Gli script di bootstrap del cluster Geo forniscono un modo rapido di impostare un cluster Geo di base utilizzabile per scopi di test. Tuttavia, per spostare il cluster Geo risultante in un cluster Geo funzionante utilizzabile negli ambienti di produzione, sono richiesti altri passaggi, vedere Passaggi richiesti per completare la configurazione del cluster Geo.
Dopo il processo di bootstrap, il servizio di booth dell'arbitro non può ancora comunicare con i servizi di booth sui siti del cluster, in quanto non vengono avviati per impostazione predefinita.
Il servizio di booth per ciascun sito del cluster viene gestito dal gruppo risorse di booth g-booth
(vedere Esempio 2, «Risorse del cluster create da ha-cluster-geo-init
»). Per avviare un'istanza del servizio booth per sito, avviare il rispettivo gruppo risorse di booth in ciascun sito del cluster. Ciò consente a tutte le istanze di booth di comunicare tra loro.
Affinché le risorse dipendano dalla richiesta creata durante il processo di bootstrap del cluster Geo, configurare i vincoli. Per ogni vincolo, impostare una policy di perdita
che definisca ciò che deve succedere alle rispettive risorse se la richiesta viene revocata da un sito del cluster.
Per informazioni, vedere Chapter 6, Configuring Cluster Resources and Constraints.
Prima che booth sia in grado di gestire una determinata richiesta nel Geo cluster, occorre inizialmente concederla manualmente a un sito. È possibile utilizzare lo strumento della riga di comando del client di booth o Hawk2 per concedere una richiesta.
Per informazioni, vedere Chapter 8, Managing Geo Clusters.
Gli script di bootstrap creano le stesse risorse di booth sui siti di entrambi i cluster e gli stessi file di configurazione di booth in tutti i siti, compreso l'arbitro. Se si estende la configurazione del cluster Geo (per passare a un ambiente di produzione), si perfezionerà probabilmente la configurazione di booth e modificherà la configurazione delle risorse del cluster correlate al booth. In seguito, è necessario sincronizzare le modifiche agli altri siti del cluster Geo per applicarle.
Per sincronizzare le modifiche nella configurazione del booth con tutti i siti del cluster (compreso l'arbitro), utilizzare Csync2. Per ulteriori informazioni, vedere Chapter 5, Synchronizing Configuration Files Across All Sites and Arbitrators.
Il CIB (Cluster Information Database) non viene sincronizzato automaticamente tra i siti di un Geo cluster. Questo significa che eventuali modifiche alla configurazione della risorsa richieste su tutti i siti del cluster devono essere trasferite manualmente agli altri siti. Per questo, selezionare le rispettive risorse, esportarle dal CIB corrente e importarle nel CIB sugli altri siti del cluster. Per informazioni, vedere Section 6.4, “Transferring the Resource Configuration to Other Cluster Sites”.
Maggiore documentazione per questo prodotto è disponibile su https://documentation.suse.com/sle-ha-12/. La documentazione comprende inoltre una completa Geo Clustering Guide
(in lingua inglese). utile in caso di ulteriori attività di configurazione e amministrazione.
Un documento con informazioni dettagliate sulle operazioni con la replica dei dati tramite DRBD tra i cluster Geo è stato pubblicato nelle serie SUSE Best Practices
(in lingua inglese): https://documentation.suse.com/sbp/all/html/SBP-DRBD/index.html.
Copyright © 2006– 2024 SUSE LLC e collaboratori. Tutti i diritti riservati.
L'autorizzazione per la copia, la distribuzione e/o la modifica di questo documento è soggetta ai termini indicati nella licenza GFDL (GNU Free Documentation License), versione 1.2 oppure, a scelta, 1.3, di cui la presente licenza e le presenti informazioni sul copyright rappresentano la sezione non variabile. Una copia della licenza versione 1.2 è inclusa nella sezione intitolata «GNU Free Documentation License».
Per i marchi di fabbrica SUSE vedere http://www.suse.com/company/legal/. Tutti gli altri marchi di fabbrica di terze parti sono proprietà dei rispettivi titolari. I simboli di marchio di fabbrica (®, ™ e così via) indicano i marchi di fabbrica appartenenti a SUSE e alle rispettive affiliate. Gli asterischi (*) indicano i marchi di fabbrica di terze parti.
Tutte le informazioni nella presente pubblicazione sono state compilate con la massima attenzione ai dettagli. Ciò, tuttavia, non garantisce una precisione assoluta. SUSE LLC, le rispettive affiliate, gli autori e i traduttori non potranno essere ritenuti responsabili di eventuali errori o delle relative conseguenze.