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 Extension / Quick Start Guides / Riferimento rapido per Geo Clustering
di SUSE Linux Enterprise High Availability Extension 15 SP3

Riferimento rapido per Geo Clustering

SUSE Linux Enterprise High Availability Extension 15 SP3

Data di pubblicazione: July 25, 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 dal pacchetto ha-cluster-bootstrap.

Autori: Tanja Roth e Thomas Schraitle

1 Panoramica concettuale

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.

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

2 Scenario di utilizzo

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:

Requisiti
Due cluster esistenti

Sono presenti almeno due cluster esistenti che si desidera combinare in un cluster Geo. (Se occorre configurare prima due cluster, seguire le istruzioni nella Riferimento rapido per l'installazione e la configurazione (in lingua inglese).

Nomi di cluster significativi

Per ciascun cluster è definito un nome significativo in /etc/corosync/corosync.conf che ne riflette l'ubicazione.

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

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

  • Basesystem Module 15 SP3

  • Server Applications Module 15 SP3

  • SUSE Linux Enterprise High Availability Extension 15 SP3

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.

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 di aprire 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 l' Administration Guide for SUSE Linux Enterprise Server 15 SP3 (Guida all'amministrazione di SUSE Linux Enterprise Server 15 SP2).

    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 dei ticket. 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 tale sito vengono definiti nei rispettivi file /etc/corosync/corosync.conf.

    totem {
        [...]
        cluster_name: amsterdam
        }

    Modificare il nome con il seguente comando crmsh:

    root # crm cluster rename NEW_NAME

    Interrompere e avviare il servizio pacemaker per applicare le modifiche:

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

5 Installazione

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:

  • High Availability (denominato sles_ha sulla riga di comando)

  • Geo Clustering for High Availability (denominato ha_geo sulla riga di comando)

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

6 Impostazione del primo sito di un cluster Geo

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

Procedura 1: Impostazione del primo sito (amsterdam) con ha-cluster-geo-init
  1. 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.

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

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

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

    1

    I nomi dei siti del cluster (come definito 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 1 determina le seguenti risorse del cluster e configurazione di booth:

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

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 sarà disponibile ai propri indirizzi 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 ulteriori 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 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.

Procedura 2: Aggiunta del secondo sito (berlin) con ha-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 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"

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

    2

    I nomi dei siti del cluster (come definito 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.

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

8 Aggiunta dell'arbitro

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.

Procedura 3: Configurazione dell'arbitro con ha-cluster-geo-init-arbitrator
  1. Eseguire il login al computer da utilizzare come arbitro.

  2. Eseguire il comando seguente. Ad esempio:

    root # ha-cluster-geo-init-arbitrator --cluster-node1 192.168.201.100

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

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 Hawk3 devono eseguire SUSE Linux Enterprise High Availability Extension 15 SP2.

  • 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 4: 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. Inoltre, mostra 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 nuovo sito del cluster 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 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.

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

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

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

12 Note legali

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.