SUSE Linux Enterprise High Availability Extension 15 SP5

Riferimento rapido per l'installazione e la configurazione #

Data di pubblicazione: 11 Dicembre 2023

Questo documento guida l'utente attraverso la procedura di configurazione di un modello base di cluster a due nodi mediante gli script di bootstrap forniti dallo shell CRM. È prevista la configurazione di un indirizzo IP virtuale come risorsa cluster e l'uso di SBD nello storage condiviso come meccanismo di isolamento dei nodi.

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 i marchi di fabbrica di terze parti appartengono ai rispettivi proprietari. I simboli dei marchi di fabbrica (®, ™, ecc.) indicano i marchi di fabbrica 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 Scenario di utilizzo #

Le procedure descritte in questo documento prevedono una configurazione minima di un cluster a due nodi con le seguenti proprietà:

Due nodi: alice (IP: 192.168.1.1) e bob (IP: 192.168.1.2), connessi l'uno all'altro tramite rete.
Un indirizzo IP virtuale mobile (192.168.1.10) che consente ai client di connettersi al servizio indipendentemente dal nodo sul quale è in esecuzione. Questo indirizzo IP viene utilizzato per connettersi allo strumento di gestione grafica Hawk2.
Un dispositivo di storage condiviso, utilizzato come meccanismo di isolamento SBD. Per evitare questi scenari split-brain.
Failover di risorse da un nodo all'altro in caso di mancato funzionamento dell'host attivo (configurazione attiva/passiva).

