test

Guide d'administration du systéme de Sun Cluster 2.2

Chapitre 1 Préparation en vue de l'administration de Sun Cluster

Ce chapitre décrit les procédures de préparation en vue de l'administration d'une configuration Sun Cluster. Certaines des procédures décrites varient en fonction du logiciel de gestion de volumes utilisé (Solstice DiskSuite ou VERITAS Volume Manager). Lorsqu'une procédure est tributaire du gestionnaire de volumes, son nom inclut le nom de ce gestionnaire. Ce chapitre comprend les sections suivantes :

Enregistrement des informations de partitionnement d'un disque (Solstice DiskSuite)

Conservez les informations de partitionnement des disques sur tous les noeuds et disques multihôtes dans la configuration Sun Cluster. Mettez à jour ces données chaque fois que de nouveaux disques sont ajoutés aux ensembles ou que vous repartitionnez des disques, car vous en aurez besoin lors du remplacement de disques.

Les informations de partitionnement des disques locaux ne sont pas aussi essentielles, car les disques locaux présents sur tous les noeuds Sun Cluster devraient avoir été partitionnés de la même façon. Lorsqu'un disque local tombe en panne, vous pouvez en général obtenir les informations de partitionnement à partir d'un autre noeud Sun Cluster.

Lorsque vous remplacez un disque multihôtes, le disque de remplacement doit être partitionné de la même façon que le disque défectueux. Selon le type de panne, il est possible que ces informations ne soient pas disponibles lorsque le remplacement est effectué. Il est donc particulièrement important de conserver un exemplaire des informations de partitionnement lorsque vous utilisez plusieurs types de partitionnement pour vos ensembles de disques.

Remarque :

Bien que VxVM n'impose pas cette opération, il peut être très utile d'enregistrer ces données.

Une méthode d'enregistrement de ces informations est illustrée dans le script de l'exemple qui suit. Avant d'exécuter ce type de script, vous devez configurer le logiciel Sun Cluster. Dans cet exemple, les fichiers contenant les informations de la table des matières de volume (VTOC) sont écrits dans le répertoire local /etc/opt/SUNWcluster/vtoc au moyen de la commande prtvtoc(1M).


#! /bin/sh
DIR=/etc/opt/SUNWcluster/vtoc 
mkdir -p $DIR 
cd /dev/rdsk 
for i in *s7 
do prtvtoc $i >$DIR/$i || rm $DIR/$i 
done

Chaque disque d'un ensemble de disques de Solstice DiskSuite doit comporter une tranche 7. Cette tranche contient les répliques de base de données d'état des métapériphériques.

Lorsqu'un disque local contient également une tranche 7 valide, les informations VTOC sont également enregistrées par le script d'exemple. Toutefois, cette opération ne devrait pas intervenir dans le cas du disque d'initialisation, car celui-ci ne comporte pas habituellement de tranche 7 valide.

Remarque :

Avant d'exécuter le script, assurez-vous qu'aucun disque n'appartient à un autre noeud Sun Cluster. Pour que ce script fonctionne, il faut que les hôtes logiques soient en mode de maintenance ou qu'ils appartiennent à l'hôte local, ou encore que Sun Cluster soit arrêté.

Enregistrement et restauration des informations VTOC (Solstice DiskSuite)

Lorsque vous enregistrez les données VTOC pour tous les disques multihôtes, vous pouvez ensuite utiliser ces informations lorsque vous remplacerez un disque. Le script de l'exemple qui suit utilise les informations VTOC enregistrées par le script ci-dessous pour partitionner le disque de remplacement de la même façon que le disque défectueux. En situation d'exploitation réelle, il suffit de remplacer c1t0d0s7 et c1t0d1s7 par le nom de chaque disque. Vous pouvez également spécifier plusieurs disques en entrant leur nom respectif un à la suite de l'autre, en les séparant par un espace.


#! /bin/sh 
DIR=/etc/opt/SUNWcluster/vtoc 
cd /dev/rdsk 
for i in c1t0d0s7 c1t0d1s7
do fmthard -s $DIR/$i $i 
done
Remarque :

