9 Fonctionnement du cluster d'ACSLS

Solaris Cluster est conçu pour effectuer une récupération automatique du système dans des scénarios de défaillance grave en transférant le contrôle du fonctionnement d'un noeud de serveur vers le suivant. Mais la plupart des défaillances dans un système Solaris ne requièrent pas un basculement complet du système pour pouvoir récupérer.

Les défaillances impliquant la communication réseau sont gérées silencieusement et rapidement par Solaris IPMP.
Les défaillances système de disques sont gérées silencieusement et automatiquement par Solaris ZFS.
Les défaillances avec une quelconque unité de disque dans la baie de stockage connectée sont récupérées automatiquement par le microprogramme de la baie de stockage. Et lorsque la baie de stockage n'a pas la faculté de récupérer d'une défaillance de disque, Solaris ZFS prend le contrôle pour fournir des E/S de disque ininterrompues vers l'autre unité de la configuration en miroir.
Si un port HBA menant à la baie partagée défaille, Solaris commute automatiquement sur un autre port. De la même manière, si un module de contrôleur sur la baie partagée défaille ou si un câble d'interconnexion est déconnecté, Solaris revient à l'autre chemin connecté à la ressource disque.
Une défaillance dans un chemin de communication avec une bibliothèque est récupérée automatiquement par la logique double TCP/IP dans ACSLS. Et les opérations provenant d'un contrôleur de bibliothèque en défaillance sont récupérées automatiquement par la logique d'ACSLS HA associée à Redundant Electronics (RE) de la bibliothèque.
Si l'un des nombreux processus en cours d'exécution dans ACSLS défaille, le démon d'ACSLS réinitialise instantanément le processus impliqué.
Si le démon d'ACSLS lui-même défaille ou si l'un des services ACSLS restants arrête de fonctionner, l'utilitaire Solaris Service Management Facility (SMF) est là pour réinitialiser immédiatement le service impliqué.

Tous ces scénarios sont gérés rapidement et automatiquement sans l'intervention de Solaris Cluster. Mais si toute autre erreur grave perturbe le fonctionnement d'ACSLS sur le noeud de serveur actif, ACSLS HA donne à Solaris Cluster l'instruction de commuter le contrôle sur l'autre noeud.

Une fois démarré, ACSLS HA sonde le système une fois par minute à la recherche de l'un des évènements suivants :

Perte de communication avec une bibliothèque connectée
Perte de contact réseau avec l'hôte logique d'ACSLS
Perte de contact avec le Listener Port RPC pour les appels du client
Perte de l'accès au système de fichiers d'ACSLS
Etat de maintenance irrécupérable du service acsls SMF

Chacun de ces évènements déclenche un basculement du cluster. Solaris Cluster sait également basculer lorsqu'une condition fatale du système survient sur le noeud de serveur actif.

Démarrage du contrôle de cluster par ACSLS

Pour activer le contrôle de basculement du cluster :

# cd /opt/ACSLSHA/util
# ./start_acslsha.sh -h <logical hostname> -g <IPMP group> -z acslspool

Cette action initie le contrôle du cluster par ACSLS. Solaris Cluster surveille le système et le sonde une fois par minute pour vérifier l'état de santé du système Solaris général et d'ACSLS plus spécifiquement. Toute condition qui est considérée fatale déclenche une action sur l'autre noeud.

Pour vérifier l'état du cluster du groupe de ressources ACSLS :

# clrg status

L'affichage :

Révèle l'état de chaque noeud ;
Identifie le noeud qui est actif ;
Révèle quelle action de basculement est suspendue.

Fonctionnement et maintenance d'ACSLS sous contrôle du cluster

Une fois que le contrôle du cluster a été activé, vous pouvez utiliser ACSLS normalement. Vous pouvez démarrer et arrêter ACSLS à l'aide de l'utilitaire de contrôle acsss par défaut. Avec le contrôle du cluster, un utilisateur démarre et arrête les services ACSLS de la même manière qu'ils démarrent ou arrêtent l'application sur un serveur ACSLS autonome. L'opération est gérée avec ces commandes acsss standard :

acsss enable
acsss disable
acsss db

Le démarrage ou l'arrêt manuel des services acsss avec ces commandes ne fait aucun cas intervenir Solaris Cluster dans l'action de basculement. L'utilisation des commandes de Solaris SMF (comme svcadm) ne fait pas non plus intervenir Cluster. Lors de l'abandon ou de l'interruption des services acsss, c'est SMF et pas Cluster qui est essentiellement responsable de la réinitialisation de ces services.

Solaris Cluster intervient uniquement pour rétablir le contrôle sur le noeud adjacent dans les circonstances suivantes :

Communication perdue avec le système de fichiers d'ACSLS
Communication perdue avec tous les ports Ethernet redondants publics
Communication perdue et irrécupérable avec une bibliothèque spécifiée

Suspension du contrôle de cluster

