Controllo dei repository SUSE HAE

1. Verificare che i repository di SUSE Linux (R) Enterprise High Availability Extension siano abilitati eseguendo il seguente comando su entrambi i nodi.

   zypper repos --show-enabled-only | grep High
   

   Saltare i passaggi seguenti se l'output include i repository SLE HAE sia per il pool che per gli aggiornamenti. Per esempio

   • SUSE_Linux_Enterprise_High_Availability_Extension_ppc64le:SLE-Product-HA15-SP6-Pool
   • SUSE_Linux_Enterprise_High_Availability_Extension_ppc64le:SLE-Product-HA15-SP6-Updates

2. Se i repository HAE non sono elencati, usare yast2 per abilitarli.

   • Software
   • Prodotti aggiuntivi
   • Aggiungi
   • Estensioni e moduli dal server di registrazione
     • Yast2 esegue un loop su entrambi i repository Pool e Aggiornamenti
     • Aggiungere entrambi i repository
   • Uscire dall'applicazione yast2

3. Al termine, riprovare lo stesso comando su entrambi i nodi.

   zypper repos --show-enabled-only | grep High
   

Entrambi i depositi SLE HAE sono elencati.

Installazione dei pacchetti software SLE HAE

Utilizzare il seguente comando per installare i pacchetti software richiesti.

Su entrambi i nodi, eseguire il seguente comando.

zypper install -t pattern ha_sles

Verifica dei requisiti hardware

Per configurare un cluster SLE ad alta disponibilità, vedere i seguenti requisiti hardware.

Per i requisiti hardware dettagliati, consultare la documentazione di SUSE Linux Enterprise High Availability nella sezione Installazione e configurazione rapida.

• Due server virtuali o partizioni logiche che fungono da nodi del cluster.
• Un secondo canale di comunicazione di rete o un'interfaccia di rete vincolata per Corosync.
• Un volume condiviso da usare come dispositivo STONITH Block Device (SBD).
• Un timer di watchdog hardware per una schermatura affidabile dei nodi.

Creazione di volumi di archiviazione condivisi

Utilizzare l'interfaccia web IBM Cloud PowerVS per creare uno o tre volumi condivisi da utilizzare come dispositivi SBD. SUSE consiglia di creare tre volumi per garantire la ridondanza. Queste informazioni continuano con la creazione di un singolo disco SBD.

Se si sceglie di utilizzare più dischi, ripetere i passaggi seguenti per ogni volume, se necessario.

1. Andate alla pagina Power Virtual Server - Volumi di archiviazione.

2. Fai clic su Create volume.

3. Nel modulo Crea volume di archiviazione, inserire le seguenti informazioni.

   • Inserite un nome per il volume.
   • Impostare la Dimensione (GB) su 1 (valore predefinito).
   • Attiva l' opzione Condivisibile.
   • Accettare i Termini e condizioni selezionando la casella corrispondente.

4. Fare clic su Crea volume per finalizzare.

   Ora è necessario collegare i volumi a entrambi i nodi del cluster.

5. Modificare la partizione logica del primo nodo del cluster.

6. Fare clic su Allega esistente per collegare il volume condiviso creato in precedenza a questo nodo.

7. Ripetere le stesse operazioni per il secondo nodo del cluster.

8. Su qualsiasi nodo, eseguite il seguente comando per identificare i nomi dei dispositivi dei volumi da 1 G.

   multipath -l | grep -B1 'size=1G'
   

   Se l'output del comando multipath -l è:

   36005076813810264e800000000006f10 dm-0 IBM,2145
   size=1G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
   

9. Per confermare il nome del dispositivo associato al volume condiviso, eseguire il seguente comando.

   ls /dev/disk/by-id/wwn-0x6005076813810264e800000000006f10
   

   Il dispositivo SBD deve avere lo stesso nome di dispositivo su tutti i nodi del cluster per garantire il corretto funzionamento del cluster.

   Per semplificare le operazioni future, esportare il percorso del dispositivo SBD come variabile d'ambiente da utilizzare durante l'inizializzazione del cluster.

   export SBD_DEVICE=/dev/disk/by-id/wwn-0x6005076813810264e800000000006f10
   

Configurazione del watchdog hardware

Il timer di watchdog hardware è abilitato per impostazione predefinita sulle partizioni logiche Power10. Per verificarne la disponibilità, eseguire il seguente comando.

ls /dev/watchdog*

L'output elenca due dispositivi: /dev/watchdog e /dev/watchdog0.

Se non è elencato alcun dispositivo watchdog, eseguire il seguente comando per verificare che la modalità di compatibilità del processore sia impostata su Power10.

