Problemi vari

il file hacmp.out visualizza l'output limitato per il comando tail -f

Problema

Nel file /var/hacmp/log/hacmp.out vengono visualizzati solo i messaggi di inizio script. Lo script che viene specificato nel messaggio non è un eseguibile oppure il livello DEBUG è impostato su basso.

Soluzione

Aggiungere l'autorizzazione per eseguire lo script utilizzando il comando chmod e assicurarsi che il livello DEBUG sia impostato su alto.

La verifica cluster visualizza il messaggio senza la notifica dell'errore di configurazione

Problema

Il seguente messaggio viene visualizzato indipendentemente dal fatto che la notifica di errore automatico sia configurata o meno:

"Remember to redo automatic error notification if configuration
has changed."

Soluzione

Ignorare questo messaggio se la notifica di errore automatico non è configurata.

Scenari che visualizzano il messaggio config_too_long

Il messaggio config_too_longviene visualizzato ogni volta che un evento cluster impiega più tempo per il completamento rispetto a un periodo di timeout specificato.

Nelle versioni di PowerHA SystemMirror precedenti a 4.5, il periodo di timeout era fisso per tutti gli eventi del cluster e impostato per default a 360 secondi. Se un evento del cluster, come un evento node_up o node_down, dura più di 360 secondi, ogni 30 secondi PowerHA SystemMirror visualizza un messaggio di avviso config_too_long che è stato registrato nel file hacmp.out .

In PowerHA SystemMirror è possibile personalizzare il periodo di tempo consentito per il completamento di un evento del cluster prima che PowerHA SystemMirror emetta un avviso di sistema.

config_too_long $sec $event_name $argument<

• $event_name: indica l'evento di riconfigurazione non riuscito.
• $argument: indica il parametro utilizzato dall'evento.
• $sec: indica il numero di secondi prima dell'invio del messaggio.

In PowerHA SystemMirror Versione 4.5 o precedente, i messaggi config_too_long continuavano a essere aggiunti al file hacmp.out ogni 30 secondi finché non si interveniva.

La console visualizza i messaggi SNMP

Problema

Il file /etc/syslogd viene modificato per inviare l'output daemon.notice al file /dev/console .

Soluzione

Modificare il file /etc/syslogd per reindirizzare l'output daemon.notice a /usr/tmp/snmpd.log. Il file snmpd.log è l'ubicazione predefinita per la registrazione dei messaggi.

I nodi cluster non riescono a scalare dopo il riavvio del sistema

Problema

I nodi cluster non si sono sfalsati dopo il riavvio del sistema.

Soluzione

Per evitare che un riavvio non pianificato del sistema interrompa un fallover nell'ambiente cluster, tutti i nodi del cluster devono avere il campo Automatically REBOOT a system after a crash (Riavvia automaticamente un sistema dopo un crash) sul pannello Change/Show Characteristics of Operating System (Modifica/Mostra caratteristiche del sistema operativo) di SMIT impostato su false, oppure è necessario mantenere la modalità Secure (sicura) di System p™ ( IBM® ) durante il normale funzionamento.

Entrambe le misure impediscono il riavvio del sistema se il comando shutdown viene eseguito inavvertitamente. Senza una di queste misure, se si verifica un riavvio non pianificato, l'attività sui dischi sul nodo di riavvio può impedire ad altri nodi di acquisire correttamente i dischi.

Oggetti eliminati visualizzati nella mappa NetView

Problema

I simboli di oggetti precedentemente eliminati o estranei sono stati visualizzati nella mappa Tivoli NetView for z/OS .

Soluzione

Ricreare il database Tivoli NetView for z/OS .

Per ricreare il database Tivoli NetView for z/OS , effettuare le seguenti operazioni sul server Tivoli NetView for z/OS :

1. Arrestare tutti i daemon Tivoli NetView for z/OS :

   /usr/OV/bin/ovstop -a

