Le présent chapitre fournit des directives sur les sujets suivants.
"Administration du temps dans les configurations de Sun Cluster"
"Administration de la base de données de configuration de grappe "
La commande scadmin startcluster attribue le statut de premier membre à un noeud de la grappe. Celui-ci devient le noeud 0 de la grappe. L'exécution de la seule commande scadmin startnode démarre les autres noeuds de Sun Cluster. Cette commande démarre les programmes nécessaires à la synchronisation multi-noeuds et coordonne l'intégration des autres noeuds au premier noeud (si Sun Cluster est déjà en cours d'exécution sur celui-ci). Vous pouvez supprimer des noeuds de la grappe en y exécutant la commande scadmin avec l'option stopnode.
Attribuez le statut de premier membre de grappe au noeud local. Pour que la commande scadmin startcluster fonctionne correctement, le noeud local doit être un noeud configuré de la grappe. Cette commande doit avoir été exécutée avec succès avant que d'autres noeuds puissent s'intégrer à la grappe. Si, pour une raison quelconque, le noeud local abandonne la procédure pendant l'intégration des autres noeuds à la grappe, il peut en résulter une altération de la BCG. Dans un tel cas, restaurez la BCG en suivant la procédure de la section "Comment restaurer la BCG".
Pour faire du noeud local un noeud configuré de la grappe, voir "Ajout et suppression de noeuds de grappe".
Il est important qu'aucun autre noeud n'exécute le logiciel de grappes à ce moment. Si le noeud local détecte un autre noeud de grappe actif, il abandonne.
Démarrez le premier noeud de la grappe avec la commande scadmin(1M).
# scadmin startcluster noeud_local nom_grappe |
L'option startcluster ne peut fonctionner si noeud_local ne correspond pas au nom du noeud sur lequel la commande est exécutée. Pour de plus amples renseignements, consultez la page de manuel scadmin(1M).
Par exemple :
phys-hahost1# scadmin startcluster phys-hahost1 grappehd Le noeud spécifié est phys-hahost1 La grappe spécifiée est grappehd ======================= AVERTISSEMENT ======================= = Création d'une nouvelle grappe = ============================================================= Vous tentez de démarrer le noeud de grappe "phys-hahost1" comme le seul noeud actif dans une nouvelle grappe. Il est important qu'aucun autre noeud de grappe ne soit actif à ce moment. Si ce noeud reçoit des informations des autres noeuds de la grappe, il abandonne. Les autres noeuds ne peuvent intégrer la grappe qu'à la fin de l'exécution de la commande. La présence de plus d'une grappe active peut provoquer l'altération des données. Voulez-vous continuer ? [o,n,?] y |
Si vous recevez le message d'erreur reconfig.4013, c'est qu'il y a déjà un noeud dans la grappe ou qu'un autre noeud est cours d'arrêt. Exécutez la commande get_node_status(1M) sur le noeud qui pourrait être actif pour en connaître l'état.
Ajoutez tous les autres noeuds à la grappe.
Exécutez la commande ci-dessous sur tous les autres noeuds, séquentiellement.
# scadmin startnode |
Si vous recevez le message d'erreur reconfig.4015 ci-après, il se peut qu'il n'y ait pas de grappe existante. Redémarrez la grappe avec la commande scadmin startcluster noeud_local.
SUNWcluster.clustd.reconf.4015 "Abandon--il n'y a pas de grappe existante ou intacte à laquelle intégrer les noeuds." |
Ce message peut également provenir d'une défaillance de partition ou de noeud. (Par exemple, un troisième noeud tente de s'intégrer à une grappe à deux noeuds lorsque l'un d'eux échoue.) Dans un tel cas, attendez la fin des défaillances. S'il y a lieu, corrigez les problèmes et tentez ensuite de réintégrer le noeud à la grappe.
S'il manque un des modules requis, la commande échoue et la console affiche un message semblable à celui-ci :
Nom de grappe par défaut de haclust Erreur : module SC 'SUNWccm' non installé ! Abandon du démarrage de la grappe. |
Pour des informations au sujet de l'installation des modules Sun Cluster, consultez le Sun Cluster 2.2 Software Installation Guide.
Pour mettre un noeud dans n'importe quel mode à l'exception du mode multi-utilisateurs, ou pour arrêter ou réinitialiser un noeud, vous devez arrêter le moniteur d'appartenance de Sun Cluster. Utilisez alors la méthode d'administration préférée de votre site pour assurer la maintenance subséquente du noeud.
Pour arrêter la grappe, vous devez arrêter également le moniteur d'appartenance sur tous les noeuds de la grappe. Pour ce faire, exécutez simultanément la commande scadmin stopnode sur tous les noeuds.
Vous ne pouvez arrêter le moniteur d'appartenance que lorsque le noeud local Sun Cluster ne possède aucun hôte logique.
Pour arrêter la moniteur d'appartenance sur un noeud, commutez le ou les hôtes logiques vers un autre noeud avec la commande haswitch(1M), puis exécutez la commande suivante :
phys-hahost1# haswitch hôte_destinationhôte_logique phys-hahost1# scadmin stopnode |
Si le noeud possède un hôte logique lorsque la commande scadmin stopnode est exécutée, il en perd la propriété au profit d'un autre noeud en mesure de maîtriser cet hôte avant l'arrêt du moniteur d'appartenance. Si le maître de relève de l'hôte logique est inactif, la commande scadmin stopnode interrompt les services de données en plus d'arrêter le moniteur d'appartenance.
Une fois la commande scadmin stopnode exécutée, Sun Cluster demeure arrêté jusqu'à l'exécution de la commande scadmin startnode, même après plusieurs réinitialisations du système.
La commande scadmin stopnode retire le noeud de la grappe. Si aucune autre défaillance ne se produit simultanément, vous pouvez arrêter autant de noeuds que vous le désirez, sans perdre le quorum au niveau des noeuds restants. (L'absence de quorum provoque l'arrêt de toute la grappe.)
Si vous arrêtez un noeud pour réparer un disque, vous devez également préparer le disque d'initialisation ou de données en suivant les procédures relatives aux disques d'initialisation du Chapitre 10, ou celles qui portent sur les disques de données dans la documentation fournie avec votre gestionnaire de volumes.
Vous devrez peut-être arrêter un ou plusieurs noeuds de Sun Cluster pour procéder à la maintenance matérielle, comme l'ajout ou la suppression de cartes SBus. Les sections suivantes décrivent la procédure requise pour arrêter un seul noeud ou la grappe en entier.
Dans une grappe comportant deux noeuds ou davantage et un système de stockage directement connecté, un problème peut se produire si le dernier noeud de la grappe subit une erreur grave ou quitte la grappe de façon inhabituelle (sans exécuter la transition stopnode). Dans un tel cas, tous les noeuds sont retirés de la grappe et celle-ci n'existe plus, mais comme le dernier noeud s'est retiré de manière inhabituelle, il tient toujours le verrouillage de noeud. Lors d'un appel ultérieur de la commande scadmin startcluster, celle-ci ne pourra obtenir le verrouillage de noeud. Pour résoudre ce problème, effacez manuellement le verrouillage de noeud avant de redémarrer la grappe, à l'aide de la procédure "Comment supprimer un verrouillage de noeud après une erreur grave de grappe".
S'il n'est pas nécessaire que les données demeurent disponibles, placez les hôtes logiques (groupes de disques) en mode de maintenance.
phys-hahost2# haswitch -m hôte_logique |
Pour de plus amples renseignements, consultez la page de manuel haswitch(1M).
L'arrêt d'un noeud Sun Cluster peut être obtenu avec la commande halt(1M) ; il s'ensuit une récupération des services de l'hôte logique sur le noeud de relève. Cependant, le résultat de la commande halt(1M) peut créer une confusion au niveau du noeud. L'exécution de la commande haswitch(1M) constitue une méthode de commutation de la propriété des hôtes logiques plus fiable.
Arrêtez Sun Cluster sur un noeud sans arrêter les services en cours d'exécution sur les autres noeuds de la grappe.
phys-hahost1# scadmin stopnode |
Lorsque vous arrêtez un noeud, le message d'erreur suivant peut s'afficher : in.rdiscd[517] : setsockopt (IP_DROP_MEMBERSHIP) : Impossible d'attribuer l'adresse demandée. Cette erreur est due à un problème de synchronisation entre le démon in.rdiscd et le module IP. Elle est sans gravité et peut être ignorée.
Arrêtez le noeud.
phys-hahost1# halt |
Le noeud peut maintenant être réparé.
L'arrêt de tous les noeuds d'une configuration Sun Cluster peut s'avérer nécessaire lorsque l'environnement présente des conditions dangereuses comme une panne du système de refroidissement ou un orage violent.
Arrêtez simultanément le moniteur d'appartenance sur tous les noeuds avec la commande scadmin(1M).
Exécutez cette commande sur la console de chaque noeud de la grappe. Laissez chaque noeud quitter la grappe et attendez que les noeuds restants se soient reconfigurés complètement avant d'exécuter la commande sur le noeud suivant
phys-hahost1# scadmin stopnode ... |
Arrêtez tous les noeuds avec la commande halt(1M).
phys-hahost1# halt ... |
Arrêtez un noeud Sun Cluster quelconque avec la commande halt(1M) ou uadmin(1M).
Si le moniteur d'appartenance est en cours d'exécution à l'arrêt d'un noeud, il y a de fortes chances que ce dernier provoque un "dépassement du délai imparti". Le message suivant apparaît alors :
panic[cpu9]/thread=0x50f939e0 : Dépassement du délai imparti - unité |
Une telle situation peut être évitée en arrêtant le moniteur d'appartenance avant le noeud. Pour de plus amples renseignements à ce sujet, voyez la procédure "Comment arrêter Sun Cluster sur tous les noeuds".
Dans une grappe comportant deux noeuds ou davantage et un système de stockage directement connecté, un problème peut se produire si le dernier noeud de la grappe subit une erreur grave ou quitte la grappe de façon inhabituelle (sans exécuter la transition stopnode). Dans un tel cas, tous les noeuds sont retirés de la grappe et celle-ci n'existe plus, mais comme le dernier noeud s'est retiré de manière inhabituelle, il tient toujours le verrouillage de noeud. Lors d'un appel ultérieur de la commande scadmin startcluster, celle-ci ne pourra obtenir le verrouillage de noeud.
Pour contourner ce problème, effacez manuellement le verrouillage de noeud avant de redémarrer la grappe. Utilisez la procédure suivante pour effacer manuellement le verrouillage de noeud et redémarrer la grappe, après fin anormale de celle-ci.
En tant que root (superutilisateur), affichez la configuration de la grappe.
# scconf nom_grappe -p |
Repérez cette ligne dans la sortie :
nom_grappe Locking TC/SSP, port : A.B.C.D, E |
Dans le cas d'un verrouillage de noeud sur un concentrateur de terminaux (CT), procédez comme suit.
Etablissez une connexion telnet au concentrateur de terminaux nom-tc.
$ telnet nom_ct Essai de 192.9.75.51... Connecté à nom_ct. Le caractère d'échappement est `^]'. |
Appuyez sur Entrée pour continuer.
Précisez cli (interface de ligne de commande).
Entrez le nom de port ou le numéro d'Annexe : cli |
Connectez-vous comme root (superutilisateur).
Exécutez la commande admin.
annex# admin |
Réinitialisez le port E.
admin : reset E |
Mettez fin à la connexion telnet.
annex# hangup |
Passez à Étape 4.
Dans le cas d'un verrouillage de noeud sur un processeur de services système (PSS), suivez les étapes ci-dessous.
Connectez-vous au PSS.
$ telnet nom_pss |
Ouvrez une session en tant qu'utilisateur pss.
Affichez les informations concernant le fichier nom_grappe.lock à l'aide de la commande suivante. (Ce fichier est un lien symbolique à /proc/csh.pid.)
$ ls -l /var/tmp/nom_grappe.lock |
Recherchez le processus csh.pid.
$ ps -ef | grep csh.pid |
Si le processus csh.pid figure dans le résultat ps -ef, interrompez ce processus à l'aide de la commande suivante.
$ kill -9 csh.pid |
Supprimez le fichier nom_grappe.lock.
$ rm -f /var/tmp/nom_grappe.lock |
Quittez le PSS.
Redémarrez la grappe.
$ scadmin startcluster |
Les instances de serveur de base de données ne peuvent s'exécuter sur un noeud que si vous avez appelé l'option startnode et que le noeud a été intégré correctement à la grappe. Toutes les instances de base de données doivent être arrêtées avant d'appeler l'option stopnode.
Si vous utilisez Oracle7 Parallel Server, Oracle8 Parallel Server ou Informix XPS, consultez la documentation du produit correspondant pour connaître les détails de la procédure d'arrêt.
Si vous utilisez la commande stopnode pendant que l'instance Oracle7 ou Oracle8 est en cours d'exécution sur le noeud, stopnode bloque, et le message suivant apparaît sur la console :
ID[vxclust] : arrêt : attente de la fin de l'exécution des applications |
Il faut arrêter l'instance Oracle7 ou Oracle8 pour que la commande stopnode s'exécute correctement.
L'exécution de la commande stopnode pendant que l'instance Informix-Online XPS est exécutée sur le noeud provoque le blocage de la base de données et la rend inutilisable.
La commande haswitch(1M) permet de commuter les hôtes logiques spécifiés (ainsi que les groupes de disques, services de données et les adresses IP logiques connexes) vers le noeud spécifié par l'hôte cible. Par exemple, la commande suivante commute les hôtes logiques hahost1 et hahost2 vers phys-hahost1, qui en devient le maître.
# haswitch # haswitch hahost_phys1 hahost_phys2 |
Si l'hôte logique possède plus d'un service de données configuré, vous ne pouvez commuter qu'un seul service ou sous-ensemble de services. Vous ne pouvez que commuter tous les services de données vers l'hôte logique.
S'il se produit une relève ou une commutation quand le système de fichiers de l'hôte logique est occupé, ce dernier n'est pris en relève que partiellement ; certains des disques du groupe demeurent sur l'hôte physique cible initial. Ne tentez pas d'effectuer une commutation si le système de fichiers d'un hôte logique est occupé. En outre, n'accédez localement au système de fichiers d'aucun hôte, car le verrouillage de fichiers ne fonctionne pas correctement s'il y a à la fois verrouillage NFS et verrouillage local.
L'hôte cible et le maître actuel de l'hôte logique doivent appartenir à la grappe pour que la commande s'exécute correctement. Sinon, elle échoue.
Dans le cas des grappes de services de données HD, vous pouvez configurer la commutation automatique pour l'éventualité suivante : un noeud échoue, les hôtes logiques dont il est le maître sont commutés vers un autre noeud, et le noeud défectueux est ramené ensuite dans la grappe. Le maître par défaut de ces hôtes logiques en reprend automatiquement possession, à moins que vous ne les ayez configurés pour qu'ils demeurent sous la maîtrise de l'hôte vers lequel ils ont été commutés.
Pour empêcher la commutation automatique d'un hôte logique vers son maître par défaut, utilisez l'option -m de la commande scconf(1M). Pour de plus amples renseignements, consultez la page de manuel scconf(1M).
Pour désactiver la commutation automatique d'un hôte logique, il suffit d'exécuter la commande scconf(1M) sur un seul noeud actif appartenant à la grappe.
# scconf nom_grappe -L hôte_logique -n noeud1,noeud2 -g dg1 -i qe0,qe0,logaddr1 -m |
Le mode maintenance s'avère utile avec certaines tâches administratives au niveau des systèmes de fichiers et des groupes de disques. Pour activer le mode maintenance des groupes de disques d'un hôte logique, utilisez l'option -m de la commande haswitch(1M).
Contrairement aux autres types de propriété d'un hôte logique, le mode maintenance demeure activé après la réinitialisation des noeuds.
Dans l'exemple suivant, la commande active le mode maintenance de l'hôte logique hahost1.
phys-hahost2# haswitch -m hahost1 |
Cette commande interrompt les services de données associés à hahost1 sur le noeud Sun Cluster qui est le propriétaire actuel du groupe de disques, et arrête également les programmes de surveillance des défaillances associés à hahost1 sur tous les noeuds de Sun Cluster. La commande exécute le démontage (umount(1M)) de tous les systèmes de fichiers de Sun Cluster présents dans l'hôte logique. La propriété du groupe de disques associée à cet hôte est libérée.
Il est possible d'exécuter cette commande sur n'importe quel hôte, peu importe le propriétaire actuel de l'hôte logique et du groupe de disques.
Pour désactiver le mode maintenance d'un hôte logique, effectuez une commutation spécifiant l'hôte physique qui deviendra propriétaire du groupe de disques. Dans l'exemple ci-dessous, la commande désactive le mode maintenance de hahost1 :
phys-hahost1# haswitch phys-hahost1 hahost1 |
Les tentatives des sous-ensembles de membres de grappe de demeurer actifs dans cette grappe peuvent provoquer des défaillances multiples (y compris le partitionnement du réseau). Normalement, ces sous-ensembles ont perdu, en tout ou en partie, leur capacité de communiquer entre eux. Dans ce cas, le logiciel tente de réduire le nombre de grappes valides à une seule. Pour y parvenir, il provoque l'abandon d'une partie ou de l'ensemble des noeuds. Voyons sur quels critères le logiciel fonde ses décisions à cet égard.
Le critère de quorum est un sous-ensemble comportant au moins la moitié des membres de l'ensemble des noeuds de grappe original (et non les seuls noeuds configurés). Si le sous-ensemble n'atteint pas le critère de quorum, les noeuds de ce sous-ensemble provoquent eux-mêmes leur abandon, et un message d'erreur reconfig.4014 apparaît. La présence d'une partition au niveau du réseau ou d'une défaillance simultanée de plus de la moitié des noeuds de la grappe peuvent être à l'origine du non-respect du critère de quorum.
Les grappes valides ne contiennent que des noeuds capables de communiquer entre eux sur des réseaux privés.
Prenons l'exemple d'une grappe à quatre noeuds qui se partitionne en deux sous-ensembles : on retrouve un seul noeud dans le premier sous-ensemble, alors que le second en comporte trois. Les deux sous-ensembles tentent d'atteindre le quorum requis. Comme le premier sous-ensemble ne possède qu'un seul noeud (sur les quatre d'origine), il ne respecte pas le critère de quorum. Par conséquent, le noeud du premier sous-ensemble s'arrête. Quant au second noeud, il possède trois des quatre noeuds originaux. Le quorum est atteint, et ce sous-ensemble demeure actif.
Prenons un autre exemple, celui d'une grappe à deux noeuds avec périphérique de quorum. Si une telle configuration comporte une partition, alors le critère de quorum est respecté avec la présence d'un noeud et du périphérique de quorum, et la grappe demeure active.
Une partition de double contrôle survient lorsqu'un sous-ensemble contient exactement la moitié des membres de la grappe. (Il n'y a pas de partition de double contrôle dans le cas d'une grappe à deux noeuds avec périphérique de quorum.) Au cours de la première installation de Sun Cluster, vous deviez décider du type de récupération privilégiée en cas de partition de double contrôle. Vous deviez choisir entre Demander et Sélectionner. Si vous avez opté pour Demander, le système vous demande de sélectionner les noeuds qui doivent demeurer actifs lorsque se produit une partition de double contrôle. Avec l'option select, le système sélectionne automatiquement les membres de la grappe qui demeurent actifs.
Si vous aviez choisi la politique de sélection automatique pour traiter les partitions de double contrôle, vous deviez choisir à nouveau entre les options ID de noeud le plus bas et ID de noeud le plus élevé. Si vous avez sélectionné l'option ID de noeud le plus bas, le sous-ensemble contenant le noeud dont l'ID est le plus bas devient la nouvelle grappe. Si vous avez sélectionné l'option ID de noeud le plus élevé, le sous-ensemble contenant le noeud dont l'ID est le plus élevé devient la nouvelle grappe. Pour de plus amples renseignements, consultez la section portant sur les procédures d'installation du Sun Cluster 2.2 Software Installation Guide.
Quelle que soit l'option choisie, vous devez arrêter manuellement les noeuds dans tous les autres sous-ensembles.
Si vous n'avez pas sélectionné une politique de sélection automatique ou si le système vous demande des précisions lorsque survient la partition, le message d'erreur suivant apparaît :
SUNWcluster.clustd.reconf.3010 "*** EXECUTER LA COMMANDE ABORTPARTITION OU CONTINUEPARTITION *** Grappe proposée : xxx Noeuds inatteignables : yyy" |
De plus, un message semblable à celui-ci apparaît toutes les dix secondes sur la console :
*** EXECUTER LA COMMANDE ISSUE ABORTPARTITION OU CONTINUEPARTITION *** Si les noeuds inatteignables se sont formés en grappe, exécutez ABORTPARTITION. (scadmin abortpartition <noeud_local> <nom_grappe>) Vous pouvez autoriser la formation de la grappe proposée avec la commande CONTINUEPARTITION. (scadmin continuepartition <noeud_local> <nom_grappe>) Partition de grappe proposée : 0 Noeuds inatteignables : 1 |
Si vous n'avez pas choisi une sélection automatique, effectuez la procédure suivante pour sélectionner une nouvelle grappe.
Pour redémarrer la grappe après une défaillance de double contrôle, vous devez attendre que le noeud arrêté soit complètement réactivé (ce délai provient de la reconfiguration ou de la réinitialisation du noeud) avant de le ramener dans la grappe avec la commande scadmin startnode.
Décidez du sous-ensemble qui formera la nouvelle grappe. Exécutez la commande suivante sur un noeud du sous-ensemble qui doit être abandonné.
# scadmin abortpartition |
Lorsque vous exécutez la commande abortpartition sur un noeud, le moniteur d'appartenance à une grappe (MAG) reproduit cette commande sur l'ensemble des noeuds de la partition concernée. En conséquence, tous les noeuds de la partition recevant la commande sont abandonnés. Au besoin, procédez à l'abandon manuel des noeuds que le MAG n'a pas réussi à contacter. Pour ce faire, exécutez la commande scadmin abortpartition sur les noeuds toujours actifs.
Exécutez la commande suivante sur un noeud du sous-ensemble qui doit demeurer actif :
# scadmin continuepartition |
Si la nouvelle grappe subit elle aussi une défaillance, un processus de reconfiguration supplémentaire s'enclenche. En tous temps, il n'y a qu'une seule grappe active.
L'enregistrement des messages d'erreur des logiciels Solaris et Sun Cluster s'effectue dans le fichier /var/adm/messages et il existe un risque de saturation du système /var. La saturation du système de fichiers /var pendant l'exécution du noeud ne change rien à l'état de ce noeud. Par contre, il se peut que vous ne puissiez plus vous y connecter. Si le noeud tombe en panne, Sun Cluster ne pourra pas démarrer, et aucune connexion ne sera possible. Dans ce cas, vous devez réinitialiser le système en mode mono-utilisateur (commande (boot -s).
Si le noeud signale que le système de fichier /var est saturé et qu'il continue d'exécuter les services Sun Cluster, effectuez les étapes de la procédure ci-dessous.
Dans cet exemple, phys-hahost1 comporte un système de fichier /var saturé.
Effectuez une commutation.
Supprimez tous les hôtes logiques du noeud d'où provient le problème.
phys-hahost2# haswitch phys-hahost2 hahost1 hahost2 |
Supprimez l'appartenance du noeud à la grappe.
S'il y a une connexion active avec phys-hahost1, exécutez la commande suivante :
phys-hahost1 scadmin stopnode |
S'il n'y a pas de connexion active avec phys-hahost1, arrêtez le noeud.
Réinitialisez le noeud en mode mono-utilisateur.
(0) ok boot -s INIT : MODE MONO-UTILISATEUR Appuyer sur Ctrl-D pour démarrer normalement (ou donner le mot de passe de root (superutilisateur) pour la maintenance système) : mot_passe_superutilisateur Activation du mode maintenance système Sun Microsystems Inc. SunOS 5.6 générique août 1997 |
Procédez comme à l'habitude pour effacer le contenu du système de fichiers saturé.
Une fois le système de fichiers vidé, passez en mode multi-utilisateurs.
# exit |
Exécutez la commande scadmin startnode pour réintégrer le noeud à la configuration.
# scadmin startnode |
Nous vous suggérons d'utiliser le protocole NTP (Network Time Protocol) fourni avec l'environnement d'exploitation Solaris pour préserver la synchronisation temporelle entre les noeuds de grappe.
Un administrateur ne peut régler l'heure des noeuds d'une configuration Sun Cluster. Il ne faut jamais utiliser les commandes date(1), rdate(1M) ou xntpdate(1M) pour régler l'heure.
Dans l'environnement Sun Cluster, les noeuds de grappe peuvent fonctionner en tant que clients NTP. Pour utiliser le protocole NTP, un serveur NTP doit être installé et configuré hors de la grappe ; il est impossible de configurer les noeuds de grappe en tant que serveurs NTP. Consultez la page de manuel xntpd(1M) pour obtenir des informations sur les clients et serveurs NTP.
Si vous utilisez des noeuds de grappe en tant que clients NTP, assurez-vous qu'il n'y a pas d'entrées crontab(1) appelant la commande ntpdate(1M). Il est plus prudent d'exécuter la commande xntpd(1M) sur les clients. De cette façon, on conserve la synchronisation des horloges sans compenser les écarts par des corrections importantes.
Effectuez les étapes ci-dessous lorsqu'un noeud éprouve une panne de matériel et qu'il doit être remplacé.
Dans cette procédure, on suppose que le disque racine du noeud défectueux est toujours fonctionnel et qu'il peut encore servir. Si le disque racine n'est pas mis en miroir, communiquez avec un représentant local du service à la clientèle de Sun Enterprise ou avec le fournisseur de service agréé de votre région.
Si le noeud défectueux n'est pas fonctionnel, passez à Étape 5.
Si vous utilisez une configuration de base de données parallèle, arrêtez la base de données.
Consultez la documentation relative à vos services de données. La commande scadmin stopnode ferme automatiquement toutes les applications HD.
Ouvrez la fenêtre de terminal avec la console de grappe.
En tant que root (superutilisateur), exécutez la commande ci-dessous dans la fenêtre de terminal.
Cette commande supprime le noeud de la grappe, ferme le logiciel Sun Cluster et désactive le gestionnaire de volumes sur ce noeud.
# scadmin stopnode |
Arrêtez le système d'exploitation du noeud.
Consultez le Guide d'administration Solaris à ce sujet.
Mettez le noeud hors tension.
Pour de plus amples renseignements, consultez le manuel d'entretien de l'équipement concerné.
Ne touchez pas aux câbles du noeud défectueux pour l'instant.
Retirez le disque d'initialisation du noeud défectueux.
Pour de plus amples renseignements, consultez le manuel d'entretien de l'équipement concerné.
Placez le disque d'initialisation au même emplacement dans le nouveau noeud.
L'adresse d'accès du disque racine doit demeurer la même. Pour de plus amples renseignements, consultez le manuel d'entretien de l'équipement concerné.
Assurez-vous que l'adresse IP du nouveau noeud est la même que celle du système défectueux. Il peut s'avérer nécessaire de modifier les serveurs d'initialisation ou les serveurs arp pour rétablir la correspondance entre l'adresse IP et la nouvelle adresse Ethernet. Pour de plus amples renseignements à ce sujet, consultez le Guide d'installation et de configuration NIS+ et DNS.
Mettez le nouveau noeud sous tension.
Pour de plus amples renseignements, consultez le manuel d'entretien de l'équipement concerné.
Si le noeud s'initialise automatiquement, arrêtez le système d'exploitation et accédez au moniteur de mémoire morte programmable (PROM) OpenBoot.
Pour de plus amples renseignements, consultez la page de manuel shutdown(1M).
Assurez-vous que chaque ID des initiateurs SCSI est correctement configurée.
Reportez-vous au Chapitre 4 du Sun Cluster 2.2 Hardware Site Preparation, Planning, and Installation Guide dans laquelle vous trouverez la procédure détaillée de configuration des ID des initiateurs SCSI.
Mettez le nouveau noeud hors tension.
Pour de plus amples renseignements, consultez le manuel d'entretien de l'équipement concerné.
Dans le noeud survivant qui partage les disques multihôtes avec le noeud défectueux, détachez tous les disques dans une unité d'expansion de disque attachée au noeud défectueux.
Pour de plus amples renseignements, consultez le manuel d'entretien de l'équipement concerné.
Mettez l'unité d'expansion de disque hors tension.
Pour de plus amples renseignements, consultez le manuel d'entretien de l'équipement concerné.
Pendant que vous remplacez le noeud défectueux, des messages semblables à ceux-ci peuvent apparaître sur la console du système. Ne tenez pas compte de ces messages, puisqu'ils ne signalent pas nécessairement un problème.
Nov 3 17:44:00 updb10a unix : AVERTISSEMENT : /sbus@1f,0/SUNW,fas@0,8800000/sd@2,0 (sd17) : 3 nov 17:44:00 updb10a unix : Echec du transport SCSI : motif : 'incomplet' : réessayer \ commande 3 nov 17:44:03 updb10a unix : AVERTISSEMENT : /sbus@1f,0/SUNW,fas@0,8800000/sd@2,0 (sd17) : 3 nov 17:44:03 updb10a unix : le disque ne réagit pas à la sélection |
Débranchez le câble SCSI du noeud défectueux et connectez-le sur la fente correspondante du nouveau noeud.
Pour de plus amples renseignements, consultez le manuel d'entretien de l'équipement concerné.
Mettez l'unité d'expansion de disque sous tension.
Pour de plus amples renseignements, consultez le manuel d'entretien de l'équipement concerné.
Attachez de nouveau tous les disques détachés à Étape 12.
Pour de plus amples renseignements, consultez le manuel d'entretien de l'équipement concerné.
Attendez la fin de la récupération sur tous les volumes de l'unité d'expansion de disque avant de détacher l'unité correspondante.
Votre gestionnaire de volumes vous permet de déterminer le moment où s'est produite la récupération des volumes.
Répétez les Étape 12 à Étape 17 pour chacune des unités d'expansion de disque restantes.
Mettez le nouveau noeud (le noeud remplacé) sous tension.
Pour de plus amples renseignements, consultez le manuel d'entretien de l'équipement concerné.
Réinitialisez le noeud et attendez que le système redevienne actif.
<#0> boot |
Déterminez l'adresse Ethernet du nouveau noeud (le noeud remplacé).
# /usr/sbin/arp nodename |
Déterminez l'ID du nouveau noeud.
En procédant par élimination, déterminez le noeud ne faisant pas partie de la grappe. Les ID de noeuds sont énumérées par ordre croissant à partir du noeud 0.
# get_node_status sc : inclus dans la grappe en cours d'exécution ID de noeud : 0 appartenance : 0 interconnexion0 : inconnue interconnexion1 : inconnue type_gv : vxvm vm_on_node : maître gv : actif b_données : inactive |
Signalez la nouvelle adresse Ethernet (du nouveau noeud) au système de grappes en exécutant la commande suivante sur tous les noeuds de la grappe :
# scconf nom_grappe -N id_noeud adresse_ethernet_hôte |
Toujours selon l'exemple de Étape 22, l'ID du noeud est 1 :
# scconf nom_grappe -N 1 adresse_ethernet_hôte |
Démarrez le nouveau noeud.
# scadmin startnode |
Si vous utilisez une configuration de base de données parallèle, redémarrez la base de données.
Consultez la documentation relative à vos services de données. Les commandes scadmin startcluster et scadmin startnode démarrent automatiquement toutes les applications HA.
Il n'est pas nécessaire que le concentrateur de terminaux soit fonctionnel pour que la grappe demeure active. Une défaillance du concentrateur n'a aucune incidence sur le fonctionnement de la grappe.
Vous pouvez remplacer un concentrateur de terminaux défectueux sans influencer le fonctionnement de la grappe. Si le nom, l'adresse IP et le mot de passe du concentrateur de terminaux de remplacement sont identiques à ceux de l'original, il n'est pas nécessaire d'exécuter les commandes sur les noeuds. Il suffit de brancher le nouveau concentrateur de terminaux pour qu'il fonctionne normalement.
Par contre, si le nom, l'adresse IP ou le mot de passe du nouveau concentrateur de terminaux ne sont pas les mêmes, exécutez la commande scconf(1M) comme le décrit la "Modification des informations TC/PSS" pour modifier ces données dans la base de données de grappe. Le fonctionnement de la grappe en cours d'exécution n'en sera pas affecté.
La commande ccdadm(1M) permet de gérer la base de données de configuration de grappe (BCG). Pour de plus amples renseignements, consultez la page de manuel ccdadm(1M).
En tant que root (superutilisateur), vous pouvez exécuter la commande ccdadm(1M) à partir de n'importe quel noeud actif. Cette commande met à jour tous les noeuds de la grappe.
Il est conseillé de contrôler point par point la BCG en ajoutant l'option -c (points de contrôle) à la commande ccdadm(1M) après chaque mise à jour de la configuration de grappe. La structure de Sun Cluster fait un usage intensif de la BCG pour stocker les données de configuration liées aux hôtes logiques et aux services de données HD. La BCG sert également à stocker les données de configuration de l'adaptateur réseau utilisées pour la gestion de réseau privé (GRP). Dès que la configuration HD ou GRP de la grappe est modifiée, nous vous suggérons fortement d'archiver un instantané valide de la BCG à jour avec l'option -c à titre d'assurance contre tout problème pouvant résulter d'une défaillance ultérieure. Il n'y pas de raison de se soustraire à une telle pratique sûre. Après tout, même les administrateurs de bases de données ou de systèmes doivent procéder régulièrement à une sauvegarde des données pour se prémunir contre les crises majeures issues de circonstances imprévisibles.
Utilisez l'option -v chaque fois que vous suspectez un problème avec la BCG dynamique.
Cette option permet de comparer l'enregistrement de cohérence de chaque exemplaire de la BCG de tous les noeuds de la grappe pour que vous puissiez vérifier que la base de données demeure cohérente dans l'ensemble des noeuds de la grappe. La fonction d'interrogation de la BCG est désactivée tout au long de la procédure de vérification.
# ccdadm nom_grappe -v |
Exécutez la commande précédente avec l'option -c une fois par semaine ou lorsque vous faites une sauvegarde de la BCG.
Cette option crée une copie de sauvegarde de la BCG dynamique. Cette copie peut servir par la suite à récupérer la BCG dynamique avec l'option -r. Voir la "Comment restaurer la BCG" pour de plus amples renseignements à ce sujet.
Lorsque vous sauvegardez la BCG, activez le mode de maintenance de tous les hôtes logiques avant d'exécuter la commande ccdadm -c. Pour récupérer la BCG, les hôtes logiques doivent être en mode maintenance. Par conséquent, la présence d'un fichier de sauvegarde identique à l'état restauré de la BCG évite d'exposer inutilement le système aux erreurs ou aux défaillances.
# ccdadm nom_grappe -c nom_fichier_points_contrôle |
Dans cette commande, nom_fichier_points_contrôle est le nom du fichier de sauvegarde.
Exécutez la commande ccdadm(1M) suivie de l'option -r chaque fois que le contenu de la BCG est altéré. Cette option rejette la copie actuelle de la BCG dynamique et restaure cette dernière avec le contenu du fichier de récupération que vous spécifiez. Exécutez cette commande pour initialiser ou restaurer la BCG dynamique lorsque l'algorithme de reconfiguration ccdd(1M) est incapable de choisir une copie valide de la BCG au moment du redémarrage de la grappe. La BCG est alors identifiée comme étant valide.
Désactivez au besoin le quorum.
Voir la section "Comment activer et désactiver le quorum BCG" pour de plus amples renseignements à ce sujet.
# ccdadm nom_grappe -q off |
Activez le mode maintenance des hôtes logiques.
# haswitch -m hôtes_logiques |
Restaurez la BCG.
Dans la commande suivante, nom_fichier_récupération est le nom du fichier que vous récupérez.
# ccdadm nom_grappe -r nom_fichier_récupération |
Si nécessaire, réactivez le quorum BCG.
# ccdadm nom_grappe -q on |
Remettez les hôtes logiques en ligne.
Par exemple :
# haswitch hôte-physique1 hôte_logique1 # haswitch hôte-physique2 hôte_logique2 |
Habituellement, le logiciel de grappes requiert un quorum avant de mettre la BCG à jour. L'option -c vous permet de passer outre cette restriction et de mettre la BCG à jour avec n'importe quel nombre de noeuds.
Utilisez cette option pour activer ou désactiver le quorum au moment de mettre à jour ou de restaurer la BCG dynamique. L'indicateur_quorum est un commutateur à deux valeurs : actif (activation du quorum) et inactif (désactivation du quorum). Par défaut, le quorum est activé.
Par exemple, si la grappe comporte trois noeuds physiques, vous avez besoin d'au moins deux noeuds pour mettre à jour la BCG. S'il y a eu une défaillance au niveau du matériel, vous ne pouvez réactiver qu'un seul noeud. Le logiciel de grappes ne vous permet donc pas de mettre la BCG à jour. Cependant, si vous exécutez la commande ccdadm -q, vous pouvez désactiver le contrôle logiciel et mettre la BCG à jour.
# ccdadm nom_grappe -q on|off |
L'option -p vous permet de purifier le fichier de la BCG (c'est-à-dire de vérifier son contenu et la syntaxe utilisée). Utilisez cette option s'il y a des erreurs syntaxiques dans le fichier de la base de données de configuration de grappe.
# ccdadm -p nom_fichier_BCG |
L'option -p signale toute erreur de format dans le fichier ciblé et enregistre une version corrigée dans le fichier nom_fichier.pure. Vous pouvez alors récupérer ce fichier "purifié" en tant que nouvelle BCG. Voir "Comment restaurer la BCG" pour de plus amples renseignements à ce sujet.
Le système consigne les erreurs de la BCG dans le fichier /var/opt/SUNWcluster/ccd/ccd.log. Les messages d'erreur critique sont également transmis à la console de grappe. Il est rare que le système subisse une panne majeure, mais dans ce cas, le logiciel crée un fichier noyau dans /var/opt/SUNWcluster/ccd.
Voici un exemple de fichier ccd.log.
lpc204# cat ccd.log 16 avr 14:54:05 lpc204 ID[SUNWcluster.ccd.ccdd.1005] : (info) démarrage de la transition 'START' avec délai de 10000 16 avr 14:54:05 lpc204 ID[SUNWcluster.ccd.ccdd.1005] : (info) transition 'START' terminée avec état 0 16 avr 14:54:06 lpc204 ID[SUNWcluster.ccd.ccdd.1005] : (info) démarrage de la transition 'STEP1' avec délai de 20000 16 avr 14:54:06 lpc204 ID[SUNWcluster.ccd.ccdd.1000] : (info) ID_noeud = 0 Actif = 0 No_généré = 0 Date = 14 fév 10h30m00 1997 Récupération = 4 16 avr 14:54:06 lpc204 ID[SUNWcluster.ccd.ccdd.1002] : (info) démarrage de la reconfiguration de la BCG choisie à partir de ID_noeud = 0 16 avr 14:54:06 lpc204 ID[SUNWcluster.ccd.ccdd.1004] : (info) la BCG d'initialisation est cohérente 16 avr 14:54:06 lpc204 ID[SUNWcluster.ccd.ccdd.1001] : (info) Activation du noeud en tant que grappe à un noeud après exécution de scadmin startcluster ; test de quorum BCG omis 16 avr 14:54:06 lpc204 ID[SUNWcluster.ccd.ccdd.1005] : (info) transition 'STEP1' terminée avec état 0 |
Le tableau ci-dessous dresse la liste des messages d'erreur courants et fournit des solutions aux différents problèmes. Le document Sun Cluster 2.2 Error Messages Manual contient la liste exhaustive de ces messages d'erreur.
Tableau 4-1 Messages d'erreur courants de la base de données de configuration de grappe
La liste des disques mise à jour par le gestionnaire de volumes contient les différents périphériques assurant la protection contre les défaillances. Si un système ne comporte pas de groupe de disques, il n'y a pas de périphériques de protection contre les défaillances (il n'y a effectivement pas de données à protéger). Cependant, lorsque l'on importe de nouveaux groupes de disques alors qu'un ou plusieurs noeuds ne font pas partie de la grappe, il faut signaler à la grappe qu'un autre ensemble de périphériques a besoin de protection contre les défaillances.
Lorsque l'on importe de nouveaux groupes de disques partagés alors qu'un ou plusieurs noeuds ne font pas partie de la grappe, il faut signaler à la grappe qu'un autre ensemble de périphériques a besoin de protection contre les défaillances. Pour ce faire, exécutez la commande scadmin resdisk à partir d'un noeud capable d'accéder au(x) nouveau(x) groupe(s) de disques.
# scadmin resdisks |
Cette commande réserve tous les périphériques connectés à un noeud, si aucun autre noeud n'appartient à la grappe (le noeud doit être capable de se connecter au même ensemble de périphériques). Autrement dit, les réservations ne sont influencées que si un et un seul noeud, parmi tous les noeuds connectés directement aux périphériques, appartient à la grappe. Si cette condition n'est pas respectée, la commande scadmin resdisks ne produit aucun résultat. Cette commande échoue également lorsque la reconfiguration de grappe est en cours. L'arrêt de ce noeud unique ou l'intégration d'autres noeuds connectés directement aux périphériques partagés provoque la libération automatique des réservations de périphériques partagés.
L'exécution de la commande scadmin resdisks est inutile si l'on importe les groupes de disques partagés lorsque tous les noeuds sont présents dans la grappe. Si tous les noeuds appartiennent à la grappe, le recours aux réservations et à la protection contre les défaillances est inutile.
Par contre, l'exportation d'un groupe de disques partagés ne libère pas les réservations des périphériques partagés du groupe de disques exportés. Il n'y a pas de libération de ces réservations tant que le noeud d'où elles proviennent n'est pas arrêté ou que l'autre noeud, avec qui il partage les périphériques, n'a pas intégré la grappe.
Pour activer et utiliser immédiatement l'ensemble de disques appartenant au groupe de disques exportés, exécutez successivement les deux commandes ci-dessous sur tous les noeuds de la grappe, après avoir exporté le groupe de disques partagés :
# scadmin reldisks # scadmin resdisks |
La première commande libère les réservations sur tous les périphériques partagés. La seconde rétablit effectivement les réservations en fonction de l'ensemble de groupes de disques importé et exclut automatiquement l'ensemble de disques associé aux groupes de disques exportés.