11 Journalisation, diagnostic et tests des clusters

Ce chapitre décrit les différentes ressources disponibles pour tester votre installation ACSLS HA et pour les aspects liés au diagnostic et aux problèmes de dépannage qui peuvent survenir sur le système.

Journalisation de Solaris Cluster

Les messages de Solaris Cluster pendant un basculement sont écrits dans le fichier /var/adm/messages. Ce fichier contient des messages en rapport aux fonctions des clusters, aux erreurs ACSLS et aux messages d'information. Seul le noeud actif écrit des messages dans le fichier /var/adm/messages.

Solaris Cluster surveille la santé d'ACSLS en le sondant toutes les 60 secondes. Vous pouvez visualiser le journal de ce sondage ici :

/var/cluster/logs/DS/acsls-rg/acsls-rs/probe_log.txt

Dans le même répertoire, il y a un fichier qui consigne chaque évènement de démarrage et d'arrêt quand il y a une séquence de basculement.

/var/cluster/logs/DS/acsls-rg/acsls-rs/start_stop_log.txt

Journal des évènements ACSLS

Le journal des évènements ACSLS est $ACS_HOME/log/acsss_event.log. Ce journal inclut des messages concernant les évènements de démarrage et d'arrêt détectés par le logiciel ACSLS. Le journal fait état des changements affectant l'état opérationnel des ressources de bibliothèque et il consigne toutes les erreurs qui sont détectées par le logiciel ACSLS. acsss_event.log est géré et archivé automatiquement à partir de paramètres définis dans acsss_config option-2.

Utilitaires de surveillance de clusters

Les utilitaires de Solaris Cluster se trouvent dans le répertoire /usr/cluster/bin.

Pour afficher l'état actuel du groupe de ressources ACSLS : clrg list -v
Pour afficher l'état actuel des deux noeuds de cluster : clrg status
Pour afficher l'état des groupes de ressources : clrs status
Pour obtenir un état détaillé des noeuds, des périphériques de quorum et des ressources de cluster : cluster status
Pour une liste détaillée des composants dans la configuration du cluster : cluster show
Pour afficher l'état de chaque noeud Ethernet dans les groupes de ressources : clnode status -m
Pour afficher l'état du groupe de ressources : scstat -g
Pour afficher l'état du groupe de périphériques : scstat -D
Pour afficher l'état de santé des liaisons réseau par pulsations : scstat -D ou clintr status
Pour afficher l'état d'IPMP : scstat -i
Pour afficher l'état des noeuds : scstat -n
Pour afficher la configuration et l'état du quorum : scstat -q or clq status
Pour afficher les ressources détaillées du cluster, y compris les valeurs de temporisation : clresource show -v

Tests de récupération et de basculement

Cette section aborde les conditions, la surveillance et les tests de récupération et de basculement.

Conditions de récupération

Il existe plusieurs conditions système fatales qui permettent quand même une récupération sans devoir passer par un basculement du système. Par exemple, avec IPMP, une connexion Ethernet dans chaque groupe peut défaillir pour une raison quelconque, mais la communication doit reprendre sans s'interrompre via l'autre chemin.

La baie de disques partagés doit être connectée aux serveurs par deux ports distincts sur chaque serveur. Si un chemin est interrompu, le fonctionnement E/S du disque doit reprendre sur l'autre chemin sans interruption.

ACSLS est composé de plusieurs "services" logiciels qui sont surveillés par l'utilitaire Solaris Service Management Facility (SMF). En tant qu'utilisateur acsss, vous pouvez afficher une liste de chacun des services acsss à l'aide de la commande acsss status. Parmi ces services, on trouve la base de données PostgreSQL, le serveur d'application Web WebLogic et le logiciel d'application ACSLS. Si un service défaille sur un système Solaris, SMF doit réinitialiser automatiquement ce service sans devoir passer par un basculement du système.

Le service acsls lui-même consiste en plusieurs processus enfants qui sont surveillés par le parent, acsss_daemon. Pour afficher la liste des sous-processus ACSLS, utilisez la commande psacs (as user acsss). Si, pour une raison quelconque, l'un des processus enfants est annulé, le parent doit réinitialiser l'enfant et restaurer le fonctionnement normal.

