LES CAHIERS d'AIX
Publication réservée aux abonnés du Point Service AIX
Janvier 1998

Nouveautés HACMP V4.2.1

Charly CASTAGNIER, Jacques REDON, Nadim TABASSUM

Introduction

Si vous n'utilisez pas HACMP et si la haute disponibilité de votre informatique vous préoccupe, lisez le premier chapitre.
Si vous n'utilisez pas HACMP et si vous êtes tenté de faire partager des disques par deux machines, ou si vous le faites déjà, lisez le deuxième chapitre.
Que vous utilisiez ou non HACMP, si la commande IMPORTVG vous intéresse lisez le troisième chapitre.
Si vous avez déjà HACMP dans une version antérieure à la V4.2.1, lisez les chapitres deux et trois à titre de révision et le chapitre quatre pour mesurer l'intérêt de cette nouvelle version.
Si vous avez déjà HACMP V4.2.1, lisez les chapitres deux à quatre pour savoir tirer le maximum de satisfaction de ce produit.

Note: La version 4.2.2 d'HACMP, maintenant disponible, ne remet pas en cause les informations fournies par ce document.

Abréviations

Dans ce document, nous utiliserons les abréviations suivantes :

VG: pour groupe de volume (Volume Groupe).
PV: pour disque physique (Physical Volume).
PP: pour partition physique (Physical Partition).
LV: pour volume logique (Logical Volume).
FS: pour système de fichiers (FileSystem).
HACMP: High Availability Cluster Multi-Processing
ODM AIX: Pour simplifier le texte, par ODM AIX nous entendrons les objets de :
/etc/objrepos/CuAt, CuDv, CuDvDr et CuDep
qui contiennent des informations sur les LV définis dans le système.
Ces objets sont systématiquements modifiés par les commandes d'ajout, de modification et de suppression.
Il y a, bien entendu, d'autres objets pour AIX dans l'ODM, mais il ne sont pas impactés par les propos de cet article.
ODM HACMP: Ce sont tous les objets contenus dans :
/etc/objrepos/HACMP*

Chapitre 1. La haute disponibilité

Les progiciels applicatifs, de plus en plus nombreux, sont le passage obligé de beaucoup d'entreprises. La disponibilité des applications, de plus en plus souvent 7 jours sur 7, 24 heures sur 24, est vitale pour la bonne marche de leurs affaires. Vous le savez bien, puisque vous avez mis en place des systèmes de sauvegarde de vos données que vous effectuez, au moins, quotidiennement. Peut-être même utilisez-vous des disques "RAID" ou avez-vous mis en place la fonction "miroir" d'AIX pour vous protéger, encore mieux, d'une panne disque.

Mais les disques ne sont qu'un des éléments de votre équipement informatique et, bien que le matériel soit de plus en plus fiable, aucun composant n'est à l'abri d'une panne :

Un adaptateur de réseau qui flanche... et personne ne peut plus se connecter.
La carte mère en panne... et plus rien ne marche.
Un adaptateur de disques hors service... et les disques sont inaccessibles.
Une mise à jour de logiciel, ou de progiciel, insuffisamment testée ou mal appliquée... et plus rien ne tourne,

Heureusement, cela n'arrive pas souvent ; mais même une seule fois est une fois de trop. Les utilisateurs de l'informatique sont en chômage technique, avec tout ce que cela implique pour l'entreprise qui peut se retrouver paralysée jusqu'au redémarrage du système.

Pour pallier ces inconvénients, vous avez peut-être déjà prévu un système de secours capable de repartir rapidement ; mais ce n'est jamais immédiat.

