Manutenzione e Risoluzione dei Problemi

Manutenzione e Risoluzione dei Problemi#

Avvisi#

Abbonamento richiesto

Questa funzionalità è disponibile solo se il firewall dispone di un abbonamento valido.

Il cluster HA fornisce monitoraggio e notifiche automatiche per aiutare gli amministratori a rispondere rapidamente a eventi di failover o problemi di sincronizzazione.

I seguenti avvisi sono disponibili:

  • ha:sync:failed: Attivato quando la sincronizzazione della configurazione tra nodo primario e secondario non riesce. Questo di solito indica che il nodo secondario non è raggiungibile a causa di problemi di rete, guasto hardware o interruzione del servizio.

  • ha:primary:failed: Attivato durante eventi di failover quando il nodo primario diventa non disponibile.

Manutenzione#

Il cluster HA è progettato per essere altamente disponibile e richiede una manutenzione minima. Tuttavia, ci sono situazioni in cui potrebbe essere necessario eseguire operazioni di manutenzione sul nodo primario o secondario.

Nodo secondario#

Il nodo secondario può essere spento per la manutenzione senza influire sul nodo primario.

  1. Arrestare keepalived sul nodo secondario:

    /etc/init.d/keepalived stop

  2. Eseguire la manutenzione.

  3. Avviare keepalived sul nodo secondario:

    /etc/init.d/keepalived start

Nodo primario#

Il nodo primario può essere spento per la manutenzione; il nodo secondario assumerà gli indirizzi IP virtuali e tutti i servizi.

  1. Arrestare keepalived sul nodo primario:

    /etc/init.d/keepalived stop

  2. Eseguire la manutenzione.

  3. Avviare keepalived sul nodo primario:

    /etc/init.d/keepalived start

Accesso remoto#

Il nodo primario è accessibile sia dalle interfacce LAN che WAN. Pertanto, il nodo secondario è accessibile solo dall’interfaccia LAN. Quando ci si connette al nodo secondario da una rete remota, è necessario accedere prima al nodo primario e poi collegarsi al nodo secondario utilizzando SSH.

Dopo essersi connessi al nodo primario, utilizzare il seguente comando per accedere al nodo secondario:

ns-ha-config ssh-remote

Questo comando stabilirà una connessione SSH al nodo secondario utilizzando la chiave SSH generata durante la configurazione HA.

Aggiornamento#

Il nodo secondario non riceve aggiornamenti di sistema automaticamente perché non ha accesso diretto a Internet. Per aggiornare il nodo secondario, è necessario connettersi al nodo primario ed eseguire il comando di aggiornamento sul nodo secondario:

ns-ha-config upgrade-remote

Questo comando scaricherà l’immagine più recente, la caricherà sul nodo secondario e la installerà. Come per un aggiornamento normale, il nodo secondario verrà riavviato dopo l’installazione.

Risoluzione dei problemi#

La risoluzione dei problemi della configurazione HA può essere complessa, soprattutto se il nodo secondario non è raggiungibile o se il nodo primario non risponde come previsto.

Ricordare che il nodo secondario non ha accesso diretto a Internet nel suo normale stato di standby. Pertanto:

  • Non è in grado di risolvere nomi DNS esterni.

  • Non è possibile raggiungere il Controller o altri portali esterni.

  • Non riceverà aggiornamenti di sistema.

Le seguenti istruzioni possono aiutare a identificare e risolvere i problemi comuni. Per iniziare la risoluzione dei problemi, è necessario accedere alla console SSH di entrambi i nodi.

Identificazione dei nodi#

Poiché il nome host del nodo secondario si sincronizza con quello primario, il prompt di bash cambia per indicare il ruolo del nodo:

  • Prompt del nodo primario: root@NethSec [P]:~#

  • Prompt del nodo secondario: root@NethSec [S]:~#

Stato di Keepalived#

Eseguire ns-ha-config status per verificare le statistiche di Keepalived. Estrarre dal risultato:

