Riferimento rapido per Geo Clustering #

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.

Figura 1: Cluster a due siti: 2x2 nodi + arbitro (opzionale) #

 

È 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 Administration Guide.

Di seguito, verrà configurato un cluster Geo di base con due siti cluster e un arbitro:

Prima di continuare, verificare che siano rispettati i seguenti requisiti:

Per i requisiti dettagliati su ciascun elemento, vedere anche Sezione 3, «Requisiti».

Tutti i computer (nodi cluster e arbitri) che fanno parte del cluster richiedono almeno i seguenti moduli ed estensioni:

Per l'installazione dei computer, selezionare HA GEO Node come ruolo del sistema. Ciò conduce all'installazione di un sistema minimo in cui i pacchetti del modello Geo Clustering for High Availability (ha_geo) sono installati per default.

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 Administration Guide.

Con Geo Clustering for SUSE Linux Enterprise High Availability Extension è disponibile un supporto per l'utilizzo dei cluster High Availability.

Per configurare un cluster Geo sono necessari i pacchetti inclusi nei seguenti modelli di installazione:

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 moduli o supporti di installazione come estensione. Per informazioni su come installare le estensioni, vedere la Deployment Guide for SUSE Linux Enterprise 15 SP3 (Guida alla distribuzione di SUSE Linux Enterprise 15 SP2).

Per installare i pacchetti da entrambi i modelli tramite riga di comando, utilizzare Zypper:

root # zypper install -t pattern ha_sles ha_geo

Importante: installazione dei pacchetti software su tutte le entità

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 15 SP3 e i modelli ha_sles e ha_geo su tutti i computer che faranno parte del Geo cluster.

• 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”.

Utilizzare lo script ha-cluster-geo-init per convertire un cluster esistente nel primo sito di un cluster Geo.

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 1 determina le seguenti risorse del cluster e configurazione di booth:

# 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"

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

Dopo aver inizializzato il primo sito del cluster Geo, aggiungere il secondo cluster con ha-cluster-geo-join, come descritto nella Procedura 2. Lo script richiede accesso SSH a un sito del cluster già configurato e aggiunge il cluster corrente al cluster Geo.

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.

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 quando 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).

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.

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.

Nota: Sincronizzazione delle modifiche tra i siti del cluster

• 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”.

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.