Vous avez peut-être prévu une machine, locale ou déportée, munie des mêmes adaptateurs et ayant une capacité de disques identique. Mais il faut redémarrer à partir des sauvegardes du système et des données, et on perd forcément toutes les données modifiées ou ajoutées depuis ces sauvegardes ; il faut aussi restaurer le système et les données.
Vous avez peut-être prévu, dans le même local, deux machines ayant des "slots" et des adaptateurs disponibles pour reconnecter les "périphériques" de la machine en panne... Mais il faut débrancher et rebrancher les cÔbles, veiller à la synchronisation des objets de l'ODM AIX et de "/etc/filesystems" et, bien sűr, que les mêmes applications, utilisateurs, groupes et mots de passe soient immédiatement accessibles.
Vous avez peut-être prévu des disques externes, dits : "partageables", connectés à deux machines... Les problèmes sont les mêmes que précédemment, avec la reconnexion des disques en moins.
Nous traiterons de cela en détail dans le chapitre 2.
Dans bien des cas, il faut reconfigurer le réseau car on ne doit pas avoir d'adresses identiques et, en général, on tient à ce que les utilisateurs accèdent aux applications de la même façon (quand ce ne sont pas les applicatifs eux-mêmes qui sont configurés pour une adresse IP bien précise).
Dans tous les cas il faut avoir prévu que vos licences de programmes (droit d'usage ou personnalisation) concernent les deux machines.

Pour que ce genre de reprise soit possible, vous avez doublé le matériel pour être sűr de pouvoir repartir quel que soit le composant en défaut ; autrement dit : pour pouvoir assurer la fiabilité de votre système, celui-ci ne doit pas comporter d'élément unique susceptible de tomber en panne sans pouvoir être secouru, donc il ne faut pas de SPOF (Single Point Of Failure).

C'est là qu'HACMP entre en jeu. GrÔce à lui, vous allez pouvoir résoudre les problèmes d'adresses, reconnaître et acquérir des disques, puis automatiser le redémarrage de vos applications sans intervention manuelle.

La détection des pannes est automatisée, soit par des "démons" (tÔches de fond) d'HACMP qui surveillent en permanence les machines, soit par la détection automatique des "errpt".

En fonction de l'incident HACMP et des scénarios mis en place dans la personnalisation du produit, les applications de la machine en panne seront relancées automatiquement sur la machine prévue à cet effet.

Jusqu'à huit RS/6000 et seize Noeuds de RS/6000 SP peuvent ainsi être fédérés pour se secourir mutuellement. Il faut, bien sűr, que toutes ces machines soient interconnectées dans un réseau local et que les disques soient partageables (ce qui est possible avec des cÔbles spéciaux pour les disques "SCSI2 FW/DE" et, naturellement, possible sur des boucles de disques SSA).

Toute la gamme RS/6000, du 43P au plus gros mono ou multi-processeur, en passant par tous les types de noeuds RS/6000 SP, peut être sécurisée avec le même HACMP.

Chapitre 2. Les disques partagés

Principe

Il est peut-être bon de rappeler quelques principes de fonctionnement d'AIX, dans le cadre de l'utilisation des disques que se partageraient deux machines...

Dans le cas où vous utiliseriez HACMP, le réseau TCP/IP et le réseau RS232 ont été représentés sur le schéma ci-dessous.
Pour que les disques soient reconnus des deux machines, on considère que la double connexion des disques est effectuée dans les règles de l'art (cÔble en Y, charges et bouchons adaptés, ID changé pour le SCSI et boucles correctement configurées pour SSA).

                                                                      
                               Réseau HACMP                          
                                                                                
 -----+------+----------------------------------------------+------+-----      
      |      |                                              |      |
    +-+------+-+            liaison RS232                 +-+------+-+
    |          |                                          |          |
    |   beta   +------------------------------------------+   delta  |
    |          |                                          |          |        
    |          |            +-----------+                 |          |        
    |  ascsi0  +------------+  hdisk2   |       +---------+  ascsi0  |        
    |          |            +-----------+       |         |          |       
    +----------+            +-----------+       |         +----------+        
    |  hdisk0  |            |  hdisk3   |       |         |  hdisk0  |        
    +----------+            +-----------+       |         +----------+ 
    |  hdisk1  |            +-----------+       |         |  hdisk1  |        
    +----------+            |  hdisk4   |       |         +----------+        
                            +-----------+       |                            
                            +-----------+       |                            
                            |  hdisk5   +-------+                             
                            +-----------+

La machine beta ne connaît pas les VG, LV et FS de la machine delta et réciproquement.
Comme point de départ, nous considérons que les disques ont été interconnectés aux deux CPU et qu'ils sont reconnus.
La machine beta s'est approprié les PV hdisk2 et hdisk3 pour son VG vgbeta.
La machine delta s'est approprié les PV hdisk4 et hdisk5 pour son VG vgdelta.

                                                                           
Machine beta                                 Machine delta
                                                                                
  vgbeta                  VG                     vgdelta             
  hdisk2  (vgbeta)        PV            (none)   hdisk2              
  hdisk3  (vgbeta)        PV            (none)   hdisk3              
  hdisk4  (none)          PV         (vgdelta)   hdisk4              
  hdisk5  (none)          PV         (vgdelta)   hdisk5              
  lvbeta1                 LV                     lvdelta1            
  lvbeta2                 LV                     lvdelta2            
  /beta1                  FS                     /delta1             
  /beta2                  FS                     /delta2

Par défaut, les VG ont le paramètre "autovaryon=true" et les FS ont le paramètre "mount=true".
Quand on lance AIX (boot) sur les machines, les VG sont activés et les FS montés :
- Sur beta : le VG vgbeta et les FS /beta1 et /beta2.
- Sur delta : le VG vgdelta et les FS /delta1 et /delta2.

La finalité de cette double connexion est de pouvoir utiliser une machine si l'autre est en panne, donc que :
- beta puisse faire "varyonvg" de vgdelta.
- delta puisse faire "varyonvg" de vgbeta.
Ceci n'est pas possible en l'état. Il faut que l'on mette les ODM et les /etc/filesystems des deux machines en phase grÔce à des informations identiques, et que l'on fasse quelques changements de paramètres.

Synchronisation initiale des ODM

Il faut passer les commandes suivantes en respectant l'ordre indiqué :

Ajout de vgdelta dans ODM de beta :

+--------------------------------------------------------------------------------+
|                                                                                |
|# sur delta:                                                                    |
|chvg -a n vgdelta                   # note 1                                    |
|chfs -a mount=false /delta1         # note 2                                    |
|chfs -a mount=false /delta2         # note 2                                    |
|varyoffvg vgdelta                   # note 3                                    |
|                                                                                |
|# sur beta:                                                                     |
|#exportvg vgdelta                   # note 4                                    |
|importvg -y vgdelta hdisk4          # note 5                                    |
|chvg -a n vgdelta                   # note 6                                    |
|chvg -Q n vgdelta                   # note 7                                    |
|chown user.groupe /dev/vgdelta      # note 8                                    |
|chown user.groupe /dev/lvdelta1     # note 8                                    |
|chown user.groupe /dev/lvdelta2     # note 8                                    |
|varyoffvg vgdelta                   # note 3                                    |
|                                                                                |
|# sur delta:                                                                    |
|varyonvg vgdelta                                                                |
|                                                                                |
+--------------------------------------------------------------------------------+

Et, symétriquement, ajout de vgbeta dans ODM de delta : :
+--------------------------------------------------------------------------------+ | | |# sur beta: | |chvg -a n vgbeta # note 1 | |chfs -a mount=false /beta1 # note 2 | |chfs -a mount=false /beta2 # note 2 | |varyoffvg vgbeta # note 3 | | | |# sur delta: | |importvg -y vgbeta hdisk2 # note 5 | |chvg -a n vgbeta # note 6 | |chvg -Q n vgbeta # note 7 | |chown user.groupe /dev/vgbeta # note 8 | |chown user.groupe /dev/lvbeta1 # note 8 | |chown user.groupe /dev/lvbeta2 # note 8 | |varyoffvg vgbeta # note 3 | | | |# sur beta: | |varyonvg vgbeta | | | +--------------------------------------------------------------------------------+

Explications

note 1
Il ne faut plus que les VG soient mis automatiquement "varyon" au boot car il faut pouvoir choisir la machine qui les activera. On les met donc en "autovaryon=no".
note 2
Comme au boot le VG ne sera pas activé, les FS ne pourraient pas être "montés", il faut donc supprimer le "mount=true" de tous les FS des VG en "autovaryon=no".
note 3
Le "varyonvg" met un verrou sur tous les disques du VG (reserve) ; de ce fait, les disques sont inaccessibles par une autre machine.
C'est pourquoi il faut faire le "varyoffvg" sur la machine qui possède le VG pour pouvoir faire la synchronisation.
note 4
IL NE FAUT PAS PASSER CETTE COMMANDE LA PREMIERE FOIS (vgdelta est inconnu de delta, et réciproquement). L'"exportvg" vide l'ODM AIX de toutes les informations du VG et "/etc/filsystems" des FS de ce VG.
note 5
L'"importvg" lit le VGDA du disque spécifié et fabrique les entrées nécessaires dans l'ODM AIX et dans "/etc/filsystems".
note 6
L'"importvg" remet TOUJOURS, par défaut, le VG en "autovaryon=yes". Il faut donc le remettre en "autovaryon=no" (rappel : note 1).
note 7
L'"importvg" remet TOUJOURS, par défaut, "QUORUM=yes". Il faut donc remettre "QUORUM=no" s'il y a des "copies miroir" de LV et qu'il n'y a pas au moins 3 disques dans le VG.
note 8
L'"importvg" remet "root.system" comme propriétaire du VG importé et de ses LV. Si ces unités doivent être la propriété d'un autre utilisateur, il faut refaire les droits avec "chown".

Après avoir passé ces commandes, la situation est la suivante sur les deux systèmes :

Machine beta Machine delta:eh ODM vgbeta VG vgdelta ODM lvbeta1 LV lvdelta1 ODM lvbeta2 LV lvdelta2 /etc/filesystems /beta1 FS /delta1 /etc/filesystems /beta1 FS /delta2 ++++++++++++++++ Eléments AJOUTES par importvg +++++++++++++++++ ODM vgdelta VG vgbeta ODM lvdelta1 LV lvbeta1 ODM lvdelta2 LV lvbeta2 /etc/filesystems /delta1 FS /beta1 /etc/filesystems /delta2 FS /beta2 ++++++++++++++++ Eléments MODIFIES par importvg ++++++++++++++++ ODM hdisk2 (vgbeta) PV (vgbeta) hdisk2 ODM hdisk3 (vgbeta) PV (vgbeta) hdisk3 ODM hdisk4 (vgdelta) PV (vgdelta) hdisk4 ODM hdisk5 (vgdelta) PV (vgdelta) hdisk5

Conséquence
Comme on a supprimé les varyon et les mount automatiques, il va de soi qu'il faudrait ajouter ces deux fonctions dans le shell qui, d'habitude, lance les applications... Mais HACMP s'en charge automatiquement,

Obligations
Chaque fois que vous modifiez un VG, un LS ou un FS sur une machine, les commandes AIX mettent à jour l'ODM, "/dev" ou "/etc/filesystems" sur la machine qui possède les disques. L'AIX de l'autre machine n'est alors plus à jour.

Par exemple, ajoutons le LV "lvDELTANEW" et le FS "/DELTANEW" sur delta.
Après cet ajout, la situation devient :

Machine beta Machine delta:eh ODM vgbeta VG vgdelta ODM lvbeta1 LV lvdelta1 ODM lvbeta2 LV lvdelta2 /etc/filesystems /beta1 FS /delta1 /etc/filesystems /beta1 FS /delta2 ODM vgdelta VG vgbeta ODM lvdelta1 LV lvbeta1 ODM lvdelta2 LV lvbeta2 /etc/filesystems /delta1 FS /beta1 /etc/filesystems /delta2 FS /beta2 ODM hdisk2 (vgbeta) PV (vgbeta) hdisk2 ODM hdisk3 (vgbeta) PV (vgbeta) hdisk3 ODM hdisk4 (vgdelta) PV (vgdelta) hdisk4 ODM hdisk5 (vgdelta) PV (vgdelta) hdisk5 ++++++++++++++++ Eléments AJOUTES par ajout LV/FS ++++++++++++++ ODM ?????? LV lvDELTANEW /etc/filesystems ?????? FS /DELTANEW

Autre exemple, modifions la taille de "/delta1" sur delta.
Après cette modification, la situation devient :

Machine beta Machine delta:eh ODM vgbeta VG vgdelta ODM lvbeta2 LV lvdelta2 /etc/filesystems /beta1 FS /delta1 /etc/filesystems /beta1 FS /delta2 ODM vgdelta VG vgbeta ODM (80 PP) ??? lvdelta1 LV lvbeta1 ODM lvdelta2 LV lvbeta2 /etc/filesystems /delta1 FS /beta1 /etc/filesystems /delta2 FS /beta2 ODM hdisk2 (vgbeta) PV (vgbeta) hdisk2 ODM hdisk3 (vgbeta) PV (vgbeta) hdisk3 ODM hdisk4 (vgdelta) PV (vgdelta) hdisk4 ODM hdisk5 (vgdelta) PV (vgdelta) hdisk5 ODM LV lvDELTANEW /etc/filesystems FS /DELTANEW ++++++++++++++++ Elément MODIFIE par CHLV/CHFS +++++++++++++++++ ODM lvbeta1 LV (100 PP) ??? lvdelta1

Autre exemple, ajoutons 2 disques à vgdelta.
Après cet ajout, la situation devient :

Machine beta Machine delta:eh ODM vgbeta VG vgdelta ODM lvbeta1 LV (100 PP) lvdelta1 ODM lvbeta2 LV lvdelta2 /etc/filesystems /beta1 FS /delta1 /etc/filesystems /beta1 FS /delta2 ODM vgdelta VG vgbeta ODM (80 PP) lvdelta1 LV lvbeta1 ODM lvdelta2 LV lvbeta2 /etc/filesystems /delta1 FS /beta1 /etc/filesystems /delta2 FS /beta2 ODM hdisk2 (vgbeta) PV (vgbeta) hdisk2 ODM hdisk3 (vgbeta) PV (vgbeta) hdisk3 ODM hdisk4 (vgdelta) PV (vgdelta) hdisk4 ODM hdisk5 (vgdelta) PV (vgdelta) hdisk5 ODM LV lvDELTANEW /etc/filesystems FS /DELTANEW ++++++++++++++++ Eléments AJOUTES par AJOUT PV +++++++++++++++++ ODM ?????? ????????? PV (vgdelta) hdisk6 ODM ?????? ????????? PV (vgdelta) hdisk7

Ces quelques exemples vous montrent qu'après chaque modification l'ODM de la machine beta est désynchronisé.
Il est donc indispensable de faire des manipulations presqu'analogues à celles indiquées au paragraphe : "Synchronisation initiale des ODM"

Synchronisations répétées de l'ODM
Examinons les différences par rapport à la synchronisation initiale.
+--------------------------------------------------------------------------------+ | | |# sur la machine: delta | |#modifications ou ajout détaillés ci-dessus | |#arrêt graceful de HACMP si utilisé ou | |#arrêt de tout applicatif qui utiliserait vgdelta (voir note ci-dessous) | |varyoffvg vgdelta # obligatoire | | | |# sur la machine: beta | |exportvg vgdelta # note 4 | |importvg -y vgdelta hdisk4 | |chvg -a n vgdelta | |chvg -Q n vgdelta | |chown user.group ..... | |chown user.group ..... | |varyoffvg vgdelta | | | |# sur la machine: delta | |#relance de HACMP si utilisé ou | |#relance des applicatifs qui utiliseraient vgdelta | |varyonvg vgdelta | | | +--------------------------------------------------------------------------------+

Note: Le plus gênant est qu'il faudra arrêter vos applications sur la machine delta.
Avec AIX V3.2.x, avec HACMP ou sans HACMP cette méthode est obligatoire.
Il manque la mise à jour des ressources HACMP... le sujet sera traité plus loin.

Chapitre 3. Apports d'AIX V4.2.1 et de ses PTF

Niveau du système
Pour vérifier le niveau de votre système, passez la commande :
+--------------------------------------------------------------------------------+ |lslpp -l | grep lvm | +--------------------------------------------------------------------------------+
Avec AIX V4.2.1 et le module "bos.rte.lvm.4.2.1.4", les commandes "varyonvg" et "importvg" offrent des options supplémentaires...

Nouvelles options du "varyonvg"

+--------------------------------------------------------------------------------+ |varyonvg -u -b nom_du_VG | +--------------------------------------------------------------------------------+

-b
efface (break) le verrou (reserve) sur les disques du VG.
-u
fait le varyonvg du VG mais ne pose pas le verrou, il laisse les disques déverrouillés (unlock).

Mise en garde
Ne croyez surtout pas que, grÔce à ces options, le VG peut être accédé par deux machines simultanément.
Mal utilisées, ces options sont dangereuses pour l'intégrité des données.

Utilisation

On utilise ces options uniquement pour pouvoir faire la mise à jour de l'ODM, et seulement durant le temps de cette mise à jour.
Il faut passer la commande sur la machine qui possède les disques.
Dès que la mise à jour (importvg) sur l'autre machine est terminée, il faut repasser la commande sans option.

Nouvelle option de l'"importvg"

Note:
La nouvelle option de la commande "importvg" ne fonctionne que si le module AIX "bos.rte.lvm" a été mis, par PTF, au niveau 4.2.1.4.
+--------------------------------------------------------------------------------+ |importvg -L nom_du_VG hdiskX | +--------------------------------------------------------------------------------+

-L
La nouvelle option "-L" de importvg autorise le LVM à lire le VGDA et les LVCB d'un VG, même quand ce VG est actif (varyonvg -u -b) sur une autre machine. L'ODM et les autres fichiers associés seront remis à jour.

Fonctionnement de la commande "imporvg -L"

Elle implique que vous ayez passé auparavant, sur le noeud qui possède le VG, la commande :
+--------------------------------------------------------------------------------+ |varyonvg -u -b vgdelta | +--------------------------------------------------------------------------------+

Elle recherche, dans le VGDA, les LV existants.
Elle fait une sauvegarde du "owner", du groupe et des permissions de ces LV.
Elle fait une sauvegarde de tous les objets de l'ODM AIX concernant ce VG.
Elle détruit et recrée chaque LV, en utilisant les informations du VGDA et des "/dev".
Elle remet les bons "owner", groupe et permissions.
Elle traite les différences :

Un LV présent dans l'ancien ODM mais absent des VGDA est supprimé.
Un LV absent de l'ancien ODM mais présent dans les VGDA est créé.

Elle ajoute ou supprime de "/etc/filesystems" les entrées nécessaires.

Restrictions à l'utilisation de l'"importvg -L"

Le VG doit être "varyoff" sur la machine qui passe l' "importvg -L".
Le VG doit déjà exister dans l'ODM.
Le VG ne peut être "varyon" que sur une seule autre machine (ce qui exclut son utilisation sur un cluster HACMP en mode 3).
La commande doit être passée aussitôt après chaque modification (ajout, modification ou suppression sur un LV et ajout ou suppression d'un FS -n'oublions pas que l'agrandissement d'un FS agrandit aussi le LV, donc le modifie-).
Le disque spécifié dans la commande doit être un disque dont la VGDA est en bon état (disque non "stale" ou "missing").
Tout nouveau LV prendra automatiquement les mêmes "owner", groupe et permission que le VG père.
Les options "-y", "-V" et "-f" sont incompatibles avec l'option "-L".
Aucune autre modification sur ce VG n'est possible pendant le déroulement de l'"importvg -L".
Le VG "rootvg" et les VG contenant un "PAGING SPACE" n'admettent pas cette commande.
Dans le cas où le disque vient d'être remplacé, "importvg -L" ne peut fonctionner que si le disque a déjà été reconnu par un "cfgmgr".

Utilisation
Pour les quatre contextes suivants, on suppose que :

Les ODM sont à jour sur les deux machines, beta et delta.
Le VG "vgdelta" est actif (varyon) sur delta, et on ajoute le LV "lvDELTANEW" et le FS "/DELTANEW".
On doit donc resynchroniser l'ODM de beta.

Contexte 1 : AIX V4.2 + "bos.rte.lvm" en V4.2.1.4, sans HACMP

+--------------------------------------------------------------------------------+ | | |#sur la machine: delta | |smit lv #pour créer le LV | |smit fs #pour créer le FS | |varyonvg -u -b vgdelta | | | |#sur la machine: beta | |lspv #pour repérer un disque du VG (ici hdisk4 ou 5) | |importvg -L vgdelta hdisk4 | | | |#sur la machine: delta | |varyonvg vgdelta | | | +--------------------------------------------------------------------------------+

On peut garder les applications actives.
Plus besoin de faire de "chvg" car toutes les options existantes de ce VG ont été remises en état avec "importvg -L".

Contexte 2 : AIX V4.2 + "bos.rte.lvm" V4.2.1.4 + HACMP V4.2.x

+--------------------------------------------------------------------------------+ | | |#sur la machine: delta | |smit lv #pour créer le LV | |smit fs #pour créer le FS | |smit hacmp | | Cluster Configuration | | Cluster Resources | | Configure a Resource Group #pour ajouter la ressource | | Synchronize Cluster Resources #pour synchroniser l'ODM HACMP | | #vérification automatique | | | | [Zones d'entrée] | | Ignore Cluster Verification Errors? [No] | | Un/Configure Cluster Resources? [Yes] or [No] | |varyonvg -u -b vgdelta | | | |#sur la machine: beta | |lspv #pour repérer un disque du VG (ici hdisk4 ou 5) | |importvg -L vgdelta hdisk4 | | | |#sur la machine: delta | |varyonvg vgdelta | | | +--------------------------------------------------------------------------------+

Il n'est pas nécessaire d'arrêter HACMP.
Il faudra lire attentivement le chapitre suivant "Chapitre 4. NOUVEAUTES HACMP V4.2.x" pour comprendre comment se fait la synchronisation automatique en HACMP V4.2.x.

Contexte 3 : AIX V4.2 + "bos.rte.lvm" en V4.2.1.4 + HACMP V3 ou V2
Ces niveaux de produits sont rarement rencontrés.

+--------------------------------------------------------------------------------+ | | |#sur la machine: delta | |smit lv #pour créer le LV | |smit fs #pour créer le FS | | | |#sur les deux machines | |smit clstop #graceful | | | |#sur la machine: delta | |smit hacmp | | Cluster Configuration | | Cluster Resources | | Configure a Resource Group #pour ajouter la ressource | | Cluster Verification #clverify | | Synchronize Cluster Resources #pour synchroniser l'ODM HACMP | |varyonvg -u -b vgdelta | | | |#sur la machine: beta | |lspv #pour repérer un disque du VG (ici hdisk4 ou 5) | |importvg -L vgdelta hdisk4 | | | |#sur la machine: delta | |varyonvg vgdelta | | | |#sur les deux machines | |smit clstart | | | +--------------------------------------------------------------------------------+

Il est interdit de modifier la topologie ou les ressources quand HACMP est actif; il faudrait donc arrêter HACMP sur les deux machines.
Dans ce cas "importvg -L" n'apporte pas beaucoup.
On peut comparer avec le contexte suivant...

Contexte 4 : AIX V4.1.X ou V3 + HACMP V4.1 ou V3

+--------------------------------------------------------------------------------+ | | |#sur la machine: delta | |smit lv #pour créer le LV | |smit fs #pour créer le FS | | | |#sur les deux machines | |smit clstop #graceful | | | |#sur la machine: delta | |smit hacmp | | Cluster Configuration | | Cluster Resources | | Configure a Resource Group #pour ajouter la ressource | | Cluster Verification #clverify | | Synchronize Cluster Resources #pour synchroniser l'ODM HACMP | | | |#sur la machine: beta | |lspv #pour repérer un disque du VG (ici hdisk4 ou 5) | |ls -l /vgdelta #pour repérer le Major Node | |importvg -y vgdelta -V major_node hdisk4 | |chvg -a n vgdelta | |chvg -Q n vgdelta #voir si nécessaire les | |chown user.groupe /dev/vgdelta #notes 1 à 8 des | |chown user.groupe /dev/lvdelta1 #chapitres précédants | |chown user.groupe /dev/lvdelta2 # | |chown user.groupe /dev/lvDELTANEW # | |varyoffvg vgdelta | | | |#sur les deux machines | |smit clstart | | | +--------------------------------------------------------------------------------+

Il est interdit de modifier la topologie ou les ressources quand HACMP est actif; il faudrait donc arrêter HACMP sur les deux machines.

Chapitre 4. NOUVEAUTES HACMP V4.2.x

HACMP V4.2 et V4.2.1 fonctionnent sous AIX V4.1.5 ou V4.2.x.
Outre le support des nouvelles machines, HACMP V4.2 dispose d'un nouveau composant : le C-SPOC (Cluster Single Point Of Control) dont la fonction est rendue possible par "godm" (Global ODM) mise en oeuvre pour le besoin.
Note: Pour la petite histoire, cette fonction utilise le langage PERL.
Le composant C-SPOC permet de faire des modifications sur un cluster actif. Les modifications engendrées par une commande du C-SPOC sont répercutées automatiquement sur tous les noeuds du cluster, soit immédiatement, soit au moment d'une bascule.
Les modifications possibles sont les suivantes :

Ajout/modification de groupes et d'utilisateurs sur tous les noeuds.
Modification de la topologie du cluster (noeuds, réseau, ressources).
Modification des volumes logiques et des systèmes de fichiers partagés décrits dans les ressources.
De telles modifications entraînent forcément des modifications en temps réel des ODM, sur la machine qui possède la ressource.
La synchronisation de l'ODM HACMP de l'autre machine doit alors être faite le plus vite possible, mais elle ne sera jamais automatique afin de vous laisser la maîtrise des modifications.
Si vous ne la provoquez pas, la synchronisation de l'ODM AIX sera automatique et contrôlée par HACMP au moment d'une bascule.
Dans la documentation HACMP, cela s'appelle : "lazy update".
Dans les versions précédentes, toute modification du cluster imposait l'arrêt d'HACMP pour faire les modifications et la synchronisation.
Les besoins rencontrés le plus souvent sont :

L'ajout et la suppression de LV et de FS dans les ressources HACMP.
L'agrandissement d'un LV ou d'un FS décrits comme ressources HACMP.
La maintenance des groupes et des utilisateurs.
On ne traite que de ces trois sujets dans ce document.

Mode de fonctionnement d'HACMP

Depuis HACMP V2, toutes les variables d'HACMP sont stockées dans les objets de l'ODM dont les noms suivent :
HACMPadapter HACMPfence HACMPnode HACMPcluster HACMPfence.vc HACMPresource HACMPcommand HACMPgroup HACMPserver HACMPdaemons HACMPnetwork HACMPsp2 HACMPevent HACMPnim
Ce que l'on appelle "variables", ce sont les informations qui permettent à HACMP de travailler dans l'environnement de l'utilisateur, variable en fonction de l'installation :

Les adresses IP, les VG, les LV, les FS, les groupes de ressources et les ressources.
Le mode de fonctionnement du cluster (rotating, cascading ou concurrent).
Les paramètres d'environnement tels que : inactive takover, utilisation de DNS, granuralité dans "hacmp.out".
Le Cluster Manager, les shell scripts des événements et les utilitaires qu'ils lancent, vont chercher, dans les objets HACMP de l'ODM, les informations dont ils ont besoin pour leur exécution et la réalisation des fonctions souhaitées.

ODM ET HACMP

Il existe trois copies de l'ODM, chacune ayant une fonction spécialisée.

1ère copie : DCD - Default Configuration Data
Les commandes appelées par SMIT, pour la personnalisation d'HACMP, travaillent dans les objets ODM du DCD (Default Configuration Data) du répertoire "/etc/objrepos".
Cet OMD n'existait pas en HACMP V1.
Depuis HACMP V2, et jusqu'à HACMP V4.2, il n'existait que cet ODM.
Pour des raisons de sécurité, il est clair qu'on ne pouvait pas modifier cet ODM quand HACMP était actif ; il fallait donc arrêter le cluster pour faire une modification de la configuration. Les commandes appelées par les menus "smit" de définition ou de modification de la topologie et des ressources se font toujours sur cet ODM.

2ème copie : ACD - Active Configuration Data
Depuis HACMP V4.2, quand on démarre HACMP sur un noeud, le DCD est recopié dans l'ACD (Active Configuration Data) du répertoire "/usr/sbin/cluster/etc/objrepos/active" ; tous les "démons" actifs d'HACMP ainsi que les utilitaires de "/usr/sbin/cluster/*" prennent leurs informations dans cet ODM.
GrÔce à cette copie "active", on peut faire des modifications sur la copie "par défaut".
Ce sont les opérations de synchronisation qui alignent ces deux ODM HACMP. Elles sont lancées, à votre demande, par les sous-menus de "smit" :

SYNCHRONIZE CLUSTER TOPOLOGIE
SYNCHRONIZE CLUSTER RESOURCES
Ces synchronisations sont obligatoires après chaque modification de topologie ou de ressource.
Juste avant une opération de reconfiguration dynamique, l'ACD est sauvegardé, par "snapshot" dans un fichier "/usr/sbin/cluster/snapshots/active.X.odm" où "X" est un chiffre de 0 à 9 avec 0 représentant toujours l'ACD le plus récent.
En cas de problème durant l'opération de reconfiguration dynamique (event reconfig FAILED), il sera toujours possible de lancer le sous-menu de "smit" :

RELEASE LOCKS SET BY DYNAMIC AUTOMATIC RECONFIGURATION EVENT
pour forcer le code retour à "0", puis de remettre la sauvegarde active ".0.odm" dans le DCD avec le sous-menu de "smit" :

RESTORE DEFAULT CONFIGURATION FROM ACTIVE CONFIGURATION

3ème copie : SCD - Stage Configuration Data du répertoire
Pendant une opération de reconfiguration dynamique, le DCD de la machine initiatrice est recopié dans le DCD des autres noeuds du cluster, puis ce DCD est recopié dans un ODM intermédiaire : le SCD (Stage Configuration Data) du répertoire "/usr/sbin/cluster/etc/objrepos/stage", avant que le SCD ne soit à son tour recopié dans l'ACD en même temps que les "démons" HACMP sont rafraîchis pour prendre en compte le nouvel ACD.
Le SCD est alors détruit.

L'ODM d'AIX et l'ODM d'HACMP

Il ne faut surtout pas confondre une modification de la configuration HACMP (topologie ou ressource), qui touche les objets ODM du DCD "/etc/objrepos/HACMP*", et les modifications d'un LV qui concernent l'ODM d'AIX ou les modifications d'un FS qui touchent "/etc/filesystems" et "CuAt" (si agrandissement de la taille du FS).
Pourtant un FS (et son LV) sont à la fois une ressource HACMP et une unité AIX.
Rappel :

La synchronisation des objets ODM HACMP se fait par les sous-menus de :
+--------------------------------------------------------------------------------+ | | |smit hacmp | | Cluster Configuration | | Cluster Topology | | Synchronize Cluster Topology | | Cluster Resources | | Synchronize Cluster Resources | | | +--------------------------------------------------------------------------------+

La synchronisation de l'ODM AIX se fait par :
+--------------------------------------------------------------------------------+ | | | ...... | |exportvg ..... | |importvg ..... | | ...... | | | +--------------------------------------------------------------------------------+

Reconfiguration dynamique (HACMP V4.2.1)

Les contextes 1 à 4 du chapitre : "Utilisation" donnaient la procédure de mise à jour de l'ODM en cas de modification de VG, LV ou FS.
L'explication détaillée de l'exemple du contexte 2 va permettre de voir le fonctionnement du "lazy update".

Les manipulations étaient les suivantes :
+--------------------------------------------------------------------------------+ | | |#sur la machine: delta | |smit lv #pour créer le LV | |smit fs #pour créer le FS | |smit hacmp | | Cluster Configuration | | Cluster Resources | | Configure a Resource Group #pour ajouter la ressource | | Synchronize Cluster Resources #pour synchroniser l'ODM HACMP | | #vérification automatique | |varyonvg -u -b vgdelta | | | |#sur la machine: beta | |lspv #pour repérer un disque du VG (ici hdisk4 ou 5) | |importvg -L vgdelta hdisk4 | | | |#sur la machine: delta | |varyonvg vgdelta | | | +--------------------------------------------------------------------------------+
On constate que l'on n'arrête pas HACMP pour faire une modification de ressource ; c'est le premier point fort.
De plus, nous faisons la mise à jour de l'ODM car, dans notre hypothèse, nous pouvons utiliser "importvg -L" avec le "bos.rte.lvm V4.2.1.4".
Mais, en fait, avec HACMP V4.2.x, il n'est pas nécessaire de faire l'"importvg" car HACMP s'en chargera automatiquement (lazy update) à la prochaine bascule du noeud modifié sur le noeud de secours.
Par contre, il est important de bien comprendre comment fonctionne la synchronisation. En effet, dans le menu qui suit, selon que l'on répondra "Yes" ou "No", on risque de perturber le bon fonctionnement d'HACMP.
Le moment venu, on reviendra en détail sur ce menu :
+--------------------------------------------------------------------------------+ | | | Synchronize Cluster Resources | | | | [Zones d'entrées] | | Ignore Cluster Verification Errors? [No] | | Un/Configure Cluster Resources? [Yes] or [No] | | | +--------------------------------------------------------------------------------+

Ajout d'un système de fichiers

La théorie
Hypothèse :

HACMP est actif sur les deux noeuds beta et delta.
Besoin :

On veut ajouter un FS "DELTANEW" dans le VG actif "vgdelta" sur le noeud delta.

Conséquences pour AIX :

Il faut créer un LV et un FS sur la machine où le VG est actif.
Il faut mettre à jour le fichier "/etc/filesystems" de l'autre noeud.
Il faudra aussi synchroniser l'ODM AIX de l'autre noeud pour qu'il connaisse aussi le nouveau LV.
Conséquences pour HACMP :

Il faut changer la ressource HACMP.
Il faut synchroniser les ressources HACMP sur tous les noeuds.

Le détail des opérations

Créer le LV : "smit lv"
+--------------------------------------------------------------------------------+ | | | Volumes logiques | | | | Liste des volumes logiques par groupe de volumes | | Ajout d'un volume logique <--------------choix | | Définition caractéristiques volume logique | | Affichage caractéristiques volume logique | | Retrait d'un volume logique | | Copie d'un volume logique | | | +--------------------------------------------------------------------------------+

Ajouter le LV en tenant compte des impératifs d'implantation physique et de miroir.
Dans cet exemple, il y a deux copies "miroir" réparties sur "hdisk4" et "hdisk5".
+--------------------------------------------------------------------------------+ | | | Ajout volume logique | | | | Nom volume logique [lvDELTANEW] | | Nom groupe de volumes vgdelta | | Nombre de partitions logiques [4] | | Noms de volume physique [hdisk4 hdisk5] | | Type volume logique [] | | Emplacement sur volume physique milieu | | Gamme de volumes physiques minimum | | Nombre maximal de volumes physiques [] | | utilisés pour l'allocation | | Nombre de copies pour chaque 2 | | partition logique | | Cohérence de l'écriture miroir? oui | |[PLUS...12] | | | +--------------------------------------------------------------------------------+

Créer le FS : "smit fs".
+--------------------------------------------------------------------------------+ | | | Système de fichiers | | | | Liste des systèmes de fichiers | | Liste des systèmes de fichiers montés | | Ajout/modif/affich/suppr systèmes de fichiers <-------choix | | Montage d'un système de fichiers | | Montage d'un groupe de systèmes de fichiers | | Démontage d'un système de fichiers | | Démontage d'un groupe de systèmes de fichiers | | Vérification d'un système de fichiers | | Sauvegarde d'un système de fichiers | | Restauration d'un système de fichiers | | Affichage du contenu d'une sauvegarde | | | +--------------------------------------------------------------------------------+

+--------------------------------------------------------------------------------+ | | | Ajout/modif/affich/suppr systèmes de fichiers | | | | Système de fichiers journalisés <----------choix | | Systèmes de fichiers CD-ROM | | Network File System (NFS) | | | +--------------------------------------------------------------------------------+

+----------------------------------------------------------------------------------------+ | | | Système de fichiers journalisés | | | | Ajout d'un système de fichiers journalisé | | Ajout d'un système de fichiers journalisé à un volume logique déjà défini <--- | | Modif/affich caractéristiques d'un système de fichiers journalisé | | Retrait d'un système de fichiers journalisé | | Défragmentation d'un système de fichiers journalisé | | | +----------------------------------------------------------------------------------------+

+--------------------------------------------------------------------------------+ | | | Ajout d'un système de fichiers journalisé à un volume logique déjà défini | | | | Ajout d'un système de fichiers standard <---------choix | | Ajout d'un système de fichiers journalisé compressé | | Ajout syst. fich. journalisé (fichiers volumineux pris en charge) | | | +--------------------------------------------------------------------------------+

Sélecter le LV déjà défini, donner le point de montage et choisir "automount=no".
+--------------------------------------------------------------------------------+ | | | Ajout d'un système de fichiers journalisé standard | | | | [Zones d'entrée] | |* Nom du volume logique lvDELTANEW | |* Point de montage [/DELTANEW] | | Montage automatique lors de l'Init-Système? non | | Droits d'accès lecture-écriture | | Options de montage [] | | Démarrage comptabilité d'utilisat. du disque ? non | | Taille de fragment (octets) 4096 | | Nombre d'octets par i-node 4096 | | Taille du groupe d'allocation (Mo) 8 | | | +--------------------------------------------------------------------------------+

+--------------------------------------------------------------------------------+ | | | ETAT DE LA COMMANDE | | | |Commande: OK stdout: oui stderr: non | | | |Selon les paramètres sélectés, la taille maximale du nouveau | |système de fichiers journalisé /DELTANEW est de 134217728 (blocs de 512 octets) | | | |Taille du nouveau système de fichiers: 32768 | | | +--------------------------------------------------------------------------------+

Maintenant que le FS est créé, il faut le charger.
+--------------------------------------------------------------------------------+ | | |# ici chargement des données | | | +--------------------------------------------------------------------------------+

Jusqu'ici, c'était de l'AIX "de base"...
Une fois que le FS est chargé, on veut l'utiliser (sinon pourquoi l'avoir créé?).
Il faut donc modifier les ressources HACMP pour tenir compte de ce nouveau FS.
+--------------------------------------------------------------------------------+ | | | smit hacmp | | | +--------------------------------------------------------------------------------+