Keepalived Statistics:
  advert_rcvd: 249
  advert_sent: 0
  become_master: 1
  release_master: 0
  packet_len_err: 0
  advert_interval_err: 0
  ip_ttl_err: 0
  invalid_type_rcvd: 0
  addr_list_err: 0
  invalid_authtype: 0
  authtype_mismatch: 0
  auth_failure: 0
  pri_zero_rcvd: 1
  pri_zero_sent: 0

Su un nodo primario, il valore di master.become_master dovrebbe essere 1 o superiore, indicando che ha assunto con successo il ruolo di master. Inoltre, master.advert.sent dovrebbe essere maggiore di 0, indicando che sta inviando attivamente annunci al nodo secondario.

Su un nodo secondario, il valore di master.advert_rcvd dovrebbe essere maggiore di 0, indicando che sta ricevendo annunci dal nodo primario. Se master.become_master è 0, significa che il nodo non è subentrato come master, il che è previsto per un nodo secondario.

Traffico VRRP#

Il nodo primario invia annunci VRRP al nodo secondario ogni secondo. È possibile verificare il traffico VRRP utilizzando il seguente comando sul nodo primario:

tcpdump -vnnpi <lan_interface> vrrp

Sostituire <lan_interface> con il nome dell’interfaccia LAN (ad esempio, eth0).

L’output dovrebbe mostrare i pacchetti VRRP inviati dal nodo primario al nodo secondario. Un esempio di output:

tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
 13:54:16.629467 IP (tos 0xc0, ttl 255, id 19404, offset 0, flags [none], proto VRRP (112), length 44)
 192.168.100.238 > 192.168.100.239: VRRPv2, Advertisement, vrid 100, prio 200, authtype simple, intvl 1s, length 24, addrs(2): 192.168.122.49,192.168.100.240 auth "1655e3d3"

Se lo stesso comando viene eseguito sul nodo secondario, dovrebbe mostrare i pacchetti VRRP ricevuti dal nodo primario.

Log#

Tutti i log sono memorizzati in /var/log/messages su entrambi i nodi.

È possibile esaminare componenti specifici del sistema HA nei log:

  • Controllare i log di sincronizzazione di rsync:

    grep ns-rsync.sh /var/log/messages

  • Esaminare le attività di connessione SSH per la sincronizzazione:

    grep dropbear /var/log/messages

  • Visualizzare le modifiche di stato e gli eventi di keepalived:

    grep Keepalived /var/log/messages

  • Traccia le importazioni della configurazione di rete sul nodo secondario:

    grep "ns-ha: Importing network configuration" /var/log/messages

Debugging#

Quando i file di log non sono sufficienti, è possibile abilitare la registrazione di debug per componenti specifici:

Eseguire il debug dello script ns-ha-config:

bash -x ns-ha-config <action> [<options>]

Visualizzare la configurazione attiva di keepalived:

cat /tmp/keepalived.conf

Abilitare la registrazione di debug di keepalived (sul primario):

uci set keepalived.primary.debug=1
uci commit keepalived
reload_config

Quindi, cercare Keepalived_vrrp nel file /var/log/messages.

Reimpostare la configurazione#

Il comando di reset ripristina la configurazione del cluster allo stato predefinito. Tipicamente, dopo il reset, il nodo primario può continuare a funzionare normalmente, mentre il nodo secondario, non più utilizzato nel cluster, dovrebbe essere riportato alle impostazioni predefinite per evitare eventuali conflitti. Dopo il reset, rimane attiva solo l’interfaccia HA, quindi è necessario un riavvio per completare il processo. Il reset deve essere eseguito localmente sul nodo primario.

Il comando di reset:

  • Arrestare e disabilitare keepalived e conntrackd.

  • Rimuovere i file di configurazione HA.

  • Pulire la configurazione di dropbear, inclusi le chiavi SSH.

Alla fine, è necessario un riavvio per applicare le modifiche. È sufficiente eseguire:

ns-ha-config reset
reboot