Surveillance de récupération

Le meilleur endroit pour consulter la récupération des ressources système (comme les E/S de disque et les connexions Ethernet) est le journal du système /var/adm/messages.

SMF tient un journal spécifique pour chaque service logiciel qu'il surveille. Ce journal affiche les évènements de démarrage, de redémarrage et d'arrêt. Pour obtenir le chemin complet vers le journal des services, exécutez la commande svcs -l service-name Les services d'ACSLS peuvent être listés à l'aide de la commande acsss : $ acsss status. Les sous-processus peuvent être listes avec la commande $ acsss p-status.

Pour afficher la récupération d'un sous-processus ACSLS quelconque, vous pouvez surveiller le acsss_event.log ($ACS_HOME/ACSSS/log/acsss_event.log). Ce journal affiche tous les évènements de récupération qui impliquent un sous-processus d'ACSLS.

Tests de récupération

Les connexions réseau redondantes doivent être réinitialisées automatiquement par la logique IP Solaris à multi-acheminement (IPMP). Toute connexion de données interrompue vers la baie de disques partagés doit être réinitialisée automatiquement par Solaris sur le chemin de données redondants. Les services gérés par Solaris Service Management Facility doivent être réinitialisés automatiquement par SMF.

Pour les tests qui impliquent un réel basculement, vous devez connaître les paramètres de propriété définis dans le fichier : $ACS_HOME/acslsha/pingpong_interval. Malgré les conditions qui peuvent déclencher un basculement, Solaris Cluster n'initie pas d'action de basculement si un basculement précédent s'est produit au cours de l'intervalle pingpong_interval spécifié. Voir

Pour vérifier le réglage actuel de Pingpong_interval, utilisez la commande de cluster :

clrg show -p Pingpong_interval

Les méthodes de validation suggérées de ce comportement peuvent inclure les suivantes :

Avec ACSLS en marche, débranchez une connexion Ethernet de chaque groupe IPMP sur le noeud actif. Surveillez l'état avec : # scstat -i.

Observez la réaction dans /var/adm/messages. Le fonctionnement d'ACSLS doit ne pas être interrompu par cette procédure.
Avec ACSLS en marche, débranchez une connexion Fibre Channel ou SAS du serveur actif vers la ressource de disque partagé.

Observez la réaction dans /var/adm/messages. Le fonctionnement d'ACSLS doit ne pas être interrompu par cette procédure.

Répétez ce test avec chacune des connexions E/S redondantes.
Arrêtez brusquement ACSLS en arrêtant acsss_daemon.

Exécutez svcs -l acsls pour localiser le journal de service.

Consultez la fain de ce journal lorsque vous arrêtez acsss_daemon. Vous devez voir que le service est automatiquement réinitialisé par SMF. La même chose doit se produire si vous arrêtez acsls avec acsls shutdown.
Désactivez le service acsls avec SMF.

Ceci peut être fait en tant qu'utilisateur root avec svcadm disable acsls ou en tant qu'utilisateur acsss avec acsss disable.

Comme SMF exécute l'évènement d'arrêt, il n'y a aucune tentative de réinitialisation du service acsls. C'est le comportement souhaité. Vous devez réinitialiser le service acsls sous SMF en utilisant $ acsss enable ou # svcadm enable acsls.
Arrêtez le service acsdb.

En tant qu'utilisateur acsdb, désactivez brusquement la base de données PostgreSQL avec la commande suivante :
```
pg_ctl stop \
     -D $installDir/acsdb/ACSDB1.0/data \
     -m immediate
```
Cette action doit arrêter la base de données et également provoquer l'arrêt des processus acsls. Exécutez svcs -l acsdb pour localiser le journal de service acsdb.

Consultez la fin du journal du servcie acsb et du journal du service acsls lorsque vous arrêtez la base de données. Vous devez voir que lorsque le service acsdb s'arrête, il arrête également le service acsls. Les deux services doivent être réinitialisés automatiquement par SMF.
Alors que ACSLS est en marche, exécutez psacs en tant qu'utilisateur acsss pour afficher une liste des sous-processus exécutés sous acsss_daemon.