Le disque de remplacement doit avoir la même capacité et la même géométrie (et en général être du même modèle et du même fabricant) que le disque défectueux. Sinon, la table des matières de volume d'origine risque de ne pas convenir au nouveau disque.

Si vous n'avez pas enregistré ces informations de VTOC mais que vous avez créé des copies miroirs des tranches pour chaque disque individuel (mêmes informations VTOC des deux côtés du miroir, par exemple), vous pouvez copier les données VTOC sur le disque de remplacement à partir de l'autre disque sous-miroir. Pour que cette procédure fonctionne, il faut que le disque de remplacement soit en mode de maintenance ou qu'il appartienne au même hôte que le disque défectueux, ou encore que Sun Cluster soit arrêté. Cette procédure est illustrée dans l'exemple suivant.


#! /bin/sh 
cd /dev/rdsk 
OTHER_MIRROR_DISK=c2t0d0s7 
REPLACEMENT_DISK=c1t0d0s7 
prtvtoc $OTHER_MIRROR_DISK | fmthard -s - $REPLACEMENT_DISK

Si vous n'avez pas enregistré les données VTOC ni créé de copies miroirs pour chaque disque individuel, vous pouvez examiner la taille des composants indiquée par la commande metaset(1M) et décompiler les informations VTOC. Compte tenu de la complexité des calculs effectués par cette procédure, celle-ci ne doit être exécutée que par un représentant spécialement formé à cette fin.

Enregistrement des informations de configuration de périphérique

Enregistrez les informations /etc/path_to_inst et /etc/name_to_major sur un support amovible (disquette ou unité de bande de sauvegarde).

Le fichier path_to_inst(4) contient les numéros d'unités mineurs pour chacun des disques contenus dans une unité d'expansion de disque multihôtes. Vous devez utiliser ces données lorsqu'un disque d'initialisation d'un noeud Sun Cluster tombe en panne et qu'il faut le remplacer.

Désignation et numérotation des instances

Des noms d'instances sont parfois indiqués dans les messages d'erreur. Le nom d'instance désigne des périphériques système comme ssd20 ou hme5.

Pour connaître les liens existant entre un nom d'instance et un nom physique, examinez la sortie /var/adm/messages ou dmesg(1M) :


ssd20 at SUNW,pln0: 
ssd20 is /io-unit@f,e0200000/sbi@0,0/SUNW,soc@3,0/SUNW,pln@a0000800,20183777 \ 
/ssd@4,0 
le5 at lebuffer5: SBus3 slot 0 0x60000 SBus level 4 sparc ipl 7 
le5 is /io-unit@f,e3200000/sbi@0,0/lebuffer@0,40000/le@0,60000

Lorsqu'un nom d'instance est attribué à un périphérique, il y reste lié.

Les numéros d'instances sont codés dans un numéro mineur de périphérique. Pour que les numéros d'instances soient conservés entre les réinitialisations, le système les enregistre dans le fichier /etc/path_to_inst. Ce fichier n'est lu qu'au moment de l'initialisation et est mis à jour au moyen des commandes add_drv(1M) et drvconfig(1M). Pour de plus amples renseignements à ce sujet, voir la page de manuel path_to_inst(4).

Lorsque vous installez l'environnement d'exploitation Solaris sur un noeud, les numéros d'instances peuvent être modifiés si des éléments matériels ont été ajoutés ou retirés depuis la dernière installation de Solaris. Il faut donc être très prudent lors de l'ajout et du retrait, sur les noeuds Sun Cluster, de périphériques comme les cartes SBus ou FC/OM. Il est important de conserver la même configuration sur les périphériques existants pour éviter toute confusion du système lors de la réinitialisation ou après une réinstallation ou une reconfiguration.