+--------------------------------------------------------------------------------+ | | | HACMP for AIX | | | | Cluster Configuration <---------choix | | Cluster Services | | Cluster System Management | | Cluster Recovery Aids | | RAS Support | | | +--------------------------------------------------------------------------------+

+--------------------------------------------------------------------------------+ | | | Cluster Configuration | | | | Cluster Topology | | Cluster Resources <---------choix | | Cluster Snapshots | | Cluster Verification | | Restore System Default Configuration from Active Configuration | | | +--------------------------------------------------------------------------------+

+--------------------------------------------------------------------------------+ | | | Cluster Resources | | | | Define Resource Groups | | Define Application Servers | | Change/Show Resources for a Resource Group <------------choix | | Change/Show Run-Time Parameters | | Change/Show Cluster Events | | Change/Show Cluster Lock Manager Resource Allocation | | Show Cluster Resources | | Synchronize Cluster Resources | | | +--------------------------------------------------------------------------------+

Ajouter le FS dans la liste des "filesystems".
+--------------------------------------------------------------------------------+ | | | Configure a Resource Group | | | |[HAUT] [Zones d'entrées] | | Resource Group Name resource_delta | | Node Relationship cascading | | Participating Node Names delta beta | | | | Service IP Label [delta] | | HTY Service IP Label [] | | Filesystems -------> ajout du FS [/DELTANEW /delta1 /delta2]| | Filesystems to Export [] | | Filesystems to NFS Mount [] | | Volume Groups [] | | Concurrent Volume Groups [] | | Raw Disk PVIDs [] | |[PLUS...6] | | | +--------------------------------------------------------------------------------+

Il faut maintenant synchroniser les ressources sur tous les noeuds.
ATTENTION : les valeurs par défaut ne conviennent pas dans tous les cas.

Avant de poursuivre l'explication, il faut regarder le menu et les réponses possibles...
+--------------------------------------------------------------------------------+ | | | Synchronize Cluster Resources | | | | [Zones d'entrées] | | Ignore Cluster Verification Errors? [No] | | Un/Configure Cluster Resources? [Yes] | | | +--------------------------------------------------------------------------------+

OPTION
ROLE
Ignore Cluster Verification Errors ?
NO = Il n'ignore pas les erreurs rencontrées et ne fera pas la mise à jour s'il y a une erreur.
YES = Il ignore les erreurs rencontrées et fait la mise à jour, qu'il y ait erreur ou non.
Ne répondre YES qu'en connaissance de cause.
Un/Configure Cluster Resources ?
NO = Il ne répercutera pas les modifications sur la configuration actuelle.
Par exemple : il ne fait pas le "mount" du nouveau FS.
Il ne déclenche pas d'événement HACMP de reconfiguration et HACMP continue de travailler avec l'ACD.
YES = il répercute immédiatement les modifications.
Par exemple : il fait le mount du nouveau FS.
Il déclenche un événement HACMP de reconfiguration qui va recopier le DCD dans le ACD.

On revient à l'exemple et on suppose que l'on répond :
+--------------------------------------------------------------------------------+ | | | Ignore Cluster Verification Errors? [No] | | | +--------------------------------------------------------------------------------+
En l'état actuel des choses, il va forcément y avoir une erreur car le nouveau FS n'est pas connu des autres noeuds. C'est ce qui est montré sur l'état qui suit...

Bien que l'on sache d'avance que HACMP va refuser de faire la synchronisation, il est fortement RECOMMANDE (pour ne pas écrire INDISPENSABLE) de faire un premier passage "en l'état" pour être sűr qu'il ne rencontre pas d'autres erreurs.
Dans la liste suivante, regarder le résultat sur les lignes repérées par des "???????".
+--------------------------------------------------------------------------------+ | | | ETAT DE LA COMMANDE | | | |Commande: OK stdout: oui stderr: non | | | |Il se peut que des instructions supplémentaires s'affichent ci-dessous | |avant que la commande ait fini de s'exécuter. | | | |[HAUT] | |Verification to be performed on the following: | | Cluster Topology | | Cluster Resources | | | |Retrieving Cluster Topology... | |Verifying Cluster Topology... | |Verifying Cluster Resources... | | | |Retrieving Resources from Node: beta... | | | |Retrieving Resources from Node: delta... | | | |Performing security mode consistency check. | |------------------------------------------- | | | |Verifying Resource Group: resource_beta | |------------------------- | | | |Verifying Resources on each Node... | | | | | |Verifying SERVICE_LABEL: beta | |Verifying Filesystem: /beta2 | |Verifying Filesystem: /beta1 | | | |Verifying Resource Group: resource_delta | |------------------------- | | | |Verifying Resources on each Node... | | | |Verifying SERVICE_LABEL: delta | |?????????????????????? ERREUR ATTENDUE ?????????????????????? | |Verifying Filesystem: /DELTANEW | |ERROR: Filesystem '/DELTANEW' not configured on Node 'beta' | |????????????????????????????????????????????????????????????? | |... | | | +--------------------------------------------------------------------------------+

+--------------------------------------------------------------------------------+ | | |... | | | |Verifying Filesystem: /delta1 | |Verifying Filesystem: /delta2 | | | |Verifying Resources across Resource Groups | |------------------------------------------ | | | | | |Verifying Application Servers | |----------------------------- | |Verifying Server: application_beta on Node beta | |Verifying Server: application_beta on Node delta | |Verifying Server: application_delta on Node delta | |Verifying Server: application_delta on Node beta | | | |Verifying Cluster Events on Individual Nodes | |-------------------------------------------- | | | |Verification has completed normally. | |Verifying Events on Node: beta | |Verifying Events on Node: delta | | | |cldare: Failures detected during verification. Please correct | |the errors and retry this command. | | | +--------------------------------------------------------------------------------+

Après avoir vérifié qu'il n'y pas d'autres erreurs que celles attendues, ou les avoir corrigées, repasser la commande avec l'option permettant "de forcer la synchronisation même s'il y a une erreur" :
+--------------------------------------------------------------------------------+ | | | Synchronize Cluster Resources | | | | [Zones d'entrées] | | Ignore Cluster Verification Errors? [Yes] <----choix | | Un/Configure Cluster Resources? [Yes] | | | +--------------------------------------------------------------------------------+

Etudier maintenant l'option suivante : .
+--------------------------------------------------------------------------------+ | | | Un/Configure Cluster Resources? [Yes] | | | +--------------------------------------------------------------------------------+
Que cache cette question dans le cas de l'exemple ?
Faut-il répondre "Yes" ou "No" ?
Il faut répondre "Yes". En effet, la ressource que l'on vient d'ajouter doit être configurée, c'est-à-dire le FS monté immédiatement sur la machine.
Pourquoi immédiatement ?
La synchronisation ayant été forcée, le DCD sera copié dans l'ACD qui va ainsi connaître "/DELTANEW".
Si l'on demande alors un arrêt "gracefull" ou "takeover" de HACMP, ce dernier va dérouler l'événement "release_disk_vg_fs" ; il va trouver le FS "/DELTANEW" et il va essayer de le démonter. S'il n'était pas monté, l'événement serait alors déclaré "FAILED", et votre arrêt aussi...

Le résultat

En forçant la synchronisation et en demandant la reconfiguration, on obtient :
+--------------------------------------------------------------------------------+ | | |Verification to be performed on the following: | | Cluster Topology | | Cluster Resources | | | |Retrieving Cluster Topology... | |Verifying Cluster Topology... | |Verifying Cluster Resources... | | | |Retrieving Resources from Node: beta... | | | |Retrieving Resources from Node: delta... | | | |Performing security mode consistency check. | |------------------------------------------- | | | |Verifying Resource Group: resource_beta | |------------------------- | | | |Verifying Resources on each Node... | | | | | |Verifying SERVICE_LABEL: beta | |Verifying Filesystem: /beta2 | |Verifying Filesystem: /beta1 | | | |Verifying Resource Group: resource_delta | |------------------------- | | | |Verifying Resources on each Node... | | | | | |Verifying SERVICE_LABEL: delta | |?????????????????? même erreur signalée ?????????????????? | |Verifying Filesystem: /DELTANEW | |ERROR: Filesystem '/DELTANEW' not configured on Node 'beta' | |?????????????????????????????????????????????????????????? | | | |Verifying Filesystem: /delta1 | |Verifying Filesystem: /delta2 | | | |Verifying Resources across Resource Groups | |------------------------------------------ | | | |Verifying Application Servers | |----------------------------- | |Verifying Server: application_beta on Node beta | |Verifying Server: application_beta on Node delta | |Verifying Server: application_delta on Node delta | |Verifying Server: application_delta on Node beta | | | |Verifying Cluster Events on Individual Nodes | |-------------------------------------------- | |... | | | +--------------------------------------------------------------------------------+

+--------------------------------------------------------------------------------+ | | |... | | | |Verification has completed normally. | |Verifying Events on Node: beta | |Verifying Events on Node: delta | | | |Verifying additional pre-requisites for Dynamic Reconfiguration... | | ...completed. | | | +--------------------------------------------------------------------------------+

Malgré les erreurs, la synchronisation aura quand même lieu car elle a été forcée.
+---------------------------------------------------------------------------------+ | | |Contacting node beta ... | |Succeeded in synchronizing HACMPgroup ODM to the remote node beta. | | | |Contacting node beta ... | |Succeeded in synchronizing HACMPresource ODM to the remote node beta. | | | |Contacting node beta ... | |Succeeded in synchronizing HACMPserver ODM to the remote node beta. | | | |Contacting node beta ... | |Succeeded in synchronizing HACMPevent ODM to the remote node beta. | | | |Contacting node beta ... | |Succeeded in synchronizing HACMPnode ODM to the remote node beta. | | | |Adding any necessary HACMP for AIX entries to /etc/inittab and /etc/rc.net for I | |Address Takeover on node beta. | |Adding any necessary HACMP for AIX entries to /etc/inittab and /etc/rc.net for I | |Address Takeover on node delta. | | | | | |clsnapshot: Creating file /usr/sbin/cluster/snapshots/active.0.odm. | | | |clsnapshot: Succeeded creating Cluster Snapshot: active.0 | | | |cldare: Requesting a refresh of the Cluster Manager... | |0513-095 La demande de régénération du sous-système a abouti. | | ...completed. | | | +---------------------------------------------------------------------------------+

En visualisant, sur beta, le fichier "/usr/sbin/cluster/history/cluster.MMJJ", on peut constater la conséquence de la réponse : "Un/Configure .../* * = yes" dans le menu de synchronisation.
+--------------------------------------------------------------------------------+ | | | ....... | |sep 19 13:30:08 EVENT START: reconfig_resource_release | |sep 19 13:30:47 EVENT COMPLETED: reconfig_resource_release | |sep 19 13:30:48 EVENT START: reconfig_resource_acquire | |sep 19 13:30:57 EVENT COMPLETED: reconfig_resource_acquire | |sep 19 13:31:15 EVENT START: reconfig_resource_complete | |sep 19 13:31:27 EVENT COMPLETED: reconfig_resource_complete | | ....... | | | +--------------------------------------------------------------------------------+

En visualisant, sur delta, le fichier "/usr/sbin/cluster/history/cluster.MMJJ", on peut constater la conséquence de la réponse : "Un/Configure = yes" dans le menu de synchronisation.
+--------------------------------------------------------------------------------+ | | | ....... | |sep 19 13:30:55 EVENT START: reconfig_resource_release | |sep 19 13:31:28 EVENT COMPLETED: reconfig_resource_release | |sep 19 13:31:35 EVENT START: reconfig_resource_acquire | |sep 19 13:31:41 EVENT START: get_disk_vg_fs /DELTANEW | |sep 19 13:31:56 EVENT COMPLETED: get_disk_vg_fs /DELTANEW | |sep 19 13:32:00 EVENT COMPLETED: reconfig_resource_acquire | |sep 19 13:32:02 EVENT START: reconfig_resource_complete | |sep 19 13:32:14 EVENT COMPLETED: reconfig_resource_complete | | ....... | | | +--------------------------------------------------------------------------------+

En passant la commande "mount"sur delta, on peut constater que ce nouveau FS a été monté, toujours à cause de la réponse : "Un/Configure = yes"...
+----------------------------------------------------------------------------------+ | | | noeud monté monté sur vfs date options | |-------- --------------- --------------- ------ ------------ --------------- | | /dev/hd4 / jfs 18 sep 18:56 rw,log=/dev/hd8 | | /dev/hd2 /usr jfs 18 sep 18:56 rw,log=/dev/hd8 | | /dev/hd9var /var jfs 18 sep 18:56 rw,log=/dev/hd8 | | /dev/hd3 /tmp jfs 18 sep 18:56 rw,log=/dev/hd8 | | /dev/hd1 /home jfs 18 sep 18:57 rw,log=/dev/hd8 | | /dev/delta1 /delta1 jfs 19 sep 13:12 rw,log=/dev/loglv | | /dev/delta2 /delta2 jfs 19 sep 13:12 rw,log=/dev/loglv | | /dev/lsDELTANEW /DELTANEW jfs 19 sep 13:31 rw,log=/dev/loglv | | | +----------------------------------------------------------------------------------+

Lazy update

Si, maintenant, les objets de l'ODM HACMP sont à jour, il n'en est pas de même de l'ODM AIX sur l'autre machine...
Si une bascule se produit, HACMP détectera une désynchronisation de l'ODM AIX et, automatiquement, il provoquera un "lazy update" sous la forme d'un "exportvg / importvg" sur la machine. Ce que nous allons constater dans les lignes qui suivent.
Dans la documentation du produit, il est cependant conseillé de provoquer cette bascule pour s'assurer que tout va bien. En effet, si on laisse faire, cette bascule pourra se produire n'importe quand, et, s'il y a un incident quelconque, il n'y aura peut-être personne pour réagir.
QUESTIONS :
Pourquoi ces précautions ? Pourquoi y aurait-il un incident ? Cette fonction ne serait-elle pas sűre ?
REPONSES :
La fonction est sűre et il n'y a pas de raison pour qu'elle provoque un incident. Mais il peut y avoir eu d'autres modifications non testées elles-mêmes... Donc, dans le doute, il vaut mieux faire le test : ce sera une bascule programmée, on pourra le faire à un moment de faible activité, et on pourra aussi prévenir les utilisateurs.
Pour provoquer la bascule, on fait un "clstop" avec "takeover", comme suit :
+--------------------------------------------------------------------------------+ | | | Stop Cluster Services | | | | | | [Zones d'entrées] | |* Stop now, on system restart or both now | | | | BROADCAST cluster shutdown? true | |* Shutdown mode takeover | | (graceful, graceful with takeover, forced) | | | +--------------------------------------------------------------------------------+
En visualisant, sur delta, le fichier "/usr/sbin/cluster/history/cluster.0919", on constate que le FS DELTANEW est bien pris en compte et démonté, preuve que son ajout avait bien été fait dynamiquement.
+--------------------------------------------------------------------------------+ | | |sep 19 13:42:34 EVENT START: node_down delta graceful (with takeover) | |sep 19 13:42:37 EVENT START: node_down_local | |sep 19 13:42:38 EVENT START: stop_server application_delta | |sep 19 13:42:41 EVENT COMPLETED: stop_server application_delta | |sep 19 13:42:42 EVENT START: release_vg_fs /DELTANEW /delta1 /delta2 | |sep 19 13:42:57 EVENT COMPLETED: release_vg_fs /DELTANEW /delta1 /delta2 | | | +--------------------------------------------------------------------------------+
Parallèlement, on constate bien, sur beta, dans "/tmp/hacmp.out" que, dans l'événement "get_disk_vg_fs", il y a un exportvg suivi d'un importvg.
+--------------------------------------------------------------------------------+ | | |+ exportvg vgdelta | |+ [[ 0 -ne 0 ]] | |+ importvg -V 40 -y vgdelta hdisk3 | |+ [[ 0 -ne 0 ]] | | | |+ rm -f /usr/sbin/cluster/etc/vg/vgdelta.replay | |+ varyoffvg vgdelta | |+ 1> /dev/null 2>& 1 | |+ [[ y = n ]] | |+ chvg -a n vgdelta | |+ [[ 0 -ne 0 ]] | |+ clvgdats hdisk3 | |+ 1> /usr/sbin/cluster/etc/vg/vgdelta | |+ [[ 0 -ne 0 ]] | |+ [[ FALSE = FALSE ]] | |+ varyonvg -n vgdelta | |+ [[ 0 -ne 0 ]] | |+ exit 0 | | | +--------------------------------------------------------------------------------+
Précédant cet "exportvg / importvg", on peut trouver l'appel de la commande clvgdats.
Cette commande a deux fonctions :

Lire, dans le VGDA, le "time stamp" de la mise à jour. C'est dans ce but qu'elle est utilisée ici. En voici la syntaxe :
+--------------------------------------------------------------------------------+ | | | /usr/sbin/cluster/utilities/clvgdats /dev/nom_du_vg | | | +--------------------------------------------------------------------------------+

Mettre à jour le fichier HACMP : "/usr/sbin/cluster/etc/vg/nom_du_vg".
L'utilisation en sera montrée plus loin, au paragraphe "Commande "clvgdats"".
En voici la syntaxe :
+----------------------------------------------------------------------------------+ | | | /usr/sbin/cluster/utilities/clvgdats hdiskX 1> /usr/sbin/cluster/etc/vg/nom_du_ | | | +----------------------------------------------------------------------------------+
(où hdiskXest le nom d'un disque du VG où la commande "clvgdats" ira lire la VGDA).

Suppression d'un système de fichiers

Voici maintenant un exemple de suppression d'un FS des ressources en HACMP V4.2.x.

Hypothèses

On veut supprimer le FS /DELTANEW.
HACMP est actif sur les deux machines.
La "ressource_delta" est active sur le noeud delta.

Mode opératoire

Démonter le répertoire après s'être assuré qu'aucun utilisateur ne travaille avec lui.
+--------------------------------------------------------------------------------+ | | |umount /DELTANEW | | | +--------------------------------------------------------------------------------+

Il faut ensuite accéder aux menus HACMP adéquats.
+--------------------------------------------------------------------------------+ | | | HACMP for AIX | | | | Cluster Configuration | | Cluster Services | | Cluster System Management <----------choix | | Cluster Recovery Aids | | RAS Support | | | +--------------------------------------------------------------------------------+

+--------------------------------------------------------------------------------+ | | | Cluster System Management | | | | Cluster Users & Groups | | Cluster Logical Volume Manager <-----------choix | | HACMP for AIX Cluster Services | | | +--------------------------------------------------------------------------------+

Il faut sélectionner le bon FS bien sűr, mais aussi la bonne ressource.
+--------------------------------------------------------------------------------+ | | | Shared File Systems | | | | List All Shared File Systems | | Change / Show Characteristics of a Shared File System | | Remove a Shared File System | | | | [HAUT] | | resource_beta /beta1 | | resource_beta /delta1 | | resource_beta /DELTANEW | | resource_beta /beta2 | | resource_beta /delta2 | | resource_delta /beta1 | | resource_delta /delta1 | | resource_delta /DELTANEW <-----------choix | | resource_delta /beta2 | | resource_delta /delta2 | | [BAS] | | | +--------------------------------------------------------------------------------+

Supprimer alors le FS de la ressource.
+--------------------------------------------------------------------------------+ | | | Remove a Journaled File System from the Cluster | | | | [Zones d'entrées] | | Resource Group Name resource_delta | | Nom du système de fichiers /DELTANEW | | Remove Mount Point non | | | +--------------------------------------------------------------------------------+

La suppression du FS entraîne également la suppression du LV.
+--------------------------------------------------------------------------------+ | | | ETAT DE LA COMMANDE | | | |Commande: OK stdout: oui stderr: non | | | |Il se peut que des instructions supplémentaires s'affichent ci-dessous | |avant que la commande ait fini de s'exécuter. | | | |delta: rmlv: le volume logique lvDELTANEW est supprimé. | | | +--------------------------------------------------------------------------------+

Il faut ensuite modidier la ressource
+--------------------------------------------------------------------------------+ | | | Configure a Resource Group | | | |[HAUT] [Zones d'entrées] | | Resource Group Name resource_delta | | Node Relationship cascading | | Participating Node Names delta beta | | | | Service IP Label [delta] | | HTY Service IP Label [] | | Filesystems --------> suppression de DELTANEW [/delta1 /delta2] | | Filesystems to Export [] | | Filesystems to NFS Mount [] | | Volume Groups [vgdelta] | | Concurrent Volume Groups [] | | Raw Disk PVIDs [] | | | +--------------------------------------------------------------------------------+

Et il faut synchroniser les ressources.
+--------------------------------------------------------------------------------+ | | | Cluster Resources | | | | Define Resource Groups | | Define Application Servers | | Change/Show Resources for a Resource Group | | Change/Show Run-Time Parameters | | Change/Show Cluster Events | | Change/Show Cluster Lock Manager Resource Allocation | | Show Cluster Resources | | Synchronize Cluster Resources <----------choix | | | +--------------------------------------------------------------------------------+

ATTENTION - Il faut réfléchir à nouveau sur la réponse à donner à "Un/Configure".
Dans le cas présent, le FS a déjà été démonté (manuellement) et supprimé avec "smit". Si on laisse la valeur par défaut à "Yes", la reconfiguration dynamique essayera de démonter un FS qui a déjà été démonté et supprimé, et cela entrainera un "EVENT FAILED" pour le "release_disk_vg_fs".
+--------------------------------------------------------------------------------+ | | | Synchronize Cluster Resources | | | | [Zones d'entrées] | | Ignore Cluster Verification Errors? [No] | | Un/Configure Cluster Resources? [No] <------ choix | | | +--------------------------------------------------------------------------------+
L'opération est réalisée par le module cldare, qui envoie le résultat de l'opération sur l'écran suivant :
+--------------------------------------------------------------------------------+ | | | ETAT DE LA COMMANDE | | | |Commande: OK stdout: oui stderr: non | | | |Il se peut que des instructions supplémentaires s'affichent ci-dessous | |avant que la commande ait fini de s'exécuter. | | | | | |cldare: Succeeded removing all DARE locks. | | | +--------------------------------------------------------------------------------+

Agrandir un FS

Cette option n'est pas proposée dans les sous-menus de HACMP.
Il suffit de passer par les sous-menus :
+--------------------------------------------------------------------------------+ | | |smit fs | | | +--------------------------------------------------------------------------------+
Il faut se rappeler qu'agrandir un FS agrandit automatiquement le LV correspondant.
Que va changer cette opération dans l'ODM AIX ?
Uniquement la taille du LV.
Que va changer cette opération dans l'ODM HACMP ?
Rien, Il ne figure que le répertoire de montage.
Que reste-t-il à faire ?
Rien...
En effet, HACMP détectera que l'ODM AIX a été modifié (clvgdats). Il fera donc automatiquement un "lazy update" à la première bascule.

Modification du point de montage

En l'état actuel des PTF à notre disposition, nous n'avons pas réussi cette opération.
Nous n'avons pas non plus trouvé de bypass.
Nous vous déconseillons donc d'essayer...

Commande "clvgdats"

En HACMP V4.2.x, dans l'événement "get_disk_vg_fs", la commande clvgdats est utilisée pour vérifier que le "time stamp" du VGDA est identique, ou plus récent, que celui conservé dans le fichier "/var/sbin/cluster/vg/nom_du_vg".
Si le VGDA du disque est plus récent, automatiquement HACMP fait un "lazy update" pour synchroniser l'ODM AIX, et il met à jour le fichier "/var/sbin/cluster/vg/nom_du_vg" en prévision de la prochaine bascule.
Reprenons l'exemple qui correspond au paragraphe "Contexte 2 : AIX V4.2 + "bos.rte.lvm" V4.2.1.4 + HACMP V4.2.x"
+--------------------------------------------------------------------------------+ | | |#sur la machine: delta | |smit lv #pour créer le LV | |smit fs #pour créer le FS | |smit hacmp | | Cluster Configuration | | Cluster Resources | | Configure a Resource Group #pour ajouter la ressource | | Synchronize Cluster Resources #pour synchroniser l'ODM HACMP | | #vérification automatique | | | | [Zones d'entrées] | | Ignore Cluster Verification Errors? [No] | | Un/Configure Cluster Resources? [Yes] or [No] | |varyonvg -u -b vgdelta | | | |#sur la machine: beta | |lspv #pour repérer un disque du VG (ici hdisk4 ou 5) | |importvg -L vgdelta hdisk4 | | | |#sur la machine: delta | |varyonvg vgdelta | | | +--------------------------------------------------------------------------------+
On fait soi-même la modification de l'ODM AIX, grÔce à :

"varyonvg -u -b vgdelta"
puis "importvg -L vgdelta"
et "varyonvg vgdelta".

Cette opération est correcte, mais elle n'est pas obligatoire car HACMP V4.2.x fera quand même le "lazy update".
Pourquoi ?
Parce que la commande "importvg -l vgdelta" ne va pas modifier le fichier : "/var/sbin/cluster/vg/vgdelta".
On peut le regretter, mais c'est normal ; "importvg" est une commande d'AIX mais pas une commande HACMP ; elle devrait regarder si HACMP est installé et dans quelle version...
Ce n'est pas la règle en UNIX, où, par principe, une commande correspond à une fonction,
Alors, pour être "parfait", et se charger de tout à la place d'HACMP, il faudrait procéder de la façon suivante :
+--------------------------------------------------------------------------------+ | | |#sur la machine: delta | |smit lv #pour créer le LV | |smit fs #pour créer le FS | |smit hacmp | | Cluster Configuration | | Cluster Resources | | Configure a Resource Group #pour ajouter la ressource | | Synchronize Cluster Resources #pour synchroniser l'ODM HACMP | | #vérification automatique | | | | [Zones d'entrées] | | Ignore Cluster Verification Errors? [No] | | Un/Configure Cluster Resources? [Yes] or [No] | |varyonvg -u -b vgdelta | |#sur la machine: beta | |lspv #pour repérer un disque du VG (ici hdisk4 ou 5) | |importvg -L vgdelta hdisk4 | |/usr/sbin/cluster/utilities/clvgdats hdisk4 1> /usr/sbin/cluster/etc/vg/vgdelta | | | |#sur la machine: delta | |varyonvg vgdelta | | | +--------------------------------------------------------------------------------+
En procédant ainsi, on gagnera un peu de temps au moment de la bascule, car HACMP ne fera pas son "lazy udate".
Mais il vaut mieux ne pas le faire que de le faire mal,
Si on laisse faire HACMP, la manipulation devient alors :
+--------------------------------------------------------------------------------+ | | |#sur la machine: delta | |smit lv #pour créer le LV | |smit fs #pour créer le FS | |smit hacmp | | Cluster Configuration | | Cluster Resources | | Configure a Resource Group #pour ajouter la ressource | | Synchronize Cluster Resources #pour synchroniser l'ODM HACMP | | #vérification automatique | | | | [Zones d'entrées] | | Ignore Cluster Verification Errors? [No] | | Un/Configure Cluster Resources? [Yes] or [No] | | | +--------------------------------------------------------------------------------+

Reprise en cas d'incident

Les incidents qui peuvent se produire sont de deux types :

1- Mauvais choix dans les menus
Par exemple, une réponse "Yes" au lieu de "No" à l'invite "Un/Configure...".
Dans ce cas, l'événement "reconfig" sera : "EVENT FAILED", et le "clstrmgr", ne recevant pas de code retour 0, bouclera sur cette fin
Pour sortir de cette impasse, il est impératif de :

Déverrouiller le "clstrmgr"avec les options présentées dans le menu suivant,
Refaire une tentative de synchronisation.

+--------------------------------------------------------------------------------+ | | | Cluster Recovery Aids | | | | Recover From Script Failure | | Release Locks Set By Dynamic Automatic Reconfiguration Event <-------choix | | Clear 9333 Disk Fence Registers | | Clear SSA Disk Fence Registers | | | +--------------------------------------------------------------------------------+

2- Coupure entre "exportvg" et "importvg"
Rappel : "exportvg" vide l'ODM AIX de toutes les informations du VG spécifié.
Tant que l'"imporvg" n'est pas terminé correctement, la machine ne connaît plus rien de ce VG ni de ses LV et FS.
Même si la machine est réinitialisée (re-boot) et HACMP relancé, ce dernier ne peut pas redémarrer. En effet, la ressource HACMP demande le VG mais ne trouve rien dans l'ODM, et le "clstrmgr" boucle sur "EVENT FAILED" de "get_disk_vg_fs".
Dans cas, il n'y a qu'une solution : arrêter HACMP sur tous les noeuds, puis faire manuellement l'"importvg" et le "chvg" qui doit suivre.
Ceci est indiqué dans les commandes suivantes :
+--------------------------------------------------------------------------------+ | | | importvg -y vgdelta -V maj_nod hdiskX #avec bon Major Node | | chvg -a n vgdelta #autovaryon=false | | chvg -Q n vgdelta #quorum=1 (si le cas) | | chown user.group vgdelta #si owner non root.system | | chown user.group lvdelta1 #si owner non root.system | | chown user.group lvdelta2 #si owner non root.system | | | +--------------------------------------------------------------------------------+

PTF pour HACMP
Les tests décrits dans ce document ne peuvent pas fonctionner sans les mises à jour qui mettent à niveau les modules suivants :
+--------------------------------------------------------------------------------+ | | |cluster.base.client.lib.usr.4.2.1.1 | |cluster.base.server.events.usr.4.2.1.1 | |cluster.base.server.events.4.2.1.2 | |cluster.base.server.rte.usr.4.2.1.1 | |cluster.base.server.utils.usr.4.2.1.1 | |cluster.cspoc.rte.4.2.1.1 | |cluster.cspoc.cmds.usr.4.2.1.1 | |cluster.haview.usr.4.2.1.1 | |cluster.msg.en_US.haview.usr.4.2.1.1 | |cluster.msg.en_US.server.usr.4.2.1.1 | |cluster.vsm.server.usr.4.2.1.1 | | | +--------------------------------------------------------------------------------+

Ajout et MAJ d'Utilisateurs ou de Groupes

+--------------------------------------------------------------------------------+ | | | HACMP for AIX | | | | Cluster Configuration | | Cluster Services | | Cluster System Management <------------choix | | Cluster Recovery Aids | | RAS Support | | | +--------------------------------------------------------------------------------+

+--------------------------------------------------------------------------------+ | | | Cluster System Management | | | |Move cursor to desired item and press Enter. | | | | Cluster Users & Groups <------------choix | | Cluster Logical Volume Manager | | HACMP for AIX Cluster Services | | | +--------------------------------------------------------------------------------+

+--------------------------------------------------------------------------------+ | | | Cluster Users & Groups | | | |Move cursor to desired item and press Enter. | | | | Users <------------choix | | Groups | | | +--------------------------------------------------------------------------------+
UTILISATEURS
+--------------------------------------------------------------------------------+ | | |Move cursor to desired item and press Enter. | | | | Add a User to the Cluster <------------choix | | Change / Show Characteristics of a User in the Cluster | | Remove a User from the Cluster | | List All Users in the Cluster | | | +--------------------------------------------------------------------------------+

+--------------------------------------------------------------------------------+ | | | Add a User to the Cluster | | | |Type or select a value for the entry field. | |Press Enter AFTER making all desired changes. | | | | [Entry Fields] | | Select nodes by Resource Group [] | | *** No selection means all nodes! *** | | | +--------------------------------------------------------------------------------+
Bien qu'il ne soit pas obligatoire de spécifier l'ID, il est conseillé de l'imposer. En effet :

Si vous imposez un ID, le système vérifie que celui-ci est libre sur tous les systèmes et ne le crée que si la condition est remplie.
Si vous n'imposiez pas l'ID, le système prendrait le premier disponible dans chaque "/etc/passwd"... L'utilisateur pourrait donc avoir un ID différent sur chaque noeud,

+--------------------------------------------------------------------------------+ | | | Add a User to the Cluster | | | |Type or select values in entry fields. | |Press Enter AFTER making all desired changes. | | | |[TOP] [Entry Field] | | Select nodes by resource group | | | |* User NAME [] | | User ID [] | | ADMINISTRATIVE USER? false | | Primary GROUP [] | | Group SET [] | | ADMINISTRATIVE GROUPS [] | | Another user can SU TO USER? true | | SU GROUPS [ALL] | | HOME directory [] | | Initial PROGRAM [] | | User INFORMATION [] | | EXPIRATION date (MMDDhhmmyy) [0] | | Is this user ACCOUNT LOCKED? false | | User can LOGIN? true | | User can LOGIN REMOTELY? true | | Allowed LOGIN TIMES [] | | Number of FAILED LOGINS before [0] | | user account is locked | | Login AUTHENTICATION GRAMMAR [compat] | | Valid TTYs [ALL] | | Days to WARN USER before password expires [0] | | Password CHECK METHODS [] | | Password DICTIONARY FILES [] | | NUMBER OF PASSWORDS before reuse [0] | | WEEKS before password reuse [0] | | Weeks between password EXPIRATION and LOCKOUT [\-1] | |... | | | +--------------------------------------------------------------------------------+

+--------------------------------------------------------------------------------+ | | |... | | Password MAX. AGE [0] | | Password MIN. AGE [0] | | Password MIN. LENGTH [0] | | Password MIN. ALPHA characters [0] | | Password MIN. OTHER characters [0] | | Password MAX. REPEATED characters [8] | | Password MIN. DIFFERENT characters [0] | | Password REGISTRY [] | | MAX. FILE size [2097151] | | MAX. CPU time [-1] | | MAX. DATA segment [262144] | | MAX. STACK size [65536] | | MAX. CORE file size [2048] | | File creation UMASK [022] | | AUDIT classes [] | | TRUSTED PATH? nosak | | PRIMARY authentication method [SYSTEM] | | SECONDARY authentication method [NONE] | | | +--------------------------------------------------------------------------------+

GROUPES
+--------------------------------------------------------------------------------+ | | | Groups | | | | List All Groups in the Cluster | | Add a Group to the Cluster <------------choix | | Change / Show Characteristics of a Group in the Cluster | | Remove a Group from the Cluster | | | +--------------------------------------------------------------------------------+
Les remarques valables pour la création d'utilisateurs s'appliquent également à l'ajout de groupes...

Chapitre 5. Conclusion
Pour mettre en évidence la nécessité de bien maîtriser ses actions quand on intervient sur son système, rien ne vaut une comparaison simple avec une situation que tout le monde connaît...
AIX, c'est comme une voiture bien réglée : on attend d'elle de pouvoir aller où l'on veut, quand on veut.
Si l'on n'est pas mécanicien et que l'on touche aux réglages du moteur, il y a de forts risques que ce dernier "cafouille"... si toutefois il consent à redémarrer,
Mais, même si l'on n'est pas mécanicien, on peut changer une roue. Mais bien sűr, pour cela il faut respecter les règles de sécurité et la procédure :

Etre sur un terrain plat non exposé.
Serrer le frein à main.
Mettre en route les feux de détresse et placer le "triangle de sécurité" à cinquante mètres du véhicule.
Préparer la roue de secours, le cric et la manivelle.
Débloquer les boulons.
Lever la voiture, déposer les boulons et déposer la roue.
Changer la roue, remettre les boulons et les serrer à la main.
Reposer la voiture et bloquer les boulons.
Ranger le cric et la roue crevée.
Récupérer le triangle, arrêter les feux de détresse et repartir.
Faire réparer la roue sans tarder...
Il ne s'agit pas ici de faire un cours de mécanique automobile, mais il faut se rendre à l'évidence : pour changer une roue...
... il faut faire dans l'ordre, toutes les opérations, .
De la même manière, il ne faut pas modifier HACMP ou le moteur AIX si l'on n'en maîtrise pas les commandes, et dans tous les cas il faut suivre le mode d'emploi, Chaque modification doit être faite, sans hÔte, en exécutant toutes les étapes.
A propos, avez vous remarqué que l'on n'a pas parlé des enjoliveurs, et que la manivelle a été oubliée sur le bord de la route ?
Que se passera-t-il à la prochaine crevaison ? ...
Ni AIX, ni HACMP ne sont fragiles ou capricieux ; ils sont seulement "binaires", Chaque commande est élémentaire, mais en oublier une implique forcément des conséquences... .

[ Top of Page | Previous Page | Next Page | Table of Contents ]

LES CAHIERS d'AIX Publication réservée aux abonnés du Point Service AIX Janvier 1998

LES CAHIERS d'AIX
Publication réservée aux abonnés du Point Service AIX
Janvier 1998