Verifica dei repository HAE su SUSE

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

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

   Salta i passaggi seguenti se l'output include i repository SLE HAE sia per Pool che per Updates. 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, utilizzare yast2 per abilitarli.

   • Software
   • Prodotti complementari
   • Aggiungi
   • Estensioni e moduli dal server di registrazione
     • Yast2 esegue un ciclo su entrambi i repository, Pool e Updates
     • Aggiungi entrambi i repository
   • Chiudi l'applicazione " yast2 "

3. Una volta terminato, riprova a eseguire lo stesso comando su entrambi i nodi.

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

Sono elencati entrambi i registri SLE HAE.

Installazione dei pacchetti software SLE HAE

Utilizza il seguente comando per installare i pacchetti software necessari.

Su entrambi i nodi, eseguire il seguente comando.

zypper install -t pattern ha_sles

Verifica dei requisiti hardware

Consultare i seguenti requisiti hardware per configurare un cluster SLE ad alta disponibilità.

Per i requisiti hardware dettagliati, consultare la documentazione relativa a SUSE Linux Enterprise High Availability nella sezione " Guida rapida all'installazione e alla configurazione".

• Due server virtuali o partizioni logiche da utilizzare come nodi del cluster.
• Un secondo canale di comunicazione di rete o un'interfaccia di rete in modalità bonded per Corosync.
• Un volume condiviso da utilizzare come dispositivo STONITH Block Device (SBD).
• Un timer watchdog hardware per un fencing affidabile dei nodi.

Creazione di volumi di archiviazione condivisi

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

Se si sceglie di utilizzare più dischi, ripetere i passaggi seguenti per ciascun volume, secondo necessità.

1. Accedi alla pagina " Power Virtual Server " - "Storage Volumes ".

2. Fai clic su Create volume.

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

   • Inserisci un nome per il volume.
   • Impostare la dimensione (GB) su 1 (impostazione predefinita).
   • Passa da Condivisibile a ON.
   • Accetta i Termini e le Condizioni spuntando la casella corrispondente.

4. Fare clic su " Crea volume " per completare l'operazione.

   Ora devi 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 allegare a questo nodo il volume condiviso creato in precedenza.

7. Ripetere gli stessi passaggi per il secondo nodo del cluster.

8. Su qualsiasi nodo, eseguire 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 verificare il nome del dispositivo associato al volume condiviso, eseguire il comando seguente.

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

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

   Per semplificare i passaggi successivi, 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 di Power10. Per verificarne la disponibilità, eseguire il seguente comando.

ls /dev/watchdog*

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

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

LD_SHOW_AUXV=1 /bin/true | grep _PLATFORM

Cerca i seguenti campi nell'output.

• AT_BASE_PLATFORM – indica il tipo effettivo di processore.
• 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 una terza LPAR come arbitro. L'arbitratore è una partizione logica che non fa parte del cluster. Ospita il server QNetd come terza istanza per consentire il raggiungimento del quorum del cluster in scenari di “split brain”. Quando il numero dei nodi del cluster è pari, gli arbitri sono fondamentali poiché aggiungono un’istanza al quorum.

Per ulteriori informazioni, consultare la documentazione di SUSE relativa a QDevice e QNetd.

L'arbitratore viene solitamente configurato dopo che il cluster è già in esecuzione. Utilizza l'approccio " crm cluster init qdevice " come descritto nella documentazione " SUSE ".

Configurazione della sincronizzazione dell'ora

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

Configurazione del primo nodo del cluster

Gli script di installazione dell’estensione Enterprise High Availability di SUSE Linux 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 digitare " 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 unico nodo.

Configurazione del secondo nodo del cluster

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

1. Accedi 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, nella sezione “ Node ” dell’output vengono visualizzati entrambi i nodi, 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 hacluster

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

passwd hacluster

Verifica dello stato dell'SBD

Utilizza 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 seguente comando.

sbd -d $SBD_DEVICE list

L'output elenca entrambi i nodi del cluster, ciascuno con lo stato " clean", a indicare che il meccanismo SBD funziona correttamente e che non ci sono azioni di fencing in sospeso.

Configurare l'azione di fencing

Per impostazione predefinita, il nodo sottoposto a fencing viene riavviato automaticamente dopo un evento di fencing.

Tuttavia, un approccio alternativo consiste nello spegnere il nodo e riavviarlo manualmente dopo aver individuato la causa principale del guasto.

L'attivazione manuale del nodo presenta diversi vantaggi.

• In questo modo si evitano inutili cicli di recinzione, che potrebbero verificarsi se il problema alla radice dovesse persistere.
• Garantisce che ogni evento di fencing venga rilevato e gestito, migliorando la stabilità e l’affidabilità del cluster.

Per configurare l'azione di fencing in modo da spegnere il nodo, utilizzare il seguente comando.

sudo crm configure property 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 avviare manualmente un'azione di fencing su uno dei nodi.

1. Esegui il seguente comando per isolare manualmente NODE2.

   crm node fence ${NODE2}
   

2. Digita y e premi Invio per procedere quando viene visualizzato il seguente messaggio, che interromperà l'operazione 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 il nodo si ricongiunga al cluster e testare il fencing dalla direzione opposta.

   Su NODE2, eseguire il seguente comando.

   crm status
   

4. Quando entrambi i nodi risultano come “ Online ” nello stato del cluster, attendere circa un minuto per garantire una maggiore stabilità. Quindi, da NODE2, avvia un’azione di fencing su NODE1 eseguendo il seguente comando, che interromperà NODE1:

   crm node fence ${NODE1}
   

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