Riferimento rapido per Geo Clustering #
Geo clustering consente di proteggere i carichi di lavoro tra i data center distribuiti globalmente. Questo documento guida l'utente attraverso la configurazione di base di un Geo cluster, mediante gli script di bootstrap Geo forniti dallo shell CRM.
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 https://www.suse.com/company/legal/. Tutti i marchi di fabbrica di terze parti appartengono ai rispettivi proprietari. I simboli dei marchi di fabbrica (®, ™, ecc.) indicano marchi commerciali di SUSE e delle sue affiliate. Gli asterischi (*) indicano i marchi di fabbrica di terze parti.
Tutte le informazioni presenti 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.
1 Panoramica concettuale #
I Geo cluster basati su SUSE® Linux Enterprise High Availability 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 arbitrator
) 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.
È anche possibile eseguire un cluster Geo a due siti senza un arbitro. In questo caso, è necessario che un amministratore del cluster Geo gestisca manualmente i ticket. Se un ticket deve essere concesso a più di un sito contemporaneamente, in entrambi i siti viene visualizzato un avviso.
Per maggiori dettagli sul concetto, sulla gestione di componenti e ticket utilizzati per i cluster Geo, vedere il Administration Guide.
2 Scenario di utilizzo #
Le procedure descritte in questo documento prevedono un cluster Geo di base con due siti del cluster e un arbitro:
Si suppone che i siti del cluster siano denominati
amsterdam
eberlin
.Si suppone che ciascun sito consista di due nodi. I nodi
alice
ebob
appartengono al clusteramsterdam
. I nodicharlie
edoro
appartengono al clusterberlin
.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:
- Due cluster esistenti
Sono presenti almeno due cluster che si intende combinare in un cluster Geo (se è necessario configurare preliminarmente i due cluster, seguire le istruzioni fornite nell'Riferimento rapido per l'installazione e la configurazione).
- Nomi di cluster significativi
Ogni cluster ha un nome significativo che riflette la sua ubicazione, ad esempio:
amsterdam
eberlin
. I nomi dei cluster sono definiti in/etc/corosync/corosync.conf
.- Arbitro
È 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».
3 Requisiti #
Tutte le macchine (nodi del cluster e arbitri) dispongono almeno dei seguenti moduli ed estensioni:
Basesystem Module 15 SP6
Server Applications Module 15 SP6
SUSE Linux Enterprise High Availability 15 SP6
Quando si installano le macchine, selezionare HA GEO Node
come system role
. Ciò conduce all'installazione di un sistema minimo in cui i pacchetti del modello Geo Clustering
for High Availability (ha_geo)
vengono installati per impostazione predefinita.
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 l'apertura di 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 ulteriori informazioni, vedere Administration Guide for SUSE Linux Enterprise Server 15 SP6.
Se i nodi non sono sincronizzati, file di log e rapporti del cluster risultano molto difficili da analizzare.
Utilizzare un numero dispari di siti 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). Qualora fosse presente un numero dispari di siti cluster, utilizzare un arbitro per gestire il failover automatico delle richieste. Se non si utilizza un arbitro, è necessario gestire manualmente il failover dei ticket.
Il cluster in ciascun sito ha un nome significativo, ad esempio:
amsterdam
eberlin
.I nomi del cluster per ciascun sito vengono definiti nei rispettivi file
/etc/corosync/corosync.conf
:totem { [...] cluster_name: amsterdam }
Modificare il nome con il seguente comando crmsh:
#
crm cluster rename NEW_NAME
Arrestare e avviare i servizi del cluster per rendere effettive le modifiche:
#
crm cluster restart
Le architetture miste in un unico cluster non sono supportate. Per i Geo cluster, tuttavia, ciascun membro del Geo cluster può presentare un'architettura diversa, sia esso un sito cluster o un arbitratore. Ad esempio, è possibile eseguire un Geo cluster con tre membri (due siti cluster e un arbitratore), dove un sito cluster viene eseguito su IBM Z, l'altro viene eseguito su x86 e l'arbitratore su POWER.
4 Panoramica degli script di bootstrap Geo #
Con
crm cluster geo_init
, convertire un cluster nel primo sito di un cluster Geo. Lo script preleva i parametri come i nomi dei cluster, l'arbitro e una o più richieste e li usa per creare/etc/booth/booth.conf
. 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
crm 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
crm 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/crmsh/crmsh.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 informazioni, vedere Administration Guide.
5 Installazione dei pacchetti High Availability e Geo Clustering #
I pacchetti per la configurazione e la gestione di un cluster Geo sono inclusi nei modelli di installazione High Availability
e Geo Clustering for High Availability
. Tali modelli sono disponibili solo dopo l'avvenuta installazione di SUSE Linux Enterprise High Availability.
Durante o dopo l'installazione di SUSE Linux Enterprise Server, è possibile registrarsi presso SUSE Customer Center e installare SUSE Linux Enterprise High Availability. Per ulteriori informazioni, vedere Deployment Guide for SUSE Linux Enterprise Server (Guida alla distribuzione di SUSE Linux Enterprise Server).
Installare i modelli High Availability e Geo Clustering dalla riga di comando:
#
zypper install -t pattern ha_sles ha_geo
Installare i modelli High Availability e Geo Clustering su tutte le macchine che faranno parte del cluster.
Nota: Installazione dei pacchetti software su tutti i nodiPer un'installazione automatizzata di SUSE Linux Enterprise Server 15 SP6 e SUSE Linux Enterprise High Availability 15 SP6, utilizzare AutoYaST per clonare i nodi esistenti. Per ulteriori informazioni, vedere il Section 3.2, “Mass installation and deployment with AutoYaST”.
6 Impostazione del primo sito di un cluster Geo #
Utilizzare il comando crm cluster geo_init
per convertire un cluster esistente nel primo sito di un Geo-cluster.
amsterdam
) con crm cluster geo_init
#Definire un IP virtuale per sito del cluster utilizzabile per accedere al sito. A tale scopo, si ipotizza l'utilizzo di
192.168.201.100
e192.168.202.100
. Non è ancora necessario configurare gli IP virtuali come risorse del cluster. L'operazione viene eseguita dagli script bootstrap.Definire il nome di almeno una richiesta che concede il diritto di eseguire determinate risorse su un sito del cluster. Utilizzare un nome significativo che rifletta le risorse che dipendono 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 clusteramsterdam
).Esegui
crm cluster geo_init
. Ad esempio, utilizzare le opzioni seguenti:#
crm cluster geo_init \ --clusters "amsterdam=192.168.201.100 berlin=192.168.202.100" \
1--tickets ticket-nfs \
2--arbitrator 192.168.203.100
3I nomi dei siti del cluster (definiti in
/etc/corosync/corosync.conf
) e gli indirizzi IP virtuali da utilizzare per ogni sito del cluster. In questo caso, sono presenti due siti del cluster (amsterdam
eberlin
) ciascuno con un indirizzo IP virtuale.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:
crm 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"
crm 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. Per assicurare la persistenza della risorsa sullo stesso nodo, se possibile, resource-stickiness è impostato su | |
Un gruppo di risorse del cluster per entrambe le primitive. Con questa configurazione, ciascun daemon di booth è disponibile al proprio indirizzo 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 informazioni, vedere Passaggi richiesti per completare la configurazione del cluster Geo. |
7 Aggiunta di un altro sito a un cluster Geo #
Dopo aver inizializzato il primo sito del cluster Geo, aggiungere il secondo cluster con crm 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 crm cluster geo_join
#Eseguire il login a un nodo del sito del cluster che si desidera aggiungere (ad esempio, sul nodo
charlie
del clusterberlin
).Eseguire il comando
crm cluster geo_join
. Ad esempio:#
crm cluster geo_join \ --cluster-node 192.168.201.100\
1--clusters "amsterdam=192.168.201.100 berlin=192.168.202.100"
2Specifica 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 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 (definiti in
/etc/corosync/corosync.conf
) e gli indirizzi IP virtuali da utilizzare per ogni sito del cluster. In questo caso, sono presenti due siti del cluster (amsterdam
eberlin
) ciascuno con un indirizzo IP virtuale.
Il comando crm cluster geo_join
copia la configurazione booth da 1, vedere la sezione Esempio 1. Inoltre, crea le risorse del cluster necessarie per il booth (vedere Esempio 2).
8 Aggiunta dell'arbitro #
Dopo aver configurato tutti i siti del tuo cluster Geo con crm cluster geo_init
e crm cluster geo_join
, configurare l'arbitro con crm cluster geo_init_arbitrator
.
crm cluster geo_init_arbitrator
#Eseguire il login al computer da utilizzare come arbitro.
Eseguire il comando seguente. Ad esempio:
#
crm cluster geo_init_arbitrator --cluster-node 192.168.201.100
1Specifica 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 crm 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 quando i servizi di booth vi vengono eseguiti.
9 Monitoraggio dei siti del cluster #
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
di Hawk2 devono eseguire SUSE Linux Enterprise High Availability 15 SP6.Se 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
obob
. Se sono stati configurati entrambi i nodi con gli script di bootstrap, il serviziohawk
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. Mostra anche eventuali
configurate per il cluster Geo. Se occorrono informazioni sulle icone utilizzate in questa vista, fare clic su .Figura 2: Dashboard Hawk2 con un sito del cluster (amsterdam
) #Per aggiungere un dashboard per il secondo sito del cluster, fare clic su
.Immettere il
con cui identificare il cluster nel . In questo caso,berlin
.Immettere il nome host completamente qualificato di uno dei nodi del cluster (in questo caso,
charlie
odoro
).Fare clic su
. Hawk2 mostra una seconda scheda per il sito del cluster appena aggiunto, con una panoramica dei relativi nodi e risorse.Figura 3: Dashboard Hawk2 con entrambi i siti del cluster #
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.
10 Fasi successive #
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 Geo-cluster risultante in uno funzionante utilizzabile negli ambienti di produzione, sono richiesti altri passaggi.
- Avvio dei servizi booth sui siti del cluster
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 cluster create dacrm 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.- Configurazione delle dipendenze della richiesta e ordinamento dei vincoli
Affinché le risorse dipendano dalla richiesta creata durante il processo di bootstrap del cluster Geo, configurare i vincoli. Per ogni vincolo, impostare una
loss-policy
che definisca ciò che deve succedere alle rispettive risorse se la richiesta viene revocata da un sito del cluster.Per informazioni, vedere Capitolo 6, Configuring cluster resources and constraints.
- Concessione iniziale di una richiesta a un sito
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 Capitolo 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 si 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 Capitolo 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 Sezione 6.4, «Transferring the resource configuration to other cluster sites».
11 Per ulteriori informazioni #
Maggiore documentazione per questo prodotto è disponibile su https://documentation.suse.com/sle-ha/. Per altre attività di configurazione e amministrazione, vedere la Geo Clustering Guide completa.
Le informazioni sulla replica dei dati sui Geo-cluster tramite DRBD sono disponibili nel documento seguente SUSE Best Practices document.