Riferimento rapido per Geo Clustering #

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.

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

Le procedure descritte in questo documento prevedono un cluster Geo di base con due siti del 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».

Tutte le macchine (nodi del cluster e arbitri) dispongono almeno dei seguenti moduli ed estensioni:

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.

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.

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

Utilizzare il comando crm cluster geo_init per convertire un cluster esistente nel primo sito di un Geo-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:

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

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

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.

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.

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 Geo-cluster risultante in uno funzionante utilizzabile negli ambienti di produzione, sono richiesti altri passaggi.

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 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».