Arrêtez l'un quelconque de ces sous-processus. Observez acsss_event.log pour confirmer que le sous-processus est réinitialisé et qu'une procédure de récupération est lancée.

Conditions pour le basculement

Le logiciel Solaris Cluster surveille le système Solaris en recherchant les conditions fatales qui peuvent nécessiter un basculement du système. Parmi ces conditions, il peut y avoir un basculement initié par l'utilisateur (clrg switch), une réinitialisation du système du noeud actif ou un blocage du système, un défaut de mémoire fatal ou des communications E/S irrécupérables sur le noeud actif. Solaris Cluster surveille également les agents HA qui sont destinés à des applications spécifiques. L'agent ACSLS HA demande un basculement du système dans l'une des conditions suivantes :

La communication TCP/IP est perdue entre le noeud actif et l'hôte logique.
Le système de fichiers $ACS_HOME n'est pas monté.
Le système de fichiers /export/backup n'est pas monté.
La communication est perdue vers un ACS listé dans le fichier $ACS_HOME/acslsha/ha_acs_list.txt dont l'état souhaité est en ligne et lorsqu'un switch lmu n'est pas autrement possible ni faisable.

Surveillance de basculement

A chaque instant, vous pouvez surveiller l'état de basculement des noeuds respectifs à l'aide de la commande : # clrg status

Ou bien vous pouvez surveiller l'activité de basculement en observant la fin du fichier start_stop_log :

# tail -f /var/cluster/logs/DS/acsls-rg/acsls-rs/start_stop_log.txt

Il peut être utile d'afficher (tail -f) le fichier /var/adm/messages sur les deux noeuds pendant que vous effectuez les opérations de diagnostic de basculement.

Tests de basculement

La méthode prescrite pour tester le basculement de cluster est d'utiliser la commande clrg switch :
```
# clrg switch -M -e -n <standby node name> acsls-rg
```
Cette action doit arrêter l'application ACSLS et basculer le fonctionnement depuis le serveur actif vers le système en veille. Les options -M -e donnent au serveur l'instruction d'activer les services SMF sur le nouveau noeud. Observez la séquence de ces évènements sur chaque noeud en consultant la fin du fichier /var/adm/messages. Vous pouvez également consulter la fin du journal démarrages-arrêts :
```
# tail -f /var/cluster/logs/DS/acsls-rg/acsls-rs/start_stop_log.txt
```
Exécutez régulièrement la commande : # clrg status
Une réinitialisation du système sur le noeud actif doit initier un basculement HA immédiat sur l'autre noeud.

Cette opération doit se terminer avec ACSLS exécuté sur le nouveau noeud actif. Sur le noeud en veille, observez la fin du fichier /var/adm/messages lorsque le système en veille endosse son nouveau rôle de noeud actif. Vous pouvez également exécuter régulièrement la commande : # clrg status
Utilisez init 5, pour mettre hors tension le noeud de serveur actif et vérifiez le basculement du système.
Déconnectez les deux câbles de données entre le noeud de serveur actif et la baie de stockage de disques partagés, et vérifiez que le système passe sur le noeud en veille.
En partant du principe qu'une certaine bibliothèque est listée dans le fichier de stratégie ha_acs_list.txt, déconnectez les deux lignes de communication Ethernet entre le noeud de serveur actif et cette bibliothèque.

Vérifiez que le système bascule sur le noeud en veille.

Tests supplémentaires

Si vos unités d'initialisation en miroir sont enfichables à chaud, vous pouvez désactiver l'une d'elles et confirmer que le système reste entièrement opérationnel. Avec une unité d'initialisation désactivée, redémarrez le système pour vérifier que le noeud provient de l'autre unité d'initialisation. Répétez cette action pour chacune des unités d'initialisation sur chacun des deux noeuds.

Retirez l'alimentation électrique unique du noeud actif ; le système doit rester totalement opérationnel avec l'autre alimentation électrique.