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 redémarrer 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.
Pour activer le contrôle de basculement du cluster :
# cd /opt/ACSLSHA/util # ./acsAgt configure
L'utilitaire vous invite à saisir le nom de l'hôte logique. Vérifiez que l'hôte logique est défini dans le fichier /etc/hosts, et que l'adresse IP correspondante est associée au groupe ipmp défini dans le Configuration du système Solaris pour ACSLS HA. Avant d'exécuter acsAgt configure, utilisez zpool list pour confirmer que acslspool est monté sur le noeud de serveur actuel.
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é d'ACSLS en particulier et du système Solaris en général. 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.
Il est recommandé de définir une stratégie dans la ressource acsls-storage pour réinitialiser le noeud actif lorsque la communication est perdue entre le noeud et le périphérique de disque RAID partagé. Cette action entraîne l'abandon du contrôle par le noeud actif lorsqu'il ne peut pas se connecter au disque, ce qui permet à Solaris Cluster de passer le contrôle à l'autre noeud. Le passage de Failover_mode de SOFT à HARD assure une réinitialisation du noeud actif en cas de perte de communication avec le périphérique de stockage partagé.
Pour afficher la valeur en cours de Failover_mode, exécutez la commande suivante :
# clrs show -v acsls-storage | grep Failover
Failover_mode doit être défini sur HARD comme suit :
# clrs set -p Failover_mode=HARD acsls-storage
Une fois que le contrôle du cluster a été activé, vous pouvez utiliser ACSLS normalement. Démarrez et arrêtez 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 du redémarrage 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.
Si vous craignez que l'opération de maintenance déclenche un basculement de cluster non voulu, suspendez le contrôle du groupe de ressources acsls.
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.
Cette suspension 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 est arrêté. Pour annuler cet état, relancez 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 est inaccessible, le contrôle repasse au noeud actuel. Le cluster tente de monter acslspool et de démarrer les services ACSLS sur ce noeud.
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.
Pour rétablir le fonctionnement d'ACSLS sur un noeud qui était actif avant une mise hors tension contrôlée :
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 lors de la mise hors tension du système. Cette action doit réinitialiser automatiquement les services acsss et reprendre un fonctionnement normal.
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.
Mettez le système sous tension.
Lorsque le menu d'initialisation GRUB apparaît, appuyer sur e (edit).
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.
En mode Edition, ajoutez -x à l'option de multi-initialisation kernel /platform/i86pc/multiboot -x et cliquez sur Retour.
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