LD_SHOW_AUXV=1 /bin/true | grep _PLATFORM

Cercate i seguenti campi nell'output.

• AT_BASE_PLATFORM - indica il tipo di processore effettivo.
• AT_PLATFORM - indica la modalità di compatibilità del processore.

La modalità di compatibilità del processore deve essere impostata su Power10. Se è impostato su una versione precedente, il watchdog dell'hypervisor non è disponibile.

Arbitro

Per un cluster a due nodi, si consiglia di utilizzare un terzo LPAR come arbitro. L'arbitro è una partizione logica che non fa parte del cluster. Ospita il server QNetd come terza istanza per supportare la ricerca del quorum del cluster in scenari di split brain. Con un numero pari di nodi del cluster, gli arbitri sono essenziali perché aggiungono un'istanza al quorum.

Per ulteriori informazioni, consultare la documentazione SUSE su QDevice e QNetd.

L'arbitro viene in genere impostato dopo che il cluster è in funzione. Utilizzare l'approccio crm cluster init qdevice come descritto nella documentazione SUSE.

Configurazione della sincronizzazione temporale

Entrambi i nodi del cluster richiedono la sincronizzazione temporale per garantire il corretto funzionamento. Quando le partizioni logiche vengono eseguite su PowerVS,, la sincronizzazione temporale viene gestita automaticamente attraverso il sito Hardware Management Console (HMC). In questa configurazione, il demone chrony non è necessario.

Configurazione del primo nodo del cluster

Gli script di installazione di SUSE Linux Enterprise High Availability Extension configurano automaticamente molti componenti chiave dell'ambiente cluster.

sudo crm cluster init --name "$CLUSTERNAME" --sbd-device "$SBD_DEVICE"

Premere Invio per accettare i valori predefiniti, oppure immettere y e premere Invio quando richiesto.

INFO: Loading "default" profile from /etc/crm/profiles.yml
WARNING: chronyd.service is not configured to start at system boot.
Do you want to continue anyway (y/n)? y
INFO: The user 'hacluster' will have the login shell configuration changed to /bin/bash
Continue (y/n)? y
INFO: A new ssh keypair is generated for user hacluster.
INFO: Configuring csync2
INFO: Starting csync2.socket service on ths-3
INFO: BEGIN csync2 checking files
INFO: END csync2 checking files
INFO: Configure Corosync (unicast):
  This will configure the cluster messaging layer.  You will need
  to specify a network address over which to communicate (default
  is eth0's network, but you can use the network address of any
  active interface).

Address for ring0 [10.51.0.84]
Port for ring0 [5405]
INFO: Initializing SBD
INFO: Hawk cluster interface is now running. To see cluster status, open:
INFO:   https://10.51.0.84:7630/
INFO: Log in with username 'hacluster', password 'linux'
WARNING: You should change the hacluster password to something more secure!
INFO: Starting pacemaker.service on ths-3
INFO: BEGIN Waiting for cluster
...........                                                                     INFO: END Waiting for cluster
INFO: Loading initial cluster configuration
WARNING: "stonith-enabled" in crm_config is set to true, it was false
INFO: Configure Administration IP Address:
  Optionally configure an administration virtual IP
  address. The purpose of this IP address is to
  provide a single IP that can be used to interact
  with the cluster, rather than using the IP address
  of any specific cluster node.

Do you wish to configure a virtual IP address (y/n)? y
Virtual IP []10.51.0.12
INFO: BEGIN Configuring virtual IP (10.51.0.12)
.                                                                               INFO: END Configuring virtual IP (10.51.0.12)
INFO: Configure Qdevice/Qnetd:
  QDevice participates in quorum decisions. With the assistance of
  a third-party arbitrator Qnetd, it provides votes so that a cluster
  is able to sustain more node failures than standard quorum rules
  allow. It is recommended for clusters with an even number of nodes
  and highly recommended for 2 node clusters.

Do you want to configure QDevice (y/n)? n
INFO: Done (log saved to /var/log/crmsh/crmsh.log on ths-3)

Il cluster è ora attivo e funzionante con un singolo nodo.

Configurazione del secondo nodo del cluster

Utilizzare le seguenti informazioni per configurare il secondo nodo del cluster.

1. Accedere al secondo nodo del cluster.

2. Per integrare il nodo nel cluster esistente, utilizzare il comando ha-cluster-join. Questo comando richiede un account utente e il nome host del primo nodo del cluster.

   sudo crm cluster join -u root -c $NODE1
   

