Vai al contenutoNaviga tra le pagine: pagina precedente [tasto di scelta p]/pagina successiva [tasto di scelta n]
documentation.suse.com / Documentazione di SUSE Linux Enterprise High Availability / Quick Start Guides / Riferimento rapido per Geo Clustering
SUSE Linux Enterprise High Availability 15 SP6

Riferimento rapido per Geo Clustering

Data di pubblicazione: 17 Settembre 2024

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.

Cluster a due siti: 2x2 nodi + arbitro (opzionale)
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.

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 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:

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 e berlin. 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.

Requisiti di rete
  • 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).

Altri requisiti e raccomandazioni
  • 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 e berlin.

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

Procedura 1: Installazione dei modelli High Availability e Geo Clustering
  1. Installare i modelli High Availability e Geo Clustering dalla riga di comando:

    # zypper install -t pattern ha_sles ha_geo
  2. Installare i modelli High Availability e Geo Clustering su tutte le macchine che faranno parte del cluster.

    Nota
    Nota: Installazione dei pacchetti software su tutti i nodi

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

Procedura 2: Impostazione del primo sito (amsterdam) con crm cluster geo_init
  1. 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 e 192.168.202.100. Non è ancora necessario configurare gli IP virtuali come risorse del cluster. L'operazione viene eseguita dagli script bootstrap.

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

  3. Eseguire il login a un nodo di un cluster esistente (ad esempio, al nodo alice del cluster amsterdam).

  4. 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.1003

    1

    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 e berlin) ciascuno con un indirizzo IP virtuale.

    2

    Il nome di una o più richieste.

    3

    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:

Esempio 1: Configurazione booth creata da 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"
Esempio 2: Risorse cluster create da 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

1

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.

2

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

3

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.

4

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.

Procedura 3: Aggiunta del secondo sito (berlin) con crm cluster geo_join
  1. Eseguire il login a un nodo del sito del cluster che si desidera aggiungere (ad esempio, sul nodo charlie del cluster berlin).

  2. 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"2

    1

    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 esistente (come in questo esempio). In alternativa, utilizzare l'indirizzo IP o il nome host di un arbitro già configurato per il cluster Geo.

    2

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

Procedura 4: Configurazione dell'arbitro con crm cluster geo_init_arbitrator
  1. Eseguire il login al computer da utilizzare come arbitro.

  2. Eseguire il comando seguente. Ad esempio:

    # crm cluster geo_init_arbitrator --cluster-node 192.168.201.1001

    1

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

Prerequisiti
  • Tutti i cluster monitorati dal dashboard 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.

Procedura 5: Utilizzo del dashboard Hawk2
  1. 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.

  2. Eseguire il login all'interfaccia Web Hawk2.

  3. Dalla barra di navigazione sinistra, selezionare Dashboard.

    Hawk2 mostra una panoramica di risorse e nodi sul sito del cluster corrente. Mostra anche eventuali Richieste configurate per il cluster Geo. Se occorrono informazioni sulle icone utilizzate in questa vista, fare clic su Legend.

    Dashboard Hawk2 con un sito del cluster (amsterdam)
    Figura 2: Dashboard Hawk2 con un sito del cluster (amsterdam)
  4. Per aggiungere un dashboard per il secondo sito del cluster, fare clic su Aggiungi cluster.

    1. Immettere il Nome cluster con cui identificare il cluster nel dashboard. In questo caso, berlin.

    2. Immettere il nome host completamente qualificato di uno dei nodi del cluster (in questo caso, charlie o doro).

    3. Fare clic su Aggiungi. Hawk2 mostra una seconda scheda per il sito del cluster appena aggiunto, con una panoramica dei relativi nodi e risorse.

      Dashboard Hawk2 con entrambi i siti del cluster
      Figura 3: Dashboard Hawk2 con entrambi i siti del cluster
  5. 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 Stato 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.

Passaggi richiesti per completare la configurazione del cluster Geo
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 da crm 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.

Nota
Nota: Sincronizzazione delle modifiche tra i siti del cluster

11 Per ulteriori informazioni