2. Rimuovere il database dal server Tivoli NetView for z/OS :

   rm -rf /usr/OV/database/*

3. Avviare il database di oggetto Tivoli NetView for z/OS :

   /usr/OV/bin/ovstart ovwdb

4. Ripristinare i campi Tivoli NetView for z/OS o HAView:

   /usr/OV/bin/ovw -fields

5. Avviare tutti i daemon di Tivoli NetView for z/OS .

   /usr/OV/bin/ovstart -a

Premendo F1 nel pannello SMIT non viene visualizzata la guida

Problema

Premendo F1 nel pannello SMIT non viene visualizzata la guida.

Soluzione

La guida può essere visualizzata solo se la variabile LANG è impostata su una delle lingue supportate da PowerHA SystemMirror e se sono installati i cataloghi dei messaggi associati a PowerHA SystemMirror . Il sito PowerHA SystemMirror supporta le seguenti lingue:

• fr_CA
• ja_JP

Per elencare le locale installate (i LPP bsl), immettere il comando seguente:

locale -a

Per elencare la locale attiva, immettere il comando seguente:

locale

Poiché la variabile di ambiente LANG determina la locale attiva, se LANG=en_US, la locale è en_US.

Errore di sintassi aritmetica con impostazione locale

Problema

Il seguente problema di sintassi aritmetica può verificarsi durante l'utilizzo del cluster PowerHA con l'impostazione della locale come pt_BR, fr_FR o, sl_SI e così via. Per esempio

# export LANG=pt_BR
# typeset -F4 var=0.00
ksh93: typeset: 0.00: arithmetic syntax error
# (( sum = sum + 0.5 ))
ksh93:  sum = sum + 0.5 : arithmetic syntax error

Questo problema può essere evitato se LANG è impostato su una delle lingue come en_Us e ja_JP.

Soluzione

Il problema si verifica a causa di un'impostazione inappropriata della variabile di ambiente LC_NUMERIC . Quando la variabile di ambiente LANG è impostata su una qualsiasi delle lingue come pt_BR, fr_FR o, sl_SI e così via, La variabile LC_NUMERIC per impostazione predefinita considera il suo delimitatore decimale come una virgola (",").

# locale
LANG=fr_FR
LC_COLLATE="fr_FR"
LC_CTYPE="fr_FR"
LC_MONETARY="fr_FR"
LC_NUMERIC="fr_FR"
LC_TIME="fr_FR"
LC_MESSAGES="fr_FR"
LC_ALL=
# locale -k LC_NUMERIC
decimal_point=","
thousands_sep=" "
grouping="3"

Per eseguire operazioni numeriche con decimali, la variabile LC_NUMERIC deve avere un delimitatore decimale come punto (".").

Per evitare questo problema, impostare LC_NUMERIC=C insieme all'impostazione LANG .

File di riepiloghi eventi troppo grande

Problema

In PowerHA SystemMirror i riepiloghi degli eventi vengono estratti da hacmp.out file e può essere visualizzato utilizzando l'opzione Problem Determination Tools > Visualizzazione e gestione PowerHA SystemMirror > Visualizza/Salva/Elimina riepiloghi eventi > Visualizza riepiloghi eventi in SMIT. Questo pannello include lo stato del gruppo di risorse e le informazioni di ubicazione alla fine. Le informazioni sul gruppo di risorse vengono raccolte dal comando clRGinfo e potrebbero richiedere ulteriore tempo se il cluster non è in esecuzione quando si esegue l'opzione Visualizza riepiloghi eventi .

Soluzione

Il comando clRGinfo visualizza rapidamente le informazioni sul gruppo di risorse quando il cluster è in esecuzione. Se il cluster non è in esecuzione, si verifica un ritardo nella visualizzazione delle informazioni sul gruppo di risorse.

Problemi di Application Monitor

Problema 1

Controllo dello stato di un Application Monitor. In alcune circostanze, potrebbe non essere chiaro se un monitor dell'applicazione è in esecuzione o meno. Per verificare lo stato di un monitor dell'applicazione, eseguire il seguente comando:

ps -ef | grep <application controller name> | grep clappmond

Questo comando produce una lunga riga di output dettagliato se l'applicazione è monitorata.

Se non è presente alcun output, l'applicazione non viene monitorata.

Soluzione

Il monitor dell'applicazione potrebbe non essere:

• Nessun monitor è configurato per il controller dell'applicazione.
• Il controllo non viene avviato perché l'intervallo di stabilizzazione non è stato completato.
• Il controllo è in stato sospeso.
• Il monitor non è configurato correttamente.
• Si è verificato un errore.

Verificare se un monitor è configurato, se l'intervallo di stabilizzazione è stato superato e se il monitor non si trova in uno stato sospeso. Se una qualsiasi configurazione non è corretta, riesaminare la configurazione originale del monitor in SMIT e riconfigurarla in base alle necessità.

Problema 2

Il monitor dell'applicazione non esegue l'azione di errore specificata. L'azione di errore specificata non si verifica quando un'applicazione ha esito negativo.

Soluzione

Selezionare Intervallo di riavvio. Se l' Intervallo di riavvio è impostato su un valore troppo breve, il Contatore di riavvio potrebbe essere reimpostato su zero troppo rapidamente, determinando una serie infinita di tentativi di riavvio e nessuna altra azione intrapresa.

Problema 3

Il monitor dell'applicazione non sempre indica che l'applicazione sta funzionando correttamente.

Soluzione

• Verificare che il monitor sia scritto per restituire il codice di uscita corretto in tutti i casi. Il valore di ritorno deve essere zero se l'applicazione funziona correttamente e deve essere un valore diverso da zero se l'applicazione ha esito negativo.
• Controllare tutti i percorsi possibili attraverso il codice, inclusi i percorsi di errore, per assicurarsi che il codice di uscita sia congruente con lo stato dell'applicazione.

Problema 4

Impossibile determinare se e quando viene eseguito il monitoraggio.

Soluzione

Controllare i file di log creati dal monitoraggio. Il monitor può registrare i messaggi stampandoli nel file stdout di output standard. Per i monitor di lunga durata, l'output viene memorizzato nel file /var/hacmp/log/clappmondapplication monitor name.resource group name.monitor.log . Per i monitor di avvio, questo output viene memorizzato nel file /var/hacmp/log/clappmond.application server name.resource group name.monitor.log . I file di log del monitoraggio vengono sovrascritti, ogni volta che viene eseguito il monitoraggio dell'applicazione.

Il file di riepiloghi eventi non visualizza le informazioni sul gruppo di risorse come previsto

Problema

PowerHA SystemMirror non riesce a spostare selettivamente il gruppo di risorse interessato su un altro nodo del cluster quando si verifica una perdita del quorum del gruppo di volumi.

Soluzione

Se il quorum viene perso per un gruppo di volumi che appartiene a un gruppo di risorse su un nodo cluster, il sistema controlla se l'errore LVM_SA_QUORCLOSE viene visualizzato nel file di log degli errori AIX del nodo. Il sistema informa il gestore cluster di spostare in modo selettivo il gruppo di risorse interessato. PowerHA SystemMirror utilizza questo metodo di notifica degli errori solo per i gruppi di volumi in mirroring con quorum abilitato.

Se il fallover non si verifica, verificare che l'errore LVM_SA_QUORCLOSE sia stato visualizzato nella registrazione errori AIX . Quando il buffer del log degli errori AIX è pieno, le nuove voci vengono eliminate fino a quando lo spazio del buffer diventa disponibile e una voce del log degli errori informa l'utente di questo problema. Per risolvere questo problema, aumentare la dimensione del buffer interno del log degli errori AIX per il programma di controllo unità.

Il processo di sostituzione del disco cluster ha esito negativo

Problema

Il processo di sostituzione del disco ha esito negativo durante l'esecuzione del comando replacepv .

Soluzione

Assicurarsi di eliminare la directory /tmp/replacepv e tentare nuovamente il processo di sostituzione.

È inoltre possibile provare ad eseguire il processo su un altro disco.

L'evento rg_move elabora più gruppi di risorse contemporaneamente

Problema

Nel file hacmp.out , un evento rg_move elabora più gruppi di risorse non simultanei in un'operazione.

Soluzione

Nei cluster con dipendenze, PowerHA SystemMirror elabora tutti i gruppi di risorse sugli eventi node_up, anche se gli eventi rg_move. Durante un singolo evento rg_move, PowerHA SystemMirror può elaborare più gruppi di risorse non concorrenti in un unico evento.

Impossibile smontare il file system

Problema

Un file system non viene smontato correttamente durante un evento, ad esempio quando si arrestano i servizi cluster con l'opzione di portare i gruppi di risorse non in linea.

Soluzione

Uno dei motivi più comuni per cui un file system non riesce ad essere smontato quando si arrestano i servizi cluster con l'opzione di portare i gruppi di risorse non in linea è perché il file system è occupato. Per smontare correttamente un file system, nessun processo o utente può accedervi al momento. Se un utente o un processo sta accedendo al file system, il file system non può essere smontato. Lo stesso problema potrebbe verificarsi se un file viene eliminato ma è ancora aperto.

Lo script per arrestare un'applicazione deve includere un controllo per garantire che i file system condivisi non siano in uso o eliminati e in stato di apertura utilizzando il comando fuser . Lo script deve utilizzare il comando fuser per visualizzare i processi o gli utenti che accedono ai file system in questione. I PID di questi processi possono quindi essere acquisiti e terminati per liberare il file system in modo che possa essere smontato. Per ulteriori informazioni, consultare fuser Command.

La riconfigurazione dinamica imposta un blocco

Problema

Quando si esegue un'operazione di riconfigurazione dinamica (DARE), potrebbe essere visualizzato un messaggio di errore su un blocco DARE se è in corso un'altra operazione DARE o se non è stata completata una precedente operazione DARE. Il messaggio di errore indica che il blocco deve essere eliminato se non è stata avviata un'operazione DARE o se non è stata completata una precedente operazione DARE.

Soluzione

Esaminare i log /var/hacmp/log/hacmp.out sui nodi cluster per determinare il motivo del precedente errore DARE. Una voce config_too_long viene visualizzata nel file hacmp.out in cui un'operazione in uno script di eventi ha impiegato troppo tempo per essere completata. Se hacmp.ou indica che uno script non è stato completato a causa di un errore, correggere questo problema e completare manualmente i passi rimanenti necessari per completare l'evento.

Eseguire l'opzione PowerHA SystemMirror SMIT Problem Determination Tools > Recover from PowerHA SystemMirror Script Failure per portare i nodi del cluster al successivo stato di evento completo.

È possibile cancellare il blocco DARE selezionando l'opzione PowerHA SystemMirror SMIT Problem Determination Tools > Release Locks Set by Dynamic Configuration se il passaggio PowerHA SystemMirror SMIT Recover from PowerHA SystemMirror Script Failure non lo ha fatto.

Il gruppo di risorse non riesce a passare in linea in una WPAR

Problema

Il gruppo di risorse non è in linea in una WPAR su un nodo particolare.

Soluzione

1. Verificare che il nodo in questione sia compatibile con WPAR. È necessario installare il fileset bos.wpars su un nodo AIX con funzionalità WPAR. Se il nodo non è compatibile con WPAR, il gruppo di risorse non viene eseguito nella WPAR. Per controllare se il sottopacchetto bos.wpars è installato, immettere il seguente comando:

   lslpp -L "bos.wpars"

2. Sul nodo specificato, verificare che esista una WPAR con lo stesso nome del gruppo di risorse abilitato per la WPAR. Utilizzare il comando lswpar <resource group name> per verificare. Se non esiste alcuna WPAR con il nome specificato, crearla utilizzando il comando mkwpar . Dopo aver creato una WPAR, accertarsi che tutti gli script definiti dall'utente associati al gruppo di risorse abilitato per la WPAR siano accessibili all'interno della WPAR.
3. Accertarsi che i file system sul nodo non siano pieni. In questo caso, liberare spazio su disco spostando alcuni file nella memoria esterna.
4. Verificare che il servizio rsh sia abilitato nella WPAR corrispondente completando la seguente procedura:
   • Verificare che il servizio di inetd sia in esecuzione in WPAR immettendo il seguente comando in WPAR:

     lssrc -s inetd

     Se il servizio inetd non è attivo, avviare il servizio utilizzando il comando startsrc .

   • Accertarsi che rsh sia elencato come servizio noto nel file /etc/inetd.conf nella WPAR.

I nodi e i dischi del repository hanno esito negativo simultaneamente

Problema

I nodi e i dischi del repository hanno esito negativo simultaneamente durante un evento come un errore del data center.

Soluzione

In un malfunzionamento simultaneo del nodo e del disco del repository, ad esempio quando si verifica un malfunzionamento di un centro dati, potrebbe essere necessario sostituire il disco del repository prima del riavvio di tutti i nodi.

1. Per sostituire il disco repository, utilizzare il seguente percorso SMIT (System Management Interface Tool):

   $ smitty sysmirror
   >Problem Determination Tools > Replace the Primary Repository Disk

   Nota: un nodo che si trova nello stato DOWN mentre il disco del repository è in fase di sostituzione continua ad accedere al disco del repository 'originale' anche dopo il riavvio. Se il disco repository 'originale' diventa nuovamente disponibile, i servizi cluster CAA (Cluster Aware AIX ) iniziano a utilizzare tale disco. Il nodo rimane nello stato DOWN .
2. Per controllare lo stato di un nodo, immettere il seguente comando:

   lscluster -m

   Questo comando produce un output simile al seguente:

   Calling node query for all nodes...
   Node query number of nodes examined: 2
         Node name: ha1clA
         Cluster shorthand id for node: 1
         UUID for node: 1ab63438-d7ed-11e2-91ce-46fc4000a002
         State of node: DOWN  NODE_LOCAL
         ...
        -----------------------------------------------------
         Node name: ha2clA
         Cluster shorthand id for node: 2
         UUID for node: 1ac309e2-d7ed-11e2-91ce-46fc4000a002
         State of node: UP
         ...
         Points of contact for node: 2
         ------------------------------------------
         Interface     State  Protocol    Status
         ------------------------------------------
         en0           UP     IPv4         none
         en1           UP     IPv4         none

3. Per forzare un nodo precedentemente non riuscito a utilizzare il 'nuovo' disco del repository, immettere i seguenti comandi sul nodo interessato:
   1. $ export CAA_FORCE_ENABLED=true
   2. $ clusterconf -fu
4. Per verificare se i servizi cluster CAA non sono attivi, immettere il seguente comando:

   lscluster -c

   Nota: potresti dover attendere fino a 10 minuti prima che il nodo si unisca nuovamente al cluster CAA, utilizzando il disco del repository 'nuovo'.
5. Per verificare se i servizi cluster CAA sono stati avviati correttamente, immettere il comando riportato di seguito:
   1. lscluster -c
   2. lscluster -m
6. Prima di riavviare PowerHA SystemMirror sul nodo interessato, la configurazione di PowerHA SystemMirror deve essere sincronizzata. La sincronizzazione deve essere avviata su un nodo che si trovava nello stato UP durante la sostituzione del disco del repository. Per avviare il processo di verifica e sincronizzazione su un nodo, utilizzare il seguente percorso SMIT:

   $ smitty sysmirror
   >Cluster Nodes and Networks > Verify and Synchronize Cluster Configuration

   Nota: Se sono disponibili più nodi e PowerHA SystemMirror non è in esecuzione su tutti, è necessario scegliere un nodo attivo per avviare la sincronizzazione.

Dopo che la verifica e la sincronizzazione sono state completate con successo nel passaggio 6, è possibile riavviare PowerHA SystemMirror sul nodo precedentemente fallito, utilizzando il seguente percorso SMIT:

$ smitty sysmirror
>System Management (C-SPOC) > PowerHA SystemMirror Services > Start Cluster Services

Commento della voce CAA nel file /etc/inetd.conf

Problema

Una voce CAA (Cluster Aware AIX ) commentata sta causando un errore durante il processo di creazione del cluster.

Soluzione

Dopo aver installato PowerHA SystemMirror, verificare che la seguente voce Cluster Aware AIX (CAA) sia commentata nel file /etc/inetd.conf prima di creare il cluster PowerHA SystemMirror .

caa_cfg stream tcp6 nowait root /usr/sbin/clusterconf 
clusterconf >>/var/adm/ras/clusterconf.log 2>&1

A partire da AIX 7.3, la voce CAA nel file /etc/inetd.conf è già commentata. Durante l'installazione di PowerHA SystemMirror , questa voce CAA nel file /etc/inetd.conf viene commentata per le versioni successive:

• PowerHA SystemMirror Versione 7.2.3 SP6, o successiva
• PowerHA SystemMirror Versione 7.2.4 SP4, o successiva
• PowerHA SystemMirror Versione 7.2.5 SP2, o successiva
• PowerHA SystemMirror Versione 7.2.6

Se AIX 7.3 è installato con una versione precedente di PowerHA SystemMirror rispetto alle versioni elencate in precedenza, la voce CAA non viene automaticamente commentata. È necessario impostare manualmente come commento la voce CAA del file /etc/inetd.conf .

Per eliminare il commento dalla voce CAA, eseguire questo comando su tutti i nodi del cluster prima di creare il cluster:

chsubserver -a -r inetd -v caa_cfg -p tcp6