Des problèmes de numéro d'instance peuvent également survenir. Prenons par exemple une configuration Sun Cluster constituée de trois tableaux SPARCstorage(TM) avec cartes SBus de canal de fibres optiques (FC/S) installées dans les fentes SBus 1, 2 et 4 sur chacun des noeuds. Les contrôleurs portent les numéros c1, c2 et c3. Si l'administrateur du système ajoute un autre tableau SPARCstorage à cette configuration (carte FC/S dans la fente SBus 3), le numéro du contrôleur correspondant sera c4. Si Solaris est réinstallé sur un des noeuds, les numéros de contrôleur c3 et c4 désigneront des tableaux SPARCstorage différents. L'autre noeud Sun Cluster désignera toujours les tableaux SPARCstorage portant les numéros d'instances originaux. Solstice DiskSuite ne communiquera pas avec les disques connectés aux contrôleurs c3 et c4.

D'autres problèmes peuvent surgir sur le plan de la numérotation des instances associées aux connexions Ethernet. Ainsi, chacun des noeuds de Sun Cluster comporte trois cartes SBus Ethernet, installées dans les fentes 1, 2 et 3 et portant les numéros d'instances hme1, hme2 et hme3. Si la carte du milieu (hme2) est retirée et que Solaris est réinstallé, la troisième carte SBus, auparavant hme3, portera désormais le nom hme2.

Réinitialisations de reconfiguration

Au cours de certaines procédures administratives décrites dans ce manuel, vous devez effectuer une réinitialisation de reconfiguration en exécutant la commande OpenBoot(TM) PROM boot  -r ou en créant le fichier /reconfigure sur le noeud, puis en réinitialisant le système.

Remarque :

Il n'est pas nécessaire d'effectuer cette réinitialisation pour ajouter des disques à une unité d'expansion de disque multihôtes existante.

N'effectuez pas de réinitialisation de reconfiguration de Solaris si un ou plusieurs éléments matériels (en particulier une unité d'expansion de disque multihôtes ou un disque) est hors tension ou défectueux. Dans de tels cas, la réinitialisation entraîne la suppression des inodes dans l'entrée /devices et des liens symboliques dans les entrées /dev/dsk et /dev/rdsk associées aux périphériques de disque. Ces disques deviennent alors inaccessibles pour Solaris, et ce jusqu'à une reconfiguration ultérieure. Lors de la réinitialisation de reconfiguration suivante toutefois, il peut arriver que les numéros mineurs initiaux du contrôleur ne soient pas restaurés et que le gestionnaire de volumes rejette les disques. Après restauration de la numérotation d'origine, le gestionnaire de volumes peut accéder aux objets associés à ces numéros.

Si tous les éléments matériels sont fonctionnels, vous pouvez effectuer une réinitialisation de reconfiguration sans inquiétude lors de l'ajout d'un contrôleur de disque à un noeud. Vous devez ajouter ces contrôleurs de façon symétrique aux deux noeuds (un déséquilibre temporaire est cependant accepté pendant la mise à niveau des noeuds). De même, si tous les éléments matériels sont fonctionnels, vous pouvez effectuer en toute sécurité une réinitialisation de reconfiguration pour supprimer certains de ces éléments.

Remarque :

Sous Sun StorEdge A3000, dans le cas d'une panne touchant un seul contrôleur, vous devriez remplacer le contrôleur défectueux le plus rapidement possible. Les autres tâches d'administration exigeant normalement une initialisation à l'aide de la commande boot --r (ajout d'un nouveau périphérique SCSI, par exemple) ne doivent être exécutées qu'après le remplacement et la remise en ligne du contrôleur défectueux, lorsque tous les numéros d'unités logiques ont été remis à l'état en vigueur avant la défaillance. Pour de plus amples renseignements, reportez-vous à la documentation de Sun StorEdge A3000.

Connexion sur le serveur en qualité de root (superutilisateur)

Pour ouvrir une session sur les noeuds Sun Cluster en tant que root (superutilisateur) par l'intermédiaire d'un terminal autre que la console, vous devez modifier le fichier /etc/default/login et mettre en commentaire la ligne suivante : 


CONSOLE=/dev/console

La ligne ci-dessus permet d'ouvrir une session avec privilèges de root (superutilisateur) au moyen des programmes rlogin(1) et telnet(1), entre autres.