È possibile utilizzare il cluster a due nodi a scopo di prova o come configurazione minima del cluster con la possibilità di estenderla in un secondo momento. Prima di utilizzare il cluster in un ambiente di produzione, vedere il Administration Guide (Guida all'amministrazione) per modificarlo secondo i propri requisiti.

2 Requisiti di sistema #

In questa sezione vengono descritti i requisiti di sistema fondamentali per lo scenario descritto nella Sezione 1. Per regolare il cluster per l'uso in un ambiente di produzione, fare riferimento all'elenco completo nel Chapter 2, System requirements and recommendations.

2.1 Requisiti hardware #

Server

Due server con software secondo quanto specificato nella Sezione 2.2, «Requisiti software».

I server possono essere bare metal o macchine virtuali. Non sono necessari gli stessi requisiti hardware (memoria, spazio su disco e così via), ma devono avere la stessa architettura. I cluster multipiattaforma non sono supportati.

Canali di comunicazione

Almeno due moduli di comunicazione TCP/IP per nodo cluster. Le apparecchiature di rete devono supportare i mezzi di comunicazione che si desidera utilizzare per la comunicazione cluster: multicast o unicast. I moduli di comunicazione devono supportare una velocità dati di 100 Mbit/s o superiore. Per la configurazione di un cluster supportato, sono necessari almeno due percorsi di comunicazione ridondanti. La configurazione può essere eseguita tramite:

Associazione dei dispositivi di rete (preferita).
Un secondo canale di comunicazione in Corosync.

Isolamento dei nodi/STONITH

Un dispositivo di isolamento dei nodi (STONITH) per evitare scenari split-brain. Ciò può essere un dispositivo fisico (un interruttore di alimentazione) o un meccanismo come SBD (STONITH by disk) abbinato a un watchdog. È possibile utilizzare SBD con lo storage condiviso o in modalità senza disco. Questo documento descrive l'uso di SBD con lo storage condiviso. Devono essere soddisfatti i seguenti requisiti:

Un dispositivo di storage condiviso. Per informazioni sulla configurazione dello storage condiviso, vedere Storage Administration Guide for SUSE Linux Enterprise Server (Guida all'amministrazione dello storage di SUSE Linux Enterprise Server). Se ai fini dei test è necessario solo lo storage condiviso di base, vedere Appendice A, Storage iSCSI di base per SBD.
Il percorso al dispositivo di storage condiviso deve essere persistente e coerente attraverso tutti i nodi nel cluster. Utilizzare nomi di dispositivi stabili come /dev/disk/by-id/dm-uuid-part1-mpath-abcedf12345.
Il dispositivo SBD non deve utilizzare RAID basati su host, LVM2, né risiedere su un'istanza DRBD*.

Per ulteriori informazioni su STONITH, vedere Chapter 12, Fencing and STONITH. Per ulteriori informazioni su SBD, vedere Chapter 13, Storage protection and SBD.

2.2 Requisiti software #

Tutti i nodi che fanno parte del cluster richiedono almeno i seguenti moduli ed estensioni:

Basesystem Module 15 SP5
Server Applications Module 15 SP5
SUSE Linux Enterprise High Availability Extension 15 SP5

2.3 Altri requisiti e raccomandazioni #

Sincronizzazione dell'orario

I nodi del cluster devono sincronizzarsi a un server NTP al di fuori del cluster. A partire da SUSE Linux Enterprise High Availability Extension 15, chrony è l'implementazione di default di NTP. Per ulteriori informazioni, vedere Administration Guide for SUSE Linux Enterprise Server 15 SP5.

Se i nodi non sono sincronizzati, il cluster potrebbe non funzionare correttamente. Inoltre, i file di registro e i report dei cluster sono particolarmente difficili da analizzare in assenza di sincronizzazione. Se si utilizzano gli script di bootstrap, l'utente verrà avvisato nel caso in cui l'NTP non fosse ancora stato configurato.

Nome host e indirizzo IP

Utilizzare indirizzi IP statici.
È supportato solo l'indirizzo IP primario.
Elencare tutti i nodi del cluster nel file /etc/hosts con il relativo nome host completo e breve. È fondamentale che i membri del cluster possano cercarsi per nome. Se i nomi non sono disponibili, non sarà possibile garantire la comunicazione interna al cluster.

SSH

Tutti nodi del cluster devono essere in grado di accedere agli altri tramite SSH. Strumenti quali crm report (per la risoluzione dei problemi) e History Explorer di Hawk2 richiedono l'accesso SSH senza password tra i nodi, altrimenti possono solo raccogliere dati dal nodo corrente.

Se per configurare il cluster si utilizzano gli script di bootstrap, le chiavi SSH verranno create e copiate automaticamente.

3 Panoramica degli script di bootstrap #

I comandi seguenti eseguono script di bootstrap che richiedono tempi e interventi manuali ridotti al minimo.

Con crm cluster init, è possibile definire i parametri fondamentali necessari per la comunicazione del cluster. In questo modo all'utente rimane un cluster a un nodo in esecuzione.
Con crm cluster join, è possibile aggiungere più nodi al proprio cluster.
Con crm cluster remove, è possibile rimuovere nodi dal proprio cluster.

Tutti gli script di bootstrap effettuano l'accesso a /var/log/crmsh/crmsh.log. Consultare questo file per eventuali dettagli sul processo di bootstrap. Tutte le opzioni impostate durante il processo di bootstrap possono essere modificate in un secondo momento con il modulo cluster YaST. Per informazioni, vedere Chapter 4, Using the YaST cluster module.

Lo script di bootstrap crm cluster init controlla e configura i seguenti componenti:

NTP

Verificare se NTP è stato configurato per essere avviato al momento del riavvio. In caso contrario, viene visualizzato un messaggio.

SSH

Crea chiavi SSH per il login senza password tra nodi del cluster.

Csync2

Configura Csync2 per replicare file di configurazione attraverso tutti i nodi in un cluster.

Corosync

Configura il sistema di comunicazione del cluster.

SBD/watchdog

Verifica che sia presente un watchdog e chiede all'utente se configurare SBD come meccanismo di isolamento dei nodi.

IP virtuale mobile

Chiede all'utente se configurare un indirizzo IP virtuale per l'amministrazione del cluster con Hawk2.

Firewall

Apre nel firewall le porte necessarie per la comunicazione del cluster.

Nome del cluster

Definisce un nome per il cluster, per impostazione predefinita hacluster. Facoltativo e utile per i cluster Geo. Di solito, il nome del cluster riflette l'ubicazione e semplifica la distinzione di un sito all'interno di un cluster Geo.

QDevice/QNetd

Chiede se configurare QDevice/QNetd per partecipare alle decisioni sul quorum. Si consiglia di utilizzare QDevice e QNetd per i cluster con un numero pari di nodi, specialmente per i cluster a due nodi.

Questa configurazione non viene trattata qui, ma è possibile impostarla successivamente, come descritto in Chapter 14, QDevice and QNetd.

4 Installazione dei pacchetti High Availability #

I pacchetti per configurare e gestire un cluster sono inclusi nel modello di installazione di High Availability. Questo modello è disponibile solo dopo l'avvenuta installazione di SUSE Linux Enterprise High Availability Extension.

È possibile effettuare la registrazione in SUSE Customer Center e installare High Availability Extension durante o dopo l'installazione di SUSE Linux Enterprise Server. Per ulteriori informazioni, vedere Deployment Guide (Guida alla distribuzione) per SUSE Linux Enterprise Server.

Procedura 1: Installazione del modello High Availability #

Installare il modello di High Availability dalla riga di comando:
```
# zypper install -t pattern ha_sles
```
Installare il pattern Alta disponibilità su tutte le macchine che faranno parte del cluster.
Nota: Installazione dei pacchetti software su tutti i nodi
Per un'installazione automatizzata di SUSE Linux Enterprise Server 15 SP5 e High Availability Extension, utilizzare AutoYaST per clonare i nodi esistenti. Per ulteriori informazioni, vedere il Section 3.2, “Mass installation and deployment with AutoYaST”.

5 Utilizzo di SBD per l'isolamento dei nodi #

Prima di poter configurare SBD con lo script di bootstrap, è necessario abilitare un watchdog su ogni nodo. SUSE Linux Enterprise Server è dotato di diversi moduli kernel che forniscono driver watchdog specifici per l'hardware. High Availability Extension utilizza il daemon SBD come componente software che «alimenta» il watchdog.

La procedura descritta di seguito utilizza il watchdog softdog.

Importante: limitazioni Softdog

Il driver softdog suppone che almeno una CPU sia ancora in esecuzione. Se tutte le CPU sono bloccate, il codice nel driver softdog che dovrebbe riavviare il sistema non viene mai eseguito. Al contrario, i watchdog hardware continuano a funzionare anche se tutte le CPU sono bloccate.

Prima di utilizzare il cluster in un ambiente di produzione, si consiglia di sostituire il modulo softdog con il rispettivo modulo hardware più adatto all'hardware in uso.

Tuttavia, se nessun watchdog corrisponde all'hardware in uso, è possibile utilizzare softdog come modulo watchdog del kernel.

Procedura 2: Abilitazione della sorveglianza Softdog per SBD #

Abilitare su ciascun nodo il watchdog softdog:

# echo softdog > /etc/modules-load.d/watchdog.conf
# systemctl restart systemd-modules-load

Controllare che il modulo softdog sia caricato correttamente:
```
# lsmod | grep dog
softdog           16384  1
```

6 Configurazione del primo nodo #

Configurare il primo nodo con lo script crm cluster init. Il tempo e l'intervento manuale necessari sono ridotti al minimo.

Procedura 3: Impostazione del primo nodo (alice) con crm cluster init #

Eseguire il login nel primo del nodo cluster come root o come utente con privilegi sudo.
Importante: chiave di accesso SSH utente sudo
Il cluster utilizza l'accesso SSH senza password per la comunicazione tra i nodi. Lo script crm cluster init verifica la presenza di chiavi SSH e le genera qualora non esistessero già.
Se si intende configurare il primo nodo come utente con privilegi sudo, è necessario assicurarsi che le chiavi SSH esistano già (o verranno generate) localmente sul nodo e non in un sistema remoto.
Avviare lo script di bootstrap:
```
# crm cluster init --name CLUSTERNAME
```
Sostituire il segnaposto CLUSTERNAME con un nome significativo, come la posizione geografica del cluster (ad esempio, amsterdam). Questo risulta particolarmente utile per creare in seguito un cluster Geo, in quanto semplifica l'identificazione di un sito.
Se per la comunicazione cluster occorre utilizzare un multicast invece di unicast (predefinito), utilizzare l'opzione --multicast (o -U).
Lo script verifica la configurazione NTP e un servizio di watchdog hardware. Se richiesto, genera le chiavi SSH pubbliche e private utilizzate per l'accesso SSH e la sincronizzazione Csync2 e avvia i rispettivi servizi.
Configurare il livello di comunicazione del cluster (Corosync):
1. Immettere un indirizzo di rete al quale collegarlo. Per impostazione predefinita, lo script propone l'indirizzo di rete di eth0. In alternativa, immettere un altro indirizzo di rete, ad esempio l'indirizzo di bond0.
2. Accettare la porta suggerita (5405) o immetterne un'altra.
Configurare SBD come meccanismo di isolamento dei nodi:
1. Confermare con y che si desidera utilizzare SBD.
2. Immettere un percorso persistente nella partizione del proprio dispositivo di blocco che si desidera utilizzare per SBD. Il percorso deve essere coerente attraverso tutti i nodi nel cluster.
  Lo script create una piccola partizione sul dispositivo da utilizzare per SBD.
Configurare un indirizzo IP virtuale per l'amministrazione del cluster con Hawk2:
1. Confermare con y che si desidera configurare un indirizzo IP virtuale.
2. Immettere un indirizzo IP inutilizzato da utilizzare come IP di amministrazione per Hawk2: 192.168.1.10
  Anziché accedere a un singolo nodo del cluster con Hawk2, è possibile connettersi all'indirizzo IP virtuale.
Scegliere se configurare QDevice e QNetd. Per la configurazione minima descritta in questo documento, per il momento declinare con n. È possibile configurare QDevice e QNetd in un momento successivo, come descritto nel Chapter 14, QDevice and QNetd.

Infine, lo script avvierà i servizi del cluster per portare il cluster online e abilitare Hawk2. L'URL da utilizzare per Hawk2 viene visualizzato sullo schermo.

A questo punto è in esecuzione un cluster a un nodo. Per visualizzarne lo stato, attenersi alla seguente procedura:

Procedura 4: Accesso all'interfaccia Web di Hawk2 #

Su un computer, avviare un browser Web e assicurarsi che JavaScript e i cookie siano abilitati.
Per l'URL, immettere l'indirizzo IP virtuale configurato con lo script di bootstrap:
```
https://192.168.1.10:7630/
```
Nota: Avviso certificato
Se quando si tenta di accedere all'URL per la prima volta, viene visualizzato un avviso certificato significa che è in uso un certificato firmato da se stessi. I certificati firmati da se stessi non sono considerati attendibili per default.
Chiedere i dettagli del certificato all'operatore del cluster per verificare il certificato.
Per continuare ignorando l'avviso, è possibile aggiungere un'eccezione nel browser.
Nella schermata di login di Hawk2, immettere il nome utente e la password dell'utente che è stato creato durante lo script di bootstrap (utente hacluster, password linux).
Importante: Password di protezione
Sostituire la password di default con una di protezione non appena possibile:
```
# passwd hacluster
```
Fare clic su Login. Per impostazione predefinita, l'interfaccia Web di Hawk2 mostra la schermata Stato:
Figura 1: Stato del cluster a un nodo in Hawk2 #

7 Aggiunta del secondo nodo #

Aggiungere un secondo nodo al cluster con lo script di bootstrap crm cluster join. Lo script deve accedere solo a un nodo del cluster esistente e completa automaticamente la configurazione di base nella macchina corrente.

Per ulteriori informazioni, vedere la pagina man crm cluster join.

Procedura 5: Aggiunta del secondo nodo (bob) con crm cluster join #

Eseguire il login nel secondo nodo come root o come utente con privilegi sudo.
Avviare lo script di bootstrap:
Se si configura il primo nodo come root, è possibile eseguire questo comando senza alcun parametro aggiuntivo:
```
# crm cluster join
```
Se si configura il primo nodo come utente sudo, è necessario specificare tale utente con l'opzione -c:
```
> sudo crm cluster join -c USER@alice
```
Se NTP non è configurato per essere avviato al momento del riavvio, viene visualizzato un messaggio. Lo script verifica anche la presenza di un dispositivo watchdog hardware. Se non è presente alcun dispositivo l'utente viene avvisato.
Se non è già stato specificato alice con -c, verrà richiesto l'indirizzo IP del primo nodo.
Se non è già stato configurato un accesso SSH senza password tra entrambe le macchine, verrà richiesta la password del primo nodo.
Dopo il login a un nodo specificato, lo script copia la configurazione Corosync, configura SSH e Csync2, porta online la macchina corrente come nuovo nodo del cluster e avvia il servizio necessario per Hawk2.

Controllare lo stato del cluster in Hawk2. In Stato › Nodi si dovrebbero vedere due nodi con uno stato di colore verde:

Figura 2: Stato del cluster a due nodi #

8 Test del cluster #

I seguenti test possono essere utili per identificare eventuali problemi con la configurazione del cluster. Tuttavia, un test realistico prevede casi d'uso e scenari specifici. Prima di utilizzare il cluster in un ambiente di produzione, testarlo in modo approfondito secondo i propri casi di utilizzo.

Il comando sbd -d DEVICE_NAME list elenca tutti i nodi visibili a SBD. Per la configurazione descritta in questo documento, l'output deve mostrare sia alice che bob.
Sezione 8.1, «Test del failover delle risorse» è un semplice test per verificare se il cluster sposta l'indirizzo IP virtuale nell'altro nodo se il nodo sul quale è attualmente in esecuzione la risorsa è impostato su standby.
Sezione 8.2, «Esecuzione del test con il comando crm cluster crash_test» simula gli errori del cluster e segnala i risultati.

8.1 Test del failover delle risorse #

La procedura seguente è un test rapido per la verifica del failover delle risorse:

Procedura 6: Test del failover delle risorse #

Aprire un terminale ed effettuare il ping del proprio indirizzo IP virtuale, 192.168.1.10:
```
# ping 192.168.1.10
```
Accedere a Hawk2.
In Stato › Risorse, verificare su quale nodo è in esecuzione l'indirizzo IP virtuale (risorsa admin_addr). Questa procedura presuppone che la risorsa sia in esecuzione su alice.
Impostare alice in modalità Standby:
Figura 3: Nodo alice in modalità standby #
Fare clic su Stato › Risorse. La risorsa admin_addr è stata migrata in bob.

Durante la migrazione, si dovrebbe vedere un flusso ininterrotto di ping verso l'indirizzo IP virtuale indicante che la configurazione del cluster e l'indirizzo IP mobile funzionano correttamente. Annullare il comando ping con Ctrl– C.

8.2 Esecuzione del test con il comando `crm cluster crash_test` #

Il comando crm cluster crash_test attiva gli errori del cluster per trovare i problemi. Prima di utilizzare il cluster nell'ambiente di produzione, si consiglia di utilizzare questo comando per assicurarsi che tutto funzioni come previsto.

Il comando supporta i controlli seguenti:

--split-brain-iptables: Simula uno scenario split-brain tramite il blocco della porta Corosync. Consente di controllare se è possibile applicare una recinzione a un nodo come previsto.
--kill-sbd/--kill-corosync/ --kill-pacemakerd: Termina i daemon per SBD, Corosync e Pacemaker. Dopo l'esecuzione di uno di questi test, è possibile trovare un report nella directory /var/lib/crmsh/crash_test/. Il report include una descrizione del caso del test e una spiegazione dei possibili risultati.
--fence-node NODE: Consente di applicare una recinzione a un nodo specifico trasmesso dalla riga di comando.

Per ulteriori informazioni, vedere la crm cluster crash_test --help.

Esempio 1: Test del cluster: isolamento dei nodi #

# crm_mon -1
Stack: corosync
Current DC: alice (version ...) - partition with quorum
Last updated: Fri Mar 03 14:40:21 2020
Last change: Fri Mar 03 14:35:07 2020 by root via cibadmin on alice

2 nodes configured
1 resource configured

Online: [ alice bob ]
Active resources:

 stonith-sbd    (stonith:external/sbd): Started alice

# crm cluster crash_test --fence-node bob

==============================================
Testcase:          Fence node bob
Fence action:      reboot
Fence timeout:     60

!!! WARNING WARNING WARNING !!!
THIS CASE MAY LEAD TO NODE BE FENCED.
TYPE Yes TO CONTINUE, OTHER INPUTS WILL CANCEL THIS CASE [Yes/No](No): Yes
INFO: Trying to fence node "bob"
INFO: Waiting 60s for node "bob" reboot...
INFO: Node "bob" will be fenced by "alice"!
INFO: Node "bob" was successfully fenced by "alice"

Per osservare lo stato di modifica di bob durante il test, accedere a Hawk2 e selezionare Stato › Nodi.

9 Fasi successive #

Gli script di bootstrap forniscono un modo rapido per configurare un cluster High Availability di base utilizzabile per i test. Tuttavia, per espandere questo cluster in uno High Availability funzionante utilizzabile negli ambienti di produzione, sono richiesti altri passaggi.

Passaggi consigliati per completare la configurazione del cluster High Availability #

Aggiunta di altri nodi

Aggiungere altri nodi al cluster utilizzando uno dei seguenti metodi:

Per i nodi individuali, utilizzare lo script crm cluster join come descritto in Sezione 7, «Aggiunta del secondo nodo».
Per l'installazione di massa di più nodi, utilizzare AutoYaST come descritto nel Section 3.2, “Mass installation and deployment with AutoYaST”.

Di norma, un cluster può contenere fino a 32 nodi. Con il servizio pacemaker_remote, è possibile estendere i cluster High Availability in modo da includere altri nodi oltre questo limite. Per ulteriori dettagli, vedere la Pacemaker Remote Quick Start.

Configurazione di QDevice

Se il cluster ha un numero pari di nodi, configurare QDevice e QNetd per partecipare alle decisioni sul quorum. QDevice fornisce un numero configurabile di voti, consentendo a un cluster di sostenere più errori dei nodi rispetto a quelli consentiti dalle regole del quorum standard. Per informazioni, vedere Chapter 14, QDevice and QNetd.

Abilitazione di un watchdog hardware

Prima di utilizzare il cluster in un ambiente di produzione, sostituire il modulo softdog con il rispettivo modulo hardware più adatto all'hardware in uso. Per informazioni, vedere Section 13.6, “Setting up the watchdog”.

10 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 Administration Guide (Guida al Geo Clustering) completa.