12 Conseils de dépannage

ACSLS HA 8.4 est l'intégration de l'application ACSLS exécutée sur un système à deux noeuds sous Solaris 11.2 avec IPMP et ZFS contrôlés par Solaris Cluster 4.2.

Vérification de l'exécution d'ACSLS

Pour vérifier que les services ACSLS sont exécutés sur le noeud actif, utilisez la commande suivante en tant qu'utilisateur acsss :

# su - acsss
$ acsss status

Si un ou plusieurs services sont désactivés, activez-les avec $ acsss enable.

Si l'affichage d'état révèle qu'un ou plusieurs services ACSLS sont en mode de maintenance, exécutez la commande $ acsss l-status.

Recherchez le chemin du fichier journal du service défectueux et consultez ce journal afin d'y trouver des informations expliquant pourquoi ce service a été placé en mode de maintenance.

Si un ou plusieurs services acsls sont en mode de maintenance, ils peuvent être effacés en les désactivant puis en les activant de nouveau avec la commande acsss.

$ acsss shutdown
$ acsss enable

En tant qu'utilisateur root, utilisez # svcadm clear <service name> pour effacer un service donné.

Le service n'est pas effacé tant que le défaut sous-jacent n'est pas corrigé.

Les journaux d'actions spécifiques doivent également être consultés pour trouver la source du problème. La plupart se trouve dans le répertoire $ACS_HOME/log.

Le premier journal à consulter est le acsss_event.log. Ce journal consigne la plupart des évènements en rapport avec le fonctionnement général d'ACSLS.

Si le problème est dû à l'interface graphique d'ACSLS ou au fonctionnement de la bibliothèque logique, les journaux associés se trouvent dans le répertoire $ACS_HOME/log/sslm.

Pour l'interface graphique d'ACSLS et pour WebLogic, consultez AcslsDomain.log, AdminServer.log et gui_trace.logs.

Les problèmes d'installation associés à WebLogic sont répertoriés dans weblogic.log.

Pour les problèmes liés à une bibliothèque logique, une fois qu'une bibliothèque logique a été configurée, consultez slim_event.logs et smce_stderr.log.

Adressage d'une connexion à la ressource de disque partagé

Vérifiez que la ressource acsls-storage est en ligne et connectée au noeud de cluster actif.
```
# clrs status acsls-storage
```
Si la ressource acsls-storage n'est pas en ligne, vérifiez si la ressource est montée sur ZFS sur le noeud actif :
```
# zpool status
```
Si acslspool n'est pas monté sur le noeud actif, vérifiez s'il est monté sur le noeud en veille.
```
# ssh standby hostname zpool status
```
Si la ressource de disque partagé est monté sur le noeud en veille, commutez le contrôle du cluster sur ce noeud.
```
# clrg switch -n standby hostname acsls-rg
```
Si acslspool n'est pas monté sur le noeud actif, et si la ressource acsls-storage est hors line, vérifiez le noeud actif voit acslspool.
```
# zpool import (no argument)
```
Remarque :
Cette opération ne fonctionne que si acsls-storage est hors ligne. Pour le mettre hors ligne, utilisez la commande clrs disable acsls-storage.

Si le noeud actif voit acslspool, essayez de l'importer :
```
# zpool import -f acslspool
```
Si l'opération import réussit, mettez la ressource acsls-storage en ligne pour Solaris Cluster :
```
# clrs enable acsls-storage
```
Si le noeud actif ne voit pas acslspool, il faut dépanner la connexion physique vers l'unité partagée.

Lorsqu'il est impossible d'envoyer une commande ping à l'hôte logique

Vérifiez que le nom de l'hôte logique est enregistré sur Solaris Cluster.
```
# clrslh list
```
Déterminez le noeud actif :
```
# clrg status | grep -i Online
```
Vérifiez s'il est possible d'envoyer une commande ping au noeud actif.
```
# ping <node name>
```
Vérifiez que la ressource de nom logical-host est en ligne et connectée au noeud actif.
```
# clrslh status
```
Si l'hôte logique n'est pas en ligne, activez-le.
```
# clrs enable <logical host>
```
Vérifiez l'état des interfaces IP affectées au groupe public.
```
# ipadm
```
Sur l'affichage en sortie, vérifiez que chaque membre du groupe ipmp public affiche l'état ok.
Vérifiez l'état physique de chaque interface du groupe public (ipmp0).
```
# dladm show-phys
```
Vérifiez que l'hôte logique est raccordé à l'une des deux interfaces du groupe ipmp public (révélé à l'étape 5).
```
# arp <logical-hostname>
# ifconfig net0
# ifconfig net4
```
Cet exemple présume que net0 et net4 ont été affectés au groupe ipmp public.

L'adresse MAC de l'une des deux interfaces doit correspondre à l'adresse MAC affectée au nom d'hôte logique.

Contrôle des interconnexions entre noeuds

S'il est suspecté que la défaillance du contrôle du cluster est due à la perte de communication Cluster entre les deux noeuds, vérifiez l'interconnexion privée pour Cluster comme suit :

# cluster status -t interconnect