Si vous craignez que votre activité de maintenance risque de déclencher un basculement de cluster non voulu, vous pouvez suspendre le contrôle du groupe de ressources ascsls.

Pour suspendre le contrôle du cluster :

# clrg suspend acsls-rg

Pendant que le groupe de ressources est suspendu, Solaris Cluster ne tente pas de passer le contrôle au noeud adjacent, quelles que soient les conditions qui pourraient déclencher une telle action si la situation était différente.

Cela vous permet d'effectuer des réparations plus invasives sur le système, même si la production de la bibliothèque fonctionne normalement.

Si le noeud actif se réinitialise pendant le mode de suspension, il ne monte pas acslspool après la réinitialisation, et le fonctionnement d'ACSLS sera arrêté. Pour annuler cet état, vous devez relancer le contrôle du cluster.

Pour relancer le contrôle du cluster :

# clrg resume acsls-rg

Si la ressource de disque partagé est montée sur le noeud actuel, le fonctionnement reprend normalement. Mais, une fois activé, si Solaris Cluster découvre que zpool n'est pas monté, il passe immédiatement le contrôle au noeud adjacent. Si le noeud adjacent n'est pas accessible, le contrôle revient au noeud actuel, et Cluster tente de monter acslspool et démarre les services ACSLS sur ce noeud.

Mise hors tension du cluster ACSLS HA

La procédure suivante présente une séquence de mise hors tension sûre lorsqu'il est nécessaire de mettre le système ACSLS HA hors tension

Déterminez le noeud actif dans le cluster.
```
# clrg status
```
Cherchez le noeud en ligne.
Ouvrez une session comme utilisateur root sur le noeud actif et arrêtez le contrôle de Solaris Cluster du groupe de ressources ACSLS.
```
# clrg suspend acsls-rg
```
Passez à l'utilisateur acsss et arrêtez les services acsss :
```
# su - acsss
$ acsss shutdown
```
Fermez la session acsss et mettez progressivement le noeud hors tension.
```
$ exit
# init 5
```
Ouvrez une session sur l'autre noeud et mettez-le hors tension en utilisant init 5.
Mettez hors tension la baie de disques partagés en utilisation l'interrupteur Marche/Arrêt physique.

Mise sous tension d'un système de cluster ACSLS suspendu

Pour rétablir le fonctionnement d'ACSLS sur un noeud qui était actif avant une mise hors tension contrôlée, utilisez la procédure suivante.

Mettez sous tension les deux noeuds à l'aide de l'interrupteur Marche/Arrêt physique local ou à distance à l'aide du Sun Integrated Lights Out Manager.
Mettez sous tension la baie de disques partagés.
Ouvrez une session sur l'un des noeuds en tant que root.
Si vous tentez d'ouvrir une session en tant que acsss ou d'afficher la liste du répertoire $ACS_HOME, vous verrez que les ressources de disques partagées ne sont montées sur aucun des noeuds. Pour reprendre la surveillance du cluster, exécutez la commande suivante :
```
# clrg resume acsls-rg
```
Avec cette action, Solaris Cluster monte le disque partagé sur le noeud qui était actif lorsque vous avez mis le système hors tension. Cette action doit réinitialiser automatiquement les services acsss et le fonctionnement normal doit reprendre.

Création d'un cluster à un seul noeud

Il peut y avoir des situations où ACSLS doit continuer de fonctionner sur un noeud à partir d'un environnement à serveur autonome pendant que l'autre noeud subit une intervention technique. C'est par exemple cas en cas de maintenance du matériel, d'une mise à niveau du système d'exploitation ou d'une mise à niveau vers Solaris Cluster.

Les procédures suivantes permettent de créer un serveur ACSLS autonome.

Redémarrez le noeud souhaité en mode non-cluster.
```
# reboot -- -x
```
Pour l'initialisation en mode non-cluster depuis Open Boot Prom (OPB) sur des serveurs SPARC :
```
ok: boot -x
```
sur les serveurs X86, il est nécessaire d'éditer le menu d'initialisation GRUB.
1. Mettez le système sous tension.
2. Lorsque le menu d'initialisation GRUB apparaît, appuyer sur e (edit).
3. A partir du sous-menu, sélectionnez kernel /platform/i86pc/multiboot au moyen des touches de direction. Quand il est sélectionné, appuyez sur e.
4. En mode Edition, ajoutez -x à l'option de multi-initialisation kernel /platform/i86pc/multiboot -x et cliquez sur Retour.
5. Avec l'option de multi-initialisation -x sélectionnée, appuyez sur b pour initialiser avec cette option.
Une fois le cycle d'initialisation terminé, ouvrez une session en tant que root et importez ACSLS Z-pool.
```
# zpool import acslspool
```
Utilisez l'option -f (force) si nécessaire lorsque les ressources de disques restent affectées à l'autre noeud.
```
# zpool import -f acslspool
```
Activez les services acsss.
```
# su - acsss
$ acsss enable
```