3. Premere Invio per accettare i valori predefiniti, oppure digitare y e premere Invio quando richiesto.

   WARNING: chronyd.service is not configured to start at system boot.
   Do you want to continue anyway (y/n)? y
   INFO: The user 'hacluster' will have the login shell configuration changed to /bin/bash
   Continue (y/n)? y
   INFO: A new ssh keypair is generated for user hacluster.
   INFO: Configuring csync2
   INFO: Starting csync2.socket service
   INFO: BEGIN csync2 syncing files in cluster
   INFO: END csync2 syncing files in cluster
   INFO: Merging known_hosts
   Warning: Permanently added 'ths-4' (ED25519) to the list of known hosts.
   INFO: BEGIN Probing for new partitions
   INFO: END Probing for new partitions
   Address for ring0 [10.51.0.230]
   INFO: Got SBD configuration
   INFO: Hawk cluster interface is now running. To see cluster status, open:
   INFO:   https://10.51.0.230:7630/
   INFO: Log in with username 'hacluster', password 'linux'
   WARNING: You should change the hacluster password to something more secure!
   INFO: Starting pacemaker.service on ths-4
   INFO: BEGIN Waiting for cluster
   ..                                                                              INFO: END Waiting for cluster
   INFO: BEGIN Adjusting sbd related timeout values
   WARNING: "stonith-timeout" in crm_config is set to 83, it was 43
   INFO: END Adjusting sbd related timeout values
   INFO: Set property "priority" in rsc_defaults to 1
   WARNING: "priority-fencing-delay" in crm_config is set to 60, it was 0
   INFO: BEGIN Reloading cluster configuration
   INFO: END Reloading cluster configuration
   INFO: Done (log saved to /var/log/crmsh/crmsh.log on ths-4)
   

4. Per verificare che il cluster SLE sia in esecuzione, eseguire il seguente comando.

   sudo crm status
   

   Se non si sono verificati errori, la sezione Node List dell'output mostra entrambi i nodi e sono elencati come Online.

   Node List:
     * Online: [ ths-3 ths-4 ]
   

   La sezione Risorse elenca due risorse che si trovano nello stato Avviato, il che indica che sono attive e funzionano correttamente.

   Full List of Resources:
     * stonith-sbd	(stonith:external/sbd):	 Started ths-3
     * admin-ip	(ocf::heartbeat:IPaddr2):	 Started ths-3
   

Impostazione di una password per l'ID utente di hacluster

Su entrambi i nodi, eseguire il seguente comando per impostare la password dell'account utente di hacluster.

passwd hacluster

Controllo dello stato dell'SBD

Utilizzare le seguenti informazioni per verificare che la variabile SBD_DEVICE sia impostata.

Per verificare lo stato degli slot SBD da uno dei nodi del cluster, eseguire il comando seguente.

sbd -d $SBD_DEVICE list

L'output elenca entrambi i nodi del cluster, ciascuno con uno stato di clean, che indica che il meccanismo SBD funziona correttamente e che non ci sono azioni di scherma in corso.

Configurare l'azione di scherma

Per impostazione predefinita, il nodo recintato viene riavviato automaticamente dopo un evento di recinzione.

Tuttavia, un approccio alternativo è quello di spegnere il nodo e avviarlo manualmente dopo aver indagato sulla causa principale del guasto.

L'attivazione manuale del nodo presenta diversi vantaggi.

• In questo modo si evitano inutili cicli di recinzione, che possono verificarsi se il problema alla radice persiste.
• Assicura che ogni evento di scherma venga notato e affrontato, migliorando la stabilità e l'affidabilità del cluster.

Per configurare l'azione di scherma per spegnere il nodo, usare il comando seguente.

sudo crm configure set cib-bootstrap-options.stonith-action off

Verificare la configurazione attuale del cluster con il seguente comando.

sudo crm configure show

Verifica delle operazioni di recinzione

Per testare la configurazione di STONITH, è necessario attivare manualmente un'azione di scherma su uno dei nodi.

1. Eseguire il seguente comando per recintare manualmente NODE2.

   crm node fence ${NODE2}
   

2. Immettere y e premere Invio per procedere quando viene richiesto il seguente messaggio, che si interromperà NODE2:

   Fencing ths-4 will shut down the node and migrate any resources that are running on it! Do you want to fence ths-4  (y/n)? y
   

3. Attivare NODE2, attendere che si ricongiunga al cluster e testare la schermatura dalla direzione opposta.

   Su NODE2, eseguite il seguente comando.

   crm status
   

4. Quando entrambi i nodi appaiono come Online nello stato del cluster, attendere circa un minuto per garantire la stabilità. Quindi, da NODE2, avviate un'azione di scherma su NODE1 eseguendo il seguente comando che fermerà NODE1:

   crm node fence ${NODE1}
   

5. Attivare NODE1, quindi avviare i servizi del cluster sul nodo.