Ce chapitre décrit les différentes ressources disponibles pour tester l'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.
Les activités mises en oeuvre au cours d'un démarrage ou d'un basculement sont largement distribuées entre les deux noeuds. Par conséquent, le point de vue choisi pour observer le fonctionnement général au cours d'un test peut considérablement affecter la capacité de voir le déroulement des événements lors de leur exécution. Reportez-vous à L'utilitaire ha_console.sh pour savoir comment obtenir une vision d'ensemble.
Une configuration de tableau de bord recommandée pour l'observation du comportement HA global au cours d'un test comprend huit fenêtres de shell (quatre fenêtres pour chaque noeud).
Un shell de commande pour root doit être réservé sur chaque noeud pour activer différentes commandes si nécessaire.
Configurez une fenêtre sur chaque noeud pour afficher la fin du fichier système /var/adm/messages.
# tail -f /var/adm/messages
Solaris Cluster imprime tous les messages d'information dans ce fichier journal.
Configurez une autre fenêtre sur chaque noeud pour afficher la fin du fichier start_stop log.de la ressource acsls-rs.
# tail -f /var/cluster/logs/DS/acsls-rg/acsls-rs/start_stop_log.txt
Tous les messages publiés par le script de démarrage acsls_agt.sh y sont affichés.
Configurez une troisième fenêtre sur chaque noeud pour afficher la fin du journal de sondage acsls-rs.
# tail -f /var/cluster/logs/DS/acsls-rg/acsls-rs/probe_log.txt
Après le démarrage de l'application, Solaris Cluster sonde la ressource ACSLS une fois par minute. Un code numérique est renvoyé à Cluster depuis chaque sonde et les résultats sont imprimés dans le fichier probe_log.txt. Chaque sonde publie dans ce journal l'une des cinq valeurs de retour standard suivantes :
0 - The probe found that ACSLS is healthy and functioning normally. 1 - The probe may not have completed due to a functional error. 2 - The probe reports that ACSLS is in a transitional state. 3 - The ACSLS application has been intentionally placed offline. 201 - A condition was detected that requires fail-over action.
Solaris Cluster lance un basculement seulement en réponse au code 201. Les conditions demandant cette action sont répertoriées au Fonctionnement du cluster d'ACSLS. Tous les autres codes de retour provenant de la sonde du cluster sont considérés comme étant fournis à titre indicatif et aucune action du cluster n'est activée en réponse.
Il est possible d'activer des exemples de sonde à des fins de test à tout moment à partir de la ligne de commande. Utilisez la commande acsAgt probe :
#/opt/ACSLSHA/util/acsAgt probe
Tous les journaux mentionnés dans les étapes qui précèdent reflètent l'état du système du point de vue de Solaris Cluster. Deux journaux supplémentaires dans le répertoire $ACS_HOME/log/ fournissent une vue au niveau de l'application ACSLS. acsss_event.log signale tous les événements importants rencontrés par ACSLS à partir du démarrage de l'application. Toute problème de démarrage d'ACSLS rencontré par SMF est consigné dans le journal acsls_start.log.
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 des différentes ressources acsls-rg sur chaque noeud : scstat -g
Pour afficher l'état de santé des liaisons réseau par pulsations : 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 ou clq status
Pour afficher les ressources détaillées du cluster, y compris les valeurs de temporisation : clresource show -v
Cette section aborde les conditions, la surveillance et les tests de récupération et de basculement.
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, affichez 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.
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.
Les connexions réseau redondantes doivent être redémarrées automatiquement par la logique IPMP Solaris. Toute connexion de données interrompue vers la baie de disques partagés doit être redémarrée automatiquement par Solaris sur le chemin de données redondants. Les services gérés par Solaris Service Management Facility doivent être redémarrée automatiquement par SMF.
Pour les tests qui impliquent un réel basculement, notez 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é.
Pour afficher ou modifier de manière dynamique l'intervalle pingpong, accédez au répertoire /opt/ACSLSHA/util et exécutez acsAgt pingpong :
# ./acsAgt pingpong Pingpong_interval current value: 1200 seconds. desired value: [1200] 300 Pingpong_interval : 300 seconds.
Utilisez l'une ou l'ensemble des technique suivantes pour évaluer la résilience de l'installation HA :
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.
Vérifiez que la valeur Failover_mode du cluster est définie sur HARD. 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 mettant fin à acsss_daemon. Utilisez pkill acsss_daemon.
Exécutez svcs -l acsls pour localiser le journal de service.
Affichez la fin de ce journal à l'arrêt de acsss_daemon. Observez que le service est redémarré automatiquement par SMF. La même chose doit se produire si l'arrêt de acsls s'effectue 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 redémarrage du service acsls. C'est le comportement souhaité. Le service acsls doit être redémarré sous SMF. En tant que root, utilisez la commande svcadm enable acsls. Ou, en tant qu'utilisateur acsss, utilisez la commande acsss-enable.
Arrêtez le service acsdb.
En tant qu'utilisateur acsdb, accédez au fichier .acsls_env.
$ su acsdb $ . /var/tmp/acsls/.acsls_env
Ensuite, 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.
Affichez la fin des journaux de service acsdb et acsls dans lesquels la base de données est arrêtée. Observez que lorsque le service acsdb s'arrête, il met aussi fin au service acsls. Les deux services doivent être redémarré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 redémarré et qu'une procédure de récupération est lancée.
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 (acsAgt nodeSwitch ou clrg switch -n), 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 de sauvegarde de base de données ($ACS_HOME/.../backup) n'est pas monté.
La communication est perdue vers la bibliothèque correspondant à un ACS spécifié 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.
A chaque instant, il est possible de surveiller l'état de basculement des noeuds respectifs à l'aide de la commande : # clrg status.
L'activité de basculement peut aussi être surveillée 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. Voir Surveillance du fonctionnement du cluster d'ACSLS.
La commande simple qui permet de lancer un basculement du cluster est acsAgt nodeSwitch.
# acsAgt nodeSwitch
Ou, utilisez la commande Cluster équivalente :
# clrg switch -n <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. L'option -M -e donnent au serveur l'instruction d'activer les services SMF sur le nouveau noeud. Voir Surveillance du fonctionnement du cluster d'ACSLS.
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.
Si les unités d'initialisation en miroir sont enfichables à chaud, désactivez 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.