Guide d|mJadministration et...

Tivoli® System Automation for Multiplatforms

Guide d'administration et d'utilisation

Version 3.1

SC11-6299-00

��

Important

Avant d’utiliser le présent document et le produit associé, prenez connaissance des informations générales figurant à

l’Annexe D, «Remarques», à la page 329.

Réf. US : SC33-8415-00

LE PRESENT DOCUMENT EST LIVRE EN L’ETAT SANS AUCUNE GARANTIE EXPLICITE OU IMPLICITE. IBM

DECLINE NOTAMMENT TOUTE RESPONSABILITE RELATIVE A CES INFORMATIONS EN CAS DE

CONTREFACON AINSI QU’EN CAS DE DEFAUT D’APTITUDE A L’EXECUTION D’UN TRAVAIL DONNE.

Ce document est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. Les informations qui y

sont fournies sont susceptibles d’être modifiées avant que les produits décrits ne deviennent eux-mêmes

disponibles. En outre, il peut contenir des informations ou des références concernant certains produits, logiciels ou

services non annoncés dans ce pays. Cela ne signifie cependant pas qu’ils y seront annoncés.

Pour plus de détails, pour toute demande d’ordre technique, ou pour obtenir des exemplaires de documents IBM,

référez-vous aux documents d’annonce disponibles dans votre pays, ou adressez-vous à votre partenaire

commercial.

Vous pouvez également consulter les serveurs Internet suivants :

v http://www.fr.ibm.com (serveur IBM en France)

v http://www.can.ibm.com (serveur IBM au Canada)

v http://www.ibm.com (serveur IBM aux Etats-Unis)

Compagnie IBM France

Direction Qualité

Tour Descartes

92066 Paris-La Défense Cedex 50

© Copyright IBM France 2008. Tous droits réservés.

© Copyright International Business Machines Corporation 2006, 2008.

http://www.fr.ibm.com

http://www.can.ibm.com

http://www.ibm.com

Table des matières

Figures . . . . . . . . . . . . . . vii

Tableaux . . . . . . . . . . . . . . ix

Avis aux lecteurs canadiens . . . . . . xi

Présentation du manuel . . . . . . . xiii

A qui s’adresse ce manuel ? . . . . . . . . xiii

Utilisation de ce guide . . . . . . . . . . xiii

Où trouver des informations supplémentaires ? . . xiv

Conventions . . . . . . . . . . . . . . xiv

ISO 9000 . . . . . . . . . . . . . . . xv

Informations connexes . . . . . . . . . . . xv

Comment obtenir des publications . . . . . . xv

Comment nous contacter par e-mail . . . . . . xvi

Résumé des modifications . . . . . xvii

Nouveautés de la version 3.1 . . . . . . . . xvii

Chapitre 1. Introduction . . . . . . . . 1

Généralités . . . . . . . . . . . . . . . 1

Haute disponibilité et moniteur de ressources . . 1

Automatisation basée sur des règles . . . . . 1

Reprise sur incident automatique . . . . . . 2

Mouvement automatique des applications . . . 2

Regroupement de ressources . . . . . . . . 2

Termes de System Automation for Multiplatforms . . 3

Grappes et domaines homologues . . . . . . 3

Ressource . . . . . . . . . . . . . . 3

Attribut de ressource . . . . . . . . . . 3

Classe de ressources . . . . . . . . . . . 4

Groupe de ressources . . . . . . . . . . 4

Ressources gérées . . . . . . . . . . . . 4

Etat nominal . . . . . . . . . . . . . 4

Equivalence . . . . . . . . . . . . . . 4

Relations . . . . . . . . . . . . . . 5

Quorum . . . . . . . . . . . . . . . 5

Condition de départage . . . . . . . . . . 6

Console d’opérations . . . . . . . . . . 6

Adaptateur d’automatisation de bout en bout . . 6

Intégration complète de RSCT à System Automation

for Multiplatforms . . . . . . . . . . . . 7

Gestionnaires de ressources fournis par RSCT et

System Automation for Multiplatforms . . . . 7

Utilisation de System Automation for

Multiplatforms sous Windows . . . . . . . . 10

Chapitre 2. Mise en route . . . . . . . 11

Etape 1 : Définition et administration d’une grappe 12

Présentation des commandes . . . . . . . 12

Création d’une grappe composée de deux noeuds 13

Configuration d’une condition de départage . . 15

Ajout d’un noeud dans une grappe existante . . 15

Mise hors ligne d’une grappe entière ou de

noeuds individuels . . . . . . . . . . . 16

Suppression des noeuds d’une grappe ou

suppression d’une grappe entière . . . . . . 17

Administration du Recovery Resource Manager 18

Etape 2 : Définition des ressources RSCT . . . . 20


Définition de ressources RSCT pour un serveur

Web . . . . . . . . . . . . . . . . 20

Etape 3 : Définition des règles d’automatisation à

partir de la ligne de commande . . . . . . . 24


Création d’une définition d’équivalence pour les

cartes réseau . . . . . . . . . . . . . 26

Création d’un groupe de ressources pour apache1

et apache1IP . . . . . . . . . . . . . 27

Définition de relations entre les ressources du

serveur Web . . . . . . . . . . . . . 28

Mise en ligne du groupe de ressources du

serveur Web . . . . . . . . . . . . . 28

Chapitre 3. Utilisation des ressources 29

Qu’est-ce qu’une ressource ? . . . . . . . . 29

Qu’est-ce qu’une classe de ressources ? . . . . . 29

Qu’est-ce que les attributs de ressources ? . . . . 30

Attributs persistants . . . . . . . . . . 30

Attributs dynamiques . . . . . . . . . . 30

Qu’est-ce qu’une ressource gérée ? . . . . . . 30

Travailler avec des ressources . . . . . . . . 30

Attributs utilisés par les ressources . . . . . . 31

Attribut NodeNameList . . . . . . . . . 31

Attribut SelectFromPolicy . . . . . . . . . 31

Attribut ResourceType . . . . . . . . . . 32

Attribut OpState . . . . . . . . . . . . 33

L’attribut NominalState peut être défini

uniquement pour les groupes de ressources . . 34

Chapitre 4. Utilisation des groupes de

ressources . . . . . . . . . . . . . 35

Qu’est-ce qu’un groupe de ressources ? . . . . . 36

Règles d’utilisation des groupes de ressources . . 37

Attributs utilisés par les groupes de ressources . . 38

Attribut AllowedNode . . . . . . . . . . 39

Attribut MemberLocation . . . . . . . . . 40

Attribut Name . . . . . . . . . . . . 41

Attribut NominalState . . . . . . . . . . 41

Attribut Priorité . . . . . . . . . . . . 42

Attribut ExcludedList . . . . . . . . . . 43

ActivePeerDomain . . . . . . . . . . . 43

Description . . . . . . . . . . . . . 43

InfoLink . . . . . . . . . . . . . . 43

Propriétaire . . . . . . . . . . . . . 43

Abonnement . . . . . . . . . . . . . 43

Attribut OpState . . . . . . . . . . . . 44

Attribut TopGroup . . . . . . . . . . . 44

© Copyright IBM Corp. 2006, 2008 iii

Attribut AutomationDetails . . . . . . . . 45

Attribut MoveStatus . . . . . . . . . . 46

ConfigValidity . . . . . . . . . . . . 46

Attributs utilisés pour les membres de groupes de

ressources . . . . . . . . . . . . . . . 47

Attribut Mandatory . . . . . . . . . . . 47

Attribut MemberOf . . . . . . . . . . . 47

Définition et administration d’un groupe de

ressources . . . . . . . . . . . . . . . 48

Création d’un groupe de ressources . . . . . 48

Ajout d’une ressource membre dans un groupe

de ressources . . . . . . . . . . . . . 48

Enumération des groupes de ressources et de

leurs membres . . . . . . . . . . . . 49

Démarrage et arrêt d’un groupe de ressources . . 50

Modification des attributs d’un groupe de

ressources . . . . . . . . . . . . . . 50

Modification des attributs des membres d’un

groupe de ressources . . . . . . . . . . 50

Suppression d’une ressource membre d’un

groupe de ressources . . . . . . . . . . 51

Suppression d’un groupe de ressources . . . . 51

Chapitre 5. Utilisation des équivalences 53

Qu’est-ce qu’une équivalence ? . . . . . . . . 53

Règles d’utilisation des équivalences . . . . . 54

Attributs utilisés par les équivalences . . . . . . 55

Attribut MemberClass (classe de membres) . . . 55

Attribut Membership (appartenance) . . . . . 55

Attribut SelectString (chaîne sélection) . . . . 55

Attribut SelectFromPolicy (sélection à partir

d’une règle) . . . . . . . . . . . . . 55

Attributs utilisés par les membres des équivalences 56

Définition et administration des équivalences . . . 56

Création d’une équivalence . . . . . . . . 56

Liste d’une ou plusieurs équivalences . . . . 57

Modification d’une équivalence . . . . . . . 57

Suppression d’une équivalence . . . . . . . 57

Chapitre 6. Utilisation des relations

gérées . . . . . . . . . . . . . . . 59

Qu’est-ce qu’une relation gérée ? . . . . . . . 59

Attributs utilisés dans les relations gérées . . . . 60

Attribut Name . . . . . . . . . . . . 60

Attribut Source . . . . . . . . . . . . 60

Attribut Target . . . . . . . . . . . . 61

Attribut Relationship . . . . . . . . . . 61

Attribut Condition . . . . . . . . . . . 61

Relations du comportement de démarrage/d’arrêt 62

Relation StartAfter . . . . . . . . . . . 62

Relation StopAfter . . . . . . . . . . . 68

Relation Dépendant de . . . . . . . . . 70

Relation DependsOnAny . . . . . . . . . 76

Relation ForcedDownBy . . . . . . . . . 77

Relations Location . . . . . . . . . . . . 79

Conditions IfOnline, IfOffline, IfNotOnline, et

IfNotOffline . . . . . . . . . . . . . 80

Règles d’utilisation des relations d’emplacement 80

Relation Collocated . . . . . . . . . . . 81

Relation AntiCollocated . . . . . . . . . 84

Relation Affinity . . . . . . . . . . . . 86

Relation IsStartable . . . . . . . . . . . 88

Création et administration des relations . . . . . 90

Création d’une relation . . . . . . . . . 90

Enumération d’une relation . . . . . . . . 90

Modification d’une relation . . . . . . . . 91

Suppression d’une relation . . . . . . . . 91

Chapitre 7. Traitement des informations

système par System Automation for

Multiplatforms . . . . . . . . . . . 93

Définition de la relation d’emplacement :

algorithme de liaison . . . . . . . . . . . 93

Evénements permettant la Mise en ligne d’un

groupe de ressources . . . . . . . . . . . 97

Modèles de comportement d’IBM Tivoli System

Automation for Multiplatforms . . . . . . . . 98

Considérations générales . . . . . . . . . 98

Réaction de System Automation for

Multiplatforms aux modifications éventuelles

d’état opérationnel d’une ressource en ligne sur

un noeud . . . . . . . . . . . . . . 102

Composition de l’état opérationnel d’un groupe

de ressources par l’automatisation de système . 105

Réactions de l’automatisation de système aux

modifications d’état opérationnel d’une

ressource démarrée ou arrêtée . . . . . . . 106

Réactions de l’automatisation de système

lorsqu’une ressource est en ligne dans un noeud

donné et que la commande de contrôle déclare

simultanément un état opérationnel pour la

ressource dans un autre noeud . . . . . . 116

Cycle d’état d’un groupe de ressources . . . . . 117

Chapitre 8. Utilisation d’Integrated

Solutions Console . . . . . . . . . 119

Octroi d’autorisations aux utilisateurs pour

l’accomplissement de tâches System Automation à

partir d’Integrated Solutions Console . . . . . 119

Création d’utilisateurs et octroi d’autorisations

leur permettant de travailler avec System

Automation for Multiplatforms à partir

d’Integrated Solutions Console . . . . . . 119

Configuration de votre navigateur Web pour

Integrated Solutions Console . . . . . . . . 121

Connexion à Integrated Solutions Console . . . . 122

Disposition du Integrated Solutions Console . . . 122

Tâches System Automation for Multiplatforms

dans l’arborescence de navigation . . . . . . 123

Utilisation de la console d’opérations SA . . . . 126

Présentation de la console d’opérations SA . . 126

Présentation des couches de la console

d’opérations SA . . . . . . . . . . . 127

Utilisation des règles d’automatisation . . . . 138

Gestion des ressources à l’aide de la console

d’opérations . . . . . . . . . . . . . 140

Gestion de vos données d’identification utilisateur 144

Stockage de vos données d’identification

utilisateur dans le coffre d’accréditation . . . 144

iv Guide d'administration et d'utilisation

Modification et suppression des données

d’identification de l’utilisateur utilisateur . . . 145

Création et modification de règles d’automatisation

dans l’éditeur de règles . . . . . . . . . . 146

Présentation de la fenêtre de l’éditeur de règles 146

Création d’une règle . . . . . . . . . . 149

Chapitre 9. Protection de vos

ressources – support réalisé par

Quorum . . . . . . . . . . . . . . 167

Généralités . . . . . . . . . . . . . . 167

Quorum de configuration . . . . . . . . . 168

Quorum opérationnel . . . . . . . . . . 168

Méthodes de protection des ressources critiques

sous AIX, Solaris et Linux . . . . . . . . 168

Méthodes de protection des ressources critiques

sous Windows . . . . . . . . . . . . 169

Types de conditions de départage . . . . . 169

Fonction VMTIMEBOMB . . . . . . . . 171

Configuration des ressources critiques . . . . 172

Pour obtenir des informations du quorum . . . 173

Configuration et gestion d’une condition de

départage . . . . . . . . . . . . . 174

Utilisation d’une condition de départage . . . 176

Vérification de la capacité des ressources à jouer

le rôle de disques de départage . . . . . . 182

Condition de départage du réseau . . . . . 182

Remplacement du quorum opérationnel . . . 186

Chapitre 10. Contrôle et

administration de System Automation

for Multiplatforms . . . . . . . . . 187

Contrôle de System Automation for Multiplatforms 187

TimeOut et RetryCount . . . . . . . . . 188

Automatisation . . . . . . . . . . . . 190

ExcludedNodes . . . . . . . . . . . . 190

ResourceRestartTimeout . . . . . . . . . 190

Exemples . . . . . . . . . . . . . . 191

Gestion des règles d’automatisation des domaines

System Automation for Multiplatforms . . . . . 192

Utilisation de la commande sampolicy pour

gérer les règles . . . . . . . . . . . . 192

Utilisation du langage XML pour définir des

règles d’automatisation . . . . . . . . . 193

Utilisation des modèles de règle . . . . . . 197

Démarrage et arrêt d’un groupe de ressources et de

membres d’un groupe . . . . . . . . . . 200

Portée des requêtes de lancement et d’arrêt . . 200

Changement de la priorité des requêtes de

lancement et d’arrêt . . . . . . . . . . 201

Annulation des requêtes de lancement et d’arrêt 201

Affichage de la liste des requêtes . . . . . . 201

Exemple de scénario . . . . . . . . . . 201

Utilisation des requêtes de verrouillage et de

déverrouillage des groupes de ressources et des

ressources . . . . . . . . . . . . . . 204

Portée des requêtes de verrouillage . . . . . 204

Changement de la priorité des requêtes . . . 204

Exemple de scénario . . . . . . . . . . 205

Hiérarchisation des requêtes . . . . . . . . 206

Sources et priorités par défaut des requêtes . . 206

Hiérarchisation des requêtes . . . . . . . 207

Déplacement des groupes de ressources à l’aide de

la commande rgreq . . . . . . . . . . . 208

Portée d’un mouvement . . . . . . . . . 208

Traitement d’une requête de déplacement . . . 209

Déplacement et relations . . . . . . . . 209

Utilisation de ressources ombrées . . . . . . . 210

Définition des ressources ombrées . . . . . 211

Configuration des paramètres de sécurité des

grappes System Automation for Multiplatforms . . 214

Limites de la configuration de la sécurité non

root . . . . . . . . . . . . . . . 217

Etablissement de diagnostics de ressources System

Automation for Multiplatforms . . . . . . . 220

Utilisation de l’interface d’événements TEC avec

System Automation for Multiplatforms . . . . . 222

Qu’est-ce que Tivoli Enterprise Console ? . . . 222

Qu’est-ce que les événements ? . . . . . . 222

Envoi d’événements vers TEC . . . . . . . 223

Activation de la fonction de diffuseur de

publications de TEC . . . . . . . . . . 223

Configuration d’un nouveau paramètre de lieu

pour les messages d’événement de TEC . . . 226

Publication d’attributs internes de System

Automation for Multiplatforms dans

l’infrastructure RSCT . . . . . . . . . . 227

Activation de GDPS/PPRC Multiplatform

Resiliency for zSeries . . . . . . . . . . . 228

Version GDPS prise en charge . . . . . . . 229

Distributions Linux prises en charge . . . . . 229

Vérification dynamique des ressources . . . . . 230

Conseils et astuces . . . . . . . . . . . . 232

Redémarrage d’un noeud . . . . . . . . 232

Arrêt d’un noeud . . . . . . . . . . . 232

Génération d’événements en cas d’incidents . . 232

Chapitre 11. Automatisation des

ressources System Automation for

Multiplatforms . . . . . . . . . . . 233

Utilisation du Global Resource Manager

(gestionnaire de ressources globales) . . . . . . 233

Qu’est-ce que la classe de ressources

IBM.Application ? . . . . . . . . . . . 233

Qu’est-ce qu’une classe de ressources

IBM.ServiceIP ? . . . . . . . . . . . . 249

Utilisation du Test Resource Manager . . . . . 256

Qu’est-ce que la classe de ressources IBM.Test ? 256

Attributs utilisés par IBM.Test . . . . . . . 256

Exemple : Création d’une ressource de test et

manipulation de son état opérationnel (OpState) 259

Chapitre 12. Automatisation des

ressources du gestionnaire de

ressources de stockage RSCT . . . . 261

Unités de stockage prises en charge . . . . . . 261

Prise en charge de l’automatisation pour les

unités de stockage à un accès ou à accès

multiple de la famille IBM TotalStorage DS4000 . 262

Table des matières v

Prise en charge des unités de stockage à accès

unique et multi-accès sur d’autres familles de

système de disque IBM TotalStorage . . . . . 263

Prise en charge des unités de stockage à accès

unique non DS4000 . . . . . . . . . . 264

Prise en charge des systèmes NFS . . . . . 265

Création de ressources IBM.AgFileSystem définies

par l’utilisateur . . . . . . . . . . . . . 266

Automatisation des ressources IBM.AgFileSystem

définies par l’utilisateur dans un environnement

LVM . . . . . . . . . . . . . . . . 266

Attributs utilisés par IBM.AgFileSystem . . . . 266

Caractéristiques des attributs . . . . . . . 267

Chapitre 13. System Automation for

Multiplatforms sous Windows :

spécificités et restrictions . . . . . . 269

Utilisation de System Automation for

Multiplatforms sur les systèmes Windows . . . . 269

Contenu de SA for Multiplatforms . . . . . 269

Utilisation de l’interpréteur de commandes IBM

Tivoli System Automation . . . . . . . . 270

Instrumentation des ressources avec les classes

de ressources . . . . . . . . . . . . 270

Procédure de démarrage . . . . . . . . . . 277

Vérification du fonctionnement du contrôleur

des ressources système (SRC) . . . . . . . 277

Redémarrage du contrôleur des ressources

système et du RMC . . . . . . . . . . 278

Indicateur de présence permettant de protéger les

ressources critiques . . . . . . . . . . . 279

Valeurs du quorum opérationnel . . . . . . 279

Composants disponibles uniquement pour System

Automation for Multiplatforms sous Windows . . 281

Utilitaire SAMSERVICE . . . . . . . . . 281

Composants non disponibles pour System

Automation for Multiplatforms sous Windows . . 282

Annexe A. Configuration d’un réseau

hautement disponible . . . . . . . . 283

Considérations à propos de la planification de la

configuration d’un réseau hautement disponible . . 283

Qu’est-ce qui rend une infrastructure de réseau

hautement disponible difficile ? . . . . . . 284

Que faut-il clarifier avant de planifier un réseau

hautement disponible . . . . . . . . . 285

Détection des incidents liés à l’interface de réseau

dans les grappes à un noeud et deux noeuds . . . 285

Recommandations supplémentaires relatives à

l’exécution de Linux sur zSeries dans un

environnement zVM . . . . . . . . . . 286

Grappe à deux noeuds, chaque noeud disposant

d’une interface Ethernet . . . . . . . . . . 287

Grappe à deux noeuds, chaque noeud disposant de

deux interfaces réseau . . . . . . . . . . 289

Deux réseaux séparés physiquement,

déplacement de ServiceIP entre les noeuds . . 289

Trois réseaux logiques dans un réseau physique,

déplacement de ServiceIP entre les interfaces

réseau . . . . . . . . . . . . . . . 290

Deux réseaux séparés physiquement, routage

dynamique et VIPA . . . . . . . . . . 291

Interface de connexion . . . . . . . . . 292

Annexe B. Identification et résolution

des incidents . . . . . . . . . . . 295

Identification et résolution des erreurs et incidents

liés à System Automation for Multiplatforms . . . 295

Fonctionnement de l’automatisation . . . . . 295

Obtention d’informations pour la résolution des

incidents . . . . . . . . . . . . . . 298

Analyse des erreurs . . . . . . . . . . 307

Analyse des incidents . . . . . . . . . 312

Impossible de configurer la grappe . . . . . 317

Suite à la défaillance d’un noeud, le noeud

distant ne parvient plus à accéder aux disques

partagés . . . . . . . . . . . . . . 317

Signalement des incidents . . . . . . . . 317

Incidents recensés et limitations . . . . . . 318

Identification et résolution des incidents liés à la

console d’opérations System Automation for

Multiplatforms . . . . . . . . . . . . . 319

Aucun domaine d’automatisation n’est affiché

dans l’arborescence de la topologie . . . . . 319

Les horodatages affichés dans la console des

opérations ne sont pas à l’heure locale . . . . 323

Après le redémarrage d’un noeud, les

ressources fixes indiquent des états d’erreur

incorrects dans la console des opérations . . . 324

Affichage des fichiers journaux dans un

environnement multilingue . . . . . . . . 324

Récupération automatique des fichiers

enregistrés dans l’éditeur de règles . . . . . 325

Annexe C. Utilisation d’IBM Support

Assistant . . . . . . . . . . . . . 327

Installation d’IBM Support Assistant et du plug-in

Tivoli System Automation for Multiplatforms . . 327

Annexe D. Remarques . . . . . . . 329

Marques . . . . . . . . . . . . . . . 330

Index . . . . . . . . . . . . . . . 331

vi Guide d'administration et d'utilisation

Figures

1. Symboles utilisés dans le document . . . . . . . . . . . . . . . . . . . . . . . . . xv

2. Vue d’ensemble de l’architecture System Automation for Multiplatforms . . . . . . . . . . . . . 9

3. Composition de l’exemple de configuration . . . . . . . . . . . . . . . . . . . . . . 102

4. Transitions d’état opérationnel des ressources automatisées . . . . . . . . . . . . . . . . . 103

5. Cycle d’état d’un groupe de ressources . . . . . . . . . . . . . . . . . . . . . . . . 117

6. Présentation de la console d’opérations . . . . . . . . . . . . . . . . . . . . . . . . 126

7. Ecran principal de la console d’opérations . . . . . . . . . . . . . . . . . . . . . . . 127

8. Présentation de la section des ressources . . . . . . . . . . . . . . . . . . . . . . . 131

9. Ecran principal de l’éditeur de règles . . . . . . . . . . . . . . . . . . . . . . . . 146

10. Quorum – majorité de noeuds . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

11. Journaux système d’une grappe à deux noeuds . . . . . . . . . . . . . . . . . . . . . 186

12. Classement des priorités des requêtes . . . . . . . . . . . . . . . . . . . . . . . . 207

13. Scénario 1 : Relations DependsOn sans ressources ombrées . . . . . . . . . . . . . . . . . 210

14. Relation DependsOn avec des ressources ombrées . . . . . . . . . . . . . . . . . . . . 211

15. Format de syntaxe et exemple de fichier de configuration du diffuseur de publications . . . . . . . . 224

16. Format de syntaxe et exemple du fichier de configuration de TEC . . . . . . . . . . . . . . . 225

17. Ressource d’agrégat et ressources constituantes . . . . . . . . . . . . . . . . . . . . . 234

18. Configuration d’une ressource de support pour une ressource IBM.Application . . . . . . . . . . 248

19. Console de gestion informatique Windows affichant tous les services . . . . . . . . . . . . . . 278

20. Configuration du système d’exploitation pour qu’il redémarre après une BSOD . . . . . . . . . . 281

21. Problèmes lors de la planification d’un réseau hautement disponible . . . . . . . . . . . . . . 284

22. Une interface à deux noeuds . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

23. Une interface réseau à deux noeuds – échec de l’interface . . . . . . . . . . . . . . . . . . 288

24. Deux interfaces à deux noeuds, deux réseaux séparés physiquement . . . . . . . . . . . . . . 289

25. Un réseau physique à deux noeuds et deux interfaces . . . . . . . . . . . . . . . . . . . 291

26. Deux réseaux séparés physiquement, routage dynamique et VIPA . . . . . . . . . . . . . . . 292

27. Interfaces de réseau connectées ensemble à un périphérique de réseau logique . . . . . . . . . . . 293

© Copyright IBM Corp. 2006, 2008 vii

viii Guide d'administration et d'utilisation

Tableaux

1. Commandes System Automation for Multiplatforms utilisées avec les ressources gérées . . . . . . . . 29

2. Commandes System Automation for Multiplatforms utilisées avec les groupes de ressources . . . . . . 35

3. Valeurs MoveStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4. Commandes System Automation for Multiplatforms utilisées conjointement aux équivalences . . . . . . 53

5. Commandes System Automation for Multiplatforms utilisées avec les relations gérées . . . . . . . . 59

6. Actions d’automatisation de système en fonction des modifications d’état opérationnel de la ressource Res1 104

7. Actions d’automatisation de système en fonction des modifications d’état opérationnel de la ressource Res2 104

8. Détermination de l’état opérationnel d’un groupe de ressources . . . . . . . . . . . . . . . . 106

9. Actions d’automatisation de système et commande de démarrage toujours en cours d’exécution . . . . . 108

10. Actions d’automatisation de système et commande de démarrage achevée avec succès . . . . . . . . 109

11. Actions d’automatisation de système lorsque la commande de démarrage s’achève avec une erreur ou

expire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

12. Actions d’automatisation de système et commande d’arrêt toujours en cours d’exécution . . . . . . . 113

13. Actions d’automatisation de système et commande d’arrêt achevée avec succès . . . . . . . . . . 114

14. Actions d’automatisation de système lorsque la commande d’arrêt s’achève avec une erreur ou expire 115

15. Actions d’automatisation de système lorsque la commande de contrôle déclare une modification d’état

opérationnel pour la ressource dans un autre noeud . . . . . . . . . . . . . . . . . . . 116

16. Rôles d’accès de System Automation for Multiplatforms . . . . . . . . . . . . . . . . . . 120

17. Icônes correspondant aux éléments dans l’arborescence des topologies . . . . . . . . . . . . . 129

18. Icônes figurant dans la colonne Etat de l’arborescence des topologies . . . . . . . . . . . . . . 130

19. Icônes de ressources dans la colonne des ressources . . . . . . . . . . . . . . . . . . . . 134

20. Icônes des requêtes d’opérateur de la zone d’information . . . . . . . . . . . . . . . . . . 142

21. Types de conditions de départage . . . . . . . . . . . . . . . . . . . . . . . . . . 170

22. Comparaison entre une condition de départage du réseau et une condition de départage du disque 183

23. Sources et niveaux de priorités des requêtes de lancement et d’arrêt . . . . . . . . . . . . . . 206

24. Autorisations et rôles pour effectuer des tâches System Automation for Multiplatforms . . . . . . . . 218

25. Méthodes de protection du quorum opérationnel . . . . . . . . . . . . . . . . . . . . 280

© Copyright IBM Corp. 2006, 2008 ix

x Guide d'administration et d'utilisation

Avis aux lecteurs canadiens

Le présent document a été traduit en France. Voici les principales différences et

particularités dont vous devez tenir compte.

Illustrations

Les illustrations sont fournies à titre d’exemple. Certaines peuvent contenir des

données propres à la France.

Terminologie

La terminologie des titres IBM peut différer d’un pays à l’autre. Reportez-vous au

tableau ci-dessous, au besoin.

IBM France IBM Canada

ingénieur commercial représentant

agence commerciale succursale

ingénieur technico-commercial informaticien

inspecteur technicien du matériel

Claviers

Les lettres sont disposées différemment : le clavier français est de type AZERTY, et

le clavier français-canadien de type QWERTY.

OS/2 et Windows - Paramètres canadiens

Au Canada, on utilise :

v les pages de codes 850 (multilingue) et 863 (français-canadien),

v le code pays 002,

v le code clavier CF.

© Copyright IBM Corp. 2006, 2008 xi

Nomenclature

Les touches présentées dans le tableau d’équivalence suivant sont libellées

différemment selon qu’il s’agit du clavier de la France, du clavier du Canada ou

du clavier des États-Unis. Reportez-vous à ce tableau pour faire correspondre les

touches françaises figurant dans le présent document aux touches de votre clavier.

Brevets

Il est possible qu’IBM détienne des brevets ou qu’elle ait déposé des demandes de

brevets portant sur certains sujets abordés dans ce document. Le fait qu’IBM vous

fournisse le présent document ne signifie pas qu’elle vous accorde un permis

d’utilisation de ces brevets. Vous pouvez envoyer, par écrit, vos demandes de

renseignements relatives aux permis d’utilisation au directeur général des relations

commerciales d’IBM, 3600 Steeles Avenue East, Markham, Ontario, L3R 9Z7.

Assistance téléphonique

Si vous avez besoin d’assistance ou si vous voulez commander du matériel, des

logiciels et des publications IBM, contactez IBM direct au 1 800 465-1234.

xii Guide d'administration et d'utilisation

Présentation du manuel

Ce manuel explique comment mettre en oeuvre et exploiter les fonctions

d’autodépannage basées sur des règles offertes par IBM Tivoli System Automation

for Multiplatforms (System Automation for Multiplatforms).

System Automation for Multiplatforms permet de garantir la haute disponibilité

des ressources présentes dans des grappes AIX (sur IBM System p), Solaris (sur

SPARC), Linux (sur IBM System x, System z, System i et System p) et Windows

(sur IBM System x).

A qui s’adresse ce manuel ?

Ce manuel est destiné aux administrateurs système et aux opérateurs souhaitant

exploiter les fonctions d’automatisation et de reprise en ligne de System

Automation for Multiplatforms.

Utilisation de ce guide

Ce manuel contient toutes les informations nécessaires pour comprendre et utiliser

les fonctions de IBM Tivoli System Automation for Multiplatforms (System

Automation for Multiplatforms).

v Le chapitre 1 est une introduction à System Automation for Multiplatforms. Il

donne un aperçu de System Automation for Multiplatforms, introduit les

composants et explique les termes techniques utilisés dans ce guide.

v Le chapitre 2 est un guide résumant les tâches à accomplir pour utiliser System

Automation for Multiplatforms. Il aborde les processus d’administration des

grappes et des noeuds et de définition des règles d’automatisation.

v Le chapitre 3 traite des attributs standard de System Automation for

Multiplatforms.

v Le chapitre 4 aborde les processus de création et d’utilisation des groupes de

ressources.

v Le chapitre 5 aborde les processus de création et d’utilisation des équivalences.

v Le chapitre 6 aborde les processus de création et d’utilisation des relations

gérées.

v Le chapitre 7 aborde le processus de traitement des informations systèmes de

System Automation for Multiplatforms.

v Le chapitre 8 décrit la console d’opérations, l’éditeur de règles et les autres

commandes et applications disponibles dans Integrated Solutions Console.

v Le chapitre 9 aborde le processus de protection de vos ressources par System


v Le chapitre 10 explique comment contrôler et administrer System Automation

for Multiplatforms.

v Le chapitre 11 décrit les gestionnaires de ressources de System Automation for

Multiplatforms.

v Le chapitre 12 explique comment automatiser les ressources du gestionnaire de

ressources de stockage RSCT.

© Copyright IBM Corp. 2006, 2008 xiii

v Le chapitre 13 détaille les différences entre la version Windows de System

Automation for Multiplatforms et les versions de System Automation for

Multiplatforms pour systèmes AIX, Solaris et Linux.

v L’annexe A décrit la procédure de configuration d’un réseau à haute

disponibilité.

v L’annexe B offre des informations utiles pour l’identification et la résolution des

incidents.

v L’annexe C explique comment utiliser IBM Support Assistant.

Où trouver des informations supplémentaires ?

Outre ce manuel, la bibliothèque d’IBM Tivoli System Automation for

Multiplatforms contient les manuels suivants :

v IBM Tivoli System Automation for Multiplatforms Guide d’installation et de

configuration, SC33-8416

v Guide de référence d’IBM Tivoli System Automation for Multiplatforms, SC33-8417

Vous pouvez télécharger la documentation complète à l’adresse suivante :

http://publib.boulder.ibm.com/tividd/td/IBMTivoliSystemAutomationforMultiplatforms3.1.html

La page d’accueil de System Automation for Multiplatforms contient des

informations récentes et des services, ainsi que d’autres éléments d’intérêt pour les

utilisateurs de System Automation for Multiplatforms.

La page d’accueil de System Automation for Multiplatforms est disponible à

l’adresse suivante :

.ibm.com/software/tivoli/products/sys-auto-linux

Conventions

Les conventions suivantes de mise en évidence sont utilisées dans ce guide :

Gras Identifie les commandes, les sous-routines, les mots clés, les fichiers, les

structures, les répertoires ainsi que d’autres éléments dont les noms sont

prédéfinis dans le système. Identifie également les objets graphiques tels

que les boutons, les intitulés, et les icônes sélectionnés par l’utilisateur.

Italique Identifie les paramètres dont les noms et valeurs en cours doivent être

fournis par l’utilisateur.

Espace simple Identifie des exemples de valeurs de données spécifiques, des exemples de

textes similaires à ceux pouvant apparaître, des exemples de morceaux de

codes de programme semblables à ceux que vous pouvez rédiger en tant

que programmeur, des messages provenant du système ou des

informations que vous devez entrer.

xiv Guide d'administration et d'utilisation

http://publib.boulder.ibm.com/tividd/td/IBMTivoliSystemAutomationforMultiplatforms2.3.html

Ce guide utilise des symboles pour l’affichage de ressources, de groupes de

ressources, d’équivalences ou de relations. Les symboles sont utilisés comme suit :

ISO 9000

Des systèmes de qualités ISO 9000 ont été utilisés dans le développement et la

fabrication de ce produit.

Informations connexes

Les publications suivantes concernant IBM Reliable Scalable Cluster Technology

(RSCT) sont disponibles sur le CD de System Automation for Multiplatforms :

v RSCT Administration Guide

v RSCT for AIX 5L: Technical Reference

v RSCT for Multiplatforms: Technical Reference

v RSCT Messages

v RSCT Diagnosis Guide

Les publications RSCT sont également disponibles sur le site Web suivant :

www.ibm.com/servers/eserver/clusters/library/

Il se peut que vous deviez également vous reporter au livre rouge IBM suivant :

v Linux on IBM zSeries and S/390: High Availability for z/VM and Linux

Vous pouvez le consulter sur le site Web suivant :

http://publib-b.boulder.ibm.com/Redbooks.nsf/RedpaperAbstracts/redp0220.html

Comment obtenir des publications

Les publications System Automation for Multiplatforms sont également disponibles

(valides ou moment de la parution) sur les sites Web :

.ibm.com/servers/eserver/clusters/library/

.ibm.com/servers/eserver/zseries/software/sa/

.ibm.com/software/sysmgmt/products/support/

Figure 1. Symboles utilisés dans le document

Présentation du manuel xv

Comment nous contacter par e-mail

Si vous souhaitez nous contacter par e-mail, envoyez vos commentaires à l’adresse

[email protected]

xvi Guide d'administration et d'utilisation

Résumé des modifications

Nouveautés de la version 3.1

Les nouveautés et améliorations suivantes ont été apportées à l’occasion de la

version 3.1 :

v System Automation for Multiplatforms peut désormais être installé sous :

– AIX 5.3 et 6.1, prérequis RSCT inclus

– Solaris 10 sur SPARC

– Windows Server 2008v La version minimale de Red Hat Enterprise Linux est désormais la version 4.6

v L’outil de configuration peut désormais être utilisé en mode silencieux sans

environnement graphique (tel que X-Window)

v System Automation for Multiplatforms sous Windows peut désormais être ajouté

à un domaine System Automation Application Manager

v Editeur de règles graphique

v Il est désormais possible d’exécuter la version en anglais du produit sur les

systèmes associés à des paramètres régionaux turcs

v La création de copies miroir de groupes de volumes est désormais possible sous

AIX

© Copyright IBM Corp. 2006, 2008 xvii

xviii Guide d'administration et d'utilisation

Chapitre 1. Introduction

Généralités

System Automation for Multiplatforms permet de gérer la disponibilité des

applications exécutées sur des grappes Linux, AIX, Solaris et Windows. Pour

obtenir des informations détaillées sur la prise en charge de chaque plateforme,

voir IBM Tivoli System Automation for Multiplatforms Guide d’installation et de

configuration. System Automation for Multiplatforms offre les fonctions suivantes :

Haute disponibilité et moniteur de ressources

System Automation for Multiplatforms offre un environnement à haute

disponibilité, dans lequel les systèmes restent disponibles en permanence. Son

infrastructure d’autodépannage permet d’éviter les temps d’arrêt provoqués par les

incidents survenant au niveau des systèmes. L’infrastructure d’autodépannage

détecte les dysfonctionnements au sein du système, les transactions et les

processus, et intervient sans gêner les utilisateurs.

System Automation for Multiplatforms garantit une haute disponibilité digne des

gros systèmes en faisant appel à des fonctions de détection accélérée des

indisponibilités et d’identification des informations relatives aux composants

d’application et aux relations existant entre ces composants. Ces fonctions

permettent de rétablir rapidement et de manière cohérente les ressources

défaillantes et les applications métier terminées, sur le même système ou sur un

autre système au sein d’une grappe Linux, AIX, Solaris ou Windows, sans

intervention de l’opérateur. Les risques d’erreur due à une intervention manuelle

sont ainsi réduits, les opérateurs n’étant plus contraints de réaliser une surveillance

manuelle et de mémoriser les composants d’application et les relations existant

entre ces composants.

Automatisation basée sur des règles

System Automation for Multiplatforms permet de configurer des systèmes à haute

disponibilité grâce à l’utilisation de règles d’automatisation définissant les relations

entre les différents composants. Ces règles concernent les applications existantes et

ne requièrent qu’un nombre restreint de modifications. Lorsque les relations sont

établies, System Automation for Multiplatforms sera responsable de la gestion des

applications sur les noeuds spécifiés en respectant la configuration. Ceci réduira les

temps d’implémentation et simplifiera le codage des applications. De plus, il

permet d’ajouter les systèmes ainsi que les ressources sans avoir à modifier de

scripts.Vous pouvez télécharger des exemples de règles d’automatisation à partir de la

bibliothèque IBM Tivoli Open Process Automation Library, accessible à l’adresse

suivante :

http://catalog.lotus.com/wps/portal/topal

Pour accéder aux exemples, cliquez sur Tivoli products dans la zone Browse by,

puis sélectionnez Tivoli System Automation dans la liste déroulante.

© Copyright IBM Corp. 2006, 2008 1


Reprise sur incident automatique

System Automation for Multiplatforms permet de rétablir rapidement et de

manière cohérente les ressources défaillantes et les applications métier terminées,

sur le même système ou sur un autre système au sein d’une grappe Linux, AIX,

Solaris ou Windows. Ceci permet de remédier efficacement aux indisponibilités du

système et des applications.

Mouvement automatique des applications

System Automation for Multiplatforms gère les relations entre les ressources dont il

a la charge, et ce, à l’échelle de la grappe. Si les applications doivent être déplacées

entre les noeuds, le démarrage et l’arrêt des relations, les noeuds requis et toute

autre action préliminaire ou de suivi sont automatiquement prises en charge par

System Automation for Multiplatforms. Ainsi, l’opérateur n’intervient plus aussi

fréquemment ce qui réduit le risque d’erreur au niveau des entrées manuelles.

Regroupement de ressources

Dans System Automation for Multiplatforms, les ressources peuvent être

regroupées. Une fois groupées, il est possible d’établir différentes relations entre les

membres du groupe, par exemple des relations d’emplacement, de démarrage ou

d’arrêt. Une fois la configuration terminée, des opérations peuvent être effectuées

au niveau du groupe en tant que simple unité, ce qui évite aux opérateurs de

devoir se souvenir des composants d’application et des relations et réduit le risque

d’erreur.

Introduction

2 Guide d'administration et d'utilisation

Termes de System Automation for Multiplatforms

Cette section donne un aperçu des termes figurant dans ce manuel pour décrire


Grappes et domaines homologues

Tout au long de ce guide, les termes grappe et domaine homologue sont utilisés

indifféremment pour désigner un groupe de systèmes hôtes configuré pour offrir

une haute disponibilité, et sur lequel System Automation for Multiplatforms est

utilisé pour automatiser et gérer les ressources. Une grappe peut comprendre un

ou plusieurs noeuds (les termes noeud et système sont également utilisés de manière

interchangeable). System Automation for Multiplatforms supporte jusqu’à 32

noeuds à l’intérieur d’une grappe.

Ressource

Une ressource se rapporte à tout composant matériel ou logiciel pouvant être

défini dans System Automation for Multiplatforms. Les utilisateurs disposent de

différentes méthodes pour définir des ressources System Automation for

Multiplatforms :

v Exécution de la commande mkrsrc ("make resource") à partir de la ligne de

commande

v Définition dans un fichier de règles d’automatisation XML

v Définition dans l’éditeur de règles graphique

v Par ailleurs, certaines ressources sont définies automatiquement par le biais de la

fonction de collecte de ressources de l’infrastructure de grappe.

Les ressources sont contrôlées par les gestionnaires de ressources appropriés (voir

«Gestionnaires de ressources fournis par RSCT et System Automation for

Multiplatforms», à la page 7). Les ressources intègrent des caractéristiques ou des

attributs que vous pouvez définir. Si vous prenez par exemple une adresse IP en

tant que ressource, les attributs comprendraient l’adresse IP elle-même et le

masque réseau.

Il existe deux types de ressource :

Ressource fixe

Une ressource dont il n’existe qu’une seule instance au sein de la grappe. Il

représente une seule entité définie pour un noeud unique et c’est le seul

noeud sur lequel il fonctionne.

Ressource flottante

Une ressource qui peut fonctionner sur plusieurs noeuds à l’intérieur de la

grappe mais uniquement sur un noeud à la fois (voir «Attribut

ResourceType», à la page 32).

Attribut de ressource

Un attribut de ressource décrit certaines caractéristiques d’une ressource. Il existe

deux types d’attributs de ressource :

Attributs persistants

Les attributs d’une adresse IP (l’adresse elle-même ainsi que le masque de

réseau) sont des exemples d’attributs persistants. Ils décrivent les

caractéristiques permanentes d’une ressource. Bien que vous puissiez

modifier l’adresse IP et le masque réseau, ces caractéristiques, en revanche,

sont généralement stables et immuables.

Introduction

Chapitre 1. Introduction 3

Attributs dynamiques

Les attributs dynamiques, par contre, se rapportent aux caractéristiques

variables de la ressource. Les attributs dynamiques d’une adresse IP, par

exemple, identifieraient des caractéristiques telles que son état

opérationnel.

Classe de ressources

Une classe de ressources est une collecte de ressources du même genre. Si, par

exemple, une application est une ressource, en conséquence toutes les applications

définies dans la grappe comprendraient une classe de ressources. Les classes de

ressources vous permettent de définir les caractéristiques les plus courantes parmi

les ressources au sein de sa classe. Dans le cas des applications, la classe de

ressources peut définir des caractéristiques d’identification telles que le nom de

l’application et différentes caractéristiques indiquant par exemple si l’application

est en cours d’exécution ou non. Par conséquent, chaque ressource à l’intérieur

d’une classe peut être notée par ses caractéristiques à un moment donné. Les

classes de ressources sont gérées par plusieurs gestionnaires de ressources – voir

«Gestionnaires de ressources fournis par RSCT et System Automation for

Multiplatforms», à la page 7.

Groupe de ressources

Les groupes de ressources sont des conteneurs logiques d’une collecte de

ressources. Ce conteneur vous permet de contrôler des ressources multiples en tant

qu’entité logique unique. Les groupes de ressources sont à la base des opérations à

l’intérieur de System Automation for Multiplatforms. Les groupes de ressources

peuvent aussi être imbriqués et les applications peuvent donc être fractionnées en

plusieurs groupes de ressources, qui font eux-mêmes partie d’un groupe de

ressources de niveau supérieur. De même, les groupes de ressources peuvent être

définis de telle sorte que leurs membres se trouvent sur différents systèmes au sein

de la grappe.

Ressources gérées

Les ressources gérées sont des ressources qui ont été définies dans System

Automation for Multiplatforms. Des ressources deviennent des ressources gérées

lorsqu’elles sont ajoutées à un groupe de ressources ou une équivalence ou

lorsqu’elles sont définies comme la cible d’une relation gérée.

Etat nominal

L’état nominal d’un groupe de ressources indique à System Automation for

Multiplatforms si les ressources du groupe sont censées être en ligne ou hors ligne

à cet instant. Par conséquent, si vous définissez l’état nominal sur ″Hors ligne″,

vous souhaitez qu’System Automation for Multiplatforms arrête les ressources à

l’intérieur du groupe. En revanche, si vous définissez l’état nominal sur ″En ligne″,

vous souhaitez faire démarrer les ressources au sein du groupe de ressources. Vous

pouvez modifier la valeur de l’attribut Etat nominal du groupe de ressources mais

vous ne pouvez pas définir directement l’état nominal d’une ressource. Voir

«Attribut NominalState», à la page 41.

Equivalence

Une équivalence est une collecte de ressources offrant la même fonctionnalité. Les

équivalences peuvent, par exemple, être utilisées pour sélectionner les adaptateurs

de réseau dont la fonction est d’héberger une adresse IP. Si un adaptateur de

Introduction


réseau passe hors ligne, System Automation for Multiplatforms sélectionne un

autre adaptateur de réseau afin d’héberger l’adresse IP.

Relations

System Automation for Multiplatforms permet de définir les relations entre les

ressources au sein d’une grappe. Il existe deux types de relations :

v Relations de démarrage et d’arrêt

Les relations servent à définir les dépendances de démarrage et d’arrêt entre les

ressources. Vous pouvez utiliser les relations de StartAfter, StopAfter,

DependsOn, DependsOnAny et ForcedDownBy pour réaliser cette opération. Par

exemple, si une ressource doit uniquement être démarrée une fois qu’une autre

ressource a été démarrée, vous pouvez définir cette condition en utilisant la

relation StartAfter comme élément de règle.

v Relations d’emplacement

Les relations d’emplacement s’appliquent aux ressources qui doivent, ou

devraient si possible, être démarrées sur le même noeud ou sur un noeud

différent à l’intérieur de la grappe. System Automation for Multiplatforms

fournit les relations d’emplacement suivantes : Collocation, AntiCollocation,

Affinity, AntiAffinity, et IsStartable. Par exemple, un serveur Web et son adresse

IP correspondante, pouvant être démarrés sur n’importe quel noeud à l’intérieur

de la grappe, devront toujours être ensemble. Par le passé, ce comportement

devait être défini par le biais de scripts complexes. System Automation for

Multiplatforms permet désormais d’utiliser une relation d’emplacement, qui

facilite le travail de définition des règles de l’administrateur.

Les relations intègrent les fonctions supplémentaires suivantes :

– La possibilité de définir des relations entre les groupes de ressources, les

ressources et les équivalences.

– La possibilité de définir des relations entre les ressources fonctionnant sur

différents systèmes à l’intérieur de la grappe.

Quorum

L’objectif principal de Quorum est de conserver les données cohérentes et de

protéger les ressources critiques. On peut concevoir Quorum comme le nombre de

noeuds requis à l’intérieur d’une grappe pour modifier la définition de la grappe

ou effectuer certaines opérations au niveau de la grappe. Il existe deux types de

quorum :

Quorum de configuration

Le quorum de configuration détermine à quel moment les modifications de

configuration de la grappe seront acceptées. Les opérations affectant la

configuration de la grappe ou des ressources ne peuvent être effectuées

que si la majorité absolue des noeuds est en ligne. Voir «Quorum de

configuration», à la page 168 pour obtenir davantage d’informations.

Quorum opérationnel

Le quorum opérationnel permet de déterminer si les ressources peuvent

être activées en toute sécurité, sans risquer un conflit avec d’autres

ressources. Dans le cas d’un fractionnement de grappe, les ressources

peuvent uniquement être démarrées dans la sous-grappe disposant du plus

grand nombre de noeuds ou dans une sous-grappe qui a obtenu une

condition de départage. Voir «Quorum opérationnel», à la page 168 pour

plus d’informations à ce sujet.

Introduction


Condition de départage

Pour résoudre les situations de parité où une grappe, ayant un nombre égal de

noeuds, est partitionnée en sous-grappes possédant chacune exactement la moitié

des noeuds définis, la condition de départage sert à déterminer quelle sous-grappe

aura un quorum opérationnel.

Console d’opérations

Dans ce document, les termes console d’opérations et console d’opérations SA sont

utilisés indifféremment pour désigner l’interface graphique basée sur un navigateur

de System Automation for Multiplatforms.

Voici les caractéristiques de la console d’opérations :

v Elle est fournie avec System Automation for Multiplatforms et peut être installée

séparément.

v La console d’opérations et l’adaptateur d’automatisation de bout en bout, qui

établit et gère la communication entre les grappes dont les ressources sont

automatisées par System Automation for Multiplatforms (domaines

d’automatisation) et la console d’opérations SA, sont configurés en mode d’accès

direct.

Adaptateur d’automatisation de bout en bout

L’adaptateur d’automatisation de bout en bout de System Automation for

Multiplatforms est nécessaire pour établir et gérer la communication entre les

domaines d’automatisation et la console d’opérations SA (ou avec IBM Tivoli

System Automation Application Manager, le cas échéant). L’adaptateur est installé

automatiquement en même temps que System Automation for Multiplatforms.

Introduction


Intégration complète de RSCT à System Automation for Multiplatforms

Reliable Scalable Cluster Technology (RSCT) est un produit complètement intégré à

System Automation for Multiplatforms. RSCT est un ensemble de logiciels qui, une

fois réunis, offrent un environnement groupé complet pour AIX, Linux, Solaris et

Windows. System Automation for Multiplatforms utilise l’infrastructure RSCT pour

permettre aux grappes de bénéficier d’une meilleure disponibilité, d’une évolutivité

accrue et de plus de simplicité d’utilisation.

RSCT comprend les sous-systèmes de base suivants :

v RMC (Resource Monitoring and Control subsystem) :RMC est utilisée pour la surveillance d’un système et pour le contrôle des

noeuds d’une grappe. Dans une grappe, RMC offre un accès global aux

sous-systèmes et aux ressources situés dans la grappe. Il assure ainsi un contrôle

simple et une infrastructure de gestion pour les grappes.

v HAGS (High Availability Group Services subsystem)HAGS est un service de coordination, de messagerie et de synchronisation.

v HATS (High Availability Topology Services subsystem)HATS intègre d’une part un signal de présence évolutif permettant de détecter

les incidents au niveau de l’adaptateur et du noeud et d’autre part un service de

messagerie fiable dans un domaine homologue.

v SRC (System Resource Controller)Le contrôleur des ressources système (SRC) est le processus d’amorce qui est

démarré en premier et qui entraîne tous les autres processus démon requis par

RSCT et System Automation for Multiplatforms pour fonctionner. Il est

également chargé de redémarrer ces processus démon après un échec. Le

contrôleur des ressources système associe un ensemble de commandes et de

sous-programmes pour simplifier la création et le contrôle des sous-systèmes par

les gestionnaires système.

Sous AIX et Linux, le contrôleur des ressources système peut être démarré à

partir du fichier inittab.

Sous Solaris et Linux, le contrôleur des ressources système peut être démarré à

partir de la fonction SMF (Service Management Facility).

Sous Windows, le contrôleur des ressources système s’exécute comme un service

Windows.

Gestionnaires de ressources fournis par RSCT et System

Automation for Multiplatforms

Les classes de ressources sont gérées par des gestionnaires de ressources (RM). Le

gestionnaire de ressources responsable de la gestion d’une ressource spécifique

dépend de la classe de ressources. Un gestionnaire de ressources est une couche

logicielle située entre une ressource et une classe de gestionnaire de ressources. Un

gestionnaire de ressources est exécuté en tant que démon contrôlé par le contrôleur

des ressources système (SRC).

Introduction


RSCT offre un ensemble central de gestionnaires de ressources permettant de gérer

les ressources System Automation for Multiplatforms sur des systèmes uniques ou

des grappes. L’ensemble de gestionnaires de ressources RSCT s’accompagne des

gestionnaires de ressources suivants, propres à System Automation for

Multiplatforms :

Recovery resource manager (Recovery RM)

Recovery RM (IBM.RecoveryRM) joue le rôle de moteur décisionnel pour System

Automation for Multiplatforms. Dès lors qu’une règle d’automatisation définissant

les disponibilités des ressources et leurs relations est fournie, les informations de

règle sont transmises à Recovery RM. Ce gestionnaire de ressources fonctionne sur

chaque noeud à l’intérieur de la grappe, avec un gestionnaire de ressources de

reprise sur incident désignée comme document maître. Le Recovery RM maître est

chargé de l’évaluation des informations de surveillance fournies par les différents

gestionnaires de ressources. Lorsqu’une intervention est nécessaire, le Gestionnaire

de ressources de reprise sur incident gère les décisions, ce qui revient à démarrer

ou à arrêter les opérations au niveau des ressources le cas échéant.

Gestionnaire de ressources globales

Le Gestionnaire de ressources globales (IBM.GblResRM) supporte les deux classes

de ressources :

IBM.Application

La classe de ressources IBM.Application définit le comportement des

ressources d’application générales. Cette classe peut être utilisée pour

démarrer, arrêter et contrôler les processus. En tant que classe générique,

elle est très flexible et peut être utilisée pour surveiller et contrôler

plusieurs types de ressources. La plupart des applications à automatiser se

feront à l’aide de cette classe. Pour en savoir plus, voir «Utilisation du

Global Resource Manager (gestionnaire de ressources globales)», à la page

233.

IBM.ServiceIP

Cette classe d’application définit le comportement des ressources

d’adresses du protocole Internet (IP). Il vous permet d’attribuer les

adresses IP à un adaptateur. En fait, il permet aux adresses IP de ’flotter’

entre les noeuds. Pour en savoir plus, voir «Qu’est-ce qu’une classe de

ressources IBM.ServiceIP ?», à la page 249.

Gestionnaire de ressources de stockage (Stockage RM)

Le gestionnaire de ressources de stockage gère et contrôle les ressources de

stockage dans un domaine d’automatisation. Le gestionnaire de ressources de

stockage offre une interface entre le RMC et les entités de stockage physiques et

logiques dans le domaine homologue en associant ces dernières aux instances des

classes de ressources qu’il fournit.

Exécuté comme un processus démon sur chaque noeud dans le domaine de

l’automatisation, le gestionnaire de ressources de stockage collecte les informations

relatives aux disques physiques reliés localement (ainsi que les entités de stockage

associées) et les associe aux instances de classe de ressources. Ces vues séparées

des ressources de stockage provenant de chaque noeud individuel sont ensuite

toutes collectées en même temps pour offrir au gestionnaire une vue globale des

ressources de stockage qui se trouvent dans un domaine d’automatisation.

Introduction


Dans un environnement de stockage partagé (où plusieurs noeuds du domaine

d’automatisation accèdent au même sous-système de disques et par conséquent

accèdent aux mêmes disques qu’il contient), la vue globale des ressources de

stockage dont dispose le gestionnaire lui permet d’identifier ces disques partagés et

d’offrir un accès séquentiel via les réserves matérielles.

Gestionnaire de ressources de configuration (Configuration RM)

La Configuration du Gestionnaire de ressources (IBM.ConfigRM) est utilisée pour

définir la grappe. De plus, vous disposez de quorum support pour vous aider à

assurer l’intégrité des données lorsque des portions au sein d’une grappe ont

interrompu la communication.

Gestionnaire des ressources de test (Test RM)

Le Gestionnaire des ressources de test (IBM.TestRM) gère les ressources de test et

présente les fonctions permettant de manipuler l’état opérationnel de ces

ressources. Le gestionnaire des ressources de test ne contrôle pas les ressources

réelles.

Il est opérationnel en mode de domaine homologue uniquement et fournit la classe

de ressources IBM.Test. Une description détaillée du Gestionnaire des ressources de

Test se trouve dans Chapitre 11, «Automatisation des ressources System

Automation for Multiplatforms», à la page 233.

figure 2 affiche un diagramme des composants décrits précédemment.

Figure 2. Vue d’ensemble de l’architecture System Automation for Multiplatforms

Introduction


Utilisation de System Automation for Multiplatforms sous Windows

System Automation for Multiplatforms sous Windows s’appuie sur les versions

prévues pour fonctionner sur les plateformes AIX, Solaris et Linux. System

Automation for Multiplatforms sous Windows fait appel au composant

″Sous-système pour applications UNIX″ fourni avec Windows Server 2003 R2 et

Windows Server 2008.

Vous pouvez utiliser System Automation for Multiplatforms sous Windows pour

gérer et automatiser des applications et des services Win32 standard.

Pour pouvoir communiquer avec le produit, les opérateurs et les administrateurs

peuvent utiliser la console d’opérations (voir «Utilisation de la console d’opérations

SA», à la page 126) ou l’interpréteur de commandes ″Tivoli System Automation″. Il

s’agit d’un processus ″Interpréteur de commandes Korn″ spécialisé. Par la suite, le

présent guide suppose que tout utilisateur possède les connaissances de base

requises pour gérer les shells de commande tels que UNIX. C’est également le cas

pour les versions de System Automation for Multiplatforms exécutées sur des

serveurs Windows. Tous les utilisateurs doivent être capables de naviguer au sein

des systèmes de fichiers UNIX standard, d’afficher et de modifier des fichiers texte

et de modifier les droits d’accès. Ils doivent également maîtriser les utilitaires tels

que ″ps″ et ″grep″. Toutes les commandes qui sont décrites dans la suite du présent

document doivent être émises depuis un interpréteur de commandes UNIX. Elles

ne peuvent pas être appelées depuis un interpréteur de commande Windows.

Introduction


Chapitre 2. Mise en route

Remarque : Avant de commencer à utiliser System Automation for Multiplatforms

sous Windows, consultez les informations décrites dans Chapitre 13,

«System Automation for Multiplatforms sous Windows : spécificités et

restrictions», à la page 269.

Ce chapitre répertorie et détaille les étapes à réaliser impérativement avant de

commencer à utiliser System Automation for Multiplatforms :

Etape 1 : Définition et administration d’une grappe (voir page 12)

Cette étape indique comment créer et supprimer une grappe, ajouter et

supprimer des noeuds d’une grappe et comment vérifier l’état de System


Etape 2 : Définition des ressources RSCT (voir page 20)

Cette étape indique comment créer une ressource telle qu’un serveur Web

et une relation d’équivalence.

Etape 3 : Définition des règles d’automatisation à partir de la ligne de

commande (voir page 24)

Cette étape explique comment définir des relations entre les composants

créés au cours des étapes 1 et 2. Elle consiste à définir la règle

d’automatisation.

Pour des informations détaillées sur les commandes mentionnées dans le présent

chapitre, reportez-vous à la documentation suivante :

Commandes IBM Reliable Scalable Cluster Technology (RSCT)

Pour obtenir une description détaillée des commandes RSCT, consultez les

pages d’aide concernées ainsi que les manuels RSCT mentionnés dans la

rubrique «Informations connexes», à la page xv.

Les documents RSCT sont disponibles sur le CD de System Automation for

Multiplatforms. Ils peuvent également être téléchargés à partir du site Web

suivant :

www.ibm.com/servers/eserver/clusters/library/

Le centre de documentation sur les grappes est accessible à l’adresse

suivante :

http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp

Commandes System Automation for Multiplatforms

Pour obtenir une description détaillée de ces commandes, consultez le

Guide de référence d’IBM Tivoli System Automation for Multiplatforms. Vous

utiliserez certaines commandes System Automation for Multiplatforms au

cours de l’étape 3.


Etape 1 : Définition et administration d’une grappe

Les scénarios décrits ci-après indiquent comment créer une grappe, configurer une

condition de départage, ajouter des noeuds à la grappe et vérifier l’état du démon

Recovery RM de System Automation for Multiplatforms (IBM.RecoveryRM).

Présentation des commandes

La liste suivante donne un aperçu des commandes Reliable Scalable Cluster

Technology (RSCT) que vous utilisez lorsque vous travaillez avec des définitions de

grappe. Vous utiliserez certaines de ces commandes à l’étape 1. Pour une

description détaillée des commandes, reportez-vous aux manuels RSCT répertoriés

à la page 11.

preprpnode Cette commande prépare les paramètres de sécurité du noeud à

inclure dans une grappe. Lorsque la commande est émise, les clés

publiques sont échangées entre les noeuds et la liste des contrôles

d’accès RMC (ACL) est modifiée pour permettre l’accès aux

ressources de la grappe à tous les noeuds de la grappe.

mkrpdomain Cette commande crée une nouvelle définition de la grappe. Elle est

utilisée pour spécifier le nom de la grappe ainsi que la liste des

noeuds à ajouter à la grappe.

lsrpdomain Cette commande répertorie les informations relatives à la grappe à

laquelle le noeud sur lequel la commande est exécutée appartient.

startrpdomain / stoprpdomain

Ces commandes sont utilisées afin de mettre respectivement la

grappe en ligne et hors ligne.

addrpnode Lorsqu’une grappe est définie et fonctionnelle, cette commande est

utilisée pour ajouter de nouveaux noeuds à la grappe.

startrpnode / stoprpnode

Ces commandes sont utilisées afin de mettre respectivement des

noeuds individuels en ligne et hors ligne dans la grappe. Elles sont

généralement utilisées lors de la maintenance d’un système donné.

Le noeud est arrêté, les réparations ou la maintenance sont

effectués, puis le noeud est redémarré et rejoint la grappe.

lsrpnode Cette commande est utilisée afin d’afficher la liste des noeuds

définis dans une grappe ainsi que l’état opérationnel (OpState) de

chaque noeud. Notez que cette commande est uniquement utile sur

les noeuds En ligne dans la grappe, autrement la liste des noeuds

ne s’affichera pas.

lssrc Cette commande répertorie les états des sous-systèmes.

rmrpdomain Cette commande supprime une grappe définie.

rmrpnode Cette commande supprime un ou plusieurs noeuds d’une

définition de la grappe.

startsrc Cette commande démarre un sous-système.

stopsrc Cette commande arrête un sous-système.

Mise en route


Création d’une grappe composée de deux noeuds

Avant de commencer la création d’une grappe, vérifiez que le réseau est configuré

correctement :

v Les adresses IP, de masque de réseau et de diffusion doivent être cohérentes

dans chaque noeud de grappe.

v Veillez à ce que la résolution de nom soit valide, les entrées DNS cohérentes ou

les entrées dans vos fichiers locaux /etc/hosts identiques dans chaque noeud.

v Ne définissez pas plus d’une interface réseau sur un noeud dans le même

sous-réseau.

v Tous les pare-feu, y compris les pare-feu locaux, doivent autoriser les

commandes ping ICMP et le trafic IP à partir de 12347/udp for cthats, 12348/udp

pour cthags, rmc 657/udp et tcp.

Pour plus d’informations, reportez-vous au Annexe A, «Configuration d’un réseau

hautement disponible», à la page 283.

Pour créer une grappe à deux noeuds, suivez la procédure ci-dessous :

1. Connectez-vous à chaque noeud dans la grappe :

v AIX/Solaris/Linux :

– Accédez à une console sur chaque noeud de la grappe et connectez-vous

en tant que root.

– Attribuez la valeur 2 à la variable d’environnement

CT_MANAGEMENT_SCOPE sur chaque noeud. Pour configurer la

variable d’environnement sur cette valeur de façon permanente, ajoutez-la

à /etc/profile.

– Supprimez les entrées superflues qui font référence au même nom d’hôte

que la table /etc/hosts (Exemple : 127.0.0.2 mon_nom_hôte). Ces entrées

sont créées lors de l’installation du système d’exploitation, mais sont en

conflit avec l’infrastructure de la grappe.v Windows :

Procédez comme suit :

a. Connectez-vous à chaque noeud en utilisant le compte utilisateur utilisé

lors de l’installation de System Automation for Multiplatforms.

b. Ouvrez une console distante Windows.

c. Ouvrez un interpréteur de commandes ″IBM Tivoli System Automation″.

En règle générale, il se trouve dans le dossier Démarrer > Tous les

programmes > Tivoli SA MP Base. Si vous avez activé le service Telnet

sur les noeuds Windows, vous pouvez ouvrir une session Telnet.

d. Assurez-vous que /etc/hosts, /etc/services et /etc/protocols sont des

liens symboliques vers les fichiers correspondants du répertoire

<WINDOWS>\system32\drivers\etc.2. Exécuter la commande preprpnode dans tous les noeuds afin d’autoriser la

communication entre les noeuds de grappe.

preprpnode node01 node02

3. Vous pouvez désormais créer une grappe appelée SA_Domain qui fonctionne

sur les noeuds node01 et node02. La commande suivante peut être exécutée à

partir de n’importe quel noeud.

mkrpdomain SA_Domain node01 node02

Mise en route

Chapitre 2. Mise en route 13

Notez que lorsque vous créez des domaines homologues RSCT (grappes) à

l’aide de la commande mkrpdomain, les caractères utilisés pour le nom du

domaine homologue sont limités aux caractères ASCII suivants : A-Z, a–z, 0-9, .

(point) et _ (trait de soulignement).

4. Pour connaître l’état du domaine SA_Domain, exécutez la commande

lsrpdomain :

lsrpdomain

Output:

Name OpState RSCTActiveVersion MixedVersions TSPort GSPort

SA_Domain Offline 2.5.5.1 No 12347 12348

La grappe est définie mais hors ligne.

5. Exécutez la commande startrpdomain pour mettre la grappe en ligne.

startrpdomain SA_Domain

Lorsque vous exécutez la commande lsrpdomain une nouvelle fois, vous

constatez que la grappe est toujours en cours de démarrage et que l’état

opérationnel (OpState) est En attente en ligne.


SA_Domain Pending online 2.5.5.1 No 12347 12348

Au bout d’un court laps de temps, la grappe est démarrée. Ainsi, si vous

exécutez à nouveau la commande lsrpdomain, vous pouvez constater que la

grappe est maintenant en ligne :


SA_Domain Online 2.5.5.1 No 12347 12348

Remarques :

1. Le message d’erreur suivant peut apparaître :

2632-044 Le domaine ne peut pas être créé en raison des erreurs suivantes

détectées lors de la collecte d’informations dans les noeuds cible :

node1 : 2632-068 Ce noeud possède le même identifiant interne que le noeud node2

et ne peut pas être inclus dans la définition du domaine.

Cette erreur se produit généralement lorsque vous reproduisez des images

Linux.

Un incident s’est produit dans la grappe et la configuration entière doit être

réinitialisée. Résolvez chaque problème en exécutant la commande suivante sur

la grappe spécifiée dans le message d’erreur afin de réinitialiser l’ID du noeud :

/usr/sbin/rsct/install/bin/recfgct

Ensuite, exécutez la commande preprpnode.

2. Le message d’erreur suivant peut également apparaître :

2632-044 Le domaine ne peut pas être créé en raison des erreurs suivantes

détectées lors de la collecte d’informations dans les noeuds cible :

node1 : 2610-418 Accès aux ressources ou à la classe de ressources spécifiée

dans la commande refusé.

Vérifiez la résolution du nom d’hôte. Vérifiez que toutes les entrées de chaque

noeud de la grappe dans vos fichiers locaux /etc/hosts de tous les noeuds et les

entrées nameserver sont identiques.

3. Le message d’erreur suivant peut apparaître :

2612-022 Une

session n’a pas pu être établie avec le démon RMC sur <nom_noeud>.

Mise en route


Cette erreur se produit le plus souvent si un pare-feu est exécuté sur l’un des

noeuds de la grappe. Pour résoudre cet incident, activez les ports suivants dans

le logiciel du pare-feu :

rmc port 657 TCP IN/OUT Source Port Range: ephemeral port

rmc port 657 UDP IN/OUT Source Port Range: ephemeral port

cthats port 12347 UDP IN/OUT Source Port Range: 1024 - 65535

cthags port 12348 UDP IN/OUT Source Port Range: 1024 - 65535

Notez que toutes les règles de pare-feu doivent autoriser la transmission des

paquets BROADCAST via le port cthats. Pour plus d’informations,

reportez-vous au document IBM RSCT Administration Guide, (Appendix A.

RSCT network considerations).

Configuration d’une condition de départage

Une condition de départage doit être définie pour toutes les grappes comprenant

un nombre de noeuds pair.

Dans le cas de grappes à deux noeuds, une condition de départage est nécessaire,

pour les raisons suivantes :

v Sans condition de départage, System Automation for Multiplatforms

n’automatise les ressources que si plus de la moitié des noeuds d’une grappe

sont en ligne. Ainsi, si aucune condition de départage n’est définie, les deux

noeuds de la grappe doivent être en ligne pour que les opérations

d’automatisation puissent être réalisées.

v Une condition de départage garantit que la grappe reste opérationnelle même si

elle est fractionnée de telle manière que la communication entre les deux noeuds

échoue.

Une condition de départage doit être définie pour toutes les grappes comprenant

un nombre de noeuds pair. Cette dernière garantit la résolution des situations où

seule la moitié des noeuds de la grappe sont en ligne ou la grappe est fractionnée.

Pour des informations détaillées sur la configuration, l’administration et

l’utilisation des conditions de départage, reportez-vous au Chapitre 9, «Protection

de vos ressources – support réalisé par Quorum», à la page 167.

Ajout d’un noeud dans une grappe existante

Une fois que vous avez créé la grappe à deux noeuds, vous pouvez avoir besoin

d’ajouter un troisième noeud à SA_Domain. Pour ce faire, vous avez besoin :

1. d’émettre la commande lsrpdomain afin de voir si votre grappe est en ligne :


SA_Domain Online 2.5.5.1 No 12347 12348

d’émettre la commande lsrpnode afin de voir les noeuds qui sont en ligne :

Name OpState RSCT Version

node02 Online 2.5.5.1


2. d’émettre la commande preprpnode suivante afin d’autoriser les

communications entre les noeuds existants et le nouveau noeud.Connectez-vous au noeud node03 et entrez :

preprpnode node01 node02

Connectez-vous au noeud node02 et entrez :

preprpnode node03

Mise en route


Connectez-vous au noeud node01 et entrez :

preprpnode node03

Il est fortement recommandé d’exécuter une commande preprpnode sur chaque

noeud, pour tous les noeuds.

3. Pour ajouter le noeud node03 à la définition de grappe, exécutez la commande

addrpnode sur les noeuds node01 ou node02, qui sont déjà en ligne dans la

grappe.

addrpnode node03

Exécutez à nouveau la commande lsrpnode afin de voir le statut de tous les

noeuds :



node03 Offline 2.5.5.1


4. Démarrez le noeud node03 à partir d’un noeud en ligne :

startrpnode node03

Après un bref instant, le noeud node03 doit être en ligne également.

Mise hors ligne d’une grappe entière ou de noeuds individuels

Pour procéder à la maintenance des noeuds ou à la mise à jour de l’application,

vous aurez peut-être besoin de mettre une grappe entière ou des noeuds

individuels d’une grappe hors ligne :

v Pour procéder à la maintenance sur une grappe SA-Domain, vous aurez

peut-être besoin de la mettre hors ligne. Pour ce faire, utilisez la commande

stoprpdomain à partir de n’importe quel noeud en ligne de la grappe.

stoprpdomain SA_Domain

Exécutez la commande lsrpdomain afin de vérifier l’état de la grappe

SA-Domain :


SA_Domain Offline 2.5.5.1 No 12347 12348

L’arrêt d’une grappe n’entraîne pas la suppression de la définition de grappe, la

grappe peut par conséquent être de nouveau mise en ligne à l’aide de la

commande startrpdomain.

v Pour mettre un ou plusieurs noeuds de grappe hors ligne, utilisez la commande

stoprpnode. Vous pouvez avoir à placer un noeud de grappe hors ligne, par

exemple :

– appliquer des mises à niveau d’applications

– procéder à la gestion sur un noeud

– avant de supprimer le noeud de la grappe

– Aussi, comme un noeud peut être défini dans plusieurs grappes sauf lorsqu’il

est en ligne et ne peut alors être défini que dans une grappe à la fois, vous

devrez peut-être mettre un noeud hors ligne dans une grappe afin de pouvoir

le mettre en ligne dans une autre grappe.

Pour mettre un noeud hors ligne, exécutez la commande stoprpnode à partir de

n’importe quel noeud en ligne d’une grappe et transmettez-le au nom de noeud

de grappe du noeud afin de le mettre hors ligne. Par exemple, procédez comme

suit pour arrêter le noeud node03 :

stoprpnode node03

Mise en route


Remarque : Soyez prudent lorsque vous arrêtez plusieurs noeuds d’une grappe.

Vous perdrez du quorum si moins de la moitié des noeuds sont en

ligne. Des indisponibilités peuvent alors avoir lieu si des ressources

sont en cours d’exécution sur les noeuds en ligne de la grappe. Voir

Chapitre 9, «Protection de vos ressources – support réalisé par

Quorum», à la page 167 pour des informations supplémentaires.Exécutez la commande lsrpnode afin de voir si le noeud node03 est hors ligne :

lsrpnode node03



Suppression des noeuds d’une grappe ou suppression d’une

grappe entière

Lorsque vous procédez à la mise à niveau du matériel ou à la réorganisation de la

configuration générale de la grappe, vous devrez peut-être supprimer des noeuds

individuels d’une grappe ou supprimer une définition de grappe entière.

v Pour supprimer un noeud d’une grappe, utilisez la commande rmrpnode. Pour

supprimer un noeud d’une grappe, le noeud doit être hors ligne. Si le noeud

que vous souhaitez supprimer n’est pas hors ligne, vous devez utiliser la

commande stoprpnode pour le mettre hors ligne. Vous pouvez également

supprimer plusieurs noeuds de la grappe à l’aide de la commande rmrpnode.

Afin de voir les noeuds hors ligne, exécutez la commande lsrpnode à partir de

n’importe quel noeud en ligne de la grappe.

lsrpnode





Exécutez ensuite la commande rmrpnode à partir de n’importe quel noeud en

ligne dans la grappe pour supprimer le noeud node03.

rmrpnode node03

Exécutez à nouveau la commande lsrpnode pour vérifier que le noeud node03 a

été supprimé.

lsrpnode




Mise en route


v Pour supprimer une définition de grappe entière, utilisez la commande

rmrpdomain. La suppression d’une grappe entraîne la suppression de la

définition de grappe de chaque noeud de la grappe. Pour que la suppression se

passe correctement, tous les noeuds de la grappe doivent être en ligne. Vous

pouvez mettre en ligne des noeuds individuels à l’aide de la commande

startrpnode, mais il est également possible de mettre en ligne tous les noeuds

hors ligne dans la grappe, en utilisant la commande startrpdomain. La

commande rmrpdomain supprime la définition de grappe de tous les noeuds

accessibles à partir du noeud dans lequel la commande a été exécutée. Si la

commande a été exécutée à partir d’un noeud en ligne dans une grappe et que

tous les noeuds sont en ligne, la commande tentera de supprimer tous leurs

fichiers de définition de grappe. S’il est impossible d’accéder à un noeud à partir

du noeud sur lequel la commande rmrpdomain est exécutée (noeud hors ligne

ou non opérationnel, par exemple), la commande rmrpdomain ne permettra pas

de supprimer la définition de grappe sur ce noeud. Si la grappe ne peut être

mise en ligne, vous pouvez utiliser l’option d’interruption forcée -f pour

supprimer des noeuds de la grappe.Exécutez la commande startrpdomain pour mettre tous les noeuds de la grappe

SA_Domain en ligne :

startrpdomain SA_Domain

Exécutez ensuite la commande rmrpdomain pour supprimer la grappe

SA_Domain :

rmrpdomain SA_Domain

Administration du Recovery Resource Manager

Sur chaque noeud en ligne dans une grappe, un démon Recovery RM de System

Automation for Multiplatforms (IBM.RecoveryRM) est exécuté. Le démon est

démarré automatiquement lorsque la grappe est mise en ligne.

Pour connaître l’état et l’ID processus du démon, utilisez la commande suivante :

lssrc -s IBM.RecoveryRM

La sortie se présente sous cette forme :

Subsystem Group PID Status

IBM.RecoveryRM rsct_rm 18283 active

Si nécessaire, vous pouvez arrêter manuellement le démon à l’aide de la

commande suivante :

stopsrc -s IBM.RecoveryRM

Pour démarrer le démon, utilisez la commande :

startsrc -s IBM.RecoveryRM

L’un des démons est le démon maître. Ce démon a la responsabilité de faire circuler

toutes les décisions nécessaires. Découvrez sur quel noeud le démon du maître est

exécuté à l’aide de la commande suivante :

lssrc -ls IBM.RecoveryRM | grep Master

Vous obtenez la sortie suivante :

Master Node Name : node03 (node number = 3)

Dans notre exemple, le démon maître fonctionne sur le noeud node03.

Mise en route


Les autres démons sont des ’démons homologues’. Ces démons homologues sont

des systèmes de secours automatiques qui se mettent en marche en cas de

défaillance du démon maître ou du noeud sur lequel le démon maître se trouve.

Dans ce cas, l’un des démons homologues devient le démon maître. Le relais entre

les démons a bien évidemment lieu sans interruption de la fonction

d’automatisation de System Automation for Multiplatforms.

Mise en route


Etape 2 : Définition des ressources RSCT


La section suivante donne un aperçu des commandes Reliable Scalable Cluster

Technology (RSCT) for Linux que vous utilisez lors de la définition de ressources

RSCT. Vous utiliserez certaines de ces commandes à l’étape 2. Pour une description

détaillée des commandes, reportez-vous aux manuels RSCT répertoriés à la page

11.

chrsrc Cette commande modifie les valeurs d’attribut persistant d’une ressource

dans une classe de ressources spécifiée.

lsrsrc Cette commande répertorie les ressources d’une classe de ressources.

mkrsrc

Cette commande crée les ressources d’une classe de ressources spécifiée.

resetrsrc

Cette commande redéfinit les ressources d’une classe de ressources

spécifiée.

rmrsrc Cette commande supprime les ressources d’une classe de ressources

spécifiée.

runact Cette command exécute une action sur une classe de ressources.

startrsrc

Cette commande met une ressource en ligne.

stoprsrc

Cette commande met une ressource hors ligne.

Définition de ressources RSCT pour un serveur Web

L’exemple ci-dessous explique comment définir un serveur Web à haute

disponibilité sur les trois noeuds de la grappe SA_Domain. La section «Etape 1 :

Définition et administration d’une grappe», à la page 12 explique comment définir

la grappe et ses noeuds (node01, node02 et node03).

Les conditions requises suivantes doivent être satisfaites pour le serveur Web à

haute disponibilité :

v Le serveur Web doit pouvoir être démarré à partir de n’importe quel noeud de

la grappe, mais ne pourra fonctionner que sur un noeud à la fois.

v Le serveur Web doit pouvoir être redémarré automatiquement sur le même

noeud ou sur un noeud différent de la grappe en cas de défaillance. Ce

mécanisme permet également la mise en indisponibilité planifiée des noeuds à

des fins de maintenance.

v Le serveur Web doit être adressable avec la même adresse IP indépendamment

du noeud sur lequel il fonctionne. L’emplacement du serveur Web est

transparent en dehors de la grappe ; aucune adaptation ne doit être effectuée

lorsque le serveur Web est déplacé d’un noeud à un autre.

Mise en route


En tant que base de l’automatisation, les composants concernés doivent tout

d’abord être décrits dans un ensemble de ressources RSCT définies. En raison de la

présence fréquente de caractéristiques de ressources inhabituelles, il existe de

nombreuses classes de ressources RSCT pour prendre en charge les différences.

Dans cet exemple, nous devons définir trois ressources RSCT à partir de classes

différentes :

1. Une ressource d’application appelée apache1 qui représente le démon du

serveur Web. La ressource provient d’une classe appelée IBM.Application.

apache1 sera une ressource flottante car le serveur Web n’est pas lié à un noeud

spécifique de la grappe.

2. Une adresse IP appelée apache1IP utilisée pour représenter l’adresse IP du

serveur Web. apache1IP provient d’une classe appelée IBM.ServiceIP. apache1IP

sera une ressource flottante, car elle peut être déplacée dans la grappe en

fonction de l’emplacement du serveur Web.

3. Une représentation appelée netequ pour les cartes d’interface réseau pouvant

être utilisées pour l’adresse apache1IP. Cette représentation s’appelle une

équivalence et appartient à la classe IBM.Equivalency. La caractéristique

”flottante” ou “fixe” n’a pas d’importance dans cette classe.

Mise en route


Création de la ressource d’application apache1

Les commandes et les scripts de démarrage, d’arrêt et de requête du serveur Web

doivent être spécifiés car ils font partie de la définition de la ressource

d’application apache1. Ces commandes et/ou scripts peuvent être différents, mais

il est souvent préférable de regrouper ces fonctions dans un même script qui

possède un paramètre de lancement pour sélectionner les actions de

démarrage/d’arrêt/d’état. Ces scripts sont souvent rédigés par l’utilisateur.

Consultez le Chapitre 11, «Automatisation des ressources System Automation for

Multiplatforms», à la page 233 pour obtenir des informations supplémentaires sur

les exigences de ces scripts.

Dans cet exemple, nous utilisons un script

/cluster/scripts/apache

possédant le contenu suivant pour un système Linux :

#!/bin/bash

OPSTATE_ONLINE=1

OPSTATE_OFFLINE=2

Action=${1}

case ${Action} in

start)

/usr/sbin/apachectl start >/dev/null 2>&1

logger -i -t "SAM-apache" "Apache started"

RC=0

;;

stop)

/usr/sbin/apachectl stop >/dev/null 2>&1

logger -i -t "SAM-apache" "Apache stopped"

RC=0

;;

status)

ps -ax |grep -v "grep"|grep "/usr/sbin/httpd">/dev/null

if [ $? == 0 ]

then

RC=${OPSTATE_ONLINE}

else

RC=${OPSTATE_OFFLINE}

fi

;;

esac

exit $RC

Veillez à ce que le script soit accessible sur tous les noeuds à partir du même

chemin d’accès au répertoire.

Mise en route


Les définitions de ressource RSCT sont créées à l’aide de la commande mkrsrc.

Toutes les caractéristiques de la ressource peuvent être définies par le biais de

paramètres de ligne de commande, mais la commande mkrsrc prend également en

charge les fichiers de définition en texte en clair. Nous utiliserons la seconde

approche à l’aide d’un fichier de définitions appelé ″apache1.def″ qui ressemble au

fichier suivant :

PersistentResourceAttributes::

Name="apache1"

StartCommand="/cluster/scripts/apache start"

StopCommand="/cluster/scripts/apache stop"

MonitorCommand="/cluster/scripts/apache status"

MonitorCommandPeriod=5

MonitorCommandTimeout=5

NodeNameList={"node01","node02","node03"}

StartCommandTimeout=10

StopCommandTimeout=10

UserName="root"

ResourceType=1

La définition de ressource peut désormais être créée à l’aide de la commande

mkrsrc et du fichier de définitions.

mkrsrc -f apache.def IBM.Application

Création de la ressource d’adresse IP apache1IP

L’adresse IP du serveur Web apache1IP est une adresse IP distincte dans la grappe

et ne correspond à aucune adresse IP attribuée aux cartes réseau de chaque noeud

de grappe créée dans les définitions système en dehors de System Automation for

Multiplatforms. L’adresse d’apache1IP est au contraire créée par System

Automation for Multiplatforms et représente une adresse d’alias supplémentaire

sur un adaptateur de réseau approprié du noeud sur lequel le serveur Web est

installé. Lorsque le serveur Web est déplacé dans un nouvel emplacement,

l’adresse d’alias est supprimée de l’ancien noeud et recréée dans le nouveau noeud

où le serveur va être redémarré.

Dans cet exemple, apache1IP possède les attributs suivants :

v Adresse IP 9.152.172.11

v Masque de réseau 255.255.255.0

v L’adresse IP peut être créée dans n’importe quel noeud de la grappe.

Cette fois, nous allons utiliser des paramètres de ligne de commande avec la

commande mkrsrc pour créer la ressource apache1IP :

mkrsrc IBM.ServiceIP \

NodeNameList="{’node01’,’node02’,’node03’}" \

Name="apache1IP" \

NetMask=255.255.255.0 \

IPAddress=9.152.172.11

Notez que la commande illustrée est divisée en plusieurs lignes à des fins de

lisibilité. En réalité, l’adresse apache1IP possède davantage d’attributs que ceux

illustrés dans la commande. Nous ne modifions pas les valeurs par défaut des

autres attributs, tels que l’attribut ResourceType qui définit par défaut la ressource

comme “flottante”.

Notez également que les ressources gérées ne sont pas démarrées/arrêtées par une

application tiers, telle que le niveau d’exécution Linux ou une manipulation de

l’opérateur.

Mise en route


Etape 3 : Définition des règles d’automatisation à partir de la ligne de

commande

Avant de définir les règles d’automatisation, vous devez vous familiariser avec les

points suivants :

v Lorsque vous ajoutez une ressource à un groupe de ressources, cette ressource

est automatisée et contrôlée par System Automation for Multiplatforms. Cela

signifie qu’System Automation for Multiplatforms s’arrange pour remplacer

l’état opérationnel (OpState) de la ressource par l’état désiré/nominal défini

(NominalState) du groupe de ressources. Si une ressource automatisée par

System Automation for Multiplatforms est démarrée ou arrêtée manuellement

par un opérateur, System Automation for Multiplatforms le reconnaît en

contrôlant cette ressource et redémarre ou arrête cette ressource pour l’amener à

l’état défini dans les règles d’automatisation.

Si une ressource est définie dans les règles d’automatisation, System Automation

for Multiplatforms contrôle cette ressource et toute action manuelle sur cette

ressource déclenche généralement une action inverse de System Automation for

Multiplatforms.C’est également le cas pour toutes les ressources se trouvant sur des noeuds

exclus de l’automatisation (consultez la description de la commande samctrl

dans le Guide de référence d’IBM Tivoli System Automation for Multiplatforms).

Si à un certain moment System Automation for Multiplatforms ne doit pas

contrôler les ressources, l’automatisation peut être définie manuellement à l’aide

de la commande suivante :

# samctrl -M T

Pour redonner le contrôle des ressources à System Automation for

Multiplatforms le mode automatique doit de nouveau être défini, à l’aide de la

commande suivante :

# samctrl -M F

Pour plus d’informations, consultez les descriptions des commandes samctrl et

lssamctrl dans le Guide de référence d’IBM Tivoli System Automation for

Multiplatforms.

v La seule solution pour démarrer et arrêter en toute sécurité les ressources

(applications) contrôlées par System Automation for Multiplatforms consiste à

utiliser les commandes System Automation for Multiplatforms appropriées

(chrg, rgreq ou rgmbrreq). Seules ces commandes reflètent la modification de

l’état désiré d’une ressource à System Automation for Multiplatforms. Si une

ressource est démarrée ou arrêtée à l’aide de sa commande 'native', System

Automation for Multiplatforms dispose toujours de l’'ancien' état désiré de cette

ressource dans les règles d’automatisation et déclenche une commande de

démarrage ou d’arrêt sur cette ressource pour la ramener à l’état désiré.

v Pour les noeuds exécutés dans un domaine System Automation for

Multiplatforms, il convient de prendre en compte certaines informations

concernant la maintenance. Ces informations sont particulièrement importantes

pour les commandes permettant d’arrêter des noeuds (AIX/Solaris/Linux : halt

et reboot, Windows : shutdown, reboot, hibernate, freeze).

Avant d’être arrêté, un noeud doit être ajouté à la liste d’exclusion de

l’automatisation, ce qui amène System Automation for Multiplatforms à arrêter

toutes les ressources exécutées sur ce noeud et à déplacer ces ressources sur un

autre noeud. Une fois que toutes les ressources sont hors ligne sur ce noeud, il

peut être arrêté ou redémarré en toute sécurité. Si vous ne le faites pas, le noeud

est immédiatement réinitialisé si une 'ressource critique' est exécutée sur le

Mise en route


noeud arrêté/réinitialisé (voir Chapitre 9, «Protection de vos ressources –

support réalisé par Quorum», à la page 167). La commande suivante permet

d’ajouter un noeud à la liste d’exclusion :

# samctrl -u a <nom-noeud>

Maintenant, le noeud peut être arrêté en toute sécurité. Une fois que le noeud

est à nouveau en ligne dans le domaine, il doit être supprimé de la liste

d’exclusion à l’aide de la commande suivante :

# samctrl -u d <nom-noeud>

v System Automation for Multiplatforms ne démarrera pas les ressources se

trouvant sur des noeuds figurant dans la liste d’exclusion, même si les autres

noeuds sont hors ligne. Par conséquent, les noeuds ne doivent figurer dans la

liste d’exclusion que pendant la maintenance. Vous pouvez vérifier la liste

d’exclusion à l’aide de la commande suivante :

# lssamctrl

v Pour les domaines System Automation for Multiplatforms à deux noeuds (ou

possédant un nombre pair de noeuds), une condition de départage doit être

configurée. Sans condition de départage, le deuxième noeud ne prendra pas le

relais pour les ressources qui étaient en cours d’exécution sur un noeud victime

d’une défaillance ou redémarré. Reportez-vous au Chapitre 9, «Protection de vos

ressources – support réalisé par Quorum», à la page 167 pour découvrir les

types de condition de départage et la manière de les configurer.

Les exemples suivants illustrent comment les ressources apache1 et apache1IP sont

transformées en ressources gérées System Automation for Multiplatforms (voir

section «Qu’est-ce qu’une ressource gérée ?», à la page 30) offrant ainsi une haute

disponibilité au serveur Web dans un environnement en grappes. Voir l’«Etape 2 :

Définition des ressources RSCT», à la page 20 relative à la définition des ressources

apache1 et apache1IP.

Pour transformer des ressources "apache1" et "apache1IP" en ressources gérées,

vous devez les ajouter à un groupe de ressources. Lorsque vous avez effectué cette

opération, System Automation for Multiplatforms lance le contrôle du groupe de

ressources et de ses ressources membres.

Dans la plupart des cas, cette opération n’est pas suffisante pour automatiser une

ressource gérée car les ressources sont généralement liées les unes aux autres. Par

exemple, les ressources "apache1" et "apache1IP" de notre exemple doivent être

disponibles dans le même noeud. Ces dépendances entre des ressources gérées

doivent être décrites et définies à l’aide de relations gérées (voir section «Qu’est-ce

qu’une relation gérée ?», à la page 59).

Un objectif d’automatisation doit être défini : une ressource gérée doit-elle être

disponible/lancée dans la grappe ou être hors ligne ?


La liste ci-après offre une présentation des commandes utilisées pour définir des

règles. Pour obtenir une description détaillée des commandes, consultez le Guide de

référence d’IBM Tivoli System Automation for Multiplatforms.

mkequ

Crée une ressource d’équivalence

chequ Modifie une ressource d’équivalence

lsequ Répertorie les équivalence et leurs attributs

Mise en route


rmequ Supprime une ou plusieurs équivalences de ressource

mkrg Crée un groupe de ressources

chrg Modifie les valeurs d’attribut persistant d’un groupe de ressources (y

compris le démarrage et l’arrêt d’un groupe de ressources)

lsrg Répertorie les valeurs d’attribut persistant d’un groupe de ressources ou de

ses membres

rmrg Supprime un groupe de ressources

mkrel Crée une relation gérée entre des ressources

chrel Modifie une ou plusieurs relations gérées entre les ressources

lsrel Répertorie les relations gérées

rmrel Supprime une relation gérée entre des ressources

samctrl

Définit les paramètres de commande de System Automation for

Multiplatforms

lssamctrl

Répertorie les commandes System Automation for Multiplatforms

addrgmbr

Ajoute une ou plusieurs ressources à un groupe de ressources.

chrgmbr

Modifie les valeurs de l’attribut persistant d’une ressource gérée dans un

groupe de ressources

rmrgmbr

Supprime une ou plusieurs ressources du groupe de ressources

lsrgreq

Répertorie les requêtes en attente appliquées aux groupes de ressources ou

aux ressources gérées

rgmbrreq

Demande le démarrage ou l’arrêt d’une ressource gérée ou annule la

requête

rgreq Demande le démarrage, l’arrêt ou le transfert d’un groupe de ressources ou

annule la requête

lssam Répertorie les groupes de ressources définis et leurs membres sous forme

d’arborescence

sampolicy

Valide et active la règle définie dans un fichier d’entrée, met à jour la règle

en cours à partir du fichier d’entrée et désactive la règle en cours.

Enregistre également la règle en cours dans un fichier au format XML.

Création d’une définition d’équivalence pour les cartes réseau

Si un noeud de la grappe possède plusieurs connexions réseau, elles ne sont

toutefois pas toutes appropriées pour l’hébergement de l’adresse apache1IP en tant

qu’alias. Une définition d’équivalence spécifie les cartes réseau pouvant héberger

l’adresse apacheIP. Le terme ’équivalence’ signifie que chaque carte de

l’équivalence peut fournir la même fonction requise indépendamment de ses

Mise en route


propres caractéristiques uniques. Puisque le serveur Web doit pouvoir être démarré

dans chaque noeud de la grappe, au moins une carte de chaque noeud doit

apparaître dans l’équivalence.

Une équivalence regroupe un ensemble de ressources provenant d’une classe

différente. Les cartes réseau appartiennent à la classe IBM.NetworkInterface. Il

n’est pas nécessaire de fournir des définitions de ressource pour toutes les cartes

réseau des noeuds de grappe car RSCT dispose d’une fonction de récolte qui crée

automatiquement des définitions de ressource pour plusieurs ressources définies

dans le système.

La commande suivante (exemple pour Linux) crée ce qu’on appelle une

équivalence statique (netequ) qui contient un adaptateur de réseau pour chacun

des noeuds de la grappe :

mkequ netequ IBM.NetworkInterface:eth0:node01,eth0:node02,eth0:node03

Dans une équivalence statique, telle que celle créée à l’aide de la commande

ci-avant, les membres de l’équivalence sont spécifiés lors de la création de cette

dernière. Ce type d’équivalence présente l’avantage de pouvoir spécifier l’ordre des

ressources contenues dans l’équivalence. Par contre, les cartes réseau supprimées

de la définition de la grappe le sont également de l’équivalence et ne seront pas

rajoutées automatiquement si elles sont récoltées ultérieurement, ce qui se traduit

par un ensemble de membres réduit.

Une interface réseau est supprimée de la définition de la grappe si son adresse IP

est supprimée ou qu’elle est déconnectée. Si la carte réseau est réactivée

ultérieurement, elle est récoltée par System Automation et incluse de nouveau dans

la définition de la grappe, mais elle n’est pas rajoutée automatiquement à la

définition de l’équivalence.

Pour contourner cette limitation, vous pouvez créer une équivalence possédant une

chaîne de sélection dynamique, à l’aide de la commande suivante :

mkequ -D ’Name like "eth0" ’ netequ IBM.NetworkInterface

Cette définition inclut toutes les cartes réseau ’eth0’ disponibles dans la grappe. La

chaîne de sélection est évaluée chaque fois que System Automation doit déterminer

sur quel noeud les ressources doivent être démarrées. La liste des ressources ’eth0’

disponibles peut changer lorsque System Automation récolte de nouvelles cartes

réseau dans la grappe de manière périodique ou que les interfaces réseau non

définies (adresse IP supprimée ou déconnectée) sont supprimées de la définition de

la grappe. Toutefois les équivalences possédant une chaîne de sélection dynamique

ne peuvent pas être triées.

Création d’un groupe de ressources pour apache1 et

apache1IP

Vous pouvez créer un groupe de ressources à l’aide de la commande mkrg. La

commande suivante crée un groupe de ressources appelé "apacherg ":

mkrg apacherg

Les ressources "apache1" et "apache1IP" seront ajoutées dans le groupe de

ressources "apacherg". Effectuez cette opération à l’aide de la commande

addrgmbr. L’ajout de ressources dans le groupe de ressources provoque leur

transformation en ressources gérées :

addrgmbr -g apacherg IBM.Application:apache1

addrgmbr -g apacherg IBM.ServiceIP:apache1IP

Mise en route


Définition de relations entre les ressources du serveur Web

Deux conditions permettent de relier les ressources apache1 et apache1I :

v Les ressources doivent démarrer/être disponibles dans le même noeud de la

grappe. Il s’agit de la relation colocalisée (voir section «Relation Collocated», à la

page 81).

v En outre, il n’est pas nécessaire de démarrer le serveur Web apache1 dans un

noeud dans lequel l’adresse IP apache1IP n’a pas encore été établie. L’adresse

apache1IP doit être disponible avant qu’apache1 ne puisse être démarrée.

System Automation for Multiplatforms offre un type de relation Dépendant de

(voir section «Relation Dépendant de», à la page 70) qui rassemble les deux

conditions requises. La relation gérée est définie à l’aide de la commande mkrel.

La commande suivante crée la relation gérée apache1_dependson_ip1 qui définit

la dépendance de la ressource apache1 vers l’adresse IP apache1IP :

mkrel -p DependsOn -S IBM.Application:apache1 -G IBM.ServiceIP:apache1IP apache1_dependson_ip1

Notre exemple requiert une deuxième relation. Au cours de l’«Etape 2 : Définition

des ressources RSCT», à la page 20, nous avons créé une équivalence de ces cartes

réseau pouvant être utilisée pour la dénomination de l’adresse apache1IP. Cette

opération est décrite dans une deuxième relation appelée

apache1IP_dependson_netequ qui lie l’adresse apache1IP à l’équivalence netequ :

mkrel -p DependsOn -S IBM.ServiceIP:apache1IP -G IBM.Equivalency:netequ apache1IP_dependson_netequ

Mise en ligne du groupe de ressources du serveur Web

Lorsque des ressources sont ajoutées dans des groupes de ressources, elles

deviennent des ressources gérées possédant un objectif d’automatisation de mise

hors ligne. Cet objectif peut être modifié au niveau du groupe de ressources à

l’aide de la commande chrg. Pour mettre le groupe de ressources apacherg en

ligne, utilisez la commande :

chrg -o online apacherg

Lorsque vous avez créé et configuré vos grappes et vos noeuds, vous pouvez

commencer à utiliser les commandes de System Automation for Multiplatforms

afin de :

v créer, supprimer, modifier et répertorier les groupes de ressources et vérifier leur

présence en ligne. Voir le Chapitre 4, «Utilisation des groupes de ressources», à

la page 35 pour des informations supplémentaires.

v créer, supprimer, modifier et répertorier les ressources membres des groupes de

ressources et vérifier leur présence en ligne. Voir le Chapitre 3, «Utilisation des

ressources», à la page 29 pour obtenir des informations supplémentaires.

v créer, supprimer, modifier et répertorier les équivalences de ressources et vérifier

leurs informations d’état. Voir le Chapitre 5, «Utilisation des équivalences», à la

page 53 pour obtenir des informations supplémentaires.

v créer, supprimer, modifier et répertorier les ressources de relations gérées et

vérifier leurs informations d’état. Pour plus d’informations, voir Chapitre 6,

«Utilisation des relations gérées», à la page 59.

La liste complète des commandes de System Automation for Multiplatforms figure

dans le Guide de référence d’IBM Tivoli System Automation for Multiplatforms.

Mise en route


Chapitre 3. Utilisation des ressources

Les sections principales suivantes de ce chapitre expliquent comment utiliser les

ressources :

v «Qu’est-ce qu’une ressource ?»

v «Qu’est-ce qu’une ressource gérée ?», à la page 30

v «Attributs utilisés par les ressources», à la page 31

Il s’agit des commandes System Automation for Multiplatforms que vous utilisez

pour les ressources gérées :

Tableau 1. Commandes System Automation for Multiplatforms utilisées avec les ressources

gérées

Commande Description Commentaires

addrgmbr Ajoute une ou plusieurs ressources à un groupe de

ressources.

Pour des

informations

supplémentaires,

consultez les

descriptions de

commande dans

le document

Guide de référence

d’IBM Tivoli

System

Automation for

Multiplatforms.

chrgmbr Modifier les valeurs de l’attribut persistant d’une

ressource gérée dans un groupe de ressources

lsrg Répertorier un groupe de ressources déjà défini ou ses

ressources membres

rmrgmbr Supprimer une ou plusieurs ressources d’un groupe de

ressources

Qu’est-ce qu’une ressource ?

Une ressource est un élément matériel ou logiciel défini dans RMC à l’aide d’une

des méthodes décrites dans «Ressource», à la page 3.

Comme décrit dans la section «Intégration complète de RSCT à System

Automation for Multiplatforms», à la page 7, System Automation for

Multiplatforms utilise la fonction du RMC en tant que base. Par conséquent, une

ressource peut être parfois référencée en tant que ressource RMC.

Les ressources (adaptateur, programme, services, disque et autre) sont contrôlées

par un gestionnaire de ressources (Resource Manager) (dont l’abréviation est RM).

Qu’est-ce qu’une classe de ressources ?

Une classe de ressources est un ensemble de ressources de même type. Par

exemple, alors qu’une ressource peut être un système de fichiers donné ou une

machine hôte donnée, une classe de ressources peut être l’ensemble de systèmes de

fichiers ou des machines hôte. Une classe de ressources définit les caractéristiques

générales que les instances de classes de ressources peuvent prendre (par exemple,

tous les systèmes de fichiers posséderont des caractéristiques d’identification (tel

qu’un nom) ainsi que des caractéristiques de modification (indiquant s’ils doivent

être montés ou pas)). Chaque instance de ressource individuelle de la classe de

ressources va définir les valeurs des caractéristiques particulières (par exemple, le

système de fichiers se nomme ″/var″ et est un système de fichiers monté).


Qu’est-ce que les attributs de ressources ?

Un attribut de ressource décrit quelques caractéristiques d’une ressource. Si la

ressource représente une machine hôte, ses attributs identifient des informations

telles que le nom d’hôte, la taille de la mémoire physique, le type de machine, etc.

Il existe deux types d’attribut de ressource : les attributs persistants et les attributs

dynamiques.

Attributs persistants

Les attributs de la machine hôte mentionnés précédemment (nom d’hôte, taille de

la mémoire physique et type de machine) sont des exemples d’attributs

persistants : ils décrivent les caractéristiques durables d’une ressource. Bien que

vous puissiez modifier le nom d’hôte ou augmenter la taille de la mémoire

physique, ces caractéristiques sont en général stables et non modifiables.

Attributs dynamiques

Les attributs dynamiques se rapportent aux caractéristiques variables de la

ressource. Les attributs dynamiques d’une ressource hôte, par exemple, identifient

le nombre moyen de processus en attente dans la file d’attente d’exécution, le délai

d’inactivité du processeur, le nombre d’utilisateurs actuellement connectés, etc.

Qu’est-ce qu’une ressource gérée ?

Une ressource devient une ressource gérée par System Automation for Multiplatforms

(appelée plus simplement ressource gérée) dès qu’elle est ajoutée à un groupe de

ressources System Automation for Multiplatforms. Cette opération s’effectue à

l’aide de la commande System Automation for Multiplatforms addrgmbr (décrite

dans le Guide de référence d’IBM Tivoli System Automation for Multiplatforms). A partir

de ce point de vue, la ressource peut être gérée à l’aide de commandes et

programmes de System Automation for Multiplatforms.

Les ressources gérées sont fournies dans la classe de ressources

IBM.ManagedResource de System Automation for Multiplatforms.

Travailler avec des ressources

Notez qu’System Automation for Multiplatforms ne vous autorise pas à démarrer

et arrêter directement les ressources.

Le démarrage et l’arrêt des ressources est basé sur le paramétrage de l’attribut

NominalState d’un groupe de ressources. Par exemple, la définition de l’attribut

NominalState d’un groupe de ressources sur ’En ligne’ indique que vous souhaitez

démarrer les ressources dans le groupe de ressources. La définition de l’attribut

NominalState d’un groupe de ressources sur Hors ligne indique que vous

souhaitez arrêter les ressources dans le groupe de ressources. Voir les descriptions

dans les sections «Démarrage et arrêt d’un groupe de ressources», à la page 50 et

«Attribut NominalState», à la page 41.

Utilisation des ressources


Attributs utilisés par les ressources

Les ressources peuvent posséder les attributs suivants :

NodeNameList

Indique les noeuds dans lesquels la ressource est autorisée à

fonctionner. NodeNameList est un attribut persistant d’une

ressource RSCT.

SelectFromPolicy

Contient la liste des noeuds dans lesquels la ressource est

disponible. SelectFromPolicy est un attribut persistant d’une

ressource gérée.

ResourceType Indique si la ressource est autorisée à fonctionner dans plusieurs

noeuds ou dans un seul. ResourceType est un attribut persistant

d’une ressource RSCT.

OpState Spécifie l’état opérationnel de la ressource ou du groupe de

ressources. OpState est un attribut dynamique d’une ressource

RSCT.

Attribut NodeNameList

L’attribut persistant NodeNameList représente l’ensemble de noeuds dans lesquels

la ressource peut fonctionner.

Les noeuds dans lesquels System Automation for Multiplatforms a démarré les

ressources sont contrôlés par l’ordre des noeuds dans l’attribut NodeNameList des

ressources. Par défaut, chaque ressource flottante sera placée dans le premier

noeud de sa liste de noeuds dans lequel elle peut démarrer, en tenant compte de

toutes ses relations avec les autres ressources. Ce comportement peut être modifié

à l’aide de l’attribut SelectFromPolicy décrit ci après. Les ressources flottantes qui

doivent être colocalisées sont placées avant les ressources flottantes indépendantes

(il s’agit des ressources qui ne possèdent pas de relations avec d’autres ressources)

et non colocalisées.

S’il existe des ressources colocalisées possédant des listes de noeuds différentes, les

ressources sont placées dans le noeud choisi par la majorité des ressources. Dans

une situation de parité, un noeud est choisi au hasard.

Attribut SelectFromPolicy

Comme décrit ci-avant, l’attribut persistant NodeNameList définit la liste de

noeuds dans lesquels la ressource est disponible. Dans cette liste, les noeuds sont

classés dans l’ordre spécifié par l’utilisateur ou dans l’ordre dans lequel le

gestionnaire de ressources possédant la ressource les a rangés. L’attribut

SelectFromPolicy offre plus de flexibilité à l’utilisateur. Il permet de spécifier à

System Automation for Multiplatforms l’algorithme à utiliser lors de la sélection

d’un noeud dans une liste. Cette opération peut être effectuée dans un ordre

précis, ce qui signifie qu’System Automation for Multiplatforms commence

toujours par le début de la liste lorsqu’il détermine le prochain noeud disponible,

ou dans un ordre quelconque, ce qui signifie qu’System Automation for

Multiplatforms choisit un noeud au hasard.



Attribut ResourceType

L’attribut ResourceType est défini par le gestionnaire de ressources ou à la création

de la ressource. L’attribut persistant ResourceType indique si une ressource est :

v fixe en série (son attribut NodeNameList contient une entrée de noeud unique).

Ressource fixe

Une ressource fixe est une ressource dont il n’existe qu’une seule instance au

sein de la grappe. Elle est définie dans un noeud unique sur lequel elle

fonctionne. Elle représente une entité telle qu’un processus, un point de

montage ou un adaptateur réseau.

Si vous souhaitez définir une application fonctionnant simultanément sur

plusieurs noeuds de la grappe, vous devez définir une ressource fixe pour

chaque noeud, en spécifiant les mêmes attributs (par exemple, name,

commandes start/stop/monitor), mais un nom de noeud différent pour

chaque ressource fixe.v flottant en série (son attribut NodeNameList contient une ou plusieurs entrées).

Bien que plusieurs noeuds soient définis pour d’éventuelles utilisations, une

seule instance de la ressource peut être active à la fois. Par exemple, une adresse

IP pouvant être déplacée d’une machine à une autre est une ressource flottante ;

si plusieurs machines ont utilisé l’adresse IP à un moment donné, une seule

machine à la fois peut l’utiliser.

Ressource flottante

Une ressource flottante est une ressource pouvant fonctionner dans

plusieurs noeuds de la grappe. Une ressource flottante est représentée

comme suit dans le RMC : vous trouvez une ressource d’agrégat et une

ressource constituante dans chaque noeud appartenant à la ressource

d’agrégat.

La ressource d’agrégat possède une valeur d’attribut ResourceType de 1.

L’ensemble de noeuds dans lesquels la ressource doit pouvoir

fonctionner est défini dans l’attribut NodeNameList de la ressource

d’agrégat. Les autres attributs de cette ressource sont définis dans le

gestionnaire de ressources et ses définitions de classes.

Si vous créez une ressource flottante, vous créez la ressource d’agrégat.

Le gestionnaire de ressources disponible pour ce type de ressources crée

des ressources constituantes dans chaque noeud sur lequel la ressource

est supposée fonctionner. Les ressources constituantes possèdent leurs

propres valeurs pour les attributs. L’attribut ResourceType d’une

ressource constituante est 0 (ressource fixe) et l’attribut NodeNameList



contient un seul et unique noeud. Lors de la création, les autres attributs

possèdent des valeurs identiques à celles de la ressource d’agrégat.

Les événements suivants ont lieu lorsque vous modifiez les attributs

d’une ressource flottante :

– La modification de l’attribut NodeNameList provoque la suppression

ou la création de ressources constituantes.

– Si vous modifiez un attribut de la ressource d’agrégat, les attributs de

toutes les ressources constituantes seront modifiés en conséquence.

– Si vous modifiez un attribut d’une ressource constituante, cette

modification affecte la ressource constituante uniquement et n’est pas

propagée aux autres ressources constituantes ou à la ressource

d’agrégat.

Une ressource flottante représente une entité bureautisable telle qu’une

application ou une adresse IP de service pouvant fonctionner dans

plusieurs noeuds.

Remarque : Une ressource flottante est libellée en tant que groupe de

déplacement dans console d’opérations.

Attribut OpState

RMC utilise l’attribut dynamique OpState afin de spécifier l’état opérationnel d’une

ressource. Cette opération est obligatoire pour les ressources ajoutées dans un

groupe de ressources.

Les valeurs suivantes sont les valeurs possibles pour l’attribut OpState :

Hors ligne La ressource n’est pas lancée.

En attente en ligne

La ressource a été démarrée, mais elle n’est pas prête à fonctionner.

En ligne La ressource est prête à fonctionner.

En attente hors ligne

La ressource est en cours d’arrêt.

Certains états opérationnels font état d’un problème :

Echec hors ligne

La ressource est cassée et ne peut être utilisée. Vous devez

réinitialiser la ressource lorsque elle est réparée.

Arrêt en ligne La ressource a été démarrée, mais n’est pas devenue disponible

dans l’intervalle de temps escompté et ne peut être mise hors ligne.

Une autre possibilité est que la ressource était en ligne et qu’une

requête de mise hors ligne n’est pas parvenue à la mettre hors

ligne.

Inconnu System Automation for Multiplatforms est incapable d’obtenir des

informations d’état fiables du RMC gérant la ressource.

Remarque : Vous devrez peut-être redémarrer une ressource possédant l’état Echec

hors ligne. Pour ce faire, utilisez la commande RMC resetrsrc. Pour

plus d’informations, consultez la page d’aide de cette commande ou la

documentation de RSCT (voir «Informations connexes», à la page xv).



Lorsque le noeud d’une ressource est hors ligne, la ressource est considérée comme

possédant l’état Echec hors ligne, même si son état opérationnel est défini sur

Inconnu à cette étape. System Automation for Multiplatforms peut procéder de la

sorte car il possède des données d’état différentes pour le noeud des ressources.

L’attribut NominalState peut être défini uniquement pour les

groupes de ressources

L’attribut NominalState peut être défini uniquement pour des groupes de

ressources. La valeur de l’attribut NominalState d’un groupe de ressources (En

ligne ou Hors ligne) détermine si l’ensemble de ses membres sera mis

automatiquement En ligne ou Hors ligne. Le fait que les ressources individuelles

ne possèdent pas d’attribut NominalState explique pourquoi toutes les ressources

doivent être membres d’un groupe de ressources.



Chapitre 4. Utilisation des groupes de ressources

Ce chapitre décrit comment utiliser les groupes de ressources dans les sections

principales suivantes :

v «Qu’est-ce qu’un groupe de ressources ?», à la page 36

v «Attributs utilisés par les groupes de ressources», à la page 38

v «Création d’un groupe de ressources», à la page 48

v «Modification des attributs d’un groupe de ressources», à la page 50

v «Suppression d’un groupe de ressources», à la page 51

v «Enumération des groupes de ressources et de leurs membres», à la page 49

v «Ajout d’une ressource membre dans un groupe de ressources», à la page 48

v «Suppression d’une ressource membre d’un groupe de ressources», à la page 51

v «Modification des attributs des membres d’un groupe de ressources», à la page

50

Section connexe :

v «Evénements permettant la Mise en ligne d’un groupe de ressources», à la page

97

Le tableau 2 répertorie les commandes System Automation for Multiplatforms que

vous utilisez avec le groupe de ressources. Pour plus d’informations, consultez la

description de la commande dans le Guide de référence d’IBM Tivoli System


Tableau 2. Commandes System Automation for Multiplatforms utilisées avec les groupes de

ressources

Commande Description

mkrg Créer un groupe de ressources

rmrg Supprimer un groupe de ressources

chrg Modifier les attributs persistants d’un groupe de ressources (y compris

le démarrage et l’arrêt d’un groupe de ressources)

lsrg Répertorier un ou plusieurs groupes de ressources

addrgmbr Ajouter des ressources membres dans un groupe de ressources

rmrgmbr Supprimer des ressources membres d’un groupe de ressources

chrgmbr Modifier les attributs des ressources membres d’un groupe de

ressources

rgreq Démarrer, arrêter, annuler ou déplacer un groupe de ressources

rgmbrreq Demande le démarrage, l’arrêt ou l’annulation d’une ressource gérée

lsrgreq Répertorie les requêtes en attente appliquées aux groupes de ressources

ou aux ressources gérées


Qu’est-ce qu’un groupe de ressources ?

Les groupes de ressource constituent le noyau central de System Automation for

Multiplatforms. Il s’agit de conteneurs logiques pouvant accueillir une série de

ressources pouvant être traitées comme une seule instance logique :

v Vous pouvez utiliser les groupes de ressources pour contrôler tous leurs

membres de manière collective. Par exemple, si vous définissez l’état nominal

(NominalState) d’un groupe de ressources sur En ligne, tous les membres sont

lancés et gérés en ligne. Si vous définissez l’état nominal (NominalState) sur

Hors ligne, tous les membres sont arrêtés et gérés hors ligne.

v Vous pouvez surveiller leur état opérationnel, qui assure une consolidation des

états opérationnels des membres de groupes de ressources.

Les membres d’un groupe de ressources peuvent être de l’un des types suivants :

v fixe en série.

v flottante en série.

v ou des groupes de ressources eux-mêmes ce qui signifie que des groupes

imbriqués peuvent être définis.

Un exemple de groupe de ressources avec des ressources fixes est un groupe de

ressources RG_Fix contenant des ressources fixes en série. Elles constituent un

serveur Web FixWebServer pouvant uniquement fonctionner dans le noeud node1

ainsi qu’une ressource de base de données FixDB2 située sur le noeud node2.

Afin de pouvoir démarrer les ressources FixWebServer et FixDB2, définissez l’état

nominal (NominalState) de RG_Fix sur En ligne. Cet exemple démontre également

que System Automation for Multiplatforms peut traiter des membres de groupes

de ressources répartis sur différents noeuds d’une grappe.

Groupes de ressources


Un exemple de membres de groupe de ressources flottantes est le suivant : un

serveur Web apache1 pouvant fonctionner sur les noeuds node1, node2 ou node3.

Le groupe de ressources RG_WebApp sera quasi identique à l’exception que le

serveur Web peut être démarré sur n’importe quel des trois noeuds.

Cet exemple illustre que les groupes de ressources peuvent contenir plusieurs

types de ressources.

Le concept de groupes de ressources est très puissant car il permet de définir des

groupes de ressources en tant que membres d’autres groupes de ressources.

Prenons par exemple, le groupe de ressources RG_A possédant une ressource

membre A, qui est elle même une ressource fixe, et le groupe de ressources

RG_WebApp issu de notre exemple précédent. Les groupes de ressources

imbriqués permettent de structurer des environnements complexes en plusieurs

couches. Le niveau d’imbrication est de 50.

Une autre souplesse de la fonctionnalité des groupes de ressources est que tous les

types de relations, tels que les relations de démarrage/d’arrêt et les relations de

contrainte, peuvent être définis avec des groupes de ressources comme ressource

source ou cible. En outre, les membres d’un groupe de ressources peuvent faire

partie de relations en tant que ressources source ou cible.

Les groupes de ressources sont définis dans la classe de ressources

IBM.ResourceGroup de System Automation for Multiplatforms.

Règles d’utilisation des groupes de ressources

Les règles suivantes concernent l’utilisation des groupes de ressources :

1. Un groupe de ressources ne peut pas contenir d’équivalence et vice versa.

2. Une ressource peut uniquement être présente dans un seul groupe.

3. Un membre ne peut être présent dans un groupe et une équivalence.

4. Le niveau d’imbrication d’un groupe de ressources est limité à 50.

5. Le nombre de ressources liées par groupes ou relations ne doit pas

dépasser 100.


Chapitre 4. Utilisation des groupes de ressources 37

Attributs utilisés par les groupes de ressources

Un groupe de ressources propose les attributs persistants RSCT suivants pouvant

être définis par l’utilisateur :

AllowedNode Limite les noeuds dans lesquels les membres de groupes de

ressources peuvent être démarrés.

MemberLocation

Définit si tous les membres d’un groupe de ressources doivent être

colocalisés ou non. Le terme ’colocalisé’ signifie que tous les

membres doivent être exécutés dans le même noeud. Le terme

’aucun’ signifie que les membres ne sont pas dépendants les uns

des autres et peuvent fonctionner de manière arbitraire dans les

noeuds dans lesquels ils sont définis.

Nom Définit un nom unique pour un groupe de ressources.

NominalState Indique l’état souhaité du groupe de ressources. System

Automation for Multiplatforms tente d’amener et de conserver le

groupe de ressources sur l’état nominal.

Priorité Définit l’importance d’un groupe de ressources en cas de conflit.

ExcludedList Définit une liste de noeuds temporairement exclus de la liste de

noeuds du groupe.

ActivePeerDomain

Représente le nom du domaine homologue dans lequel le groupe

est défini. Cet attribut ne peut pas être défini par l’utilisateur.

Description Peut contenir un texte descriptif concernant le groupe de

ressources.

InfoLink Peut être utilisé pour indiquer l’URL d’une page HTML où

l’opérateur pourra trouver des informations supplémentaires sur la

ressource.

Propriétaire fournit des informations concernant le propriétaire du groupe de

ressources, par exemple, le nom et le numéro de téléphone d’un

responsable.

Abonnement Peut contenir des informations sur l’abonnement grâce à une

gestion de bout en bout.

Remarque : Les attributs persistants décrits dans cette section peuvent uniquement

être modifiés si le groupe de ressources qui les contient est hors ligne.

Les exceptions à cette règle sont l’attribut NominalState et les attributs

d’information Description, InfoLink, et Propriétaire, qui peuvent

également être modifiés lorsque le groupe de ressources est En ligne.

Un groupe de ressources fournit les attributs dynamiques suivants :

OpState Spécifie l’état opérationnel général de l’ensemble des ressources

gérées.

TopGroup Affiche le nom du groupe de ressources de niveau supérieur d’un


AutomationDetails

Affiche les états internes System Automation for Multiplatforms du




MoveStatus Montre la progression du déplacement d’un groupe de ressources

demandé par le biais d’une commande rgreq.

ConfigValidity

Indique si une règle est devenue invalide.

Attribut AllowedNode

Utilisez l’attribut AllowedNode pour définir un ensemble de noeuds dans une

grappe qui n’autorise le fonctionnement que d’un nombre limité de membres du


Vous pouvez choisir entre les paramètres suivants :

Tous Il s’agit de la valeur par défaut. Elle indique que le groupe de

ressources n’impose aucune restriction. Il peut fonctionner dans

n’importe quel noeud de la grappe.

Un noeud Définit un noeud spécifique dans lequel tous les membres du

groupe de ressources doivent fonctionner. Si vous supprimez le

noeud spécifié de la grappe ultérieurement, l’attribut AllowedNode

sera défini par défaut sur All.

Equivalence de noeuds

Contient un ensemble de noeuds dans lesquels les membres du

groupe de ressources peuvent uniquement fonctionner. Seules les

équivalences statiques sont autorisées. Consultez également le

Chapitre 5, «Utilisation des équivalences», à la page 53.

Aspect de limitation du noeud au niveau du paramètre

AllowedNode

Dans certains cas de figure, il peut s’avérer utile de limiter le fonctionnement d’un

membre du groupe de ressources sur un ensemble de noeuds. Par exemple,

lorsqu’une ressource flottante est définie, un attribut NodeNameList, dont le

fonctionnement est, en règle générale, indépendant de l’utilisation de System

Automation for Multiplatforms, doit être spécifié. L’attribut NodeNameList des

ressources flottantes est utilisé par les gestionnaires de ressources (par exemple, le

GblResRM) qui détiennent une ressource flottante. L’attribut NodeNameList

définit, pour les gestionnaires de ressources, les noeuds sur lesquels une ressource

flottante peut fonctionner. L’attribut AllowedNode, quant à lui, appartient à un

paramètre de groupe de ressources possédant divers membres de groupe de

ressources qui sont des ressources flottantes. L’attribut AllowedNode autorise la

limitation des noeuds sur lesquels les membres de groupe de ressources peuvent

fonctionner. Pour les membres de groupe de ressources des types suivants, cela

signifie :

v Pour une ressource fixe , que l’attribut NodeNameList, contenant uniquement le

noeud sur lequel la ressource est située, doit faire partie du paramètre

AllowedNode.

v Pour une ressource flottante, que l’intersection des paramètres NodeNameList et

AllowedNode définit l’ensemble de noeuds dans lesquels la ressource flottante

est démarrée et contrôlée par System Automation for Multiplatforms.

v Pour un groupe de ressources, que l’intersection entre le paramètre

AllowedNode et le groupe interne et externe provient d’une liste de noeuds

autorisés pour le groupe interne. La liste résultante définit les noeuds sur

lesquels les membres du groupe de ressources interne sont autorisés à

fonctionner.



L’exemple suivant explique le comportement du paramètre AllowedNode dans une

limitation de noeuds : soit, un groupe de ressources externe RG_A possédant un

membre FixA dont l’attribut NodeNameList = {node1}, un membre de ressource

flottante FloatB dont l’attribut NodeNameList ={node1, node2, node3} et un groupe

de ressources RG_B dont l’attribut AllowedNode = {node2, node3, node4}. La liste

AllowedNode du groupe RG_A définit les noeuds {node1, node2, node 4}. Le

groupe RG_B contient le membre FloatC avec l’attribut NodeNameList {node1,

node2, node3,node4} et le membre FloatD avec l’attribut NodeNameList {node3,

node4}.

Le résultat de ce scénario est le suivant :

v FixA peut uniquement être démarré par System Automation for Multiplatforms

sur le noeud node1.

v FloatB peut uniquement être démarré par System Automation for Multiplatforms

sur les noeuds node1 et node2.

v Les membres du groupe RG_B peuvent uniquement fonctionner sur les noeuds

node2 et node4.

v FloatC peut uniquement être démarré par System Automation for

Multiplatforms sur les noeuds node2 et node4.

v FloatD peut uniquement être démarré par System Automation for

Multiplatforms sur le noeud node4.

La liste des noeuds autorisés (AllowedNode) d’un groupe interne n’est pas

appliquée lorsque son groupe externe ne possède aucune limitation de noeuds en

raison de l’intersection entre son paramètre AllowedNode et la liste AllowedNode

de son groupe externe.

Attribut MemberLocation

Utilisez l’attribut persistant MemberLocation pour spécifier l’emplacement par

défaut des ressources dans le groupe de ressources. Les valeurs correctes sont les

suivantes :

Collocated (valeur par défaut)

Le terme ’colocalisé’ signifie que tous les membres doivent être

exécutés dans le même noeud. Si vous spécifiez la valeur



’Collocated’, vous ne pouvez pas utiliser les relations gérées

Affinity, AntiAffinity et AntiCollocated entre des ressources du

groupe de ressources pour spécifier les noeuds dans lesquels les

ressources membres doivent se trouver. Consultez le Chapitre 6,

«Utilisation des relations gérées», à la page 59 pour obtenir des

informations détaillées sur les relations.

None Le terme ’None’ signifie que le groupe de ressources n’impose

aucune restriction relative à l’emplacement de ses membres.

L’attribut MemberLocation s’applique à toutes les ressources membres du groupe

de ressources.

Si les groupes de ressources sont imbriqués, la valeur de l’attribut MemberLocation

des groupes de ressources externes doit autoriser la spécification d’un ou plusieurs

groupes internes. Par conséquent, si l’attribut MemberLocation d’un groupe de

ressources est défini sur Collocated, seuls les groupes de ressources colocalisés sont

autorisés comme membres.

Attribut Name

Le nom d’un groupe de ressources doit être unique au sein d’une grappe.

Attribut NominalState

Utilisez l’attribut persistant NominalState pour contrôler un groupe de ressources.

Si vous définissez l’état nominal (NominalState) d’un groupe de ressources sur En

ligne, tous ses membres seront démarrés et maintenus en ligne.

L’attribut NominalState peut être défini sur En ligne ou Hors ligne. Un état

nominal défini sur Hors ligne provoque l’arrêt de tous les membres du groupe de

ressources et leur maintien hors ligne. Il existe certaines exceptions :

1. Si les groupes de ressources sont imbriqués, un état nominal défini sur En ligne

pour un groupe externe provoque l’annulation d’un état nominal défini sur

hors ligne pour un groupe interne et le démarrage de ces groupes internes.

Vous ne pouvez pas arrêter les groupes internes séparément.

2. Si les groupes de ressources sont imbriqués, un état nominal défini sur Hors

ligne pour un groupe externe ne provoque pas l’annulation d’un état nominal

défini sur En ligne pour un groupe interne. Un état nominal En ligne pour un

groupe interne provoque le démarrage de ce groupe et des groupes qu’il

contient. L’état opérationnel du groupe externe sera modifié, mais les membres

des autres groupes resteront inchangés.

3. Les dépendances de groupes croisées peuvent provoquer le démarrage forcé de

membres individuels de groupes. Consultez la section «Relations du

comportement de démarrage/d’arrêt», à la page 62.

La valeur par défaut pour l’état nominal d’un groupe de ressources est Hors ligne.

Vous pouvez modifier cet attribut à n’importe quel moment.

Remarque : Vous pouvez modifier cet attribut à l’aide de la commande chrg –o

(consultez la description de la commande chrg dans le Guide de

référence d’IBM Tivoli System Automation for Multiplatforms). La valeur

numérique de cet attribut est

1 Hors ligne

0 En ligne



Attribut Priorité

Utilisez l’attribut persistant Priorité pour spécifier la priorité relative du groupe de

ressources par rapport aux autres groupes de ressources.

L’attribut Priorité est utilisé pour résoudre des conflits liés au démarrage de

groupes de ressources dont les relations gérées entrent en conflit (décrit dans le

Chapitre 6, «Utilisation des relations gérées», à la page 59) avec des ressources

démarrées ou en ligne. Ces conflits peuvent naître entre le groupe de ressources ou

la relation gérée de ce groupe et toute autre ressource démarrée ou en cours de

fonctionnement.

Si un groupe comporte des membres ayant un état Non lié ou Hors ligne, il

n’existe pas de valeur de réajustement de +10. Pour les groupes de ressources qui

possèdent la même priorité, le nombre de membres non obligatoires détermine

l’ordre. Le groupe avec le plus petit nombre de membres non obligatoires est

sacrifié en premier. Si les groupes possèdent un même niveau de priorité et un

même nombre de membres non obligatoires, c’est l’algorithme qui décide du

groupe qui sera sacrifié.

Prenons, par exemple, une grappe avec un seul noeud en ligne et deux groupes de

ressources possédant une relation AntiCollocated l’un envers l’autre. Cela signifie

que les groupes de ressources ne peuvent jamais être démarrés dans le même

noeud en même temps. System Automation for Multiplatforms utilise désormais la

valeur de l’attribut Priorité des groupes de ressources afin de déterminer lequel

des groupes doit être en ligne, et celui qui ne peut être en ligne en raison de la

relation AntiCollocated contradictoire.

Si un groupe de ressources actif possédant un niveau de priorité moindre empêche

l’activation d’un groupe de ressources possédant un niveau de priorité plus élevé

en raison de relations contradictoires, le groupe ressources avec la priorité la plus

faible sera arrêté afin de permettre l’activation du groupe avec la priorité la plus

élevée.

Si les groupes de ressources sont imbriqués, le groupe de ressources externe doit

posséder un niveau de priorité égal au supérieur à celui du groupe de ressources

interne.

La valeur par défaut de l’attribut Priorité est zéro, c.-à-d. la valeur la plus faible.

La valeur maximale est 200.

La véritable priorité d’un groupe de ressources est calculée à partir de la valeur de

l’attribut de priorité et d’une valeur d’ajustement déterminée par l’état observé

actuel du groupe (voir «Attribut AutomationDetails», à la page 45). La valeur

d’ajustement des groupes en ligne est de +10, pour rendre plus difficile le sacrifice

des ressources démarrées est de -10 pour les groupes à l’état Echec hors ligne. La

véritable valeur de la priorité peut être comprise entre -10 et +210. (Pour plus

d’informations sur la signification de la priorité, voir «Définition de la relation

d’emplacement : algorithme de liaison», à la page 93.)



Astuce : System Automation for Multiplatforms utilise également l’attribut

Obligatoire des ressources gérées (décrit à la section «Attributs utilisés pour les

membres de groupes de ressources», à la page 47) pour déterminer les ressources

qui seront démarrées en cas de conflit. Lorsqu’il s’agit de groupes de ressources

imbriqués, les groupes de ressources qui sont des membres facultatifs doivent

posséder un niveau de priorité inférieur à celui des membres obligatoires. Le cas

échéant, les membres obligatoires peuvent être supprimés.

Attribut ExcludedList

Utilisez l’attribut ExcludedList afin d’exclure temporairement un noeud ou une

liste de noeuds de la liste de noeuds du groupe. Lorsque vous excluez un noeud,

les ressources résidant dans le noeud exclu ne subissent pas automatiquement un

arrêt forcé. Le déplacement doit être déclenché par le biais de la commande rgreq.

Cela signifie que lorsque vous placez un noeud dans la liste d’exclusion, System

Automation for Multiplatforms ne considère pas le noeud comme un candidat

potentiel pour héberger la ressource. Cet attribut peut être utilisé pour déplacer

progressivement et sans interruption de service des ressources d’un noeud en vue

d’une exclusion ultérieure (par le biais de la commande samctrl).

Les règles suivantes sont d’application :

1. L’exclusion d’un noeud signifie, pour un membre d’un groupe de ressources

fixes, que la ressource ne peut plus être démarrée.

2. L’exclusion d’un noeud signifie, pour un membre d’un groupe de ressources

flottantes, que ses constituants situés sur ce noeud ne peuvent plus être

démarrés.

ActivePeerDomain

Cet attribut indique le nom de domaine homologue RSCT dans lequel le groupe

est défini.

Description

Cet attribut peut contenir un texte descriptif concernant le groupe de ressources.

Cet attribut ne répond qu’à des besoins d’information et n’affecte pas les fonctions

d’automatisation.

InfoLink

Cet attribut peut être utilisé pour spécifier l’URL d’une page HTML où l’opérateur

pourra trouver des informations supplémentaires sur la ressource. Cet attribut ne

répond qu’à des besoins d’information et n’affecte pas les fonctions

d’automatisation.

Propriétaire

Cet attribut fournit des informations concernant le propriétaire du groupe de

ressources, par exemple, le nom et le numéro de téléphone du responsable. Cet

attribut ne répond qu’à des besoins d’information et n’affecte pas les fonctions

d’automatisation.

Abonnement

Cet attribut contient des informations sur l’abonnement issues de la fonction de

gestion de bout en bout.



Attribut OpState

System Automation for Multiplatforms utilise l’attribut dynamique OpState afin de

spécifier l’état opérationnel général de l’ensemble (des ressources gérées). Cet état

général est déterminé à partir des états opérationnels individuels des ressources

membres du groupe de ressources. Les valeurs possibles pour l’attribut OpState

sont les suivantes :

Etat Valeur Description

Inconnu 0

En ligne 1 Indique que toutes les ressources membres obligatoires

sont en ligne. Les ressources membres facultatives sont

ignorées.

Hors ligne 2 Indique que toutes les ressources membres sont hors

ligne.

Echec Hors ligne 3 Indique si une ou plusieurs ressources membres

contenues dans le groupe de ressources ont l’état Echec

en ligne. Dans ce cas, toutes les ressources contenues

dans le groupe de ressources seront définies sur Hors

ligne.

Un groupe de ressources peut obtenir l’état Echec hors

ligne suite à l’exécution d’une liaison si des membres

d’un groupe de ressources n’ont pu être placés (voir aussi

«Définition de la relation d’emplacement : algorithme de

liaison», à la page 93). Dans un tel cas, les détails de

l’automatisation indique l’état BindingState comme

Sacrifié (voir aussi «Attribut AutomationDetails», à la

page 45).

Arrêt en ligne 4 Indique qu’une ressource membre est définie sur Arrêt en

ligne.

En attente en ligne 5 Indique qu’une commande de démarrage a été exécutée

(l’attribut NominalState du groupe de ressources est

défini sur En ligne). Le groupe de ressources doit

commencer à traiter une action en ligne.

En attente hors ligne 6 Indique qu’une action de mise hors ligne a été lancée.

Attribut TopGroup

Cet attribut indique le groupe de ressources de niveau supérieur d’un groupe de

ressources.

Dans System Automation for Multiplatforms, les groupes de ressources peuvent

être membres d’un autre groupe de ressources et donc être imbriqués. L’attribut

TopGroup affiche le nom du groupe de ressources de niveau supérieur du groupe

courant. L’attribut peut être affiché à l’aide de la commande lsrg, comme indiqué

dans le Guide de référence d’IBM Tivoli System Automation for Multiplatforms et

expliqué ci-dessous.

Remarque : Lorsque la commande lsrg –g est utilisée pour envoyer une requête à

un groupe de ressources, l’attribut NominalState du groupe de niveau

supérieur est indiqué dans le résultat aux côtés de l’attribut

TopGroup. Le résultat se présente sous cette forme :

TopGroup = apacherg

TopGroupNominalState = Offline



Attribut AutomationDetails

Cet attribut affiche les états internes d’automatisation système du groupe. Ces états

incluent :

CompoundState

Statut général du groupe de ressources incluant les dépendances.

L’état ’Satisfaisant’, par exemple, indique que le groupe/la

ressource a atteint l’état demandé par l’utilisateur.

DesiredState Etat du groupe de ressources demandé par l’utilisateur. L’état ’En

ligne’, par exemple, indique que l’utilisateur a demandé que le

groupe de ressources soit en ligne.

ObservedState

L’état réel du groupe de ressources du point de vue de

l’automatisation. L’état ’En ligne’, par exemple, indique que le

groupe de ressources est actuellement en ligne.

BindingState Etat indiquant si le groupe de ressources est lié à un système

spécifique. L’état ’Lié’, par exemple, indique que le groupe de

ressources est actuellement lié à un système spécifique.

AutomationState

Etat indiquant si le groupe de ressources est en cours

d’automatisation. Par exemple, ″En veille″ signifie que System

Automation for Multiplatforms n’est pas en train d’essayer de

démarrer ou d’arrêter la ressource.

ControlState Etat indiquant si le groupe de ressources peut être contrôlé à l’aide

de l’automatisation. L’état ″Démarrable″, par exemple, indique

qu’il est actuellement possible de démarrer ce groupe de

ressources.

HealthState C’est état n’est pas encore utilisé, il est réservé pour les versions

futures.

Pour afficher les détails d’automatisation comme indiqué ci-dessus, vous devez

utiliser la commande lsrg avec les option –A d et –V. Par exemple, pour afficher

les détails de l’automatisation d’un groupe de ressources ″apacherg″, utilisez la

commande :

lsrg –A d –V –g apacherg



Attribut MoveStatus

Cet attribut dynamique indique la progression de déplacement d’un groupe de

ressources lancé à l’aide de la commande rgreq.

Pour récupérer l’état de progression, utilisez la commande lsrg conjointement aux

options -A d et -V.

Exemple :

Pour récupérer l’état de progression du groupe de ressources ″apacherg″, utilisez la

commande suivante :

lsrg –A d -V –g apacherg

Tableau 3. Valeurs MoveStatus

Valeurs MoveStatus Description

Non défini Etat pendant l’initialisation

Non pris en charge Le déplacement n’est pas pris en charge

None Ne fait pas partie du processus de

déplacement

En cours de préparation Les opérations de déplacement ont été

démarrées

Arrêt Hors ligne - Phase 1 : les ressources sont

arrêtées

Annulation Le déplacement est annulé (non disponible)

Démarrage Phase En ligne : les ressources sont

redémarrées

Retour en arrière Le déplacement a échoué, redémarrez les

groupes sur les noeuds d’origine

En cours d’achèvement Le déplacement se termine

ConfigValidity

Lorsqu’une règle a été établie, plusieurs circonstances peuvent engendrer

l’invalidité de cette règle. Cet attribut indique la cause de cette invalidité.

Par exemple, si un noeud est supprimé du domaine homologue et qu’il s’agissait

de l’unique noeud commun des membres d’un groupe de ressources colocalisé, les

ressources ne peuvent plus être démarrées. Ce cas de figure sera indiqué par

l’attribut ConfigValidity.



Attributs utilisés pour les membres de groupes de ressources

Pour chaque membre de groupe de ressources, l’utilisateur doit définir des

attributs persistants :

Mandatory Défini pour chaque membre de groupe de ressources, il indique si

le membre est obligatoire pour le groupe. Un membre peut aussi

être facultatif.

MemberOf Le nom du groupe de ressources dont les ressources sont membres.

SelectFromPolicy

Utilisé pour indiquer à System Automation for Multiplatforms

l’endroit où les ressources flottantes doivent être démarrées.

ConfigValidity

Cet état est réservé pour une utilisation ultérieure.

Attribut Mandatory

Utilisez l’attribut persistant Mandatory pour indiquer si une ressource gérée est

obligatoire (Mandatory) ou facultative (Non-Mandatory).

Lorsqu’un groupe de ressources est démarré, toutes les ressources gérées

obligatoires (Mandatory) au sein d’un groupe doivent également être démarrées.

Les ressources gérées facultatives (Non-Mandatory) (dont l’attribut Mandatory est

défini sur faux (False)) ne peuvent être démarrées en cas de conflit. Si une

ressource gérée obligatoire (Mandatory) échoue, le groupe de ressources complet

est arrêté et démarré dans un autre noeud, mais si un membre facultatif du groupe

de ressources échoue, le groupe de ressources reste en ligne dans ce noeud.

Les ressources membres d’un groupe de ressources sont obligatoires sauf si la

valeur de l’attribut est explicitement définie sur False.

Les ressources membres avec un attribut de ressource gérée Mandatory défini sur

False, peuvent être éliminées afin d’activer le groupe de ressources.

Attribut MemberOf

Indique que la ressource est contenue dans une ressource d’un groupe de

ressources. L’attribut persistant MemberOf est généré de manière implicite lorsque

des ressources (notamment des groupes de ressources imbriqués) sont ajoutées

dans un groupe de ressources. L’attribut MemberOf est utilisé pour déterminer

l’ensemble de ressources à démarrer ou à arrêter lorsque le groupe de ressources

est activé ou désactivé (de manière explicite via un ordre d’arrêt ou de manière

implicite via un incident non récupérable survenu dans une ressource membre).

Une ressource peut être membre d’un seul et unique groupe de ressources.



Définition et administration d’un groupe de ressources

Création d’un groupe de ressources

Pour créer un groupe de ressources, utilisez la commande mkrg dans laquelle vous

définissez pour System Automation for Multiplatforms :

v L’emplacement dans lequel le groupe de ressources est autorisé à fonctionner.

v L’importance relative du groupe de ressources par rapport aux autres groupes

de ressources (à l’aide de l’attribut Priorité, comme indiqué à la section «Attribut

Priorité», à la page 42).

v La relation Location entre les ressources membres du groupe de ressources

(détaillé dans la section «Relations Location», à la page 79).

L’état nominal des groupes de ressources récemment créés sera défini par défaut

sur Hors ligne. Ainsi, l’utilisateur ou l’administrateur peut entièrement configurer

le groupe de ressources et ces ressources.

Par exemple, pour définir un nouveau groupe de ressources apacherg2 avec la

relation d’emplacement “Aucun” et le nom de noeud autorisé “node03”, entrez :

mkrg -l None -n node03 apacherg2

Pour plus d’informations, consultez la page d’aide de la commande mkrg ou la



Pour établir une liste de noeuds pour un groupe de ressources, utilisez :

v la commande mkrg, pour créer un nouveau groupe de ressources.

v la commande chrg, pour un groupe de ressources existant.

Pour spécifier une liste de noeuds à utiliser avec les commandes susmentionnées,

vous pouvez :

v Saisir le nom d’un noeud en utilisant la commande mkrg/chrg.

v Etablir en tant qu’équivalence, l’ensemble de noeuds dans lequel le groupe de

ressources peut être activé. Vous devez effectuer cette opération avant d’établir

la liste de noeuds. Vous pouvez ensuite utiliser la commande mkrg/chrg :

l’équivalence demandée sera jointe au groupe de ressources. (Pour obtenir des

informations supplémentaires sur les équivalences, consultez le Chapitre 5,

«Utilisation des équivalences», à la page 53).

Ajout d’une ressource membre dans un groupe de ressources

Pour ajouter une ou plusieurs ressources membres à un groupe de ressources,

utilisez la commande addrgmbr.

Remarques :

1. Une ressource membre ne peut être ajoutée dans plus d’un groupe de

ressources à la fois.

2. Une ressource membre ne peut se trouver dans un groupe de ressources et une

équivalence à la fois.

Par exemple, pour ajouter une ressource membre apache1, appartenant à la classe

de ressources IBM.Application, au groupe de ressources apacherg2, entrez :

addrgmbr -g apacherg2 IBM.Application:apache1



Pour plus d’informations, consultez la page d’aide de la commande addrgmbr ou

la description de la commande dans le Guide de référence d’IBM Tivoli System


Enumération des groupes de ressources et de leurs membres

Les commandes suivantes permettent de répertorier les groupes de ressources et

leurs membres :

lssam Répertorie les groupes de ressources et leurs membres sous forme

d’arborescence. Pour plus d’informations sur la commande, consultez la

page d’aide de la commande lssam ou la description de la commande dans

le Guide de référence d’IBM Tivoli System Automation for Multiplatforms. Sous

Windows, lssam peut être appelée à partir du dossier Démarrer > Tous les

programmes > Tivoli SA MP Base > Liste des groupes de ressources

définis - lssam.

lsrg Répertorie les groupes de ressources ou les membres d’un groupe de

ressources. Cette section vous offre un aperçu de la manière dont la

commande est utilisée et fournit quelques exemples d’utilisation.

Pour plus d’informations, consultez la page d’aide de la commande lsrg ou

la description de la commande dans le Guide de référence d’IBM Tivoli


Pour répertorier un groupe de ressources ou ses membres, vous pouvez utiliser la

commande lsrg. Si vous omettez le nom du groupe de ressources, tous les groupes

de ressources seront répertoriés. Si le nom du group de ressources est spécifié par

le biais de l’option-m, les noms des ressources membres et les classes de ressources

sont répertoriés.

Si le paramètre Attr est spécifié, les attributs spécifiés pour le groupe de ressources

sont répertoriés.

Trois groupes de ressources sont définis dans les exemples suivants :

Exemple 1 : si la commande lsrg est saisie, le type d’informations suivant

s’affichera :

Resource Group Names:

apacherg2

apacherg3

apacherg4

Exemple 2 : pour répertorier tous les membres des groupes de ressources, entrez :

lsrg -m

Cette information s’affiche :

Affichage des informations liées aux ressources membre :

Class:Resource:Node[ManagedResource] Mandatory MemberOf OpState WinSource Location

IBM.Application:apache1 True apacherg2 Offline Nominal node03

Exemple 3 : apacherg2 contient une ressource. Pour répertorier les membres

d’apacherg2, la commande suivante est saisie :

lsrg -m -g apacherg2




Ressource membre 1:

Classe:Ressource:Noeud[ManagedResource] = IBM.Application:apache1

Mandatory = True

MemberOf = apacherg2

OpState = Offline

Exemple 4 : pour répertorier les attributs du groupe de ressources apacherg2, la

commande suivante est saisie :

lsrg -g apacherg2


Resource Group 1:

Name = apacherg2

MemberLocation = None

Priority = 0

AllowedNode = node03

NominalState = Offline

OpState = Offline

Démarrage et arrêt d’un groupe de ressources

Pour démarrer ou arrêter un groupe de ressources, définissez respectivement

l’attribut NominalState du groupe de ressources sur En ligne ou Hors ligne. A cette

fin, utilisez la commande chrg.

Par exemple, pour démarrer un groupe de ressources nommé apacherg2, entrez :

chrg -o online apacherg2

Pour plus d’informations, consultez la page d’aide de la commande chrg ou la



Modification des attributs d’un groupe de ressources

Pour modifier les valeurs des attributs persistants d’un ou plusieurs groupes de

ressources, utilisez la commande chrg. Vous pouvez également modifier le nom du

groupe de ressources à l’aide de cette commande, en utilisant l’option -c.

Exemple 1 : pour modifier la relation d’emplacement du groupe apacherg2 sur

Collocated (colocalisé), entrez :

chrg -l collocated apacherg2

Exemple 2 : pour modifier le nom du groupe apacherg3 en apacherg4, entrez :

chrg -c apacherg4 apacherg3

Pour plus d’informations, consultez la page d’aide de la commande chrg ou la



Modification des attributs des membres d’un groupe de

ressources

Pour modifier les attributs des membres de groupes de ressources, utilisez la

commande chrgmbr.



Cette commande permet également de définir des modifications à apporter à

l’attribut Mandatory d’une ressource gérée, grâce à l’option -m. Vous pouvez

modifier le groupe de ressources auquel la ressource appartient en utilisant

l’option -c.

Par exemple, pour modifier le groupe de ressources apacherg2 auquel la ressource

membre apache2 de la classe de ressources IBM.Application appartient par le

groupe de ressources apacherg3, entrez :

chrgmbr -c apacherg3 -g apacherg2 IBM.Application:apache2

Pour plus d’informations, consultez la page d’aide de la commande chrgmbr ou la



Suppression d’une ressource membre d’un groupe de

ressources

Utilisez la commande rmrgmbr pour supprimer :

v toutes les ressources membres d’un groupe de ressources spécifié.

v uniquement les ressources membres spécifiées du groupe de ressources indiqué.

v les ressources membres correspondant à une chaîne de sélection.

System Automation for Multiplatforms assure également la mise à jour de

n’importe quelle relation gérée ou équivalence associée.

Par exemple, pour supprimer une ressource membre apache2 appartenant à la

classe de ressources IBM.Application du groupe de ressources apacherg3, entrez :

rmrgmbr -g apacherg3 IBM.Application:apache2

Pour plus d’informations, consultez la page d’aide de la commande rmrgmbr ou la



Suppression d’un groupe de ressources

Pour supprimer un ou plusieurs groupes de ressources, utilisez la commande

rmrg. Les groupes de ressources sont spécifiés à l’aide du paramètre Resource_group

ou par la correspondance avec une chaîne de sélection. Les ressources membres

associées aux groupes de ressources supprimés, sont également supprimées par

System Automation for Multiplatforms. Si le groupe de ressources à supprimer est

toujours en ligne, il ne sera pas supprimé. Notez que les relations dans lesquelles

les groupes de ressources supprimés sont la source seront également supprimées.

Cela implique que tous les groupes de ressources imbriqués dans le groupe de

ressources à supprimer sont également supprimés. Si vous souhaitez empêcher la

suppression récursive des groupes de ressources contenus, procédez comme suit :

1. Supprimez ces groupes de ressources comme membres du groupe de ressources

à supprimer, à l’aide de la commande rmrgmbr.

2. Supprimez le groupe de ressources de rétention.

Par exemple, pour supprimer les groupes de ressources apacherg2 et apacherg3,

entrez :

rmrg apacherg2 apacherg3



Pour plus d’informations, consultez la page d’aide de la commande rmrg ou la





Chapitre 5. Utilisation des équivalences

Ce chapitre décrit les équivalences dans les sections principales suivantes :

v «Qu’est-ce qu’une équivalence ?»

v «Attributs utilisés par les équivalences», à la page 55

v «Règles d’utilisation des équivalences», à la page 54

v «Création d’une équivalence», à la page 56

v «Modification d’une équivalence», à la page 57

v «Suppression d’une équivalence», à la page 57

v «Liste d’une ou plusieurs équivalences», à la page 57

Le tableau 4 répertorie les commandes System Automation for Multiplatforms que

vous utilisez pour les équivalences. Pour plus d’informations, consultez les

descriptions des commandes dans le Guide de référence d’IBM Tivoli System


Tableau 4. Commandes System Automation for Multiplatforms utilisées conjointement aux

équivalences


mkequ Créer une ressource d’équivalence

rmequ Supprimer une ressource d’équivalence

chequ Modifier une ressource d’équivalence

lsequ Répertorier les ressources d’équivalence

Qu’est-ce qu’une équivalence ?

Une équivalence est une collection de ressources offrant les mêmes fonctionnalités.

Une équivalence se compose d’un ensemble de ressources fixes provenant de la

même classe de ressources.

Par exemple, les adaptateurs de réseau peuvent être définis en tant

qu’équivalences. Si un adaptateur de réseau passe hors ligne, un autre adaptateur

de réseau peut prendre le relais et poursuivre le processus de l’adaptateur hors

ligne.

Les équivalences sont également utilisées pour établir la liste de noeuds d’un

groupe de ressources. A partir de cette équivalence, vous pouvez sélectionner une

ou plusieurs ressources afin de satisfaire une relation gérée. Mais seul un membre

peut être démarré sur un noeud pour satisfaire une relation gérée. Pour des

informations sur les relations gérées, voir le Chapitre 6, «Utilisation des relations

gérées», à la page 59.

Il existe deux types d’équivalence :

1. Equivalences avec une liste d’appartenance statique. Ce type d’équivalence

contient un ensemble fixe de ressources qu’un utilisateur a ajouté de manière

explicite à l’équivalence.

2. Equivalences avec une liste de chaînes de sélection. Ce type d’équivalence

détermine de manière dynamique les ressources qui seront contenues au sein

de l’équivalence. Si des ressources RMC correspondant à la chaîne de sélection

dynamique sont créées, elles sont automatiquement contenues dans


l’équivalence. Il est fortement déconseillé de définir une règle pour ce type

d’équivalence, car les ressources ne sont pas ordonnées.

Les types d’équivalence suivants peuvent être utilisés pour mettre en application

un comportement d’automatisation spécifique :

Failback (remise en ligne)

Ne peut être utilisé que pour les équivalences ordonnées. Les équivalences

de ce type ont le comportement suivant :

System Automation for Multiplatforms vérifie que toutes les ressources de

l’équivalence sont exécutées sur le noeud hébergeant le premier membre

de l’équivalence. Si ce membre passe Hors ligne, System Automation for

Multiplatforms démarre les ressources sur le noeud hébergeant le

deuxième membre de l’équivalence. Lorsque le premier membre revient En

ligne, System Automation for Multiplatforms arrête toutes les ressources

dépendantes et les redémarre sur le noeud hébergeant le premier membre

de l’équivalence.

Notez qu’une demande de transfert sur un groupe de ressources possédant

une relation avec une équivalence de type Failback ne se comporte pas

comme prévu : le transfert a lieu, mais immédiatement après, le groupe de

ressources est remis en ligne sur le noeud d’origine !

NoFailure

Les équivalences de ce type ont le comportement suivant :

Les ressources possédant une dépendance avec l’équivalence ne passeront

pas à l’état Echec hors ligne si elles n’atteignent pas l’état opérationnel En

ligne dans le délai imparti. Cela est utile pour les ressources dont le

démarrage est lent. Cela revient à définir un délai d’expiration infini pour

la commande de démarrage d’une ressource, à la différence près que ces

ressources peuvent être automatisées de nouveau une fois le délai de mise

en ligne atteint, alors que les ressources pour lesquelles le délai

d’expiration de la commande de démarrage est très élevé ne peuvent pas

être automatisées avant la fin de ce délai car elles sont en attente.

Ressources reflet/Equivalences reflet

Une ressource reflet contrôle l’état opérationnel d’une autre ressource.

System Automation for Multiplatforms ne fait qu’évaluer l’état

opérationnel des ressources reflet ; il ne les démarre pas et ne les arrêtes

pas. Les ressources reflet permettent de définir des relations entre une

ressource flottante et une ressource fixe parmi plusieurs ressources fixes

exécutées sur des noeuds différents. Pour une description détaillée, voir

«Utilisation de ressources ombrées», à la page 210.

Les équivalences sont fournies dans la classe de ressources IBM.Equivalency

d’System Automation for Multiplatforms.

Règles d’utilisation des équivalences

Les règles suivantes concernent l’utilisation des équivalences :

1. Une ressource peut être membre d’une équivalence ou d’un groupe de

ressources, mais pas des deux.

2. Une ressource peut être présente dans plusieurs équivalences.

3. Les ressources spécifiées doivent provenir de la même classe de ressources.

4. Les équivalences ne peuvent pas être membres d’une équivalence.

5. Les groupes de ressources ne peuvent pas être membres d’une équivalence.

Equivalences


6. Les équivalences ne peuvent pas être membres d’un groupe de ressources.

7. Une équivalence qui satisfait une relation pour une ressource active ne peut pas

être modifiée.

8. Une équivalence peut uniquement être la cible d’une relation gérée (elle ne peut

en être la source).

9. Les membres d’une équivalence doivent être des ressources fixes. Les

ressources flottantes ne sont pas autorisées.

Attributs utilisés par les équivalences

Attribut MemberClass (classe de membres)

System Automation for Multiplatforms utilise l’attribut persistant MemberClass

afin de déterminer la classe de ressources de toutes les ressources membres.

Attribut Membership (appartenance)

System Automation for Multiplatforms utilise l’attribut persistant Membership afin

de déterminer l’ensemble des ressources contenues au sein de l’équivalence. Si

vous spécifiez l’attribut Membership, les attributs SelectString ne sont pas

autorisés.

Attribut SelectString (chaîne sélection)

System Automation for Multiplatforms utilise l’attribut persistant SelectString afin

de déterminer de manière dynamique les ressources d’une équivalence. Si des

ressources correspondant à la chaîne de sélection sont insérées ou supprimées du

système, System Automation for Multiplatforms modifie automatiquement

l’équivalence. Si vous spécifiez un attribut SelectString, les attributs Membership

ne sont pas autorisés.

Attribut SelectFromPolicy (sélection à partir d’une règle)

System Automation for Multiplatforms utilise l’attribut persistant SelectFromPolicy

afin de déterminer la règle à utiliser lors de la sélection à partir d’une équivalence.

Vous pouvez modifier cet attribut lorsque les ressources faisant référence à

l’équivalence sont hors ligne. Règles possibles :

Any (par défaut)

Dan ce cas de figure, si une ressource de l’équivalence échoue,

System Automation for Multiplatforms choisit une ressource sans

se référer à un ordre de sélection pré-sélectionné.

Ordered Dans ce cas de figure, si une ressource de l’équivalence échoue,

System Automation for Multiplatforms démarre toujours à partir

du début de la liste de sélection.

Remarque : N’utilisez pas une règle Ordered avec un attribut

SelectString dynamique.

Il existe des paramètres supplémentaires pour l’attribut persistant SelectFromPolicy,

qui peuvent être combinés avec le paramètre Any ou Ordered pour parvenir à un

comportement d’automatisation particulier :

Failback (remise en ligne)

L’option Failback ne peut être spécifiée que sur des règles ordonnées. Si

cette option est spécifiée, System Automation for Multiplatforms remet les

Equivalences


ressources en ligne sur le noeud hébergeant le premier membre de

l’équivalence dès que ce dernier redevient disponible.

Notez que cette fonction a un impact sur les demandes de transfert sur les

groupes de ressources (voir aussi «Déplacement des groupes de ressources

à l’aide de la commande rgreq», à la page 208) : si une équivalence avec

des règles Failback est impliquée dans une demande de transfert, le

transfert du groupe de ressources est effectué, mais immédiatement après

la mise En ligne des ressources sur le noeud cible, l’option Failback de

l’équivalence retransfert le groupe de ressources vers le noeud d’origine.

NoFailure

Si l’option NoFailure est spécifiée, les ressources possédant une relation

DependsOn avec l’équivalence ne passeront pas à l’état Echec hors ligne si

une demande En ligne sur ces ressources n’aboutit pas dans le délai

d’attente de mise en ligne imparti. Cela implique la remise en ligne de ces

ressources sur un autre noeud que si la commande de contrôle de ces

ressources renvoie Echec hors ligne.

NoControl

L’option NoControl identifie les membres de l’équivalence comme

ressources reflet. Dans ce cas, System Automation for Multiplatforms ne

démarre pas et n’arrête pas les membres de l’équivalence, mais il ne réagit

qu’aux modifications de l’état opérationnel des ressources membres de

l’équivalence. Par défaut, System Automation for Multiplatforms démarre

et arrête les ressources contrôlables d’une équivalence, telles que la classe

IBM.Application.

Attributs utilisés par les membres des équivalences

v Une ressource devant être ajoutée à une équivalence doit posséder cet attribut :

– OpStatev Une ressource devant être ajoutée à une équivalence peut posséder ces attributs :

– NodeNameList

– ResourceType

Pour obtenir des informations supplémentaires, reportez-vous à la section

«Attributs utilisés par les ressources», à la page 31.

Définition et administration des équivalences

Création d’une équivalence

Pour créer une équivalence parmi les ressources, utilisez la commande mkequ.

Pour plus d’informations, consultez la page d’aide de la commande mkequ ou la

description de la commande mkequ dans le Guide de référence d’IBM Tivoli System


Par exemple, pour créer une équivalence statique appelée NetworkInterfaces de

deux interfaces ethernet eth0 situées sur le noeud node01 ou node02 des systèmes

Linux de la classe de ressources IBM.NetworkInterface, entrez :

mkequ NetworkInterfaces IBM.NetworkInterface:eth0:node01,eth0:node02

Pour créer l’équivalence dynamique NetworkInterfacesDynamic contenant toutes

les interfaces ethernet disponibles dans une grappe de systèmes Linux, entrez :

mkequ -D "Name like ’eth%’" NetworkInterfacesDynamic IBM.NetworkInterface

Equivalences


Dans une grappe de systèmes AIX, entrez :

mkequ -D "Name like ’en%’" NetworkInterfacesDynamic IBM.NetworkInterface

Dans une grappe de systèmes Solaris, entrez :

mkequ -D "Name like ’bge%’" NetworkInterfacesDynamic IBM.NetworkInterface

Liste d’une ou plusieurs équivalences

Pour répertorier une ou plusieurs équivalences, utilisez la commande lsequ.

Pour plus d’informations, consultez la page d’aide de la commande lsequ ou la

description de la commande lsequ dans le Guide de référence d’IBM Tivoli System


Si vous oubliez le nom d’une équivalence, toutes les équivalences définies seront

répertoriées. Si vous spécifiez une équivalence, les attributs persistants de cette

équivalence seront répertoriés. Si vous spécifiez le nom d’attribut en tant

qu’opérande, les attributs spécifiés seront répertoriés.

Par exemple, pour répertorier les attributs persistants de l’équivalence

NetworkInterfaces, entrez :

lsequ -A p -e NetworkInterfaces

Modification d’une équivalence

Pour ajouter, supprimer ou remplacer intégralement les ressources d’une

équivalence, utilisez la commande chequ.

Pour plus d’informations, consultez la page d’aide de la commande chequ ou la



Utilisez également cette commande pour modifier le nom de l’équivalence.

Par exemple, pour ajouter la ressource eth1 située dans le noeud node01 du

système Linux appartenant à la classe de ressources IBM.NetworkInterface, dans

l’équivalence NetworkInterfaces, entrez :

chequ -u a NetworkInterfaces IBM.NetworkInterface:eth1:node01

Suppression d’une équivalence

Pour supprimer une ou plusieurs équivalences, utilisez la commande rmequ.

Pour plus d’informations, consultez la page d’aide de la commande rmequ ou la

description fournie dans le Guide de référence d’IBM Tivoli System Automation for

Multiplatforms.

Spécifiez une ou plusieurs équivalences en utilisant le nom de l’équivalence en tant

qu’opérande ou la chaîne de sélection.

Par exemple, pour supprimer une équivalence appelée NetworkInterfaces, entrez :

rmequ NetworkInterfaces

Equivalences


Equivalences


Chapitre 6. Utilisation des relations gérées

Ce chapitre décrit comment utiliser les relations gérées dans les sections

suivantes :

v «Qu’est-ce qu’une relation gérée ?»

v «Attributs utilisés dans les relations gérées», à la page 60

v «Relations du comportement de démarrage/d’arrêt», à la page 62

v «Relations Location», à la page 79

v «Création et administration des relations», à la page 90

Remarque : Notez que les décisions de System Automation sont basées sur

plusieurs facteurs, tels que les combinaisons de relations entre les

groupes et les ressources, les paramètres des attributs et l’état nominal

des groupes. Chacun de ces facteurs peut avoir un impact sur le

comportement de l’automatisation. Les exemples décrits ci-après

n’illustrent que le comportement d’automatisation type rencontré

lorsque les relations sont utilisées ; le véritable comportement peut

différer des descriptions du présent document.

Le tableau 5 répertorie les commandes System Automation for Multiplatforms

utilisées pour les relations gérées. Pour plus d’informations, consultez la



Tableau 5. Commandes System Automation for Multiplatforms utilisées avec les relations

gérées


mkrel Créer une relation gérée

lsrel Répertorier les relations gérées

rmrel Supprimer une relation gérée

chrel Modifier une relation gérée

Qu’est-ce qu’une relation gérée ?

Une relation gérée existe entre une ressource source et une ou plusieurs ressources

cible. Par exemple, lors de l’initialisation d’un groupe de ressources, la ressource

source doit être démarrée après la mise en ligne de la ressource cible. Cet exemple

utilise une valeur StartAfter de l’attribut Relationship.

Comme illustré dans l’exemple, les relations indiquent toujours une direction. Les

relations peuvent traverser les frontières des noeuds.

Dans notre second exemple, une ressource source doit être démarrée, si possible,

sur le même noeud que la ressource cible. Cet exemple de relation gérée utilise une

valeur Affinity de l’attribut Relationship (décrit dans la section «Attribut

Relationship», à la page 61).


Les attributs de relation peuvent être utilisés avec des attributs Condition (décrit

dans la section «Attribut Condition», à la page 61). Dans notre troisième exemple,

une ressource source doit être démarrée, si possible sur le même noeud que la

ressource cible, mais uniquement si la ressource cible est en ligne. Cet exemple de

relation gérée utilise une valeur Affinity de l’attribut Relationship, conjointement à

une valeur IfOnline de l’attribut Condition.

L’attribut Relationship est décrit dans la section «Attribut Relationship», à la page

61, l’attribut Condition est décrit dans la section «Attribut Condition», à la page 61.

En utilisant une combinaison de relations gérées, vous pouvez définir des scénarios

d’automatisation complexes.

Comme mentionné ci-avant, une relation est définie entre une ressource source et

une ou plusieurs ressources cible. Si vous supprimez la ressource source d’une

relation (il peut s’agir d’un membre de groupe de ressources ou de la ressource

RMS sous-jacente), la relation sera supprimée. Si vous supprimez la dernière

ressource cible de la liste des ressources cible (il peut s’agir d’un membre de

groupe de ressources ou de la ressource RMS sous-jacente), la relation ne sera pas

supprimée. Vous devez supprimer cette relation à l’aide de la commande rmrel.

La raison de ce comportement est qu’aucune relation ne devrait être effacée de

manière accidentelle. C’est pourquoi, une relation Dépendant de (DependsOn) a

été définie d’une ressource source vers une ressource cible. La ressource source ne

peut fonctionner correctement sans la ressource cible. Aussi, la relation ne doit pas

être supprimée automatiquement, sauf si vous demandez à System Automation for

Multiplatforms de le faire.

Les relations gérées sont fournies dans la classe de ressources System Automation

for Multiplatforms IBM.ManagedRelationship.

Attributs utilisés dans les relations gérées

Sections connexes :

v «Attributs utilisés par les ressources», à la page 31

v «Attributs utilisés par les groupes de ressources», à la page 38

v «Attributs utilisés par les équivalences», à la page 55

L’image suivante illustre un autre exemple de relation gérée :

Une relation gérée possède les attributs décrits dans les sections suivantes.

Attribut Name

Utilisez l’attribut persistant Name pour spécifier le nom que vous souhaitez utiliser

pour la relation gérée. Cet attribut est facultatif. Il facilite la modification ou la

suppression des relations.

Attribut Source

Utilisez l’attribut persistant Source pour spécifier la ressource source de la relation

gérée.

Relations gérées


Attribut Target

Utilisez l’attribut persistant Target pour spécifier la liste des ressources cible de la

relation gérée.

Attribut Relationship

Utilisez l’attribut persistant Relationship pour spécifier la relation à appliquer entre

les ressources source et cible. Il existe deux types de relations : des dépendances de

démarrage/d’arrêt et des dépendances d’emplacement :Dépendances de démarrage et d’arrêt (Start / Stop) :

v StartAfter

v StopAfter

v DependsOn

v DependsOnAny

v ForcedDownBy

Les dépendances Start/Stop sont utilisées pour définir un comportement de

démarrage/d’arrêt.Dépendances d’emplacement (Location)

v Collocated

v AntiCollocated

v Affinity

v AntiAffinity

v IsStartable

Les dépendances d’emplacement sont utilisées pour localiser les ressources dans

les noeuds.

Attribut Condition

L’attribut persistant Condition indique une condition à utiliser avec des relations

Location (décrit dans la section «Relations Location», à la page 79), à l’exception de

la relation gérée IsStartable. La condition IfPossible ne peut être utilisée qu’avec la

relation StartAfter.

L’attribut persistant Condition définit les conditions d’applicabilité de la relation.

Les conditions sont les suivantes :

v IfOnline

v IfNotOnline

v IfOffline

v IfNotOffline

v IfPossible

v None

Relations gérées

Chapitre 6. Utilisation des relations gérées 61

Relations du comportement de démarrage/d’arrêt

System Automation for Multiplatforms propose les relations suivantes qui peuvent

être utilisées pour définir le comportement de démarrage/d’arrêt :

v StartAfter

v StopAfter

v DependsOn

v DependsOnAny

v ForcedDownBy

La source d’une relation de démarrage/d’arrêt peut être un membre d’un groupe

de ressources ou un groupe de ressources. Voir la section «Qu’est-ce qu’un groupe

de ressources ?», à la page 36 pour obtenir des informations supplémentaires sur

les groupes de ressources.

La cible d’une relation de démarrage/d’arrêt peut être :

v un membre d’un groupe de ressources ou un groupe de ressources.

v une équivalence.

v une ressource RSCT (qui n’est pas une ressource gérée) devant fournir un

attribut d’état opérationnel (OpState).

Notez que dans le cas d’une relation Dépendant de (DependsOn) où les ressources

source et/ou cible sont des groupes, ces groupes doivent posséder un emplacement

de membre colocalisé (collocated).

Une commande de démarrage ne peut pas être exécutée directement sur une

ressource. Par conséquent, démarrez une ressource en définissant l’état nominal du

groupe de ressources dont la ressource est membre sur En ligne.

Relation StartAfter

Utilisez la relation StartAfter pour garantir que la ressource source démarre

uniquement lorsque la ou les ressources cible sont en ligne.

La relation StartAfter présente le modèle de comportement suivant :

v A l’aide du comportement de démarrage StartAfter, définissez un ordre de

démarrage pour les ressources A et B :

Lorsque la ressource source A doit démarrer, la ressource cible B est démarrée en

premier. Une fois que la ressource B est active, la ressource A est démarrée.

Notez que les ressources A et B peuvent être démarrées sur différents noeuds.

Une variante de ce comportement est obtenue en utilisant la condition IfPossible

avec la relation StartAfter entre deux groupes de ressources car le groupe de

ressources cible B est ignoré s’il ne peut pas être associé, ce qui se traduit par un

état de liaison sacrifié (voir «Définition de la relation d’emplacement :

algorithme de liaison», à la page 93). Dans ce cas, la source de la relation est

démarrée sans tenir compte de la relation.

La relation StartAfter ne propose pas de comportement d’arrêt forcé (voir la section

«Relation Dépendant de», à la page 70).

Relations gérées


Informations détaillées sur le comportement de démarrage de la

relation StartAfter

Le comportement de démarrage est contrôlé par l’état opérationnel (OpState) de la

ressource cible. Lorsque l’état opérationnel de la ressource B est en ligne, la

ressource A est démarrée.

Généralement, les ressources A et B sont membres du même groupe de ressources.

La définition de l’état nominal de leur groupe de ressources sur En ligne provoque

le démarrage des deux membres A et B. En raison de la relation StartAfter définie

entre A et B, la ressource B est démarrée en premier lieu. Lorsque l’état

opérationnel de la ressource B est en ligne, la ressource A est démarrée.

Si la ressource A est membre du groupe de ressources RG_A et la ressource B est

membre du groupe de ressources RG_BC et qu’une relation StartAfter est définie

entre A et B, le comportement de démarrage de la relation StartAfter est déclenché

lorsque l’état nominal du groupe de ressources RG_A est défini sur En ligne.

En raison de la séquence de démarrage de la relation StartAfter, la ressource B doit

être démarrée la première. Si l’état nominal du groupe de ressources RG_BC est

défini sur hors ligne, le conflit suivant apparaît :

RG_BC veut que la ressource B soit hors ligne alors que la relation StartAfter force

son démarrage. System Automation for Multiplatforms résout le conflit de manière

à ce que la requête de mise en ligne prime toujours sur la requête de mise hors

ligne. Par conséquent, la ressource B est démarrée même si d’autres membres

éventuels du groupe RG_BC ne pourront être démarrés car leur état nominal est

défini sur Hors ligne. Lorsque la ressource est en ligne, System Automation for

Multiplatforms démarre la ressource A. La ressource C n’est pas démarrée.

Si la ressource A a été démarrée et que la ressource B est démarrée en raison

d’une relation StartAfter, mais que l’état nominal de son groupe reste Hors ligne, la

ressource B est récupérée, ce qui signifie qu’elle est redémarrée en cas d’incident.

Ce comportement sophistiqué a été introduit à l’occasion de la version 2.3 de

System Automation for Multiplatforms. Dans les versions précédentes, B n’aurait

pas été redémarré en cas d’incident.

Relations gérées


L’ordre de démarrage agit uniquement dans la direction avant de la relation. Si les

ressources A et B appartiennent à des groupes de ressources différents (A

appartient à RG_A et B à RG_B), la définition de l’état nominal du groupe RG_B

sur En ligne n’aura aucune incidence sur la ressource A, car la ressource B ne

possède pas de relation avant avec la ressource A.

Lorsque l’état nominal de RG_A est défini sur En ligne, la ressource A peut être

démarrée directement car la ressource B est déjà en ligne.

Un autre scénario peur englober la possibilité que la ressource A possède une

relation StartAfter avec les ressources B et C.

Dans ce cas, le démarrage de A implique que les ressources B et C soient en ligne

avant qu’System Automation for Multiplatforms puisse démarrer la ressource A.

Par exemple, A, B et C sont membres du groupe de ressources RG_ABC. La

définition de l’état nominal du RG_ABC sur En ligne provoque le démarrage

parallèle des ressources B et C en premier lieu. Lorsque l’état opérationnel des

deux ressources est défini sur En ligne, la ressource A peut être démarrée.

Il est également possible que les ressources A, B et C soient respectivement

membres des groupes de ressources RG_A, RG_B et RG_C.

Relations gérées


A possède une relation StartAfter avec B et C. La définition de l’état nominal du

groupe RG_A sur En ligne provoque le démarrage des ressources C et B en raison

de leur relation StartAfter. Lorsque les ressources B et C sont en ligne, la

ressource A peut être démarrée.

L’exemple illustré ci-après montre le comportement de démarrage lorsque deux

groupes de ressources («RG1» et «RG2») sont connectés par l’intermédiaire d’une

relation StartAfter/IfPossible et que le groupe de ressources cible («RG2») est

introuvable :

v La source de la relation («RG1») est démarrée.

v La relation avec le groupe de ressources cible («RG2») n’est pas appliquée et son

état de liaison devient Sacrifié. Notez que ce comportement est différent si les

deux groupes de ressources appartiennent à un autre groupe.

Utilisation de la condition IfPossible avec une relation StartAfter : Vous pouvez

spécifier la condition IfPossible avec des relations StartAfter. Cette condition

indique que le groupe de ressources cible peut être ignoré s’il ne peut pas être

associé. Dans ce cas, le groupe de ressources cible passe à l’état Sacrifié et la

relation StartAfter est ignorée. La relation StartAfter et la condition IfPossible

doivent uniquement être utilisées entre des groupes. Des résultats imprévisibles

peuvent se produire si des ressources gérées sont définies comme ressources de

support.

Relations gérées


Informations détaillées sur le comportement d’arrêt de la relation

StartAfter

La ressource cible B ne peut être arrêtée lorsque la ressource A est En ligne. Si

l’attribut d’état nominal (NominalState) d’une ressource source A est modifié sur

Hors ligne, la ressource cible B s’arrête automatiquement. Les deux ressources

peuvent être arrêtées simultanément.

Généralement, la ressource source A et la ressource cible B sont membres du même

groupe de ressources. Aussi, leurs valeurs NominalState sont identiques.

Définissez l’attribut NominalState de RG_AB sur Hors ligne afin d’arrêter les deux

membres A et B. Comme la relation StartAfter ne requiert pas de séquence d’arrêt,

les ressources A et B peuvent être arrêtées simultanément.

Compte tenu que RG_B possède l’état nominal (NominalState) En ligne, vous

pouvez démarrer et arrêter RG_A sans affecter le groupe de ressources RG_B. Il

reste en ligne.Si vous définissez l’état nominal (NominalState) de RG_B sur Hors ligne et celui de

RG_A sur En ligne, la ressource cible B démarrera avant la ressource source A.Si vous définissez l’état nominal (NominalState) de RG_A sur Hors ligne, les

ressources A et B sont arrêtées simultanément.

Considérez le comportement d’arrêt suivant :

Si l’état nominal (NominalState) de RG_A est En ligne et celui de RG_B est hors

ligne, les ressources A et B sont en ligne. Définissez à présent l’état nominal

(NominalState) de RG_A sur Hors ligne. Les ressources A et B sont arrêtées

simultanément. La raison de ce comportement est que la ressource B a démarré

suite à la requête de démarrage émise sur le groupe de ressources RG_A et

transmise via la relation StartAfter. La définition de RG_A sur Hors ligne provoque

la suppression de la requête de démarrage et la définition de l’état

nominal(NominalState) du groupe de ressources RG_B sur Hors ligne provoque

l’arrêt de la ressource B.La relation StartAfter déclenche le comportement d’arrêt typique : les ressources A

et B peuvent être arrêtées simultanément.

Les ressources A, B et C sont membres des groupes de ressources individuels

RG_A, RG_B et RG_C.

Relations gérées


La ressource C doit être ligne afin de prendre en charge les ressources A et B. Tant

que l’état nominal (NominalState) de RG_A et RG-B est En ligne, la ressource C

doit demeurée En ligne même si l’état nominal de RG_C est Hors ligne. Une fois

l’état nominal de RG_A et RG_B défini sur Hors ligne, la ressource C peut être

arrêtée. Tel sera le cas si l’état nominal de RG_C est également Hors ligne.

Règles relatives à l’utilisation de la relation StartAfter

1. La relation StartAfter ne doit pas entrer en conflit avec une relation Dépendant

de existante.

2. La relation StartAfter ne suppose pas qu’une relation Location existe entre les

ressources gérées. Si vous souhaitez définir une relation Location (voir section

«Relations Location», à la page 79), vous devez créer une relation

supplémentaire à cet effet.

3. Si System Automation for Multiplatforms est requis pour le démarrage de la

ressource source, il tentera toujours cependant de démarrer en premier lieu la

ressource cible.

4. Si la ressource cible échoue, cela ne signifie pas que la ressource source sera

arrêtée.

Relations gérées


Relation StopAfter

Utilisez la relation StopAfter pour garantir que la ressource source peut

uniquement être arrêtée lorsque la ressource cible a déjà été arrêtée.

La relation StopAfter présente le modèle de comportement suivant :

v La ressource A n’est pas arrêtée tant que la ressource cible B n’est pas hors ligne

(y compris Echec hors ligne).

La relation StopAfter ne propose pas de comportement de démarrage ou d’arrêt

forcé. (voir sections «Relation StartAfter», à la page 62 et «Relation Dépendant de»,

à la page 70).


StopAfter

La ressource source A ne peut être arrêtée lorsque la ressource cible B est En ligne.

Si l’attribut d’état opérationnel (OpState) de la ressource cible B est modifié sur

Hors ligne ou Echec Hors ligne, la ressource source A s’arrête automatiquement

Généralement, la ressource source A et la ressource cible B sont membres du même

groupe de ressources. Définissez l’attribut NominalState de RG_AB sur En ligne

afin de démarrer les deux membres A et B. Comme la relation StopAfter ne

requiert pas de séquence de démarrage, les ressources A et B peuvent être

démarrées simultanément. La définition de l’attribut NominalState de leur groupe

de ressources sur Hors ligne provoque l’arrêt des membres. En raison de la relation

entre A et B, la ressource B est arrêtée la première. Lorsque l’état opérationnel de

la ressource B est hors ligne, la ressource A est arrêtée.

Si les ressources A et B font partie de groupes de ressources différents (A

appartient à RG_A et B à RG_B) et que RG_B possède l’état nominal

(NominalState) Hors ligne, vous pouvez démarrer et arrêter RG_A sans

dépendance avec le groupe de ressources RG_B. Si vous définissez l’état nominal

de RG_B sur En ligne et celui de RG_A sur Hors ligne, la ressource source A ne

peut être arrêtée tant que la ressource cible B est en ligne.

Relations gérées


Si l’état nominal (NominalState) de RG_A est Hors ligne, vous pouvez arrêter ou

démarrer RG_B sans dépendance avec la ressource A.Il est également possible que la ressource A soit membre du groupe de ressources

RG_A, la ressource B du groupe RG_B et la ressource C du groupe RG_C. A

possède une relation StopAfter avec B et C.

Si l’état nominal de RG_A est défini sur En ligne et que vous souhaitez l’arrêter,

RG_A ne peut être arrêté tant que l’état nominal de RG_B et RG_C est défini sur

En ligne. Une fois l’état nominal de RG_B et RG_C défini sur Hors ligne ou Echec

hors ligne, la ressource A peut être arrêtée.

Relations gérées


Relation Dépendant de

System Automation for Multiplatforms utilise la relation Dépendant de pour

garantir que la ressource source démarre uniquement lorsque la ou les ressources

cible sont en ligne. Il est utilisé de façon similaire pour la relation StartAfter, sauf

si :

v Une relation Dépendant de inclut également une colocalisation implicite (détaillé

dans la section «Relation Collocated», à la page 81) entre les ressources source et

cible.

v Si une ressource cible échoue, la ressource source sera également arrêtée.

La relation Dépendant de présente les trois modèles de comportement suivants :

La ressource A dépend de la fonction de la ressource B, ce qui signifie que la

ressource A ne peut fonctionner sans la ressource B. Par conséquent, le

comportement d’arrêt forcé a été introduit (voit point 3 de la liste suivante).

1. A l’aide du modèle de comportement de démarrage Dépendant de, définissez

une séquence de démarrage pour les ressources A et B avec une colocalisation

implicite :

Lorsqu’une ressource A (source) doit être démarrée, la ressource cible B doit

être démarrée la première. Une fois que la ressource B est en ligne, la

ressource A (source) est démarrée.

2. A l’aide du comportement d’arrêt Dépendant de, définissez une séquence

d’arrêt pour les ressources A et B :

Lorsque la ressource B (cible) doit être arrêtée, la ressource source A est arrêtée

la première. Une fois que la ressource A est hors ligne, la ressource B (cible) est

arrêtée.

3. Comportement d’arrêt forcé en cas d’échec de la ressource cible : lorsque la

ressource B échoue, la ressource A est arrêtée également. Un redémarrage est

alors déclenché en fonction du comportement de démarrage décrit au point 1.

Informations détaillées sur le comportement de démarrage de la

relation Dépendant de

La séquence de démarrage de la relation Dépendant de est contrôlée via l’état

opérationnel (OpState) de la ressource cible. Lorsque l’état opérationnel de la

ressource B est en ligne, la ressource A est démarrée. En plus de la séquence de

démarrage, la relation Dépendant de offre une contrainte colocalisée qui provoque

le démarrage de la ressource A sur le même noeud que celui dans lequel la

ressource B a été démarrée. Par conséquent, la ressource B doit être déjà démarrée

dans un noeud dans lequel la ressource A peut être démarrée après coup. La

contrainte colocalisée faisant partie de la relation Dépendant de correspond au

comportement de la relation colocalisée. Pour des informations supplémentaires

sur ce comportement, consultez la section «Relation Collocated», à la page 81.


Relations gérées


La définition de l’état nominal de leur groupe de ressources sur En ligne provoque

le démarrage des deux membres A et B. En raison de la relation Dépendant de

définie entre A et B, la ressource B est démarrée en premier lieu. Lorsque l’état

opérationnel de la ressource B est en ligne, la ressource A est démarrée dans le

même noeud.

Si la ressource A est membre du groupe de ressources RG_A et la ressource B est

membre du groupe de ressources RG_BC et qu’une relation Dépendant de est

définie entre A et B, le comportement de démarrage de la relation Dépendant de

est déclenché lorsque l’état nominal du groupe de ressources RG_A est défini sur

En ligne.

En raison de la séquence de démarrage de la relation Dépendant de, la ressource B

doit être démarrée la première. Si l’état nominal du groupe RG_BC est défini sur

En ligne, le conflit suivant aura lieu : RGRG_BC veut que la ressource B soit hors

ligne alors que la relation Dépendant de force son démarrage. System Automation

for Multiplatforms résout le conflit de manière à ce que la requête de mise en ligne

prime toujours sur la requête de mise hors ligne. Par conséquent, la ressource B est

démarrée même si d’autres membres éventuels du groupe RG_BC ne pourront être

démarrés car leur état nominal est défini sur Hors ligne. Lorsque la ressource B est

en ligne, System Automation for Multiplatforms démarre la ressource A. Les

ressources A et B sont bien évidemment démarrées dans le même noeud. La

ressource C n’est pas démarrée.

L’ordre de démarrage agit uniquement dans la direction avant de la relation. Si les

ressources A et B appartiennent à des groupes de ressources différents (A

appartient à RG_A et B à RG_B),

la définition de l’état nominal du groupe RG_B sur En ligne n’aura aucune

incidence sur la ressource A, car la ressource B ne possède pas de relation avant

avec la ressource A. Lorsque l’état nominal du groupe RG_A est également défini

sur En ligne, la ressource A peut être démarrée directement dans le même noeud

car la ressource B est déjà en ligne.

Un autre scénario peur englober la possibilité que la ressource A possède une

relation Dépendant de avec les ressources B et C.

Relations gérées


Dans ce cas, le démarrage de A implique que les ressources B et C soient en ligne

avant qu’System Automation for Multiplatforms puisse démarrer la ressource A.

Par exemple, A, B et C sont membres du groupe de ressources RG_ABC. La

définition de l’état nominal du RG_ABC sur En ligne provoque le démarrage

parallèle des ressources B et C en premier lieu. Lorsque l’état opérationnel des

deux ressources est En ligne, la ressource A est démarrée. Les trois ressources sont

démarrées dans le même noeud car la ressource A doit être démarrée dans le

noeud dans lequel les ressources B et C fonctionnent.

Il est également possible que les ressources A, B et C soient respectivement

membres des groupes de ressources RG_A, RG_B et RG_C.

A possède une relation Dépendant de avec B et C. La définition de l’état nominal

du groupe RG_A sur En ligne provoque le démarrage des ressources B et C.

Lorsque les ressources B et C sont en ligne, la ressource A peut être démarrée dans

le même noeud.


Dépendant de

Vous ne pouvez pas contrôler la séquence d’arrêt de la relation Dépendant de à

l’aide de l’état opérationnel (OpState) de la ressource source.

Lorsque l’état opérationnel de la ressource A est hors ligne, la ressource B peut

alors être arrêtée.


Relations gérées


Définissez l’attribut d’état nominal du groupe de ressources sur Hors ligne pour

arrêter les deux membres A et B. En raison de la relation Dépendant de, la

ressource A est arrêtée la première. Une fois la ressource A hors ligne, la

ressource B est arrêtée.

La ressource A est membre du groupe de ressources RG_A et la ressource B est

membre du groupe de ressources RG_B et une relation Dépendant de est définie

entre A et B. Vous pouvez déclencher le comportement de démarrage de la relation

Dépendant de en définissant l’état nominal du groupe de ressources RG_B sur En

ligne (l’arrêt direct des ressources est impossible dans System Automation for

Multiplatforms). En raison de la relation Dépendant de, la ressource A doit être

arrêtée la première. Un conflit aura lieu si l’état nominal du groupe de ressources

A est défini sur En ligne : RG_A veut la mise en ligne de la ressource A alors que

la relation Dépendant de provoque son arrêt.

System Automation for Multiplatforms résout le conflit de manière à ce que la

requête de mise en ligne prime toujours sur la requête de mise hors ligne. Par

conséquent, la ressource A demeure en ligne et la ressource B ne peut être arrêtée.

La ressource A ne peut être arrêtée que si l’état nominal de RG_A est défini sur

Hors ligne. Une fois la ressource A hors ligne, la ressource B est arrêtée.

Vous devez également tenir compte d’un comportement d’arrêt implicite :

Lorsque l’état nominal de RG_A est défini sur En ligne et que l’état nominal du

groupe de ressources RG_B est défini sur Hors ligne, les ressources A et B sont En

ligne, comme expliqué dans le scénario de démarrage susmentionné. Supposons

maintenant que l’état nominal de RG_A soit défini sur Hors ligne. Cette

modification provoque l’arrêt de la ressource A. En outre, la ressource B sera

également arrêtée. La raison est que la ressource a été démarrée suite à une requête

de démarrage émise sur le groupe de ressources RG_A et a été propagée à l’aide

de la relation Dépendant de de la ressource B. Puisque l’état nominal du groupe

de ressources RG_A est défini sur Hors ligne, la requête de démarrage est

supprimée et l’état nominal Hors ligne du groupe de ressources RG_B provoque

l’arrêt de la ressource B. La relation Dépendant de déclenche le comportement

d’arrêt typique : la ressource B ne peut être arrêtée avant la ressource A. Par

conséquent, la ressource A est arrêtée la première. Une fois la ressource A hors

ligne, la ressource B est arrêtée.

Relations gérées


Des ressources A et B possédant une relation Dépendant de avec une ressource C

constituent un autre scénario. L’arrêt de la ressource C requiert la mise hors ligne

préalable des ressources A et B.

Prenons, par exemple, des ressources A, B et C membres du même groupe de

ressources RG_ABC.

La définition de l’état nominal du groupe RG_ABC sur Hors ligne déclenche l’arrêt

préalable des ressources A et B. Lorsque l’état opérationnel des deux ressources est

défini sur Hors ligne, la ressource C peut être arrêtée. Dans un scénario alternatif,

les ressources A, B et C sont respectivement membres des groupes de ressources

individuels RG_A, RG_B et RG_C.

La définition de l’état nominal de RG_C sur Hors ligne déclenche le comportement

d’arrêt de la relation Dépendant de. Dans ce cas, l’état nominal des groupes de

ressources RG_A et RG_C peut rejeter le comportement d’arrêt. La ressource C ne

pourra être arrêtée aussi longtemps que l’état nominal des groupes RG_A et RG_B

est défini sur En ligne. La raison est qu’en cas de conflits, une requête de mise en

ligne prime toujours sur une requête de mise hors ligne. Par conséquent, le

comportement d’arrêt de la relation Dépendant de est ajourné jusqu’à ce que l’état

nominal de RG_A et RG_B soit défini sur Hors ligne. Lorsque leurs membres A et

B sont hors ligne, la ressource C est également arrêtée.

Informations détaillées sur le comportement d’arrêt forcé de la

relation Dépendant de

Le principe de base de la relation Dépendant de est que la ressource source A

dépend de la fonctionnalité de la ressource cible B. Si la ressource cible B échoue,

la ressource source A ne fonctionne plus. Par conséquent, le redémarrage de la

ressource B ne suffit pas. Suite à l’échec de la ressource B, la ressource A subira

également un arrêt forcé. Les deux ressources devront être redémarrées en fonction

du comportement de démarrage : la ressource B en premier suivie de la

ressource A.

Relations gérées


Par exemple, définissez une ressource A possédant une relation Dépendant de

avec la ressource B.

Les deux ressources sont en ligne. Si la ressource B échoue, la ressource A s’arrête

et le comportement de démarrage standard est déclenché. La ressource B sera

redémarrée en première suivie de la ressource A.

Les ressources A et B sont membres du même groupe de ressources RG_AB.

En outre, la relation ″la ressource A est dépendante (Dépendant de) de la

ressource B″ est définie. Lorsque le groupe RG_AB est défini sur En ligne, la

ressource B est démarrée la première suivie de la ressource A. Si la ressource B

échoue ou passe à l’état hors ligne, la ressource A est également arrêtée. Un

redémarrage standard sera effectué après coup à l’aide de la séquence Dépendant

de :

La ressource B est démarrée avant la ressource A.

Il peut également s’agir d’un scénario dans lequel la ressource A est membre du

groupe de ressources RG_A, la ressource B est membre du groupe RG_B, où la

ressource A possède une relation Dépendant de avec la ressource B.

Lorsque le groupe de ressources RG_A est défini sur En ligne alors que l’état

nominal du groupe RG_B est Hors ligne, la ressource B est démarrée la première

suivie de la ressource A. Le comportement d’arrêt forcé de la relation Dépendant

de est déclenché par une défaillance de la ressource B. Par conséquent, la

ressource A sera également arrêtée. L’arrêt aura lieu même si l’état nominal du

groupe RG_A est défini sur En ligne. Dans System Automation for Multiplatforms,

ces conflits sont toujours résolus de la manière suivante : le comportement d’arrêt

forcé prime toujours sur la requête de mise en ligne d’un groupe de ressources.

Le comportement d’arrêt forcé est propagé par l’intermédiaire de chaînes de la

relation Dépendant de. Prenons le scénario suivant : les ressources A, B et C sont

respectivement membres des groupes de ressources RG_A, RG_B et RG_C. La

ressource C est membre du groupe de ressources RG_C et les relations suivantes

sont définies : A dépend de (Dépendant de) B et B dépend de (Dépendant de) C.

Relations gérées


Supposons que le groupe de ressources RG_A est défini sur En ligne ce qui

déclenche le démarrage séquentiel des trois ressources C, B et A qui possèdent

l’état En ligne. Supposons maintenant que la ressource C échoue. Cet incident

provoque l’arrêt forcé de la ressource A en premier lieu puis de la ressource B. La

raison est que le comportement d’arrêt forcé a davantage d’importance qu’une

requête standard de mise en ligne.

Règle d’utilisation de la relation Dépendant de

Il existe une règle d’utilisation de la relation Dépendant de :

1. Si les ressources source et cible forment un groupe, tous les membres du

groupe doivent être colocalisés.

Relation DependsOnAny

Le comportement de la relation DependsOnAny est identique à celui de la relation

Dépendant de à l’exception qu’elle ne fournit pas de contrainte colocalisée pour la

séquence de démarrage. Par conséquent, les ressources source et cible peuvent se

situer dans le même noeud ou dans des noeuds différents.

La relation DependsOnAny présente les trois modèles de comportement suivants :

1. A l’aide du comportement de démarrage, la relation DependsOnAny définit un

ordre de démarrage pour les ressources A et B sans relation d’emplacement :

Lorsqu’une ressource A (source) doit être démarrée, la ressource cible B doit

être démarrée la première. Une fois que la ressource B est en ligne, la

ressource A (source) est démarrée. Notez que la seule différence par rapport à

la relation Dépendant de est que les ressources A et B peuvent être démarrées

dans des noeuds différents.

2. A l’aide du comportement d’arrêt, la relation DependsOnAny définit une

séquence d’arrêt pour les ressources A et B :

Lorsque la ressource B (cible) doit être arrêtée, la ressource source A est arrêtée

la première. Une fois que la ressource A est hors ligne, la ressource B (cible) est

arrêtée.

3. Comportement d’arrêt forcé en cas d’échec de la ressource cible : lorsque la

ressource B échoue, la ressource A est arrêtée également. Un redémarrage est

alors déclenché en fonction du comportement de démarrage décrit au point 1.

Consultez la section relative à la relation Dépendant de pour obtenir des

informations supplémentaires sur la relation DependsOnAny.

Remarque : Le scénario A ---> DependsOn ---->B correspond au scénario A --->

DependsOnAny ---> B et A----> Collocated---->B

Relations gérées


Relation ForcedDownBy

Utilisez la relation ForcedDownBy pour garantir que la ressource source ne pourra

être arrêtée que si la ressource cible est hors ligne.

La relation ForcedDownBy présente le modèle de comportement suivant :

v La ressource A doit être arrêtée de manière forcée lorsque la ressource cible est

désactivée de manière inattendue ou qu’elle est elle-même désactivée de manière

forcée. L’arrêt des ressources A et B peut se produire simultanément. L’arrêt

forcé de la ressource A se déclenche lorsque la ressource B entre dans l’un des

états normaux d’arrêt (Hors ligne) après avoir préalablement possédé l’état En

ligne ou l’un des états d’arrêt terminaux (Echec hors ligne), indépendamment de

son état précédent.

La relation ForcedDownBy ne propose pas de comportement de démarrage ou

d’arrêt (voir sections «Relation StartAfter», à la page 62, «Relation StopAfter», à la

page 68 et «Relation Dépendant de», à la page 70).

Informations détaillées sur le comportement d’arrêt forcé de la

relation ForcedDownBy

La principe de base de la relation ForcedDownBy est que la source A doit être

arrêtée de manière forcée lorsque la ressource cible B est hors ligne ou échoue.

Par exemple, définissez une ressource A possédant une relation ForcedDownBy

avec la ressource B.

Les deux ressources sont En ligne. Si la ressource B est arrêtée ou échoue, la

ressource A sera arrêtée de manière forcée.

Il peut également s’agir d’un scénario dans lequel la ressource A est membre du

groupe de ressources RG_A et la ressource B du groupe RG_B, où la ressource A

possède une relation ForcedDownBy avec la ressource B.

Lorsque l’attribut NominalState des groupes de ressources RG_A et RG_B est

défini sur En ligne, les ressources A et B sont démarrées sans aucune dépendance

l’une envers l’autre. Le comportement d’arrêt forcé de la relation ForcedDownBy

est déclenché par :

1. Une défaillance de la ressource B. Elle provoque l’arrêt de la ressource A.

L’arrêt aura lieu même si l’état nominal du groupe RG_A est défini sur En

ligne. Mais comme dans ce cas l’état nominal du groupe RG_A est toujours

défini sur En ligne, la ressource A sera redémarrée par System Automation for

Multiplatforms.

Relations gérées


2. Un arrêt de la ressource B.

La définition de l’état nominal du groupe RG_B sur Hors ligne provoque l’arrêt

de la ressource A. L’arrêt aura lieu même si l’état nominal du groupe RG_A est

défini sur En ligne. Mais comme dans ce cas l’état nominal du groupe RG_A

est toujours défini sur En ligne, la ressource A sera redémarrée par System


Relations gérées


Relations Location

System Automation for Multiplatforms propose les relations suivantes qui peuvent

être utilisées pou définir les relations d’emplacement (Location) :

v Collocated

v AntiCollocated

v Affinity

v AntiAffinity

v IsStartable

Par exemple, les ressources A et B sont des ressources flottantes pouvant être

démarrées sur les noeuds node1, node2 et node3 :

L’idée sous-jacente de ces relations est de définir des contraintes d’emplacement

entre les ressources. Les types de ressources tels que les ressources flottantes, ainsi

que les groupes proposent une liste de noeuds pouvant être démarrés. Les

ressources A et B sont des ressources flottantes pouvant être démarrées sur les

noeuds node1, node2 et node3.

Une condition requise pourrait être que la ressource A doit toujours être démarrée

sur le noeud dans lequel la ressource B fonctionne ou est supposée fonctionner. Ce

comportement peut être spécifié en définissant une relation Collocated entre A et B.

Le comportement contraire requérant que la ressource A ne soit pas démarrée sur

le noeud dans lequel la ressource B fonctionne peut être spécifié à l’aide de la

relation AntiCollocated.

Si la condition requise est que la ressource A doit être, dans la mesure du possible,

démarrée sur le noeud dans lequel la ressource B fonctionne, ou ailleurs le cas

échéant, la relation Affinity sera utilisée. La différence par rapport à la relation

Collocated est que la relation définit des relations d’emplacement ’souples’.

La relation AntiAffinity est utilisée pour indiquer que la ressource A ne doit pas

être démarrée, dans la mesure du possible, au même emplacement que celui où la

ressource B fonctionne. Si seule cette condition ne peut être satisfaite, le processus

A peut être démarré dans le noeud où la ressource B se trouve. Tout comme la

relation Affinity, la relation AntiAffinity définit des contraintes d’emplacement

’souples’ par rapport à la relation AntiCollocated.

La relation IsStartable définit que la ressource source A peut uniquement être

démarrée dans un noeud dans lequel la ressource cible B peut être démarrée. Cette

relation est uniquement prise en considération si les ressources source et cible

possèdent l’état nominal En ligne. Si l’une des ressources (source ou cible) ne

possède pas l’état nominal En ligne, la relation IsStartable sera supprimée avec les

ressources possédant l’état nominal Hors ligne.

Relations gérées


Conditions IfOnline, IfOffline, IfNotOnline, et IfNotOffline

Vous pouvez combiner les relations suivantes avec toutes les relations

d’emplacement à l’exception de la relation IsStartable. Ces conditions sont les

suivantes :

IfOnline La condition IfOnline définit que relation d’emplacement peut

uniquement être évaluée si l’état opérationnel (OpState) de la

ressource cible est défini sur En ligne. Autrement, l’emplacement

est ignoré. La condition IfOnline n’englobe pas les états tels que En

attente en ligne et En attente hors ligne.

IfOffline La condition IfOffline signifie que la relation d’emplacement peut

uniquement être évaluée si l’état opérationnel (OpState) de la

ressource cible est défini sur Hors ligne, Echec hors ligne ou

Inconnu. Autrement, la relation d’emplacement est ignorée.

IfNotOnline La condition IfNotOnline signifie que la relation d’emplacement

peut uniquement être évaluée si la ressource cible ne possède pas

l’état En ligne. La relation IfNotOnline englobe les états tels que En

attente en ligne et Arrêt en ligne. Autrement, la relation

d’emplacement est ignorée.

IfNotOffline La condition IfNotOffline signifie que la relation d’emplacement

peut uniquement être évaluée si la ressource cible ne possède pas

l’état Hors ligne ou Echec hors ligne. Autrement, la relation

d’emplacement est ignorée.

Règles d’utilisation des relations d’emplacement

1. La source d’une relation d’emplacement peut être un membre d’un groupe de

ressources ou un groupe de ressources. Voir la section «Qu’est-ce qu’un groupe

de ressources ?», à la page 36 pour obtenir des informations supplémentaires

sur les groupes de ressources.

2. La cible d’une relation d’emplacement peut être :

v un membre d’un groupe de ressources ou un groupe de ressources.

v une ressource RMC (qui n’est pas une ressource gérée) devant fournir une

méthode de démarrage/d’arrêt et un attribut d’état opérationnel (OpState).3. Si les ressources source et cible forment un groupe, tous les membres du

groupe doivent être colocalisés.

Relations gérées


Relation Collocated

System Automation for Multiplatforms utilise la relation Collocated afin de

garantir que les ressources source et cible se trouvent dans le même noeud. La

relation Collocated présente le modèle de comportement suivant :

v La relation Collocated définit que la ressource A peut uniquement être démarrée

sur le noeud dans lequel la ressource B est en cours d’exécution.

La relation Collocated peut être utilisée conjointement à l’attribut Condition,

comme indiqué à la page 83.

Informations détaillées sur le comportement de principe de la

relation Collocated

La section suivante décrit en détail quatre états que la relation Collocated peut

prendre :

Cas I :

Au démarrage de la ressource A, placez-la dans le même noeud que celui où la

ressource B est en cours d’exécution. ’En cours d’exécution’ signifie que l’état

opérationnel de la ressource B est En ligne, En attente en ligne, Echec en ligne ou

En attente hors ligne.

Ce comportement est le comportement standard.

La relation Collocated tente d’optimiser la sélection du noeud basée sur des

prédictions pour des situations ultérieures. Les cas possibles sont les suivants :

Cas II :

La ressource B est démarrée et la ressource A possède l’état Hors ligne, Echec hors

ligne ou Inconnu.

En règle générale, vous vous attendez à ce que la sélection du noeud pour la

ressource B se fasse indépendamment de la ressource A. Mais lorsque System

Automation for Multiplatforms sélectionne un noeud pour la ressource B, le noeud

est sélectionné en fonction de la possibilité pour la ressource A de démarrer dans

ce noeud ultérieurement. La raison de cette approche prévisionnelle est qu’elle

simplifie le comportement de démarrage de la ressource A : si aucune erreur ne se

produit, vous êtes assuré que la ressource A pourra être démarrée dans le noeud

où la ressource B est en cours d’exécution une fois la ressource B démarrée.

Relations gérées


Cas III :

La ressource A est démarrée et la ressource B possède l’état Hors ligne.

En théorie, la ressource A peut être désormais placée dans n’importe quel noeud

de la liste de noeuds car la ressource A ne peut pas être liée à un noeud dans

lequel la ressource B est en cours d’exécution. Une fois encore, l’approche

prévisionnelle tente de trouver un emplacement de noeud pour la ressource A

dans lequel la ressource B pourra également être démarrée ultérieurement. Par

conséquent, System Automation for Multiplatforms détermine le même

emplacement de noeud pour les deux ressources A et B même s’il ne démarre que

la ressource A. Le comportement interne de System Automation for

Multiplatforms est le suivant : lorsque la ressource A doit être démarrée, System

Automation for Multiplatforms détermine un emplacement de noeud pour les

ressources A et B puis démarre la ressource A. (Remarque : le démarrage de la

ressource B n’est pas dirigé par la relation Collocated. Il est influencé par la

relation de démarrage/d’arrêt ou une relation de groupe).

Pour résumer l’approche prévisionnelle : si la ressource A ou B est démarrée et

que l’autre ressource possède l’état Hors ligne, System Automation for

Multiplatforms détermine l’emplacement où les deux ressources sont liées de

manière logique préalablement au démarrage.

Notez que l’optimisation de l’emplacement de noeud est uniquement une prévision

basée sur les circonstances en cours. Les conditions requises à l’origine de la

sélection du noeud peuvent varier au fil du temps.

Prenons par exemple un scénario où la prédiction pour la sélection du noeud est

erronée : les ressources A et B sont des ressources flottantes et peuvent se situer

dans les noeuds 1, 2, 3. La relation ″A -- Collocated ---> B″ est définie. La

ressource B doit maintenant être démarrée. En raison de la relation colocalisée,

System Automation for Multiplatforms peut sélectionner le noeud node1 pour les

ressources A et B. Puis la ressource B est démarrée. Après quelques instants,

l’apparition d’une erreur d’utilisation a pour conséquence que la ressource A ne

peut plus être démarrée dans le noeud node1. L’état opérationnel (OpState) de la

ressource dans le noeud node1 est Echec hors ligne. Ensuite, une requête requiert

le démarrage de la ressource A. Comme la ressource A ne peut plus être démarrée

dans le noeud node1, un conflit voit le jour et doit être résolu conformément aux

indications communiquées ci-après.

Cas IV :

Un autre état éventuel est que la ressource A possède déjà un état en cours

d’exécution (état opérationnel est En ligne, En attente en ligne, Echec en ligne ou

En attente hors ligne) au démarrage de la ressource B.

Relations gérées


Lors du démarrage de la ressource A, le noeud sélectionné pour la ressource B

était le même. Si aucune erreur ne survient, la ressource B peut être démarrée dans

ce noeud. Si un problème se pose et empêche le démarrage de la ressource B dans

le noeud sélectionné précédemment, la ressource ne sera plus liée et, au démarrage

de la ressource B, un nouvel emplacement de noeud doit être trouvé. Cela signifie

que la ressource B peut être démarrée dans un autre noeud.

Les relations et conditions suivantes peuvent être définies :

v Collocated/IfOnline

La relation A ---> Collocated/IfOnline -----> B signifie que la relation

d’emplacement est uniquement prise en considération lorsque la ressource B

possède l’état En ligne. Autrement, la relation d’emplacement est ignorée. La

condition IfOnline n’englobe pas les états tels que En attente en ligne et En

attente hors ligne.

v Collocated/IfOffline

La relation A ---> Collocated/IfOffline -----> B signifie que la relation

d’emplacement est uniquement valide lorsque la ressource B possède l’état Hors

ligne, Echec hors ligne ou Inconnu.

v Collocated/IfNotOnline

La relation A ---> Collocated/IfNotOnline -----> B signifie que la relation

d’emplacement est uniquement valide lorsque la ressource B ne possède pas

l’état En ligne.

v Collocated/IfNotOffline

La relation A ---> Collocated/IfNotOffline -----> B signifie que la relation

d’emplacement est uniquement valide lorsque la ressource B ne possède pas

l’état Hors ligne, Echec hors ligne ou Inconnu.

Relations gérées


Relation AntiCollocated

System Automation for Multiplatforms utilise la relation AntiCollocated afin de

garantir que les ressources source et cible se trouvent dans des noeuds différents. La

relation AntiCollocated présente le modèle de comportement suivant :

v La relation AntiCollocated définit que la ressource A peut uniquement être

démarrée sur un noeud autre que celui dans lequel la ressource B est en cours

d’exécution.

La relation AntiCollocated peut être utilisée conjointement à l’attribut Condition,

comme indiqué à la page 85.


relation AntiCollocated

La section suivante décrit en détail quatre états que la relation AntiCollocated peut

prendre :

Cas I :

Au démarrage de la ressource A, placez-la dans un noeud autre que celui où la

ressource B est en cours d’exécution. ’En cours d’exécution’ signifie que l’état

opérationnel de la ressource B est En ligne, En attente en ligne, Echec en ligne ou

En attente hors ligne.

Ce comportement est le comportement standard.

La relation AntiCollocated tente d’optimiser la sélection du noeud basée sur des

prédictions pour des situations ultérieures. Les cas possibles sont les suivants :

Cas II :

La ressource B est démarrée et la ressource A possède l’état Hors ligne, Echec hors

ligne ou Inconnu.

En règle générale, vous vous attendez à ce que la sélection du noeud pour la

ressource B se fasse indépendamment de la ressource A. Lorsque System

Automation for Multiplatforms sélectionne un noeud pour la ressource B, un

noeud autorisant le démarrage ultérieur de la ressource A dans un autre noeud est

sélectionné. La raison de cette approche prévisionnelle est qu’elle simplifie le

comportement de démarrage de la ressource A : si aucune erreur ne se produit,

vous êtes assuré que la ressource A pourra être démarrée dans un noeud autre que

le noeud dans lequel la ressource B est en cours d’exécution une fois la

ressource B démarrée. Ce cas de figure correspond à la description du Cas I.

Relations gérées


Cas III :

La ressource A est démarrée et la ressource B possède l’état Hors ligne ou Echec

hors ligne.

En théorie, la ressource A peut être désormais placée dans n’importe quel noeud

de la liste de noeuds. Une fois encore, l’approche prévisionnelle tente de trouver

un emplacement de noeud pour la ressource A qui autorise le démarrage ultérieur

de la ressource B dans un autre noeud. Par conséquent, System Automation for

Multiplatforms détermine un emplacement de noeud pour la ressource B même

s’il ne démarre que la ressource A.

Résumé de l’approche prévisionnelle :

Si la ressource A possède un état en ligne et que la ressource A ou B est démarrée,

(voir Cas II et III), System Automation for Multiplatforms détermine un

emplacement de noeud différent pour les ressources A et B avant de démarrer

l’une des deux.

Comme mentionné dans la description de la relation Collocated, il peut arriver que

les prévisions basées sur les circonstances courantes deviennent erronées avec le

temps. Néanmoins, l’approche prévisionnelle simplifie le comportement

d’automatisation dans la plupart des cas.

Cas IV :

La ressource A possède déjà un état en cours d’exécution (état opérationnel défini

sur En ligne, En attente en ligne, Echec en ligne ou en Attente hors ligne) lorsque

la ressource B est démarrée.

Lors du démarrage de la ressource A (voir cas III), le noeud sélectionné pour la

ressource B était déjà différent. Si aucune erreur ne se produit, la ressource B peut

être démarrée. Si un problème se pose et a pour conséquence que la ressource B ne

peut plus être démarrée dans le noeud sélectionné précédemment, un nouvel

emplacement de noeud doit être trouvé au démarrage de la ressource B. Cela

signifie que la ressource B peut être démarrée dans n’importe emplacement, même

dans celui où la ressource A est déjà en cours d’exécution.


v AntiCollocated/IfOnline

La relation A ---> AntiCollocated/IfOnline -----> B signifie que la relation

d’emplacement est uniquement valide lorsque la ressource B possède un état En

ligne. Autrement, la relation d’emplacement est ignorée. La condition IfOnline

n’englobe pas les états tels que En attente en ligne et En attente hors ligne.

v AntiCollocated/IfOffline

La relation A ---> AntiCollocated/IfOffline -----> B signifie que la relation

d’emplacement est uniquement valide lorsque la ressource B possède l’état Hors

ligne, Echec hors ligne ou Inconnu.

Relations gérées


v AntiCollocated/IfNotOnline

La relation A ---> AntiCollocated/IfNotOnline -----> B signifie que la relation

d’emplacement est uniquement valide lorsque la ressource B ne possède pas un

état En ligne.

v AntiCollocated/IfNotOffline

La relation A ---> AntiCollocated/IfNotOffline -----> B signifie que la relation


état Hors ligne, Echec hors ligne ou Inconnu.

Relation Affinity

La relation Affinity présente le modèle de comportement suivant :

v La relation Affinity définit qu’au démarrage de la ressource A, le même noeud

que celui où la ressource B est en cours d’exécution est sélectionné, dans la

mesure du possible. Si d’autres relations d’emplacement inhibe cette relation, la

ressource A peut également fonctionner sur un autre noeud.

La relation Affinity ressemble fortement à la relation Collocated. Par conséquent, la

relation Affinity définit une relation d’emplacement souple alors que la relation

Collocated est une relation d’emplacement rigide.

La relation Affinity peut être utilisée conjointement à l’attribut Condition (décrit à

la section «Attribut Condition», à la page 61).


v Affinity/IfOnline

La relation A ---> Affinity/IfOnline -----> B signifie que la relation

d’emplacement peut uniquement être prise en considération lorsque la

ressource B possède un état En ligne. Autrement, la relation d’emplacement est

ignorée. La condition IfOnline n’englobe pas les états tels que En attente en ligne

et En attente hors ligne.

v Affinity/IfOffline

La relation A ---> Affinity/IfOffline -----> B signifie que la relation

d’emplacement est uniquement valide lorsque la ressource B possède un état

Hors ligne, Echec hors ligne ou Inconnu.

v Affinity/IfNotOnline

La relation A ---> Affinity/IfNotOnline -----> B signifie que la relation


état En ligne.

v Affinity/IfNotOffline

La relation A ---> Affinity/IfNotOffline -----> B signifie que la relation



Relations gérées


Relation AntiAffinity

La relation AntiAffinity présente le modèle de comportement suivant :

v La relation AntiAffinity définit qu’au démarrage de la ressource A, un noeud

autre que celui où la ressource B est en cours d’exécution est sélectionné, dans

la mesure du possible. Si d’autres relations d’emplacement inhibe cette relation,

la ressource A peut également fonctionner sur le même noeud.

La relation AntiAffinity ressemble fortement à la relation AntiCollocated. Par

conséquent, la relation AntiAffinity définit une relation d’emplacement souple alors

que la relation AntiCollocated est une relation d’emplacement rigide.

La relation AntiAffinity peut être utilisée conjointement à l’attribut Condition

(décrit à la section «Attribut Condition», à la page 61).

Voir aussi «Relations Location», à la page 79.


v AntiAffinity/IfOnline

La relation A ---> AntiAffinity/IfOnline -----> B signifie que la relation

d’emplacement est uniquement valide lorsque la ressource B possède un état En

ligne. Autrement, la relation d’emplacement est ignorée. La condition IfOnline

n’englobe pas les états tels que En attente en ligne et En attente hors ligne.

v AntiAffinity/IfOffline

La relation A ---> AntiAffinity/IfOffline -----> B signifie que la relation

d’emplacement est uniquement valide lorsque la ressource B possède un état

Hors ligne, Echec hors ligne ou Inconnu.

v AntiAffinity/IfNotOnline

La relation A ---> AntiAffinity/IfNotOnline -----> B signifie que la relation


état En ligne.

v AntiAffinity/IfNotOffline

La relation A ---> AntiAffinity/IfNotOffline -----> B signifie que la relation



Relations gérées


Relation IsStartable

La relation IsStartable présente le modèle de comportement suivant :

v La relation IsStartable définit que la ressource A peut uniquement être placée

dans un noeud dans lequel la ressource B peut être démarrée lorsque les

ressources A et B possèdent un état nominal En ligne.

La relation IsStartable n’implique pas que la ressource cible puisse être démarrée

ultérieurement. La raison est que les défaillances de ressources peuvent empêcher

la résolution ultérieure de toutes les relations.

Voir aussi «Relations Location», à la page 79.


relation IsStartable

La relation IsStartable déclenche le comportement suivant :

La relation IsStartable définit que la ressource source peut uniquement être placée

dans un noeud dans lequel la ressource cible peut être démarrée. Cette relation est

uniquement prise en considération si les ressources source et cible possèdent l’état

nominal En ligne. Si l’une des ressources (source ou cible) ne possède pas l’état

nominal En ligne, la relation IsStartable sera supprimée avec les ressources

possédant l’état nominal Hors ligne.

L’exemple suivant détaille le comportement de la relation IsStartable :

Les ressources A et B sont des ressources flottantes et sont membres du même

groupe de ressources RG_A. La ressource A peut fonctionner dans le noeud node1

et node2 et la ressource B dans le noeud node3. La relation IsStartable est définie

de la ressource A vers la ressource B.

Les deux membres sont lancés lorsque l’état nominal du groupe de ressources est

défini sur En ligne. En fonction de la relation IsStartable, les ressources A et B sont

démarrées dans le noeud node2, ce noeud étant le noeud situé à l’intersection des

deux ressources. Lorsque la ressource B se trouve dans un état Echec en ligne dans

le noeud node2, le démarrage du groupe de ressources RG_A ne provoque pas le

démarrage de la ressource A. Aussi, il n’existe aucun noeud sur lequel les

ressources A et B peuvent être lancées.

L’exemple suivant apporte des informations supplémentaires sur la relation

IsStartable. Dans ce scénario, la ressource A peut fonctionner dans les noeuds

node1, node2 et node3 et est membre du groupe de ressources RG_A. La

ressource B peut fonctionner dans les noeuds node1 et node2 et est membre du

groupe de ressources RG_B. Une relation IsStartable est définie de la ressource A

vers la ressource B.

Relations gérées


La section suivante illustre les états éventuels de cet exemple :

v L’état nominal de RG_A est défini sur En ligne alors que celui de RG_B est

défini sur Hors ligne. Puisque la relation IsStartable est uniquement prise en

considération lorsque les ressources source et cible (RG_A et RG_B) possèdent

un état nominal En ligne et que dans ce cas l’état nominal de RG_B est Hors

ligne, la relation sera ignorée. Par conséquent, la ressource A peut démarrer sur

le noeud node1, node2 ou node3.

v L’état nominal de RG_A est défini sur En ligne alors que le groupe RG_B est

déjà en ligne. Dans ce cas, la relation IsStartable est prise en considération et

System Automation for Multiplatforms lance la ressource A dans un noeud où

la ressource B peut démarrer (le noeud node1 ou node2).

v En raison d’une défaillance, la ressource B ne peut démarrer dans les noeuds

node1 et node2 et l’état nominal du groupe RG_B est En ligne. Le démarrage du

groupe de ressources RG_A empêche la mise en ligne de la ressource A car la

ressource B ne peut être démarrée dans les noeuds contigus node1 et node2.

v En raison d’une défaillance, la ressource B ne peut démarrer dans les noeuds

node1 et node2 et l’état nominal du groupe RG_B est Hors ligne. Lorsque l’état

nominal du groupe de ressources RG_A est défini sur En ligne, System

Automation for Multiplatforms supprime la ressource B et la relation IsStartable

est ignorée en raison de l’état requis hors ligne du groupe de ressources RG_B.

Relations gérées


Création et administration des relations

Création d’une relation

Pour créer une relation entre une ressource source et une ou plusieurs ressources

cible, utilisez la commande mkrel.

La ressource source doit être membre d’un groupe de ressources. La ressource cible

ne doit pas se trouver dans le groupe de ressources.

Par exemple, pour définir une relation AntiCollocated d’une ressource source

FloatWebServerA de la classe IBM.Application vers une ressource cible

FloatWebServerB de la classe IBM.Application avec la condition ’IfOnline’ et le

nom ’Rel1’, entrez :

mkrel -p anticollocated -o ifonline -S IBM.Application:FloatWebServerA -G

IBM.Application:FloatWebServerB Rel1

Pour plus d’informations, consultez la page d’aide de la commande mkrel ou la

description de la commande mkrel dans le Guide de référence d’IBM Tivoli System


Enumération d’une relation

Pour répertorier une relation, utilisez la commande lsrel.

Si vous ne spécifiez pas le nom d’une relation, toutes les relations actuellement

définies seront répertoriées :

lsrel

Affichage des informations liées aux relations gérées :

Nomm Classe:Ressource:Noeud[Source] ResourceGroup[Source]

Rel1 IBM.Application:FloatWebServerA RG_WebApp

Si vous définissez un nom de relation en utilisant l’option -M, une liste des

attributs persistants de la relation spécifiée sera affichée. Par exemple, pour

répertorier les attributs de la relation Rel1, entrez :

lsrel -M Rel1

Affichage des informations liées à la relation gérée :

pour la relation gérée "Rel1".

Relation gérée 1:

Nom = Rel1

Classe:Ressource:Noeud[Source] = IBM.Application:FloatWebServerA

Classe:Ressource:Noeud[Cible] = {IBM.Application:FloatWebServerB}

Relation = AntiCollocated

Conditionnel = IfOnline

ResourceGroup[Source] = RG_WebApp

Relations gérées


Il se peut que vous obteniez un résultat identique en affichant la liste de toutes les

relations dans lesquelles IBM.Application:FloatWebServerA est la source (option

-S) :

lsrel -S IBM.Application:FloatWebServerA

Affichage des informations liées à la relation gérée :

Relation gérée 1:

Nom = Rel1

Classe:Ressource:Noeud[Source] = IBM.Application:FloatWebServerA

Classe:Ressource:Noeud[Cible] = {IBM.Application:FloatWebServerB}

Relation = AntiCollocated

Conditionnel = IfOnline

ResourceGroup[Source] = RG_WebApp

Pour plus d’informations, consultez la page d’aide de la commande lsrel ou la

description de la commande lsrel dans le Guide de référence d’IBM Tivoli System


Modification d’une relation

Pour modifier une relation, utilisez la commande chrel.

Par exemple, pour modifier une relation appelée Rel1 (créée ci-avant) en relation

AntiAffinity, entrez :

chrel -p antiaffinity Rel1

Pour plus d’informations, consultez la page d’aide de la commande chrel ou la

description de la commande chrel dans le Guide de référence d’IBM Tivoli System


Suppression d’une relation

Pour supprimer une relation définie entre des ressources source et cible, utilisez la

commande rmrel.

Par exemple, pour supprimer une relation pour une ressource source

FloatWebServerA de la classe IBM.Application, entrez :

rmrel -S IBM.Application:FloatWebServerA

Pour plus d’informations, consultez la page d’aide de la commande rmrel ou la

description de la commande rmrel dans le Guide de référence d’IBM Tivoli System


Relations gérées


Chapitre 7. Traitement des informations système par System


Ce chapitre décrit tout d’abord l’algorithme de liaison également appelé ″classeur″.

Il s’agit d’une fonction interne de System Automation for Multiplatforms chargée

du positionnement des noeuds de toutes les ressources. La seconde partie de ce

chapitre traite des événements qui permettent la mise en ligne d’un groupe de

ressources. La troisième partie est consacrée aux modèles de comportement de


Définition de la relation d’emplacement : algorithme de liaison

Le classeur est appelé lors d’un lancement de ressources pour lesquelles System

Automation for Multiplatforms n’a pas encore attribué de position de noeud. Les

ressources qui disposent d’un emplacement de noeud sont ″liées″. Par exemple,

une ressource flottante A pouvant fonctionner dans plusieurs noeuds. Dans ce cas,

l’algorithme de liaison doit déterminer (lier) un emplacement de noeud pour la

ressource flottante en prenant toutes ces relations d’emplacement en considération.

En fonction des exécutions précédentes d’algorithme de liaison, une nouvelle

solution doit être trouvée. Les solutions de liaison ne doivent pas nécessairement

être non ambiguës. Plusieurs constellations offrent des solutions alternatives dans

lesquelles la sélection par System Automation for Multiplatforms est arbitraire.

Un exemple de scénario ambigu serait un groupe de ressources avec une relation

d’emplacement colocalisée contenant deux ressources flottantes A et B pouvant être

exécutées dans les noeuds node1 et node2. Au lancement du groupe, deux

solutions alternatives sont possibles : A ou B est lié au noeud node1 ou A et B sont

liés au noeud node2.

Si l’algorithme de liaison trouve une solution pour positionner le noeud des

ressources impliquées, la ou les ressources sont démarrées. Il est, toutefois, évident

que des relations d’emplacement peuvent donner lieu à des conflits devant être

résolus.

Exemple : deux ressources flottantes "A" et "B" peuvent être situées sur les noeuds

"node1" et "node2". Mais, en raison de contraintes de performance, elles ne peuvent

pas être exécutées de manière simultanée sur le même noeud. Pour ce faire, on

indique les relations AntiCollocated de "A" à "B" et de "B" à "A". Il est supposé que

la ressource "A" fonctionne déjà sur le noeud node 1, tandis que le noeud node 2

échoue. Si un utilisateur lance la ressource "B", un conflit de résolution

d’emplacement aura lieu puisque les ressources ne peuvent pas être lancées sur le

même noeud. Dans le cas présent, il n’existe pas de solution parfaite à cet incident

qui permettrait l’exécution des deux ressources. Pour résoudre ce type de conflits,

System Automation for Multiplatforms effectue une étape d’élimination.

Il se peut que les ressources qui sont déjà en ligne soient impliquées dans le

problème. Ces ressources reçoivent une prime de priorité supplémentaire de 10


dans leur priorité définie par le groupe de ressources (pour plus d’informations sur

l’attribut Priorité et ses effets, voir Attributs utilisés par les groupes de ressources,

«Attribut Priorité», à la page 42).

La section suivante décrit en détail le processus de recherche de solution de

System Automation for Multiplatforms pour des relations d’emplacement et la

gestion de la résolution des conflits. Ce processus s’appelle ″algorithme de liaison″.

L’algorithme de liaison comprend plusieurs étapes :

1. Etape de reconnaissance : Détermination de la configuration des

sous-ensembles pour lesquels les relations d’emplacement peuvent être

résolues de manière indépendante.

L’algorithme de reconnaissance se compose de plusieurs étapes :

a. Etape 1a : Recherche de toutes les ressources impliquées (sous-ensemble

de configuration)

Les relations d’emplacement peuvent diviser une configuration client en

divers sous-ensembles de configuration pouvant être résolus

indépendamment. La raison est que les relations d’emplacement affectent

souvent un seul sous-ensemble de ressources de la configuration. Exemple

de configuration : A --> Collocated --> B, B--> Collocated --> C et D -->

Collocated --> E. Les emplacements de relation pour A, B et C peuvent être

résolus indépendamment de D et E. Pour ces deux sous-ensembles, toutes

les étapes suivantes sont effectuées séparément.

b. Etape 1b : Ignorer toutes les ressources lorsque l’état opérationnel est

Echec hors ligne

Il est évident que toutes les instances dont l’état opérationnel est Echec hors

ligne ne peuvent contribuer à la constitution d’une solution de liaison. Ces

instances sont extraites du sous-ensemble de configuration utilisé pour la

recherche d’une solution de liaison. Prenons par exemple un Groupe de

ressources R1 contenant deux ressources flottantes A et B pouvant être

exécutées sur les noeuds node1 et node2. Le groupe possède un paramètre

colocalisé défini ce qui signifie que les ressources A et B doivent être lancées

sur le même noeud. Supposons que le noeud node2 tombe en panne : les

constituants des ressources flottantes A et B du noeud node2 ont l’état

″Echec hors ligne″. Par conséquent, ils sont supprimés du sous-ensemble de

configuration, car les instances du noeud node2 ne seront d’aucun recours

lors de la résolution du problème de liaison.

c. Etape 1c : Nettoyage des groupes de ressources ne pouvant être lancés.

Si des membres obligatoires des groupes de ressources ont l’état ″Echec hors

ligne″, le groupe de ressources ne peut être lancé en raison du

comportement du groupe. Aussi, tous les autres membres du groupe de

ressources doivent être arrêtés.

Prenons, par exemple, un groupe de ressources R1 avec des ressources

flottantes A et B comme décrites ci-avant. Si la ressource flottante A ne peut

être démarrée sur l’un des noeuds en raison d’une erreur d’application, et

s’il s’agit d’un membre obligatoire du groupe de ressources, la ressource

flottante B sera également arrêtée (voir les membres de groupes de

ressources).2. Etape de recherche d’une solution idéale : Essayez de trouver une solution

″idéale″

Tout d’abord, le gestionnaire de ressources de reprise sur incident tente de

trouver une solution idéale pour toutes les relations d’emplacement impliquées

d’un sous-ensemble de configuration. Au cours de cette étape, il tente de

Logique de System Automation for Multiplatforms


trouver des liaisons comme indiqué dans la rubrique «Relations Location», à la

page 79. Puisque le but de cette première étape est de trouver une solution

idéale, toutes les relations Affinity et AntiAffinity sont traitées comme s’il

s’agissait de relations Collocated ou AntiCollocated. En outre, les ressources

hors ligne qui ne sont pas censées être lancées seront utilisées pour des

tentatives de liaison si nécessaire. Si aucun conflit de relation d’emplacement

n’a lieu, les ressources nécessaires sont liées et l’algorithme de liaison est créé.

System Automation for Multiplatforms peut ensuite lancer les ressources qui

doivent être démarrées.

Dans certains cas, l’étape de liaison donne lieu à un conflit provoqué par des

contraintes contradictoires ne pouvant être surmontées. Pour résoudre ce

conflit, System Automation for Multiplatforms propose une étape d’élimination

qui comprend les sous-étapes suivantes.

3. Etape d’élimination : Résoudre les conflits de relations d’emplacement

L’étape d’élimination se compose de plusieurs sous-étapes :

a. Etape 3a : Ignorer les relations Affinity et AntiAffinity

La première approche pour surmonter un conflit consiste à ignorer toutes

les relations Affinity et AntiAffinity, car il s’agit de relations d’emplacement

″accessoires″. En fonction des liaisons précédentes, System Automation for

Multiplatforms tente de trouver une solution pour les ressources qui

doivent être liées. Puisque les relations Affinity et AntiAffinity sont

ignorées, les relations d’emplacement sont simplifiées et les probabilités de

trouver une solution de liaison s’en trouvent accrues. Si une solution est

trouvée, l’étape de sacrifice n’a pas lieu. Mais il se peut que le conflit ne

puisse être surmonté. Alors, l’étape du sacrifice a lieu.

b. Etape 3b : Ignorer toutes les ressources possédant l’état opérationnel =

Hors ligne et qui ne doivent pas être lancées

Si vous ignorez toutes les relations Affinity et AntiAffinity et que cela ne

vous aide pas à trouver une solution au problème de liaison, (voir étape 3a),

la prochaine étape consiste à ignorer toutes les ressources de l’évaluation de

liaison qui sont Hors ligne et qui ne doivent pas être lancées. Cette

opération augmente les possibilités de trouver une solution de liaison.

Si une solution de liaison est disponible, l’étape de sacrifice n’a pas lieu. Le

cas échéant, passez à l’étape suivante du processus d’élimination.

Prenons par exemple un groupe de ressources R1 qui contient une ressource

flottante A, et un groupe de ressources R2 qui contient une ressource

flottante B et une relation A AntiCollocated. Les ressources flottantes A et B

peuvent être exécutées sur les noeuds node1 et node2, mais le noeud node2

ne fonctionne pas.

L’état actuel nominal de R1 est défini sur En ligne : la ressource A doit être

liée avant de pouvoir être lancée. En premier lieu, System Automation for

Multiplatforms tente de trouver une solution idéale. Par conséquent, il tente

de lier A et B. Mais dans ce cas de figure, aucune solution ne peut être

trouvée. Ensuite, System Automation for Multiplatforms ignore toutes les

relations Affinity et AntiAffinity, qui ne fournissent également aucune

solution. Puis, il ignore toutes les ressources possédant l’état Hors ligne et

qui ne doivent pas être lancées. La ressource B est donc ignorée lors de

l’évaluation. Il est désormais possible de lier la ressource A au modèle.


Chapitre 7. Traitement des informations système par System Automation for Multiplatforms 95

Les ressources non obligatoires sont supprimées de l’ensemble des liaisons

dans l’ordre suivant :

1) Les ressources non démarrables sont supprimées en premier.

2) Si aucune ressource n’a pu être supprimée, les ressources actuellement

hors ligne sont alors prises en compte.

3) Si malgré cela, aucune ressource n’a pu être supprimée, toutes les

ressources non obligatoires sont supprimées.

4) Si le groupe de ressources lui-même est un membre non obligatoire,

toutes les ressources, y compris celles qui sont obligatoires, sont

supprimées.c. Etape 3c : Arrêt des membres les moins importants du groupe de

ressources

La prochaine étape de sacrifice consiste à présent à arrêter les membres du

groupe de ressources et à ignorer ses membres lors de l’évaluation de

liaison. Comme chaque groupe de ressources possède une valeur de

priorité, les membres du groupe de ressources du ou des groupes possédant

la valeur de priorité la plus faible sont arrêtés en premier lieu, puis une

tentative de recherche de solution de liaison a lieu sans ces membres. Si

cette solution ne satisfait pas les contraintes de liaison, les membres du

groupe de ressources possédant le prochain niveau de priorité le plus faible

sont sélectionnés.

En plus du schéma de priorité, l’arrêt et la suppression des groupes de

ressources sont effectués en deux sous-étapes :

1) Tous les membres facultatifs du niveau de priorité du groupe sont

arrêtés et ignorés dans la solution de liaison. Si un groupe est un

membre facultatif d’un autre groupe, les membres obligatoires sont

supprimés d’une manière explicite. Cette étape supplémentaire permet

d’organiser des règles d’administration plus complexes telles que la

règle d’administration SAP et de gérer les situations qui nécessitent

l’arrêt des ressources avant de trouver une solution de liaison, par

exemple, quand un serveur de mise en file d’attente SAP a échoué.

2) Si le conflit persiste, les membres du prochain groupe avec la priorité la

plus faible sont arrêtés comme indiqué ci-dessus.

Ces étapes sont réalisées de manière itérative jusqu’à ce qu’une solution de

liaison soit trouvée ou que le problème de liaison soit considéré comme

insoluble. Dans ce dernier cas, toutes les ressources qui contribuent au

problème de liaison sont arrêtées et une nouvelle tentative de résolution

aura lieu quand ces ressources seront arrêtées.

Astuces :

v D’autres groupes doivent posséder une priorité identique ou supérieure à

celle des groupes internes. Autrement, les groupes externes seront

supprimés avant les groupes internes. Si les groupes externes sont

supprimés avant les groupes internes, ces derniers sont arrêtés

automatiquement.

v Les groupes de ressources qui sont des membres facultatifs d’un autre

groupe de ressources doivent posséder un niveau de priorité inférieur à

celui des groupes de ressources qui sont des membres obligatoires du

même groupe de ressources. Le cas échéant, les membres obligatoires

peuvent être supprimés.

v Pour plus d’informations sur la gestion des priorités, voir Attributs

utilisés par les groupes de ressources, «Attribut Priorité», à la page 42).



Evénements permettant la Mise en ligne d’un groupe de ressources

Tous les groupes de ressources de niveau supérieur dont l’attribut NominalState

est En ligne seront automatisés : c’est-à-dire qu’une tentative de démarrage des

groupes de ressources de niveau supérieur et des groupes gérés au sein de ces

groupes sera effectuée, à la condition que les relations gérées des ressources gérées

de ces groupes de ressources puissent être satisfaites.

Si un groupe de ressources ou une ressource gérée ne peut être mis en ligne

(lorsqu’un ou plusieurs de ses ressources membres n’atteignent pas complètement

l’état En ligne requis), le groupe de ressources possède l’état Hors ligne. Le groupe

de ressources demeure Hors ligne jusqu’à ce qu’un événement informe System

Automation for Multiplatforms qu’il doit à nouveau essayer de lancer le groupe de

ressources.

Les événements suivants peuvent provoquer la mise en ligne d’un groupe de

ressources Hors ligne :

v Modification de l’attribut AllowedNodes (décrit dans «Attribut AllowedNode», à la

page 39) du groupe de ressources, par exemple, afin d’inclure un noeud

supplémentaire à l’endroit où le groupe de ressources peut être lancé. Pour plus

d’informations, consultez la description de la commande chrg dans le Guide de

référence d’IBM Tivoli System Automation for Multiplatforms.

v Retrait d’une ressource gérée d’un groupe de ressources. Par conséquent, les

ressources membre peuvent être démarrées en raison de la suppression d’une

ressource qui n’a pu être supprimée. Pour plus d’informations, consultez la

description de la commande rmrgmbr dans le Guide de référence d’IBM Tivoli


v Ajout d’une ressource dans un groupe de ressources qui est la ressource cible

d’une relation gérée mais qui n’est pas actuellement membre d’un groupe de

ressources. Cette opération sera alors automatisée par System Automation for

Multiplatforms. Par conséquent, les ressources membres peuvent être démarrées

car une relation gérée peut être satisfaite. Pour plus d’informations, consultez la

description de la commande addrgmbr dans le Guide de référence d’IBM Tivoli


v Lancement d’une ressource non contrôlable par System Automation for

Multiplatforms et qui est une relation gérée d’un membre du groupe de

ressources. Par conséquent, la ressource passe à l’état En ligne et la relation

gérée est satisfaite. Le groupe de ressources peut éventuellement passer à l’état

En ligne. Pour utiliser la ressource, vous pouvez utiliser la commande RMC

startrsrc (pour des informations détaillées, reportez-vous à la page d’aide de

cette commande).

v Ajout d’un constituant à un agrégat qui rendra les ressources agrégées

disponibles sur plusieurs noeuds et permettra éventuellement à System

Automation for Multiplatforms de satisfaire toutes les contraintes des relations

gérées. Si le constituant est une partie du logiciel, vous devrez installer le

logiciel ou le définir correctement. Si la ressource est une ressource flottante,

ajoutez un constituant en créant un nom de noeud dans l’attribut

NodeNameList. Pour des informations détaillées, reportez-vous à la

documentation RMC et aux pages d’aide.

v Une nouvelle ressource est trouvée à l’aide d’une équivalence qui utilise une

chaîne de sélection dynamique. Par conséquent, cette ressource est ajoutée à

l’équivalence et peut convertir une relation gérée en cette équivalence.



v Passage d’une ressource gérée à l’état Facultatif : cette ressource pourra être

sacrifiée. Par conséquent, les autres ressources gérées peuvent être lancées. Pour

plus d’informations, consultez la description de la commande chrgmbr dans le

Guide de référence d’IBM Tivoli System Automation for Multiplatforms.

v Réalisation d’une réinitialisation pour un agrégat ou l’un de ses constituants

après résolution d’un incident. Par conséquent, la ressource sera Hors ligne et

pourra alors être lancée par System Automation for Multiplatforms. Pour plus

d’informations, consultez la page d’aide de la commande RMC resetrsrc.

v Mise en ligne d’un noeud jusque-là hors ligne. System Automation for

Multiplatforms sera éventuellement capable de faire passer le groupe de

ressources à l’état En ligne.

v Modification d’un attribut de priorité d’un groupe de ressources (détaillé dans la

section «Attribut Priorité», à la page 42). Il se peut qu’un groupe de ressources

ne puisse être démarré en raison d’un conflit de priorité avec un autre groupe

de ressources. Dans ce cas, augmentez la priorité du groupe que vous souhaitez

lancer ou diminuez la priorité de l’autre groupe. Les modifications sont

appliquées au prochain démarrage du groupe.

v Arrêt d’un groupe de ressources de priorité supérieure : un groupe de ressources

avec une priorité inférieure ne peut être lancé. Vous évitez ainsi un conflit de

relation gérée. Pour plus d’informations, consultez la description de la

commande chrg dans le Guide de référence d’IBM Tivoli System Automation for

Multiplatforms.

Si un groupe de ressources possède actuellement une valeur NominalState, les

événements suivants peuvent provoquer des actions d’automatisation

supplémentaires :

1. La valeur de l’attribut NominalState passe de Hors ligne à En ligne.

2. La valeur de l’attribut NominalState passe de En ligne à Hors ligne.

Modèles de comportement d’IBM Tivoli System Automation for

Multiplatforms

Cette section décrit comment System Automation for Multiplatforms se comporte

et comment il réagit dans certaines situations.

Considérations générales

Les sections suivantes décrivent les difficultés liées aux commandes de démarrage

(Start), de contrôle (Monitor) et d’arrêt (Stop).

Problèmes liés à la commande de démarrage (Start)

IBM Tivoli System Automation for Multiplatforms utilise la commande indiquée

dans l'attribut de la commande de démarrage afin de mettre la ressource en ligne.

Elle appelle la commande de démarrage dans les cas suivants :

v Immédiatement après la modification de l’attribut NominalState d’un groupe de

ressources à l’état En ligne et la satisfaction de toutes les dépendances de

démarrage de cette ressource.

v Immédiatement après la modification de l’état opérationnel de En ligne à Hors

ligne en raison d’une défaillance de la ressource.

La commande de démarrage n’est pas appelée si le changement de l’état

opérationnel à Hors ligne est la conséquence d’un des événements suivants :

v L’attribut NominalState du groupe de ressources a été remplacé par Hors ligne.



v La ressource a été arrêtée ou son interruption a été forcée par System

Automation for Multiplatforms afin de respecter une dépendance sur une autre

ressource.

Si la commande de démarrage a déjà été exécutée pour une ressource, mais que

cette ressource est toujours Hors ligne au moment ou le délai d’attente de mise en

ligne a expiré et que le nombre de tentatives maximum restant (défini par l’attribut

RetryCount) pour exécuter la commande de démarrage n’a pas été atteint, le délai

d’attente de mise en ligne (en secondes) d’une ressource est calculé à l’aide de la

formule suivante :

MAX(StartCommandTimeout, MonitorCommandPeriod, MonitorCommandTimeout) + 5

Remarques :

1. + 5 n’est pas une valeur absolue car System Automation for Multiplatforms

n’utilise pas de véritable temporisateur. La valeur réelle peut varier entre 5 et

8 secondes, selon le moment où le démon System Automation for

Multiplatforms est appelé à nouveau, ce qui se produit fréquemment.

2. Ce délai d’attente de mise en ligne n’est évalué que si l'état opérationnel de la

ressource n’a pas changé au cours de l’exécution précédente de la commande

de démarrage. Si l’état opérationnel a effectivement changé (par exemple, de En

attente en ligne à En ligne), le temporisateur de délai d’attente de mise en ligne

est annulé, la commande de démarrage de la ressource est exécutée

immédiatement après la modification de l’état opérationnel à En ligne.

Par défaut, la commande de démarrage est exécutée de manière synchrone par

System Automation for Multiplatforms, ce qui signifie qu’System Automation for

Multiplatforms attend la fin de l’exécution de la commande et prend connaissance

de tout code retour éventuel.

Outre le délai d’attente de mise en ligne, chaque ressource possède un attribut

StartCommandTimeout. L’attribut StartCommandTimeout détermine le nombre

d’exécution maximum de la commande de démarrage. Si la commande de

démarrage ne répond pas au cours du délai d’attente StartCommandTimeout, elle

sera détruite par System Automation for Multiplatforms à l’aide de la commande

SIGKILL et un message est envoyé au journal système du noeud.

Des incidents peuvent toutefois se produire si un processus applicatif lancé dans le

délai StartCommandTimeout ne rend pas le contrôle à System Automation for

Multiplatforms. Dans ce cas, le processus applicatif est détruit chaque fois que le

délai d’attente StarCommandTimeout arrive à expiration, ce qui explique pourquoi

System Automation for Multiplatforms ne peut démarrer cette application en tant

que ressource. Pour corriger l’incident, vous devez dissocier le processus applicatif

de la commande de démarrage appelante en utilisant l’une des méthodes

suivantes :

v Rediriger tous les descripteurs de fichiers et démarrer le processus applicatif en

arrière-plan, par exemple :

/usr/bin/application >/outputfile 2>&1 &

v Créer une petite application d’encapsuleur qui utilise la fonction de langage C

’setsid()’ pour obtenir le détachement du processus applicatif de la commande

appelante de démarrage.

v Si les méthodes susmentionnées ne fonctionnent pas ou ne conviennent pas pour

une application donnée, la valeur de l'attribut RunCommandsSync de la

ressource doit être définie sur 0. Dans ce cas, System Automation for

Multiplatforms ne respecte pas l'attribut StartCommandTimeout de cette



ressource : la commande de démarrage et tous ses processus enfant demeureront

par conséquent pendant une période indéterminée sur ce noeud.

Remarque : si vous utilisez cette méthode, System Automation for

Multiplatforms n’attend pas le code retour de la commande de démarrage ; la

ressource ne bascule pas même si la commande de démarrage échoue. Si la

ressource n’est pas remise en ligne au cours du délai d’attente de mise en ligne,

System Automation for Multiplatforms exécute à nouveau la commande de

démarrage une fois le nombre de tentatives restant (RetryCount) expiré.

Problèmes liés à la commande de contrôle (Monitor)

System Automation for Multiplatforms utilise la commande de contrôle d’une

ressource IBM.Application afin de déterminer l’état opérationnel de cette ressource

sur un noeud. System Automation for Multiplatforms lance le contrôle d’une

ressource lorsqu’elle est ajoutée à un groupe de ressources ou un équivalent. La

ressource est contrôlée sur tout noeud sur lequel elle peut être exécutée, qui sont

les noeuds spécifiés dans l'attribut NodeNameList de la ressource.

Après une première exécution, la commande de contrôle est exécutée à la

fréquence définie dans l’attribut MonitorCommandPeriod. La ressource est

contrôlée indéfiniment sur chaque noeud sur lequel la ressource est définie jusqu’à

ce que la ressource soit supprimée du groupe de ressources ou équivalent.

A partir de la version 1.2 de System Automation for Multiplatforms, la commande

de contrôle est également exécutée immédiatement après l’exécution des

commandes de démarrage (Start) et d’arrêt (Stop) d’une ressource (uniquement

pour les commandes synchrones, si l’attribut RunCommandsSync de cette

ressource est défini sur la valeur par défaut, à savoir, 1). Cette nouveauté a été

introduite afin d’améliorer les performances de démarrage/d’arrêt d’un groupe de

ressources complet, car l’état opérationnel de la ressource est contrôlé

immédiatement après l’exécution des commandes de démarrage et d’arrêt. Après

l’exécution de la commande de contrôle, la fréquence de durée de la commande de

contrôle en secondes est à nouveau respectée, ce qui signifie que la prochaine

commande de contrôle sera exécutée après écoulement de la durée de la

commande de contrôle.

A compter de System Automation for Multiplatforms version 2.2, la valeur de

l’attribut MonitorCommandPeriod peut être inférieure à celle de l’attribut

MonitorCommandTimeout pour une ressource donnée. Cela est possible car

l’attribut MonitorCommandPeriod correspond en fait à la période comprise entre la

fin de la dernière exécution de la commande de contrôle et le début de la suivante.

L’attribut MonitorCommandTimeout peut donc désormais être spécifié

indépendamment de l’attribut MonitorCommandPeriod et de fréquentes exécutions

de la commande de contrôle peuvent ainsi être effectuées, même avec des scripts

de commande de contrôle dont l’exécution est longue. Il est cependant

recommandé de s’assurer que la commande de contrôle reste aussi efficace que

possible.

Vous devez garder à l’esprit deux problématiques liées à l’utilisation de la

commande de contrôle afin d’éviter des défaillances ou des comportements

inattendus :

1. La commande de contrôle est exécutée dans tous les noeuds sur lesquels la

ressource est autorisée à fonctionner. Si une ressource est censée être hors ligne

(la valeur de l’attribut NominalState du groupe de ressources est offline) et

qu’un opérateur démarre la ressource manuellement, System Automation for



Multiplatforms détecte cette opération grâce à la commande MonitorCommand

de la ressource et exécute la commande d’arrêt sur la ressource afin de la

mettre hors ligne.

Si vous devez mettre En ligne (ou Hors ligne) une seule ressource d’un groupe

de ressources afin, par exemple, d’effectuer une sauvegarde, vous devez utiliser

une requête de System Automation for Multiplatforms (la commande rgreq).

L’attribut NominalState du groupe de ressources est ainsi ignoré et vous

pouvez alors démarrer un membre du groupe de ressources, même si la valeur

de l’attribut NominalState de la ressource est offline.

2. Si une commande de contrôle en cours d’exécution ne se termine pas avant

l’expiration du délai d’attente de l’attribut MonitorCommandTimeout, System

Automation for Multiplatforms détruit la commande de contrôle à l’aide de la

commande SIGKILL, envoie un message au journal système du noeud et définit

l’état opérationnel de la ressource sur Inconnu. Par conséquent, cette ressource

et toutes les ressources dépendantes ne seront pas automatisées en l’absence

d’un état. Si ce message apparaît fréquemment dans le journal système, vérifiez

la valeur de l’attribut MonitorCommandTimeout et ajustez-la, si nécessaire.

Problèmes liés à la commande d’arrêt (StopCommand)

Par défaut, la commande de d’arrêt est exécutée de manière synchrone par System

Automation for Multiplatforms, ce qui signifie que System Automation for

Multiplatforms attend la fin de l’exécution de la commande et prend connaissance

de tout code retour éventuel. En outre, il existe un attribut StopCommandTimeout

pour chaque ressource qui détermine le temps d’exécution maximal de la

commande d’arrêt. Si la commande d’arrêt ne répond pas au cours du délai

d’expiration de la commande d’arrêt, elle sera détruite par System Automation for

Multiplatforms à l’aide de la commande SIGKILL. Si cette éventualité se produit,

un message est consigné dans le journal système de ce noeud.

Si la commande d’arrêt d’une ressource a été exécutée, mais que l’état opérationnel

de cette ressource ne devient pas Hors ligne avant la fin du délai d’attente de la

mise hors ligne, System Automation for Multiplatforms génère une opération de

réinitialisation sur la ressource. Le délai d’attente de la mise hors ligne (en

secondes) d’une ressource est calculé à l’aide de la formule suivante :

MAX(StopCommandTimeout, MonitorCommandPeriod, MonitorCommandTimeout) + 5

Notez que +5 n’est pas une valeur absolue car System Automation for

Multiplatforms n’utilise pas de véritable temporisateur. Les démons System

Automation for Multiplatforms sont réveillés plus fréquemment, d’où la valeur

supplémentaire, qui peut être comprise entre 5 et 8 secondes.

La génération d’une opération de réinitialisation sur une ressource se traduit par

une seconde exécution de la commande d’arrêt, mais cette fois, une variable

d’environnement spéciale (SA_RESET) a la valeur 1. Cela peut être exploité dans la

commande d’arrêt d’une ressource pour améliorer le comportement des arrêts

forcés. Par exemple :

#/bin/sh

# Exemple de script d’automatisation stop/reset pour l’application lpd

if [ $SA_RESET == 1 ]; then

killall -9 lpd

exit $?

else

/etc/init.d/lpd stop

exit $?

fi



Si vous ne souhaitez une autre exécution de la commande d’arrêt, le script peut

être fermé. Par exemple :

#/bin/sh



exit 0

else


exit $?

fi

Si la ressource ne s’arrête toujours pas après la seconde exécution de la commande

d’arrêt, l’état opérationnel de la ressource devient Arrêt en ligne, ce qui signifie

qu’une intervention manuelle est maintenant requis pour arrêter la ressource.

System Automation for Multiplatforms ne reprendra l’automatisation de la

ressource qu’une fois l’incident résolu par un opérateur.

Ce comportement apparaît dans IBM Tivoli System Automation for Multiplatforms,

version 2.2. Les scénarios concernés par la modification sont les suivants :

v Une commande d’arrêt échoue : dans la version 2.2 ou supérieure, une seconde

commande d’arrêt est émise

v Réinitialisation manuelle : une réinitialisation manuelle entraîne désormais

l’exécution d’une commande d’arrêt pour toutes les ressources indiquées. Si la

commande resetrsrc est exécutée sans que l’attribut NodeNameList soit défini

dans la chaîne de sélection, la commande d’arrêt sera exécutée sur toutes les

ressources. Si le nom de la ressource est indiqué dans la chaîne de sélection pour

une ressource flottante, la commande d’arrêt sera exécutée deux fois pour

chaque ressource, puisque la chaîne de sélection se compose de la ressource

d’ensemble et des ressources constitutives. Par conséquent, nous vous

recommandons d’indiquer l’attribut NodeNameList dans la chaîne de sélection

de la commande à chaque fois qu’une commande resetrsrc est exécutée.

v Gestion des états pendant le démarrage ou l’arrêt des ressources : pour plus

d’informations, voir Chapitre 7, «Traitement des informations système par

System Automation for Multiplatforms», à la page 93.

Réaction de System Automation for Multiplatforms aux

modifications éventuelles d’état opérationnel d’une ressource

en ligne sur un noeud

L’exemple de configuration suivant est utilisé dans les discussions de la prochaine

section :

Figure 3. Composition de l’exemple de configuration



La composition de l’exemple de configuration est la suivante :

v Une grappe à 2 noeuds

v Disque de départage

– Noeud node1 : Système de production.

– Noeud node2: Système de secours.v Groupe de ressources : RG1. avec

– Ressource flottante : Res1

– Ressource flottante : Res2

– Relation : Res1 Dépendant de Res2v Les ressources sont En ligne sur le noeud Node1.

La figure 4 illustre les transitions d’état opérationnel type des ressources

automatisées par System Automation for Multiplatforms :

Il existe sept états opérationnels (OpState) pour une ressource. L’état opérationnel

d’une ressource est déterminé par System Automation for Multiplatforms à l’aide

de la commande de contrôle. L’état courant d’une ressource est fourni par System

Automation for Multiplatforms à l’aide du code retour de la commande de

contrôle. Notez que le renvoi des valeurs d’état opérationnel En ligne et Hors ligne

à System Automation for Multiplatforms par une commande de contrôle suffit, les

autres valeurs d’état opérationnel qu’une ressource peut prendre peuvent être

exploitées de manière facultative.

Certaines valeurs d’état opérationnel telles que Inconnu ou Echec hors ligne

peuvent également être définies par System Automation for Multiplatforms. Par

exemple, l’état opérationnel Inconnu est défini pour une ressource si le délai

d’exécution de la commande de contrôle est arrivé à expiration. System

Automation for Multiplatforms ne connaît par conséquent plus l’état opérationnel

de cette ressource.

Figure 4. Transitions d’état opérationnel des ressources automatisées



Les deux tableaux suivants illustrent les réactions de System Automation for

Multiplatforms lors d’une modification d’état opérationnel des ressources Res1 et

Res2 de notre exemple. Notez que les tableaux de ce chapitre contiennent toutes les

valeurs d’état opérationnel possibles pour une ressource, même si un état

opérationnel donné n’a aucun sens dans cette situation. Les colonnes contenant ces

états opérationnels improbables sont précédées par le mot 'improbable' dans les

tableaux suivants.

Modification de l’état opérationnel de la ressource Res1

L’état actuel de Res1 et Res2 sur le noeud node1 est En ligne. Le tableau suivant

illustre les actions lancées par System Automation for Multiplatforms en fonction

de la valeur retour de la commande de contrôle de Res1.

Tableau 6. Actions d’automatisation de système en fonction des modifications d’état

opérationnel de la ressource Res1

Commande de

contrôle (état

opérationnel)

Première action

d’automatisation de système

Deuxième action


RC=0 (Inconnu) => Aucune, attendre la

prochaine commande de

contrôle avec RC<>0

Aucune

RC=1 (En ligne) => Aucune Aucune

RC=2 (Hors ligne) => Démarrer Res1 Aucune

RC=3 (Echec Hors

ligne)

=> Arrêter Res2 Après la mise hors ligne de

Res2, démarrer les deux

ressources sur le noeud

node2 dans le bon ordre

RC=4 (Arrêt en ligne) => Aucune : attendre action de

l’opérateur

Aucune

RC=5 (En attente en

ligne)

=> Improbable, attendre En

ligne

Aucune

RC=6 (En attente

hors ligne)

=> Attendre Hors ligne Aucune

Modification de l’état opérationnel de la ressource Res2

L’état actuel de Res1 et Res2 sur le noeud node1 est En ligne. Le tableau suivant

illustre les actions lancées par System Automation for Multiplatforms en fonction

de la valeur retour de la commande de contrôle de Res2.


opérationnel de la ressource Res2

Commande de

contrôle (état

opérationnel)

Première action


Deuxième action


RC=0 (Inconnu) => Aucune, attendre la

prochaine commande de

contrôle avec RC<>0

Aucune

RC=1 (En ligne) => Aucune Aucune

RC=2 (Hors ligne) => Procéder à l’arrêt forcé de

Res1

Après mise hors ligne de

Res1, démarrer Res2, après

mise en ligne de Res2 ->

démarrer Res1




opérationnel de la ressource Res2 (suite)

Commande de

contrôle (état

opérationnel)

Première action


Deuxième action


RC=3 (Echec Hors

ligne)

=> Procéder à l’arrêt forcé de

Res1

Démarrer les deux ressources

sur le noeud node2 dans le

bon ordre

RC=4 (Arrêt en ligne) => Aucune : attendre action de

l’opérateur

Aucune

RC=5 (En attente en

ligne)

=> Improbable, attendre En

ligne

Aucune

RC=6 (En attente

hors ligne)

=> Attendre Hors ligne Aucune

Composition de l’état opérationnel d’un groupe de ressources

par l’automatisation de système

IBM Tivoli System Automation for Multiplatforms est un produit d’automatisation

basé sur des règles. Le point de contrôle de l’automatisation est le niveau du

groupe de ressources, ce qui signifie qu’un opérateur démarre ou arrête

généralement un groupe de ressources entier au lieu de démarrer ou d’arrêter des

ressources seules. Cette opération est réalisée par la modification de l’attribut d’état

nominal (NominalState) d’un groupe de ressources par En ligne ou Hors ligne.

Immédiatement après la modification de l’attribut, System Automation for

Multiplatforms détermine les ressources à démarrer ou à arrêter, de manière à

respecter les règles modifiées.

L’attribut d’état opérationnel (OpState) d’un groupe de ressources regroupe les

attributs d’état opérationnel de toutes les ressources contenues dans un groupe par

rapport à la valeur d’état nominal de ce groupe de ressources. Aussi, si l’état

nominal d’un groupe de ressources a été modifié sur En ligne, l’état opérationnel

du groupe de ressources affiche ″En attente en ligne″ jusqu’à ce que toutes les

ressources du groupe soient En ligne. Enfin, si toutes les ressources de ce groupe

de ressources ont atteint la valeur de l’attribut d’état nominal (NominalState) du

groupe de ressources, l’état opérationnel du groupe de ressources sera modifié sur

En ligne, et cette valeur d’attribut d’état opérationnel du groupe pourra être

utilisée pour vérifier l’état des ressources de ce groupe.

Remarque : Les ressources membre peuvent posséder un état opérationnel

différent de celui de leur groupe si des requêtes ont été générées

directement sur elles. Pour plus d’informations, voir «Démarrage et

arrêt d’un groupe de ressources et de membres d’un groupe», à la

page 200.



Le tableau suivant montre comment System Automation for Multiplatforms

compose la valeur de l’attribut d’état opérationnel d’un groupe de ressources en

fonction de l’état opérationnel des deux ressources Res1 et Res2 de notre exemple.

Notez que cette représentation devient de plus en plus complexe en fonction du

nombre de ressources contenues dans un même groupe de ressources.

Tableau 8. Détermination de l’état opérationnel d’un groupe de ressources

Etat opérationnel de

Res2

Etat

opérationnel

de Res1

Etat opérationnel du


Action

d’automatisation de

système

Inconnu Inconnu => Inconnu Aucune

Hors ligne Hors ligne => Hors ligne Aucune

En attente en ligne Hors ligne => En attente en ligne Attendre jusqu’à ce

que Res2 soit En

ligne

En ligne Hors ligne => En attente en ligne Démarrer Res1

En ligne En attente en

ligne

=> En attente en ligne Attendre jusqu’à ce

que Res1 soit En

ligne

En ligne En ligne => En ligne Aucune

En ligne En attente hors

ligne

=> En attente hors ligne Attendre jusqu’à ce

que Res1 soit Hors

ligne

En ligne Echec hors

ligne

=> En attente hors ligne Arrêter Res2

En attente hors ligne Hors ligne => En attente hors ligne Attendre jusqu’à ce

que Res2 soit Hors

ligne

Echec hors ligne Hors ligne => Hors ligne Aucune

Réactions de l’automatisation de système aux modifications

d’état opérationnel d’une ressource démarrée ou arrêtée

System Automation for Multiplatforms automatise généralement les ressources en

fonction de l’état désiré du groupe de ressources et de la valeur d’état opérationnel

de la ressource. Le but est d’atteindre un état où l'état opérationnel et l’état

souhaité de la ressource sont identiques. En outre, System Automation for

Multiplatforms agit si l’état opérationnel d’une ressource change, par exemple, si

une ressource qui était en cours d’exécution est désormais contrôlée Hors ligne.

Un autre déclencheur d’actions d’automatisation est le code retour de la

commande de démarrage (Start). Si la commande de démarrage renvoie une erreur

(un code retour autre que 0) et que la ressource n’est pas contrôlée En ligne,

System Automation for Multiplatforms procède au basculement de la ressource

vers un autre noeud autorisé.



Les sections suivantes décrivent les actions effectuées par System Automation for

Multiplatforms si l’état opérationnel d’une ressource change pendant ou

rapidement après l’exécution des commandes de démarrage (Start) ou d’arrêt

(Stop) d’une ressource.

Les améliorations apportées dans System Automation for Multiplatforms V2R2

permettent une implémentation plus compatible de la commande de contrôle d'une

ressource. Cela est particulièrement important lorsque la commande de démarrage

d’une ressource est exécutée. A ce stade, System Automation for Multiplatforms

sait que l’état opérationnel de la ressource est En attente en ligne et cet état est

donc défini pour la ressource. Les seules exceptions sont les suivantes :

v l’état opérationnel signalé par la commande de contrôle devient En ligne (auquel

cas, l’objectif d’automatisation est atteint),

v l’état opérationnel signalé par la commande de contrôle devient Echec hors ligne

(ce qui prévient System Automation for Multiplatforms que la ressource est

endommagée et qu’elle ne peut pas être démarrée sur ce noeud avant

l’intervention manuelle d’un utilisateur).

De la même manière, cela s’applique à l’exécution de la commande d’arrêt, où

l’état opérationnel de la ressource devient En attente hors ligne pendant cette

période. Les exceptions possibles sont les suivantes :

v la commande de contrôle renvoie l’état Hors ligne ou Echec hors ligne (ce qui

indique que l’objectif de l’automatisation est déjà atteint),

v la commande de contrôle renvoie l’état Arrêt en ligne (ce qui indique qu’une

intervention manuelle est requise car la ressource ne peut pas être arrêtée par

System Automation for Multiplatforms).

Commande de démarrage (StartCommand)

Les tableaux suivants illustrent les réactions de System Automation for

Multiplatforms aux modifications d’état opérationnel lors de l’exécution de la

commande de démarrage. Il existe un tableau pour chacune des trois situations

possibles où la commande de contrôle fait état d’une modification de l’état

opérationnel :

1. La commande de démarrage est toujours en cours d’exécution (commande de

démarrage longue durée).

2. La commande de démarrage s’est achevée avec succès (situation normale).

3. La commande de démarrage s’est achevée avec une erreur ou a expiré.



La commande de démarrage est toujours en cours d’exécution :

Tableau 9. Actions d’automatisation de système et commande de démarrage toujours en

cours d’exécution

Commande de démarrage Commande de contrôle

Action d’automatisation de

système

Commande de démarrage

lancée mais pas terminée.

RC=0 (Inconnu) L’état opérationnel est En

attente en ligne, Attendre En

ligne

RC=1 (En ligne) Démarrer une autre

ressource, si elle existe

RC=2 (Hors ligne) L’état opérationnel est En


ligne

RC=3 (Echec Hors ligne) La ressource est basculée sur

un autre noeud ; d’autres

ressources dépendantes

peuvent également subir un

arrêt forcé

RC=4 (Arrêt en ligne) Improbable

L’état opérationnel est En


ligne

RC=5 (En attente en ligne) L’état opérationnel est En


ligne

RC=6 (En attente hors ligne) Improbable



ligne

Remarques :

1. Si la commande MonitorCommand indique que la ressource est en ligne,

System Automation for Multiplatforms ignore le code retour de la commande

de démarrage, car la mise en ligne de la ressource a déjà été réalisée.

2. Lorsque la commande de contrôle signale la ressource comme étant un Echec

hors ligne, un basculement est déclenché. Toutes les autres valeurs d’état

opérationnel sont mappées à En attente en ligne et System Automation attend

que l’état opérationnel devienne En ligne.



La commande de démarrage s’est achevée avec succès : Ce tableau décrit les

actions d’automatisation classiques effectuées lorsqu’une commande de démarrage

aboutit.

Tableau 10. Actions d’automatisation de système et commande de démarrage achevée

avec succès

Commande de démarrage Commande de contrôle


système

RC=0 (succès) et nombre de

tentatives actuel <

RetryCount (samctrl)

RC=0 (Inconnu) L’état opérationnel est

Inconnu tant que de

nouvelles informations ne

sont pas reçues

RC=1 (En ligne) L’état opérationnel est En

ligne. Le traitement de la

commande de démarrage est

considéré comme terminé.

RC=2 (Hors ligne) L’état opérationnel est En


ligneUn délai d’attente de mise en

ligne déclenche ces actions :

1. Une opération de

réinitialisation est

effectuée.

2. Si la réinitialisation

aboutit, une tentative de

démarrage est émise.

3. Le nombre de relances est

augmenté.

RC=3 (Echec Hors ligne) L’état opérationnel est Echec

Hors ligne. Le traitement de

la commande de démarrage

est considéré comme

terminé.

RC=4 (Arrêt en ligne) ImprobableL’état opérationnel est En


ligne

RC=5 (En attente en ligne) L’état opérationnel est En


ligne

RC=6 (En attente hors ligne) ImprobableL’état opérationnel est En


ligne

RC=0 (succès) et nombre de

tentatives actuel =

RetryCount (samctrl) après

expiration du délai d’attente

de mise en ligne

La ressource est sur Echec

Hors ligne, la commande

d’arrêt est émise au niveau

de la ressource, qui est

ensuite basculée sur un autre

noeud ; d’autres ressources

dépendantes peuvent

également subir un arrêt

forcé



La commande de démarrage s’est achevée avec une erreur ou a expiré : Le

tableau suivant décrit les actions d’automatisation classiques effectuées lorsqu'une

commande de démarrage renvoie une erreur ou expire, selon l’état opérationnel de

la ressource :

Tableau 11. Actions d’automatisation de système lorsque la commande de démarrage

s’achève avec une erreur ou expire

Commande de contrôle Commande de démarrage


système

RC=0 (Inconnu) RC=1 (autre que zéro)

échec ou expiration

Lorsque la commande de

démarrage renvoie 1, la

ressource est immédiatement

basculée sur un autre noeud. Le

code retour de la commande de

contrôle est ignoré.

RC=1 (En ligne) RC=1 (autre que zéro)

échec

Lorsque la commande de

contrôle renvoie 1 (En ligne), le

code retour de la commande de

démarrage est ignoré. Aucune

autre action n’est déclenchée. La

ressource reste En ligne.




s’achève avec une erreur ou expire (suite)



système

RC=1 (En ligne) La commande de

démarrage a expiré

Si la commande de contrôle

renvoie 1 (En ligne), un délai

d’attente de la commande de

démarrage ne déclenche ni

l’exécution d’une commande

d’arrêt ni d’une action

d’automatisation.

Toutefois, System Automation

détruit la commande de

démarrage lorsqu’elle expire, ce

qui peut également entraîner la

destruction du processus des

ressources proprement dit s’il ne

peut pas être détaché du script

de la commande de démarrage à

cet instant. Si cela se produit,

l’état opérationnel de la

ressource passe à nouveau à

Hors ligne. Dès que la

commande de contrôle détecte

que la ressource est Hors ligne,

System Automation redémarre la

ressource sur le même noeud.

Ce comportement peut

engendrer une boucle si la

commande de démarrage aboutit

à une expiration. Dans ce cas, le

nombre de relances (RetryCount)

n’a aucun effet, car le compteur

interne est réinitialisé lorsque

l’état opérationnel de la

ressource passe à En ligne.

Astuce : la boucle est

généralement due à une erreur

de la commande de démarrage.

Toutefois, une boucle peut être

évitée si la commande de

contrôle de la ressource renvoie

Echec Hors ligne, au cas où le

processus applicatif serait détruit

de manière inattendue. Dans ce

cas, un contrôle se produit et la

ressource est démarrée sur un

autre noeud

Pour plus d’informations sur la

manière dont la commande de

démarrage d’une ressource

IBM.Application est traitée, voir

«Utilisation du Global Resource

Manager (gestionnaire de

ressources globales)», à la page

233.




s’achève avec une erreur ou expire (suite)



système

RC=2 (Hors ligne) RC=1 (autre que zéro)


Immédiatement après renvoi de

RC=1 par la commande de

démarrage, System Automation

for Multiplatforms arrête la

ressource et un basculement a

lieu.

Si la commande de démarrage a

dépassé le délai d’attente, son

traitement est arrêté à l’aide de

killpg() (voir aussi «Utilisation

du Global Resource Manager

(gestionnaire de ressources

globales)», à la page 233).

RC=3 (Echec Hors ligne) RC=1 (autre que zéro)


Si une commande de contrôle a

déjà renvoyé 3 (Echec hors

ligne), une remise en ligne a lieu

et l’exécution de la commande

de démarrage qui a échoué n’a

aucun effet supplémentaire.

RC=4 (Arrêt en ligne) RC=1 (autre que zéro)


Improbable, immédiatement

après renvoi de RC=1 par la

commande de démarrage,

System Automation for

Multiplatforms arrête la

ressource et attend une action de

l’opérateur

RC=5 (En attente en ligne) RC=1 (autre que zéro)


Immédiatement après renvoi de

RC=1 par la commande de

démarrage, System Automation

for Multiplatforms arrête la


lieu lorsque la ressource est

déclarée Hors ligne.

RC=6 (En attente hors

ligne)

RC=1 (autre que zéro)


Improbable, immédiatement

après renvoi de RC=1 par la

commande de démarrage,


Multiplatforms arrête la


lieu lorsque la ressource est

déclarée Hors ligne.

Remarque : Lorsque la commande de contrôle signale la ressource comme étant En

ligne, le code retour de la commande de démarrage est ignoré. Les

résultats des deux commandes sont alors incohérents :

v La commande de démarrage indique que le démarrage de la

ressource a échoué

v La commande de contrôle signale la ressource comme étant En

ligne.



Commande d’arrêt (StopCommand)

Les tableaux de cette section illustrent les réactions de System Automation for

Multiplatforms aux modifications d’état opérationnel lors de l’exécution de la

commande d’arrêt. La commande d’arrêt renvoie à l’arrêt et à la réinitialisation des

méthodes d’automatisation de système, ce qui signifie dans les deux cas que la

commande d’arrêt est exécutée. De même, les deux valeurs de délai d’attente,

StopCommandTimeout et ResetCommandTimeout, renvoient à la même valeur de

délai d’attente.

Il existe un tableau pour chacune des trois situations où la commande de contrôle

fait état d’une modification de l’état opérationnel :

1. La commande d’arrêt est toujours en cours d’exécution (commande d’arrêt

longue durée).

2. La commande d’arrêt s’est achevée avec succès (situation normale).

3. La commande d’arrêt s’est achevée avec une erreur ou a expiré.

La commande d’arrêt est toujours en cours d’exécution :

Tableau 12. Actions d’automatisation de système et commande d’arrêt toujours en cours

d’exécution

Commande d’arrêt Commande de contrôle


système

Commande d’arrêt lancée

mais pas terminée.


attente hors ligne, Attendre

Hors ligne



Hors ligne

RC=2 (Hors ligne) Poursuivre l’arrêt des autres

ressources

RC=3 (Echec Hors ligne) Poursuivre l’arrêt des autres

ressources

RC=4 (Arrêt en ligne) Attendre action de

l’opérateur

RC=5 (En attente en ligne) ImprobableL’état opérationnel est En


Hors ligne

RC=6 (En attente hors ligne) L’état opérationnel est En


Hors ligne

Une fois que la commande MonitorCommand a indiqué que l’état de la ressource

est Hors ligne ou Echec hors ligne, System Automation for Multiplatforms ignore

le code retour de la commande d’arrêt, car la mise hors ligne de la ressource a déjà

été réalisée.

Si l’état opérationnel de la ressource apparaît comme Arrêt en ligne, System

Automation for Multiplatforms attend l’intervention d’un opérateur, car la

ressource ne peut pas être arrêtée. Toutes les autres valeurs d’état opérationnel sont

mappées à En attente hors ligne et System Automation for Multiplatforms attend

que l’état opérationnel devienne Hors ligne.



La commande d’arrêt s’est achevée avec succès : Ce tableau décrit le

comportement habituel de System Automation for Multiplatforms :

Tableau 13. Actions d’automatisation de système et commande d’arrêt achevée avec

succès

Commande d’arrêt Commande de contrôle


système

RC=0 (Succès)

et

( (Le délai d’attente de mise

hors ligne n’est pas atteint)

ou

(commande de

réinitialisation envoyée sur la

ressource et délai

d’expiration de la

réinitialisation non atteint)



Hors ligne



Hors ligne

RC=2 (Hors ligne) L’état opérationnel est Hors

ligne. Le traitement de la

commande d’arrêt est


RC=3 (Echec Hors ligne) L’état opérationnel est Echec

Hors ligne. Le traitement de

la commande d’arrêt est


RC=4 (Arrêt en ligne) L’état opérationnel est Arrêt

en ligne. Le traitement de la

commande d’arrêt est

considéré comme terminé,

Attendre action de

l’opérateur.

RC=5 (En attente en ligne) ImprobableL’état opérationnel est En


Hors ligne

RC=6 (En attente hors ligne) L’état opérationnel est En


Hors ligne

RC=0

(succès)

et

après le délai de mise hors

ligne


attente hors ligne ;

commande de réinitialisation

envoyée sur la ressource

RC=0

(succès)

et

après le délai de

réinitialisation

L’état opérationnel est Arrêt

en ligne, Attendre action de

l’opérateur

La commande d’arrêt s’est achevée avec une erreur ou a expiré : Le tableau

ci-dessous répertorie les actions d’automatisation qui surviennent lorsqu’une

commande d’arrêt s’achève avec une erreur ou expire. Les actions diffèrent si la

commande d’arrêt est appelée pour une opération d’arrêt ou pour une opération

de réinitialisation.



Tableau 14. Actions d’automatisation de système lorsque la commande d’arrêt s’achève

avec une erreur ou expire

Commande d’arrêt Commande de contrôle Actions d’automatisation

RC=1

(autre que zéro ; échec ou

expiration)et

( (Le délai d’attente de mise

hors ligne n’est pas atteint)

ou

(commande de

réinitialisation envoyée sur la

ressource et délai

d’expiration de la

réinitialisation non atteint)

RC=0 (Inconnu) Envoyer l’ordre de

réinitialisation

immédiatement

RC=1 (En ligne) Envoyer l’ordre de

réinitialisation

immédiatement.

RC=2 (Hors ligne) Poursuivre l’arrêt des autres

ressources

RC=3 (Echec Hors ligne) Poursuivre l’arrêt des autres

ressources

RC=4 (Arrêt en ligne) Envoyer l’ordre de

réinitialisation

immédiatement

RC=5 (En attente en ligne) Envoyer l’ordre de

réinitialisation

immédiatement

RC=6 (En attente hors ligne) Envoyer l’ordre de

réinitialisation

immédiatement

RC=1

(échec)

et

après le délai de mise hors

ligne


attente hors ligne ;

commande de réinitialisation

envoyée sur la ressource

RC=1

(échec)

et

après le délai de

réinitialisation

L’état opérationnel est Arrêt

en ligne, Attendre action de

l’opérateur

Remarques :

1. L’état opérationnel de la ressource devient En attente hors ligne en attendant

de passer à Hors ligne, Echec hors ligne ou Arrêt en ligne. Si l’état opérationnel

ne devient pas Hors ligne ou Echec hors ligne avant la fin du délai d’attente de

la mise hors ligne, System Automation for Multiplatforms génère une opération

de réinitialisation sur la ressource, ce qui déclenche une exécution de la

commande d’arrêt. Si l’état opérationnel ne devient toujours pas Hors ligne,

Echec hors ligne ou Arrêt hors ligne avant la fin du délai d’attente de la

réinitialisation, la ressource passe finalement à l’état Arrêt en ligne pour

indiquer qu’un opérateur doit arrêter la ressource. Si le code retour de la

commande d’arrêt ou de l’opération de réinitialisation est différent de 0 (zéro),

la ressource sera interrompue et placée à l’état d’automatisation Problème, qui

nécessite une intervention manuelle. Pour résoudre le problème, il est

nécessaire de réinitialiser la ressource à l’aide de la commande resetrsrc. Il faut

cependant que le code retour de cette opération de réinitialisation soit 0 (zéro),

car dans le cas contraire, la ressource restera à l’état d’automatisation Problème.

2. Si l’ordre était une réinitialisation, la ressource passe à l’état Arrêt en ligne, au

lieu d’envoyer un ordre de réinitialisation.



Réactions de l’automatisation de système lorsqu’une

ressource est en ligne dans un noeud donné et que la

commande de contrôle déclare simultanément un état

opérationnel pour la ressource dans un autre noeud

Le tableau suivant montre les actions effectuées par System Automation for

Multiplatforms si une ressource est en ligne dans un noeud et que la commande

de contrôle déclare un état opérationnel spécifique pour la ressource dans un autre

noeud.

Tableau 15. Actions d’automatisation de système lorsque la commande de contrôle déclare

une modification d’état opérationnel pour la ressource dans un autre noeud

Commande de contrôle sur un noeud de

secours

Actions d’automatisation de système

RC=0 (Inconnu) Aucune action d’automatisation possible

pour cette ressource avant que la commande

de contrôle ne renvoie le code retour RC<>0.

RC=1 (En ligne) 1. Les ressources dans les deux noeuds sont

arrêtées.

Cette opération concerne les ressources

suivantes, qui sont arrêtées également :

v les ressources dépendantes qui sont

liées par des relations dependsOn ou

forcedDownBy

v les autres membres de groupes

Pour déterminer quelles ressources

seront arrêtées, il convient d’examiner la

portée de l’exécution du classeur : toutes

les ressources liées par des relations, y

compris par des relations d’appartenance

à un même groupe, seront arrêtées (voir

«Définition de la relation

d’emplacement : algorithme de liaison»,

à la page 93).

2. Les ressources sont ensuite redémarrées

sur l’un des noeuds.

RC=2 (Hors ligne) Aucune action, il s’agit de l’état opérationnel

habituel de la ressource sur un noeud de

secours.

RC=3 (Echec Hors ligne) Aucune action, mais plus aucun

basculement ne peut avoir lieu vers ce

noeud.

RC=4 (Arrêt en ligne) Improbable, erreur de script (requiert

d’abord l’état opérationnel En ligne ...)

RC=5 (En attente en ligne) Identique à En ligne

RC=6 (En attente hors ligne) Improbable, erreur de script (requiert

d’abord l’état opérationnel En ligne ...)



La remarque la plus importante est qu’System Automation for Multiplatforms

arrêtera la ressource dans les deux noeuds si elle est déclarée En ligne dans plus

d’un noeud à la fois, au lieu d’arrêter uniquement la ressource dans le noeud de

secours. Cette remarque implique également que toutes les ressources ayant une

dépendance avec cette ressource peuvent également être arrêtées. Par exemple,

toutes les ressources possédant une relation Dépendant de (DependsOn) avec cette

ressource seront également arrêtées. Nous vous recommandons par conséquent de

ne pas démarrer ou arrêter des applications ou des ressources contrôlées par


Cycle d’état d’un groupe de ressources

figure 5 indique les transitions d’état qui se produisent lorsque System Automation

lance et arrête un groupe de ressource.

Au début du cycle (�1�), l’état DesiredState du groupe de ressources est hors ligne,

son état ObservedState est hors ligne et les membres du groupe de ressources ne

sont pas liés. Ainsi, l’état BindingState n’est pas lié.

Si l’état NominalState du groupe de ressources devient en ligne (�2�), l’état

DesiredState du groupe de ressources devient également en ligne. L’état

BindingState est toujours non lié (�3�).

Figure 5. Cycle d’état d’un groupe de ressources



Lors de l’étape de liaison (�4�), le classeur essaie de trouver, pour tous les

membres du groupe de ressources, une position qui satisfasse toutes les

dépendances définies dans la règle d’automatisation. Si l’étape de liaison réussit,

l’état BindingState du groupe de ressources devient Lié (�5�). Autrement, l’état

BindingState du groupe de ressources devient Sacrificed et les ressources ne sont

pas lancées.

Lorsque tous les membres des groupes de ressources sont liés, System Automation

sait sur quel noeud les lancer. Le module logique envoie les ordres de lancement

pour les membres du groupe de ressources (�6�) et s’assure que toutes les

dépendances définie dans la règle d’automatisation sont satisfaites. Pendant que les

ressources sont lancées, l’état ObservedState du groupe de ressources devient En

attente en ligne (�7�).

Lorsque toutes les ressources sont en ligne, l’état ObservedState du groupe de

ressources devient En ligne (�8�).

Lorsque l’état NominalState du groupe de ressources devient Hors ligne (�9�),

l’état DesiredState du groupe de ressources devient Hors ligne (�10�). Cela conduit

System Automation à arrêter tous les membres du groupe de ressources. Le

module logique envoie des ordres d’arrêt pour les ressources (�11�) et s’assure que

toutes les dépendances définies dans la règle d’automatisation sont satisfaites.

Lorsque les ressources sont arrêtées, l’état ObservedState devient En attente hors

ligne (�12�). Lorsque toutes les ressources sont hors ligne, l’état ObservedState du

groupe de ressources devient Hors ligne (�13�).

Lors de l’étape d’annulation de la liaison (�14�), la position du noeud des membres

du groupe de ressources est supprimée des tables internes et l’état BindingState du

groupe de ressources devient Non lié (�1�).



Chapitre 8. Utilisation d’Integrated Solutions Console

Ce chapitre décrit les tâches que vous pouvez accomplir dans la console

d’opérations SA et l’éditeur de règles, ainsi que les autres tâches et applications

System Automation disponibles dans Integrated Solutions Console.

Octroi d’autorisations aux utilisateurs pour l’accomplissement de

tâches System Automation à partir d’Integrated Solutions Console

La tâche d’installation crée un utilisateur autorisé (ID utilisateur par défaut :

eezadmin). Celui-ci est autorisé à accomplir des tâches System Automation for

Multiplatforms à partir d’Integrated Solutions Console. Pour octroyer des

autorisations à d’autres utilisateurs, vous devez affecter les ID utilisateur dont ils

disposent dans le domaine d’automatisation à des groupes d’utilisateurs System

Automation for Multiplatforms spécifiques, qui ont été créés et affectés à des rôles

d’accès System Automation for Multiplatforms spécifiques au cours de l’installation

de la console d’opérations SA. Sachez que les ID utilisateur du domaine

d’automatisation doivent être des chaînes alphanumériques contenant des

caractères issus du jeu de codes local.

Les utilisateurs de la console d’opérations peuvent stocker et modifier leurs

données d’identification pour les domaines dans le coffre d’accréditation

d’Integrated Solutions Console (reportez-vous à la rubrique «Gestion de vos

données d’identification utilisateur», à la page 144 pour obtenir des informations

supplémentaires).

Création d’utilisateurs et octroi d’autorisations leur permettant

de travailler avec System Automation for Multiplatforms à

partir d’Integrated Solutions Console

Les ID et groupes d’utilisateurs sont créés lors de l’installation de la console

d’opérations SA. Les groupes d’utilisateurs sont associés aux rôles utilisateur

correspondant.

Le rôle administratif WebSphere supressmonitor détermine si vous pouvez accéder

aux tâches d’administration spécifiques WebSphere depuis Integrated Solutions

Console. Si ce rôle vous est uniquement attribué (sans aucun autre rôle vous

accordant des droits d’accès aux tâches administratives WebSphere), les tâches

administratives WebSphere sont supprimées de l’interface utilisateur.

Groupes

ID utilisateur par défaut (créés lors

de l’installation) Rôles

EEZAdministratorGroup eezadmin EEZAdministrator,suppressmonitor

EEZOperatorGroup EEZOperator,suppressmonitor

EEZConfiguratorGroup EEZConfigurator,suppressmonitor

EEZMonitorGroup EEZMonitorGroup,suppressmonitor

Pour obtenir des informations détaillées sur la méthode de création et

d’autorisation des utilisateurs dans Integrated Solutions Console, consultez la

documentation Websphere Application Server.


Rôles d’accès pour System Automation for Multiplatforms

Le tableau 16 décrit les rôles d’accès déterminant les tâches System Automation for

Multiplatforms auxquelles un utilisateur peut accéder dans Integrated Solutions

Console.

Les rôles d’accès sont créés lors de l’installation de la console d’opérations SA et

attribués aux groupes d’utilisateurs repris dans la colonne de droite du tableau.

Pour attribuer des rôles d’accès à des utilisateurs individuels, vous devez attribuer

les ID utilisateur aux groupes d’utilisateurs correspondant.

Les rôles d’accès EEZ* autorisent uniquement les utilisateurs à accéder aux tâches

System Automation for Multiplatforms et à les utiliser. Les autres tâches de la

console d’administration sont disponibles uniquement pour les utilisateurs ayant le

rôle d’accès administrateur pour Websphere Application Server.

Tableau 16. Rôles d’accès de System Automation for Multiplatforms

Rôle Autorisations Nom de groupe

EEZMonitor Accorde des droits d’accès minimums. Les utilisateurs

ayant ce rôle peuvent exécuter des opérations de type

Demande mais ne peuvent pas activer et désactiver

les règles d’automatisation ni exécuter des actions qui

modifient l’état des ressources ; par exemple, ils ne

peuvent pas soumettre de demandes de démarrage.

Dans l’arborescence de navigation, les tâches

disponibles pour les utilisateurs EEZMonitor sont les

suivantes :

v Console d’opérations SA

v Accréditations de domaine stockées

EEZMonitorGroup

EEZOperator Outre les droits accordés par le rôle EEZMonitor, les

utilisateurs ayant ce rôle ont la possibilité d’émettre

des demandes sur les ressources. Le rôle n’autorise

pas les utilisateurs à effectuer des tâches qui

modifient la configuration, telles que l’activation et la

désactivation de règles.


disponibles pour les utilisateurs EEZOperator sont les

suivantes :



EEZOperatorGroup


Tableau 16. Rôles d’accès de System Automation for Multiplatforms (suite)

Rôle Autorisations Nom de groupe

EEZConfigurator Outre les droits accordés par le rôle EEZMonitor, les

utilisateurs ayant ce rôle ont la possibilité d’exécuter

des tâches qui modifient la configuration, telles que

l’activation et la désactivation de règles.

Les utilisateurs ayant uniquement ce rôle ne peuvent

pas soumettre de demandes sur les ressources. Le

rôle est obligatoire pour pouvoir gérer les règles

d’administration.


disponibles pour les utilisateurs EEZConfigurator




v Activation d’une règle d’automatisation

v Désactivation de la règle d’automatisation active

EEZConfiguratorGroup

EEZAdministrator Etend les rôles EEZOperator et EEZConfigurator,

accordant des droits d’accès maximums.

Les utilisateurs ayant ce rôle ont la possibilité

d’effectuer toutes les opérations disponibles sur la

console d’opérations SA.


disponibles pour les utilisateurs EEZAdministrator



v Activation d’une règle d’automatisation

v Désactivation de la règle d’automatisation active


v Configuration du contexte de lancement du portail

Tivoli Enterprise

v Modifier une règle existante

v Créer une nouvelle règle

v Parcourir le pool de règles

EEZAdministratorGroup

Configuration de votre navigateur Web pour Integrated Solutions

Console

Les navigateurs Web suivants sont pris en charge à partir des versions indiquées :

v Microsoft Internet Explorer V6.0 SP1

v Mozilla V1.7.8

v Firefox 1.5

Pour afficher Integrated Solutions Console dans votre navigateur Web, vous

devez :

v Activer JavaScript dans tous les navigateurs Web.

v Pour Microsoft Internet Explorer, vous devez :

– définir le niveau de sécurité sur Moyen.

Chapitre 8. Utilisation d’Integrated Solutions Console 121

Ne définissez pas un niveau de sécurité sur "Elevé". Si vous devez définir un

niveau de sécurité élevé, veillez à activer l’entrée Contrôles ActiveX et

plug-ins - Contrôles d’initialisation et de script ActiveX non marqués

comme sécurisés dans la page des paramètres. Autrement, les informations

affichées dans la console ne sont pas mises à jour automatiquement.

– affectez à Script - Active Scripting la valeur Activer dans la page des

paramètres de sécurité. Autrement, vous risqueriez de rencontrer des

incidents de navigation.

Connexion à Integrated Solutions Console

Pour accéder à Integrated Solutions Console, suivez la procédure ci-dessous :

1. Ouvrez une fenêtre du navigateur Web et tapez l’adresse de la console

Integrated Solutions Console dans la barre d’Adresse.

L’entrée doit se présenter sous cette forme :

http://<hostname>:<port>/ibm/console

où <hostname> désigne le nom de l’hôte sur lequel est exécuté le Integrated

Solutions Console et <port> désigne le numéro de port de Integrated Solutions

Console. Le port pas défaut est 9060.

2. Attendez que la console soit chargée dans le navigateur. Une page de

connexion s’affiche après le démarrage de la console.

3. Entrez votre ID utilisateur et votre mot de passe, puis cliquez sur Connexion.

L’interface utilisateur de Integrated Solutions Console s’ouvre.

Une fois connecté, veillez à utiliser le lien de Déconnexion situé dans la barre

d’outils de la console quand vous avez terminé d’utiliser la console afin

d’éviter tout accès non autorisé. En cas de période d’inactivité prolongée au

cours de cette session de connexion, la session expire et vous devez vous

connecter de nouveau pour accéder à la console.

Si l’ID utilisateur que vous avez fourni est déjà connecté sur un emplacement

différent, vous devez choisir entre vous déconnecter de cet autre endroit ou

revenir à la page de connexion.

Il est recommandé de ne pas utiliser simultanément plusieurs fenêtres de

navigateur sur le même système client pour se connecter à la même console

Integrated Solutions Console car les types de navigateur autres que Microsoft

Internet Explorer partageront une même session HTTP entre plusieurs instances

de navigateur si ces instances sont exécutées sur le même système et qu’elles se

connectent à la même console Integrated Solutions Console. L’utilisation de

plusieurs instances de navigateur à l’aide de la même session HTTP entraîne

des résultats inattendus.

Le même cas se produit si vous ouvrez plusieurs fenêtres de navigateur

Microsoft Internet Explorer en sélectionnant Fichier > Nouveau Fenêtre (ou en

appuyant sur Ctrl+N) à partir d’une session Integrated Solutions Console

existante. En effet, la nouvelle fenêtre de navigateur et celle à partir de laquelle

elle a été ouverte partagent alors la même session.

Disposition du Integrated Solutions Console

Cette rubrique offre un aperçu de la disposition de l’interface utilisateur du

Integrated Solutions Console. Pour plus d’informations sur l’utilisation de

l’interface utilisateur, consultez l’Integrated Solutions Consoleaide en ligne, qui est

accessible via le lien Aide situé sur la barre d’outils de la console.


Bannière

Affiche une image commune sur toutes les installations du Integrated

Solutions Console. La bannière comporte un message d’accueil pour

l’utilisateur qui se connecte et des liens pour se déconnecter de la console

et ouvrir la rubrique d’aide.

Arborescence de navigation

Répertorie les tâches disponibles dans la console. Les tâches sont groupées

dans des noeuds organisationnels qui représentent des catégories de tâches.

Les noeuds organisationnels peuvent être imbriqués dans plusieurs

niveaux. Les tâches qui sont présentées varient selon votre rôle utilisateur

et vos paramètres de Vue courants. Quand vous cliquez sur une tâche dans

l’arborescence de navigation, une page s’ouvre dans la zone de travail

contenant un ou plusieurs modules permettant d’effectuer la tâche.

Utilisez la liste de sélection Vue en haut de l’arborescence de navigation

pour modifier la liste des tâches selon vos préférences. Vous pouvez

organiser les tâches comme suit :

Toutes les tâches

Cette option permet d’afficher l’ensemble des tâches de la console.

Les tâches sont regroupées dans des noeuds organisationnels. Les

tâches qui sont spécifiques à System Automation for

Multiplatforms sont disponibles sous le noeud IBM Tivoli System


Mes tâches

Cette option permet d’afficher uniquement les tâches que vous

avez ajoutées à la vue. Au départ, cette liste est vide, mais elle

offre un lien vers la page Mes tâches. Depuis cette page Mes

tâches, vous pouvez ajouter ou supprimer des éléments de la liste

Mes tâches de l’arborescence de navigation. Pour des informations

détaillées sur l’utilisation de Mes tâches, consultez la rubrique

d’aide de la console.

Sélection de produit

L’option de sélection d’un nom de produit permet d’afficher

uniquement les tâches d’un produit particulier, par exemple, IBM

Tivoli System Automation for Multiplatforms.

Zone de travail

Quand vous lancez une page, le contenu de cette page s’affiche dans la

zone de travail. Si vous n’avez lancé aucune page, la page d’accueil du

Integrated Solutions Console s’ouvre dans la zone de travail. Elle affiche

les produits installés qui utilisent Integrated Solutions Console comme

interface utilisateur courant. Vous pouvez ouvrir la page d’accueil pour

IBM Tivoli System Automation for Multiplatforms en cliquant sur le nom

du produit dans la liste.

Tâches System Automation for Multiplatforms dans l’arborescence de

navigation

Les tâches affichées dans l’arborescence de navigation dépendent de votre rôle

utilisateur System Automation for Multiplatforms et de vos paramètres Vue

actuels. Si vous n’avez pas personnalisé la liste des tâches de la Vue, développez

l’entrée IBM Tivoli System Automation for Multiplatforms de l’arborescence de


navigation pour afficher la liste des tâches spécifiques au produit auxquelles vous

avez accès. La liste suivante offre un aperçu de l’ensemble des tâches Tivoli System

Automation disponibles.

Accueil

Ouvre la page d’accueil de Tivoli System Automation. Pour ouvrir cette

page, vous pouvez également cliquer sur le lien IBM Tivoli System

Automation for Multiplatforms de la page d’accueil de Integrated

Solutions Console.

Console d’opérations SA

Ouvre la console d’opérations SA dans la zone de travail. La console

d’opérations SA permet de gérer et de contrôler les ressources automatisées

et d’effectuer des tâches administratives, dont certaines sont également

disponibles depuis l’arborescence de navigation (par exemple, l’activation

et la désactivation de règles des domaines d’automatisation qui prennent

en charge ces tâches).

Tâches opérationnelles

Le noeud contient les tâches suivantes :

Activation d’une règle d’automatisation

Permet d’activer les règles d’automatisation pour les domaines

d’automatisation qui prennent en charge l’activation de la règle.

Vous pouvez également effectuer cette tâche à partir de la console

d’opérations SA.

Désactivation de la règle d’automatisation active

Permet de désactiver la règle d’automatisation actuellement active

pour les domaines d’automatisation qui prennent en charge la

désactivation de la règle. Vous pouvez également effectuer cette

tâche à partir de la console d’opérations SA.

Paramètres

Le noeud contient les tâches suivantes :

Accréditations de domaine stockées

Cette tâche permet d’administrer les données d’identification

utilisateur pour les domaines d’automatisation de premier niveau

auxquels vous avez accès. Les données d’identification utilisateur

d’un domaine d’automatisation sont enregistrées dans le coffre

d’accréditation lors de votre premier accès au domaine.

Configuration du contexte de lancement du portail Tivoli Enterprise

Si vous utilisez à la fois la console d’opérations SA et le portail

Tivoli Enterprise pour la gestion et le contrôle des ressources, cette

tâche permet de configurer la prise en charge du contexte de

lancement pour le portail Tivoli Enterprise. Le contexte de

lancement permet aux utilisateurs de lancer des espaces de travail

du portail Tivoli Enterprise depuis la console d’opérations SA en

un seul clic de souris. La configuration de la fonction de contexte

de démarrage est décrite dans le Guide d’installation et de

configuration d’IBM Tivoli System Automation for Multiplatforms ainsi

que dans l’aide en ligne de la console d’opérations SA.

Gestion de règles

Permet de créer et d’enregistrer de nouvelles règles à l’aide d’une interface

graphique. Vous pouvez également naviguer au sein des règles existantes,

charger des règles pour les modifier, renommer et supprimer des règles.


Lorsque vous sélectionnez une des tâches suivantes, une nouvelle page

d’onglet s’ouvre dans la zone de travail d’Integrated Solutions Console :

Modifier une règle existante

Charge une règle existante dans l’éditeur de règles, où elle peut

être modifiée et enregistrée. Vous pouvez charger la règle active à

partir d’un domaine d’automatisation connecté, sélectionner une

règle stockée dans le pool de règles d’un domaine ou sélectionner

une règle enregistrée sur le système de fichier local. Pendant le

chargement de la règle, l’application recherche les erreurs de

sémantique et de syntaxe.

Créer une nouvelle règle

Permet de créer une règle. Une fois la règle créée, vous pouvez

l’enregistrer dans le pool de règles d’un domaine d’automatisation

connecté ou dans le système de fichiers local.

Parcourir les règles du pool de règles

Permet de gérer les règles stockées dans les pools de règles. Une

fois que vous avez exploré le pool de règles d’un domaine

d’automatisation connecté, vous pouvez modifier, renommer ou

supprimer les règles affichées.


Utilisation de la console d’opérations SA

Cette section présente la console d’opérations SA.

Remarque : La console d’opérations n’est pas disponible dans l’environnement

Solaris. Cependant, une console d’opérations installée sur un autre

système d’exploitation peut être utilisée pour gérer les domaines

Solaris.

Présentation de la console d’opérations SA

La console d’opérations SA est une interface graphique de type navigateur affichée

dans IBM Integrated Solutions Console (ISC).

La figure suivante affiche la configuration de la console d’opérations SA pour les

utilisateurs de System Automation for Multiplatforms et les utilisateurs d’IBM

Tivoli System Automation Application Manager.

System Automation for Multiplatforms concerne la partie gauche de la figure, qui

montre comment la console d’opérations est utilisée en mode d’accès direct, sans la

partie d’automatisation de bout en bout, pour laquelle l’application IBM Tivoli

System Automation Application Manager est requise. Mode d’accès direct signifie

que vous ne pouvez commander et gérer que les domaines contrôlés par IBM

Tivoli System Automation for Multiplatforms. System Automation Application

Manager offre deux modes : le mode d’automatisation de bout en bout et le mode

d’automatisation de premier niveau. Ces deux modes sont décrits dans le Guide

d'administration et d'utilisation d’IBM Tivoli System Automation Application Manager.

Figure 6. Présentation de la console d’opérations


Les domaines d’IBM Tivoli System Automation for Multiplatforms peuvent être

soit contrôlés par la console d’opérations (comme décrit dans la partie de gauche

de la figure) ou par la gestion d’automatisation de bout en bout (comme illustré

dans la partie de droite de la figure). Toutefois, ils ne peuvent pas être contrôlés

simultanément.

Présentation des couches de la console d’opérations SA

L’écran principal de la console d’opérations se compose de plusieurs zones :

�1� Barre de menus

Utilisez les entrées du menu disponible dans la barre de menus pour

mettre à jour les informations affichées dans l’arborescence des topologies

et l’arborescence des ressources, modifier vos préférences utilisateur et

afficher des informations sur la version de console d’opérations que vous

utilisez.

�2� Barre de titre

Utilisez les commandes de la barre de titre pour afficher la page d’aide en

ligne de la fenêtre que vous ouvrez et pour développer et réduire la

fenêtre.

Barre d’information

La barre d’information n’est pas illustrée dans la figure ci-après. Elle est

affichée sous la barre de menus lorsque vous avez effectué une action sur

un élément de la console d’opérations. Elle affiche un message confirmant

que la demande ou la commande a été soumise pour traitement. Le

message de la barre d’information ne confirme que l’action initiale ; il n’est

pas mis à jour pendant le traitement de la commande ou de la demande.

Les résultats des actions système effectuées suite à la demande ou la

commande sont reflétés dans la console d’opérations. Vous pouvez par

exemple y consulter l’état d’une ressource modifiée.

Figure 7. Ecran principal de la console d’opérations


Le message de confirmation est remplacé par un nouveau message chaque

fois que vous effectuez une action sur un élément de la console

d’opérations. Si vous cliquez sur Effacer dans la barre d’information, cette

dernière est masquée. Elle réapparaît avec un nouveau message de

confirmation lorsque vous effectuez une action sur un élément.

�3� Zone d’information

Utilisez les pages de la zone d’information pour obtenir des informations

sur l’élément que vous avez sélectionné dans l’arborescence des topologies

ou la table des ressources et pour effectuer des opérations sur l’élément.

Pour plus d’informations sur la zone d’information, reportez-vous à la

rubrique «Présentation de la zone d’information», à la page 136.

�4� Section des ressources

Les zones de la section des ressources permettent d’utiliser les ressources :

Afficher et Rechercher

Les fonctions Afficher et Rechercher permettent de limiter

l’étendue de la table des ressources. La fonction Afficher permet

de n’afficher que les ressources à l’état d’erreur ou d’avertissement.

La fonction Rechercher permet de n’afficher que les ressources qui

répondent à des critères de recherche spécifiques.

Table des ressources

Affiche une liste des ressources et de leurs états. Permet de

sélectionner et d’utiliser des ressources. La table des ressources se

compose de deux vues :

Vue des résultats de recherche

Lorsque vous utilisez Rechercher pour n’afficher qu’un

ensemble spécifique de ressources dans la table des

ressources, les résultats de la recherche sont affichés dans

la vue des résultats de recherche. Pour plus d’informations,

reportez-vous à la rubrique «Vue des résultats de

recherche», à la page 135.

Vue de la hiérarchie des groupes

La vue de la hiérarchie des groupes s’affiche lorsque vous

n’affichez pas les résultats d’une recherche. Pour plus

d’informations, reportez-vous à la rubrique «Vue de la

hiérarchie des groupes», à la page 132.

Pour plus d’informations sur la section des ressources,

reportez-vous à la rubrique «Ce qu’il faut savoir sur la section des

ressources», à la page 131.

�5� Arborescence des topologies

L’arborescence des topologies affiche les domaines d’automatisation et les

noeuds qui appartiennent aux domaines. L’arborescence des topologies

affiche les informations relatives à l’état, permet de sélectionner et

d’utiliser des domaines et des noeuds et permet de contrôler le contenu de

la table des ressources. Pour plus d’informations, reportez-vous à la

rubrique «Ce qu’il faut savoir sur l’arborescence des topologies», à la page

129.


Ce qu’il faut savoir sur l’arborescence des topologies

L’arborescence Topologie est divisée en trois colonnes :

v La colonne Topologie affiche les domaines d’automatisation

et les noeuds

qui appartiennent à un domaine dans une vue hiérarchique.

v La colonne Etat affiche l’état de fonctionnement du domaine.

v La colonne Situé(e) ici permet d’identifier sur quel domaine une ressource est

hébergée et sur quel(s) noeud(s) elle réside.

Navigation dans l’arborescence des topologies : Pour développer ou réduire les

noeuds d’un domaine, cliquez sur le triangle placé devant l’icône du domaine.

Sélection d’un élément dans l’arborescence des topologies : Pour sélectionner un

élément dans l’arborescence, cliquez sur son nom. La sélection d’un domaine ou

d’un noeud à une incidence sur les éléments qu’affiche la table des ressources dans

la zone d’information :

v La table des ressources affiche les ressources qui sont hébergées par le domaine

sélectionné ou qui résident sur le noeud sélectionné.

v Les pages de la zone d’information affichent des informations sur l’élément que

vous avez sélectionné dans l’arborescence des topologies. Selon le type

d’élément que vous avez sélectionné, des boutons sont activés sur les pages pour

vous permettre d’effectuer des opérations sur l’élément.

Remarques :

1. Pour sélectionner ses ressources dans un domaine d’automatisation, vous devez

tout d’abord développer le domaine en cliquant sur le carré bleu qui se trouve

en regard du domaine concerné dans l’arborescence des topologies.

2. Les ressources sélectionnées pour lesquelles une référence a été créée figurent

dans la partie droite de la fenêtre.

Limitation de l’étendue de l’arborescence des topologies : Par défaut, tous les

domaines d’automatisation sont affichés dans l’arborescence des topologies. Si vous

ne souhaitez pas afficher l’intégralité des domaines d’automatisation, vous pouvez

masquer certains domaines. Pour limiter l’étendue de l’arborescence des

topologies, vous pouvez utiliser la page Domaines visibles de la fenêtre

Préférences. Pour ouvrir le panneau Préférences, cliquez sur Menu dans la barre

de menus et sélectionnez Préférences.

Eléments affichés dans la colonne des topologies : La colonne des topologies

présente les domaines d’automatisation et les noeuds gérés par chaque domaine

d’automatisation.

Les icônes suivantes sont utilisées pour identifier les éléments de l’arborescence

des topologies :

Tableau 17. Icônes correspondant aux éléments dans l’arborescence des topologies

Icône Description

Un domaine d’automatisation. Lorsque le domaine n’est pas actif ou que

son état est inconnu, l’icône est grisée.

Noeud qui appartient à un domaine d’automatisation. Lorsqu’un noeud

n’est pas actif, l’icône est grisée.


Contenu de la colonne Etat : La colonne Etat indique l’état de fonctionnement

d’un domaine. Lorsque le domaine fonctionne correctement, la colonne est vide.

Un domaine est considéré fonctionner correctement si aucune des ressources que

vous utilisez comme indicateurs d’état du domaine n’a rencontré un incident

nécessitant votre attention. Par défaut, les ressources de niveau supérieur d’un

domaine sont utilisées comme indicateur d’état des domaines. Toutefois, vous

pouvez également définir, dans la page Domaines visibles du panneau Préférences

(Menu –> Préférences), un ensemble de ressources différent pour indiquer si un

domaine fonctionne normalement.

Si une ressource utilisée comme indicateur d’état de fonctionnement d’un domaine

rencontre un incident, l’une des icônes suivantes apparaît dans la colonne Etat :

Tableau 18. Icônes figurant dans la colonne Etat de l’arborescence des topologies

Icône L’icône indique ...

Un avertissement a été émis. L’incident peut encore être résolu

automatiquement, mais l’élément requiert une surveillance accrue.

L’icône rouge d’erreur indique qu’une erreur s’est produite. Pour résoudre

cet incident, l’opérateur doit intervenir.

L’icône noire indique qu’une erreur irréparable s’est produite. Pour résoudre

ce problème, l’opérateur doit intervenir en urgence.

Remarque : Si vous voyez une icône d’avertissement en regard du nom du

domaine, cela peut indiquer que l’ID utilisateur et le mot de passe

n’ont pas été entrés pour ce domaine System Automation for

Multiplatforms. Double-cliquez sur le nom du domaine et entrez l’ID

utilisateur et le mot de passe correspondant. Votre administrateur

système peut vous aider à vous procurer l’ID utilisateur et le mot de

passe.

Eléments affichés dans la colonne Situé(e) ici : Vous pouvez utiliser la colonne

Situé(e) ici pour identifier le ou les domaine(s) qui héberge une ressource ou un

groupe de ressources ainsi que les noeuds sur lesquels ils se trouvent. Pour

connaître l’emplacement d’une ressource ou d’un groupe de ressources, vous

pouvez sélectionner la ressource ou le groupe de ressources dans la table des

ressources. Une fois l’élément sélectionné, une marque s’affiche dans la colonne

Situé(e) ici du domaine qui héberge la ressource. Si vous affichez la hiérarchie des

noeuds, une ou plusieurs coche(s) indiquent le ou les noeuds sur lesquels la

ressource réside.


Ce qu’il faut savoir sur la section des ressources

La figure suivante représente la section des ressources.

La section des ressources contient les zones suivantes :

En-tête de section : L’en-tête de section affiche le nom du domaine ou du noeud

actuellement sélectionné dans l’arborescence des topologies.

Afficher et Rechercher : Les fonctions Afficher et Rechercher permettent de

limiter l’étendue de la table des ressources :

Afficher

Sélectionnez l’option Erreurs et avertissements de la liste déroulante

Afficher pour n’afficher que les ressources à l’état Erreur ou Avertissement.

La vue est toujours appliquée à la liste des ressources actuellement affichée

dans la table des ressources.

Rechercher

Permet de n’afficher que les ressources qui satisfont certains critères de

recherche.

Vues de la table des ressources : Les ressources que vous contrôlez et gérez à

partir de la console d’opérations sont affichées dans la table des ressources. Cette

table des ressources se compose de deux vues, qui sont décrites dans les sections

ci-après. Dans ces deux vues, vous pouvez effectuer les actions de base suivantes :

Sélectionner une ressource

Pour sélectionner une ressource, cliquez sur son nom dans la colonne des

ressources.

Figure 8. Présentation de la section des ressources


Contrôler l’ordre de tri de la table des ressources

Vous pouvez trier la table des ressources en fonction de toute colonne en

cliquant sur la flèche de tri de l’en-tête de colonne.

Si la flèche de tri d’un en-tête de colonne est pleine, cela signifie que la

table est actuellement triée sur cette colonne. Le sens de cette flèche

indique l’ordre de tri actuel (croissant ou décroissant). En cliquant sur la

flèche de tri pleine, vous pouvez passer d’un tri par ordre croissant à un tri

par ordre décroissant et réciproquement.

Lorsque vous placez le curseur sur une flèche de tri, une bulle d’aide

indique l’état de tri actuel de la colonne et l’ordre de tri que vous

obtiendrez si vous cliquez sur la flèche de tri.

Exploration des pages de la table des ressources

La table des ressources peut comporter plusieurs pages. Pour parcourir la

table ou accéder à une page spécifique, utilisez les commandes disponibles

dans la ligne d’état située sous la table.

Vue de la hiérarchie des groupes : La vue de la hiérarchie des groupes s’affiche

lorsque vous n’affichez pas les résultats d’une recherche. Dans la figure ci-après,

les ressources de niveau supérieur du domaine d’automatisation "FEPLEX1",

sélectionné dans l’arborescence des topologies, sont affichées dans la table des

ressources.

Colonne Ressource :

Cette colonne contient une liste des ressources et de leurs états. Les ressources

répertoriées dépendent de vos sélections :

v Un domaine ou un noeud est sélectionné dans l’arborescence des topologies : les

ressources de niveau supérieur du domaine ou du noeud sont affichées.

v Un groupe est sélectionné dans la table des ressources : les membres du groupe

sont affichés.

Pour trier les ressources par nom suivant l’ordre alphabétique, cliquez sur la flèche

de tri de l’en-tête de colonne.

Lorsque vous sélectionnez un groupe dans la table des ressources, les membres du

groupe sont affichés dans la table des ressources. Dans la zone située au dessus de


la table, un chemin de navigation apparaît. Sur ce chemin, le nom du groupe dont

les membres sont répertoriés dans la table des ressources est mis en évidence pour

indiquer que le groupe est sélectionné.

Le chemin de navigation sert à la navigation et à l’orientation :

v Lorsque vous explorez la hiérarchie des groupes, une entrée est ajoutée au

chemin pour chaque groupe que vous sélectionnez.

v La dernière entrée du chemin identifie le groupe dont les membres sont

actuellement affichés dans la table des ressources. Lorsque le nom du groupe est

mis en évidence, le groupe est sélectionné et ses détails sont affichés dans la

zone d’information.

v Lorsque vous cliquez sur Haut dans le chemin de navigation, les ressources de

niveau supérieur du noeud ou du domaine d’automatisation sélectionné dans

l’arborescence des topologies sont de nouveau affichées dans la table des

ressources et le chemin de navigation disparaît.

v Lorsque le chemin de navigation dépasse trois niveaux, une ellipse (...) remplace

toutes les entrées du chemin, exceptées les deux dernières.

Vous ne pouvez pas cliquer sur l’ellipse. Pour remonter la hiérarchie des

groupes, cliquez sur un nom de groupe disponible dans le chemin jusqu’à ce

que le groupe à afficher apparaisse de nouveau.

L’icône de ressource à gauche du nom de la ressource dans la colonne des

ressources indique le type de ressource et son état en ligne:

v Lorsque la ressource est en ligne, son icône est active ; lorsque la ressource est

hors ligne, l’icône est grisée.


v Lorsqu’une ressource est à l’état d’avertissement ou d’erreur, son icône est mise

en évidence avec une icône d’avertissement ou d’erreur.

v Une icône d’opérateur

indique qu’une requête d’opérateur a été soumise sur

la ressource. La couleur de l’icône d’opérateur change pendant le traitement de

la requête, le jaune indique que la requête a été soumise, le vert indique que la

requête a abouti.

Les types de ressources affichées dans la colonne des ressources sont les

suivantes :

Tableau 19. Icônes de ressources dans la colonne des ressources

Icône Description

ressource

Groupe de ressources

groupe de déplacement, également appelé ressource flottante.

Le tableau ci-après répertorie les icônes d’avertissement et d’erreur qui

apparaissent dans la colonne des noms de ressource lorsqu’une ressource est à

l’état d’erreur ou d’avertissement.

Icône Description

L’icône d’avertissement jaune indique que la ressource se trouve à l’état

d’avertissement. Cet incident peut être résolu automatiquement. Cependant,

la ressource doit être surveillée soigneusement.

L’icône rouge d’erreur indique que la ressource se trouve à l’état d’erreur.

L’intervention de l’opérateur est nécessaire.

L’icône d’erreur noire indique que la ressource a rencontré une erreur

irrémédiable. L’opérateur doit intervenir immédiatement.

Colonne Etat composé :

Cette colonne indique l’état composé de la ressource. En effectuant un tri sur cette

colonne, vous pouvez regrouper les ressources par état.

L’état composé peut présenter l’une des valeurs suivantes :

Etat Description

OK La ressource fonctionne normalement. Sélectionnez-la pour afficher

davantage d’informations.

Avertissement La ressource est à l’état d’avertissement. Sélectionnez-la pour afficher

davantage d’informations.

Erreur La ressource est à l’état d’erreur. Sélectionnez-la pour afficher davantage

d’informations.


Etat Description

Fatale La ressource a rencontré une erreur irrémédiable. Sélectionnez-la pour

afficher davantage d’informations.

Vue des résultats de recherche : Lorsque vous utilisez Rechercher pour n’afficher

qu’un ensemble spécifique de ressources dans la table des ressources, les résultats

de la recherche sont affichés dans la vue des résultats de recherche. Les critères de

recherche utilisés sont affichés dans la zone située au dessus de la table des

ressources. Dans cette vue, la table des ressources se présente comme suit :

Pour limiter la portée des ressources actuellement affichées dans la table des

ressources à celles à l’état d’erreur ou d’avertissement, vous pouvez appliquer en

plus la vue Erreurs et avertissements fournie dans la zone Vue.

Colonnes de la table des ressources :

Dans la vue des résultats de recherche, la table des ressources contient trois

colonnes :

Colonne Ressource

Cette colonne répertorie les ressources qui correspondent aux critères de

recherche.

v Pour trier les ressources par nom suivant l’ordre alphabétique, cliquez

sur la flèche de tri de l’en-tête de colonne.

v Si une ressource est à l’état d’avertissement ou d’erreur, son icône est

mise en évidence avec une icône d’avertissement ou d’erreur.

v Si une requête d’opérateur a été soumise sur la ressource, une icône

d’opérateur est affichée.

v Si vous cliquez sur une ressource, cette dernière est sélectionnée et ses

détails sont affichés dans la zone d’information.


Remarque : Lorsque vous sélectionnez un groupe dans la vue des

résultats de recherche, les détails du groupe sont affichés

dans la zone d’information, mais la table des ressources

n’est pas remplacée par la vue de la hiérarchie des groupes

pour afficher les membres du groupe.

Pour afficher les membres du groupe dans la vue de la

hiérarchie des groupes, vous devez sélectionner le groupe et

cliquer sur Effacer les résultats (voir «Suppression des

résultats de la recherche»).

Colonne Etat composé

Cette colonne indique l’état composé de la ressource. En effectuant un tri

sur cette colonne, vous pouvez regrouper les ressources par état.

Membre de colonne

Si une ressource est membre d’un groupe, le nom du groupe est affiché

dans cette colonne. Lorsque vous triez la table des ressources sur cette

colonne, les ressources membres du même groupe sont répertoriées les

unes après les autres.

Suppression des résultats de la recherche :

Si vous cliquez sur Effacer les résultats, la table des ressources bascule vers la vue

de la hiérarchie des groupes. Les ressources affichées dans la vue de la hiérarchie

des groupes dépendent de votre sélection dans la vue des résultats de recherche :

v Aucune ressource n’a été sélectionnée : les ressources de niveau supérieur du

noeud ou du domaine d’automatisation sélectionné dans l’arborescence des

topologies sont affichées.

v Un groupe de ressources a été sélectionné : Les membres du groupe sont

affichés. Dans le chemin de navigation, le nom du groupe est mis en évidence et

les détails du groupe sont affichés dans la zone d’information.

v Une ressource membre d’un groupe a été sélectionnée : les membres du groupe

sont affichés, le nom du groupe est affiché dans le chemin de navigation, mais il

n’est pas mis en évidence et le nom de la ressource sélectionnée est mis en

évidence dans la table des ressources.

Présentation de la zone d’information

Ce chapitre présente un rapide aperçu des pages dans la zone d’information.

Les pages de la zone d’information affichent des informations sur l’élément que

vous avez sélectionné dans l’arborescence des topologies ou la table des ressources.

Sur les pages de la zone d’information, des commandes vous permettent

d’effectuer des opérations sur l’élément sélectionné (ressource, groupe, noeud ou

domaine d’automatisation). Les pages disponibles et leur contenu dépendent du

type d’élément sélectionné dans l’arborescence des topologies ou la table des

ressources :

Lorsque vous sélectionnez ... ...les pages suivantes sont disponibles

un domaine d’automatisation dans

l’arborescence des topologies

v Général

v Règle

v Informations complémentaires


Lorsque vous sélectionnez ... ...les pages suivantes sont disponibles

un noeud dans l’arbre des topologies v Général

v Informations complémentaires (disponibles

uniquement si des informations complémentaires

existent)

une ressource ou un groupe de

ressources dans la table des

ressources

v Général

v Relations (disponible uniquement si la ressource

possède des relations)

v Informations de localisation

v Informations complémentaires (disponibles

uniquement si des informations complémentaires

existent)

Page Général : La page Général est toujours disponible lorsqu’un élément est

sélectionné dans l’arborescence des topologies ou la table des ressources. Les

informations figurant sur la page Général et les opérations éventuelles dépendent

de la sélection qui a été effectuée au niveau de l’arborescence des topologies ou de

la table des ressources.

Page Général d’un domaine

Voir la page Général d’un domaine pour obtenir des informations sur l’état

d’un domaine, son état de communication, et l’état des ressources qu’il

héberge et pour afficher le fichier journal du domaine.

Page Général d’un noeud

Reportez-vous à la page Général d’un noeud pour obtenir des informations

détaillées sur le noeud comme, par exemple, son nom, sa classe et

éventuellement une description du noeud. De plus, la page contient des

informations sur l’état observé du noeud. Un bouton vous permet

d’exclure ou d’inclure le noeud de l’automatisation.

Page Général d’un groupe de ressources

Voir la page Général d’un groupe de ressources :

v pour obtenir des informations détaillées sur le groupe de ressources en

lui-même comme sa classe.

v pour afficher des informations détaillées sur les différents états du

groupe.

v pour soumettre une requête de démarrage ou d’arrêt.

v pour afficher la pile de requêtes de la ressource.

v pour savoir si le groupe de ressources appartient à un autre groupe de

ressources. Si tel est le cas, un lien est disponible pour vous permettre

d’accéder directement à ce groupe de ressources.

Page Général d’une ressource

Voir la page Général :

v pour afficher des informations détaillées concernant la ressource telles

que sa classe ou son propriétaire par exemple.

v pour obtenir des informations détaillées sur les différents états de la

ressource.

v pour voir les requêtes d’opérateur le cas échéant.

v pour soumettre une requête de démarrage ou d’arrêt.

v pour savoir si la ressource appartient à un groupe.


Page Règles : Vous ne pouvez accéder à la page Règles que lorsqu’un domaine

est sélectionné dans l’arborescence des topologies. Elle vous permet de vérifier,

d’activer et de désactiver les règles d’automatisation qui sont stockées dans le pool

de règles.

Informations de localisation : La page est disponible pour les groupes de

ressources. Cette page permet de déterminer l’emplacement et l’état des membres

du groupe de ressources.

Page Informations supplémentaires : Une page Informations complémentaires

peut être affichée pour les domaines d’automatisation, les noeuds, les ressources, et

les groupes de ressources lorsque des informations complémentaires sont

disponibles.

Page Relations : Une page Relations est disponible lorsque vous sélectionnez une

ressource ou un groupe dans la table des ressources et que des relations en aval et

en amont ont été définies.

Utilisation des règles d’automatisation

Vérification des règles d’automatisation

Effectuez cette tâche pour vérifier si les règles d’automatisation dans le pool de

règles peuvent être activées ou si elles contiennent des erreurs qui devront être

résolues avant leur activation.

Pour effectuer cette tâche, les prérequis suivants doivent être respectés :

v Vous devez disposer au minimum des privilèges EEZConfigurator.

v Le répertoire de pool de règles est configuré pour le domaine d’automatisation.

v Les règles d’automatisation sont stockées dans le répertoire de pools de règles.


1. Ouvrez la page ″Sélectionner une règle d’automatisation″ de l’une des façons

suivantes :

v Dans l’arborescence de la navigation de la console, cliquez sur Tivoli System

Automation for Multiplatforms > Tâches opérationnelles >Activer une

règle d’automatisation. Dans la page ″Activer une règle d’automatisation″,

sélectionnez le domaine d’automatisation approprié et cliquez sur Suivant.

v Ouvrez une console d’opérations SA, sélectionnez le domaine

d’automatisation approprié dans l’arborescence des topologies, ouvrez la

page des règles du domaine et cliquez sur Activer une nouvelle règle.2. Si une icône d’erreur ou d’avertissement s’affiche dans la colonne de droite du

tableau de règles, des avertissements et/ou des erreurs seront émis(es) lors de

la vérification de validité effectuée à l’ouverture de la page.

Pour afficher la liste des problèmes pour une règle, sélectionnez la règle et

cliquez sur le bouton Afficher les avertissements ou Afficher les erreurs qui

s’affiche en dessous du champ Description. Si des erreurs ont été détectées

dans le fichier, vous devez les corriger avant d’activer la règle. Bien que les

avertissements n’empêchent pas l’activation de la règle, vous devez rechercher

un moyen de les éviter.

3. Cliquez sur Annuler pour fermer la liste des règles. Répétez la procédure

jusqu’à ce que tous les problèmes signalés soient résolus et que la règle soit

prête à être activée.


Vérification de l’activation des règles lors de l’automatisation de l’adaptateur

d’automatisation de bout en bout : Dans les environnements où l’adaptateur

d’automatisation de bout en bout a été automatisé, avant d’activer des règles,

vérifiez qu’elles contiennent les définitions de ressource du groupe de ressources

samadapter.

Pour vérifier que la nouvelle règle contient les définitions de ressource du groupe

de ressources samadapter :

v Parcourez le fichier de règles XML et recherchez l’élément <ResourceGroup

name="samadapter-rg" class="IBM.ResourceGroup">.

– Si la nouvelle règle contient cet élément, vous pouvez activer la règle à partir

de la console d’opérations. Voir «Activation des règles d’automatisation».

– Si la nouvelle règle ne contient pas cet élément, ne l’activez pas. Si vous

activez la nouvelle règle, les définitions de ressource de samadapter seront

supprimées et l’adaptateur sera arrêté, ce qui rendra le domaine indisponible

dans la console d’opérations.

Pour réactiver l’adaptateur d’automatisation de bout en bout, utilisez la fonction

Définir de la boîte de dialogue de configuration de l’adaptateur d’automatisation

de bout en bout. Cette fonction est décrite dans la section ″Configuration de

l’adaptateur d’automatisation de bout en bout″ du Guide d’installation et de

configuration d’IBM Tivoli System Automation for Multiplatforms.

Pour empêcher la suppression de l’adaptateur lors de l’activation d’une nouvelle

règle :

1. Utilisez la commande sampolicy -s <fichier> pour enregistrer la règle en cours

contenant les définitions de ressource pour samadapter.

2. Copiez les définitions de ressource de samadapter dans la nouvelle règle à

activer.

3. Activez la nouvelle règle à partir de la console d’opérations.

Activation des règles d’automatisation

Réalisez cette opération pour activer une règle d’automatisation pour un domaine

d’automatisation System Automation for Multiplatforms.



v Le répertoire de pool de règles est configuré pour le domaine.

v Les règles d’automatisation sont stockées dans le répertoire de pool de règles du

domaine.

Avant de poursuivre, il est conseillé d’effectuer les vérifications décrites dans

«Vérification des règles d’automatisation», à la page 138.


1. Ouvrez la page ″Sélectionner une règle d’automatisation″ de l’une des façons

suivantes :


Automation for Multiplatforms > Tâches opérationnelles >Activer une

règle d’automatisation. Dans la page ″Activer une règle d’automatisation″,

sélectionnez le domaine d’automatisation approprié et cliquez sur Suivant.


v Ouvrez une console d’opérations SA, sélectionnez le domaine

d’automatisation approprié dans l’arborescence des topologies, ouvrez la

page des règles du domaine et cliquez sur Activer une nouvelle règle.2. Sélectionnez la règle d’automatisation que vous souhaitez activer dans la table

de règles. La règle doit être exempte d’erreur afin d’être activée.

3. Cliquez sur Activer pour activer la règle. Si vous tentez d’activer une règle qui

est déjà active, vous recevez un avertissement.

L’activation de la règle à partir de la console d’opérations SA ne nécessite pas

d’interruption, le processus d’activation correspond à celui déclenché par la

commande sampolicy -r.

v Tous les éléments de la règle déjà présents dans le système et qui ont les

mêmes attributs et les mêmes valeurs, restent inchangés.

v Si des attributs ont changé, l’élément correspondant est modifié dans le

système.

v Si les éléments de la règle n’existent pas dans le système, ils sont alors créés.

v Les éléments présents dans la règle d’automatisation active mais qui ne le

sont pas dans la nouvelle sont supprimés.

Désactivation de la règle d’automatisation active

Effectuez cette tâche pour désactiver la règle d’automatisation active pour un

domaine d’automatisation. Cette opération peut s’avérer nécessaire, par exemple, si

la règle provoque des problèmes graves, qui ne peuvent pas être résolus d’une

autre manière.



v Le répertoire de pool de règles est configuré pour le domaine.

v Les règles d’automatisation sont stockées dans le répertoire de pool de règles du

domaine.

Vous pouvez désactiver une règle d’automatisation en procédant de l’une des

façons suivantes :

v Ouvrez une console d’opérations SA, sélectionnez le domaine d’automatisation

dans l’arborescence des topologies, ouvrez la page Règle du domaine et cliquez

sur Désactiver la règle.


Automation for Multiplatforms > Tâches opérationnelles >Désactiver la règle

en cours. Dans la page ″Désactiver la règle active″, sélectionnez le domaine

d’automatisation approprié et cliquez sur Désactiver la règle.

Résultats : La règle est désactivée, le domaine n’est plus automatisé. L’ensemble

des ressources, groupes et relations sera supprimé et les ressources

correspondantes seront arrêtées. Si l’adaptateur avait un niveau de disponibilité

élevé, les ressources à l’origine de cette haute disponibilité, par exemple, un service

IP et le groupe de ressources de l’adaptateur, seront conservées. Par conséquent, le

domaine sera toujours à haute disponibilité.

Gestion des ressources à l’aide de la console d’opérations

La gestion des ressources consiste à :

v démarrer ou arrêter une ressource ou un groupe de ressources ;

v exclure un noeud de l’automatisation et l’inclure à nouveau.


Gestion des requêtes

Vous arrêtez et vous démarrez les ressources en intervenant sur leur état. Vous

pouvez effectuer cela en soumettant des requêtes de démarrage ou d’arrêt pour

faire passer l’état d’une ressource sur en ligne ou hors ligne. L’état à appliquer

d’une ressource sera modifié lorsque votre requête est prioritaire. La ressource ne

pourra être démarrée ou arrêtée que si toutes les relations ont abouti. Voir la

description dans «Démarrage et arrêt d’un groupe de ressources et de membres

d’un groupe», à la page 200.

Pour envoyer des requêtes, respectez les règles suivantes :

v Les requêtes en ligne ne peuvent être soumises sur les ressources que si l’état de

ces requêtes est hors ligne.

v Les requêtes hors ligne ne peuvent être soumises sur les ressources que si l’état

de ces requêtes est en ligne.

v Les requêtes ne peuvent être envoyées que si l’état actuel de la ressource a été

généré par un opérateur. Dans ce cas, les requêtes d’opérateur doivent être

annulées.

Remarque : En raison de la conception interne de System Automation for

Multiplatforms, les requêtes concernant les groupes de ressources ne

sont pas propagées sur les membres correspondant à des ressources

flottantes.

Envoi des requêtes de démarrage : Pour envoyer une requête de démarrage,

procédez comme suit :

1. Dans la table des ressources, sélectionnez la ressource à démarrer.

_________________________________________________________________

2. Sur la page Général, cliquez sur Requête d’activation.

La fenêtre Requête d’activation s’affiche

_________________________________________________________________

3. Dans la zone d’entrée de la fenêtre Requête d’activation, expliquez les raisons

pour lesquelles vous souhaitez modifier l’objectif d’automatisation de la

ressource sur l’état Actif. Le point-virgule ″;″ ne peut pas être utilisé dans les

commentaires.

_________________________________________________________________

4. Cliquez sur Envoyer pour envoyer la requête.

_________________________________________________________________

Résultats :

v Un message de confirmation est affiché sur la barre d’information ; il indique

que la requête a été soumise pour traitement.

v Après la régénération suivante, l’icône de la ressource change pour indiquer

qu’une requête a été émise sur la ressource.

v La requête est traitée. Le traitement de la requête se termine lorsque la ressource

a démarré. L’icône de l’opérateur devient vert.

Envoi des requêtes d’arrêt : Pour envoyer une requête d’arrêt, procédez comme

suit :

1. Dans la table des ressources, sélectionnez la ressource à arrêter.

_________________________________________________________________


2. Sur la page Général, cliquez sur Requête de désactivation. Le bouton est

activé uniquement si l’état à appliquer de la ressource est Inactif et qu’aucune

autre requête d’opérateur n’existe sur la ressource.

La fenêtre Requête de désactivation s’ouvre.

_________________________________________________________________

3. Utilisez la zone d’entrée pour expliquer brièvement la raison pour laquelle

vous voulez remplacer l’objectif d’automatisation de la ressource par Hors

ligne. Le point-virgule ″;″ ne peut pas être utilisé dans les commentaires.

_________________________________________________________________

4. Cliquez sur Envoyer pour envoyer la requête.

_________________________________________________________________

Résultats :

v Un message de confirmation est affiché sur la barre d’information ; il indique

que la requête a été soumise pour traitement.

v Après la régénération suivante, l’icône de la ressource change pour indiquer

qu’une requête a été émise sur la ressource.

v La requête est traitée. Le traitement de la requête se termine lorsque la ressource

est arrêtée. L’icône de l’opérateur devient vert.

Affichage des informations sur la requête d’opérateur : Lorsqu’un opérateur a

envoyé une requête de démarrage ou d’arrêt sur une ressource, une icône de

requête d’opérateur apparaît sur la page Général de la ressource. L’icône indique si

la requête a abouti ou non :

Tableau 20. Icônes des requêtes d’opérateur de la zone d’information

Icône Requête

d’opérateur Description

(jaune)

Une requête d’arrêt à été envoyée. L’icône jaune d’opérateur indique si

l’état observé de la ressource n’est pas encore Inactif.

(jaune)

Une requête de démarrage à été envoyée. L’icône jaune d’opérateur

indique si l’état observé de la ressource n’est pas encore Actif.

(vert)

L’icône verte d’opérateur indique que la requête d’arrêt a été

correctement exécutée. L’état observé de la ressource est Inactif.

(vert)

Une icône verte d’opérateur indique que la requête de démarrage a été

exécutée. L’état observé de la ressource est Actif.

Vous pouvez afficher d’autres informations sur la requête comme suit :

v Déplacez la souris sur l’icône de requête de l’opérateur pour afficher l’ID

utilisateur issu de la requête de l’opérateur.

v Cliquez sur l’icône de requête de l’opérateur pour afficher la fenêtre des détails

de la requête.


Affichage de la liste des requêtes : Les ressources et les votes envoyés sur une

ressource sont ajoutés à la liste des requêtes de la ressource. Vous pouvez afficher

la liste pour identifier les requêtes qui ont été émises et, parmi ces dernières, celle

qui est prioritaire. La liste des requêtes est classée par ordre de priorité avec en

tête de liste la requête gagnante.

La liste contient des informations sur chaque requête ou chaque vote, par

exemple :

v sa source (par exemple, le nom de l’opérateur qui a émis la requête)

v son ordre de priorité

v date et heure de création

Dans la fenêtre Liste des requêtes, vous pouvez afficher les informations détaillées

concernant chaque requête et chaque vote ainsi que les commentaires

préalablement ajoutés par les opérateurs lors de l’envoi de la requête. En raison de

la conception interne de System Automation for Multiplatforms, les requêtes

concernant les groupes de ressources ne sont pas propagées sur les membres

correspondant à des ressources flottantes.

Etapes à suivre pour afficher une liste de requêtes et les détails de la requête :


1. Dans la table des ressources, sélectionnez la ressource pour laquelle vous

souhaitez afficher la liste des requêtes ou les détails d’une requête.

_________________________________________________________________

2. Sur la page Général, cliquez sur Afficher les requêtes.

La liste des requêtes s’affiche. La liste est triée par ordre de priorité. La

première entrée correspond à la requête gagnante.

_________________________________________________________________

3. Pour afficher les détails d’une requête, sélectionnez la ressource dans la liste et

cliquez sur

La fenêtre Détails de la requête s’affiche.

_________________________________________________________________

Annulation des requêtes : Vous pouvez annuler des requêtes d’opérateur

préalablement envoyées sur les ressources. Les votes et les requêtes générés par les

gestionnaires d’automatisation ne peuvent être annulés.

Voici ce qui se produit si vous annulez une requête :

v Lorsque vous annulez une requête qui n’était pas prioritaire, vous empêchez par

cette action qu’elle soit traitée ultérieurement.

v Lorsque vous annulez la requête en charge de l’état en cours de la ressource,

vous modifiez l’état à appliquer de la ressource par son contraire si aucune

requête ou aucun vote au sein de la liste des requêtes n’est prioritaire lorsque la

requête que vous avez annulée est supprimée.

v Lorsque vous annulez une requête, les votes générés sur d’autres ressources en

raison de relations de StartAfter ou StopAfter sont également annulés.


Etapes à suivre pour annuler une requête :

Pour annuler une requête, procédez comme suit :

1. Sélectionnez la ressource dans la table des ressources.

_________________________________________________________________

2. Sur la page Général, cliquez sur Annuler la requête.

Le bouton est activé uniquement si une requête d’opérateur figure dans la liste

des requêtes de la ressource.

Le texte situé à gauche du bouton Annuler la requête décrit l’état possible à

appliquer de la ressource une fois la requête annulée. L’état possible à

appliquer est calculé de la façon suivante :

v Si d’autres requêtes ou votes figurent dans la liste des requêtes, la requête

gagnante détermine l’état attendu à appliquer.

v Si aucune autre requête ou vote ne figure dans la liste, l’état à appliquer

défini dans la règle devient l’objectif d’automatisation.

v Si d’autres requêtes ou votes figurent dans la liste des requêtes, celle ou

celui dont la valeur de priorité est la plus élevée sera prioritaire.

L’état à appliquer défini au terme de la procédure d’annulation peut être

différent de l’état attendu, par exemple, lorsqu’une nouvelle requête ou un

nouveau vote est généré au même moment ou immédiatement après avoir

annulé la requête.

_________________________________________________________________

Gestion de vos données d’identification utilisateur

Stockage de vos données d’identification utilisateur dans le

coffre d’accréditation

Si un domaine rejoint la console d’opérations pour la première fois, un symbole

jaune d’avertissement s’affiche dans la colonne Etat de l’arborescence des

topologies :

Cliquez sur le domaine pour ouvrir la page d’authentification Domaine

d’automatisation.


Entrez un ID utilisateur valide pour le domaine. L’ID utilisateur doit posséder les

autorisations nécessaires pour effectuer des opérations sur les ressources dans le

domaine d’automatisation de premier niveau pris en charge par la console

d’opérations (opérations de demande de mise en ligne d’une ressource automatisée

ou d’exclusion d’un noeud de l’automatisation, par exemple).

Si vous laissez la case cochée sur la page, vos données d’identification de

l’utilisateur pour le domaine sont enregistrées dans le coffre d’accréditation et l’ID

utilisateur ne sera pas demandé lors des prochaines tentatives pour accéder au

domaine.

Modification et suppression des données d’identification de

l’utilisateur utilisateur

Effectuez les opérations suivantes pour gérer vos données d’identification de

l’utilisateur stockées dans le coffre d’accréditation :

1. Cliquez sur Tivoli System Automation for Multiplatforms > Paramètres >

Données d’identification du domaine stockées dans l’arborescence de

navigation.

_________________________________________________________________

2. La page Données d’identification du domaine stockées comprend les options

suivantes :

v Pour modifier les données d’identification de l’utilisateur pour un domaine,

sélectionnez le domaine dans la table Données d’identification du coffre

d’accréditation et cliquez sur Modifier pour afficher la page

″Authentification du domaine d’automatisation du premier niveau″.

v Pour supprimer les données d’identification des utilisateurs pour un

domaine spécifique dans le coffre d’accréditation, sélectionnez le domaine et

cliquez sur Supprimer.

v Pour supprimer vos données d’identification pour tous les domaines

d’automatisation de premier niveau dans le coffre d’accréditation, cliquez sur

Supprimer tout.

_________________________________________________________________


Création et modification de règles d’automatisation dans l’éditeur de

règles

Cette section présente l’éditeur de règles graphique, qui permet de gérer vos règles

d’automatisation.

Présentation de la fenêtre de l’éditeur de règles

Cette section décrit la fenêtre de l’interface utilisateur de l’éditeur de règles. Pour

obtenir des instructions pas à pas sur l’utilisation de l’éditeur de règles, consultez

l’aide en ligne, accessible par le biais du lien Aide qui se trouve dans la barre

d’outils de la console.

L’écran principal de l’éditeur de règles se compose de plusieurs zones, comme le

montre la figure 9 :

�1� Type de règle

Le type de règle indique si la topologie actuellement chargée représente

une règle d’automatisation de bout en bout System Automation

Application Manager ou une règle d’automatisation de premier niveau


Figure 9. Ecran principal de l’éditeur de règles


�2� Barre de menus commune

Les boutons de la barre de menus permettent d’accomplir les actions

courantes. Vous pouvez par exemple effectuer un zoom avant ou arrière

sur l’afficheur de topologie et vous déplacer vers les zones adjacentes de la

règle actuellement chargée.

�3� Barre de filtrage

La barre de filtrage permet d’appliquer différents filtres aux entités

affichées dans l’afficheur de topologie. Vous pouvez spécifier une chaîne de

texte partielle (par exemple, le filtre "WAS" affichera uniquement les

ressources contenant la chaîne "WAS").

�4� Zone d’aide

Lorsque vous accomplissez certaines tâches de modification, des cases de

sélection et des boutons supplémentaires s’affichent sous la barre de

filtrage pour vous aider à accomplir la tâche souhaitée. Par exemple,

lorsque vous ajoutez un membre à un groupe, une case de sélection

Sélectionner un membre s’affiche pour indiquer les noms des éléments

que vous pouvez ajouter au groupe. Vous pouvez faire une sélection puis

cliquer sur Ajouter un membre pour terminer la tâche.

�5� Panneau d’aperçu

Le panneau d’aperçu permet d’identifier la partie de la règle actuellement

affichée dans l’afficheur de topologie. Il peut se révéler particulièrement

utile si vous avez effectué un zoom avant sur une petite partie d’une règle.

Vous pouvez également l’utiliser pour afficher une autre partie de la règle.

Voir «A propos du panneau d’aperçu», à la page 148

�6� Afficheur de topologie

L’afficheur de topologie permet de modifier la règle actuellement chargée.

Vous pouvez créer de nouveaux éléments de règle et des relations, ajouter

des membres aux groupes, supprimer des éléments, etc. Voir «A propos de

l’afficheur de topologie», à la page 147

�7� Onglets de propriétés

Les onglets de propriétés permettent d’affecter des valeurs aux propriétés

de l’élément de règle actuellement sélectionné. Cliquez sur le bouton

Appliquer pour appliquer les modifications apportées à un onglet de

propriétés.

�8� Panneau des messages d’erreur

Le panneau des messages d’erreur permet d’identifier et de résoudre les

incidents affectant la règle actuellement chargée. Les éventuelles erreurs de

sémantique et de syntaxe sont recherchées dans la règle lorsque vous la

chargez dans l’éditeur, mais aussi chaque fois que vous modifiez les

propriétés d’un élément et que vous les appliquez.

A propos de l’afficheur de topologie

L’afficheur de topologie affiche une représentation graphique de la règle

d’automatisation actuellement chargée. Chacun des éléments de la règle est

représenté par une icône. Les appartenances à des groupes sont représentées par

des lignes de liaison bleues (la flèche part du groupe conteneur et pointe vers le

membre de groupe). Les relations entre les éléments sont représentées par des

lignes de liaison roses (la flèche part de la ressource source et pointe vers la cible

de la relation).


Redimensionnement : Utilisez l’icône Redimensionner le point de vue

(elle se

trouve dans le coin inférieur droit de l’afficheur de topologie) pour modifier la

taille de l’afficheur de topologie. Cliquez sur l’icône avec le bouton gauche de la

souris, maintenez le bouton enfoncé et faites glisser la souris vers la position

souhaitée. Par exemple, pour réduire la taille de l’afficheur de topologie, faites

glisser le pointeur vers le coin supérieur gauche.

Panoramique : Cliquez sur les symboles triangulaires qui se trouvent sur le

périmètre de l’afficheur de topologie pour déplacer l’affichage dans la direction

souhaitée. Par exemple, pour afficher la zone adjacente située plus à droite, cliquez

sur Panoramique Est

. Vous pouvez également cliquer sur Mode Panoramique

souris

dans la barre de menus commune pour faire glisser l’affichage et afficher

ainsi une zone adjacente. Par exemple, si vous cliquez à l’aide du bouton gauche

de la souris près du centre de la vue, que vous maintenez le bouton enfoncé et que

vous faites glisser le pointeur vers le coin supérieur droit, vous faites ainsi

apparaître la zone située dans le coin inférieur gauche.

Zoom : Cliquez sur l’icône de zoom avant

ou de zoom arrière

qui se

trouve dans le menu commun pour effectuer un zoom avant ou arrière sur

l’afficheur de topologie. Cliquez sur Adapter le contenu au point de vue

pour

redimensionner la règle de manière à ce qu’elle s’affiche entièrement dans

l’afficheur de topologie. Vous pouvez également cliquer sur Mode Zoom souris

dans la barre de menus commune pour effectuer un zoom avant sur une zone

précise. Pour définir cette zone, maintenez le bouton gauche de la souris enfoncé

après avoir cliqué sur un coin de la zone, puis faites glisser le pointeur vers le coin

opposé.

Limitation de l’étendue de l’afficheur de topologie : Par défaut, tous les

éléments de règle sont affichés dans l’afficheur de topologie. Pour afficher un

sous-ensemble d’éléments, vous pouvez utiliser la barre de filtrage afin d’appliquer

un filtre. Vous pouvez également afficher ou masquer les relations, les

appartenances à des groupes, les ressources constituantes, les attributs persistants

et les ressources référencées à l’aide des commandes du menu Afficher. Dans le cas

de ressources fixes telles que IBM.ServiceIP, les attributs persistants associés sont

créés automatiquement et un nom généré automatiquement leur est attribué. Par

défaut, les attributs persistants sont masqués. Pour les afficher, utilisez la

commande Afficher -> Afficher les attributs persistants. La suppression

intentionnelle de groupes de déplacement et de ressources fixes ne supprime pas

les attributs persistants associés. Ceci permet d’éviter les problèmes susceptibles de

se produire lorsque plusieurs ressources partagent un même attribut persistant. Les

attributs persistants s’affichent automatiquement si vous sélectionnez la commande

Créer -> Attributs persistants.

A propos du panneau d’aperçu

Le panneau d’aperçu affiche une vue à l’échelle de l’ensemble de la représentation

graphique de la règle. Si vous avez effectué un zoom avant sur une petite partie de

la règle dans l’afficheur de topologie, le panneau d’aperçu représente cette zone au

moyen d’un rectangle bleu. Vous pouvez déplacer l’affichage sur une autre zone de

la règle en faisant glisser ce rectangle vers l’emplacement souhaité sur le panneau

d’aperçu.


Création d’une règle

Dans le scénario ci-dessous, vous allez apprendre à utiliser l’éditeur de règles pour

définir une règle d’automatisation. La grappe, les noeuds et les ressources de cet

exemple s’appuient sur la description proposée dans Chapitre 2, «Mise en route», à

la page 11, qui explique comment les définir à l’aide de commandes RSCT et

System Automation for Multiplatforms. Le scénario est décomposé en plusieurs

étapes :

v Etape 1 : Sélection du type de règle et du domaine

v Etape 2 : Création de la ressource d’application apache1

v Etape 3 : Création de la ressource d’adresse IP apache1IP

v Etape 4 : Création d’un groupe de ressources

v Etape 5 : Création d’une équivalence dynamique

v Etape 6 : Définition de relations

v Etape 7 : Enregistrement de la règle

Etape 1 : Sélection du type de règle et du domaine

1. Dans le menu d’Integrated Solutions Console, sélectionnez Tivoli System

Automation > Gestion de règles > Créer une nouvelle règle :


Etape 2 : Création de la ressource d’application apache1

La section «Définition de ressources RSCT pour un serveur Web», à la page 20

explique comment créer une ressource d’application portant le nom "apache1" à

partir d’un fichier de définition. Pour créer la même ressource à l’aide de l’éditeur

de règles, suivez la procédure ci-dessous :

1. Cliquez à l’aide du bouton droit de la souris sur l’afficheur de topologie, puis

sélectionnez Créer > Groupe de déplacement > IBM.Application :


Un groupe de déplacement par défaut s’affiche dans l’afficheur de topologie.

Les propriétés par défaut s’affichent dans le panneau des propriétés :


2. Dans l’onglet de propriétés Général, remplacez le nom par défaut du groupe de

déplacement par le nom correct ("apache1") et indiquez à quels noeuds il

s’applique (noeuds "node01", "node02" et "node03"). S’il s’agit d’un domaine

déconnecté, vous devez créer une liste de noeuds dans le panneau Noeuds avec

constituants. Pour ajouter un noeud à la liste, saisissez son nom dans la zone

prévue à cet effet et cliquez sur le bouton Appliquer au noeud. La figure

ci-dessous montre comment ajouter le noeud node03 à la liste :


3. Dans l’onglet de propriétés Attributs de la classe, saisissez les caractéristiques

des attributs de la classe dans les zones prévues à cet effet, puis cliquez sur le

bouton Appliquer :


Etape 3 : Création de la ressource d’adresse IP apache1IP

La section «Définition de ressources RSCT pour un serveur Web», à la page 20

explique comment créer une ressource d’adresse IP portant le nom "apache1IP" à

l’aide de paramètres de ligne de commande. Pour créer la même ressource à l’aide

de l’éditeur de règles, suivez la procédure ci-dessous :

1. Cliquez à l’aide du bouton droit de la souris sur la topologie, puis sélectionnez

Créer > Groupe de déplacement > IBM.Service.IP :


2. Saisissez les caractéristiques des attributs dans l’onglet de propriétés Général,

puis cliquez sur le bouton Appliquer.


3. Saisissez les caractéristiques des attributs dans l’onglet de propriétés Attributs

de la classe, puis cliquez sur le bouton Appliquer :


Etape 4 : Création d’un groupe de ressources

La section «Création d’un groupe de ressources pour apache1 et apache1IP», à la

page 27 explique comment ajouter les ressources apache1 et apache1IP à un groupe

de ressources portant le nom "apacherg". Pour réaliser la même opération à l’aide

de l’éditeur de règles, suivez la procédure ci-dessous :


sélectionnez Créer > Groupe de ressources :

2. Pour ajouter apache1 au groupe, cliquez à l’aide du bouton droit de la souris

sur le groupe, puis sélectionnez Ajouter un membre :


3. Dans la zone d’aide, sélectionnez apache1 dans la liste déroulante Sélectionner

un membre, puis cliquez sur le bouton Ajouter un membre :

Une ligne reliant apacherg à apache1 apparaît alors dans l’afficheur de

topologie :


4. Pour ajouter apache1IP au groupe, cliquez à l’aide du bouton droit de la souris

sur le groupe de ressources, puis sélectionnez Ajouter un membre. Vous

pouvez également indiquer le membre sans utiliser la zone d’aide : cliquez sur

le membre en question dans l’afficheur de topologie :

Des lignes reliant apacherg à apache1 et apache1IP apparaissent alors dans

l’afficheur de topologie :


Etape 5 : Création d’une équivalence dynamique

La section «Création d’une définition d’équivalence pour les cartes réseau», à la

page 26 décrit la méthode permettant de créer une équivalence dynamique à l’aide

de la ligne de commande, afin de définir les adaptateurs de réseau qui pourront

être utilisés pour accueillir l’adresse apache1IP. Pour créer la même équivalence

dynamique à l’aide de l’éditeur de règles, suivez la procédure ci-dessous :


sélectionnez Créer > Equivalence :


2. Dans l’onglet de propriétés, saisissez les attributs de l’équivalence, puis cliquez

sur le bouton Appliquer :


Etape 6 : Définition de relations

La section «Définition de relations entre les ressources du serveur Web», à la page

28 détaille la méthode de ligne de commande permettant de définir des relations

entre apache1 et apache1IP et entre apache1IP et l’équivalence netequ. Pour définir

les mêmes relations à l’aide de l’éditeur de règles, suivez la procédure ci-dessous :

1. Pour définir la relation entre les ressources apache1 et apache1IP, cliquez à

l’aide du bouton droit de la souris sur le groupe de déplacement apache1 dans

l’afficheur de topologie, puis sélectionnez Créer une relation :

2. Dans la zone d’aide, sélectionnez apache1IP dans la liste déroulante

Sélectionner une cible :


3. Cliquez sur le bouton OK. Une ligne de relation reliant apache1 et apache1IP

apparaît dans l’afficheur de topologie :

4. Dans le panneau Propriétés, remplacez le nom par défaut de la relation par le

nom correct ("apache1_dependson_ip1"), sélectionnez la condition correcte

(Dépendant de) dans la liste déroulante Type, puis cliquez sur le bouton

Appliquer :


5. Pour définir la relation entre apache1IP et l’équivalence netequ, cliquez à l’aide

du bouton droit de la souris sur le groupe de déplacement apache1IP dans

l’afficheur de topologie, puis sélectionnez Créer une relation :

Une ligne de relation reliant apache1IP à netequ apparaît alors dans l’afficheur

de topologie :


6. Dans le panneau Propriétés, remplacez le nom par défaut de la relation par le

nom correct ("apache1IP_dependson_netequ"), sélectionnez la condition correcte

(Dépendant de) dans la liste déroulante Type, puis cliquez sur le bouton

Appliquer :

Etape 7 : Enregistrement de la règle

Vous pouvez enregistrer la règle dans un fichier local ou dans un pool de règles.

v Pour enregistrer la règle dans un fichier local, procédez comme suit :

1. Dans le menu Fichier, sélectionnez Enregistrer dans un fichier local.

La boîte de dialogue Téléchargement de fichier s’affiche.

2. Dans cette boîte de dialogue, cliquez sur Enregistrer.

3. Naviguez jusqu’au dossier souhaité et spécifiez le nom du fichier de règles,

puis cliquez sur Enregistrer.

4. Dans la boîte de dialogue Téléchargement terminé, cliquez sur Fermer.v Pour enregistrer la règle dans un pool de règles, procédez comme suit :

1. Dans le menu Fichier, sélectionnez Enregistrer dans un pool de règles.

2. Sélectionnez le domaine souhaité dans la liste déroulante des domaines.

Seuls les domaines modifiables peuvent être sélectionnés.

3. Dans la zone Nom du fichier de règles, saisissez le nom de fichier de la

règle, puis cliquez sur Enregistrer.


Chapitre 9. Protection de vos ressources – support réalisé par

Quorum

Ce chapitre explique comment System Automation for Multiplatforms protège vos

ressources grâce à la configuration et au quorum opérationnel.

Généralités

Une grappe (portant aussi le nom de domaine homologue) peut être fractionnée en

deux ou plusieurs sous-grappes si la communication est interrompue entre les

éléments à l’intérieur de la grappe. Les sous-grappes ne communiquant pas entre

elles, il se peut que System Automation for Multiplatforms démarre une nouvelle

instance d’une application qui est déjà en cours d’exécution dans une autre

sous-grappe. Par exemple, si l’application sollicite l’accès à un disque partagé en

vue d’une récupération après incident, une altération de données peut se produire

en raison de l’accès simultané au disque.

Ces ressources sont qualifiées de critiques. Une ressource critique est une ressource

qui ne fonctionnera que sur un seul noeud à un moment donné. Si cette ressource

est active sur deux ou plusieurs noeuds séparés, l’intégrité des données de la

grappe est donc menacée. Afin de protéger ces ressources critiques, System

Automation for Multiplatforms veille à ne conserver qu’une seule sous-grappe et à

supprimer les autres. Par conséquent, System Automation for Multiplatforms

protège les données contre tout risque de corruption provoquée par des incidents

du système ou des partitions au sein du réseau.

Si une grappe est fractionnée en deux ou plusieurs sous-grappes, le gestionnaire de

ressources de configuration (ConfigRM) détermine les sous-grappes possédant une

majorité de noeuds. On parle de majorité lorsque la sous-grappe possède plus de

la moitié de tous les noeuds définis dans la grappe. La sous-grappe constituée

Figure 10. Quorum – majorité de noeuds


d’une majorité de noeuds se composera d’un quorum opérationnel. Cette

sous-grappe va être conservé et devenir la grappe active, alors que l’autre

sous-grappe va être dissoute.

La protection des ressources critiques est réalisée par

v le quorum de configuration

v le quorum opérationnel

Quorum de configuration

Le quorum de configuration détermine à quel moment les modifications de

configuration de la grappe seront acceptées. L’intégrité de la grappe est assurée

par la règle majoritaire suivante : Les opérations affectant la configuration de la

grappe ne sont autorisées que si les noeuds n/2+1 sont actifs, où n représente le

nombre de noeuds défini à l’intérieur de la grappe. Toutefois, pour certaines

opérations, la règle majoritaire peut être remplacée ou les règles du quorum de

configuration s’appliquer :

v Vous pouvez supprimer des noeuds à l’aide de la commande rmrpnode si la

moitié des noeuds est en ligne et si la configuration peut être supprimée de l’un

des noeuds hors ligne. Vous pouvez également utiliser l’option -f de cette

commande pour passer outre la règle majoritaire.

v La règle de quorum de la commande startrpdomain est n/2, mais vous pouvez

remplacer cette valeur par l’option Tous les noeuds (-A) ou l’option Noeud local

(-L).

Remarque : Dans une situation de parité, vous pouvez démarrer ou arrêter des

groupes de ressources à l’aide de la commande chrg –o online/offline

group_name.Pour plus d’informations, consultez la documentation de RSCT. Voir «Informations

connexes», à la page xv.

Quorum opérationnel

Le quorum opérationnel permet de déterminer si les ressources peuvent être

activées en toute sécurité, sans risquer un conflit avec d’autres ressources. Le

quorum opérationnel est déterminé en fonction du nombre de noeuds en ligne et

du départage afin de résoudre certaines situations de parité. Une sous-grappe est

associée à un quorum opérationnel si plus de la moitié de ses noeuds sont actifs.

Lorsqu’un quorum opérationnel existe, System Automation for Multiplatforms peut

réaliser des opérations sur les ressources ou les groupes de ressources et les mettre

en ligne. Sans quorum, System Automation for Multiplatforms ne peut pas

intervenir sur une ressource.

Méthodes de protection des ressources critiques sous AIX,

Solaris et Linux

Si des ressources critiques sont actives dans une sous-grappe AIX, Solaris ou Linux

dépourvue de tout quorum, ConfigRM utilise l’attribut CritRsrcProtMethod de

chaque noeud de la sous-grappe pour déterminer comment arrêter le système. Les

méthodes de protection reposent sur l’arrêt immédiat du système de Kernel Panic.

Support réalisé par Quorum


Il existe six méthodes de protection :

Signification Valeur

Réinitialisation à froid et redémarrage du système d’exploitation (par

défaut)

1

Arrêt du système d’exploitation 2

Réinitialisation à froid et redémarrage du système d’exploitation avec

Sync

3

Arrêt avec Sync 4

Aucune protection. Le système continue de fonctionner 5

Quitte et redémarre les sous-systèmes RSCT 6

Une méthode de protection avec sync envoie les mémoires tampon du système de

fichiers vers le disque avant que le système d’exploitation ne soit arrêté ou

réinitialisé. En conséquence, le risque de perte de données ou d’incohérence au

niveau du système de fichier est réduit. Notez que les méthodes de protection sync

peuvent toutefois représenter une solution peu fiable dans certaines situations. Il y

a toujours le risque que l’accès aux données se fasse au cours de la vidange du

système de fichiers à partir d’une autre application qui vient juste de démarrer

dans la sous-grappe qui a remporté le quorum opérationnel. Vous devez étudier ce

cas de figure si ceci peut se produit dans un système donné et dans un

environnement d’application.

Quelle que soit la méthode de protection utilisée, il est fortement recommandé

d’utiliser un système de fichiers de journalisation. Ainsi, vous protégerez le

système de fichiers contre tout type de corruption du système lui-même et

améliorera considérablement la reprise sur incident du système de fichiers suite à

sa réinitialisation.

Les méthodes de protection au niveau des noeuds peuvent être différentes.

Toutefois, la même méthode de protection est définie pour chaque noeud au sein

d’une grappe tout entière.

Méthodes de protection des ressources critiques sous

Windows

Pour indiquer comment le système doit réagir lors d’une panne du système

(BSOD) si des ressources sont actives dans une sous-grappe Windows dépourvue

de quorum, vous devez utiliser la boîte de dialogue de démarrage et de

récupération Windows. Pour plus d’informations, voir «Valeurs du quorum

opérationnel», à la page 279.

Types de conditions de départage

Dans une situation de parité où la grappe est fractionnée en sous-grappes -chacune

d’elles possédant un nombre égal de noeuds- le gestionnaire de ressources a

recours à une condition de départage pour déterminer quelle sous-grappe possède

le quorum opérationnel. La sous-grappe, qui a été retenue, disposera d’un quorum

opérationnel.


Chapitre 9. Protection de vos ressources – support réalisé par Quorum 169

Il existe plusieurs types de condition de départage qui sont :

Tableau 21. Types de conditions de départage

Condition

de

départage

Système

d’exploitation ou

plateforme Description

Operator AIX, Solaris,

Linux, Windows

Cette condition de départage demande à l’opérateur ou à

l’administrateur de prendre une décision. Tant que

l’administrateur n’a pas explicitement effectué le

départage, aucune sous-grappe ne comportera de

quorum opérationnel. L’état du quorum opérationnel est

défini sur ″PendingQuorum″ et reste dans cet état

jusqu’à ce que le réseau soit réparé, les noeuds

défectueux réparés et mis en ligne, ou jusqu’à ce que

l’opérateur détermine parmi ces grappes laquelle est

retenue et laquelle est exclue. Ceci peut se faire en

lançant ″ResolveOpQuorumTie″ sur un noeud dans

chaque sous-grappe active.

Fail AIX, Solaris,

Linux, Windows

Il s’agit d’une pseudo condition de départage, en

d’autres termes, elle ne pourra pas résoudre cette

condition. Aucune sous-grappe ne comporte de quorum

opérationnel.

SCSI Solaris, Linux sur

System i, Linux

sur System p et

Linux sur System i

Cette condition de départage présume qu’un disque SCSI

est partagé par tous les noeuds de la grappe. La

réservation de la condition de départage se fait par la

commande ’SCSI reserve’ ou ’persistent reserve’.

ECKD Linux sur System

z

Cette condition de départage présume qu’un disque

ECKD est partagé par tous les noeuds de la grappe. On

accède au disque au moyen de la commande ’ECKD

reserve’.

DISK AIX Ce type de condition de départage vous permet

d’indiquer SCSI ou un disque physique de type SCSI qui

utilise un nom de périphérique AIX et suppose que le

disque SCSI est partagé par un ou plusieurs noeuds de la

grappe. La réservation de la condition de départage se

fait par la commande ’SCSI reserve’ ou ’persistent

reserve’. Si vous créez une condition de départage de ce

type, vous devez définir l’attribut de ressource

persistante de DeviceInfo afin d’identifier le disque

physique. Seuls les disques SCSI et les disques physiques

du type SCSI sont pris en charge. Les disques physiques,

rattachés à Fiber Channel, iSCSI et Serial Storage

Architecture Connections, conviennent ici.

EXEC AIX, Solaris,

Linux, Windows

Cette condition de départage générique appelle un

élément exécutable personnalisé pour les opérations

soumises à une condition de départage. La condition de

départage du réseau "samtb_net" expédiée avec ce

produit est implémentée en tant que condition de

départage exécutable EXEC. Voir «Condition de

départage du réseau», à la page 182 pour savoir

comment configurer la condition de départage EXEC afin

d’utiliser la commande exécutable "samtb_net".

Si une grappe comprenant un nombre étrange de noeuds à l’intérieur de la grappe

est partitionnée par inadvertance, la sous-grappe comprenant plus de la moitié des

noeuds disponibles, a un quorum. Par exemple, sur une grappe à trois noeuds, la

sous-grappe disposant de deux noeuds, a un quorum. L’autre sous-grappe ne



comprenant qu’un seul noeud disponible n’a de quorum opérationnel ni de

quorum de configuration et, en conséquence, aucune ressource ne pourra être

démarrée sur ce noeud. Si une ressource critique est déjà en fonctionnement sur ce

noeud, la méthode de protection définie sera appliquée au noeud (voir «Méthodes

de protection des ressources critiques sous AIX, Solaris et Linux», à la page 168 et

«Méthodes de protection des ressources critiques sous Windows», à la page 169).

Si vous avez un nombre égal de noeuds à l’intérieur de la grappe et qu’une des

sous-grappes comprend la moitié des noeuds lorsqu’une grappe est fractionnée, en

conséquence une condition de départage détermine sur quelle sous-grappe les

ressources critiques vont être exécutées. Les noeuds où sont stockées les ressources

critiques et qui échouent au stade de la condition de départage sont soumis à la

protection de ressources, c’est-à-dire qu’ils sont arrêtés ou réinitialisés

immédiatement.

Pour réaliser un départage automatique sans intervention de l’opérateur, vous

devez utiliser un disque de départage (SCSI pour Solaris, Linux sur System i,

Power ou ECKD pour Linux sur System z, DISK pour AIX). Un disque de

départage est un disque partagé accessible par tous les noeuds à l’intérieur d’une

grappe.

SLES 10 x/Systèmes Linux : Au démarrage, RSCT supprime les modules du

programme de surveillance, tels que i8xx_tco et

i6300esb, qui peuvent avoir été préchargés pour

charger le module softdog requis. Par conséquent, un

programme de surveillance de matériel ne peut pas

être exécuté en parallèle avec System Automation for

Multiplatforms.

Fonction VMTIMEBOMB

La fonction vmtimebomb qui fonctionne pour Linux sur System z sous VM assure

la protection des données dans le cadre de scénarios où z/VM est mis en suspens

mais les systèmes hôtes Linux sont toujours en fonctionnement. Il s’agit d’une

nouvelle implémentation de méthodes de protection décrites dans la section

précédente. Depuis la perspective des Services de topologies, on peut accéder

uniquement à la fonction vmtimebomb indirectement via un module spécial VM

vmwatchdog. Ce module est similaire au module de programme de surveillance

softdog omniprésent dans Linux.

Les modules de programme de surveillance visent à empêcher un arrêt anormal en

redémarrant automatiquement le système d’exploitation en cas d’incident grave.

Généralement, une application envoie régulièrement un signal ’ping’ au

programme de surveillance (normalement en écrivant à un périphérique donné)

pour indiquer qu’il est en fonctionnement. Il permet de donner des informations

sur l’état de fonctionnement de l’ensemble du système. Si l’application échoue, ceci

signifie qu’il y a un sérieux dysfonctionnement.

Quelque chose doit surveiller l’état du programme de surveillance pour prendre

des décisions lorsque l’application signale ″all’s well″. Avec softdog, il s’agit du

système d’exploitation Linux. Dans des circonstances particulièrement extrêmes, le

système d’exploitation risque de tomber en panne et de ne plus répondre. Avec

vmwatchdog, la surveillance externe est prise en charge par le Programme de

contrôle z/VM, qui peut redémarrer le système d’exploitation sur la machine



virtuelle même dans les pires situations. Le vmwatchdog est supporté uniquement

pour les versions du kernel 2.6 fonctionnant en tant que systèmes hôtes sous

z/VM 5.1.0 (ou supérieure).

Configuration des ressources critiques

Utilisez l’attribut persistant ProtectionMode pour indiquer si la ressource est

critique. Si la ressource est critique, alors la Configuration RM (IBM.ConfigRM)

décide si la ressource peut être démarrée comme demandé. L’attribut peut

comporter les valeurs entières 0 (non–critique) ou 1 (critique). Par défaut, les

ressources IBM.Application ne sont pas –critiques, et les ressources IBM.ServiceIP

sont critiques. Si la ressource est définie sur la valeur ″Critique″, le contrôle sera

démarré immédiatement.

Exécutez la commande RSCT lsrsrc pour afficher la valeur de l’attribut

ProtectionMode :

lsrsrc IBM.Application Name NodeNameList ProtectionMode

Exécutez la commande RSCT chrsrc pour définir la ressource comme critique, en

attribuant la valeur 1 à ProtectionMode :

chrsrc -s "Name=’apache1’" IBM.Application ProtectionMode=1

Pour définir une ressource sur non–critique, définissez ProtectionMode sur 0 :

chrsrc -s "Name=’apache1’" IBM.Application ProtectionMode=0

Exécutez ce qui suit pour vérifier si les ressources critiques sont actuellement

actives sur un noeud pour une classe de ressources IBM.Application:

lsrsrc IBM.Application Name NodeNameList OpState ProtectionMode

Le résultat suivant s’affiche :

ressource 1 :

Name="apache1"

NodeNameList = {"node1","node2"}

OpState = 1

ProtectionMode = 1

ressource 2 :

Name="apache1"

NodeNameList = {"node1"}

OpState = 2

ProtectionMode = 1

ressource 3 :

Name="apache1"

NodeNameList = {"node2"}

OpState = 1

ProtectionMode = 1

La ressource critique apache1 est active sur le noeud 2.

Exécutez ce qui suit pour vérifier si les ressources critiques sont actuellement

actives sur les noeuds :

lsrsrc IBM.PeerNode Name CritRsrcActive

La sortie est la suivante :

Attributs persistants et dynamiques de la ressource pour IBM.PeerNode

ressource 1 :

Name = "node1"



CritRsrcActive = 0

ressource 2 :

Name = "node2"

CritRsrcActive = 1

Les ressources critiques sont actives sur le noeud 2.

Pour obtenir des informations du quorum

Utilisez la commande lssrc pour le démon d’IBM.RecoveryRM afin d’obtenir les

états actuels du quorum.

node02:~/build # lssrc -ls IBM.RecoveryRM


Etat du démon :

Nom du noeud : noeud02

Nom de noeud maître : neud01 (numéro du noeud = 1)

Notre CVN : 61035379498

Nombre total de noeuds: 2

Nombre de membre associé : 2

Nombre de quorum de configuration : 2

Nombre de quorum au démarrage : 1

Etat du quorum opérationnel : HAS_QUORUM

Dans Quorum de configuration : TRUE

Dans Etat de configuration: TRUE

La signification des différents attributs est la suivante :

Nombre total de noeuds

correspond au nombre de noeuds définis dans la grappe.

Nombre de membre associé

est le nombre de démons IBM.RecoveryRM fonctionnant dans la

grappe. Il équivaut au nombre de noeuds actifs dans la

(sous)grappe.

Nombre de quorum de configuration

est le nombre de démons IBM.RecoveryRM qui doit être actif afin

d’ajouter des modifications au sein de la configuration au moyen

des commandes de la System Automation for Multiplatforms.

Nombre de quorum au démarrage

Est le nombre de démons IBM.RecoveryRM devant être actifs avant

que le moteur d’automatisation de la System Automation for

Multiplatforms ne soit activé.

Etat du quorum opérationnel

Indique si la grande (sous)grappe peut survivre ou doit être

immédiatement dissoute au cas où des ressources critiques

fonctionnent sur le(s)noeud(s) à l’intérieur de la sous-grappe. L’état

du quorum opérationnel est fourni par l’attribut dynamique

OpQuorumState de la classe PeerDomain. OpQuorumState peut

comporter les valeurs suivantes :

0 – HAS_QUORUM

System Automation for Multiplatforms peut

démarrer les ressources

1 – PENDING_QUORUM

Indique qu’une situation de parité s’est produite et

n’a toujours pas été résolue. System Automation

for Multiplatforms ne démarre aucune ressource.



2 – NO_QUORUM

System Automation for Multiplatforms n’est pas

autorisée à démarrer des ressources.

Dans Quorum de configuration

Indique si un nombre suffisant de noeuds hébergeant les démons

IBM.RecoveryRM sont actifs pour accepter les modifications de

configuration par les commandes de System Automation for

Multiplatforms. Indique TRUE si le nombre total de membres du

groupe du démon IBM.RecoveryRM ″associés″ au sein de la

grappe est égal ou supérieur au nombre figurant au niveau du

quorum de configuration.

Dans Etat de la configuration

Indique si le démon-maître IBM.RecoveryRM a terminé la

vérification du contenu du registre système au démarrage. Si l’état

affiche FALSE, toute commande de System Automation for

Multiplatforms sera rejetée.

Entrez ce qui suit dans OpQuorumState :

lsrsrc IBM.PeerDomain Name OpQuorumState


Attributs persistants et dynamiques de la ressource pour : IBM.PeerDomain

ressource 1 :

Name = "myCluster"

OpQuorumState = 0

Configuration et gestion d’une condition de départage

La classe de ressources IBM.TieBreaker vous permet de configurer une condition

de départage telle qu’ECKD ou SCSI. De plus, deux conditions de départage sont

prédéfinies, Operator et Fail. La condition de départage de type Operator donne

un résultat indéterminé lorsqu’une situation de parité se produit et c’est à

l’administrateur de résoudre cette situation de parité en autorisant ou en refusant

le quorum opérationnel. Lorsqu’une situation de parité se produit et qu’une

situation de départage du type ″Fail″ est active, la tentative de réservation de la

condition de départage est toujours refusée. Le type de condition de départage par

défaut est défini sur ’Operator’.

Afin de répertorier le type de condition de départage disponible :

lsrsrc -c IBM.TieBreaker

Vous obtenez la sortie suivante sur un système Linux fonctionnant sur System x,

System p ou System i :

Attributs persistants d’une classe de ressources pour : IBM.TieBreaker

ressource 1 :

AvailableTypes ={["SCSI",""],["EXEC",""],["Operator",""],["Fail",""]}

Pour répertorier le nom de la condition de départage :

lsrsrc IBM.TieBreaker


Attributs persistants de ressource pour : IBM.TieBreaker

ressource 1 :

Name = "FAIL"

Type = "FAIL"

DeviceInfo = ""



ReprobeData = ""

ReleaseRetryPeriod = 0

HeartbeatPeriod = 0

PreReserveWaitTime = 0

PostReserveWaitTime = 0

NodeInfo = {}

ressource 2 :

Name = "Operator"

Type = "Operator"

DeviceInfo = ""

ReprobeData = ""


HeartbeatPeriod = 0



NodeInfo = {}

ressource 3 :

Name = "myTieBreaker"

Type = "SCSI"

DeviceInfo = "ID=0 LUN=0 CHAN=0 HOST=2"

ReprobeData = ""


HeartbeatPeriod = 5



NodeInfo = {}

ressource 4:

Name = "mytb"

Type = "EXEC"

DeviceInfo = "PATHNAME=/usr/sbin/rsct/bin/samtb_net

Address=192.168.177.2"

ReprobeData = ""


HeartbeatPeriod = 30



NodeInfo = {}

ActivePeerDomain = "21"

Bien que vous puissiez définir plusieurs ressources de condition de départage dans

la classe de ressources IBM.TieBreaker, seule l’une de ces conditions peut être

active au sein de la grappe en même temps. Exécutez la commande suivante pour

répertorier la condition de départage qui est actuellement active dans la grappe :

lsrsrc -c IBM.PeerNode OpQuorumTieBreaker


Attributs persistants de la classe de ressources pour : IBM.PeerNode

ressource 1 :

OpQuorumTieBreaker = "Operator"

La condition de départage active est définie au moyen de cette commande :

chrsrc -c IBM.PeerNode OpQuorumTieBreaker="Operator"

Pour accepter/refuser le quorum opérationnel lorsqu’une condition de départage

est de type ″Operator″ :

runact -c IBM.PeerDomain ResolveOpQuorumTie Ownership=1 (0 pour refuser)

Remarque : Afin d’éviter des conditions d’indétermination, la condition de

départage de l’opérateur doit être refusée en premier lieu concernant



la/les sous-grappe(s) perdante avant de l’autoriser dans la

sous-grappe qui est supposée continuer.

Utilisation d’une condition de départage

Pour créer une configuration de base de la condition de départage, vous avez

besoin d’une grappe de deux (ou toute autre valeur entière) de noeuds. Vous avez

également besoin d’un disque partagé par tous les noeuds de la grappe. Le disque

sur lequel s’applique la condition de départage est partagé entre tous les noeuds

de la grappe.

Attention : Lors de la définition des ressources à départager, gardez toujours à

l’esprit que le disque sur lequel les ressources IBM.TieBreaker sont stockées, ne

doit pas être utilisé pour stocker les systèmes de fichiers.

Les trois exemples suivants montrent comment utiliser une condition de départage

avec un périphérique ECKD, SCSI ou DISK. Notez que la condition de départage

n’a pas besoin d’être formatée ou segmentée. Par conséquent, elle sera marquée

active sans informations de taille (pour ECKD).

Exemple 1 : configuration d’une condition de départage ECKD

pour une grappe à deux noeuds

Notez ce qui suit lorsque vous définissez un disque à départager sous VM :

v L’ensemble du mini-disque doit être défini.

v Si la mémoire cache du mini-disque est utilisé, sa valeur devrait être définie sur

″off″.

v Deux noeuds se partagent le disque ECKD.

Le type de condition de départage s’appliquant à ECKD concerne Linux sur

System z. Si vous souhaitez créer une condition de départage au niveau d’ECKD,

vous devez configurer l’attribut persistant de la ressource DeviceInfo pour indiquer

le numéro du périphérique ECKD. Ce type de condition de départage utilise un

mécanisme de réservation/libération et devra être réservée de nouveau

périodiquement pour mettre la réservation en suspens. C’est pour cette raison que

nous vous recommandons fortement d’indiquer l’attribut persistant de ressource

HearbeatPeriod lors de la création d’une condition de départage de ce type.

L’attribut persistant de ressource HearbeatPeriod définit l’intervalle dans lequel la

requête de réservation est émise à nouveau.

Notez les informations système suivantes (Linux kernel 2.4) :

node01:~ # cat /proc/subchannels

Device sch. Dev Type/Model CU in use PIM PAM POM CHPIDs

---------------------------------------------------------------------

50DE 0A6F 3390/0A 3990/E9 F0 A0 FF 7475E6E7 FFFFFFFF

node01:~ # cat /proc/dasd/devices

50dc(ECKD) at ( 94: 0) is : active at blocksize: 4096, 601020 blocks, 2347 MB

50dd(ECKD) at ( 94: 4) is : active at blocksize: 4096, 601020 blocks, 2347 MB

50de(ECKD) at ( 94: 8) is : active at blocksize: 4096, 601020 blocks, 2347 MB

50df(ECKD) at ( 94: 12) is : active at blocksize: 4096, 601020 blocks, 2347 MB

Pour Linux kernel 2.6, utilisez la commande lscss au lieu de la commande cat

/proc/subchannels.Pour utiliser la condition de départage, procédez comme suit :

1. Créez un objet de ressource à départager dans la classe IBM.TieBreaker.

DeviceInfo indique le numéro du périphérique ECKD. Vous pouvez l’obtenir

dans le fichier /proc/dasd/devices.

node01:~ # mkrsrc IBM.TieBreaker Name=myTieBreaker Type=ECKD DeviceInfo="ID=50de" HeartbeatPeriod=5



node01:~ # lsrsrc IBM.TieBreaker

Attributs persistants de ressource pour : IBM.TieBreaker

ressource 1 :

Name = "Operator"

Type = "Operator"

DeviceInfo = ""

ReprobeData = ""


HeartbeatPeriod = 0



NodeInfo = {}

ressource 2 :

Name = "Fail"

Type = "Fail"

DeviceInfo = ""

ReprobeData = ""


HeartbeatPeriod = 0



NodeInfo = {}

ressource 3 :

Name = "myTieBreaker"

Type = "ECKD"

DeviceInfo = "ID=50de"

ReprobeData = ""


HeartbeatPeriod = 5



NodeInfo = {}

2. Remplacez l’attribut OpQuorumTieBreaker dans la classe IBM.PeerNode par

l’un des objets de ressource à départager.

node01:~ # chrsrc -c IBM.PeerNode OpQuorumTieBreaker="myTieBreaker"

node01:~ # lsrsrc -c IBM.PeerNode

Attributs persistants de la classe de ressources pour : IBM.PeerNode

ressource 1 :

CommittedRSCTVersion = ""

ActiveVersionChanging = 0

OpQuorumOverride = 0

CritRsrcProtMethod = 1

OpQuorumTieBreaker = "myTieBreaker"

Astuces : Si un noeud d’une grappe de deux noeuds est réinitialisé, le noeud

réinitialisé peut revenir très rapidement. Cette opération risque de perturber la

méthode de départage et entraîner une réinitialisation intempestive du noeud

restant. Si un noeud appartenant à une grappe doit être réinitialisé manuellement,

utilisez la commande halt -nf à la place de reboot -nf.

Si le noeud sur lequel s’applique la condition de départage ne répond plus et qu’il

ne peut être réinitialisé, il faudra intervenir manuellement sur un autre noeud pour

rompre la réservation et pour qu’il prenne la relève sur l’autre noeud. Le disque

sur lequel s’applique la condition de départage peut

v être soit rattaché au noeud fonctionnant correctement, à condition que ce noeud

ne soit pas réinitialisé :



--------------------------------------------------------------

50DE 0A6F 3390/0A 3990/E9 F0 A0 FF 7475E6E7 FFFFFFFF


50de(ECKD) at ( 94: 8) is dasdc: active at blocksize: 4096,601020 blocks, 2347 MB



v être réinitialisé, si le noeud a été réinitialisé et ne peut plus reconnaître le disque

à départager :



--------------------------------------------------------------

50DE 0A6F FFFF/00 F0 A0 FF 7475E6E7 FFFFFFFF


50de(ECKD) at ( 94: 8) is dasdc : boxed

Pour rompre la réservation au niveau du disque à départager, entrez la

commande /usr/sbin/rsct/bin/tb_break:

tb_break -t ECKD /dev/dasdc

Le disque à départager ne devrait pas être réservé par le noeud en bon état de

fonctionnement.

Remarque : Si la commande tb_brk ne fonctionne pas la première fois, exécutez-la

de nouveau.

Exemple 2 : configuration d’une condition de départage SCSI

pour une grappe à deux noeuds

Le type de condition de départage SCSI est propre à Solaris, Linux sur System i,

pSeries et iSeries. Si vous souhaitez créer un objet à départager au niveau de SCSI,

vous devez indiquer le périphérique SCSI à l’aide de l’attribut persistant

DeviceInfo de la ressource. Si la configuration est différente au niveau de plusieurs

noeuds à l’intérieur de la grappe, vous pouvez également utiliser l’attribut

persistant NodeInfo de la ressource pour faire apparaître ces différences. Ce type

de condition de départage utilise un mécanisme de réservation/libération et devra

être réservée de nouveau périodiquement pour mettre la réservation en suspens.

C’est pour cette raison que nous vous recommandons fortement d’indiquer

l’attribut persistant de ressource HearbeatPeriod lors de la création d’une condition

de départage de ce type. L’attribut persistant de ressource HearbeatPeriod définit

l’intervalle dans lequel la requête de réservation est émise à nouveau.

Linux : Sous Linux, les unités SCSI peuvent être identifiées par les quatre valeurs

entières des attributs HOST, CHAN, ID et LUN :

node1:~# dmesg | grep "Attached scsi disk"

Généralement, ces paramètres sont identiques sur chaque noeud de la grappe.Par exemple, pour les noeuds 1 et 2, on obtient HOST=0 CHAN=0 ID=4 LUN=0.Vous pouvez ensuite créer l’objet à départager :

mkrsrc IBM.TieBreaker Name=myTieBreaker Type=SCSI DeviceInfo=" HOST=0 CHAN=0 ID=4 LUN=0"

Les quatre valeurs susmentionnées peuvent aussi être différentes sur les noeuds

(même si le périphérique cible est le même). Dans ce cas, il faudrait utiliser la zone

NodeInfo.

Utilisez les quatre valeurs entières issues du résultat de la commande :

# dmesg | grep "Attached scsi disk"

Attached scsi disk sdf at scsi2, channel 2, id 4, lun 0

Pour le disque sdf, on obtient HOST=2, CHAN=2, ID=4, LUN=0.Par exemple, un périphérique SCSI est connecté à 2 noeuds appelés node1 et

node2 et comporte les identificateurs SCSI suivants :

node1: HOST=0 CHAN=0 ID=4 LUN=0

node2: HOST=2 CHAN=2 ID=4 LUN=0



Vous pouvez alors créer l’objet à départager de la façon suivante

# mkrsrc IBM.TieBreaker Name=scsi Type=SCSI DeviceInfo="ID=4 LUN=0"

NodeInfo=’{["node1", "HOST=0 CHAN=0"], ["node2", "HOST=2 CHAN=2"]}’

System Automation for Multiplatforms traite DeviceInfo et NodeInfo de telle

manière qu’il fusionne les deux chaînes, en commençant par DeviceInfo puis

NodeInfo. Par exemple, pour le premier noeud ″node1″, la chaîne fusionnée est

"ID=4 LUN=0 HOST=0 CHAN=0"

qui sera ensuite analysée.

Tous les mots clés en double seront autorisés et le dernier sera utilisé. Par

conséquent, la même commande peut être indiquée en tant que

# mkrsrc IBM.TieBreaker Name=myTieBreaker Type=SCSI DeviceInfo="ID=4 LUN=0

HOST=0,CHAN=0" NodeInfo=’{["node2", "HOST=2 CHAN=2"]}’

Cette simplification peut être utile puisque l’ID SCSI est le même pour la plupart

des noeuds.

Astuce : Si le noeud sur lequel la condition de départage doit s’appliquer est hors

service ou ne peut être réinitialisé, il faudra accéder manuellement à un autre

noeud pour libérer le disque SCSI à départager. Pour libérer un disque, exécutez la

commande :

tb_break [–f] HOST CHAN ID LUN

par exemple,

/usr/sbin/rsct/bin/tb_break –f HOST=0 CHAN=0 ID=4 LUN=0

Solaris : Sous Solaris, les unités SCSI peuvent être identifiées par le nom de

l’unité de disque.

node1:~# format

Searching for disks...done

AVAILABLE DISK SELECTIONS:

0. c0t0d0 <DEFAULT cyl 8894 alt 2 hd 255 sec 63>

/pci@0,0/pci1022,7450@2/pci1000,3060@3/sd@0,0

1. c5t60050768018200A88000000000000064d0 <DEFAULT cyl 96 alt 2 hd 64 sec 32>

/scsi_vhci/disk@g60050768018200a88000000000000064

Vous pouvez alors créer l’objet à départager de la façon suivante

# mkrsrc IBM.TieBreaker Name=myTieBreaker Type=SCSI

DeviceInfo="DEVICE=c5t60050768018200A88000000000000064d0" HeartbeatPeriod=5

Astuce : Si le noeud sur lequel la condition de départage doit s’appliquer est hors

service ou ne peut être réinitialisé, il faudra accéder manuellement à un autre

noeud pour libérer le disque SCSI à départager. Pour libérer un disque, exécutez la

commande :

tb_break -b -t SCSI "DEVICE=<nom_unité>"

par exemple,

# /usr/sbin/rsct/bin/tb_break -b -t SCSI

"DEVICE=c5t60050768018200A88000000000000064d0"

Exemple 3 : configuration d’une condition de départage AIX pour

une grappe à deux noeuds

Le type de départage de DISK s’applique à AIX. Si vous souhaitez créer un objet

DISK à départager, vous devez définir un attribut persistant DeviceInfo pour



indiquer le nom de l’unité sous AIX. Le nom de l’unité sous AIX doit indiquer un

disque SCSI ou un disque physique de type SCSI partagé par tous les noeuds dans

le domaine homologue.

Les disques physiques rattachés via Fiber Channel, iSCSI, et Serial Storage

Architecture peuvent servir de condition de départage de DISK. Toutefois, les

disques durs IDE ne prennent pas en charge le protocole SCSI, en conséquence ils

ne peuvent être départagés. Les volumes logiques ne peuvent pas non plus être

départagés. Ce type de condition de départage utilise un mécanisme de

réservation/libération et devra être réservée de nouveau périodiquement pour

mettre la réservation en suspens. C’est pour cette raison que nous vous

recommandons fortement d’indiquer l’attribut persistant de ressource

HearbeatPeriod lors de la création d’une condition de départage de ce type.

L’attribut persistant de ressource HearbeatPeriod définit l’intervalle dans lequel la

requête de réservation est émise à nouveau.

Pour imprimer tous les volumes physiques connus présents dans le système ainsi

que le nom du disque physique de chaque volume, entrez la commande lspv :

lspv

Un résultat similaire au résultat suivant s’affiche :

hdisk0 000000371e5766b8 rootvg active

hdisk1 000069683404ed54 None

Pour vérifier qu’un disque est de type SCSI ou compatible SCSI et qu’il peut donc

servir de condition de départage DISK, utilisez la commande lsdev. Par exemple :

lsdev -C -l hdisk1

Une sortie de ce type s’affichera :

hdisk1 Available 10-60-00-0,0 16 Bit SCSI Disk Drive

Pour servir de disque à départager, le disque doit être partagé par tous les noeuds

dans le domaine homologue. Vérifiez l’ID du volume physique issu de la

commande lspv pour déterminer si le disque est partagé par plusieurs noeuds

(dans la sortie précédente pour la commande lspv, l’ID du volume physique est

répertorié dans la seconde colonne ; l’ID du volume pour hdisk1 est

000069683404ed54.) Cependant, gardez à l’esprit que le système AIX se souvient de

tous les disques qui ont été attachés au système. Les disques répertoriés par la

commande lspv peuvent ne plus être attachés. Si ce disque a été déplacé dans une

autre machine, il apparaîtra en tant que disque partagé, alors qu’en réalité il n’est

plus rattaché à la première machine.

Le disque sur lequel les ressources IBM.TieBreaker sont stockées ne devrait pas être

uniquement utilisé pour stocker des systèmes de fichiers. Si les noeuds dans la

grappe partagent plus d’un disque, il peut s’avérer difficile de déterminer quel est

le disque sur lequel s’applique la condition de départage et quel est le disque

réservé aux données applicatives. La sortie issue de la commande lsdev affiche

l’adresse SCSI associée au disque. (Dans le résultat précédent issu de la commande

lsdev, l’adresse SCSI est répertoriée dans la troisième colonne ; l’adresse SCSI

pourhdisk0 est 10-60-00-0,0.) Ces informations vous aideront à identifier le disque

approprié si vous connaissez l’adresse du disque avant son installation.

Une fois que vous connaissez le nom de l’unité, vous pouvez exécuter la

commande mkrsrc :

mkrsrc IBM.TieBreaker Name=myTieBreaker Type=DISK DeviceInfo="DEVICE=/dev/hdisk1" HeartbeatPeriod=5



Astuce : La condition de départage s’appuie sur la réservation SCSI-2, qui n’est

pas forcément prise en charge par toutes les combinaisons de configuration de

système de stockage et de pilote. Pour vérifier que la configuration prend en

charge la réservation SCSI-2, RSCT est livré avec l’utilitaire disk_reserve, qui doit

être appelé en spécifiant son chemin d’accès complet (/usr/sbin/rsct/bin/disk_reserve).

La condition de départage ne fonctionne pas correctement si son disque peut être

réservé et déverrouillé par l’un des deux noeuds et que le disque ne peut pas être

réservé lorsqu’il est verrouillé par l’autre noeud.

Syntaxe :Utilisation :

/usr/sbin/rsct/bin/disk_reserve [-l | -u | -b] [-h] [-v] [-f]

[-d nom_disque_serveur]

/usr/sbin/rsct/bin/disk_reserve [-l | -u | -b] [-h] [-v] [-f]

[-g nom_unité_groupe_serveurs]

-h - affiche ce texte d’aide

-v - prolixe

-f - réserve après la rupture (pour l’option -l ou -b)

-d nom_disque_serveur - disque à utiliser (par exemple, /dev/sdb)

-l - verrouile (réserve)

-u - déverrouille (libère)

-b - effectue une rupture

-g nom_unité_groupe_serveurs (par exemple, /dev/sg1)

Exemples :

/usr/sbin/rsct/bin/disk_reserve -l -f -d /dev/sde

/usr/sbin/rsct/bin/disk_reserve -l -g /dev/sg3

Si le noeud sur lequel la condition de départage doit s’appliquer est hors service

ou ne peut être réinitialisé, il faudra accéder manuellement à un autre noeud pour

libérer le disque SCSI à départager. Pour libérer le disque, exécutez la commande :

/usr/sbin/rsct/bin/tb_break –f –t DISK "DEVICE=/dev/hdisk1"

Exécutez la commande lspath. Exemple :

lspath -l hdisk2

lspath: 0514-538 Impossible d’effectuer la fonction demandée car l’unité spécifiée

ne prend pas en charge plusieurs chemins d’accès.

Exemple de sortie :Contrairement à l’exemple ci-dessus, l’exemple suivant ne prend pas en charge la

réservation SCSI-2 et donc la condition de départage.

#lspath -l hdisk2

Enabled hdisk2 fscsi0

Failed hdisk2 fscsi0















Vérification de la capacité des ressources à jouer le rôle de

disques de départage

Les disques de départage réalisent une réservation SCSI-2 sur le disque SCSI

défini. Pour qu’une ressource puisse être considérée comme une condition de

départage valide, elle doit répondre aux conditions suivantes :

v Le disque doit être accessible à partir de tous les noeuds simultanément

(directement connecté à chaque noeud).

v La réservation SCSI-2 doit être en mesure de réserver le disque.

v La réservation SCSI-2 doit réserver le disque de manière exclusive. Les

demandes de réservation en provenance d’un autre noeud seront rejetées.

La troisième condition peut ne pas concerner les environnements virtuels tels que

les disques connectés à des interfaces d’entrée-sortie virtuelles sur System p.

Suivez la procédure ci-dessous pour savoir si la réservation exclusive fonctionne

sur un disque donné :

1. Créez un domaine à deux noeuds et définissez une ressource de disque de

départage. Pour vérifier qu’aucune ressource n’est en ligne, arrêtez la ressource

définie et ne créez pas d’autres ressources.

2. Connectez-vous à la console des deux noeuds et lancez l’énumération du

journal système (par exemple, tail -f /var/log/messages sur un système Linux).

3. Désactivez la connexion réseau sur un des noeuds, par exemple en débranchant

le ou les câbles réseau ou en utilisant la commande ifconfig <if> down.

4. Vérifiez le résultat renvoyé par le journal système : après quelques secondes,

l’un des noeuds doit indiquer ’HAS_QUORUM’ et l’autre noeud

’PENDING_QUORUM’. Si les deux noeuds indiquent ’HAS_QUORUM’, le

disque ne peut pas être utilisé, car la réservation n’est pas exclusive. Le disque

ne sera pas en mesure de résoudre les gros problèmes de dédoublement.

Si le domaine se compose de plus de deux noeuds, la vérification se déroule de la

même manière. Le réseau doit être divisé en deux parties, le même nombre de

noeuds devant être présent dans chaque moitié, et l’état du quorum doit ensuite

être déterminé sur un noeud d’une sous-grappe.

Les disques de réseau de stockage SAN, par exemple, ne peuvent pas jouer le rôle

de ressources de disques de départage.

Condition de départage du réseau

La condition de départage du réseau présente une alternative aux conditions de

départage du disque et de l’opérateur décrites dans les sections précédentes de ce

chapitre. Elle utilise une IP (instance de réseau) pour résoudre une situation de

parité.



Il peut y avoir plusieurs raisons justifiant l’utilisation d’une condition de départage

du réseau, comme par exemple :

v Il est impossible d’utiliser une condition de départage du disque.

v La priorité supérieure est de permettre à l’environnement à haute disponibilité

de communiquer avec les instances en dehors de la grappe.

Exemple : Les fonctions essentielles d’un serveur Web sont de délivrer des pages

Web aux clients en dehors de la grappe. Afin de rendre ce service hautement

disponible, la condition de départage ne devrait pas autoriser l’accès à un noeud

incapable de communiquer aux instances en dehors de la grappe.

La condition de départage du réseau doit être utilisée uniquement pour les

domaines dans lesquels tous les noeuds se trouvent dans le même sous-réseau IP.

Si les noeuds se trouvent dans des sous-réseaux IP différents, le risque de voir les

deux noeuds envoyer des commandes ping à la condition de départage de réseau

est plus élevé, alors même qu’ils ne peuvent pas communiquer entre eux. Par

ailleurs, l’adresse IP de la passerelle par défaut ne doit pas être utilisée si elle est

virtualisée par l’infrastructure du réseau. Choisissez une adresse IP accessible

exclusivement par le biais d’un chemin unique à partir de chaque noeud du

domaine.

Conditions requises pour la condition de départage du réseau

Pour assurer la fonction de condition de départage du réseau, l’instance de réseau

IP externe doit pouvoir être atteinte par tous les noeuds au sein d’une grappe

hautement disponible. L’instance du réseau IP externe doit pouvoir répondre aux

demandes d’écho dans ICMP (ping). Si vous définissez une règle de pare-feu qui

aura pour effet de bloquer le trafic dans ICMP entre les noeuds de la grappe et

l’instance du réseau IP, par conséquent la condition de départage du réseau ne

fonctionnera pas. Le risque le plus grave est que les noeuds de la grappe ne

pourront plus communiquer avec leurs homologues (fractionnement de la grappe),

mais les deux sous-grappes pourront atteindre l’instance du réseau IP. Dans des

conditions normales de fonctionnement, IP veille à : si les deux sous-grappes

peuvent atteindre la passerelle externe, elles peuvent aussi communiquer avec

leurs homologues. Certaines configurations inhabituelles de l’instance du réseau IP

ne respecteront pas cette règle (par ex. paramètres du pare-feu). Si vous ne pouvez

pas respecter cette règle, vous ne pourrez pas utiliser la condition de départage du

réseau.

La table suivante présente les avantages et les inconvénients de ces deux types de

conditions de départage :

Tableau 22. Comparaison entre une condition de départage du réseau et une condition de

départage du disque

Condition de départage du réseau Condition de départage du disque

+ Aucune dépendance matérielle

+ Evalue la disponibilité de

communication.

+ Condition de départage sécurisée.

Le matériel veille à ce qu’une seule

instance (noeud) puisse être

soumise à une condition de

départage.



Tableau 22. Comparaison entre une condition de départage du réseau et une condition de

départage du disque (suite)

Condition de départage du réseau Condition de départage du disque

- Si l’instance IP externe n’est pas

disponible en cas de fractionnement

d’une grappe, aucune sous-grappe

n’aura de quorum.

- Des conditions d’erreur dans

lesquelles une situation de parité se

produit mais où plusieurs noeuds

peuvent communiquer peuvent

avoir lieu. Dans ce cas, il y a une

petite chance pour que les deux

sous-grappes puissent être soumises

à la condition de départage.

- Si la communication est rompue,

cette condition de départage peut

garantir l’accès à un noeud qui ne

peut communiquer avec les

instances situées en dehors de la

grappe.

Configuration d’une condition de départage s’appliquant au

réseau

La condition de départage du réseau est réalisée en tant que condition de

départage exec du RSCT. Voir la documentation sur RSCT si vous souhaitez en

savoir plus concernant la commande exec de la condition de départage - La

commande exécutable de la condition de départage samtb_net se trouve dans le

répertoire /usr/sbin/rsct/bin. Lors de l’implémentation, les options suivantes

devront être spécifiées en tant que mots clés au cours de la création de la condition

de départage d’une commande exec RSCT.

Address=<IP address>

Adresse de l’instance IP externe qui devrait être utilisée pour

résoudre une situation de parité. Indiquez une adresse IPv4 en

format point, par exemple 192.168.1.1. N’utilisez pas de nom DNS

car en cas de problèmes de communication, survenant

généralement lors du fractionnement de la grappe, DNS ne pourra

fonctionner correctement. L’adresse doit impérativement figurée,

aucune option par défaut n’est disponible.

Log=<1/0> Indiquez 1 si vous souhaitez que la condition de départage du

réseau rédige des journaux systèmes dans la fonction journal

système (syslog). La valeur par défaut est 1. Les valeurs autorisées

sont 1 et 0.

Count=<number>

Nombre de demandes d’écho dans ICMP envoyées pour

déterminer le quorum. Si la première requête obtient une réponse,

aucune autre requête n’est envoyée. La valeur par défaut est 2. La

gamme de valeurs autorisée est comprise entre 1 et 9.

La commande suivante générera une nouvelle condition de départage du réseau :

# mkrsrc IBM.TieBreaker Type="EXEC" Name="mynetworktb"

DeviceInfo=’PATHNAME=/usr/sbin/rsct/bin/samtb_net Address=192.168.1.1

Log=1’ PostReserveWaitTime=30;

Activez votre condition de départage du réseau comme suit :

# chrsrc -c IBM.PeerNode OpQuorumTieBreaker="mynetworktb"



Vous pouvez utiliser n’importe quelle commande normale RSCT pour manipuler la

définition de la condition de départage du réseau. Pour supprimer la définition de

condition de départage, utilisez la commande rmrsrc.

Quelques informations préalables à connaître concernant la condition de

départage du réseau. : Le principe de la condition de départage RSCT repose sur

l’idée que lorsqu’un noeud réserve une condition de départage, celle-ci n’est plus

disponible et ne peut pas être réservée par un autre noeud.

Puisque ceci ne s’applique pas à un réseau (condition de départage d’un réseau),

certaines restrictions ont été introduites dans la conception de base de la condition

de départage.

Comportement de réservation : après l’échec d’une tentative de réservation, aucune

autre réservation n’est autorisée tant que le noeud n’a pas rejoint la grappe. Pour

garantir cela, un fichier doit figurer dans /var/ct/ indiquant de ce fait qu’un échec

de la réservation s’est produit. Si ce fichier est présent, tout appel vers une

réservation de condition de départage échouera obligatoirement. Il existe un autre

processus engendré qui observe le quorum et supprime le fichier des blocs si le

noeud a été de nouveau ajouté au domaine.

L’exemple de fichier suivant a été créé par la condition de départage du réseau

suite à l’échec d’une opération de réservation de la condition de départage vers

l’instance du réseau IP externe 192.168.1.1. Il comprend l’horodatage de l’échec de

l’opération de réservation.

# cat /var/ct/samtb_net_blockreserve_192.168.1.1

Mo Jul 4 08:38:40 CEST 2005

Configuration d’une condition de départage RSCT dans le cadre du départage

du réseau : Cette section décrit les options de configuration les plus importantes

pour une définition de condition de départage RSCT et vous donne un aperçu de

la manière de les configurer pour une condition de départage du réseau.

PostReserveWaitTime=30

En cas d’échec d’une réservation, ConfigRM va périodiquement

appeler l’opération de réservation à départager. Etant donné que la

condition de départage du réseau ne tient compte que de la

première tentative de réservation et bloque les réservations

périodiques au cas où un échec de réservation s’est produit

auparavant, PostReserveWaitTime doit être défini sur un nombre

maximal de valeur, 30 le cas échéant. Ceci évitera la surcharge du

système au cas où un noeud resterait en attente sur l’état du

Quorum (appels périodiques pour départager la réservation).

HeartbeatPeriod=30

Après la réussite d’une réservation, ConfigRM commence à appeler

périodiquement une opération heartbeat à départager. Pour que le

système ne soit par surchargé lors du fractionnement de la grappe,

augmentez le délai entre les signaux de présence ou mettez-les

hors fonction en définissant l’attribut HeartbeatPeriod sur 0.



Révision des journaux système d’un scénario de condition de départage du

réseau : Voici les journaux système d’une grappe à deux noeuds (n1 et n2). Pour

le scénario d’erreur, on suppose qu’aucune ressource critique ne fonctionne sur les

deux noeuds. Un problème de réseau interrompra tous les chemins de

communication disponibles entre les homologues, mais un homologue (n2) peut

encore communiquer avec sa passerelle (192.168.177.2). Après un certain temps et

une fois la communication rétablie, les deux noeuds peuvent être ajoutés à la

grappe.

Remplacement du quorum opérationnel

Pour supprimer des noeuds de la grappe, au moins un des noeuds présents dans

la grappe doit être en ligne pour exécuter la commande rmrpnode. S’il n’y a pas

assez de noeuds pour atteindre un quorum opérationnel, il est impossible d’ajuster

la taille de la grappe en tant qu’administrateur afin que le quorum soit rétabli.

Si pour une raison ou pour une autre, la fonction de quorum opérationnel doit être

désactivée, l’attribut persistant OpQuorumOverride doit être défini sur 1 :

chrsrc –c IBM.PeerNode OpQuorumOverride=1

Dans ce cas, l’état de quorum opérationnel est toujours HAS_QUORUM et la

protection de la ressource n’est plus assurée.

Figure 11. Journaux système d’une grappe à deux noeuds



Chapitre 10. Contrôle et administration de System Automation

for Multiplatforms

Ce chapitre décrit les divers paramètres pouvant être utilisés pour contrôler et

modifier les comportement général de System Automation for Multiplatforms. Il

donne également un aperçu général de l’infrastructure de System Automation for

Multiplatforms et donne quelques conseils et astuces judicieux.

Contrôle de System Automation for Multiplatforms

Vous pouvez utiliser plusieurs attributs pour modifier le comportement général de

System Automation for Multiplatforms. Vous pouvez lancer/arrêter la fonction

d’automatisation, définir des expirations ou exclure des noeuds de

l’automatisation, par exemple, pour des raisons de maintenance.

Ces attributs sont les suivants :

v TimeOut

Indique la valeur du délai d’attente en secondes pour une opération de contrôle

de démarrage exécuté par System Automation for Multiplatforms. Lorsque le

délai d’attente expire, l’opération est répétée si le nombre de tentatives autorisé

(RetryCount) n’est pas dépassé.

v RetryCount

Nombre de tentatives autorisées lorsqu’une opération de contrôle échoue ou que

son délai d’attente expire.

v Automation

Indicateur qui active ou désactive l’automatisation par System Automation for

Multiplatforms.

v ExcludedNodes

Liste de noeuds sur lesquels System Automation for Multiplatforms exclut de

manière active les ressources ou les arrête. Peut être utilisé à des fins de

maintenance, par exemple.

v ResourceRestartTimeOut

Délai en secondes au cours duquel System Automation for Multiplatforms

attend avant de redémarrer les ressources situées sur un noeud défectueux dans

un autre noeud.

v TraceLevel

Le niveau de trace peut être utilisé pour contrôler le volume d’entrées de trace

écrites. La valeur maximale est de 255 résultats pour la trace très détaillée et la

valeur 0 supprime l’écriture des différentes classes d’entrées de trace. La

réduction du niveau de trace est recommandée pour les règles d’automatisation

avec un grand nombre de ressources.

Les valeurs actuelles des attributs décrits ci-dessus peuvent être répertoriées avec

la commande lssamctrl. Les attributs sont modifiés à l’aide de la commande

samctrl. Pour obtenir une liste et une description de ces commandes, reportez-vous

à Guide de référence d’IBM Tivoli System Automation for Multiplatforms.


TimeOut et RetryCount

L’attribut TimeOut est toujours utilisé en association avec l’attribut RetryCount :

TimeOut

Indique le délai d’attente au cours duquel System Automation for

Multiplatforms attend que le gestionnaire de ressources entreprenne une

action.

RetryCount

Indique le nombre de tentatives d’opérations de contrôle possibles que

System Automation for Multiplatforms effectuera au cours du délai de

TimeOut si l’opération de contrôle échoue. En général, si la première

tentative échoue, les chances que l’opération aboutisse à la seconde

tentative ou aux suivantes sont relativement faibles.

Opérations de démarrage

Le temporisateur des opérations est lancé lorsque System Automation for

Multiplatforms envoie la première opération de contrôle de démarrage pour une

ressource. Une fois qu’il est lancé, il existe plusieurs possibilités :

1. La ressource est modifiée avec l’état souhaité (en ligne ou hors ligne) au cours

du délai d’attente. Dans ce cas, aucune autre action n’est déclenchée car la

ressource possède l’état que System Automation for Multiplatforms lui a

affecté.

2. La ressource rejette le contrôle de démarrage au cours du délai d’attente. Ce

qui se produit ensuite dépend du code de refus :

v Si ce code indique que l’erreur est remédiable, System Automation for

Multiplatforms continue de lancer des opérations de contrôle de démarrage

sur la ressource. Chaque tentative d’opération de contrôle est comptée.

Lorsque la valeur de RetryCount est dépassée, System Automation for

Multiplatforms arrête de lancer d’autres opérations de contrôle.

v Si l’erreur n’est pas remédiable, la ressource entrera dans un état de

défectuosité. Que cet incident déclenche ou non d’autres actions

d’automatisation dépend du type de ressource sur laquelle l’opération de

démarrage a été lancée :

– Si une ressource fixe est affectée, aucune autre action n’est déclenchée.

– Si l’opération de contrôle a été lancée sur la constituante d’une ressource

flottante et cette constituante a l’état Hors ligne ou Echec hors ligne,

System Automation for Multiplatforms tentera de lancer les opérations de

contrôle sur une autre constituante de la ressource. Notez que la

constituante ayant rejeté l’opération de contrôle restera dans un état

d’erreur irrémédiable tant que vous n’aurez pas lancé une opération de

réinitialisation sur elle.3. La ressource n’atteint pas l’état souhaité (en ligne) à la fin du délai d’attente.

Dans ce cas, System Automation for Multiplatforms émet tout d’abord une

opération de réinitialisation sur la ressource et attend jusqu’à ce que l’opération

de réinitialisation ait été acceptée et que la ressource ait été mise en ligne.

Ensuite, System Automation for Multiplatforms émet une autre opération de

contrôle de démarrage sur la ressource. Chaque tentative d’opération de

contrôle est comptabilisée et System Automation for Multiplatforms arrête

d’émettre des opérations de contrôle lorsque le nombre de tentatives autorisées

(RetryCount) est dépassé ou que le délai d’attente maximal (TimeOut *

RetryCount) expire, quel que soit le premier des deux cas de figure qui se

produit en premier.

Contrôle et administration de System Automation for Multiplatforms


Si System Automation for Multiplatforms arrête d’émettre des opérations de

contrôle pour une ressource fixe ou un composant de la ressource flottante, l’état

opérationnel de cette ressource est défini sur Echec hors ligne. Cela indique que la

ressource ne peut plus être utilisée et qu’un intervention manuelle est nécessaire

pour corriger la cause de l’échec. Une fois le problème résolu, la ressource doit être

réinitialisée à l’aide de la commande RMC resetrsrc.

Le compteur de tentatives est réinitialisé lorsque les ressources atteignent l’état

souhaité car aucun seuil n’a été mis en oeuvre. Cela signifie, par exemple, que si

une ressource est lancée, reste en ligne pendant une courte période, puis s’arrête,

elle est relancée par System Automation for Multiplatforms dans une boucle.

Les valeurs par défaut sont les suivantes :

v TimeOut = 60

v RetryCount = 3

Vous pouvez utiliser la commande samctrl –t Timeout pour modifier la valeur de

délai d’expiration (TimeOut) et la commande samctrl –r Retry_count pour modifier

la valeur de nombre de tentatives (RetryCount).

La classe IBM.Application fournit sa propre valeur de délai d’expiration. Si vous

ajoutez une ressource de classe IBM.Application à un groupe, la valeur générale du

délai d’expiration (TimeOut) n’est pas utilisée pour cette ressource. La valeur du

délai d’expiration utilisé pour ce membre du groupe sera la valeur la plus grande

de l’attribut StartCommandTimeout ou MonitorCommandPeriod (qui sont des

attributs de la ressource IBM.Application).

Opérations d’arrêt (Stop)

Le temporisateur des opérations est lancé lorsque System Automation for

Multiplatforms envoie, pour la première fois, une opération de contrôle d’arrêt de

ressource à une ressource. Une fois qu’il est lancé, il existe plusieurs possibilités :

1. La ressource change et prend l’état souhaité (hors ligne) au cours de la période

d’expiration. Aucune autre action n’est déclenchée.

2. La ressource refuse le contrôle d’arrêt au cours de la période d’expiration. Ce

qui se produit ensuite dépend du code de refus :

v Si le code indique que l’erreur peut être récupérée, System Automation for

Multiplatforms émet une autre opération de contrôle d’arrêt pour la

ressource.

v Si l’erreur ne peut pas être récupérée, la ressource se trouve dans un état

d’erreur. Une intervention manuelle est nécessaire pour que la ressource ne

soit plus dans l’état d’erreur.3. La ressource n’atteint pas l’état souhaité (hors ligne) au cours de la période

d’expiration. Dans ce cas, System Automation for Multiplatforms émet d’abord

une opération de réinitialisation pour la ressource et attend que la ressource

atteigne l’état souhaité (hors ligne).


Chapitre 10. Contrôle et administration de System Automation for Multiplatforms 189

Automatisation

Cette coche indique si la fonction d’automatisation de System Automation for

Multiplatforms est activée ou non. Si l’automatisation est désactivée, System

Automation for Multiplatforms arrête l’opération de contrôle d’arrêt. L’état des

ressources restera inchangé.

La valeur par défaut est le mode AUTO qui indique que l’automatisation est

activée.

Utilisez la commande samctrl –M F pour activer l’automatisation et la commande

samctrl –M T pour la désactiver.

ExcludedNodes

Il s’agit d’une liste de noeuds dans laquelle System Automation for Multiplatforms

procède à l’arrêt des ressources et les déplace dans un autre noeud, si cette

opération est possible. Prenons, par exemple, une ressource flottante A qui peut

fonctionner sur quatre noeuds : node05, node06, node07 et node08. Il s’agit d’un

membre du groupe de ressources RG_A. Lorsque le groupe est en ligne, il est

démarré sur le noeud node05. Si vous ajoutez le noeud node05 dans la liste des

noeuds exclus, System Automation for Multiplatforms arrête la ressource sur le

noeud node05 et la redémarre dans l’un des autres noeuds.

Avertissement : si vous excluez un noeud, il se peut qu’un ou plusieurs membres

obligatoires du groupe ne puissent être redémarrés dans un autre noeud et que le

groupe entier soit arrêté.

Par défaut, la liste est vide, ce qui signifie que tous les noeuds situés dans le

domaine homologue peuvent être utilisés.

Utilisez la commande samctrl –u a pour ajouter un ou plusieurs noeuds dans la

liste des noeuds exclus, la commande samctrl –u d pour supprimer des noeuds de

cette liste et la commande samctrl –u r pour remplacer des noeuds dans la liste.

ResourceRestartTimeout

La valeur ResourceRestartTimeout indique le délai d’attente en secondes de System

Automation for Multiplatforms avant de redémarrer les ressources situées dans un

noeud ayant échoué sur un autre noeud. Cette attente a pour but de donner une

chance aux ressources ou aux noeuds défectueux de procéder à un nettoyage avant

de procéder au déplacement des ressources vers un autre système.

La durée par défaut est 5 secondes.

Vous indiquez la valeur de délai d’attente de redémarrage des ressources à l’aide

de la commande samctrl –o.

Vous pouvez indiquer le niveau de trace à l’aide de la commande samctrl -l . Le

niveau de trace (TraceLevel ) détermine le volume d’entrées de trace écrites. La

valeur par défaut est 127. La valeur maximale 255 permet d’obtenir une trace très

détaillée. Si la valeur est sur 0, les différentes classes d’entrées de trace ne sont pas

écrites. La réduction du niveau de trace est recommandée pour les règles

d’automatisation avec un grand nombre de ressources.



Exemples

Pour répertorier les paramètres de contrôle courants de System Automation for

Multiplatforms, utilisez la commande lssamctrl :

lssamctrl

Affichage des informations de contrôle de System Automation for Multiplatforms :

Affichage des informations de contrôle de System Automation for Multiplatforms :

SAMControl:

TimeOut = 60

RetryCount = 3

Automation = Auto

ExcludedNodes = {}

ResourceRestartTimeOut = 5

ActiveVersion = [1.2.0.0,Tue 04 May 2004 12:30:48 PM EDT]

Enable Publisher = Désactivé

TraceLevel = 127

Pour ajouter le noeud node05 à la liste des noeuds exclus, entrez cette commande :

samctrl -u a node05

Pour définir le paramètre RetryCount sur 5, entrez cette commande :

samctrl –r 5



Gestion des règles d’automatisation des domaines System Automation

for Multiplatforms

Cette section explique comment gérer les règles d’automatisation déterminant le

comportement d’automatisation de System Automation for Multiplatforms.

Les règles d’automatisation constituent les éléments centraux de System

Automation for Multiplatforms. Elles permettent de définir le comportement

d’automatisation (actions et décisions) de System Automation for Multiplatforms.

Les règles contiennent des définitions de groupes de ressources, des relations entre

les ressources et/ou des groupes et équivalences. En règle générale, c’est le rôle

principal de l’administrateur de gérer les règles et de s’assurer qu’elles sont

correctes et peuvent être re-créées.

Pour utiliser une ou plusieurs règles, utilisez la commande sampolicy. Elle peut

être utilisée de trois manières :

1. Pour enregistrer une règle et la restaurer ultérieurement.

2. Pour remplacer complètement une règle.

3. Pour mettre à jour la règle active.

La commande sampolicy gère les groupes de ressources, les relations, les

équivalences, les ressources IBM.Application, IBM.ServiceIP, IBM.AgFileSystem et

IBM.Test, les paramètres de contrôle (samctrl) et les ressources IBM.TieBreaker.

Utilisation de la commande sampolicy pour gérer les règles

Les chapitres suivants décrivent comment gérer les règles à l’aide de la commande

sampolicy. Pour plus d’informations, consultez la description de la commande

dans le Guide de référence d’IBM Tivoli System Automation for Multiplatforms.

Désactivation des demandes de confirmation de la commande sampolicy :Lorsque vous exécutez la commande sampolicy pour activer, désactiver ou mettre

à jour une règle, une fois que la vérification de la syntaxe a été réalisée, un

message vous demande de confirmer l’action. Pour désactiver cette demande de

confirmation dans les scripts de traitement par lots par exemple, vous pouvez

utiliser le paramètre -q avec la commande sampolicy.

Exemple : Pour supprimer la demande de confirmation lors de l’activation de la

règle qui est indiquée dans le fichier XML myPolicy.xml, exécutez la commande

suivante :

sampolicy -q -a myPolicy.xml

Enregistrement d’une règle

System Automation for Multiplatforms utilise un fichier XML pour définir la règle

d’automatisation. Le chapitre consacré aux règles XML dans le Guide de référence

d’IBM Tivoli System Automation for Multiplatforms explique comment définir un

fichier de règles XML.

Exemple : Pour enregistrer les règles actives dans le fichier myPolicy.xml, utilisez

la commande suivante :

sampolicy -s /usr/xml/myPolicy.xml



Activation, restauration et remplacement d’une configuration

enregistrée

Vous pouvez utiliser la commande sampolicy pour activer, restaurer ou remplacer

une règle.

Exemple : Pour activer la règle qui est indiquée dans le fichier XML myPolicy.xml,

exécutez la commande suivante :

sampolicy -a /usr/xml/myPolicy.xml

Mise à jour d’une règle active

Vous pouvez utiliser la commande sampolicy pour mettre à jour la règle

actuellement active d’une manière ne nécessitant pas l’interruption. Le processus

de mise à jour est décrit plus en détails dans le chapitre suivant.

Exemple : Pour mettre à jour la règle active avec les éléments qui sont indiqués

dans le fichier XML update.xml, exécutez la commande suivante :

sampolicy -u update.xml

Désactivation d’une règle active

Pour désactiver la règle actuellement active, exécutez la commande suivante :

sampolicy -d

Demande d’informations sur les règles

Pour afficher les informations principales concernant la règle (attributs

PolicyName, PolicyDescription et PolicyAuthor, par exemple), utilisez l’option -i

avec la commande sampolicy.

Exemple :

Pour afficher les informations relatives à la règle courante qui se trouvent dans le

fichier myPolicy.xml, exécutez cette commande :

sampolicy -i /usr/xml/myPolicy.xml

Utilisation du langage XML pour définir des règles

d’automatisation

Vous pouvez définir les règles d’automatisation dans des fichiers XML. Cette

approche offre un certain nombre d’options :

v Vous pouvez définir les règles d’automatisation initiales d’un domaine System

Automation for Multiplatforms dans un fichier XML

v Vous pouvez mettre à jour la règle d’automatisation

Vous pouvez créer et modifier les fichiers de règles XML à l’aide de l’éditeur de

règles graphique d’Integrated Solutions Console en suivant les instructions de la

section «Création et modification de règles d’automatisation dans l’éditeur de

règles», à la page 146



Utilisation du langage XML pour définir les règles

d’automatisation initiales d’un domaine System Automation for

Multiplatforms

Ce scénario décrit la procédure à suivre pour configurer un nouveau domaine

System Automation for Multiplatforms en définissant des règles d’automatisation

et en les activant. Le scénario suppose que vous ayez déjà effectué les tâches

prérequises suivantes :

1. System Automation for Multiplatforms est installé sur tous les noeuds qui

formeront la grappe.

2. Vous avez défini et démarré la grappe comme le décrit la section «Etape 1 :

Définition et administration d’une grappe», à la page 12.


1. Définissez les éléments XML requis dans un fichier XML, comme expliqué dans

le Guide de référence d’IBM Tivoli System Automation for Multiplatforms (dans le

chapitre "Guide de référence XML des règles", qui offre également un exemple

de règles d’automatisation XML).

2. Enregistrez le fichier XML dans le répertoire du pool de règles. Cette opération

est obligatoire si vous souhaitez gérer vos règles d’automatisation à partir de la

console d’opérations SA.

3. Vérifiez la règle d’automatisation en vue de rechercher des erreurs et

avertissements éventuels. Utilisez l’une des méthodes suivantes :

v Dans la ligne de commande, exécutez la commande sampolicy -c. Les

résultats de la vérification s’affichent :

– Si aucun incident n’est signalé, vous recevez un message confirmant que

la règle d’automatisation est prête à être activée.

– Si des incidents ont été détectés lors de la vérification, la liste des

incidents s’affiche. Toutes les erreurs détectées doivent être résolues avant

de pouvoir activer la règle. Si des avertissements ont été émis, vous devez

vérifier que les problèmes sous-jacents ne peuvent pas être évités, bien

que la règle puisse être activée même s’ils n’ont pas été résolus.v Sur la console d’opérations SA, ouvrez la page "Sélectionner une règle

d’automatisation". Sur cette page, vous pouvez voir si la règle

d’automatisation est prête à être activée ou si des problèmes ont été détectés

lors de la vérification. Toutes les erreurs détectées doivent être résolues avant


vérifier que les problèmes sous-jacents ne peuvent pas être évités, bien que la

règle puisse être activée même s’ils n’ont pas été résolus. Pour plus

d’informations, voir «Vérification des règles d’automatisation», à la page 138.4. Activez la règle d’automatisation. Utilisez l’une des méthodes suivantes :

v Dans la ligne de commande, exécutez la commande suivante :

sampolicy -a <nom_fichier>

où <file_name> correspond au nom qualifié complet du fichier XML dans

lequel la règle d’automatisation à activer est définie.

v Sur la console d’opérations SA, ouvrez la page "Sélectionner une règle

d’automatisation", sélectionnez celle de votre choix puis cliquez sur Activer

la règle. En règle générale, cette action est équivalente à l’exécution de la

commande sampolicy -r. Pour l’activation initiale de la règle, toutefois, elle

est équivalente à la commande sampolicy -a.



Utilisation du langage XML pour mettre à jour une règle

d’automatisation

Effectuez les opérations suivantes :

1. Enregistrez la règle d’automatisation active dans un fichier XML. Pour ce faire,

exécutez la commande suivante à partir de la ligne de commande :

sampolicy -s <nom_fichier>

où <nom_fichier> correspond au nom qualifié complet du fichier XML dans

lequel la règle d’automatisation doit être enregistrée. Cette étape est obligatoire,

que la règle d’automatisation active soit le résultat de l’activation d’un fichier

de règles XML ou ait été définie à l’aide de commandes de ligne de commande.

Elle présente, entre autres, l’avantage de disposer d’une sauvegarde de la règle

active pour des besoins d’activation et de référence futurs.

2. Créez une copie du fichier XML et enregistrez-la sous un autre nom afin de

s’assurer que les définitions de la règle d’automatisation sont conservées.

3. Apportez les modifications nécessaires à la règle d’automatisation dans le

fichier de règles XML. Ceci peut nécessiter, par exemple, de supprimer ou de

créer des ressources et des groupes, de modifier des appartenances à des

groupes, de modifier des valeurs d’attribut, d’ajouter, de supprimer ou de

modifier des relations.

4. Vérifiez la règle d’automatisation en vue de rechercher des erreurs et

avertissements éventuels. Utilisez l’une des méthodes suivantes :

v Dans la ligne de commande, exécutez la commande suivante :

sampolicy -c <nom_fichier>

où <nom_fichier> correspond au nom qualifié complet du fichier XML à

vérifier. Les résultats de la vérification s’affichent :

– Si aucun incident n’est signalé, vous recevez un message confirmant que

la règle d’automatisation est prête à être activée.

– Si des incidents ont été détectés lors de la vérification, la liste des

incidents s’affiche. Toutes les erreurs détectées doivent être résolues avant


vérifier que les problèmes sous-jacents ne peuvent pas être évités, bien

que la règle puisse être activée même s’ils n’ont pas été résolus.v Sur la console d’opérations SA, ouvrez la page "Sélectionner une règle

d’automatisation". Sur cette page, vous pouvez voir si la règle

d’automatisation est prête à être activée ou si des problèmes ont été détectés

lors de la vérification. Toutes les erreurs détectées doivent être résolues avant


vérifier que les problèmes sous-jacents ne peuvent pas être évités, bien que la

règle puisse être activée même s’ils n’ont pas été résolus. Pour plus

d’informations, voir «Vérification des règles d’automatisation», à la page 138.

Lorsque vous êtes sûr de la disponibilité de la règle d’automatisation en vue d’une

activation, vous avez plusieurs possibilités pour activer la règle :

Activation nécessitant une interruption

Dans ce type d’activation de règle, la nouvelle règle d’automatisation

remplace complètement la précédente, ce qui signifie que toutes les

définitions actives sont supprimées et que toutes les ressources sont

arrêtées avant que le nouveau fichier de règles soit activé. Les

conséquences de cette opération sont les mêmes que si vous désactiviez la

règle d’automatisation active et en activiez une nouvelle.



Pour activer une règle d’automatisation de cette manière, utilisez la

commande suivante :

sampolicy -a <nom_fichier>

où <nom_fichier> correspond au nom qualifié complet du fichier XML

contenant la règle d’automatisation à activer.

Activation avec conservation des éléments actifs qui sont absents de la nouvelle

règle Ce type d’activation de règles ne nécessite aucune interruption et conserve

les éléments définis dans la règle active mais qui ne sont pas mentionnés

dans la nouvelle.


commande suivante :

sampolicy -u <nom_fichier>

où <nom_fichier> correspond au nom qualifié complet du fichier XML

contenant la règle d’automatisation à activer.

L’activation d’une règle d’automatisation par cette méthode a les effets

suivants :

v Les nouveaux éléments qui sont définis dans le fichier de règles XML

sont ajoutés à la règle d’automatisation active.

v Toutes les modifications apportées dans le fichier de règles XML aux

éléments qui existent dans la règle d’automatisation en cours sont

appliquées.

v Les éléments qui sont définis de manière identique à la fois dans la règle

d’automatisation active et dans la nouvelle règle restent intacts

v Les éléments présents dans la règle d’automatisation active mais qui ne

le sont pas dans la nouvelle règle restent intacts.

Cette approche d’activation permet d’étendre et de modifier la règle

d’automatisation active en utilisant les fichiers de règles XML qui ne

contiennent que les nouveaux éléments et les modifications apportées aux

éléments existants. Sachez que pour être activés, ces fichiers de règles XML

doivent être complets, à savoir être correctement formés, valides et sans

erreurs.

Activation avec suppression des éléments actifs qui sont absents de la nouvelle

règle Ce type d’activation de règles ne nécessite aucune interruption, cependant,

les éléments présents dans la règle active mais pas dans la règle

d’automatisation à activer, sont supprimés.


commande suivante :

sampolicy -r <nom_fichier>

où <nom_fichier> correspond au nom du fichier XML contenant la règle

d’automatisation à activer. Ce type d’activation de règle est également

réalisé lorsque vous activez une règle d’automatisation à partir de la

console d’opérations SA (voir «Activation des règles d’automatisation», à la

page 139).L’activation d’une règle d’automatisation par cette méthode a les

effets suivants :

v Les éléments qui sont définis de manière identique à la fois dans la règle

d’automatisation active et dans la nouvelle règle restent intacts

v Les nouveaux éléments qui sont définis dans le fichier de règles XML

sont ajoutés à la règle d’automatisation active.



v Toutes les modifications apportées dans le fichier de règles XML aux

éléments qui existent dans la règle d’automatisation en cours sont

appliquées.

v Les éléments présents dans la règle d’automatisation active mais qui ne

le sont pas dans la nouvelle règle sont supprimés.

Ce type d’activation permet d’étendre et de modifier la règle

d’automatisation active en utilisant les fichiers de règles XML qui ne

contiennent que les nouveaux éléments, les modifications apportées aux

éléments existants et les éléments qui doivent rester intacts. Sachez que

pour être activés, ces fichiers de règles XML doivent être complets, à savoir

être correctement formés, valides et sans erreurs.

Utilisation des modèles de règle

Si vous utilisez des règles volumineuses qui contiennent plusieurs valeurs

reproductibles, ou si vous voulez déplacer une règle d’un environnement à un

autre plus rapidement, vous pouvez vous servir de la fonction de traitement de

modèle de la commande sampolicy.

A la place des valeurs réelles, utilisez les paramètres du fichier XML qui se

présentent comme suit %%parname%%, où parname désigne le nom du paramètre. Le

paramètre doit être défini dans l’élément ″var″ du fichier de modèle de règle XML.

L’élément contient les attributs suivants :

nom nom du paramètre

valeur valeur du paramètre

Un seul paramètre peut être utilisé dans plusieurs emplacements et plusieurs

fichiers mais vous devez le modifier pour l’utiliser dans un seul emplacement. Il

facilite la migration de la règle d’un environnement à un autre.

De plus, il est possible d’inclure d’autres fichiers XML dans un fichier de modèle

de règle XML afin de faciliter l’utilisation de modèle de règle XML.

Vous pouvez relier de nouveaux fichiers XML à l’aide de l’élément include. La

valeur de son noeud doit contenir le chemin du fichier relié ; le chemin peut être

une valeur relative.

Le fichier de modèle XML possède un élément principal différent :

AutomationPolicyTemplate. Si vous voulez activer ou mettre à jour une règle à

l’aide des modèles, vous devez utiliser le paramètre -t associé à la commande

sampolicy.

Exemple :

sampolicy -a -t top.xml

Contenu d’un fichier top.xml :

<AutomationPolicyTemplate productID="SAM" version="2.3.0"

xmlns="http://.ibm.com/TSA/Policy.xsd"

xmlns:xsi="http://.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://.ibm.com/TSA/Policy.xsd SAMPolicyTemplate.xsd ">

<PolicyInformation>

<PolicyName>template</PolicyName>

<AutomationDomainName>%%domain%%</AutomationDomainName>

<PolicyToken>1.0</PolicyToken>

<PolicyDescription>MyDescription</PolicyDescription>



<PolicyAuthor>admin</PolicyAuthor>

</PolicyInformation>

<var name="domain" value="lnx"/>

<var name="node1" value="lnxcm11x"/>

<include>internal.xml</include>

</AutomationPolicyTemplate>

Contenu de internal.xml :

<?xml version="1.0" encoding="UTF-8"?>

<AutomationPolicy productID="SAM" version="2.3"



xsi:schemaLocation="http://.ibm.com/TSA/Policy.xsd SAMPolicy.xsd">

<ControlInformation>

<Timeout>60</Timeout>

<RetryCount>3</RetryCount>

<ResourceRestartTimeout>5</ResourceRestartTimeout>

</ControlInformation>

<Resource name="T1" class="IBM.Test" node="%%node1%%">

<ClassAttributesReference>

<IBM.TestAttributes name="IBM.Test.T1"/>

</ClassAttributesReference>

</Resource>

<IBM.TestAttributes name="IBM.Test.T1" >

<TimeToStart>0</TimeToStart>

<TimeToStop>0</TimeToStop>

<WriteToSyslog>0</WriteToSyslog>

</IBM.TestAttributes>

</AutomationPolicy>

La règle présentée ci-dessus va créer une ressource IBM.Test simple à l’aide de

modèles. La règle XML obtenue contiendra tous les fichiers XML inclus ainsi que

les paramètres remplaçants. Elle sera enregistrée dans le dossier en cours sous le

nom du fichier de niveau supérieur suivi du suffixe .complete.tmp.

Le fichier top.xml.complete.tmp qui est généré à partir des deux fichiers exemple

ci-dessus (top.xml et internal.xml), à l’aide de la commande sampolicy -a -t

top.xml se présente ainsi :

<?xml version="1.0" encoding="UTF-8"?>

<AutomationPolicy productID="SAM" version="2.3"



xsi:schemaLocation="http://.ibm.com/TSA/Policy.xsd SAMPolicy.xsd">

<PolicyInformation>

<PolicyName>template</PolicyName>

<AutomationDomainName>lnx</AutomationDomainName>

<PolicyToken>1.0</PolicyToken>

<PolicyDescription>MyDescription</PolicyDescription>

<PolicyAuthor>admin</PolicyAuthor>

</PolicyInformation>

<ControlInformation>

<Timeout>60</Timeout>

<RetryCount>3</RetryCount>

<ResourceRestartTimeout>5</ResourceRestartTimeout>

</ControlInformation>

<Resource name="T1" class="IBM.Test" node="lnxcm11x">

<ClassAttributesReference>

<IBM.TestAttributes name="IBM.Test.T1"/>

</ClassAttributesReference>

</Resource>



<IBM.TestAttributes name="IBM.Test.T1" >

<TimeToStart>0</TimeToStart>

<TimeToStop>0</TimeToStop>

<WriteToSyslog>0</WriteToSyslog>

</IBM.TestAttributes>

</AutomationPolicy>



Démarrage et arrêt d’un groupe de ressources et de membres d’un

groupe

Vous utilisez des requêtes de démarrage et d’arrêt pour mettre des groupes de

ressources ou des membres de groupes de ressources en ligne ou hors ligne. Les

requêtes de démarrage et d’arrêt priment toujours sur la valeur de l’attribut

NominalState d’un groupe de ressources. L’état nominal proprement dit n’est pas

modifié.

Vous pouvez envoyer des requêtes de lancement et d’arrêt à partir de la console

d’opérations SA ou de la ligne de commande.

Dans la ligne de commande, utilisez les commandes suivantes :

v Pour démarrer ou arrêter un groupe de ressources, entrez la commande suivante

:

rgreq –o <start|stop>

v Pour démarrer ou arrêter un membre de groupe de ressources, entrez la

commande suivante :

rgmbrreq –o <start|stop>

Portée des requêtes de lancement et d’arrêt

La portée d’une requête de lancement ou d’arrêt est déterminée par l’envoi de la

requête pour un groupe de ressources ou pour un membre particulier d’un groupe

de ressources :

v Une requête envoyée pour un groupe de ressources concerne tous les membres

du groupe. D’autres ressources peuvent être concernées si des relations sont

définies dans la règle pour le groupe de ressources ou un de ses membres, ou

les deux.

v Une requête qui est envoyée dans un membre d’un groupe de ressources ne

concerne que la ressource en particulier. D’autres ressources peuvent être

concernées si la ressource comporte des relations.

Remarque : Une requête qui est émise dans un membre obligatoire d’un groupe

de ressources peut également avoir un impact sur les états observés

et composés du groupe de ressources. Cela se produit lorsque la

requête conduit le membre dans un état observé qui entre en conflit

avec l’état souhaité du groupe de ressources. Dans ce cas, l’état

observé du groupe de ressources devient l’état "attente" et son état

composé devient l’état "erreur".

Exemple :

Lorsqu’un opérateur envoie une requête d’arrêt dans un membre

obligatoire d’un groupe de ressources dont l’état souhaité est en

ligne, l’état observé du groupe de ressource devient "En attente en

ligne" et son état composé devient "erreur" lorsque la ressource du

membre est arrêtée.

Les requêtes de lancement et d’arrêt provenant de la même source se remplacent

l’une l’autre car la liste de requêtes pour un groupe de ressources ou une ressource

gérée ne peut contenir qu’une requête provenant de chaque source.



Changement de la priorité des requêtes de lancement et

d’arrêt

Le niveau de priorité et la valeur de son attribut source détermine la priorité d’une

requête. En fonction du mode d’envoi d’une requête, l’attribut Source et le niveau

de priorité sont définis sur les valeurs par défaut. Vous pouvez remplacer les

valeurs par défaut lorsque vous émettez les commandes rgreq et rgmbrreq en

utilisant l’option –S pour spécifier la source et l’option -p pour définir le niveau de

priorité de la requête. Pour plus d’informations sur la manière dont les niveaux de

priorité des requêtes sont définis, voir «Hiérarchisation des requêtes», à la page

206.

Annulation des requêtes de lancement et d’arrêt

Les requêtes de lancement et d'arrêt sont permanentes, elles sont conservées

indéfiniment dans une liste de requêtes de ressources. Pour les retirer de la liste,

elles doivent être annulées. Lorsque vous annulez la requête active et que la liste

de requêtes contient d’autres requêtes, la requête qui suit dans la liste est activée.

v Pour annuler les requêtes dans la liste de requêtes d’un groupe de ressources,

entrez la commande suivante :

rgreq –o cancel

v Pour annuler les requêtes dans la liste de requêtes d’un groupe de ressources,

entrez la commande suivante :

rgreq –o cancel

Affichage de la liste des requêtes

Vous pouvez utiliser la commande lsrgreq pour afficher les requêtes envoyées.

Exemple de scénario

L’exemple de scénario ci-dessous illustre la manière dont un opérateur modifie

l’état d’un groupe de ressources en émettant et en annulant des requêtes et

l’utilisation de la commande lsrgreq pour afficher la liste de requêtes d'une

ressource et suivre la réussite de ces requêtes. Pour obtenir une description

détaillée des commandes utilisées dans les exemples ci-dessous, consultez le Guide

de référence d’IBM Tivoli System Automation for Multiplatforms.

L’attribut NominalState du groupe "top-rg" est hors ligne, mais son état

opérationnel est En ligne :

lnxcm3x:# lsrg -g top-rg | grep State

Affichage des informations de groupe de ressources :

Pour le groupe de ressources "top-rg".

Resource Group 1:


OpState = Online


La sortie de la commande lsrgreq indique que l'attribut OpState du groupe

provient d’une requête de lancement active à partir d’une automatisation de bout

en bout :

lnxcm3x:# lsrgreq -L -g top-rg

Affichage des informations de requête de groupe de ressources :

Toutes les informations de requête


Resource Group 1:

ResourceGroup = top-rg



Priority = Elevée

Action = start

Source = Automatisation

NodeList = {}

ActiveStatus = Actif

Token = 8f5697eb5f84c0f044995b3d00040a5b

UserID =

MoveStatus = None

Lorsqu’un opérateur tente de mettre le groupe "top-rg" hors ligne, il émet une

requête d’arrêt :

rgreq –o stop top-rg

La sortie de la commande lsrgreq indique que la requête d'arrêt de l’opérateur a

été ajoutée à la liste de requêtes mais n’a pas remporté. La requête d’arrêt reste

inactive car elle a été émise avec la priorité par défaut (faible) et ne peut pas

prévaloir sur la requête d’arrêt mieux classée à partir d’une automatisation de bout

en bout :





Resource Group 1:


Priority = Elevée

Action = start


NodeList = {}



UserID =

MoveStatus = None

Resource Group 2:


Priority = low

Action = stop

Source = Operator

NodeList = {}

ActiveStatus = InActive

Token = 8f5697eb5f84c0f044995dad0007b338

UserID =

MoveStatus = None

La sortie de la commande lsrg indique que le groupe reste en ligne :




Resource Group 1:


OpState = Online


Pour mettre le groupe hors ligne, l’opérateur émet une requête d’arrêt de priorité

élevée :

rgreq –p high –o stop top-rg



Le résultat de la commande lsrgreq montre que la requête a remplacé la

précédente requête de faible priorité de l’opérateur, s’est substituée à la requête de

démarrage de l’automatisation de bout en bout et est devenue la requête active :





Resource Group 1:


Priority = Elevée

Action = start


NodeList = {}

ActiveStatus = InActive


UserID =

MoveStatus = None

Resource Group 2:


Priority = Elevée

Action = stop

Source = Operator

NodeList = {}


Token = 8f5697eb5f84c0f044996004000368b1

UserID =

MoveStatus = None

Le groupe est arrêté en raison de la requête d’arrêt :




Resource Group 1:


OpState = Hors ligne

TopGroupNominalState = Hors ligne

Pour que le groupe "top-rg" soit de nouveau en ligne, l’opérateur doit seulement

annuler la dernière requête d’arrêt et il n’est pas nécessaire de recourir à une

requête de lancement supplémentaire :

rgreq –o cancel top-rg

Les exemples de sortie ci-dessous indiquent que le groupe "top-rg" est lancé une

fois que la requête a été annulée car la requête d’automatisation de bout en bout

redevient active :

lnxcm3x: # lsrgreq -L -g top-rg




Resource Group 1:


Priority = Elevée

Action = start


NodeList = {}



UserID =

MoveStatus = None






Resource Group 1:

Resource Group 1:


OpState = Online

TopGroupNominalState = Hors ligne

Utilisation des requêtes de verrouillage et de déverrouillage des

groupes de ressources et des ressources

Vous utilisez les requêtes de verrouillage pour geler les groupes de ressource et les

membres de groupes dans leur état en cours et empêcher qu’ils soient automatisés.

Pour reprendre l’automatisation des groupes de ressources et des ressources

verrouillées, vous pouvez utiliser des requêtes de déverrouillage. Vous pouvez

émettre des requêtes de verrouillage et de déverrouillage à partir de la ligne de

commande :

v Pour verrouiller un groupe de ressources, utilisez cette commande :

rgreq -o lock

v Pour verrouiller un membre de groupe de ressources, utilisez cette commande :

rgmbrreq -o lock

Les requêtes de verrouillage sont permanentes, elles sont conservées indéfiniment

dans une liste de requêtes de ressources. Pour les retirer de la liste de requêtes,

vous devez déverrouiller la ressource. Si la requête de verrouillage est active

lorsque vous déverrouillez la ressource, la requête qui suit dans la liste est activée.v Pour déverrouiller un groupe de ressources et pour supprimer la requête de

verrouillage de la liste de requêtes, utilisez la commande suivante :

rgreq -o unlock

v Pour déverrouiller un membre de groupe de ressources et pour supprimer la

requête de verrouillage de la liste de requêtes, utilisez la commande suivante :

rgmbrreq -o unlock

Portée des requêtes de verrouillage

La portée d’une requête de verrouillage peut être déterminée comme suit :

v La ressource verrouillée est située dans la portée de la requête de verrouillage.

v Tous les membres d’un groupe de ressources sont situés dans la portée d’une

requête de verrouillage si le groupe est lui-même compris dans sa portée.

v Si la cible d’une relation StartAfter, DependsOn ou DependsOnAny est comprise

dans la portée d’une requête de verrouillage, la source est également comprise

dans sa portée.

v Si la source d’une relation StopAfter est comprise dans la portée d’une requête

de verrouillage, la cible l’est également.

Changement de la priorité des requêtes

Pour hiérarchiser les requêtes, System Automation for Multiplatforms s’appuie sur

le niveau de priorité et sur la valeur de l’attribut Source de la requête. En fonction

du mode d’envoi d’une requête, l’attribut Source et le niveau de priorité sont

définis sur les valeurs par défaut. Pour que les valeurs par défaut soient ignorées,

lorsque vous exécutez les commandes rgreq et rgmbrreq, utilisez l’option -S pour



définir la source et l’option -p pour définir le niveau de priorité de la requête. Pour

plus d’informations sur la hiérarchisation des requêtes, voir «Hiérarchisation des

requêtes», à la page 206.

Les requêtes de verrouillage provenant de la même source se remplacent l’une

l’autre car la liste de requêtes d’un groupe de ressources ou d’un membre de

groupe de ressources ne peut contenir qu’une requête provenant de chaque source.

Vous pouvez utiliser la commande lsrgreq pour afficher une liste des requêtes.

Exemple de scénario

L’exemple de scénario ci-dessous illustre la manière dont un opérateur modifie

l’état d’un groupe de ressources en émettant et en annulant des requêtes et

l’utilisation de la commande lsrgreq pour afficher la liste de requêtes d’une

ressource et suivre la réussite de ces requêtes. Pour obtenir une description

détaillée des commandes utilisées dans les exemples ci-dessous, consultez le Guide

de référence d’IBM Tivoli System Automation for Multiplatforms.

L’attribut NominalState du groupe de ressources ″top-rg″ est En ligne, mais son

état opérationnel est Hors ligne :




Resource Group 1:

NominalState = Online

OpState = Hors ligne

TopGroupNominalState = Online

La sortie de la commande lsrgreq indique que le groupe est hors ligne car une

requête de verrouillage l’empêche de démarrer :





Resource Group 1:


Priority = Elevée

Action = lock

Source = Operator

NodeList = {}

ActiveStatus = Inactive


UserID =

MoveStatus = None

Lorsqu’un opérateur tente de mettre le groupe ″top-rg″ en ligne, il déverrouille le

groupe :

rgreq -o unlock top-rg

A présent, la liste de requêtes pour ″top-rg″ se présente ainsi :




Requêtes introuvables.



Hiérarchisation des requêtes

Sources et priorités par défaut des requêtes

La valeur par défaut sur laquelle l’attribut Source d’une requête est défini et le

niveau de priorité par défaut de la requête dépend de la manière dont la requête

est envoyée (envoi) et du type de ressource dans laquelle elle est émise (ressource

cible). tableau 23 indique les valeurs par défaut.

Tableau 23. Sources et niveaux de priorités des requêtes de lancement et d’arrêt

Programme d’envoi Ressource cible

Valeur de l’attribut

Source

Niveau de priorité

par défaut


SA en mode d’accès

direct ou en mode


premier niveau

Ressource ou groupe

de ressources

Operator Elevé

Interface de ligne de

commande de

System Automation

for Multiplatforms

Ressource ou groupe

de ressources

Operator Faible

Les valeurs possibles

sont :

Faible, Elevé, Forcer

Planificateur externe

(par exemple, Tivoli

Workload Scheduler

ou une tâche cron)

Ressource ou groupe

de ressources

ExtSched Elevé

Les valeurs possibles

sont :

Faible, Elevé, Forcer

Moteur


bout en bout

Référence de

ressource


bout en bout faisant

référence à une

ressource ou à un


System Automation

for Multiplatforms

Automation Elevé


SA en mode


bout en bout

Référence de

ressource



référence à une

ressource ou à un


System Automation

for Multiplatforms

Automation Elevé

Interface de ligne de

commande de

gestionnaire


bout en bout

Référence de

ressource



référence à une

ressource ou à un


System Automation

for Multiplatforms

Automation Elevé



Hiérarchisation des requêtes

Les requêtes qui sont envoyées dans un groupe de ressources sont hiérarchisées de

la manière suivante :

v Les requêtes sont prioritaires sur l’attribut NominalState du groupe de

ressources.

v Si des requêtes ont des niveaux de priorité différents, le niveau de priorité

détermine une priorité de requête.

v Si des requêtes possèdent le même niveau de priorité, les attributs Source sont

évalués afin de déterminer la priorité de chaque requête. figure 12 illustre la

manière dont la valeur de l’attribut Source influence la priorité des requêtes.

La figure 12 illustre les faits suivants :

– Les requêtes de la source '"Operator" sont prioritaires sur les requêtes des

sources "Automation" et "ExtSched".

– Les requêtes de la source "Automation" sont prioritaires sur les requêtes de la

source "ExtSched".

Cela signifie que vous pouvez remplacer les requêtes de la source "Automation"

en émettant des requêtes de ligne de commande à l’aide de l’option -p high.

Pour remplacer des requêtes de la source '"Operator", vous devez indiquer

l’option -p force.

Priorité des requêtes de console d’opérations

Toutes les requêtes de mise en ligne ou hors ligne envoyées par System

Automation for Multiplatforms ou la console d’opérations d’automatisation de

bout en bout génèrent des requêtes de démarrage et d’arrêt en provenance de la

source "Automation". Ces requêtes possède une priorité plus élevée que l’attribut

NominalState. Les opérateurs peuvent remplacer ces requêtes dans la ligne de

commande en envoyant les commandes avec la priorité Force.

Figure 12. Classement des priorités des requêtes



Priorité des requêtes d’automatisation de bout en bout

Lorsque les requêtes sont émises sur des ressources d’automatisation de bout en

bout, les requêtes résultantes sur les ressources d’automatisation de premier niveau

référencées sont toujours émises par le gestionnaire d’automatisation de bout en

bout, ce qui explique pourquoi leur niveau de priorité est toujours sur "High" et

leur attribut source sur "Automation". Cette règle s’applique indépendamment du

fait que la requête originale sur la ressource d’automatisation de bout en bout ait

été émise par le gestionnaire d’automatisation de bout en bout ou par un

opérateur.

Déplacement des groupes de ressources à l’aide de la commande

rgreq

Vous pouvez déplacer des groupes de ressources dans un autre noeud de grappe

sans affecter toutes les ressources fonctionnant actuellement sur le même noeud.

Cela est souhaitable, par exemple, dans les scénarios d’équilibrage de charge, dans

lesquels les objectifs de charge de travail et de performance peuvent être atteints

lorsqu’un seul ou un faible nombre de groupes de ressources sont déplacés vers un

autre noeud.

Les ajustements de position des ressources peuvent être effectués à l’aide de la

commande rgreq –o move.

Portée d’un mouvement

La portée d’un déplacement se situe au niveau de tous les membres d’un groupe

de ressources de niveau supérieur. Les ressources dépendantes d’une ou plusieurs

ressources impliquées dans le mouvement peuvent être affectées, c.-à-d. arrêtées ou

démarrées. Une requête de déplacement ne peut être émise pour une ressource

gérée unique.

Si la valeur de l’attribut MemberLocation du groupe de ressources de niveau

supérieur est collocated, il n’est pas nécessaire de spécifier une liste de noeuds

pour la commande rgreq. Dans ce cas, toutes les ressources sont situées dans le

même noeud et seront enlevées du noeud. Si le groupe de ressources n’est pas

associé à la valeur collocated, une liste contenant un ou plusieurs noeuds doit être

spécifiée par le biais de l’option –n de la commande rgreq. Toutes les ressources

seront enlevées de ce noeud.

Une requête de déplacement est émise pour un groupe de ressources qui contient

uniquement des ressources fixes ne sera pas acceptée. Aussi, une requête de

déplacement émise pour un groupe de ressources hors ligne sera refusée.

Lorsqu’une requête de déplacement est déjà en cours, une autre requête de

déplacement émise pour le même groupe sera refusée.

Si une ressource se situant dans la portée du déplacement dispose d’une

dépendance sur une équivalence, toutes les autres ressources ayant une

dépendance sur cette même équivalence seront également ajoutées à la portée du

déplacement, et par conséquent arrêtées puis redémarrées au cours du

déplacement. Pour éviter ce comportement, vous devez créer différentes

équivalences pour les ressources non associées même si les membres des

équivalences sont identiques.



Traitement d’une requête de déplacement

Depuis la version 2.3, le comportement de System Automation for Multiplatforms

au cours de la phase hors ligne a changé. Dans les versions antérieures, toutes les

ressources situées dans la portée du déplacement étaient arrêtées. Désormais, une

approche d’exclusion de noeud permet d’arrêter uniquement les ressources situées

dans la portée et qui sont actuellement exécutées sur les noeuds indiqués dans la

demande de déplacement ou qui possèdent une dépendance sur ces ressources.

Dans la phase En ligne du déplacement, le classeur effectue un nouveau placement

de noeud pour tous les membres du groupe de ressources et le groupe est

redémarré.

Notez qu’il est impossible de redémarrer des membres obligatoires du groupe de

ressources de niveau supérieur tout en procédant au déplacement de la liste de

noeuds. Cette liste sera ignorée et les ressources pourront alors être redémarrées.

De même, si l’unique emplacement dans lequel vous pouvez redémarrer une

ressource est le système original sur lequel elle était exécutée, elle doit être

redémarrée à cet emplacement s’il s’agit d’une ressource obligatoire.

Une requête de déplacement est supprimée automatiquement lorsque l’action de

déplacement est exécutée. L’attribut dynamique MoveStatus du groupe de

ressources déplacé affichera des valeurs indiquant l’état de progression du

déplacement.

Vous pouvez, cependant, avoir besoin d’annuler une requête de déplacement si les

ressources ne sont pas redéplacées dans le noeud d’origine même si l’opération

n’aboutit pas. Vous pouvez annuler une requête de déplacement à l’aide de la

commande suivante :

rgreq -o movecancel

Déplacement et relations

En plus d’effectuer une requête de déplacement sur les membres du groupe de

ressources de niveau supérieur, il se peut que la position d’autres membres ou

groupes de ressources doive être ajustée en fonction des contraintes de relations

définies. Cette remarque s’applique aux relations suivantes :

v Collocation

v AntiCollocation

v DependsOn

v DependsOnAny

v StopAfter

v ForcedDownBy

En outre, il se peut que les relations Affinity et AntiAffinity ne soient pas remplies

après le déplacement.



Utilisation de ressources ombrées

Une ressource ombrée possède les caractéristiques suivantes :

v C’est une ressource fixe de la classe IBM.Application, qui surveille l’attribut

OpState d’une autre ressource fixe.

v C’est un membre d’une équivalence dont la valeur de l’attribut SelectFromPolicy

est définie sur NoControl, qui spécifie que System Automation for

Multiplatforms se contente d’évaluer l’attribut OpState des ressources du

membre mais il ne lance pas ces ressources et il ne les arrête pas.

Vous devez utiliser des ressources ombrées si vous souhaitez définir une relation

du type DependsOn d’une ressource flottante vers l’une des ressources fixes

exécutées sur différents noeuds, car la relation DependsOn déclenche un

comportement StartAfter et un comportement StopAfter.

Si vous configurez ce type de relation DependsOn sans définir de ressources

ombrées, un comportement d’automatisation indésirable est observé :

Dans le scénario 1, System Automation for Multiplatforms arrête la ressource

flottante même si une seule des ressources fixes n’est pas disponible, et System

Automation for Multiplatforms ne peut relancer la ressource flottante que si les

deux ressources fixes sont disponibles.

Figure 13. Scénario 1 : Relations DependsOn sans ressources ombrées



Pour obtenir le comportement d’automatisation souhaité, vous créez des ressources

ombrées qui sont des membres d’une équivalence NoControl :

Dans le scénario 2, le comportement ForceDown de la relation DependsOn conduit

System Automation for Multiplatforms à arrêter la ressource flottante si l’état

opérationnel du membre actuellement sélectionné de l’équivalence devient hors

ligne, mais à présent System Automation for Multiplatforms peut relancer la

ressource flottante si au moins un autre membre de l’équivalence est en ligne.

Définition des ressources ombrées

Pour créer des ressources ombrées :

1. Créez les scripts de commande pour les ressources ombrées.

Même si System Automation for Multiplatforms n’utilise que

MonitorCommand, des éléments StartCommand et StopCommand valides

doivent également être fournis. MonitorCommand doit interroger l’attribut

OpState de la ressource pour laquelle elle est ombrée. Cela est possible :

v en interrogeant l’attribut OpState à l’aide de

‘lsrsrc –s ‘Name like “<res> “’IBM.Application OpState

v en dupliquant l’attribut MonitorCommand de la ressource originale

v en enregistrant l’attribut OpState de la ressource originale dans un fichier et

en le lisant dans l’attribut MonitorCommand de la ressource ombrée

Exemple :

L’exemple de script ci-dessous contient les commandes nécessaires pour la

ressource ombrée de la ressource « fixed_rs1» :

#!/bin/ksh

#

# shadow_sample.sh

Figure 14. Relation DependsOn avec des ressources ombrées



#

# init section

#

Action=${1:-status}

ResName=${2:-myresource}

UNKNOWN=0

ONLINE=1

OFFLINE=2

FAILED_OFFLINE=3

export CT_MANAGEMENT_SCOPE=2 # nécessaire à l’exécution de commande SA MP

#

# main section

#

case ${Action} in

start)

# is not executed .. so irrelevant

RC=0

;;

stop)

# is not executed .. so irrelevant

RC=0

;;

status|*)

RCval=$(lsrsrc -xt -s ’Name="’${ResName}’"’

IBM.Application OpState)

RCx=${RCval:-2}

case ${RCx} in

[1]*) RC=${ONLINE}

;;

*) RC=${OFFLINE}

;;

esac

#logger -i -t "$(basename $0)" "${ResName} monitored: ${RC}"

esac

exit ${RC}

2. Créez les ressources ombrées à l’aide d’une commande pour chacune des

ressources, comme indiqué ci-dessous :

# mkrsrc IBM.Application \

Name="fixed_rs1_shadow" \

ResourceType=0 \

NodeNameList=”{‘node1’}” \

UserName=”root” \

StartCommand="/samplepath/shadow_sample.sh start fixed_rs1" \

StopCommand="/samplepath/shadow_sample.sh stop fixed_rs1" \

MonitorCommand="/samplepath/shadow_sample.sh status fixed_rs1" \

MonitorCommandPeriod=10 \

RunCommandsSync=1

3. Créez une équivalence avec une valeur d’attribut SelectFromPolicy définie sur

NoControl.

Pour créer l’équivalence qui contient les ressources fixes créées lors de l’étape 2,

utilisez la commande suivante :

# mkequ <equ-name> -p A,NoControl \

IBM.Application:<ressource-fixe1>:<nom-noeud1>,<ressource-fixe2>:<nom-noeud2>

[,...]



Exemple :

mkequ -p A,NoControl shadow_equ IBM.Application:fixed_rs1_shadow:node1,fixed_rs2_shadow:node2

Pour définir une règle ordonnée, utilisez -p O,NoControl.

4. Créez la relation DependsOn à partir de la ressource flottante dans

l’équivalence 'shadow_equ' :

# mkrel –p DependsOn –S IBM.Application:float1 –G IBM.Equivalency:shadow_equ \

float1-depon-shadow_equ



Configuration des paramètres de sécurité des grappes System


Cette section explique comment configurer les paramètres de sécurité non root de

l’interface de ligne de commande de System Automation for Multiplatforms sur les

systèmes AIX, Solaris et Linux. Pour System Automation for Multiplatforms sous

Windows, seul l’ID utilisateur administrateur est valide.

Par défaut, sur les systèmes Linux, Solaris et AIX, seul l’utilisateur root dispose

des droits nécessaires pour accomplir des tâches opérationnelles dans System

Automation for Multiplatforms et apporter des modifications aux règles

d’automatisation de System Automation for Multiplatforms. Les autres utilisateurs

ne disposent que d’un accès en lecture.

Le concept de sécurité de System Automation for Multiplatforms est basé sur celui

du composant RSCT, RMC, qui implémente l’autorisation de sécurité à l’aide d’un

fichier de liste de contrôle d’accès. En particulier, RMC utilise le fichier ACL dans

un noeud particulier pour déterminer les autorisations dont un utilisateur doit

disposer pour accéder à des classes de ressources et à leurs instances de ressource.

Dans la mesure où les gestionnaires de ressources de System Automation sont

implémentées en interne sous forme d’application RMC, le même ensemble de

règles de contrôle de LCA doit être utilisé pour permettre aux utilisateurs autres

que root de gérer (définir, annuler la définition ou modifier) les classes de

ressources liées à System Automation (IBM.ResourceGroup,

IBM.ManagedRelationship, IBM.Equivalency, IBM.ManagedResource,

IBM.CHARMControl, IBM.Application et IBM.ServiceIP) et de lancer et arrêter les

groupes de ressources correspondants.

Pour obtenir des informations détaillées sur la configuration des fichiers LCA

RMC, consultez les sections suivantes du manuel IBM RSCT Administration Guide :

v section “Gestion de l’accès utilisateur aux ressources à l’aide de fichiers LCA

RMC” du chapitre 4 ("Gestion et surveillance des ressources à l’aide de RMC et

des gestionnaires de ressources")

v section “Configuration des mappages d’identités d’autorisations globales et

locales” du chapitre 7 ("Présentation et administration des services de sécurité de

grappe")

La prise en charge des autorisations de sécurité RSCT et RMC est en mesure de

gérer l’accès utilisateur en fonction des classes de ressources individuelles et des

noeuds simples, par exemple, l’accès utilisateur peut être limité à une classe de

ressource RMC spécifique sur un noeud particulier dans la grappe. Ce paramètre

de niveau d’autorisation, en revanche, est très complexe et nécessite une

compréhension claire de la nature de chaque classe de ressources RMC

individuelles. Par conséquent, il est recommandé de créer des rôles pour un

opérateur System Automation for Multiplatforms et un administrateur System

Automation for Multiplatforms en les associant à des paramètres généraux qui

permettront aux utilisateurs non root de gérer toutes les classes de ressources à

partir de n’importe quel noeud défini dans la grappe. En utilisant la procédure

décrite ci-dessous, vous créez ces deux rôles :

v «sa_admin» pour un administrateur

v «sa_operator» pour un opérateur



Pour créer les rôles, suivez cette procédure (notez que le droit root est requis) :

1. Créez les ID utilisateur qui ont l’autorisation de gérer System Automation for

Multiplatforms sur tous les noeuds. Utilisez la commande appropriée pour

votre système d’exploitation, par exemple, sur Linux, utilisez :

# /usr/sbin/useradd ernie

# /usr/sbin/useradd bert

2. Créez un groupe pour les ID utilisateur sur tous les noeuds. Utilisez la

commande appropriée pour votre système d’exploitation, par exemple, sur

Linux, utilisez :

# /usr/sbin/groupadd sagroup

3. Ajoutez le groupe aux ID utilisateur sur tous les noeuds. Utilisez la commande

appropriée pour votre système d’exploitation, par exemple, sur Linux, utilisez :

# /usr/sbin/usermod –G sagroup ernie

# /usr/sbin/usermod –G sagroup bert

Remarque : Assurez-vous de définir la variable d’environnement ci-dessous

pour tous les utilisateurs de System Automation for

Multiplatforms sur tous les noeuds (portée de domaine

homologue) :

CT_MANAGEMENT_SCOPE=2

Vous pouvez définir de façon permanente la variable si vous

définissez les paramètres dans le profil.

4. Modifiez la propriété du groupe du fichier /var/ct/IBM.RecoveryRM.log.

Le fichier est utilisé pour suivre l’historique de System Automation for

Multiplatforms. Toutes les commandes qui modifient les ressources du

gestionnaire d’automatisation (IBM.RecoveryRM) sont consignées dans ce

fichier.

Par défaut, le fichier appartient au groupe d’utilisateurs root :

-rw-r--r-- 1 root root 204 Oct 4 22:00 /var/ct/IBM.RecoveryRM.log

Vous devez modifier la propriété du groupe afin d’utiliser la valeur «sagroup»,

à l’aide de la commande appropriée pour votre système d’exploitation, par

exemple, sur Linux, utilisez :

/bin/chgrp sagroup /var/ct/IBM.RecoveryRM.log

Vous devez également modifier l’autorisation du fichier sur 664 :

# /bin/chmod 664 /var/ct/IBM.RecoveryRM.log

-rw-rw-r-- 1 root sagroup 204 Oct 4 22:00 /var/ct/IBM.RecoveryRM.log

Remarque : Si le fichier /var/ct/IBM.RecoveryRM.log n’existe pas après

l’installation initiale de System Automation for Multiplatforms,

vous pouvez créer un fichier fictif à l’aide de la commande

/usr/bin/touch :

# /usr/bin/touch /var/ct/IBM.RecoveryRM.log

5. Modifiez le fichier /var/ct/cfg/ctsec_map.global sur tous les noeuds.

Vous devez ajouter les entrées ci-dessous pour les ID utilisateur «ernie» et «

bert» au fichier de mappage d’identités d’autorisations globales RSCT

(/var/ct/cfg/ctsec_map.global) sur tous les noeuds de la grappe :

unix:ernie@<cluster>=sa_operator

unix:ernie@<any_cluster>=sa_operator

unix:bert@<cluster>=sa_admin

unix:bert@any_cluster>=sa_admin



Le fichier est utilisé pour mapper un ID utilisateur local sur un noeud en ID

utilisateur global dans le domaine System Automation for Multiplatforms. Dans

l’exemple, l’ID utilisateur local «ernie» est mappé vers l’ID utilisateur global

«sa_operator» et l’ID utilisateur local «bert» est mappé vers l’ID utilisateur

global «sa_admin».

Vous pouvez facilement autoriser d’autres ID utilisateur local pour System

Automation for Multiplatforms en ajoutant des lignes supplémentaires dans ce

fichier de mappage global (sur tous les noeuds) et en les mappant vers le rôle

souhaité (opérateur System Automation for Multiplatforms ou administrateur

System Automation for Multiplatforms).

Remarque : Si le fichier /var/ct/cfg/ctsec_map.global n’existe pas sur un

noeud, copiez le fichier par défaut /usr/sbin/rsct/cfg/ctsec_map.global dans le répertoire /var/ct/cfg et ajoutez les

nouvelles entrées dans le fichier /var/ct/cfg/ctsec_map.global.

Ne supprimez pas des entrées du fichier /var/ct/cfg/ctsec_map.global, qui se trouve dans le fichier par défaut que

vous avez copié. Les fichiers /var/ct/cfg/ctsec_map.global

doivent être identiques sur tous les noeuds de la grappe.

6. Modifiez le fichier /var/ct/cfg/ctrmc.acls sur tous les noeuds. Vous devez

ajouter les entrées ci-dessous pour les ID utilisateur globaux «sa_operator» et

«sa_admin» au fichier de LCA RMC (/var/ct/cfg/ctrmc.acls), sur tous les

noeuds de la grappe et commentez la ligne en commençant par LOCALHOST. Par

exemple :

# Le paragraphe ci-dessous contient des entrées de LCA par défaut.

# Ces entrées sont ajoutées

# à chaque LCA définie pour une classe de ressource et

# sont examinées après chaque entrée

# définie explicitement pour une classe de ressources

# par les paragraphes de ce fichier,

# dont le paragraphe OTHER.

DEFAULT

root@LOCALHOST * rw

# LOCALHOST * r // Notez vos commentaires sur cette ligne

none:root * rw // Fournissez un accès root à tous

none:sa_admin * rw // Ajoutez cette ligne pour saadmin

none:sa_operator * rso // Ajoutez cette ligne pour saoperator

7. Une fois que les modifications ci-dessus sont terminées, la commande

ci-dessous doit être exécutée sur chaque noeud de la grappe pour activer les

modifications :

# /usr/bin/refresh -s ctrmc

8. Des modifications supplémentaires sont nécessaires pour utiliser les

commandes sampolicy et *samadapter :

a. Accédez aux fichiers de configuration :

# /bin/chgrp -R sagroup /opt/IBM/tsamp/sam/cfg

# /bin/chmod g+ws /opt/IBM/tsamp/sam/cfg

# /bin/chmod g+w /opt/IBM/tsamp/sam/cfg/*

b. Accédez aux fichiers journaux :

# /bin/chgrp -R sagroup /var/ibm/tivoli/common/eez/logs

# /bin/chmod g+ws /var/ibm/tivoli/common/eez/logs

# /bin/chmod g+w /var/ibm/tivoli/common/eez/logs/*

c. Accédez aux fichiers de configuration dans le répertoire /etc.S’il n’existe pas de répertoire /etc/opt/IBM/tsamp/sam/cfg, créez-le en

utilisant

# /bin/mkdir -p /etc/opt/IBM/tsamp/sam/cfg.



Ensuite, définissez les autorisations de manière appropriée :

# /bin/chgrp -R sagroup /etc/opt/IBM/tsamp/sam/cfg

# /bin/chmod g+ws /etc/opt/IBM/tsamp/sam/cfg

# /bin/chmod g+w /etc/opt/IBM/tsamp/sam/cfg/*

9. Des ajustements facultatifs sont nécessaires pour utiliser le module

«sam.policies» :

Des règles prédéfinies adaptées à différentes applications sont disponibles dans

le module d’installation «sam.policies », qui peut être téléchargé à l’adresse

suivante :


Pour permettre à un utilisateur qui possède le rôle «sa_admin» de configurer

ces règles prédéfinies, les autorisations et la propriété du répertoire

/usr/sbin/rsct/sapolicies doivent être modifiées une fois que le module

«sam.policies » est installé sur tous les noeuds :

# chmod –R 2775 /usr/sbin/rsct/sapolicies

# chgrp -R sagroup /usr/sbin/rsct/sapolicies

Résultats : Lorsque les étapes ci-dessus sont terminées, les utilisateurs locaux

«ernie» et «bert» peuvent effectuer les tâches facultatives de System Automation

for Multiplatforms, comme l’émission de requêtes de lancement et d’arrêt dans des

ressources, et l’utilisateur local «bert» peut également effectuer les tâches

d’administration de System Automation for Multiplatforms, comme la définition et

la modification des règles.

Limites de la configuration de la sécurité non root

La liste ci-dessous résume les limites de la configuration de la sécurité non root

décrite ci-dessus :

v Un utilisateur classique ne peut pas afficher le contenu du fichier de trace du

gestionnaire de ressources RMC (par exemple, la trace du démon

IBM.RecoveryRMd).

Tous les démons de gestionnaire de ressources RMC utilisent l’utilitaire de

bibliothèque de cadre RMC pour créer des fichiers de trace et des images

centrales dans le répertoire /var/ct/<cluster>. Dans la mesure où ces

gestionnaires de ressources ne peuvent être lancés que par un super utilisateur

(ID utilisateur root) par le biais de la commande /usr/bin/startsrc, les fichiers

qui sont créés appartiennent à l’ID utilisateur root.

Cela implique qu’un utilisateur non root ne peut pas collecter des informations

de débogage et de trace en utilisant la commande /usr/sbin/rsct/bin/ctsnap.

Pour permettre à des utilisateurs non root de collecter des traces ou des données

de débogage ctsnap, ou les deux, un mécanisme comme «sudo» doit être

implémenté pour ces utilisateurs et ces commandes.

v Les commandes suivantes ne peuvent être appelées qu’avec les droits d’accès

root car elles utilisent la consignation Tivoli, qui ne fonctionne que si les fichiers

journaux sont gérés avec les droits d’accès root :

– La commande sampolicy

– La commande samadapter pour démarrer l’adaptateur d’automatisation de

bout en boutv La granularité des objets de la LCA est basée sur les classes de ressources et non

sur les ressources. Cela signifie qu’un utilisateur régulier a l’autorisation de

modifier les ressources d’une classe de ressources ou non, mais il n’est pas

possible d’accorder ou de refuser des autorisations sur la base d’une ressource.



Par exemple, un administrateur de base de données ne peut pas disposer d’une

autorisation uniquement pour les ressources de base de données.

v Le rôle «sa_operator» peut modifier les ressources en modifiant les valeurs

d’attribut pour les ressources. Cela résulte de l’autorisation «s», qui est

nécessaire pour émettre des requêtes System Automation for Multiplatforms.

Sans l’autorisation «s», les utilisateurs qui possèdent ce rôle ne peuvent pas

effectuer de tâche utile, mais avec cette autorisation, ils peuvent modifier et

définir des attributs.

Le tableau ci-dessous indique le rôle ou le droit requis pour effectuer les tâches

System Automation for Multiplatforms classiques.

Tableau 24. Autorisations et rôles pour effectuer des tâches System Automation for

Multiplatforms

Tâche Droits Rôles Autorisations

Installation de

produit

root Administrateur

système

Installation et mise à

niveau de System

Automation for

Multiplatforms

Gestion de grappe root/sa_admin Administrateur

système/Administrateur

System Automation

for Multiplatforms

Définition,

lancement, arrêt et

surveillance des

grappes et des

gestionnaires de

ressources RMC

individuelles

Définition de

ressource et

définition de règle

System Automation

for Multiplatforms

root/sa_admin Administrateur


System Automation

for Multiplatforms

Définition,

suppression,

modification des

ressources et

configuration des

règles

d’automatisation

Opération

d’automatisation

root/sa_admin/sa_operator

Administrateur

système/Administrateur et

opérateur System

Automation for

Multiplatforms

Emission de requêtes

en ligne et hors ligne,

réinitialisation et

surveillances des

groupes de

ressources et des

ressources

individuelles

Collecte de données

de trace et de

débogage pour la

détermination des

problèmes

root Administrateur

système

Accès à tous les

fichiers (journaux) de

trace du système et

des applications (voir

la liste des limites

ci-dessus).

Configuration de la

sécurité

root Administrateur

système

Définition,

modification et

suppression de la

configuration de la

sécurité décrite dans

cette section.



Tableau 24. Autorisations et rôles pour effectuer des tâches System Automation for

Multiplatforms (suite)

Tâche Droits Rôles Autorisations

Configuration de

l’adaptateur

root/sa_admin Administrateur


System Automation

for Multiplatforms

Définition,

modification et

suppression de la

configuration de

l’automatisation de

bout en bout.



Etablissement de diagnostics de ressources System Automation for

Multiplatforms

Pour obtenir des informations supplémentaires sur les ressources gérées par

System Automation for Multiplatforms, vous pouvez utiliser la commande

samdiag, détaillée dans le Guide de référence d’IBM Tivoli System Automation for

Multiplatforms. Cette commande est principalement conçue pour une utilisation

dans des cas de figure où l’utilisateur ne comprend pas toujours ce qui arrive au

système et pourquoi.

Remarque : La commande samdiag disponible dans la version 1 de System

Automation for Multiplatforms pouvait uniquement être exécutée sur

le noeud sur lequel le démon maître était en cours d’exécution. Par

conséquent, l’exécution de la commande samdiag sur un démon de la

version 2 provoquera une erreur si les démons des versions 1 et 2

coexistent dans la même grappe et que le démon maître se trouve sur

un noeud de la version 1.

Pour obtenir des informations sur le groupe de ressources ″apacherg″, utilisez la

commande :

samdiag -g apacherg

Résultat :

Diagnosis::Resource: apacherg/ResGroup/IBM.ResourceGroup

type: CHARM Resource Group

Status -

Observed: Offline - Logiciel hors ligne

Desired: Offline - Hors ligne demandé

(Nominal: Offline - Etat nominal : Hors ligne)

Automation: Idle - Déclencheur CharmBase lié

Startable: Yes - La ressource peut être démarrée

Binding: Unbound - Etat de liaison initialisés

Compound: Satisfactory - Satisfaisant

Resource Based Quorum: None -

Members and Memberships:

+---bind/HasMember ---> RA/Float/IBM.Test

Group Constraint: None

Binding Constraints:

Flags:

None

Orders:

Outstanding Order: None - La ressource est indisponible

Dependencies:

Start: Satisfied

+---InCluster ---> Cluster

Stop: Satisfied

Binding exceptions:

There are unbound members.

Static Relationships:


Dynamic Relationships:

+---bind/HasMember ---> RA/Float/IBM.Test"



La section suivante propose une interprétation de certaines informations fournies

dans l’exemple :

v L’état observé (ObservedState) doit indiquer la même valeur que l’état

opérationnel (OpState) et l’état nominal (NominalState). Si tel n’est pas le cas,

contactez le centre de support prenant en charge votre zone.

v Des valeurs différentes dans l’état souhaité (DesiredState) et nominal

(NominalState) indiquent qu’une requête a été émise sur le groupe de

ressources.

v L’état d’automatisation (AumationState) peut être ″occupé″ ou ″en veille″. ’L’état

Occupé signifie que le démon de System Automation for Multiplatforms

(IBM.RecoveryRM) attend qu’un autre gestionnaire de ressources démarre ou

arrête une ressource. Lorsque l’opération a été effectuée, l’état d’automatisation

(AutomationState) passe à ″en veille″. Si tel n’est pas le cas, contactez le centre

de support prenant en charge votre zone.

v Un état de possibilité de démarrage défini sur ″Non″ indique que certaines

relations, par exemple, une relation Dépendant de, ne sont pas configurées

correctement.

v L’état de liaison (BindingState) ’non lié’ est associé à l’état observé

(Observedstate) ’Hors ligne’. Il indique que le groupe de ressources est hors

ligne. Avant de pouvoir être défini sur ’en ligne’, une étape de liaison qui

consiste à choisir le bon composant doit être effectuée. Ensuite, l’état de liaison

(BindingState) est défini sur ’Lié’. Un état de liaison (BindingState) défini sur

’Lié’ pour des groupes de ressources hors ligne est une erreur.

v Un état composé (CompoundState) ’Satisfaisant’ indique que les états observés et

souhaités (ObservedState et DesiredState) sont identiques. Les états composés

(CompoundStates) ’Interdit’, ’Refusé’ ou ’Interrompu’ indiquent des erreurs

telles que des relations qui n’ont pas été satisfaites ou des ressources

’interrompues’.

v Un quorum de ressources équivalent à ’Aucun’ signifie que toutes les ressources

flottantes du groupe ne prennent pas en charge les quorum de ressources

indépendants et que la case ″Quorum de ressources″ n’est pas cochée.

v ’Bind/HasMember’ (Lier/possède un membre) décrit la relation entre le groupe

de ressources apacherg et ses membres flottants RA/Float/IBM.Test. Lorsque

vous effectuez l’étape de liaison mentionnée ci-dessus, un composant est

sélectionné pour chaque relation Bind/HasMember’ (Lier/possède un membre).

Ce composant est lié temporairement au groupe de ressources avant d’être défini

En ligne.

v Les ordres en attente se réfèrent à l’état d’automatisation (AutomationState). Si

l’état d’automatisation (AutomationState) n’est pas ’En veille’, la commande en

attente est affichée ici.

v Les dépendances de démarrage/d’arrêt indiquent lorsqu’une règle empêche le

démarrage d’une ressource.

v Les exceptions de liaison fournissent une explication plus précise sur l’état de

liaison (BindingState).

v Les relations statiques signifient que toutes les ressources constituantes et tous

les groupes de ressources sont membres d’une grappe.

v Les relations dynamiques sont des relations temporaires créées par l’étape de

liaison.



Utilisation de l’interface d’événements TEC avec System Automation

for Multiplatforms

Les sections suivantes expliquent comment utiliser l’interface d’événements TEC

(Tivoli Enterprise Console) pour avertir les administrateurs système lorsque des

événements importants surviennent dans les grappes automatisées par System


Chaque fois qu’une modification de la configuration de System Automation for

Multiplatforms ou de l’état d’une ressource automatisée intervient, mais aussi

lorsque des problèmes sont détectés, l’interface d’événements TEC peut être

utilisée pour avertir l’administrateur système.

Il existe deux façons d’avertir l’administrateur :

1. Via l’envoi d’événements à IBM Tivoli Enterprise Console. Le diffuseur de

publications TEC doit au préalable être activé (voir «Activation de la fonction

de diffuseur de publications de TEC», à la page 223).

2. Via la publication d’attributs internes de System Automation for Multiplatforms

dans l’infrastructure RSCT. L’administrateur doit s’abonner à l’un des scripts de

l’Event Resource Manager (ERRM) afin d’obtenir les données sur l’événement.

Pour plus d’informations sur cette procédure, voir IBM Reliable Scalable Cluster

Technology for Linux, Technical Reference, SA22–7983. Vous pouvez également

consulter la description fournie dans la section précédente «Génération

d’événements en cas d’incidents», à la page 232.

Qu’est-ce que Tivoli Enterprise Console ?

Tivoli Enterprise Console (TEC) est une application de gestion d’événements basée

sur des règles qui utilise un serveur central pour traiter les événements entrants.

TEC agit comme un point de collecte central pour les alarmes et les événements

provenant de sources différentes, notamment d’applications Tivoli, d’applications

partenaires Tivoli, d’applications client, de plateformes de gestion de réseaux et de

systèmes de bases de données relationnelles.

Qu’est-ce que les événements ?

Les événements sont des unités d’informations qui peuvent représenter les

données de performance ou indiquer des problèmes, des états et des modifications

concernant les ressources. En règle générale; System Automation for

Multiplatforms envoie des événements lorsque l’aide d’un administrateur est

requise.

Le langage ″Basic Recorder of Objects in C (BAROC)″ est utilisé pour définir la

structure des événements et leurs propriétés. Ces définitions sont stockées dans des

fichiers portant l’extension .baroc.



Envoi d’événements vers TEC

System Automation for Multiplatforms utilise la fonction d’intégration

d’événements (EIF) Tivoli de l’interface d’événements TEC pour envoyer des

événements vers TEC. Les événements seront envoyés sur le port d’événements

non TME du serveur de TEC.

Les raisons suivantes sont à l’origine d’envoi d’événements de System Automation

for Multiplatforms vers TEC :

v Modification de l’état d’une ressource ou d’une grappe.

v Ajout ou suppression d’une ressource.

v Ajout ou suppression d’une relation.

v Ajout ou suppression d’une requête.

Activation de la fonction de diffuseur de publications de TEC

Afin de recevoir et d’afficher les événements provenant de sources différentes telles

que des programmes, des systèmes ou des périphériques réseau, vous devez

activer le diffuseur de publications de TEC en effectuant les étapes suivantes :

1. Importez, compilez, chargez et activez le fichier baroc de TEC dans le serveur

TEC (/usr/sbin/rsct/samples/tec/SystemAutomation.baroc). Pour plus

d’informations sur cette procédure, voir IBM Tivoli Enterprise Console Rule

Builder’s Guide, GC32–0669.

2. Copiez les fichiers /usr/sbin/rsct/samples/tec/samPublisher.conf et

/usr/sbin/rsct/samples/tec/TECPublisher.conf dans /etc/Tivoli/tec sur tous les noeuds

de grappe System Automation for Multiplatforms.

3. Personnalisez le fichier de configuration du diffuseur de publications

/etc/Tivoli/tec/samPublisher.conf et le fichier EIF de TEC /etc/Tivoli/tec/TECPublisher.conf dans chaque noeud de grappe.

4. Activez le diffuseur de publications en exécutant la commande samctrl –e TEC

sur un noeud de grappe System Automation for Multiplatforms. Par défaut, le

diffuseur de publications est désactivé. Exécutez la commande samctrl –e P

pour activer simultanément tous les diffuseurs définis dans le fichier de

configuration du diffuseur de publications.



Fichier de configuration du diffuseur de publications

Le fichier de configuration du diffuseur de publications /etc/Tivoli/tec/samPublisher.conf définit une liste de consommateurs cible ainsi que leurs

paramètres. Il s’agit du format de syntaxe du fichier de configuration du diffuseur

de publications :

Les règles de syntaxe suivantes sont d’application :

v les lignes qui commencent par # et des lignes vides sont ignorées

v format de paramètre : <keyword>=<value>

v le mot clé ″Publisher″ commence un nouveau triplet de paramètres ″Publisher″,

″LibraryPath″ et ″ConfigPath″

v le mot clé ″Publisher″ spécifie le nom unique du programme de publication

v le mot clé ″LibraryPath″ spécifie le chemin absolu d’accès à la bibliothèque du

programme de publication

v le mot clé ″ConfigPath″ spécifie le chemin d’accès absolu au fichier de

configuration EIF de TEC.

v la valeur du mot clé "Publisher" doit comporter de 1 à 8 caractères

v la valeur du mot clé "Publisher" ne peut comporter que les caractères suivants :

'0'-'9', 'A'-'Z', 'a'-'z' et '_'

v les valeurs ″RMC″, ″P″, ″ALL″ et ″STOPALL″ du mot clé ″Publisher″ sont

réservées

v un maximum de 15 programmes de publication peut être spécifié dans ce

fichier de configuration

#

# Publisher configuration file

# file name: /etc/Tivoli/tec/samPublisher.conf

#

# File format:

# <keyword>=<value>

#

# Publisher - nom unique du diffuseur de publications

# longueur du nom : 1-8 caractères

# caractères valides : ’0’-’9’, ’A’-’Z’, ’a’-’z’ et ’_’

# LibraryPath - nom de la bibliothèque du diffuseur de publications

# ConfigPath - chemin d’accès absolu vers le fichier de configuration EIF

# de TEC

#

# Plusieurs entrées au niveau de "Publisher", "LibraryPath" et "ConfigPath"

# peuvent être spécifiées.

# Un triplet pour client cible du diffuseur de publications.

# Nombre maximal de diffuseurs de publications pris en charge : 15

# Section de mise à jour en ligne -----------------------------------------------

# Fin de section de mise à jour en ligne ----------------------------------------

Publisher=TEC

LibraryPath=libTECPublisher.so

ConfigPath=/etc/Tivoli/tec/TECPublisher.conf

# Publisher=TEC2

# LibraryPath=libTECPublisher.so

# ConfigPath=/etc/Tivoli/tec/TECPublisher2.conf

Figure 15. Format de syntaxe et exemple de fichier de configuration du diffuseur de

publications



Fichier de configuration EIF de TEC /etc/Tivoli/tec/TECPublisher.conf

Le fichier de configuration EIF de TEC spécifie tous les paramètres nécessaires

pour se connecter à un serveur TEC spécifique. Le nom de fichier doit

correspondre au nom spécifié en tant que ″ConfigPath″ dans le fichier de

configuration de TEC.

Le format de syntaxe du fichier EIF de TEC pour le diffuseur de publications de

TEC est la syntaxe existante du fichier de configuration EIF de TEC.

# TEC EIF configuration file

#

# File format:

# <keyword>=<value>

#

# ServerLocation - nom de l’hôte sur lequel le serveur TEC fonctionne

# ServerPort - numéro de port sur lequel le serveur TEC écoute

# les événements TEC non TME. Les événements TEC TME ne sont pas pris en charge

# 5529 - port non TME par défaut des serveurs TEC sous Windows

# 0 - port non TME par défaut des serveurs TEC sous AIX et Linux

# ConnectionMode - établit la distinction entre connection_oriented OU connection_less

# - (le mode par défaut est connection_oriented)

# BufferEvents - indique si le fichier de stockage temporaire est activé

# (YES | MEMORY_ONLY | NO) (l’option par défaut est YES)

# BufEvtPath - indique le nom de chemin d’accès absolu au fichier cache

# (chemin par défaut : /etc/Tivoli/tec/cache)

# NO_UTF8_CONVERSION - indique si la conversion UTF8 est effectuée de nouveau dans la

# bibliothèque EIF

# La valeur doit être OUI, autrement l’événement est corrompu

# (la valeur par défaut est NON)

# FilterMode - indique si les événements qui correspondent à un filtre son envoyés vers

# le serveur d’événements (FilterMode=IN) ou éliminés

# (FilterMode=OUT) (la valeur par défaut est OUT)

# Filter - Filtre :Classe=nom_classe;[attribut=valeur[;attribut=valeur]*]

#

# Pour une description de tous les mots clés pris en charge et de leurs valeurs,

# reportez-vous au manuel : “Tivoli Event Integration Facility - Reference", SC32-1241,

# Chapitre : “Appendix B. Keywords for Configuration Files“.

#Indiquez le nom de serveur ou l’adresse IP du serveur sur lequel TEC fonctionne

#champ “ServerLocation”.

ServerLocation=tecserver.ibm.com

ServerPort=5529

ConnectionMode=connection_less

BufferEvents=YES

BufEvtPath=/etc/Tivoli/tec/TECPublisher.cache

NO_UTF8_CONVERSION=YES

# Filtres par défaut

# Filtrer toutes les relations d’ajout/de suppression d’événements

Filtre :Class=SystemAutomation_Relationship_Configuration_Change

# Filtrer tous les événements d’ajout/de suppression de ressources

Filtre :Class=SystemAutomation_Resource_Configuration_Change

# Filtrer les événements de statut de ressources possédant la sévérité HARMLESS (inoffensif)

Filtre :Class=SystemAutomation_Resource_Status_Change;severity=HARMLESS

# Filtrer les événements de statut de ressources possédant la sévérité WARNING (avertissement)

Filtre :Class=SystemAutomation_Resource_Status_Change;severity=WARNING

# Filtrer toutes les requêtes d’ajout/de suppression d’événements

Filtre :Class=SystemAutomation_Request_Configuration_Change

Figure 16. Format de syntaxe et exemple du fichier de configuration de TEC



Pour éviter l’encombrement de TEC par un flot important de messages, les filtres

sont fournis dans le fichier de configuration EIF # de TEC. Tous les filtres sont

activés par défaut ; seuls les messages critiques sont envoyés à TEC. Si vous

souhaitez envoyer des messages supplémentaires à TEC, désactivez le filtre

correspondant en utilisant le caractère de commentaire #.

Activation du diffuseur de publications

Par défaut, la fonction de diffuseur de publications est désactivée. Pour connaître

l’état du diffuseur de publications, exécutez la commande suivante :

node1:/usr/sbin/rsct/samples/tec # lssamctrl

Les données de contrôle suivantes de System Automation for Multiplatforms

s’affichent :

SAMControl:

TimeOut = 60

RetryCount = 3

Automation = Auto

ExcludedNodes = {}


ActiveVersion = [1.2.0.0,Fri Apr 16 16:05:50 2004]

EnablePublisher = Désactivé

Pour activer le diffuseur de publications de TEC, exécutez la commande suivante

sur un noeud :

node1:/usr/sbin/rsct/samples/tec # samctrl –e TEC

Pour désactiver le diffuseur de publications de TEC, exécutez la commande

suivante sur un noeud :

node1:/usr/sbin/rsct/samples/tec # samctrl –d TEC

Pour activer tous les diffuseurs définis dans le fichier de configuration du diffuseur

de publications, exécutez la commande suivante sur un noeud :

node1:/usr/sbin/rsct/samples/tec # samctrl –e P

Pour désactiver tous les diffuseurs définis dans le fichier de configuration du

diffuseur de publications, exécutez la commande suivante sur un noeud :

node1:/usr/sbin/rsct/samples/tec # samctrl –d P

Configuration d’un nouveau paramètre de lieu pour les

messages d’événement de TEC

Les messages d’événement de TEC sont toujours définis dans la langue dans

laquelle le système est défini par défaut sur le noeud où le document maître IBM

Tivoli System Automation for Multiplatforms fonctionne.

Remarque : Les noms de ressources dans les messages d’événement de TEC

peuvent être endommagés si l’utilisateur a créé les ressources (mkrg,

mkrsrc) dans un interpréteur de commandes dont le paramètre de lieu

est différent du paramètre de lieu par défaut du système, ou que le

programme du terminal possède un jeu de caractères différent du

paramètre de lieu de l’interpréteur de commandes. Pour résoudre ce

problème, les paramètres de lieu du système et de l’interpréteur de

commandes doivent être configurés de manière identique et le

transcodage de caractères du programme du terminal doit être défini

en fonction des paramètres adéquats. Si le paramètre de lieu de

l’interpréteur de commandes est modifié et que les ressources sont



créées à l’aide d’anciens paramètres de lieu, toutes les ressources

devront être supprimées et recréées à l’aide des nouveaux paramètres

de lieu.

Si l’utilisateur décide de modifier les paramètres de lieu du système par défaut en

fonction de ses besoins, il lui faudra effectuer cette modification sur tous les

noeuds de grappe. Pour se faire, procédez comme suit :

1. Arrêtez la grappe à l’aide de la commande stoprpdomain.

2. Modifiez le fichier qui contient les paramètres système régionaux par défaut,

définissez les valeurs appropriées et enregistrez le fichier.

SUSE Linux

Fichier : /etc/sysconfig/language

Mots clés : RC_LANG="<NewLocale>" (remplacez <NewLocale> par vos

paramètres régionaux)

ROOT_USES_LANG="yes"

Tous les mots clés commençant par RC_LC_ doivent être définis pour

les chaînes vides ""

par exemple RC_LC_ALL= ""

Exécutez /etc/SUSEconfig pour appliquer les modifications apportées à

votre système.

Vous pouvez également utiliser l’outil de configuration système yast2

sysconfig pour appliquer ces modifications.

RedHat Linux

File: /etc/sysconfig/i18n

Keywords: LANG="<NewLocale>" (remplacez <NewLocale> par vos


AIX

File: /etc/environment

Keywords: LANG="<NewLocale>" (remplacez <NewLocale> par vos


3. Réamorcez le système.

4. Renouvelez les étapes sur tous les noeuds de grappe.

5. Démarrez la grappe à l’aide de la commande startrpdomain.

Publication d’attributs internes de System Automation for

Multiplatforms dans l’infrastructure RSCT

Cette fonction porte les attributs internes de System Automation for Multiplatforms

à la connaissance de l’infrastructure RSCT. A cet effet, les classes de ressources

IBM.ResourceGroup, IBM.Equivalency, et IBM.ManagedResource sont étendues à

l’aide de l’attribut de structure de données dynamique AutomationDetails. La

structure de données dynamique AutomationDetails contient les attributs

suivants :

v CompoundState – état général de la ressource, y compris des dépendances de

groupes. Indique l’état de progression de la ressource vers l’état souhaité

(DesiredState). Par exemple, ″satisfaisant″ indique que la ressource ou le groupe

de ressources a atteint l’état souhaité par l’utilisateur.



v DesiredState – état de la ressource demandé par l’utilisateur. Par exemple, ″En

ligne″ indique que l’utilisateur a demandé que la ressource soit en ligne.

v ObservedState – état actuel de la ressource du point de vue de l’automatisation.

Par exemple, ″En ligne″ indique que la ressource est actuellement en ligne.

v BindingState – état indiquant si la ressource est liée à un système spécifique. Par

exemple, ″Lié″ indique que la ressource est actuellement liée à un système

spécifique.

v AutomationState – état indiquant si la ressource est en cours d’automatisation.

Par exemple, ″En veille″ indique qu’System Automation for Multiplatforms n’est

pas en train d’essayer de démarrer ou d’arrêter la ressource.

v ControlState – état indiquant que la ressource peut être contrôlée à l’aide de

l’automatisation. Par exemple, ″Démarrable″ indique qu’il est actuellement

possible de démarrer la ressource.

v HealthState – état de santé de la ressource. Cet état est réservé aux versions

ultérieures.

Les commandes lsequ et lsrg ont été développées afin d’afficher ces attributs.

Tout changement de valeur de l’un ou l’autre des attributs signale le changement

d’état d’une ressource et est publié dans RSCT. Si le diffuseur de publications de

TEC est activé (voir «Activation de la fonction de diffuseur de publications de

TEC», à la page 223), ces modifications d’état sont également indiquées en tant

qu’événements de TEC.

Activation de GDPS/PPRC Multiplatform Resiliency for zSeries

De nos jours, les marchés et les entreprises dépendent des solutions de reprise sur

incident afin de récupérer des données vitales. C’est la raison pour laquelle System

Automation for Multiplatforms prend en charge GDPS/PPRC Multiplatform

Resiliency sur System z (xDR).

GDPS (Geographically Dispersed Parallel Sysplex) est une solution de mise à

disposition des applications et de reprise sur incident, très personnalisée qui

fonctionne avec votre environnement z/OS. Elle permet d’effectuer une reprise sur

incident et de défaillance à partir d’un point de contrôle unique et d’assurer la

cohérence des données. Pour plus d’informations sur GDPS, voir le document IBM

Redbooks GDPS Family - An Introduction to Concepts and Capabilities, SG24-6374-01,

qui peut-être téléchargé à l’adresse http://ibm.com/redbooks.

System Automation for Multiplatforms permet d’étendre GDPS/PPRC pour les

systèmes Linux qui s’exécutent sur System z. Il fournit une solution coordonnée de

reprise sur incident, exécutée sur zSeries, dont z/OS, Linux sur System z sous

z/VM, et Linux sur System z exécutant une version native dans le LPAR.

Remarques :

1. Si vous souhaitez utiliser la fonctionnalité xDR, des versions particulières de

z/VM, Linux sur System z, GDPS et System Automation for Multiplatforms

doivent être installées. Pour plus d’informations sur la fonctionnalité disponible

et les versions nécessaires, reportez-vous aux manuels GDPS. System

Automation for Multiplatforms prend en charge xDR pour Linux sur System z

uniquement.

2. Les conventions de nommage xDR nécessitent que le nom des grappes et des

noeuds ne dépasse pas 32 caractères. Pour xDR, le nom des grappes ne dépend

pas des minuscules/majuscules. Pour utiliser xDR, System Automation for

Multiplatforms doit être personnalisé selon les indications des manuels GDPS.



3. L’anglais est la seule langue prise en charge par xDR et GDPS.

Version GDPS prise en charge

xDR requiert GDPS V3.3 avec l’APAR PK30315 ou ultérieur

Distributions Linux prises en charge

Les distributions Linux suivantes sont prises en charge pour xDR :

v xDR for Linux sur z/VM nécessite SUSE SLES 9 SP2 ou RedHat

v xDR for Linux exécutant une version native dans LPAR requiert SUSE SLES 10

SP1. Pour la prise en charge native de LPAR, GDPS 3.4 est obligatoire

v xDR for Linux sur xSeries et pSeries nécessite SUSE



Vérification dynamique des ressources

La vérification des ressources est généralement réalisée pendant la configuration,

lors de la définition de la ressource dans System Automation for Multiplatforms.

L’utilisateur est alors immédiatement averti en cas de problème et la définition

d’une nouvelle ressource échoue.

Il se peut que cela ne soit pas le cas lorsqu’une ressource a été définie, une

modification de configuration a alors lieu. System Automation for Multiplatforms

est averti lorsque la modification de configuration a eu lieu ; il doit alors accepter

ou réagir à ces modifications. En conséquence, il se peut qu’une ou plusieurs

ressources ne soient plus valides.

Cela peut par exemple se produire lorsque vous définissez une ressource à l’aide

de la commande mkrsrc, que vous modifiez les valeurs d’une ressource à l’aide de

la commande chrsrc ou que vous supprimez une ressource définie en utilisant la

commande rmrsrc.

Afin de vérifier ces modifications de configuration et de conserver la validité d’une

ressource pour l’utilisateur, les classes de ressources IBM.ResourceGroup,

IBM.ManagedResource, IBM.Equivalency et IBM.ManagedRelationship contiennent

un attribut dynamique ConfigValidity (validité de la configuration). L’attribut

ConfigValidity contient une chaîne expliquant pourquoi une ressource n’est pas

valide.

Utilisez la commande lsrsrc –Ad pour afficher la valeur de l’attribut ConfigValidity

avec les valeurs d’autres attributs dynamiques d’une ressource.

Les vérifications suivantes sont effectuées :

v L’attribut AllowedNode (noeud autorisé) d’un groupe de ressources est vide

Lorsque vous retirez un noeud, il se peut qu’une équivalence contienne une liste

de membres vide. Un groupe de ressources ne sera plus valide s’il utilise cette

équivalence vide en tant qu’attribut ″AllowedNode″. Lorsque cela se produit,

l’attribut dynamique ″ConfigValidity″ du groupe de ressources contient la chaîne

"Allowed node list is empty".

v L’intersection entre les noeuds autorisés (AllowedNode) des groupes de

ressources imbriqués est vide

Dans un groupe de ressources colocalisé, tous les groupes de ressources internes

imbriqués et les groupes de ressources qu’ils contiennent doivent posséder au

minimum un noeud en commun. S’il existe un seul noeud commun, et que vous

supprimez ce noeud, plus aucun groupe de ressources ne sera valide. Si tel est le

cas, l’attribut dynamique ″ConfigValidity″ du groupe de ressources contiendra la

chaîne ″Aucun noeud commun dans le groupe de ressources imbriqué

colocalisé″.

v Pas de noeud pour exécuter la ressource

Dans un groupe de ressources, il se peut qu’il existe un seul noeud commun

entre les attributs ″AllowedNode″ des groupes de ressources et l’attribut

NodeNameList d’un membre d’une ressource. Si vous supprimez ce noeud, le

groupe de ressources ne sera plus valide. Si tel est le cas, l’attribut dynamique

″ConfigValidity″ du groupe de ressources contiendra la chaîne ″Aucun noeud

commun pour démarrer la ressource″.



v Aucun noeud pour satisfaire une relation

Dans une relation DependsOn (dépendant de), avec une colocalisation implicite,

l’attribut NodeNameList de la source et NodeNameList de la ressource cible

doivent posséder au minimum un noeud en commun. Si vous supprimez ce

noeud, la relation ne sera plus valide. Si tel est le cas, l’attribut dynamique

″ConfigValidity″ du groupe de ressources contiendra la chaîne ″Aucun noeud

commun entre la source et la cible″.

v Impossible de satisfaire une relation AntiCollocated - 1

Si deux ressources flottantes obligatoires d’un groupe de ressources possèdent

chacune une relation AntiCollocated l’une envers l’autre, et que l’opération de

suppression résulte en la présence d’un noeud unique dans l’attribut

AllowedNode du groupe de ressources, le groupe de ressources ne sera plus

valide. Si tel est le cas, l’attribut dynamique ″ConfigValidity″ du groupe de

ressources et la relation gérée AntiCollocation contiendront la chaîne ″Impossible

de satisfaire une relation AntiCollocated″.

v Impossible de satisfaire une relation AntiCollocated - 2

Une suppression de noeuds ne laisse plus qu’un seul composant dans le même

noeud de deux ressources flottantes. Mais les deux ressources possèdent une

relation AntiCollocated. Si tel est le cas, les attributs dynamiques

″ConfigValidity″ de la relation gérée AntiCollocated contiendront la chaîne

″Impossible de satisfaire une relation AntiCollocated″.

v Propagation de l’invalidité

Tout groupe de ressources interne non valide provoquera la non validité des

groupes de ressources qu’il contient. Dans ce cas, l’attribut dynamique

″ConfigValidity″ du groupe de ressources concerné contiendra la chaîne ″Un

groupe de ressources joint est incorrect″.



Conseils et astuces

Cette section offre des conseils et astuces utiles pour administrer des grappes à

l’aide de System Automation for Multiplatforms.

Redémarrage d’un noeud

Ne redémarrez pas un noeud lorsque des ressources fonctionnent sur ce noeud.

Arrêtez tout d’abord toutes les ressources en cours d’exécution à l’aide de la

commande :

samctrl -u a <nom_noeud>

Maintenant, vous pouvez redémarrer le noeud en toute sécurité.

Cette commande empêche également le démarrage des ressources sur ce noeud.

Réactivez le noeud pour les ressources en cours d’exécution en entrant la

commande suivante :

samctrl -u d <nom_noeud>

Arrêt d’un noeud

Avant d’arrêter un noeud (par ex., à l’aide de la commande RSCT stoprpnode ),

vous devez exclure ce noeud de l’automatisation à l’aide de la commande :

samctrl -u a <nom_noeud>

Cette exclusion doit être effectuée même si aucune ressource n’est actuellement en

ligne sur le noeud.

Lorsque vous avez redémarré le noeud et qu’il est en ligne, vous devez à nouveau

établir l’automatisation sur ce noeud en saisissant la commande :

samctrl -u d <nom_noeud>

Génération d’événements en cas d’incidents

RSCT possède la capacité de générer des événements lors de la modification d’un

attribut dynamique d’une ressource. Cette opération est possible grâce à l’ERRM

(event response resource manager - gestionnaire de ressources de réponse à

événement). Le gestionnaire de ressources de réponse à événement propose un

ensemble de commandes qui vous permettent de gérer les événements d’intérêt

(appelés ″conditions″) et de faire réagir le système RMC de façon particulière

(appelées ″réponses″) si l’événement se produit.

Aussi, par exemple, vous pouvez souscrire à l’état opérationnel d’un groupe de

ressources et recevoir un e-mail en cas de modification de son état. Vous pouvez

également gérer différentes ressources vitales dans votre système. Pour plus

d’explications sur la génération de ce type d’événements, consultez le chapitre

consacré aux principes de base du contrôle des ressources dans IBM Reliable

Scalable Cluster Technology for Linux, Technical Reference, SA22–7893.



Chapitre 11. Automatisation des ressources System


Le présent chapitre aborde le processus d’automatisation des ressources pour

lesquelles System Automation for Multiplatforms fournit des gestionnaires de

ressources.

Utilisation du Global Resource Manager (gestionnaire de ressources

globales)

Cette section décrit les caractéristiques du Global Resource RM.

Le Global Resource RM (IBM.GblResRM) offre les deux classes de ressources

suivantes :

1. IBM.Application :

Cette classe permet la gestion et le contrôle de types de ressources

supplémentaires (par ex., les applications métier) via le sous-système RMC. Ces

ressources peuvent être automatisées ou récupérées par des applications de

gestion telles qu’System Automation for Multiplatforms.

2. IBM.ServiceIP :

Cette classe est utilisée pour la gestion des adresses IP pouvant être démarrées,

arrêtées ou déplacées entre des adaptateurs réseau et des noeuds au sein d’un

domaine homologue sous le contrôle du sous-système RMC. Ces adresses IP

sont généralement fournies aux clients qui se connectent à un service

quelconque s’exécutant dans le domaine. System Automation for

Multiplatforms peut ensuite être utilisé pour que le service et l’adresse IP qui

lui sont associés restent actifs, même en cas de défaillance dans le domaine.

Le gestionnaire de ressources (et l’accès à ses classes) est utilisable en mode de

domaine homologue uniquement.

La sous-section suivante décrit les caractéristiques externes des classes de

ressources prises en charge par ce gestionnaire de ressources. Chacune des

sous-sections décrit une classe de ressources, ainsi que ses attributs persistants et

dynamiques, ses actions, etc.

Qu’est-ce que la classe de ressources IBM.Application ?

La classe de ressources IBM.Application permet la création, la gestion et le contrôle

des nouveaux types de ressources flottantes et fixes via le sous-système RMC. Ces

ressources peuvent être automatisées ou récupérées par System Automation for

Multiplatforms. Afin de créer une nouvelle ressource, les trois scripts suivants

(commandes rép.) doivent être fournis :

1. Un script de démarrage (ou commande) pour mettre la ressource en ligne.

2. Un script d’arrêt (ou commande) pour mettre la ressource hors ligne.

3. Un script (ou une commande) permettant de gérer la ressource au cours de

l’interrogation.


Outre ces scripts, il existe les paramètres de base suivants pour la classe de

ressources IBM.Application :

1. Le nom de la ressource.

2. Les noeuds sur lesquels la ressource peut être exécutée.

3. Un nom d’utilisateur pour démarrer/lancer/gérer l’application.

4. Une méthode à utiliser afin de démarrer/lancer/gérer l’application de manière

synchrone ou asynchrone.

5. Différentes valeurs de délai d’attente.

6. La caractérisation de la ressource en tant que vitale ou non vitale.

7. La détermination de la fréquence de contrôle.

8. L’identification de la ressource en tant que ressource fixe ou flottante.

Chaque ressource générique orchestrée à l’aide de la classe de ressources

IBM.Application est considérée comme une ressource globale, c.-à-d. qu’elle n’est

pas liée à un noeud unique. Cependant, la ressource peut être définie comme

existante dans un seul sous-ensemble de noeuds de la grappe. Pour chaque

ressource générique, vous devez créer une instance de la classe de ressources

IBM.Application. Cette instance s’appelle ″ressource d’agrégat″ car elle représente

la ressource flottante qui peut être déplacée entre des noeuds. En outre, il existera

également une instance de la classe de ressources IBM.Application pour chaque

noeud dans lequel la ressource générique existe. Ces instances s’appellent

″ressources constituantes de la ressource d’agrégat″. Les ressources constituantes

sont des ressources fixes, c.-à-d. qu’elles existent sur un noeud exactement de la

grappe. La figure 17 illustre la différence entre des ressources d’agrégat et

constituantes.

Les ressources constituantes sont créées ou supprimées automatiquement lorsque

la définition de la ressource d’agrégat est modifiée. La plupart des opérations de

gestion sont effectuées via la ressource d’agrégat, mais il se peut que certaines

applications choisissent de contrôler directement les constituants ou de fonctionner

directement sur eux. Les modifications apportées à la ressource d’agrégat sont

automatiquement appliquées à tous les constituants, alors que la modification

apportée à un attribut d’un constituant affecte uniquement ce constituant et ne

s’applique pas aux autres ressources (par exemple, le constituant d’un noeud peut

posséder une commande de démarrage différente ou un intervalle de contrôle

différent).

Lorsque vous retirez des noeuds de l’attribut NodeNameList de la ressource

d’agrégat, les constituants sont supprimés automatiquement.

Figure 17. Ressource d’agrégat et ressources constituantes

Global resource RM


Attributs utilisés par IBM.Application

Cette section décrit les attributs utilisés par les ressources de la classe de ressources

IBM.Application.

Lorsqu’une ressource de cette classe est créée à l’aide de la commande RMC

mkrsrc, elle doit posséder les attributs suivants :

v Name

v StartCommand

v StopCommand

v MonitorCommand

v UserName

Les ressources de cette classe peuvent posséder les attributs suivants :

v NodeNameList

v ResourceType

v StartCommandTimeout

v StopCommandTimeout

v MonitorCommandTimeout

v MonitorCommandPeriod

v RunCommandsSync

v ProtectionMode

Les ressources de cette classe possèdent l’attribut dynamique suivant :

v OpState

Attribut Name

L’attribut persistant Name est un nom défini par l’utilisateur pour

la ressource d’application générique. La ressource d’agrégat et la

ressource constituante possèdent la même valeur pour cet attribut.

Vous devez spécifier une valeur unique pour cet attribut à la

création d’une nouvelle ressource IBM.Application.

L’attribut doit être un type de chaîne de caractères.


L’attribut persistant NodeNameList est un tableau de chaînes

indiquant les noeuds sur lesquels la ressource IBM.Application est

disponible.

Si la ressource est flottante, le Global Resource RM veillera à ce

qu’il existe une ressource constituante (c.-à-d. fixe) pour chaque

nom de noeud de la liste. Les ressources constituantes sont créées

ou supprimées de manière implicite en fonction des besoins de

correspondance avec les entrées de la liste. Les ressources

constituantes ne contiendront qu’une seule entrée dans ce tableau,

car il s’agit de ressources fixes qui ne peuvent donc être

disponibles que sur un seul noeud. Pour une ressource flottante,

cet attribut est modifié de manière implicite si une ressource

constituante est supprimée de manière explicite par

l’administrateur afin que la relation entre la ressource d’agrégat et

la ressource constituante soit toujours cohérente.

Il se peut que cette liste soit vide pour une ressource flottante, ce

qui signifie qu’elle n’est disponible nulle part et que les

constituants peuvent être ajoutés séparément.

La liste peut contenir au maximum un nom si la ressource est fixe

Global resource RM

Chapitre 11. Automatisation des ressources System Automation for Multiplatforms 235

(c.-à-d. si ResourceType=0). Si aucun nom n’a été attribué à une

ressource fixe, RMC proposera un nom par défaut. En effet, la

ressource fixe est associée à un noeud et elle ne peut donc pas être

créée sans nom ou ID de noeud.

Pour les ressources d’agrégat, la valeur de cet attribut peut être

modifiée à l’aide de la commande chrsrc. Toute tentative de

modification de cet attribut pour une ressource constituante

générera une erreur.


L’attribut persistant ResourceType vous permet d’identifier s’il

s’agit d’une ressource fixe ou flottante. Une valeur entière 0

indique que la ressource est fixe, un valeur 1 indique qu’il s’agit

d’une ressource flottante. Cet attribut est défini par défaut sur

flottant s’il n’est pas spécifié à la création d’une nouvelle ressource

IBM.Application.

Attribut StartCommand

La valeur de l’attribut persistant StartCommand contient la

commande et les arguments exacts qui seront exécutés lorsque le

gestionnaire de ressources reçoit une requête de démarrage pour

l’instance de la ressource correspondante. La commande est

uniquement exécutée par les ressources constituantes même si la

requête de mise en ligne a été envoyée à la ressource d’agrégat.

Dans ce cas, le gestionnaire de ressources choisira une ressource

constituante si celle-ci n’est pas spécifiée afin d’exécuter la requête

de mise en ligne.

La commande est exécutée sous l’ID utilisateur spécifié avec

l’attribut UserName.

La commande est exécutée avec les droits d’accès et

l’environnement de l’utilisateur spécifié.

L’attribut RunCommandSync détermine si le gestionnaire de

ressources doit attendre ou non la fin de l’exécution de la

commande (voir rubrique suivante pour obtenir des informations

supplémentaires). Le nom de la commande doit être une chaîne de

caractères et un chemin d’accès absolu (c.-à-d. qu’il doit

commencer par un ‘/’). Il doit exister et être exécutable dans

chaque noeud où la ressource est accessible (c.-à-d. où il y a un

constituant).

Cet attribut doit être spécifié lorsqu’une nouvelle ressource

IBM.Application est définie.

Le chemin ou les options de la commande StartCommand d’une

ressource IBM.Application ne doivent comporter aucun caractère

NLS.

La commande peut renvoyer les valeurs suivantes :

0 La commande a été exécutée avec succès.

!= 0 Une erreur s’est produite lors du traitement de la

commande.

Voir «Gestion des codes retour des commandes de démarrage,

d’arrêt et de contrôle par le gestionnaire de ressources», à la page

243.

Attribut StopCommand

La valeur de l’attribut persistant StopCommand contient la

Global resource RM


commande et les arguments exacts qui seront exécutés lorsque le

gestionnaire de ressources reçoit une requête d’arrêt pour l’instance

de la ressource. Une requête d’arrêt de l’agrégat sera émise par

tous les constituants.

Tous les autres aspects liés à l’exécution de la commande sont

identiques à ceux de l’attribut StartCommand.


IBM.Application est définie.

Le chemin ou les options de la commande StopCommand d’une

ressource IBM.Application ne doivent comporter aucun caractère

NLS.

La commande peut renvoyer les valeurs suivantes :

0 La commande a été exécutée avec succès.

!= 0 Une erreur s’est produite lors du traitement de la

commande.

Voir «Gestion des codes retour des commandes de démarrage,

d’arrêt et de contrôle par le gestionnaire de ressources», à la page

243.

Attribut MonitorCommand

La valeur de l’attribut persistant MonitorCommand contient la

commande et les arguments exacts qui seront exécutés afin de

déterminer ou de mettre à jour l’état opérationnel (l’attribut

OpState) de la ressource. La valeur de sortie de la commande est

utilisée en tant que nouvel état opérationnel de la ressource :

Inconnu (Unknown) = 0

En ligne (Online) = 1

Hors ligne (Offline) = 2

Echec en ligne (Failed Offline) = 3

Arrêt en ligne (Stuck Online) = 4

En attente en ligne (Pending Online) = 5

En attente hors ligne (Pending Offline) = 6

L’état En ligne ou Hors ligne doit au minimum être défini par le

script MonitorCommand.

IBM.GblResRM exécute la commande à chaque échéance de la

durée MonitorCommandPeriod lorsqu’il y a des abonnés pour

l’attribut dynamique OpState. Tous les autres aspects relatifs à

l’exécution de la commande sont identiques à ceux décrits dans la

section ’Attribut StartCommand’. Afin d’éviter de consommer les

ressources système, cette commande doit être aussi efficace que

possible.

Cette commande doit être renvoyée dans un délai raisonnable,

généralement de quelques secondes et au plus de 360 secondes.Le nom de l’attribut MonitorCommand doit être un chemin d’accès

absolu (c.-à-d. qu’il doit commencer par un ‘/’). Il doit exister et

être exécutable dans chaque noeud où la ressource est accessible

(c.-à-d. où il y a un constituant).


IBM.Application est définie. Pour en apprendre davantage sur la

valeur retour de l’attribut MonitorCommand, consultez les sections

«Problématiques majeures lors de la définition des ressources

IBM.Application», à la page 242 et «Gestion des codes retour des

Global resource RM


commandes de démarrage, d’arrêt et de contrôle par le

gestionnaire de ressources», à la page 243.

Le chemin ou les options de la commande MonitorCommand

d’une ressource IBM.Application ne doivent comporter aucun

caractère NLS.

Attribut MonitorCommandPeriod

La valeur de l’attribut persistant MonitorCommandPeriod indique

la durée (nombre de secondes) d’attente entre les invocations de

l’attribut MonitorCommand. Cette période d’attente démarre

lorsque le premier appel est terminé. Cet attribut doit être un

entier supérieur à 0. Sa valeur par défaut est définie sur 5

secondes.

Cette période commençant à la fin de l’appel précédent, la valeur

de l’attribut MonitorCommandTimeout peut être supérieure à la

valeur de l’attribut MonitorCommandPeriod.

Attribut MonitorCommandTimeout

A l’aide de l’attribut persistant MonitorCommandTimeout, vous

pouvez spécifier la durée d’exécution autorisée pour une

commande de contrôle avant qu’elle ne soit supprimée à l’aide de

la commande killpg(). Si la commande arrive à expiration, l’état

opérationnel (attribut OpState) de la ressource est défini sur

Inconnu (Unknown) = 0.

Cet attribut doit être un entier supérieur ou égal à 0.

La valeur doit être inférieure à 360 secondes. La valeur par défaut

de cet attribut est de 5 secondes.

Attribut StartCommandTimeout

A l’aide de l’attribut persistant StartCommandTimeout, vous


commande de démarrage avant qu’elle ne soit supprimée à l’aide

de la commande killpg(). Cet attribut définit également le délai au

bout duquel System Automation for Multiplatforms s’attend à ce

que la ressource soit en ligne. Cette valeur est utilisée par System

Automation for Multiplatforms en lieu et place du délai d’attente

par défaut fourni avec les paramètres de contrôle.

Cet attribut doit être un entier supérieur ou égal à 0. Une valeur

équivalente à 0 pour cet attribut indique qu’il n’y a pas de délai

d’expiration. Cet attribut n’est pas utilisé si l’attribut

RunCommandsSync est défini sur 0. La valeur par défaut de cet

attribut est de 5 secondes.

Attribut StopCommandTimeout

A l’aide de l’attribut persistant StopCommandTimeout, vous


commande d’arrêt avant qu’elle ne soit supprimée à l’aide de la

commande killpg(). Cet attribut doit être un entier supérieur ou

égal à 0. Une valeur équivalente à 0 pour cet attribut indique qu’il

n’y a pas de délai d’expiration. La valeur par défaut de cet attribut

est de 5 secondes.

Attribut RunCommandsSync

Utilisez l’attribut persistant RunCommandsSync afin de contrôler si

les commandes de démarrage/d’arrêt sont exécutées de manière

synchrone avec la méthode en ligne()/hors ligne(). Si la valeur de

cet attribut est définie sur une valeur d’entier 1 qui est la valeur

Global resource RM


par défaut, la réponse aux méthodes en ligne() /hors ligne() ne

sera pas achevée avant l’aboutissement ou l’expiration de la

commande. Toute sortie stderr/stdout sera renvoyée dans la

réponse dans ce cas de figure. Si la valeur de cet attribut est 0,

alors IBM.GblResRM va ″lancer et oublier″ les commandes de

démarrage/d’arrêt. Lorsque fork/exec s’achève avec succès, le

gestionnaire de ressources les oublie et ils s’exécutent de manière

indépendante du gestionnaire de ressources.

Cet attribut est défini par défaut sur 1. Les délais d’expiration ne

s’appliquent pas aux commandes lorsque cet attribut est défini sur

0.Si votre commande de démarrage est l’exécutable de l’application

et que la commande ne répond pas après une certaine attente mais

fonctionne aussi longtemps que votre application fonctionne, vous

ne pouvez pas utiliser le mode synchrone. Si vous fonctionnez en

mode synchrone, le gestionnaire de ressources supprimera la

commande une fois le délai d’attente de la commande de

démarrage arrivé à expiration.

Utilisez CommandsSync=1 lorsque vous connaissez la durée

d’exécution de la commande de démarrage. Adaptez l’attribut

StartCommandTimeout en fonction de ce délai. Lors de surcharge

système, ce délai peut être allongé même en cas de démarrage

normal sans condition d’erreur.

Utilisez RunCommandsSync=0 lorsque la commande ne s’exécute

pas jusqu’à ce que votre application fonctionne (par exemple,

l’exécutable de votre application). Si vous souhaitez exécuter

l’exécutable de l’application directement (mode asynchrone) mais

que vous souhaitez utiliser le mode commande synchrone et

envoyer la commande aux interpréteurs de commandes en

arrière-plan, redirigez les descripteurs de fichier d’entrée-sortie. Si

le gestionnaire de ressources est toujours connecté au processus,

descripteurs d’entrée-sortie, le délai d’expiration la commande de

démarrage mettra fin à ce processus.

L’attribut RunCommandsSync contrôle également l’environnement

dans lequel les commandes de démarrage/d’arrêt et de contrôle

sont exécutées. Vous pouvez soit sélectionner un environnement de

base pour les commandes, soit le gestionnaire de ressources peut

exécuter un tour complet de l’environnement de connexion

comprenant le profil d’utilisateur et les fichiers de configuration.

Vous pouvez comparer cela à la commande système 'su' (switch

user) pour changer d’utilisateur. Vous pouvez conserver le même

environnement ou exécuter la commande 'su –' et le profil complet

(shell de connexion) pour l’utilisateur sélectionné. Les valeurs

suivantes sont admises pour l’attribut de ressource

RunCommandsSync :

Valeur Description

0 Exécute les commandes en mode asynchrone.

Exécute les commandes dans un environnement réduit.

1 (par

défaut)

Exécute les commandes en mode synchrone.

Exécute les commandes dans un environnement réduit.

Global resource RM


Valeur Description

2 Exécute les commandes en mode asynchrone.

Exécute les scripts de profil et de connexion pour

un utilisateur donné et génère l’environnement de

connexion des utilisateurs.

3 Exécute les commandes en mode synchrone.

Exécute les scripts de profil et de connexion pour

un utilisateur donné et génère l’environnement de

connexion des utilisateurs.

En fonction du système d’exploitation utilisé (AIX, Solaris ou

Linux), l’environnement réduit de l’utilisateur contient les variables

d’environnement suivantes (les valeurs des variables représentent

un exemple d’utilisateur) :

SHELL=/bin/bash

USER=myuser

PATH=:/usr/ucb:/bin:/usr/bin

LOGIN=myuser

PWD=/home/myuser

LANG=de_DE.UTF-8

HOME=/home/myuser

SHLVL=2

LOGNAME=myuser

Si ces valeurs ne sont pas suffisantes pour les commandes de

démarrage/d’arrêt et de contrôle, définissez les variables

nécessaires au niveau de la commande de démarrage/d’arrêt ou de

contrôle, ou ajoutez-les au profil d’utilisateurs (ou configuration de

l’interpréteur de commandes) et sélectionnez l’environnement de

connexion pour les commandes (RunCommandsSync=2|3).

Attribut UserName

L’attribut persistant UserName définit un nom d’utilisateur sous

lequel les commandes de contrôle, de démarrage et d’arrêt sont

exécutées. Les commandes sont exécutées avec les droits d’accès et

l’environnement de l’utilisateur spécifié. Une vérification sera

effectuée sur chaque noeud afin de garantir l’existence du nom

d’utilisateur en cas de modification de la configuration de la

ressource.


IBM.Application est définie. L’attribut doit être un type de chaîne

de caractères.

Attribut ProtectionMode

Utilisez l’attribut persistant ProtectionMode afin de spécifier si la

ressource est vitale ou non. S’il s’agit d’une ressource vitale,

IBM.ConfigRM décide si la ressource peut être démarrée comme

demandé. (Pour des informations supplémentaires sur ce

comportement, consultez le Chapitre 9, «Protection de vos

ressources – support réalisé par Quorum», à la page 167).

L’attribut peut posséder les valeurs d’entier 0 (non vitale) ou 1

(vitale). La valeur par défaut est ″non vitale″. Si la ressource est

définie sur la valeur ″Vitale″, le contrôle sera démarré

immédiatement, même si aucun abonné n’existe pour cette

ressource.

Global resource RM


Attribut OpState

La valeur de cet attribut d’état dynamique contient l’état

opérationnel de la ressource déterminé par le code de sortie issu de

l’exécution périodique de la commande. Les valeurs possibles de

cet attribut telles que définies dans le diagramme de transition

d’état de l’architecture RMC sont :








Cet attribut est disponible à partir de la ressource d’agrégat et de

toutes les ressources constituantes. La valeur d’une ressource

d’agrégat est un cumul des états de chacun des constituants.

HealthCommand

Réservé pour une utilisation ultérieure.

HealthCommandPeriod


HealthCommandTimeout


InstanceName


InstanceLocation


Actions utilisées par IBM.Application

Cette section décrit les actions pouvant être effectuées sur des ressources de la

classe de ressources IBM.Application.

Action refreshOpState

En fonctionnement normal, l’attribut MonitorCommandPeriod

détermine l’intervalle au bout duquel l’état opérationnel (OpState)

d’une ressource IBM.Application est évalué par son script de

contrôle. Si une ressource est capable de détecter un incident, il est

possible de déclencher une exécution immédiate du script de

contrôle chargé de la vérification de la ressource. Une

réinitialisation de l’état opérationnel de la ressource de

l’application aura immédiatement lieu.

Par exemple, pour réinitialiser l’état opérationnel de la ressource

’WebServer’ fonctionnant sur le noeud node02, exécutez la

commande suivante dans n’importe quel mode :

runact -s "Name=’WebServer’ && NodeNameList={’node02’}" IBM.Application refreshOpState

SendEIFevent Réservé pour une utilisation ultérieure.

Global resource RM


Problématiques majeures lors de la définition des ressources

IBM.Application

Gardez à l’esprit les remarques suivantes lorsque vous définissez une ressource

IBM.Application :

1. Afin de satisfaire l’objectif d’automatisation, les ressources de System

Automation for Multiplatforms sont toujours contrôlées. Que la commande soit

démarrée ou arrêtée, la commande de contrôle doit déterminer l’état actuel de

la ressource. N’installez pas la commande de contrôle dans un système de

fichiers qui n’est pas toujours présent (par exemple, un système NFS faisant

partie d’une règle et qui est uniquement introduit si la ressource NFS est

lancée). Si l’état opérationnel “inconnu” apparaît pour IBM.Application, vérifiez

le journal système et veillez à ce que le gestionnaire de ressources GblResRM

puisse accéder à la commande de contrôle à n’importe quel moment.

2. Le gestionnaire de ressources GblResRM supprimera toute commande

fonctionnant pendant un délai supérieur à la valeur de délai d’expiration

autorisée. Si vous constatez un état opérationnel “inconnu” pour

IBM.Application lors d’une surcharge système, la commande aura

probablement besoin d’un délai d’exécution supérieur à la valeur définie

autorisée pour cette ressource. Si le temps d’unité centrale est accru, il n’y aura

aucun problème. La commande de contrôle pourra s’achever et faire état d’un

nouvel état opérationnel valide. Vérifiez le journal système afin de savoir si la

commande a été supprimée en raison de l’expiration du délai d’exécution. Si

des commandes ont été supprimées en cours de fonctionnement normal,

vérifiez et ajustez les valeurs de délai d’expiration dans vos définitions de

ressources.

3. Le moniteur doit clairement identifier le processus ou l’application dont il a la

charge. Si le moniteur consulte, par exemple, la table de processus à la

recherche d’un processus particulier, ce dernier doit être identifié de manière

unique. Si le moniteur contrôle un autre processus que celui contrôlé par

l’automatisation, le comportement de la ressource entière sera imprévisible.

4. Si vous essayez d’automatiser des services système de base (spoule

d’impression ou agent de transfert de messagerie, par exemple), veillez à ce

que ces services soient démarrés et arrêtés uniquement par le biais de

l’automatisation et non par le niveau d’exécution du système ou le processus

init.

5. Si vous possédez un moniteur plus sophistiqué pouvant non seulement

déterminer l’existence d’un processus mais également la capacité d’une

application à fournir un service, il n’existe aucun moyen d’en faire part au

moteur d’automatisation et de déclencher l’arrêt ou la fermeture de

l’application. Si le moniteur découvre que le processus ou l’application est

disponible mais suspendu ou en attente, le moniteur supprimera lui-même ce

processus/cette application. L’automatisation reconnaîtra l’application comme

n’étant plus disponible (au cours du prochain contrôle) et tentera de la

redémarrer à partir de son emplacement ou de la déplacer dans un autre

noeud.

6. Si vous tentez de supprimer une ressource en ligne de la classe

IBM.Application (par ex., à l’aide de la commande rmrsrc), la commande sera

rejetée. Vous pouvez forcer la suppression en définissant la force sur Force=1.

Par exemple, pour supprimer une ressource appelée ’Webserver’, entrez :

rmrsrc -s "Name==’WebServer’ && ResourceType==1" IBM.Application Force=1

7. La limite logicielle du nombre maximal de fichiers ouverts est de 1024. La

limite matérielle étant à son maximum, la limite logicielle peut être ajustée si

nécessaire dans les scripts exécutés comme commandes de démarrage, d’arrêt

ou de contrôle pour une ressource.

Global resource RM


Pour augmenter la limite, ajoutez l’instruction suivante sous l’en-tête des scripts

*Command de la ressource :

# ulimit -S -n <nouvelle-limite-nombre-fichiers-ouverts>

Cette action n’a d’impact que sur les applications nécessitant un nombre

considérable de fichiers ouverts (par exemple, WebSphere Application Server).

Gestion des codes retour des commandes de démarrage, d’arrêt

et de contrôle par le gestionnaire de ressources

Le gestionnaire de ressources traite les codes retour des commandes de démarrage,

d’arrêt et de contrôle comme suit :

Commande de démarrage :

1. Si la commande de démarrage a été capable de démarrer la ressource, elle doit

renvoyer une valeur 0 pour indiquer que la ressource a été démarrée

correctement et doit rester en ligne au cours des prochaines secondes.

2. Si la commande de démarrage n’a pas été capable de démarrer la ressource,

elle doit renvoyer une valeur autre que 0. Cette valeur indique à

l’automatisation de ne pas redémarrer la ressource et de définir l’état

opérationnel de la ressource sur Echec hors ligne. Cet état indique que vous

devez intervenir manuellement pour corriger la ressource. Lorsque la ressource

est capable de démarrer, redéfinissez l’état opérationnel Echec hors ligne à

l’aide de la commande resetrsrc. Notez que lorsqu’une commande de

démarrage échoue, l’automatisation émet une commande d’arrêt afin de

garantir que les restes du démarrage défectueux sont supprimés.

3. Si la commande de démarrage s’achève avec succès et renvoie la valeur 0, mais

que la commande de contrôle de la ressource ne fait état d’aucun passage à

l’état En ligne après un certain temps (en fonction des paramètres de la

configuration de contrôle de l’automatisation), l’automatisation tentera de

redémarrer la ressource. Le nombre total de tentatives de démarrage est défini

par l’attribut RetryCount (consultez la description de la commande lssamctrl

dans le Guide de référence d’IBM Tivoli System Automation for Multiplatforms) et la

valeur par défaut est 3. Si l’état opérationnel de la ressource ne prend pas la

valeur En ligne après la dernière tentative, une commande d’arrêt est exécutée

et la ressource passe à l’état Echec hors ligne.

4. Si la commande de démarrage d’une ressource ne peut être achevée dans les

délais impartis spécifiés dans l’attribut StartCommandTimeout, le gestionnaire

de ressources supprimera la commande de démarrage et considérera le

démarrage comme une commande de démarrage défectueuse, comme décrit au

point 2.

5. Si la commande de démarrage était valide lors de la définition de la ressource

mais a été supprimée ultérieurement ou n’est plus présente (par exemple,

système NFS manquant), la procédure de démarrage sera considérée comme un

échec de la commande de démarrage, comme décrit au point 2.

Commande d’arrêt :

1. Si la commande d’arrêt a été capable d’arrêter la ressource, elle doit renvoyer

une valeur 0 pour indiquer que la ressource a été arrêtée correctement et doit

rester hors ligne au cours des prochaines secondes.

2. Aucun mécanisme ne prend en charge la gestion d’une commande d’arrêt

défectueuse dans IBM Tivoli System Automation for Multiplatforms. La

commande d’arrêt peut indiquer un arrêt défectueux de l’application en

renvoyant une valeur autre que 0, mais cela ne déclenchera aucune action

d’automatisation.

Global resource RM


Si la ressource n’atteint pas l’état opérationnel Hors ligne après un certain

temps, IBM Tivoli System Automation for Multiplatforms exécute une opération

de réinitialisation sur la ressource et la commande d’arrêt est appelée une

seconde fois. Ce second appel de la commande d’arrêt peut être déterminé

dans le script StopCommand en vérifiant la variable d’environnement

SA_RESET, qui a la valeur 1 pour le second appel. Pour cela, la commande

d’arrêt peut être utilisée comme suit :

#/bin/sh



killall -9 lpd

exit $?

else


exit $?

fi

Si vous ne souhaitez une autre exécution de la commande d’arrêt, le script peut

être fermé. Par exemple :

#/bin/sh



exit 0

else


exit $?

fi

Cette fonction de réinitialisation a été introduite à l’occasion de la version 2.2

de IBM Tivoli System Automation for Multiplatforms. Toutefois, il n’est pas

nécessaire de reécrire les scripts de règles existants car ils fonctionnent toujours

de la même manière. Cependant, en évaluant la variable d’environnement

SA_RESET, vous pouvez désormais facilement améliorer le comportement de la

fonction d’arrêt. Si la seconde commande d’arrêt ne parvient pas non plus à

mettre la ressource hors ligne, l’état opérationnel de la ressource devient Arrêt

en ligne. A ce stade, une intervention de l’utilisateur est requise pour arrêter la

ressource. Une fois que la ressource a été arrêtée et que son état opérationnel

est devenu Hors ligne, IBM Tivoli System Automation for Multiplatforms prend

le contrôle de cette ressource.

3. Si la commande d’arrêt d’une ressource ne peut être achevée dans les délais

impartis spécifiés dans l’attribut StopCommandTimeout, le gestionnaire de

ressources supprimera la commande et considérera l’arrêt comme une

commande d’arrêt défectueuse, comme décrit au point 2, à la page 243.

4. Si un code retour différent de zéro est renvoyé par une commande d’arrêt ou

une opération de réinitialisation, la ressource passe à l’état d’automatisation

Problème. Pour rétablir la situation, la seule solution consiste à exécuter la

commande resetrsrc sur cette ressource. Comme l’exécution de la commande

resetrsrc sur une ressource déclenche la commande d’arrêt sur la ressource en

question, il est nécessaire que l’exécution de la commande d’arrêt se déroule

correctement (le code retour renvoyé doit être zéro). En règle générale, il est

recommandé de configurer la commande d’arrêt d’une ressource de telle sorte

qu’un code retour différent de zéro soit renvoyé uniquement lorsque l’arrêt de

la ressource pose un réel problème. Dans toutes les autres situations, la

commande d’arrêt doit être configurée de manière à renvoyer le code retour

zéro pour éviter que la ressource ne se retrouve à l’état Problème.

5. Si la commande stop était valide lors de la définition de la ressource mais a été

supprimée ultérieurement ou n’est plus présente (par exemple, système NFS

manquant), la procédure d’arrêt sera considérée comme un échec de la

commande d’arrêt, comme décrit au point 2, à la page 243.

Global resource RM


Commande de contrôle :

1. Si la commande de contrôle a été capable de déterminer l’état opérationnel de

la ressource, elle doit renvoyer l’un des états opérationnels RMS valides (voir

page 241). Gardez à l’esprit que si la valeur 0 est renvoyée, il ne s’agit pas de

l’état opérationnel RMC En ligne, mais de la valeur de retour pour l’état

opérationnel Inconnu, qui est l’état le plus critique de l’automatisation. Une

ressource avec l’état opérationnel Inconnu ne sera plus automatisée et peut

également affecter d’autres ressources possédant des dépendances avec cette

ressource.

2. Si la commande de contrôle d’une ressource ne peut s’achever dans les délais

impartis spécifiés dans l’attribut MonitorCommandTimeout, le gestionnaire de

ressources supprimera la commande de contrôle et définira l’état opérationnel

RMC sur Inconnu, qui indique un problème majeur avec la ressource. Il n’y

aura pas d’automatisation de cette ressource jusqu’à ce que la commande de

contrôle renvoie un état opérationnel autre qu’Inconnu.

3. Si la commande de contrôle était valide lors de la définition de la ressource,

mais a été supprimée ultérieurement ou n’est plus présente (par exemple,

système NFS manquant), l’état opérationnel sera défini sur Inconnu indiquant

un problème majeur avec la ressource.

4. Dans les deux cas, la commande de contrôle peut continuer à faire état d’états

opérationnels RMC valides lorsque la charge système a diminué ou que le

système NFS est de nouveau présent, et l’automatisation continuera à

automatiser la ressource.

5. Lors de l’exécution de la commande de démarrage d’une ressource, l’état

opérationnel de la ressource est toujours En attente en ligne, quel que soit le

véritable état opérationnel renvoyé par une commande de contrôle, pour

indiquer que la ressource est en fait en cours de démarrage. Il existe deux

exceptions : si la commande de contrôle renvoie l’état En ligne ou Echec hors

ligne (car ces valeurs d’état opérationnel indiquent que la ressource est déjà en

ligne ou endommagée) et qu’elle ne peut pas être démarrée.

6. Lors de l’exécution de la commande d’arrêt d’une ressource, l’état opérationnel

de la ressource est toujours En attente hors ligne, quel que soit le véritable état

opérationnel renvoyé par une commande de contrôle, pour indiquer que la

ressource est en fait en cours d’arrêt. Il existe trois exceptions : si la commande

de contrôle renvoie Hors ligne, Echec hors ligne ou Arrêt en ligne (car ces

valeurs d’état opérationnel indiquent que la ressource est déjà hors ligne ou

arrêtée) et qu’elle ne peut pas être arrêtée.

Création de processus à partir de Global Resource Manager

(gestionnaire de ressources globales) pour les commandes de

démarrage, d’arrêt et de contrôle des ressources IBM.Application

Le premier processus dans le noyau UNIX/Linux est le processus init qui crée et

démarre (génère) le contrôleur des ressources système (src) Comme illustré dans la

figure suivante, le contrôleur des ressources système est responsable des

gestionnaires de ressources de System Automation for Multiplatforms.

Le Gestionnaire de ressources globales traite des processus supplémentaires pour

exécuter les commandes de démarrage/d’arrêt et de contrôle d’une ressource

Init-+-atd

|

|-srcmstr

| |

| |-IBM.GblResRMd---IBM.GblResRMd---13*[Ibm.GblResRMd]

Global resource RM


IBM.Application. Toutes les commandes créées par le Gestionnaire de ressources

globales s’exécutent dans le shell de l’utilisateur spécifié. Voici un exemple de

pseudo-code pour cette fonctionnalité :

{

fork;

if child

switch to specified user ID;

run the users default shell and execute the command e.g.

bash -c /usr/bin/mycommand;

endif

}

La commande (mycommand dans l’exemple de code ci-dessus) peut correspondre à

n’importe quel exécutable, y compris à des scripts de shell susceptibles de créer

d’autres processus ou d’utiliser un contrôle de travaux.

Voici des exemples de divers scénarios possibles :

1. IBM.Application est défini en mode commande asynchrone :

StartCommand="/usr/bin/mycommand"

RunCommandsSync=0

Dans ce cas, le gestionnaire de ressources globales crée (génère) un processus

pour la commande puis se détache complètement du nouveau processus et

ferme tous les descripteurs de fichier du nouveau processus.

Le gestionnaire de ressources globales ne prend plus en charge le nouveau

processus et, théoriquement, la commande peut toujours être exécutée.

Etant donné que le nouveau processus n’a plus de parent, il devient orphelin et

il est adopté par le processus init. Lorsque finalement le processus s’arrête, init

récupère le code retour du processus.

2. IBM.Application est défini en mode commande synchrone :

StartCommand="/usr/bin/mycommand"

RunCommandsSync=1

Dans la cas présent, le Gestionnaire de ressources globales ne se détache pas du

processus récemment créé (généré). Les descripteurs de fichier sont ouverts et

le gestionnaire de ressources attend que la commande ait terminé de s’exécuter.

v Si la commande renvoie un mauvais code retour, les messages stderr sont

capturés et écrits dans le fichier de trace du Gestionnaire de ressources

globales et dans le bloc erreur de la commande de démarrage/d’arrêt.

v Si la commande ne répond pas au cours du délai d’attente spécifié par

l’attribut StartCommandTimeout, le Gestionnaire de ressources globales

envoie la commande SIGKILL au processus généré (shell utilisateur par

défaut). SIGKILL est propagé dans tous les processus enfant du shell

utilisateur et par conséquent, tous les processus enfant s’arrêteront.3. IBM.Application est défini en mode commande synchrone, mais utilise un

contrôle de travail du shell utilisateur :

StartCommand="/usr/bin/mycommand &"

RunCommandsSync=1

Dans cette configuration, le shell utilisateur par défaut ne peut pas être arrêté

tant que tous les processus enfant ayant des descripteurs de fichiers ouverts

dans le shell n’ont pas eux-mêmes été arrêtés. Dans notre exemple, le délai

spécifié par l’attribut StartCommandTimeout s’applique également à la

commande mycommand, même si celle-ci est exécutée en arrière-plan du shell

utilisateur. Par conséquent, si l’exécution de la commande mycommand dure plus

longtemps que le délai défini par l’attribut StartCommandTimeout, le

Global resource RM


gestionnaire de ressources globales envoie la commande SIGKILL au shell

utilisateur et propage cette commande sur l’ensemble des processus

d’arrière-plan.

Si vous souhaitez que cette configuration fonctionne, vous devez vous assurer

que tous les descripteurs de fichier du processus enfant de l’interpréteur de

commandes soient détachés de l’interpréteur de commandes. Le résultat peut

ressembler à :

StartCommand="/usr/bin/mycommand > /dev/null 2>&1 &"

RunCommandsSync=1

Le shell utilisateur peut désormais se terminer juste après avoir créé (généré) le

processus pour la commande et se soit détaché des descripteurs de fichier du

nouveau processus. La commande (mycommand) se comporte de la même

manière que dans le premier scénario : elle devient orpheline et est adoptée par

le processus init.

Exemple : Implémentation du spoule d’impression lpd en tant

que ressource IBM.Application

L’exemple suivant indique comment préparer le spoule d’impression lpd sur un

système Linux SUSe géré par System Automation for Multiplatforms.

1. Supprimez le lpd du niveau d’exécution par défaut du système. Si vous

souhaitez exécuter cette ressource en tant que ressource flottante sur plusieurs

noeuds, vous devez contrôler le niveau d’exécution dans chaque noeud.

2. Pour les commandes de démarrage et d’arrêt d’IBM.Application, utilisez les

scripts init par défaut du démon lp :

StartCommand: /etc/init.d/lp start

StopCommand : /etc/init.d/lp stop

3. Pour la commande de contrôle, utilisez un simple script de shell qui vérifie le

processus lpd dans la table de processus :

File : /root/lpmon

#!/bin/bash

OPSTATE_ONLINE=1

OPSTATE_OFFLINE=2

ps -ax | grep -v "grep" | grep "/usr/sbin/lpd" > /dev/null

if [ $? == 0 ]

then

exit $OPSTATE_ONLINE

else

exit $OPSTATE_OFFLINE

fi

De même, vous pouvez utiliser la commande pidmon de System Automation

for Multiplatforms. Il parcourt la table de processus à la recherche d’une chaîne

de commande donnée. Si la chaîne de commande a été trouvée, l’état

opérationnel RMC est renvoyé. Pour obtenir une description détaillée de cette

commande, consultez le Guide de référence d’IBM Tivoli System Automation for

Multiplatforms.

MonitorCommand: /root/lpmon

ou

MonitorCommand: /usr/sbin/rsct/bin/pidmon ’/usr/sbin/lpd’

4. S’il s’agit d’une ressource flottante, veillez à ce que tous les noeuds puissent

accéder aux commandes de démarrage/d’arrêt et de contrôle par le même

chemin d’accès. Comme le lpd est une application simple et de petite taille, les

valeurs par défaut des attributs Start-/Stop- et MonitorCommandTimout (la

Global resource RM


valeur par défaut est de 5 secondes) peuvent être utilisées Afin de démarrer

lpd, les scripts init fournissent la racine en tant que nom d’utilisateur

d’IBM.Application.

La ressource IBM.Application peut désormais être définie à l’aide de la commande

mkrsrc :

# mkrsrc IBM.Application \

Name = "line_printer_daemon" \

ResourceType = 1 \

StartCommand = "/etc/init.d/lpd start" \

StopCommand = "/etc/init.d/lpd stop" \

MonitorCommand = "/usr/sbin/rsct/bin/pidmon ’/usr/sbin/lpd’ " \

MonitorCommandPeriod = 15 \

MonitorCommandTimeout = 5 \

StartCommandTimeout = 5 \

StopCommandTimeout = 5 \

UserName = "root" \

RunCommandsSync = 1 \

ProtectionMode = 0 \

NodeNameList = "{’node01’,’node02’}"

Cette commande crée trois ressources : une ressource d’agrégat appelée

″line_printer_daemon″ qui peut être mise en ligne dans les noeuds ″node01″ et

″node02″ ainsi que deux ressources constituantes également appelées

″line_printer_daemon″, l’une dans le noeud ″node01″ et l’autre dans le noeud

″node02″. Si une requête de démarrage est émise pour la ressource d’agrégat, le

Gestionnaire de ressources globales choisit un constituant et le démarre à l’aide du

script (ou la commande) spécifié avec l’attribut StartCommand.

Configuration d’une ressource de support pour une ressource

IBM.Application

Si vous utilisez une ressource IBM.Application en association avec des relations

IBM.Equivalency et Dépendant de, l’automatisation choisira une ressource dans

l’équivalence et mettra cette ressource à disposition en tant que ressource de

support pour IBM.Application.

Application A1

Inxcm1

Application B

Inxcm1, Inxcm2, Inxcm3

Application A2

Inxcm1

Application A3

Inxcm2

Application A4

Inxcm3

Figure 18. Configuration d’une ressource de support pour une ressource IBM.Application

Global resource RM


Dans cet exemple de configuration, l’automatisation extrait une application Ax à

partir d’une équivalence et veille à ce que l’application B dépende de cette

application (voir les chapitres Chapitre 5, «Utilisation des équivalences», à la page

53 et Chapitre 6, «Utilisation des relations gérées», à la page 59). Etant donné que

la plupart des ressources à partir de l’équivalence peuvent remplir les contraintes

d’emplacement de la relation Dépendant de (dans cet exemple, A1 et A2 peuvent

s’exécuter sur lnxcm1), l’automatisation informera de la ressource sélectionnée

pour la commande de démarrage de la ressource B.

Si nécessaire, le script de démarrage de la ressource B peut utiliser cette

information pour transmettre des paramètres spéciaux à cette application ou

activer un code dédié devant être exécuté en association avec la ressource

sélectionnée à partir de l’équivalence.

Pour transmettre cette information à la commande de démarrage, le gestionnaire

de ressources définira les variables d’environnement suivantes dans

l’environnement de commande de démarrage de la ressource :

Variable Valeur

SA_SUPPORTING_RESOURCE_RH Descripteur de ressource de la ressource de

support, comme "0x601d 0xffff 0xcac15160

0xbad91087 0x0f933128 0x58888f98"

SA_SUPPORTING_RESOURCE_NAME Nom de la ressource de support, comme

"A1"

Voici quelques exemples de code qui peuvent illustrer comment le script de

démarrage de la ressource B peut supporter les variables d’environnement de la

ressource de support :

# commande de démarrage pour la ressource B avec logique pour

# ressource de support

...

si [ $SA_SUPPORTING_RESOURCE_NAME = "A1" ]

then

# démarre la ressource B et la connecte à la ressource de support

# ressource A1

...

fi

si [ $SA_SUPPORTING_RESOURCE_NAME = "A2" ]

# démarre la ressource B et la connecte à la ressource de support

# ressource A2

...

then

fi

Qu’est-ce qu’une classe de ressources IBM.ServiceIP ?

La classe de ressources IBM.ServiceIP est utilisée pour la gestion des adresses IP

pouvant être démarrées, arrêtées ou déplacées entre des adaptateurs et des noeuds

d’un domaine homologue. Chaque ressource de cette classe identifie une adresse

IP. Ces adresses IP sont généralement fournies aux clients qui se connectent à un

service quelconque s’exécutant dans le domaine. Une application de gestion de

reprise sur incident peut être utilisée pour maintenir le service ainsi que l’adresse

IP associée actifs, mais si des incidents ont lieu au sein du domaine.

Une adresse IP de service est une ressource d’agrégat possédant une ressource

constituante sur chaque noeud dans lequel l’administrateur souhaite autoriser la

Global resource RM


mise en ligne éventuelle de la ressource. Il s’agit d’une ressource flottante car elle

ne peut posséder qu’un seul constituant actif à la fois.

La classe de ressources IBM.ServiceIP utilise les paramètres de base suivants :

1. Le nom de la ressource.

2. Les noeuds sur lesquels la ressource peut être exécutée.

3. L’adresse IP pouvant être déplacée.

4. Le masque de réseau de l’adresse IP.

L’adresse de broadcast et l’indicateur de l’interface réseau seront prélevés dans

l’interface parent à laquelle la ressource ServiceIP est associée au cours du

démarrage.

Gardez à l’esprit qu’IBM.ServiceIP générera une entrée de routage statique pour le

réseau dans lequel IBM.ServiceIP est actif. Veillez à ce que ce réseau/cette route ne

détruise pas la configuration réseau de l’unité à laquelle ServiceIP est associé.

Aussi, l’automatisation ne tient pas compte du routage dynamique. Si vous

spécifiez une adresse ServiceIP qui ne se trouve pas dans le sous-réseau de

l’interface réseau parent, l’unité physique hébergera deux réseaux différents. Veillez

à définir correctement le routage en dehors de la grappe d’automatisation afin de

prendre en charge le réseau.

Caractéristiques d’IBM.ServiceIP

La classe IBM.Service IP possèdent deux caractéristiques différentes :

1. IBM.ServiceIP sélectionne automatiquement une interface réseau adaptée

Si IBM.ServiceIP reçoit une requête de démarrage, le gestionnaire de ressources

tente de choisir une interface réseau adaptée. S’il en trouve une, l’IP de service

sera associée à cette interface. Cette interface se nomme ″ressource de support″

ou ″interface réseau de support″.

Afin de déterminer l’interface réseau adaptée, le gestionnaire de ressources

compare l’attribut IPAddress de la ressource IBM.ServiceIP à l’adresse IP de

toutes les interfaces réseau existantes. S’il existe une interface réseau adaptée

(sous-réseau), le gestionnaire de ressources affecte l’adresse pseudonyme à cette

interface réseau. Si aucun sous-réseau correspondant n’est trouvé, la requête de

mise en ligne échoue.

La sélection d’un algorithme d’automatisation par une interface automatique

n’aboutira pas à l’évaluation de l’état actuel de l’interface réseau. Aussi

longtemps que l’interface réseau est configurée et fonctionne, l’IP de service

(ServiceIP) peut être attribuée à l’interface réseau. Gardez à l’esprit que

UNIX/Linux ne modifie pas l’état d’une interface réseau, par exemple, si le

câble réseau est débranché. Même si le pilote de périphérique est capable de

détecter le câble manquant, l’interface restera configurée et fonctionnelle.

Si vous souhaitez exploiter le mécanisme de signal de présence RSCT afin de

détecter un incident d’interface réseau tel qu’un câble manquant, utilisez la

configuration de la ressource de support d’IBM.ServiceIP décrite dans la section

suivante.

Exemple

Une adresse IBM.ServiceIP est définie comme suit :


NetMask="255.255.255.0"

NodeNameList="{’node01’,’node02’}"

Global resource RM


Les interfaces réseau suivantes sont disponibles dans la grappe :

1. IPAddress=192.168.1.1

Netmask=255.255.255.0

NodeNameList="{’node01’}"

2. IPAddress=9.152.172.91

Netmask=255.255.255.0


3. IPAddress=192.168.2.1

Netmask=255.255.255.0


Seule l’interface numéro 1 est capable de mettre en attente l’IP de service.

Toutes les autres interfaces ne correspondent pas à l’adresse (au sous-réseau) de

l’IP de service. Les appels de démarrage IBM.ServiceIP sur d’autres noeuds que

le noeud node01 échoueront, car il n’existe aucune interface réseau de support

adaptée.

2. IBM.ServiceIP reçoit une ressource de support à associer à l’adresse IP de

service

Dans ce cas, il n’y a aucune limite pour les attributs IPAddress et NetMask de

la ressource IBM.ServiceIP. L’IP de service doit posséder une relation

’dépendant de’ (DependsOn) (voir «Relation Dépendant de», à la page 70) avec

une équivalence des interfaces réseau (voir Chapitre 5, «Utilisation des

équivalences», à la page 53 relatif aux ressources de support). Si System

Automation for Multiplatforms décide de mettre une ressource d’IP de service

en ligne sur un noeud donné, il extrait une interface réseau adaptée de

l’équivalence des interfaces réseau et la soumet à IBM.ServiceIP comme

ressource de support. Il s’agit de l’interface qui héberge l’alias.

Dans cette configuration, l’automatisation est capable de contrôler l’état

opérationnel de l’interface réseau à laquelle l’adresse IP de service est associée.

Si un incident d’interface est détecté par le signal de présence RSCT,

l’automatisation diminuera une chaîne de dépendance et arrêtera l’adresse

ServiceIP. Si une autre interface réseau est en ligne dans l’équivalence,

l’automatisation choisit un périphérique auquel affecter l’adresse ServiceIP.

Exemple :

Une adresse IBM.ServiceIP est définie comme suit :


NetMask="255.255.255.0"

NodeNameList="{’node01’,’node02’,’node03’}"

Les interfaces réseau suivantes sont disponibles dans la grappe :

1. IPAddress=192.168.1.1

Netmask=255.255.255.0


2. IPAddress=192.168.1.2

Netmask=255.255.255.0


3. IPAddress=192.168.1.3

Netmask=255.255.255.0


Les trois interfaces réseau forment une équivalence.

Global resource RM


La figure suivante illustre la configuration :

Si System Automation for Multiplatforms décide de démarrer l’IP de service, il

extrait une interface réseau de l’équivalence. Dans cet exemple, l’IP de service peut

flotter entre les noeuds node01, node02 et node03, car les trois noeuds possèdent

une interface réseau dans l’équivalence pouvant agir en tant que ressource de

support.

Attributs utilisés par IBM.ServiceIP

Cette section décrit les attributs utilisés par les ressources de la classe de ressources

IBM.ServiceIP.


mkrsrc, elle doit posséder les attributs suivants :

v Name

v IPAddress


v NodeNameList

v ResourceType

v NetMask

v ProtectionMode

Les ressources de cette classe possèdent l’attribut dynamique suivant :

v OpState

Attribut Name


cette adresse IP de service (par ex., mail-server-ip). La ressource

d’agrégat et la ressource constituante possèdent la même valeur

pour cet attribut.Vous devez spécifier une valeur unique pour cet attribut à la

création d’une nouvelle ressource IBM.ServiceIP.

L’attribut doit être un type de chaîne de caractères.



indiquant les noeuds sur lesquels la ressource IBM.ServiceIP est

disponible.

Global resource RM


Si la ressource est flottante, le Global Resource RM veillera à ce

qu’il existe une ressource constituante (fixe) pour chaque nom de

noeud de la liste. Les ressources constituantes sont créées ou

supprimées de manière implicite en fonction des besoins de

correspondance avec les entrées de la liste. Les ressources

constituantes ne contiendront qu’une seule entrée dans ce tableau,

car il s’agit de ressources fixes qui ne peuvent donc être

disponibles que sur un seul noeud. Pour une ressource flottante,

cet attribut est modifié de manière implicite si une ressource

constituante est supprimée de manière explicite par

l’administrateur afin que la relation entre la ressource d’agrégat et

la ressource constituante soit toujours cohérente.




La liste peut contenir au maximum un nom si la ressource est fixe

(c.-à-d. si ResourceType=0). Si aucun nom n’est attribué à une

ressource fixe, le RMC fournira un nom par défaut car la ressource

fixe est liée à un noeud et ne peut par conséquent être créée sans

nom de noeud ou sans ID de noeud.

Pour les ressources d’agrégat, la valeur de cet attribut peut être

modifiée à l’aide de la commande chrsrc. Toute tentative de

modification de cet attribut pour une ressource constituante

générera une erreur.


Utilisez l’attribut persistant ResourceType pour identifier s’il s’agit

d’une ressource fixe ou flottante. Une valeur entière 0 indique que

la ressource est fixe, un valeur 1 indique qu’il s’agit d’une

ressource flottante. Cet attribut est défini par défaut sur flottant s’il

n’est pas spécifié à la création d’une nouvelle ressource

IBM.ServiceIP.

Attribut IPAddress

A l’aide de l’attribut persistant IpAddress, vous pouvez spécifier

l’adresse IP qui sera associée à une interface réseau sur laquelle la

ressource est mise en ligne. Cet attribut est obligatoire lorsque vous

créez une nouvelle ressource IBM.ServiceIP. L’adresse IP doit être

communiquée à l’aide de la notation ‘décimale avec point’ en tant

que chaîne de caractères, par ex., 9.152.80.251.

Attribut NetMask

Utilisez l’attribut persistant NetMask afin de spécifier le masque de

réseau qui sera affecté à l’adresse IP définie dans l’attribut de

l’adresse IP. L’attribut doit être communiqué en tant que chaîne de

caractères, par ex., 255.255.255.0.


L’attribut persistant ProtectionMode indique si la ressource est

vitale ou non. S’il s’agit d’une ressource vitale, IBM.ConfigRM

décide si la ressource peut être démarrée comme demandé. (Pour

des informations supplémentaires sur ce comportement, consultez

le Chapitre 9, «Protection de vos ressources – support réalisé par

Quorum», à la page 167.

L’attribut peut posséder les valeurs d’entier 0 (non vitale) ou 1

(vitale). La valeur par défaut est ″Vitale″.

Global resource RM


Attribut OpState


opérationnel de la ressource déterminé par le gestionnaire de

ressources. Les valeurs typiques pour cet état sont En ligne

(valeur 1) et Hors ligne (valeur 2) ce qui signifie que l’adresse IP

est opérationnelle ou pas.

Que se passe-t-il lorsqu’une adresse IBM.ServiceIP est

démarrée ?

Si le gestionnaire de ressources peut attribuer une adresse IP sur l’interface de

réseau sélectionnée, les fonctions suivantes seront transmises :

1. Sous Linux sur System z avec le matériel de réseau OSA, une autre adresse IP

sera initialisée pour l’adresse IP spécifiée.

2. L’adresse ServiceIP est créée en tant qu’alias IP sur le périphérique réseau

sélectionné.

3. Pour rendre invalide les entrées de la table ARP (Protocole de résolution

d’adresse) d’un autre hôte IP qui peut avoir l’adresse du ServiceIP avec une

fausse adresse matérielle (adresse MAC) dans leur mémoire cache, un paquet

ARP gratuit/non demandé est diffusé sur le réseau.

4. Un message de journal système est créé pour enregistrer le fait qu’une adresse

ServiceIP est démarrée sur l’interface réseau spécifiée.

Notez également que

v un alias d’adresse IP peut générer une nouvelle entrée dans la table de routage

du système de l’hôte (au cas où l’adresse ServiceIP est différent de celle de

l’adresse réseau du périphérique).

v L’adresse IBM.ServiceIP ne modifiera pas vos paramètres de passerelle par

défaut ou tout autre configuration réseau/routage.

Exemple 1 : Définition d’une adresse IP en tant que ressource

IBM.ServiceIP

Afin de définir une adresse IP possédant l’IP d’adresse 9.152.172.11, le masque de

réseau 255.255.255.0 et pouvant éventuellement fonctionner sur les noeuds node05

et node06, exécutez la commande suivante :

mkrsrc IBM.ServiceIP

Name="WebServerIP"



NetMask=255.255.255.0

Exemple 2 : Définition d’une adresse IP en tant que ressource

IBM.ServiceIP et utilisation d’une IBM.Equivalency d’interfaces

réseau

Comme indiqué dans l’exemple précédent, définissez une adresse IP possédant l’IP

d’adresse 9.152.172.11, le masque de réseau 255.255.255.0 et pouvant

éventuellement fonctionner sur les noeuds node05 et node06 :

mkrsrc IBM.ServiceIP

Name="WebServerIP"



NetMask=255.255.255.0

Les noeuds node05 et node06 possèdent chacun plus d’une interface réseau. Pour

créer une équivalence contenant le périphérique eth1 des noeuds node05 et

node06, entrez :

mkequ MyInterfaces IBM.NetworkInterface:eth1:node05,eth1:node06

Global resource RM


Vous pouvez désormais vous connecter à l’IP de service ServiceIP avec

l’équivalence :

mkrel -p dependson -S IBM.ServiceIP:WebServerIP -G IBM.Equivalency:MyInterfaces

WebIp_depon_MyInterfaces

Global resource RM


Utilisation du Test Resource Manager

Cette section décrit les caractéristiques du gestionnaire de ressources Test resource

manager.

L’IBM Test resource manager (IBM.TestRM) gère les ressources de test et offre des

fonctions permettant de manipuler l’état opérationnel de ces ressources. Le

gestionnaire de ressources est opérationnel en mode de domaine homologue

uniquement et fournit la classe de ressources IBM.Test. IBM.TestRM ne contrôle pas

les ressources réelles.

Qu’est-ce que la classe de ressources IBM.Test ?

La classe de ressources IBM.Test permet la création, la gestion et le contrôle de

nouveaux types de ressources fixes et flottantes via le sous-réseau RMC. Il ne s’agit

pas véritablement de ressources, mais simplement de conteneurs permettant de les

définir, les surveiller et les contrôler. Ces ressources peuvent être automatisées ou

récupérées par System Automation for Multiplatforms. La classe IBM.Test a pour

but de fournir une ressource légère et simple d’utilisation permettant de simuler

les scénarios d’automatisation sans pour autant nécessiter un temps système

important. Chaque ressource contrôlée par la classe IBM.Test est considérée comme

une ressource générique qui comprend une ressource d’agrégat et une ressource

constituante dans chaque noeud où la ressource est définie. Voir figure 17, à la

page 234 pour obtenir des informations supplémentaires.

La classe de ressources IBM.Test offre un ensemble d’attributs de ressources

persistantes permettant de simuler le comportement de ressources réelles.

Attributs utilisés par IBM.Test

Cette section décrit les attributs persistants utilisés par la classe de ressources

IBM.Test.


mkrsrc, elle doit posséder l’attribut persistant suivant :

v Name


v NodeNameList

v ResourceType

v ForceOpState

v TimeToStart

v TimeToStop

v WriteToSyslog

v MoveTime

v MoveFail

Les ressources de cette classe possèdent les attributs dynamiques suivants :

v OpState

v MoveState

v OpQuorumState

Test resource manager


Attribut Name


la ressource de test. La ressource d’agrégat et la ressource

constituante possèdent la même valeur pour cet attribut.Vous devez spécifier une valeur unique pour cet attribut à la

création d’une nouvelle ressource IBM.Test.



indiquant les noeuds dans lesquels la ressource IBM.Test est

disponible.

Si la ressource est flottante, le TestRM veillera à ce qu’il existe une

ressource constituante (fixe) pour chaque nom de noeud de la liste.

Les ressources constituantes sont créées ou supprimées de manière

implicite en fonction des besoins de correspondance avec les

entrées de la liste. Les ressources constituantes ne contiendront

qu’une seule entrée dans ce tableau, car il s’agit de ressources fixes

qui ne peuvent donc être disponibles que sur un seul noeud. Pour

une ressource flottante, cet attribut est modifié de manière implicite

si une ressource constituante est supprimée de manière explicite

par l’administrateur afin que la relation entre la ressource d’agrégat

et la ressource constituante soit toujours cohérente.





Utilisez l’attribut persistant ResourceType pour identifier s’il s’agit

d’une ressource fixe ou flottante. Une valeur entière 0 indique que

la ressource est fixe, un valeur 1 indique qu’il s’agit d’une

ressource flottante. Cet attribut est défini par défaut sur fixe s’il

n’est pas spécifié à la création d’une nouvelle ressource IBM.Test.

Attribut ForceOpState

Utilisez cet attribut afin d’initier une modification de l’état

opérationnel (OpState) de la ressource de test via la commande

RMC chrsrc. Il peut être utilisé pour simuler un incident dans la

ressource. La dernière modification d’état est sauvegardée dans cet

attribut de ressource persistant. La spécification de cet attribut lors

de la création de la ressource n’a aucun effet. En règle générale, les

modifications du ForceOpState doivent être effectuées dans les

ressources constituantes, lorsque la ressource d’agrégat rassemble

l’état opérationnel (OpState) de toutes les ressources. Les valeurs

autorisées pour cet attribut sont :










TimeToStart Lorsqu’une ressource de test reçoit la commande de démarrage,

l’attribut TimeToStart indique le délai (en secondes) dont aura

besoin une ressource pour changer d’état opérationnel de ″En

attente en ligne ″ à ″En ligne″. La valeur par défaut est de 0

seconde ; la ressource est mise directement en ligne.

TimeToStop Lorsqu’une ressource de test reçoit la commande d’arrêt, l’attribut

TimeToStop indique le délai (en secondes) dont aura besoin une

ressource pour changer d’état opérationnel de ″En attente hors

ligne ″ à ″Hors ligne″. La valeur par défaut est de 0 seconde ; la

ressource est mise directement hors ligne.

WriteToSyslog Une ressource de la classe IBM.Test peut consigner les événements

de mise en ligne ou hors ligne et les événements ForceOpState

dans la fonction syslog. Utilisez l’attribut WriteToSyslog pour

activer/désactiver l’écriture dans le démon système. Les valeurs

autorisées pour cet attribut sont :

0 Ne pas écrire dans le démon système (il s’agit de la valeur

par défaut)

1 Ecrire dans le démon système

Attribut OpState


opérationnel de la ressource. L’état opérationnel de la ressource

IBM.Test suit les commandes de démarrage et d’arrêt RMC ou

l’événement ForceOpState à partir d’un opérateur ou d’un script de

test (jeu d’essai automatisé). Les valeurs possibles de cet attribut

telles que définies dans le diagramme de transition d’état de

l’architecture RMC sont :








MoveTime Réservé pour une utilisation interne.

MoveFail Réservé pour une utilisation interne.

MoveState Réservé pour une utilisation interne.

OpQuorumState

Réservé pour une utilisation interne.



Exemple : Création d’une ressource de test et manipulation

de son état opérationnel (OpState)

Afin de créer une ressource IBM.Test dans deux noeuds, exécutez la commande

RMC suivante :

mkrsrsc IBM.Test \

Name="mytest" \

NodeNameList="{’node01’,’node02’}" \

ResourceType=1 \

TimeToStart=5 \

TimeToStop=2 \

WriteToSyslog=1

La commande suivante provoque la modification de l’état opérationnel d’un

constituant situé sur le noeud node02 à Echec hors ligne. Si la ressource est

automatisée par System Automation for Multiplatforms, le gestionnaire

d’automatisation démarre la ressource sur un autre noeud.

chrsrc -s "Name=’myTest’ && NodeNameList={’node02’}" IBM.Test ForceOpState=3



Chapitre 12. Automatisation des ressources du gestionnaire

de ressources de stockage RSCT

IBM Tivoli System Automation for Multiplatforms utilise la fonction de

gestionnaire de ressources de stockage (StorageRM) fournie par RSCT, qui permet

d’automatiser les ressources du système de fichiers de la classe IBM.AgFileSystem.

L’étendue de la prise en charge proposée par IBM Tivoli System Automation for

Multiplatforms pour l’automatisation de ces ressources varie en fonction d’un

certain nombre de facteurs, tels que le type d’unité de stockage sur laquelle le

système de fichiers réside, le système d’exploitation du noeud auquel l’unité de

stockage est associée, et si des entités de stockage sont collectées ou définies par

l’utilisateur :

v L’étendue de la prise en charge spécifique à la plateforme est décrite dans

«Unités de stockage prises en charge».

v Pour automatiser les ressources IBM.AgFileSystem qui sont collectées

automatiquement, aucune autre configuration supplémentaire n’est requise. Pour

automatiser les systèmes de fichiers qui ne sont pas collectés automatiquement,

vous devez utiliser des ressources IBM.AgFileSystem définies par l’utilisateur.

Les sections suivantes décrivent les étapes que vous devez suivre pour définir et

automatiser ces ressources :

– «Création de ressources IBM.AgFileSystem définies par l’utilisateur», à la

page 266

– «Automatisation des ressources IBM.AgFileSystem définies par l’utilisateur

dans un environnement LVM», à la page 266

Pour plus d’informations sur le gestionnaire de ressources de stockage, consultez

les sections suivantes du Chapitre 6 - "Understanding and administering the

storage resource manager" du manuel RSCT Administration Guide :

v Configuring file system mounting on IBM.AgFileSystem resources

v Storage resource manager prerequisites

Unités de stockage prises en charge

System Automation for Multiplatforms sous Solaris prend en charge les unités de

stockage de la manière suivante :

v Seules les ressources IBM.AgFileSystem définies par l’utilisateur sont prises en

charge. Ces ressources peuvent être montées et démontées en mettant les

ressources en ligne ou hors ligne respectivement.

v Tous les types de systèmes de fichiers Solaris (UFS et ZFS, par exemple) sont

pris en charge.

v Les entités de stockage des classes IBM.VolumeGroup, IBM.Partition, IBM.Disk

et IBM.LogicalVolume ne sont pas prises en charge.

v La collecte automatique des ressources IBM.AgFileSystem n’est pas prise en

charge.

v Pour plus d’informations sur la prise en charge du système de fichiers NFS sous

Solaris, voir «Prise en charge des systèmes NFS», à la page 265.

Pour plus d’informations sur la prise en charge des unités de stockage sous

Windows, voir «Composants non disponibles pour System Automation for

Multiplatforms sous Windows», à la page 282.


Les sections suivantes présentent, pour chaque plateforme, l’étendue de la prise en

charge disponible pour l’automatisation des ressources IBM.AgFileSystem sous AIX

et Linux.

Prise en charge de l’automatisation pour les unités de

stockage à un accès ou à accès multiple de la famille IBM

TotalStorage DS4000

AIX

Une prise en charge complète est disponible pour les unités de stockage SPIO et

MPIO :

v Les ressources IBM.AgFileSystem collectées peuvent être automatisées.

Les ressources IBM.AgFileSystem sont collectées si elles sont de type jfs ou jfs2

et résident sur des entités de stockage elles-mêmes collectées (entités de stockage

de la classe IBM.LogicalVolume, IBM.VolumeGroup, IBM.Disk).

v Les ressources IBM.AgFileSystem définies par l’utilisateur peuvent être

automatisées (par exemple, les systèmes de fichiers NFS).

v La réservation SCSI-2 est prise en charge pour les unités de stockage SPIO et

MPIO qui utilisent le pilote RDAC (Redundant Disk Array Controller).

Limitations :

v Pas de segmentation des données


automatisées si le disque hébergeant le système de fichiers possède le même

nom sur tous les noeuds de la grappe.

Linux sur POWER et Linux sur System x

Une prise en charge complète est assurée pour les unités de stockage SPIO

(entrée-sortie à un accès) et pour les unités de stockage MPIO (entrée-sortie

multi-accès) équipées de pilote d’unité RDAC (Redundant Disk Array Controller) :


Les ressources IBM.AgFileSystem sont collectées si elles sont du type ext2, ext3

ou reiserfs et résident sur des entités de stockage elles-mêmes collectées (entités

de stockage de la classe IBM.LogicalVolume, IBM.Partition, IBM.VolumeGroup,

IBM.Disk).



v La réservation SCSI-2 est prise en charge pour les disques collectés depuis le

pilote RDAC.

v Linux RAID (unités /dev/md) est pris en charge.

Limitations :

v Les systèmes de fichiers créés sur des unités md sans LVM ne sont pas collectés,

ils ne peuvent être automatisés qu’à l’aide des ressources IBM.AgFileSystem

définies par l’utilisateur.

v Les unités md elles-mêmes sont uniquement collectées en tant que ressources

IBM.Disk si un volume physique a été créé sur l’unité md à l’aide de la

commande pvcreate.

v La réservation SCSI-2 n’est pas prise en charge pour les pilotes non RDAC ou

pour les unités md elles-mêmes.





v EVMS n’est pas pris en charge, y compris tous les groupes de volumes et les

volumes logiques créés ou gérés par EVMS.

v Pour SLES 10 et RHEL 5, la collecte des entités de stockage de classes IBM.Disk,

IBM.VolumeGroup, IBM.LogicalVolume et IBM.AgFileSystem ainsi

qu’IBM.Partition est prise en charge. Les systèmes de fichiers peuvent être

automatisés si les limitations des unités md répertoriées ci-dessus sont

respectées.

Linux sur System z

Les unités md sont collectées en tant que ressources IBM.Disk si un volume

physique a été créé sur l’unité md à l’aide de la commande pvcreate.

Limitations :

v Seules les ressources IBM.AgFileSystems ou IBM.AgFileSystem définies par

l’utilisateur qui résident sur les unités md collectées peuvent être automatisées.

La collecte de ressources des autres disques n’est pas prise en charge. Même si la

collecte sur les autres disques aboutit, les ressources collectées ne peuvent pas

être automatisées.




v La réservation SCSI n’est pas prise en charge.

Prise en charge des unités de stockage à accès unique et

multi-accès sur d’autres familles de système de disque IBM

TotalStorage

AIX

Une prise en charge complète est disponible pour les unités de stockage SPIO et

MPIO :







v La réservation SCSI-2 est prise en charge pour les unités de stockage SPIO et

MPIO qui utilisent le pilote RDAC (Redundant Disk Array Controller).

Limitations :

v Pas de création de copies miroir





Chapitre 12. Automatisation des ressources du gestionnaire de ressources de stockage RSCT 263


Une prise en charge complète est assurée pour les unités de stockage SPIO

(entrée-sortie à un accès) et une prise en charge limitée est assurée pour les unités

de stockage MPIO (entrée-sortie multi-accès) pour les systèmes de disque IBM

TotalStorage.




de stockage de la classe IBM.LogicalVolume, IBM.VolumeGroup, IBM.Disk).



v Linux RAID (unités /dev/md) est pris en charge.

Limitations :


automatisées uniquement si le disque hébergeant le système de fichiers possède

le même nom sur tous les noeuds de la grappe, et si les limitations décrites

ci-dessous concernant les unités md sont respectées.

v La réservation SCSI-2 est prise en charge pour les pilotes RDAC uniquement.

v Les systèmes de fichiers créés sur des unités md sans LVM ne sont pas collectés,

ils ne peuvent être automatisés qu’à l’aide des ressources IBM.AgFileSystem

définies par l’utilisateur.

v Les unités md elles-mêmes sont uniquement collectées en tant que ressources

IBM.Disk si un volume physique a été créé sur l’unité md à l’aide de la

commande pvcreate.

v EVMS n’est pas pris en charge, y compris tous les groupes de volumes et les

volumes logiques créés ou gérés par EVMS.

Linux sur System z



Limitations :










Prise en charge des unités de stockage à accès unique non

DS4000

AIX

Une prise en charge complète est disponible pour les unités de stockage à accès

unique :








v La réservation SCSI-2 est prise en charge.

Limitations :

v Pas de création de copies miroir






Une prise en charge limitée est assurée :




de stockage de la classe IBM.LogicalVolume, IBM.Partition, IBM.VolumeGroup,

IBM.Disk).



Limitations :

v La prise en charge de la réservation SCSI est limitée. Effectuez une opération de

réservation de disque pour vérifier si la réservation SCSI est disponible.




Linux sur System z



Limitations :










Prise en charge des systèmes NFS

Les remarques suivantes concernent Linux sur POWER, Linux sur System x, Linux

sur System z, Solaris et AIX :

Les systèmes de fichiers NFS ne sont pas collectés. Pour automatiser ce type de

systèmes de fichiers, vous devez utiliser des ressources IBM.AgFileSystem définies

par l’utilisateur.


Les systèmes de fichiers NFS de classe IBM.AgFileSystem peuvent uniquement être

automatisés et surveillés si l’utilisateur root du système qui importe dispose d’un

accès en écriture au système de fichiers.

L’utilisation en cascade des systèmes de fichiers n’est pas possible :

IBM Tivoli System Automation for Multiplatforms permet de définir un serveur

NFS à haute disponibilité, dans lequel les systèmes de fichiers exportés sont

automatisés en tant que ressources de classe IBM.AgFileSystem qui résident sur un

support de disque partagé. Le serveur NFS est lui-même automatisé en tant que

ressource de la classe IBM.Application, capable de flotter sur les systèmes ayant

accès au support de disque partagé. Lorsqu’un système supplémentaire importe les

systèmes de fichiers, les systèmes de fichiers importés ne doivent pas déjà résider

en tant que ressources IBM.AgFileSystem définies par l’utilisateur sur le système

qui importe, sans quoi la surveillance des systèmes de fichiers échouera et les

ressources passeront à l’état OpState 3 (ECHEC HORS LIGNE).

Création de ressources IBM.AgFileSystem définies par l’utilisateur

Pour automatiser les systèmes de fichiers qui ne sont pas collectés

automatiquement (périphériques NFS, par exemple), utilisez la commande mkrsrc

pour créer les ressources IBM.AgFileSystem correspondantes.

Exemple :

mkrsrc IBM.AgFileSystem Name=<nom> DeviceName=<nom_périphérique>

Vfs=<type_système_fichiers> MountPoint=<point_montage>

NodeNameList={<liste_de_noms_de_noeuds>}

Automatisation des ressources IBM.AgFileSystem définies par

l’utilisateur dans un environnement LVM

Pour automatiser les systèmes de fichiers qui résident sur des volumes logiques et

qui ne sont pas collectés automatiquement, définissez les dépendances existant

entre les systèmes de fichiers, les volumes logiques et les groupes de volumes à

l’aide d’IBM Tivoli System Automation for Multiplatforms. Vous devez pour cela

effectuer les opérations suivantes :

1. Définissez une ressource de classe IBM.Application destinée à représenter le

groupe de volumes. Créez des scripts pour les attributs StartCommand,

StopCommand et MonitorCommand de la ressource IBM.Application qui

contiennent les commandes appropriées pour l’activation, la désactivation et

l’indication d’états du groupe de volumes.

2. Définissez une ressource de classe IBM.AgFileSystem destinée à représenter le

système de fichiers.

3. Définissez une relation DependsOn dans laquelle la ressource du système de

fichiers est la source et la ressource de l’application représentant le groupe de

volumes est la cible.

Attributs utilisés par IBM.AgFileSystem

Cette section décrit les attributs persistants utilisés par la classe de ressources

IBM.AgFileSystem. Lorsqu’une ressource de cette classe est créée à l’aide de la

commande RMC mkrsrc, elle doit posséder les attributs persistants suivants :

v Name

v Vfs


v DeviceName

v MountPoint


v NodeNameList

v ResourceType

v ProtectionMode

v PreOnlineMethod

v Force

Les ressources de cette classe possèdent les attributs dynamiques suivants :

v OpState

Caractéristiques des attributs

Attribut Name

L’attribut persistant Name est un nom défini par l’utilisateur pour ce point

de montage (mail-server-data, par exemple). La ressource d’agrégat et la

ressource constituante possèdent la même valeur pour cet attribut. Vous

devez spécifier une valeur unique pour cet attribut lors de la création

d’une nouvelle ressource IBM.AgFileSystem. L’attribut doit être un type de

chaîne de caractères.

Attribut Vfs

L’attribut persistant Vfs permet d’indiquer le type de système de fichiers

représenté par la ressource.

Attribut DeviceName

L’attribut persistant DeviceName permet d’indiquer le nom d’un système

de fichiers existant (par exemple, /dev/fslv03).

Attribut MountPoint

L’attribut persistant MountPoint permet d’indiquer un point de montage

existant.


L’attribut persistant NodeNameList est un tableau de chaînes indiquant les

noeuds sur lesquels la ressource IBM.AgFileSystem est disponible. Si la

ressource est flottante, le gestionnaire de ressources de stockage veillera à

ce qu’une ressource constituante (fixe) existe pour chacun des noms de

noeud figurant dans la liste. Les ressources constituantes sont créées ou

supprimées de manière implicite en fonction des besoins de

correspondance avec les entrées de la liste. Les ressources constituantes ne

contiendront qu’une seule entrée dans ce tableau, car il s’agit de ressources

fixes qui ne peuvent donc être disponibles que sur un seul noeud. Pour

une ressource flottante, cet attribut est modifié de manière implicite si une

ressource constituante est supprimée de manière explicite par

l’administrateur afin que la relation entre la ressource d’agrégat et la

ressource constituante soit toujours cohérente. Il se peut que cette liste soit

vide pour une ressource flottante. Cela signifie qu’elle n’est disponible

nulle part et que les constituants peuvent être ajoutés séparément. La liste

peut contenir au maximum un nom si la ressource est fixe (c’est-à-dire si

ResourceType=0). Si aucun nom n’a été attribué à une ressource fixe, RMC

proposera un nom par défaut. En effet, la ressource fixe est associée à un

noeud et elle ne peut donc pas être créée sans nom ou ID de noeud. Pour

les ressources d’agrégat, la valeur de cet attribut peut être modifiée à l’aide


de la commande chrsrc. Toute tentative de modification de cet attribut

pour une ressource constituante générera une erreur.


Utilisez l’attribut persistant ResourceType pour indiquer s’il s’agit d’une

ressource fixe ou flottante. La valeur 0 indique que la ressource est fixe et

la valeur 1 indique qu’il s’agit d’une ressource flottante. Si aucune valeur

n’est précisée lors de la création de la ressource IBM.AgFileSystem, cet

attribut prend par défaut la valeur 0 (fixe).


L’attribut persistant ProtectionMode indique si la ressource est critique ou

non. S’il s’agit d’une ressource critique, IBM.ConfigRM décide si la

ressource peut être démarrée comme demandé. Pour plus d’informations

sur ce comportement, voir Chapitre 9, «Protection de vos ressources –

support réalisé par Quorum», à la page 167. L’attribut peut prendre les

valeurs 0 (non critique) ou 1 (critique). La valeur par défaut est 1 (critique).

Attribut PreOnlineMethod

Ce paramètre détermine si le gestionnaire de ressources de stockage doit

utiliser par défaut la commande fsck pour vérifier et réparer les systèmes

de fichiers et définit le cas échéant le format exact de cette commande.

Pour plus d’informations, consultez le manuel RSCT Administration Guide,

Chapter 6 - Understanding and administering the storage resource

manager.

Attribut Force

Indiquez Force=1 si une ressource IBM.AgFileSystem définissant la même

valeur d’attribut DeviceName existe déjà. C’est par exemple le cas si le

système de fichiers a été collecté par le gestionnaire de ressources de

stockage. L’attribut Force est inutile si le gestionnaire de ressources de

stockage ne connaît pas déjà le périphérique (comme c’est le cas avec le

système de fichiers NFS).

Attribut OpState

La valeur de cet attribut d’état dynamique contient l’état opérationnel de la

ressource déterminé par le gestionnaire de ressources. Les valeurs

courantes de cet état sont En ligne (valeur 1) et Hors ligne (valeur 2). Elles

indiquent si le point de montage est monté ou non.


Chapitre 13. System Automation for Multiplatforms sous

Windows : spécificités et restrictions

Ce chapitre résume les spécificités du comportement de System Automation for

Multiplatforms sous Windows. Il décrit en particulier les différences entre la

version Windows et les versions de System Automation for Multiplatforms sous

AIX, Solaris et Linux. Cela ne vous dispense cependant pas de lire les chapitres

précédents, car ils contiennent des informations générales sur le produit, valables

pour toutes les plateformes.

Utilisation de System Automation for Multiplatforms sur les systèmes

Windows

Comme expliqué dans les chapitres précédents, les compétences d’administration

UNIX de base sont requises pour utiliser System Automation for Multiplatforms

sur des systèmes Windows.

Contenu de SA for Multiplatforms

Le programme d’installation crée le dossier Tivoli SA MP Base dans votre menu

Démarrer. Il contient les éléments suivants :

v Dossier Documentation

Ce dossier contient une copie électronique de la documentation utilisateur pour

ce produit. Pour afficher le fichier PDF, un "programme de lecture PDF" doit être

installé sur votre système. Le dossier Documentation est indisponible si vous

décidez de ne pas en installer.

v Configurer l’adaptateur d’automatisation - cfgsamadapter

Exécute le programme de configuration en mode graphique de l’adaptateur

d’automatisation System Automation for Multiplatforms.

v Interpréteur de commandes IBM Tivoli System Automation

Il s’agit de l’interpréteur de commandes principal à utiliser comme interface

avec RSCT et System Automation for Multiplatforms sous Windows.

v Liste des ressources définies – lssam

Quand un domaine a été configuré et les ressources créées, cet utilitaire vous

permet d’afficher l’ensemble des ressources définies et les groupes de ressources

ainsi que leurs états. Il démarre un interpréteur de commandes SA MP avec la

commande lssam -top.

v Version SA MP

Lien vers un fichier texte contenant des informations sur la version de System

Automation for Multiplatforms actuellement installée.

v Désinstaller SA for Multiplatforms

Lien permettant de désinstaller le produit.


Utilisation de l’interpréteur de commandes IBM Tivoli System

Automation

Toutes les commandes liées à RSCT et à System Automation for Multiplatforms

doivent être exécutées à partir de l’Interpréteur de commandes IBM Tivoli

System Automation, qui se trouve par défaut dans le dossier Démarrer > Tous les

programmes > SA for Multiplatforms. Il est impossible d’exécuter des commandes

RSCT ou System Automation for Multiplatforms à partir de la fenêtre d’invite de

commande standard et de la commande Exécuter de Windows.

Cet interpréteur de commandes IBM Tivoli System Automation est basé sur un

processus d’interpréteur de commandes Korn qui est installé avec le composant

Windows "Sous-système pour applications UNIX". Par conséquent, vous pouvez le

personnaliser davantage (par exemple, en configurant l’éditeur de ligne de

commande de choix) en modifiant les fichiers /etc/profile.lcl ou

<user_home>/.kshrc.

Après avoir configuré votre premier domaine d’automatisation, vous pouvez vous

connecter sur n’importe quel système de ce domaine. Vous pouvez exécuter une

commande RSCT ou System Automation for Multiplatforms à partir de n’importe

quel noeud du domaine.

Vous pouvez ouvrir une session à l’aide d’une des méthodes suivantes :

v Connectez-vous directement au système Windows et ouvrez un interpréteur de

commandes IBM Tivoli System Automation.

v Ouvrez une connexion depuis un ordinateur à l’aide de l’option “Ouvrir une

connexion distante”, puis ouvrez un interpréteur de commandes IBM Tivoli

System Automation.

v Si vous avez configuré le service Telnet SUA ou le processus démon rsh (voir la

description dans le Guide d’installation et de configuration d’IBM Tivoli System

Automation for Multiplatforms), vous pouvez accéder à tous les noeuds du

domaine d’automatisation par le biais de Telnet ou de rsh. Cet accès est pris en

charge uniquement par System Automation for Multiplatforms sous Windows

Server 2003.

Instrumentation des ressources avec les classes de

ressources

Une ressource est une entité physique (matériel) ou logique (logiciel) qui fournit

des services aux autres composants. Chaque ressource appartient à une classe de

ressource spécifique. Toutes les ressources prennent en charge un ensemble

commun d’opérations et, au sein de leurs classes, disposent d’un ensemble unique

d’attributs et de méthodes. Toutes les ressources contrôlées par RSCT sont

globalement accessibles dans la grappe. Les classes de ressources sont mises en

oeuvre par les gestionnaires de ressources comme décrit dans les chapitres

précédents du présent guide. System Automation for Multiplatforms sous

Windows permet de contrôler et d’automatiser les types de ressources suivants à

l’aide de la classe de ressources IBM.Application :

v Applications SUA (binaires)

v Script de shell SUA

v Applications Windows (EXE)

v Fichiers de traitement par lots Windows

v Scripts Visual Basic

v Services Windows


v Volumes et ressources partagés

IBM.Application

Automatisation des scripts de shell et des applications SUA natives : Vous

pouvez automatiser les applications binaires qui sont conçues pour ou adaptées

aux scripts de shell et sous-système SUA (.sh et .ksh) à l’aide de la classe de

ressource IBM.Application qui est fournie par le gestionnaire des ressources

globales. Le comportement des ressources est le même que sur les systèmes AIX,

Solaris et Linux, et il ne sera donc pas décrit de façon plus détaillée dans ce

document.

Automatisation des applications Windows (binaires) : Dans des sous-systèmes

SUA, la commande runwin32 simplifie la recherche et l’exécution des binaires

Win32. Dans le répertoire /usr/contrib/win32/bin, le sous-système fournit

également une collection regroupant de nombreux scripts de shell portant le nom

des certaines commandes cmd.exe intégrées et de certains utilitaires Windows

généralement présents dans le répertoire système de Windows

(%SystemRoot%\system32 sous Windows Server 2003 et %SystemRoot%\System32 sous

Windows Server 2008).

Outre ces scripts de shell, les interpréteurs de commandes SUA fournissent

également une méthode de recherche de commande insensible à la casse afin de

simplifier l’appel direct de programmes Win32, sans avoir à utiliser l’adressage

indirect des scripts dans /usr/contrib/win32/bin.

Une fois qu’une application Win32 est démarrée, elle interagit directement avec le

sous-système Windows sans aucune autre connexion, en principe, avec le

sous-système SUA. La classe de ressources IBM.Application peut également

contrôler les applications Windows natives (.exe). Ces applications sont lancées

directement ou à l’aide d’un script de shell ou d’un fichier de traitement par lots

Windows, qui peut, par exemple, être utilisé pour le mappage de codes retour.

Vous pouvez automatiser les applications Win32 à interface graphique (le

Bloc-notes, par exemple), mais les interfaces graphiques ne s’afficheront pas sur le

poste de travail.

Automatisation des fichiers de traitement par lots Windows : La classe de

ressources IBM.Application permet d’automatiser les applications Windows qui

sont démarrées, arrêtées et gérées à l’aide des fichiers de traitement par lots

Windows (.bat). Vous pouvez indiquer ces fichiers de traitement par lots comme

commandes de Démarrage, d’Arrêt et de Gestion des ressources en ajoutant au

préfixe le processeur de fichiers de traitement par lots Windows correct cmd.exe.

Dans ce cas, le fichier de traitement par lots doit renvoyer les codes retour requis

indiquant l’état courant de la ressource de Tivoli System Automation for

Multiplatforms. Le fichier de traitement par lots doit se terminer par un appel de

sortie <RC> afin de terminer l’opération. Il ne doit pas utiliser l’option /b de la

commande exit, car la variable d’environnement ERRORLEVEL prendrait alors la

valeur du code retour, qui ne peut pas être observé dans l’environnement

d’interpréteur de commande du sous-système pour applications UNIX.

Exemple :

StartCommand "cmd.exe /C XYZStart.bat"

StopCommand = "cmd.exe /C XYZStop.bat"

MonitorCommand = "cmd.exe /C XYZMonitor.bat"

Chapitre 13. System Automation for Multiplatforms sous Windows : spécificités et restrictions 271

Automatisation des scripts Visual Basic : De nombreux programmes utilitaires

sous Windows sont mis en oeuvre à l’aide des scripts Visual Basic (VBScripts). Ces

scripts sont lancés à la fois depuis l’interpréteur de commandes Windows et depuis

l’interpréteur de commandes Korn fourni par Interix à l’aide de l’utilitaire cscript.

Il s’agit d’un exemple de script très simple qui ouvre une boîte de dialogue

Windows et vous demande d’indiquer la valeur entière à retourner comme valeur

de sortie à l’appelant :

sExitCode = InputBox ( "Enter Exit Code (0 - 255)", "Script", "0")

Si non IsNumeric(sExitCode) Alors sExitCode = 0

WScript.Quit(sExitCode Mod 255)

Après l’exécution de ce script avec cscript, le code de sortie qui a été indiqué par

l’utilisateur peut être demandé en observant la variable d’environnement

%ERRORLEVEL% ou la valeur $? dans l’interpréteur de commandes Korn,

respectivement.

Exemple :

StartCommand "cscript XYZStart.vbs"

StopCommand = "cscript XYZStop.vbs"

MonitorCommand = "cscript XYZMonitor.vbs"

Pour plus d’informations, voir

http://.microsoft.com/technet/interopmigration/unix/sfu/runwin32.mspx

Automatisation des services Windows : De nombreuses applications du système

d’exploitation Windows sont enregistrées comme des services et sont contrôlées

par le gestionnaire de services Windows. Selon les paramètres, ce contrôleur va les

démarrer lors du démarrage du système et même réagir en cas d’échec, par

exemple, en les redémarrant. Afin de pouvoir être contrôlée par le gestionnaire de

services Windows, chaque application doit enregistrer une méthode pour le

démarrage, l’arrêt et pour la transmission de l’état courant au gestionnaire de

services Windows.

Ces services seront contrôlables par Tivoli System Automation for Multiplatforms

par le biais de l’utilitaire samservice. L’utilitaire permet d’effectuer les tâches

suivantes :

v Contacter le gestionnaire de services Windows pour :

– démarrer ou arrêter un service avec le nom donné

– demander l’état opérationnel courant du servicev Associer les codes retour provenant du gestionnaire de services Windows aux

codes retour définis de Tivoli System Automation for Multiplatforms

v Se déconnecter du gestionnaire de services Windows

L’utilitaire samservice permet de créer des ressources de classe IBM.Application. Il

est possible de spécifier cet utilitaire pour les commandes de Démarrage, d’Arrêt et

de Gestion comme décrit dans l’exemple ci-dessous. L’utilitaire samservice est

fourni uniquement sous forme de composant de System Automation for

Multiplatforms sous Windows.

Remarque : Quand vous utilisez samservice pour automatiser les services

Windows, le service Windows particulier ne doit plus être démarré

automatiquement par le gestionnaire de services Windows.


Exemple :

StartCommand "samservice –start XYZ"

StopCommand = "samservice –stop XYZ"

MonitorCommand = "samservice –monitor XYZ"

Automatisation des volumes Windows : Les volumes Microsoft Windows sont

des zones de stockage uniques accessibles avec un système de fichiers unique,

c’est-à-dire des unités logiques. Ces volumes peuvent devenir accessibles sous

Windows en leur attribuant un identificateur d’unité ou en les installant dans un

répertoire vide qui est accessible sur le système.

Sur les disques de base, une partition principale ou logique formatée est

représentée par un volume. Sur les disques dynamiques, vous pouvez définir une

seule partition par disque et les volumes peuvent s’étendre sur plusieurs partitions.

L’interface graphique de gestion du disque Windows (qui correspond à un

composant logiciel enfichable pour l’interface graphique de gestion informatique)

et l’outil de ligne de commande “diskpart.exe” permettent de gérer, d’installer et

de désinstaller des volumes. L’outil diskpart.exe offre un mode de commande

interactif et un mode de script où les commandes de gestion de disque, de

partition et de volume peuvent être exécutées.

Quand vous utilisez diskpart.exe pour effectuer des opérations de gestion de

volume, vous devez sélectionner le volume pour pouvoir exécuter une commande

de volume.

Exemple :

DISKPART> liste des volumes

Volume ### Ltr Libellé Fs Type Taille Etat Info

---------- --- ----------- ----- ---------- ------- --------- --------

* Volume 0 Etendu NTFS Etendu 202 Mo Sain

Volume 1 D BRMSCD2FRE_ CDFS CD-ROM 122 Mo Sain

Volume 2 C NTFS Partition 4087 Mo Sain Système

Volume 3 E SUA NTFS Partition 8189 Mo Sain

DISKPART> sélection du volume 0

Le Volume 0 est le volume sélectionné.

DISKPART> détails du volume

Disque### Etat Taille Libre Dyn Gpt

-------- ---------- ------- ------- --- ---

* Disque 2 En ligne 101 Mo 394 Ko *

Disque 3 En ligne 101 Mo 378 Ko *

En lecture seule : Non

Masqué : Non

Aucun identificateur d’unité par défaut : Oui

Copie répliquée : Non


La commande diskpart.exe “assign” permet d’installer un volume. Un

identificateur d’unité est attribué au volume ou il est installé dans un répertoire

vide :

DISKPART> assign mount=C:\test

DiskPart a correctement attribué l’identificateur d’unité ou le point de montage.



---------- --- ----------- ----- ---------- ------- --------- --------


C:\test\




La commande diskpart.exe “remove” permet de désinstaller un volume :

DISKPART> remove mount=C:\test

DiskPart a correctement supprimé l’identificateur d’unité ou le point de montage.



---------- --- ----------- ----- ---------- ------- --------- --------





Automatisation des ressources partagées Windows : Les systèmes Windows

autorisent le partage de disque et d’autres ressources avec d’autres systèmes via la

méthode de “ressources partagées”. L’ensemble des disques (c’est-à-dire les

volumes) ou les dossiers Windows (c’est-à-dire une arborescence de répertoires

particulière) peuvent être partagés. Ces ressources partagées sont publiées suivant

la convention de dénomination universelle (UNC).

Exemple de nom d’une ressource partagée : \\computername\resourcename

Un système Windows peut accéder à une ressource partagée en sélectionnant

simplement le nom universel ou en associant le nom universel à un identificateur

d’unité. La commande “net.exe use” permet d’associer une ressource partagée à un

identificateur d’unité.

Exemple : “net.exe use X: \\server\res” associe la ressource partagée “res” du

système “server” à l’identificateur d’unité “X”.

Automatisation des partages NFS : Les systèmes Windows avec le module du

sous-système pour applications UNIX permettent d’utiliser les partages NFS. Les

partages NFS sont installés à l’aide de la commande “mount” et désinstallés à

l’aide de la commande “umount”.


IBM.ServiceIP

La procédure de création d’une adresse IP de service sous Windows est similaire à

celle décrite pour AIX, Solaris et Linux dans les chapitres précédents de ce

document. La seule différence se trouve dans la zone de “Nom” des interfaces

réseau collectées. Sous Windows, l’ID unique de chaque connexion réseau

représente l’interface réseau connectées. Par conséquent, en lieu et place des

identifications classiques de type “eth0” ou “en0”, le nom de l’interface réseau se

présentera de la manière décrite ci-dessous.

> lsrsrc IBM.NetworkInterface

Attributs persistants de ressource pour IBM.NetworkInterface

ressource 1 :

Name = "F8A5F7C5-68C9-4F39-8779-4AFA80385145"

DeviceName = ""

IPAddress = "9.152.23.169"

SubnetMask = "255.255.252.0"

Subnet = "9.152.20.0"

CommGroup = "CG1"

HeartbeatActive = 1

Aliases = {}

DeviceSubType = 0

LogicalID = 0

NetworkID = 0

NetworkID64 = 0

PortID = 0

HardwareAddress = ""

DevicePathName = "Local Area Connection"

ActivePeerDomain = "Domain1"

NodeNameList = {"SAXBOPT10C"}

La valeur “DevicePathName” de la classe IBM.NetworkInterface reflète le nom des

interfaces explorées sous les “connexions réseau” Windows. Elle permet de

reconnaître les interfaces réseau collectées à utiliser pour la création d’une

ressource IBM.ServiceIP.

Restrictions liées aux adresses IP : L’approche utilisée par System Automation

for Multiplatforms sous Windows Server 2003 et Windows Server 2008 pour

l’attribution d’adresses IP aux interfaces réseau diffère de celle utilisée sur les

autres plateformes prises en charge. Sur les autres plateformes, une adresse IP de

base est associée à une interface réseau et les autres adresses IP sont considérées

comme des adresses IP d’alias. Plus précisément, lorsqu’une adresse IP est

attribuée en utilisant la ressource IBM.ServiceIP, elle est considérée comme une

adresse IP d’alias sur ces plateformes. Sous Windows Server 2003 et Windows

Server 2008, toutes les adresses IP sont au même niveau et les concepts d’adresses

de base et d’adresses d’alias n’existent pas. Sur les plateformes Windows Server,

les adresses IP attribuées en utilisant une ressource IBM.ServiceIP ne sont en aucun

cas prioritaires par rapport aux autres adresses IP attribuées aux interfaces réseau.

Cette différence d’approche en matière d’association d’adresses IP aux interfaces

réseau sous Windows Server 2003 et Windows Server 2008 a une conséquence

majeure : lorsque System Automation for Multiplatforms envoie une requête au

système pour obtenir la liste des adresses IP associées à une interface réseau, la

première adresse IP renvoyée pour l’interface réseau sera considérée comme

l’adresse IP de base. L’adresse IP de base est utilisée par System Automation for

Multiplatforms pour créer une ressource IBM.NetworkInterface pour l’interface

réseau. La plateforme Windows Server renvoyant toujours l’adresse IP ″la plus

faible″ comme première adresse IP, cette dernière est systématiquement utilisée

pour la ressource IBM.NetworkInterface représentant l’interface réseau. En matière

d’adresses IP, les expressions ″la plus faible″ et ″inférieure″ font référence aux

quatre valeurs séparées par des points qui définissent les adresses IP.


Exemple : les adresses IP 192.168.0.11 et 192.168.0.100 sont actuellement attribuées

à une interface réseau. L’adresse IP 192.168.0.11 est inférieure à 192.168.0.100, car

les trois premières valeurs sont égales et la quatrième valeur de la première

adresse IP est inférieure à la quatrième valeur de la deuxième adresse. Ainsi,

l’adresse IP 192.168.0.11 est l’adresse IP la plus faible de l’interface réseau et par

conséquent l’adresse IP de base. Une ressource IBM.NetworkInterface est collectée

pour l’interface réseau associée à l’adresse IP 192.168.0.11.

La définition, sur une interface réseau, d’une nouvelle adresse IP ″inférieure″ à

l’adresse IP actuelle ″la plus faible″ ou la suppression de l’adresse ″la plus faible″

provoquera la modification de l’adresse IP de base de l’interface réseau. Plus

précisément, si une adresse IP attribuée en utilisant une ressource IBM.ServiceIP

est ″inférieure″ à l’adresse IP actuelle ″la plus faible″, cette adresse IP deviendra la

nouvelle adresse IP de base. Lorsqu’une nouvelle adresse IP devient l’adresse IP de

base d’une interface réseau, System Automation for Multiplatforms détecte la

modification et la ressource IBM.NetworkInterface correspondante est modifiée. Si

la nouvelle adresse IP de base ne se trouve pas dans le même sous-réseau que

l’ancienne adresse IP, la ressource IBM.NetworkInterface est déplacée vers un autre

groupe de communication, ce qui peut provoquer une défaillance au niveau des

domaines d’automatisation en cours d’exécution.

Exemple : les adresses IP 192.168.0.11 et 192.168.0.100 sont actuellement attribuées

à une interface réseau. L’adresse IP 192.168.0.11 étant l’adresse IP la plus faible de

l’interface réseau, elle est considérée comme l’adresse IP de base. La nouvelle

adresse IP 10.0.0.1 est attribuée à l’interface réseau grâce à la mise en ligne d’une

ressource IBM.ServiceIP. L’adresse IP 10.0.0.1 étant désormais l’adresse IP la plus

faible, elle devient l’adresse IP de base. System Automation for Multiplatforms

détecte cette modification et modifie la ressource IBM.NetworkInterface de

l’interface réseau en conséquence.

Avertissement : Sous Windows Server 2003 et Windows Server 2008, vous ne

devez en aucun cas changer l’adresse IP ″la plus faible″ d’une interface réseau en

ajoutant une adresse à l’interface, en supprimant une adresse de l’interface ou en

modifiant une de ses adresses existantes. L’utilisation de la ressource IBM.ServiceIP

pour modifier l’adresse est également proscrite. Si vous modifiez l’adresse IP ″la

plus faible″ d’une interface réseau, vous risquez dans tous les cas de perturber

gravement le fonctionnement des domaines d’automatisation System Automation

for Multiplatforms en cours d’exécution.

Adresses IP en double : Windows Server 2003 et Windows Server 2008 détectent

automatiquement les adresses IP en double. Si une nouvelle adresse IP est ajoutée

ou qu’une adresse existante est modifiée, un contrôle est réalisé pour déterminer si

la nouvelle adresse IP est déjà en cours d’utilisation sur la liaison réseau

(c’est-à-dire sur le sous-réseau) à laquelle l’interface réseau est connectée. Si une

nouvelle adresse IP est détectée comme étant un doublon, elle est désactivée par le

système d’exploitation. Lors de l’affichage des adresses IP du système, Windows

Server répertorie également toutes les adresses IP en double et signale la présence

des doublons.

Lorsqu’une adresse IP est attribuée à une interface réseau en utilisant une

ressource IBM.ServiceIP, Windows Server détecte également les adresses IP en

double. Si l’adresse IP est considérée comme étant un doublon, la ressource

IBM.ServiceIP perd le contrôle de l’adresse IP sur ce système. System Automation

for Multiplatforms signale que l’état de la ressource IBM.ServiceIP est Non défini.


Avertissement : Veillez à ce que les adresses IP attribuées à une interface réseau

en utilisant une ressource IBM.ServiceIP soient uniques sur la liaison réseau à

laquelle l’interface réseau est connectée. Dans le cas contraire, System Automation

for Multiplatforms ne pourra pas démarrer, arrêter ni surveiller la ressource

IBM.ServiceIP.

Si vous créez une adresse IP en double en utilisant une ressource IBM.ServiceIP,

vous devez supprimer cette adresse IP manuellement. Pour ce faire, utilisez la

commande Windows netsh.exe. Procédez comme suit :

1. Sélectionnez Démarrer > Tous les programmes > Accessoires > Invite de

commandes.

2. Exécutez la commande suivante : netsh.exe interface ipv4 show ipaddresses.

3. Repérez le nom de l’interface à laquelle est attribuée l’adresse IP en double.

4. Exécutez la commande suivante : netsh.exe interface ipv4 delete address

name="<nom de l’interface>" address="<adresse IP en double>".

5. Exécutez la commande suivante : netsh.exe interface ipv4 show ipaddresses.

6. Vérifiez que l’adresse IP en double a bien été supprimée.

Procédure de démarrage

Vérification du fonctionnement du contrôleur des ressources

système (SRC)

Le contrôleur des ressources système (SRC) est le processus d’amorce qui est

démarré en premier et qui entraîne tous les autres processus démon requis par

RSCT et Tivoli System Automation for Multiplatforms pour fonctionner. Il est

également chargé de redémarrer ces processus démon après un échec.

Introduit tout d’abord dans AIX, le contrôleur des ressources système associe un

ensemble de commandes et de sous-programmes pour simplifier la création et le

contrôle des sous-systèmes par le gestionnaire système. Le contrôleur des

ressources système a été conçu pour réduire le besoin d’intervention de l’opérateur.

Il offre une méthode de contrôle des processus de sous-système à l’aide de

l’interface de ligne de commande commune.

Le contrôleur des ressources système prend en charge l’ensemble des commandes

d’administration suivantes :

srcmstr

Démarre le contrôleur des ressources système

startsrc

Démarre un sous-système ou un groupe de sous-systèmes

stopsrc

Arrête un sous-système ou un groupe de sous-systèmes

refresh

Régénère un sous-système

traceon/traceoff

Active ou désactive la fonction de trace d’un sous-système

lssrc Récupère l’état d’un sous-système


Le contrôleur des ressources système sous Windows démarre automatiquement en

tant que service Windows au démarrage du système. Il se trouve dans la liste des

services Windows sous le nom “Contrôleur des ressources système”

Les autres composants de RSCT et System Automation for Multiplatforms sont

démarrés par le biais du processus démon init.d, configuré dans /etc/r2.d.

Redémarrage du contrôleur des ressources système et du

RMC

La procédure suivante décrit la méthode de renvoi de tous les composants de

RSCT/RMC. Elle doit être utilisée uniquement si toutes les autres options

d’interaction avec Tivoli System Automation for Multiplatforms (stoprpnode,

stoprpdomain, par exemple) ont échoué.

Pour renvoyer tous les composants, procédez comme suit :

1. Arrêtez tous les gestionnaires de ressources, les sous-systèmes HATS et HAGS

en exécutant la commande stopsrc –a.

2. Vérifiez que tous les processus sont arrêtés en exécutant lssrc –a

3. Vous pouvez également exécuter une commande kill -9 sur les sous-systèmes

qui restent affichés dans les résultats de la commande lssrc –a.

4. Arrêtez le contrôleur des ressources système à partir du gestionnaire de

services Windows.

5. Vous pouvez également exécuter une commande kill -9 sur le processus du

contrôleur des ressources système si le processus srcmstr figure toujours dans

le résultat renvoyé par la commande ps -e -o pid,cmdnam -X unix | grep

srcmstr.

6. Redémarrez le contrôleur des ressources système à partir du gestionnaire de

services Windows.

7. Démarrez le sous-système RMC en exécutant la commande rmcctrl -s.

Figure 19. Console de gestion informatique Windows affichant tous les services


Indicateur de présence permettant de protéger les ressources critiques

Dans un environnement à haute disponibilité, il est essentiel qu’une seule instance

de ressource critique fonctionne en même temps. L’exemple classique d’une

ressource critique porte sur l’accès en lecture-écriture à un disque partagé, qui,

lorsqu’il est accordé à plus d’un noeud à la fois, risque d’entraîner une altération

de la structure du système de fichiers à moins qu’un système de fichiers

compatible avec la grappe prenne soin de le verrouiller correctement.

L’algorithme de quorum de ConfigRM évite que ce scénario se produise, mais à la

seule condition que ConfigRM, HATS et HAGS possèdent suffisamment de

ressources pour exécuter leurs calculs. L’indicateur de présence intervient si cette

infrastructure RSCT de niveau inférieur ne peut plus assurer la gestion des

ressources critiques ; par exemple la carence de processus ou les verrouillages.

L’indicateur de présence nécessite un accès à intervalle régulier sur une période

donnée ; si l’accès est manqué, le noyau déclenche lui-même un réamorçage

immédiat, le dernier moyen d’éviter de démarrer deux fois une ressource critique.

Sur les systèmes Linux, cette fonction est mise en oeuvre par le biais d’un

redémarrage (appel système “halt”) et du module appelé “softdog”. Sous Solaris et

AIX, c’est le pilote de périphérique haDMS qui est utilisé pour cette opération.

Sous Windows, c’est le pilote de périphérique ibmhadms.sys qui est utilisé. Il sert

pour :

v arrêter immédiatement un système sur demande

v arrêter le système s’il n’a pas été réenclenché pendant un moment (indicateur de

présence)

Le pilote de périphérique utilise une routine de noyau de bas niveau pour

provoquer un “écran bleu” (BSOD). Il s’agit de la méthode la plus efficace pour

arrêter immédiatement un système Windows. L’effet est équivalent à celui de la

méthode “halt” disponible sur les systèmes UNIX et Linux.

Valeurs du quorum opérationnel

Si des ressources critiques sont actives sur une sous-grappe dépourvue d’un

quorum, ConfigRM détermine la façon dont le système doit prendre fin. Sous AIX,

Solaris et Linux, il existe six méthodes de protection différentes pouvant être

configurées par l’attribut “CritRsctProtMethod” sur chaque noeud. Pour System

Automation for Multiplatforms sous Windows, le pilote de périphérique

ibmhadms.sys ne peut pas être configuré de cette manière.

Vous pouvez configurer la reprise et la méthode de restauration d’un système

après une BSOD à partir de la boîte de dialogue “Démarrage et reprise” à la

section avancée des propriétés système. Vous pouvez définir cette option dans

Windows Propriétés système > “Avancé” Onglet > “Démarrage et reprise” à la

section > Paramètres. Les modifications de configuration souhaitées doivent être

indiquées séparément sur chaque système.


Pour System Automation for Multiplatforms sous Windows, voici comment se

présente la table de la méthode de protection :

Tableau 25. Méthodes de protection du quorum opérationnel

Signification Valeur


Multiplatforms sous

Windows

Réinitialisation à froid et

redémarrage du système

d’exploitation (par défaut)

1 L’option qui détermine si le

système est réamorcé ou non

lors de la BSOD est indiquée

dans “Propriétés système” Arrêt du système

d’exploitation

2

Réinitialisation à froid et

redémarrage du système

d’exploitation avec Sync

3 Non pris en charge –

Traitement identique aux

valeurs 1 et 2 ci-dessus

Arrêt avec Sync 4

Aucune protection. Le

système continue de

fonctionner

5 Pris en charge

Quitte et redémarre les

sous-systèmes RSCT

6 Pris en charge

En fonction de la configuration Windows, le système d’exploitation redémarrera

automatiquement après une BSOD.


Composants disponibles uniquement pour System Automation for

Multiplatforms sous Windows

Utilitaire SAMSERVICE

Cet utilitaire permet de démarrer, d’arrêter et de gérer facilement les services

Windows. Il contacte le processus de gestionnaire de services Windows, lance une

demande des états en cours puis renvoie l’état une fois converti dans la valeur

d’état RSCT. Chaque commande de démarrage ou d’arrêt de samservice entraîne

une demande de démarrage ou d’arrêt également sur le gestionnaire de services

Windows. Si un service ne peut pas être démarré ou arrêté par l’utilitaire

samservice, exécutez la commande manuellement depuis le gestionnaire de

services Windows et déboguer ses résultats.

Figure 20. Configuration du système d’exploitation pour qu’il redémarre après une BSOD


Composants non disponibles pour System Automation for

Multiplatforms sous Windows

Le gestionnaire de ressources de stockage est disponible sous AIX, Solaris et Linux,

mais pas sous Windows. Cela signifie que vous devez utiliser les scripts de

contrôle spécifiés pour les ressources IBM.Application afin de contrôler les

ressources de stockage (disques).


Annexe A. Configuration d’un réseau hautement disponible

Lors de la configuration d’un réseau hautement disponible, il faut distinguer deux

cas de figure :

v Un système de communication en grappe plus fiable dans lequel l’infrastructure

de la grappe (RSCT) veille à ce que toutes les voies de communication

disponibles sont utilisées pour assurer l’intégrité de la grappe et la configuration

de la reproduction des données.

v Une représentation d’un service informatique hautement disponible dans lequel

l’automatisation prend en charge une adresse IP (portant le nom de ServiceIP)

représentant un service informatique aux clients hors de la grappe.

Bien qu’il soit possible d’utiliser la même interface de communication pour traiter

les deux tâches, nous recommandons de suivre une autre procédure. La section

suivante décrit la procédure à suivre.

Considérations à propos de la planification de la configuration d’un

réseau hautement disponible

Cette section vise à vous aider à mieux comprendre la complexité d’un réseau

hautement disponible et répertorie quelques questions qui viseront à vous aider à

planifier la configuration d’un réseau hautement disponible.


Qu’est-ce qui rend une infrastructure de réseau hautement

disponible difficile ?

La configuration d’une infrastructure de réseau hautement disponible ne sera pas

aussi simple que de brancher une autre interface de réseau sur un noeud existant.

Bien entendu, vous pouvez brancher le nouveau périphérique et le configurer avec

une adresse issue du réseau existant, mais ceci ne fonctionnera pas si la

″mauvaise″ interface est hors service. Voici un exemple de configuration sous

Linux :

Chaque périphérique réseau statique entraîne l’affichage d’une donnée dans la

table de routage. L’algorithme de routage sélectionne la première route

correspondante à partir de cette table de routage. Dans cet exemple, échec du

périphérique eth1 sur le noeud lnxcm1. Etant donné qu’eth1 est la première entrée

dans la table de routage, le noeud ne peut envoyer d’autres modules vers le réseau

bien qu’il y ait une autre interface de réseau en fonction.

Ce chapitre vous donne quelques conseils pour vous aider à rendre votre

infrastructure de réseau hautement disponible plus sophistiquée. Comme dans la

plupart des cas, l’approche la plus complexe (routage dynamique) reste la

meilleure, mais vous souhaiterez peut-être étudier les deuxième et troisième

meilleures approches pour réduire le niveau de difficulté et fournir un moindre

effort.

Figure 21. Problèmes lors de la planification d’un réseau hautement disponible

Configuration du réseau


Que faut-il clarifier avant de planifier un réseau hautement

disponible

Répondez aux questions suivantes avant de lancer la planification d’un réseau

hautement disponible :

1. De quel genre de réseau hautement disponible avez-vous besoin ? Est-il

nécessaire de déplacer la ressource ServiceIP d’une interface vers une autre sur

le même noeud, ou vaut-il mieux utiliser un autre noeud connecté à une

interface en fonctionnement dans un sous-réseau requis.

2. Pouvez-vous implémenter des sous-réseaux supplémentaires IP ou devez-vous

utiliser une infrastructure de réseau existante ?

3. Travaillez-vous exclusivement avec vos noeuds de grappe ou pouvez-vous

implémenter/déployer des services de réseau sur d’autres noeuds en dehors de

la grappe d’automatisation?

4. De quelle sorte de matériel réseaux disposez-vous ?

5. Quels investissements souhaitez-vous faire ?

6. Quel degré de complexité souhaitez-vous introduire ?

7. De quelles compétences disposez-vous ?

En fonction des réponses aux questions posées ci-dessus, faites votre choix parmi

l’une des configurations décrites dans ce chapitre pour développer votre propre

stratégie de réseau hautement disponible.

Détection des incidents liés à l’interface de réseau dans les grappes à

un noeud et deux noeuds

Si vous exécutez une grappe à un noeud ou à deux noeuds, une configuration

supplémentaire est nécessaire pour détecter les incidents liés à l’interface de réseau.

Le logiciel de la grappe essaie périodiquement d’atteindre chaque interface réseau

de la grappe. Si une interface échoue à un noeud d’une grappe comprenant deux

noeuds, l’interface située à l’autre noeud sera également marquée comme hors

ligne car elle ne reçoit pas de réponse de la part de son homologue.

Pour éviter tout comportement de ce type, le logiciel de la grappe devra être

configuré pour contacter une instance du réseau hors de la grappe. La meilleure

façon d’effectuer ceci est d’utiliser la passerelle de noeud par défaut du

sous-réseau où se trouve l’interface.

Créez le fichier suivant sur chaque noeud :

/var/ct/cfg/netmon.cf

Chaque ligne de ce fichier doit contenir le nom de la machine ou l’adresse IP de

l’instance du réseau externe. Les adresses IP devront être exprimées en notation

décimale.

Voici un exemple de fichier netmon.cf :

#il s’agit de la passerelle par défaut pour toutes les interfaces au sein

du sous-réseau 192.168.1.0 192.168.1.1

# Il s’agit de la passerelle par défaut pour toutes les interfaces au sein

du sous-réseau 192.168.2.0 gw.de.ibm.com


Annexe A. Configuration d’un réseau hautement disponible 285

Recommandations supplémentaires relatives à l’exécution de

Linux sur zSeries dans un environnement zVM

Lorsque vous exécutez IBM Tivoli System Automation for Multiplatforms sur

Linux sur zSeries au sein d’un environnement zVM, il est conseillé de créer un

fichier netmon.cf conformément à la procédure ci-dessus, mais également de

désactiver la diffusion pour tous les groupes de communication. Le mécanisme de

signal de présence RSCT transmet régulièrement des commandes ping de

diffusion, en particulier lorsqu’aucune interface réseau n’est disponible. Cette

fonction permet de savoir si l’interface réseau envoyant les commandes ping de

diffusion est toujours opérationnelle (si cela est le cas, les autres machines sont

censées répondre à cette commande ping). Cette fonction n’est pas utile si le fichier

netmon.cf a été configuré correctement en suivant la procédure décrite ci-dessus.

En effet, dans ce cas, la disponibilité d’autres interfaces réseau identifiées doit être

vérifiée. Alors que les commandes ping de diffusion lancées à partir d’un poste

autonome ne posent aucun problème, si les machines font partie d’un

environnement zVM, des problèmes de performances peuvent survenir. La raison

en est simple : tous les systèmes fonctionnant au sein de cet environnement zVM

et du même segment de réseau (même réseau IP et même masque réseau)

répondent à la requête ping de diffusion. Par conséquent, même les systèmes

invités de machine virtuelle en veille et transférés dans l’espace de pagination sont

chargés dans l’environnement zVM dans le seul but de répondre à la commande

ping. En fonction du nombre de systèmes invités fonctionnant dans cet

environnement zVM, les performances de l’ensemble du système z/VM peuvent

être ralenties.

Pour éviter tout impact négatif sur les performances, les modifications de

configuration suivantes sont recommandées :

v Obtenez la liste de tous les groupes de communication de la grappe :

# lscomg

v Désactivez la diffusion pour tous les groupes de communication :

# chcomg -x b <groupe de communication> ...

Par exemple :

chcomg -x b CG1

v Utilisez à nouveau la commande lscomg pour vérifier que la diffusion est

désactivée.



Grappe à deux noeuds, chaque noeud disposant d’une interface

Ethernet

La configuration du réseau suivante s’affiche :

Ressource Nom Unité IP

Noeud de grappe lnxcm1 eth0 9.152.172.1/24

Noeud de grappe lnxcm2 eth0 9.152.172.2/24

Routeur gw eth0 9.152.172.254/24

ServiceIP – – 9.152.172.3/24

Lors de cette configuration, la communication à l’intérieur de la grappe et la

présentation du service informatique hautement disponible utilisent la même voie

de communication, le réseau 9.152.172.0

ServiceIP peut être attribué automatiquement soit via l’interface eth0 lnxcm1 ou

l’interface eth0 lnxcm2. Si une interface échoue, l’automatisation renvoie le

ServiceIP vers l’autre noeud. En conséquence, il répond aux exigences relatives à

l’attribution d’une ressource ServiceIP au sein de l’interface réseau en fonction.

Si un échec se produit sur l’une des interfaces réseau au sein de cette

configuration, ceci entraînera une défaillance de la communication à l’intérieur de

la grappe ainsi que l’ensemble des problèmes décrits dans Chapitre 9, «Protection

de vos ressources – support réalisé par Quorum», à la page 167. Si la

communication échoue comme décrit dans figure 23, à la page 288, la condition de

départage détermine quel noeud pourra fonctionner au sein du processus

d’automatisation. S’il s’agit du noeud lnxcm1, l’automatisation ne trouvera aucune

interface réseau en ligne à laquelle attribuer la ressource ServiceIP au niveau de

lnxcm1.

Figure 22. Une interface à deux noeuds



Dans cet exemple, le réseau 9.152.172.0 répond à deux objectifs :

1. Représenter le réseau pour le service informatique hautement disponible.

2. Utilisé pour la communication interne entre les grappes.

Exemple de règles de System Automation for Multiplatforms :

lnxcm1# mkequ NetInt IBM.NetworkInterface:eth0:lnxcm1,eth0:lnxcm2

lnxcm1# mkrsrc IBM.ServiceIP Name="SIP"

IPAddress="9.152.172.3"

NetMask="255.255.255.0"

NodeNameList="{’lnxcm1’,’lnxcm2’}"

lnxcm1# mkrg rg

lnxcm1# addrgmbr -g rg IBM.ServiceIP:SIP

lnxcm1# mkrel -p dependson -S IBM.ServiceIP:SIP -G IBM.Equivalency:NetInt

Avantage Inconvénient

Configuration simplifiée. Chaque problème de communication

entraîne le fractionnement de la grappe.

Nécessite moins de matériel réseau. ServiceIP se déplace uniquement entre les

noeuds.

Figure 23. Une interface réseau à deux noeuds – échec de l’interface



Grappe à deux noeuds, chaque noeud disposant de deux interfaces

réseau

Avant de démarrer cette configuration, ne perdez pas de vue qu’il est impossible

d’avoir plus d’une interface réseau statique au sein du même sous-réseau IP. Vous

devrez entrer chaque adresse IP dans la table de routage du noyau. Si deux

interfaces se trouvent dans le même sous-réseau, deux routes permettent d’accéder

au même réseau. Si l’interface, qui est à l’origine de la première entrée, échoue, la

communication au sein de ce sous-réseau sera rompue même si une autre interface

est toujours en fonctionnement.

Deux réseaux séparés physiquement, déplacement de

ServiceIP entre les noeuds

La configuration réseau suivante concerne :


Noeud de grappe lnxcm1 eth0

eth1

9.152.172.1/24

192.168.1.1/24


eth1

9.152.172.2/24

192.168.1.2/24

Routeur gw eth0 9.152.172.254/24

ServiceIP - – 9.152.172.3/24

Il existe maintenant deux réseaux 192.168.1.0 et 9.152.172.0 pour assurer les

communications à l’intérieur de la grappe. Si un incident se produit au niveau

d’une interface réseau, la grappe ne sera pas rompue.

v Le réseau 9.152.172.0 représente le réseau pour le service informatique

hautement disponible.

v Le réseau 192.168.1.0 rend la communication interne entre les grappes plus

fiable.

Figure 24. Deux interfaces à deux noeuds, deux réseaux séparés physiquement



Puisque seul le réseau du ServiceIP est connecté à la passerelle, un échec de

l’interface eth0 au niveau de lnxcm1 provoquera le déplacement de ServiceIP vers

l’interface eth0 au niveau de l’autre noeud lnxcm2. Puisque les deux réseaux sont

séparés physiquement, il est impossible de déplacer ServiceIP depuis eth0 vers

eth1 au sein du même noeud.

L’exemple des règles de System Automation for Multiplatforms est le même que

celui décrit à la page , à la page 288.


Configuration simplifiée. ServiceIP se déplace uniquement entre les

noeuds.

Redondance au sein de la communication à

l’intérieur des grappes.

Trois réseaux logiques dans un réseau physique, déplacement

de ServiceIP entre les interfaces réseau

Il est nécessaire de procéder à une autre configuration réseau non seulement pour

déplacer ServiceIP entre les noeuds au sein de la grappe mais aussi entre les

interfaces au sein d’un noeud. Un réseau logique séparé est nécessaire pour chaque

interface d’un noeud, ainsi qu’un réseau supplémentaire pour ServiceIP. Le fait de

choisir un réseau existant (eth0 ou eth1) entraînera des problèmes de routage.

Veillez à connecter toutes les interfaces au même réseau physique. Ceci permet à

chaque interface de mettre en attente toutes les adresses des réseaux logiques.




eth1

192.168.1.1/24

192.168.2.1/24


eth1

192.168.1.2/24

192.168.2.2/24

Routeur gw eth0 9.152.172.254/24

ServiceIP - – 9.152.172.3/24



v Le réseau 9.152.172.0 représente le réseau pour le service informatique

hautement disponible.

v Le réseau 192.168.1.0 représente le premier réseau de communication interne à

l’intérieur de la grappe.

v Le réseau 192.168.2.0 représente le deuxième réseau de communication interne à

l’intérieur de la grappe.

Exemple de règles de System Automation for Multiplatforms :

lnxcm1# mkequ NetInt

IBM.NetworkInterface:eth0:lnxcm1,eth1:lnxcm1,eth0:lnxcm2,eth1:lnxcm2

lnxcm1# mkrsrc IBM.ServiceIP Name="SIP" IPAddress="9.152.172.3"

NetMask="255.255.255.0" NodeNameList="{’lnxcm1’,’lnxcm2’}"

lnxcm1# mkrg rg

lnxcm1# addrgmbr -g rg IBM.ServiceIP:SIP

lnxcm1# mkrel -p dependson -S IBM.ServiceIP:SIP -G IBM.Equivalency:NetInt


Configuration simplifiée. 3 réseaux logiques dans 1 réseau physique.



Trafic entre trois réseaux sur 1 moyen

physique.

ServiceIP peut se déplacer entre les

interfaces et les noeuds

Deux réseaux séparés physiquement, routage dynamique et

VIPA

La description détaillée de cette configuration n’est pas abordée dans ce manuel.

Autrement dit, ServiceIP est attribué à un réseau virtuel à l’intérieur du noyau

d’un noeud de grappe. Le routage dynamique sur tous les noeuds de grappe et la

passerelle assurent que la route vers ServiceIP est établie.

Figure 25. Un réseau physique à deux noeuds et deux interfaces






eth1

9.152.170.1/24

9.152.171.1/24


eth1

9.152.170.2/24

9.152.171.2/24

Routeur gw eth0

eth1

9.152.170.254/24

9.152.171.254/24

ServiceIP - – 9.152.172.3/24


Il n’existe pas de dépendance au réseau

physique.

Configuration complexe.

Concept permettant de trouver au sein d’un

réseau dynamique un hôte (adresse IP)

Routage dynamique exigé.

Plus besoin de déplacer ServiceIP entre les

interfaces

La configuration ne concerne pas

uniquement les noeuds de grappe ; la

passerelle doit elle-aussi prendre en charge

le routage dynamique.

Interface de connexion

Plusieurs interfaces de réseau physique sont reliées ensemble à un seul réseau

logique. Le système d’exploitation doit supporter cette fonction au moyen d’un

pilote de périphérique de connexion adéquat. Consultez le document sur votre

système d’exploitation pour savoir comment configurer la connexion à l’interface

sur votre système. Assurez-vous d’avoir configuré la connexion HA (à haute

disponibilité) et que vos cartes d’interface réseau prennent en charge le mécanisme

de détection d’échecs de l’interface dont votre périphérique de connexion a besoin.

Figure 26. Deux réseaux séparés physiquement, routage dynamique et VIPA






eth1

9.152.172.1/24

9.152.172.1/24


eth1

9.152.172.2/24

9.152.172.2/24

Routeur gw eth0 9.152.172.254/24

ServiceIP - - 9.152.172.3/24


Configuration simplifiée. Le système d’exploitation doit supporter

l’interface de connexion.



Le matériel d’interface réseau devra prendre

en charge la détection d’échecs d’interface

(par exemple, le contrôle de connexion MII)

Il est inutile de déplacer ServiceIP entre les

périphériques sur le même noeud.

ServiceIP9.152.172.3

gw

eth09.152.172.254

eth09.152.172.2

eth19.152.172.2

eth19.152.172.1

bond09.152.172.1

bond09.152.172.2

eth09.152.172.1

lxcm1 lxcm2

9.152.172.0

Figure 27. Interfaces de réseau connectées ensemble à un périphérique de réseau logique



Annexe B. Identification et résolution des incidents

Utilisez ces informations pour résoudre les incidents que vous pouvez rencontrer

lors de l’utilisation de IBM Tivoli System Automation for Multiplatforms.

Identification et résolution des erreurs et incidents liés à System


Cette section comporte les rubriques suivantes :

v «Fonctionnement de l’automatisation»Cette rubrique résume les concepts importants de System Automation.

v «Obtention d’informations pour la résolution des incidents», à la page 298Utilisez cette rubrique pour apprendre comment recueillir des informations sur

les ressources automatisées et les groupes de ressources.

v «Analyse des erreurs», à la page 307Utilisez les scénarios d’erreur décrits dans cette rubrique pour savoir comment

comprendre, isoler et résoudre les erreurs qui sont signalées par System

Automation. Les erreurs traitées sont les suivantes :

– «L’attribut OpState d’une ressource prend la valeur Echec hors ligne», à la

page 307

– «Un groupe de ressource prend la valeur OpState ou Echec hors ligne», à la

page 308

– «La commande StartCommand est arrivée à expiration», à la page 309

– «La commande StopCommand est arrivée à expiration», à la page 310

– «MonitorCommand est arrivé à expiration», à la page 311v «Analyse des incidents», à la page 312

Utilisez les scénarios d’incident décrits dans cette rubrique pour résoudre

efficacement les incidents liés à Sytem Automation, qui ne sont généralement

pas signalés par des messages d’erreur. Les incidents traités sont les suivants :

– «Une ressource n’est pas lancée», à la page 312

– «Un groupe de ressources n’est pas lancé», à la page 313

– «Une ressource ne peut pas être arrêtée», à la page 313

– «Un groupe de ressources ne peut pas être arrêté», à la page 314

– «Aucune reprise en ligne n’a lieu une fois qu’un noeud a été exclu», à la page

314

– «Aucune reprise de ligne n’a lieu après la panne ou le redémarrage d’un

noeud», à la page 315

– «Impossible de configurer la grappe», à la page 317

Fonctionnement de l’automatisation

Cette rubrique résume les concepts importants de System Automation. Pour plus

d’informations, voir Chapitre 7, «Traitement des informations système par System

Automation for Multiplatforms», à la page 93.

Gestionnaire d’automatisation

Le gestionnaire d’automatisation se compose du classeur et du module logique.


Classeur : Le classeur est chargé de rechercher une position pour les membres

d’un groupe de ressources lorsque le groupe est lancé ou lorsque les ressources

doivent être lancées sur un autre noeud car le noeud sur lequel elles se trouvaient

n’était pas exécuté précédemment, est en panne ou a été redémarré. La tâche

correspondante est l’étape de liaison et le résultat de la tâche est reflétée dans

l’attribut BindingState d’une ressource.

Les valeurs d’attributs BindingState pour une ressource sont les suivantes :

Non lié

La ressource n’est pas liée et est donc hors ligne. System Automation n’a

pas encore essayé de rechercher une position pour la ressource.

Lié La ressource a été liée à un noeud et est exécutée sur ce noeud ou System

Automation lance la ressource sur le noeud une fois que toutes les

dépendances dans les autres ressources ont été complétées.

Sacrificed

System Automation n’a pas pu trouvé de position pour la ressource. Il n’y

a aucune noeud sur lequel la ressource peut être lancée et pour cette

raison, la ressource ne sera pas lancée par System Automation.

Si la position de plusieurs groupe de ressources entraîne un conflit, la valeur de

priorité contrôle le groupe qui ne l’emporte pas dans ce conflit : il n’est pas

positionné et son état de liaison est défini sur Sacrificed, comme indiqué dans

l’exemple suivant :

Scénario : Dans une grappe contenant deux noeuds, le groupe de ressources

«RG1» contient la ressource «R1» et le groupe de ressources «RG2» contient la

ressource «R2». «R1» dépend de «R2». Les deux ressources sont lancées. Ensuite,

«R1» échoue. Le comportement qui en résulte dépend de la priorité des groupes de

ressources :

v Si «RG1» et «RG2» possèdent la même priorité, «R1» n’est pas relancé.

v Si «RG1» possède au moins une priorité de 21 (et «RG2» une priorité de 0), «R2»

est arrêté, et «R2» et «R1» sont lancées sur un autre noeud.

Module logique : Le module logique est chargé d’envoyer les ordres de

lancement et d’arrêt des ressources individuelles pour les mettre en ligne ou hors

ligne. Lors de l’envoi des ordres, le module logique s’assure que toutes les

dépendances de lancement et d’arrêt définies dans la règle d’automatisation sont

satisfaites.

Etats internes importants des ressources

System Automation conserve les informations concernant de nombreux états

internes pour chaque ressource. Les plus importants sont les suivants :

DesiredState

L’état que System Automation anticipe pour une ressource est appelé

DesiredState. Il s’agit de l’état dans lequel la ressource doit être lorsque les

requêtes et les votes des autres ressources sont pris en compte. L’état

DesiredState est en ligne ou hors ligne.

L’état DesiredState d’une ressource n’est pas forcément identique à la

valeur de l’attribut NominalState du groupe de ressources qui contient la

ressource, car les requêtes et les votes qui sont envoyés dans une ressource

possèdent une priorité supérieure à celle de l’attribut NominalState (pour

plus d’informations sur les priorités des requêtes, voir «Démarrage et arrêt

d’un groupe de ressources et de membres d’un groupe», à la page 200).

Résolution des incidents


ObservedState

L’état ObservedState est l’état réel de la ressource. Il est surveillé par le

gestionnaire de ressources de la ressource, par exemple, avec l’attribut

MonitorCommand pour une ressource de la classe IBM.Application et tous

les changements d’état sont signalés au gestionnaire d’automatisation.

L’objectif de System Automation est de s’assurer que les valeurs d’état

ObservedState de toutes les ressources correspondent aux valeurs d’état

DesiredState.


Annexe B. Identification et résolution des incidents 297

Obtention d’informations pour la résolution des incidents

Avant de commencer, collectez les données de débogage et de

trace

A tout moment de l’opération, les sous-systèmes de System Automation et de

RSCT écrivent les données de débogage et de trace dans des fichiers de trace situés

sur le disque local. Les fichiers de trace sont créés sous forme de mémoires tampon

en anneau pour limiter l’espace utilisé par les fichiers. Lorsque l’espace disponible

est dépassé, les fichiers de trace sont remplacés. En fonction du nombre de

ressources et de l’activité sur les noeuds, il est possible de consigner de grandes

quantités de données dans ces fichiers et ils peuvent être remplacés à tout moment.

Pour s’assurer qu’aucune donnée de débogage et de trace n’est perdue et améliorer

la probabilité que toutes les informations de diagnostic nécessaires soient

disponibles, au cas où vous auriez besoin de prendre contact avec le support IBM,

il est recommandé de collecter toutes les données de trace avant de commencer les

activités de résolution d’incidents, qui peuvent générer une sortie de trace.

Pour collecter toutes les données de débogage et de trace, utilisez la commande

ctsnap :

/usr/sbin/rsct/bin/ctsnap

La commande génère un fichier compacté dans le répertoire /tmp.

Astuce : Si vous êtes sûr que l’incident est lié à l’automatisation, par exemple,

lorsqu’une ressource n’est pas lancée, il suffit généralement de collecter la

trace de RecoveryRM. Pour enregistrer la trace de RecoveryRM dans un

fichier, suivez cette procédure :

1. Découvrez sur quel noeud le démon du maître RecoveryRM est

exécuté. A cet effet, émettez la commande suivante :

lssrc –ls IBM.RecoveryRM | grep Master

2. Enregistrez la trace de RecoveryRM dans un fichier de sortie. A cet

effet, émettez la commande ci-dessous sur le noeud du maître :

rpttr /var/ct/<domain-name>/log/mc/IBM.RecoveryRM/trace > <nom-fichier-sortie>

Utilisation du journal système comme source d’informations

Les messages qui sont générés par tous les sous-systèmes de System Automation et

par RSCT constituent la première source d’informations pour définir et résoudre

des incidents :

v Sous Linux : les messages sont écrits dans le journal système

(/var/log/messages).

v Sous AIX : le programme de journalisation système n’est pas configuré par

défaut. Les messages sont écrits dans le journal d’erreurs.

Pour pouvoir obtenir les données de débogage, il est recommandé de configurer

le programme de journalisation système dans le fichier /etc/syslog.conf.

Lorsque vous avez effectué les modifications nécessaires, vous devez réutiliser

syslogd à l’aide de la commande refresh –s syslogd. L’emplacement du fichier

journal est défini dans /etc/syslog.conf.

v Solaris : les messages sont écrits dans le journal système (/var/adm/messages).

v Sous Windows : les messages sont consignés dans /var/adm/log/messages. Vous

pouvez formater le fichier journal à l’aide de /usr/sbin/rsct/bin/fcslogrpt.



Les messages sont consignés dans le journal système pour les événements

suivants :

v Lancement d’un sous-système. Par exemple :

Mar 10 13:04:15 node1 RecoveryRM[5482]: (Recorded using libct_ffdc.a cv

2):::Error ID: 824....zgK22/WNI/8cU0B....................:::Reference

ID: :::Template ID: 0:::Details File: :::Location:

RSCT,IBM.RecoveryRMd.C,1.21.1.2,135 :::RECOVERYRM_INFO_0_ST

IBM.RecoveryRM daemon has started.

v Arrêt d’un sous-système. Par exemple :

Mar 10 13:04:28 node1 RecoveryRM[5482]: (Recorded using libct_ffdc.a cv

2):::Error ID: 822....AhK22/osT18cU0B....................:::Reference

ID: :::Template ID: 0:::Details File: :::Location:

RSCT,RecoveryRMDaemon.C,1.14,177 :::RECOVERYRM_2621_402_ER

IBM.RecoveryRM daemon stopped by SRC command or exiting due to an error

condition . Error id 0

v Erreur dans un sous-système. Par exemple :

Mar 10 13:04:14 node1 srcmstr: src_error=-9035, errno=0,

module=’srchevn.c’@line:’251’, 0513-035 The IBM.RecoveryRM Subsystem ended

abnormally. SRC will try and restart it.

v Messages liés à l’état Quorum de la sous-grappe. Par exemple :

Mar 9 16:13:07 node1 ConfigRM[31411]: (Recorded using libct_ffdc.a cv

2):::Error ID: :::Reference ID: :::Template ID: 0:::Details

File: :::Location:

RSCT,PeerDomain.C,1.99.11.1,15510 :::CONFIGRM_HASQUORUM_ST The

operational quorum state of the active peer domain has changed to

HAS_QUORUM. In this state, cluster resources may be recovered and

controlled as needed by management applications.

v Lancement et arrêt d’une ressource IBM.ServiceIP. Par exemple :

Mar 8 09:41:08 node1 GblResRM[1886]: (Recorded using libct_ffdc.a cv 2):::Error

ID: :::Reference ID: :::Template ID: 0:::Details File: :::Location:

RSCT,ServiceIP.C,1.2.5,1360 :::GBLRESRM_IPONLINE IBM.ServiceIP

assigned address on device. IBM.ServiceIP 10.67.78.89 eth1:1

Mar 8 09:42:44 node1 GblResRM[1886]: (Recorded using libct_ffdc.a cv 2):::Error

ID: :::Reference ID: :::Template ID: 0:::Details File: :::Location:

RSCT,ServiceIP.C,1.2.5,1434 :::GBLRESRM_IPOFFLINE

IBM.ServiceIP removed address. IBM.ServiceIP 10.67.78.89

v Une commande StartCommand, StopCommand ou MonitorCommand pour une

ressource de classe IBM.Application aboutit à une expiration. Par exemple :

Mar 13 10:25:55 node1 GblResRM[24275]: (Recorded using libct_ffdc.a cv

2):::Error ID: :::Reference ID: :::Template ID: 0:::Details File: :::Location:

RSCT,Application.C,1.2.1,2434 :::GBLRESRM_MONITOR_TIMEOUT

IBM.Application monitor command timed out. Resource name resource1

Astuce : Outre les données consignées par défaut, il est recommandé de consigner

l’exécution des commandes StartCommand et StopCommand pour les

commandes IBM.Application à un emplacement spécifique.

Les scripts fournis avec les règles prédéfinies pour System Automation

consignent toutes les exécutions des commandes StartCommand et

StopCommand pour une ressource dans le journal système par défaut.

L’exemple de sortie ci-dessous affichent les données écrites dans le

journal système lorsqu’une ressource est lancée pour la commande

StartCommand de la règle prédéfinie pour le serveur NFS :

Mar 13 10:34:31 node1 /usr/sbin/rsct/sapolicies/nfsserver/nfsserverctrl-

server:[27230]: NFS server started



Utilisation des journaux d’audit comme source d’information

journal d’audit du démon du maître d’IBM.RecoveryRM

Le démon du maître d’IBM.RecoveryRM gère un journal d’audit dans

lequel il enregistre toutes les requêtes, les réponses aux requêtes liées aux

erreurs, les informations importantes sur la règle en cours et les problèmes

de liaison. Pour afficher le journal, exécutez la commande rpttr sur le

noeud sur lequel le démon du maître d’IBM.RecoveryRM est exécuté :

rpttr /var/ct/<nom_domaine>/log/mc/IBM.RecoveryRM/résumé_trace

Exemple :

L’exemple ci-dessous indique les quatre enregistrements qui apparaissent

dans le journal d’audit pour les quatre événements suivants :

v Un opérateur envoie une requête de démarrage sur un groupe de

ressources "A".

v Cela a pour effet d’envoyer une requête de démarrage sur sa ressource

membre "RA".

v Une requête d’arrêt est envoyée sur le groupe de ressources "A".

v Cela a pour effet d’envoyer une requête d’arrêt sur sa ressource membre

"RA". 12:16:20.168613 T(1096711088) _RCD Online request injected: A/ResGroup/IBM.ResourceGroup

12:16:20.181285 T(1096711088) _RCD Online Request against RA on node saxb02

12:16:35.722675 T(1096711088) _RCD Offline request injected: A/ResGroup/IBM.ResourceGroup

12:16:35.727970 T(1096711088) _RCD Offline Request against RA on node saxb02

journal d’audit du démon GblResRM

Sur chaque noeud, le démon GblResRM tient un journal d’audit dans

lequel il enregistre toutes les exécutions de commande de démarrage,

d’arrêt ou de réinitialisation d’une ressource, chaque démarrage ou arrêt

d’une ressource ServiceIP et chaque modification d’état opérationnel d’une

ressource. Pour afficher ce journal d’audit, exécutez la commande rpttr

localement sur un noeud :

rpttr /var/ct/<domain_name>/log/mc/IBM.GblResRM/trace_summary

Exemple :

L’exemple ci-dessous représente les enregistrements qui apparaissent dans

le journal d’audit lorsqu’une ressource ("appfloata") et une ressource

IBM.ServiceIP ("ip") sont arrêtées.

12:51:08.864796 T(4152898784) _GBD Taking application resource offline: Name=appfloata

Handle=0x6028 0xffff 0xff2f99d1 0x13fbb275 0x1046ca5c 0x98691b60

12:51:10.877355 T(4152603872) _GBD Stop command for application resource "appfloata"

(handle 0x6028 0xffff 0xff2f99d1 0x13fbb275 0x1046ca5c 0x98691b60)

succeeded with exit code 0

12:51:12.888128 T(4150719712) _GBD Monitor detect OpState change for resource Name=appfloata

OldOpState=6 NewOpState=2

Handle=0x6028 0xffff 0xff2f99d1 0x13fbb275 0x1046ca5c 0x98691b60

12:51:12.961970 T(4152898784) _GBD Resource "ip"

(handle 0x6029 0xffff 0xff2f99d1 0x13fbb275 0x1046ca62 0x544260f8):

IP address 10.47.77.97 has been successfully taken offline

on network interface "eth0:0"

12:51:12.962272 T(4152898784) _GBD Monitor reports: No network device flagged UP

with IP address 10.47.77.97.

Taking resource "ip" (handle 0x6029 0xffff 0xff2f99d1

0x13fbb275 0x1046ca62 0x544260f8) offline.

Utilisation de l’historique des commandes

Le fichier /var/ct/IBM.RecoveryRM.log est utilisé pour enregistrer l’historique des

commandes d’IBM Tivoli System Automation. Il contient les entrées de toutes les

commandes de System Automation exécutées localement sur le noeud.



Exemple :

User root invoked "chrg -o Online samadapter-rg on Thu Mar 1 16:51:53 CET 2007

User root invoked "chrg -o Offline samadapter-rg on Thu Mar 1 17:00:14 CET 2007

User root invoked "chrg -o Online samadapter-rg on Thu Mar 1 17:00:20 CET 2007

Utilisation des commandes pour rassembler des informations

Utilisez les commandes décrites dans cette section pour obtenir des informations

détaillées sur les ressources et les groupes de ressources si les informations

fournies dans le journal système sont insuffisantes pour résoudre l’incident. Pour

de meilleurs résultats, vous devez appeler les commandes dans l’ordre dans lequel

elle sont affichées.Pour plus d’informations sur les commandes, consultez le Guide de référence d’IBM

Tivoli System Automation for Multiplatforms.

Les commandes ci-dessous peuvent être utilisées pour rassembler des informations

sur les ressources et les groupes de ressources :

1. lsrg –Ab –V –g <resource-group-name>

La commande lsrg –Ab affiche toutes les informations sur les groupes de

ressources définis dans la règle d’automatisation. Ajoutez l’option -V pour

afficher également les informations d’automatisation les plus importantes, y

compris les états DesiredState, ObservedState et BindingState. Lors de l’analyse

de la sortie, veillez à vérifier si la valeur de l’attribut ConfigValidity indique un

incident de configuration (pour plus d’informations sur l’attribut

ConfigValidity, voir «Vérification dynamique des ressources», à la page 230).

Cet exemple présente les informations affichées pour un groupe de ressources

qui est hors ligne :

node1:~ # lsrg -Ab -V -g rg1

Starting to list resource group information.

Displaying Resource Group information:

All Attributes

For Resource Group "rg1".

Resource Group 1:

Name = rg1

MemberLocation = Collocated

Priority = 0

AllowedNode = ALL


ExcludedList = {}

Subscription = {}

Owner =

Description =

Instruction =

ActivePeerDomain = domain1

OpState = Offline

TopGroup = rg1

MoveStatus = [None]

ConfigValidity =

AutomationDetails[CompoundState] = Satisfaisant

[DesiredState] = Hors ligne

[ObservedState] = Hors ligne

[BindingState] = Non lié

[AutomationState] = Interne

[StartableState] = Oui

[HealthState] = Non disponible



Cet exemple présente les informations affichées pour un groupe de ressources

qui est en ligne :

node1:~ # lsrg -Ab -V -g rg1

Starting to list resource group information.

Displaying Resource Group information:

All Attributes

For Resource Group "rg1".

Resource Group 1:

Name = rg1

MemberLocation = Collocated

Priority = 0

AllowedNode = ALL

NominalState = Online

ExcludedList = {}

Subscription = {}

Owner =

Description =

Instruction =


OpState = En ligne

TopGroup = rg1

MoveStatus = [None]

ConfigValidity =

AutomationDetails[CompoundState] = Satisfaisant

[DesiredState] = En ligne

[ObservedState] = En ligne

[BindingState] = Lié

[AutomationState] = Interne

[StartableState] = Oui

[HealthState] = Non disponible

2. lsrg –m

La commande affiche l’état opérationnel de toutes les ressources gérées.

Exemple :

node1:~ # lsrg –m

Affichage des informations liées aux ressources membre :

Class:Resource:Node[ManagedResource] Mandatory MemberOf OpState WinSource Location

IBM.ServiceIP:ip1 True rg1 Online Nominal node1

IBM.Application:app1 True rg1 Online Nominal node1

IBM.Application:app2 True rg2 Offline

3. lssamctrl

La commande lssamctrl affiche les paramètres globaux d’automatisation, par

exemple, la liste des noeuds exclus et l’attribut RetryCount, qui spécifie le

nombre maximal de tentatives pour la commande StartCommand lorsque la

ressource n’est pas lancée à la première tentative.

Exemple :

node1:~ # lssamctrl

Displaying SAM Control information:

SAMControl:

TimeOut = 60

RetryCount = 3

Automation = Auto

ExcludedNodes = {}


ActiveVersion = [2.2.0.1,Thu Jun 14 08:00:09 2007]

EnablePublisher = Désactivé

TraceLevel = 31

ActivePolicy = []



4. lsrgreq -L {-m}

La commande lsrgreq –L répertorie toutes les requêtes qui ont été émises dans

les groupes de ressources. Ces requêtes sont émises directement à partir de la

ligne de commande à l’aide de la commande rgreq, implicitement à partir de la

console des opérations ou par un gestionnaire d’automatisation de bout en

bout. Dans ce dernier cas, la source de la requête est ‘Automation’.

Exemple :

node1:~ # lsrgreq –L



ResourceGroup Priority Action Source NodeList Active UserID MoveStatus

rg1 low Start Operator {} Actif Aucun

Si la commande est exécutée avec l’option -m, toutes les requêtes dans les

membres du groupe de ressources sont affichées.

Exemple :

node1:~ # lsrgreq -L –m

Affichage des informations de requête de ressources membres :


Member Resource 1:

Class:Resource:Node[ManagedResource] = IBM.Application:app1

Priority = low

Action = Démarrer

Source = Operator


UserID =

5. lssam

La commande lssam affiche des informations résumées concernant les états

opérationnels des ressources gérées, noeud par noeud. Elle fournit des

informations supplémentaires sur les noeuds exclus et les requêtes émises dans

des ressources ou des groupes de ressources.

Exemple :

Dans cer exemple, la commande lssam a été utilisée pour comprendre pourquoi

la ressource 'app1' est hors ligne alors que l’état nominal du groupe de

ressources 'rg1' dont elle fait partie est Online.

node1:~ # lssam

Online IBM.ResourceGroup:rg1 Nominal=Online

|- Online IBM.ServiceIP:ip1

|- Online IBM.ServiceIP:ip1:node1

’- Offline IBM.ServiceIP:ip1:node2 Node=Excluded

’- Offline IBM.Application:app1 Request=Hors ligne

|- Offline IBM.Application:app1:node1

’- Offline IBM.Application:app1:node2 Node=Excluded

Offline IBM.ResourceGroup:rg2 Nominal=Offline

’- Offline IBM.Application:app2

’- Offline IBM.Application:app2:node2 Node=Excluded

La sortie indique pourquoi 'app1' est hors ligne alors que l’état nominal du

groupe de ressources 'rg1' est en ligne (Nominal=En ligne):

v Le noeud 'node2' figure dans la liste des noeuds exclus (Node=Excluded).

C’est pour cette raison que toutes les ressources du noeud, y compris 'app1',

sont hors ligne.

v Une requête hors ligne a été émise dans 'app1' (Request=Hors ligne). C’est

pour cette raison qu’elle est également hors ligne sur le noeud 'node1'.

Notez que les informations les plus importantes sont mises en surbrillance dans

la couleur de la sortie.



6. lsequ –Ab

La commande lsequ –Ab est utilisée pour afficher toutes les ressources du type

"équivalence" qui sont définies dans la règle d’automatisation. Généralement,

les équivalences sont utilisées pour définir les interfaces réseau qui peuvent

être utilisées par les ressources de type IBM.ServiceIP.

Lors de l’analyse de la sortie de la commande, veillez à vérifier que si la valeur

de l’attribut ConfigValidity indique un incident de configuration (pour plus

d’informations sur l’attribut ConfigValidity, voir «Vérification dynamique des

ressources», à la page 230).

Exemple :

node1:~ # lsequ –Ab

Affichage des informations de l’équivalence :

All Attributes

Equivalency 1:

Name = eq1

MemberClass = IBM.NetworkInterface

Resource:Node[Membership] = {eth0:node1,eth0:node2}

SelectString = ""

SelectFromPolicy = ANY

MinimumNecessary = 1

Subscription[Consumer,...] = {[EEZ,All,None]}


Resource:Node[ValidSelectResources] = {eth0:node1,eth0:node2}

Resource:Node[InvalidResources] = {}

ConfigValidity =

AutomationDetails[CompoundState] = Non définie

L’attribut Resource:Node[ValidSelectResources] doit contenir des ressources, en

particulier si un attribut SelectString dynamique est utilisé. Ensuite, l’attribut

OpState des ressources valides doit être vérifié :

# lsrsrc IBM.<MemberClass-attribute-value> Name NodeNameList OpState

7. lsrel –Ab

La commande lsrel –Ab permet d’afficher toutes les relations définies dans la

règle d’automatisation.

Exemple :

node1:~ # lsrel –Ab

Affichage des informations de relations gérées :

All Attributes

Relation gérée 1:

Class:Resource:Node[Source] = IBM.Application:app1

Class:Resource:Node[Target] = {IBM.Application:app2}

Relationship = StartAfter

Conditional = NoCondition

Name = app1_StartAfter_app2


ConfigValidity =

Lors de l’analyse de la sortie, vérifiez que les relations sont terminées (par

exemple, la source et la cible d’une relation doivent être définies) et vérifiez si

la valeur de l’attribut ConfigValidity indique un incident de configuration (pour

plus d’informations sur l’attribut ConfigValidity, voir «Vérification dynamique

des ressources», à la page 230).

8. lsrsrc -A d -c IBM.CHARMControl

Cette commande répertorie l’attribut public de la classe CHARMControl, qui

représente le moteur d’automatisation lui-même. La commande renvoie

actuellement uniquement la valeur de l’attribut d’automatisation, qui est en

règle générale la valeur 1. Lorsque la configuration des groupes de ressources

et des relations est endommagée, ce qui arrive parfois, l’automatisation ne



fonctionne pas correctement. Dans ce cas, la valeur de l’attribut

d’automatisation passe sur 0, indiquant que l’automatisation a été arrêtée.

En arrêtant l’automatisation au lieu de recycler RecoveryRM (comme cela était

le cas dans les versions de System Automation for Multiplatforms antérieures à

la version 2.3), vous pouvez collecter les informations de diagnostic et même

corriger la configuration. Une relation ayant une cible inexistante, par exemple,

est considérée comme une configuration endommagée. Une fois qu’une telle

relation est corrigée ou supprimée, l’automatisation peut être reprise en arrêtant

puis redémarrant le maître RecoveryRM en cours à l’aide des commandes

stopsrc et startsrc.

9. samdiag (pour une analyse approfondie)

La commande samdiag permet d’afficher des informations d’état détaillées

pour une ressource individuelle. La commande peut également être utilisée

pour externaliser toutes les variables internes d’une ressource à partir du

gestionnaire d’automatisation. La commande est très utile pour l’analyse des

incidents, mais elle n’est pas destinée à une utilisation quotidienne car elle

génère un grand volume d’informations.

Exemple :

node1:~ # samdiag -g rg1

Affichage des informations pour ces éléments :

Groupe de ressources "rg1" :

Diagnosis::Resource: rg1/ResGroup/IBM.ResourceGroup

type: CHARM Resource Group

Status -

Observed: Online - Disponible

Desired: Online - Demandé en ligne

(Nominal: Online - Etat nominal : en ligne)

Automation: Idle - Déclencheur CharmBase lié


Binding: Bound - Lié


Resource Based Quorum: Not Supported - Déclencheur CharmBase lié

Members and Memberships:

+---HasMember ---> app1/Fixed/IBM.Application/node1

+---HasMember ---> ip1/Fixed/IBM.ServiceIP/node1

+---bind/HasMember ---> app1/Float/IBM.Application

+---bind/HasMember ---> ip1/Float/IBM.ServiceIP

Group Constraint: Collocated


Flags:

None

Orders:

Outstanding Order: None - Ressource disponible

Dependencies:

Start: Satisfied


Stop: Satisfied

Binding exceptions:

None




+---bind/HasMember ---> app1/Float/IBM.Application

+---bind/HasMember ---> ip1/Float/IBM.ServiceIP"



Pour interroger les informations pour une ressource spécifique, la commande

doit être exécutée de la manière suivante :

samdiag IBM.<resource-class-name>:<resource-name>:<node-name>

Par exemple, pour la ressource ‘app1’ sur le noeud ‘node1’ :

node1:~ # samdiag IBM.Application:app1:node1

Affichage des informations pour ces éléments :

Resource "IBM.Application:app1:node1":

Diagnosis::Resource: app1/Fixed/IBM.Application/node1

type: Fixed Resource

Status -

Reported: Online - En ligne

Observed: Online - En ligne

Desired: Online - Demandé en ligne

(Nominal: Offline - Par défaut : Hors ligne)

Automation: Idle - Inactif - Terminée en ligne


Binding: Bound - Lié


Resource Based Quorum: Not Supported - Déclencheur CharmBase lié

Groups and Aggregates:

<---HasMember ---- rg1/ResGroup/IBM.ResourceGroup

<---bind/HasMember ---- rg1/ResGroup/IBM.ResourceGroup


Flags:

None

Orders:

Outstanding Order: None - Idle - Online completed

Dependencies:

Start: Satisfied

+---RunsOn ---> node1/Node/IBM.PeerNode

Stop: Satisfied

<---HasMember ---- rg1/ResGroup/IBM.ResourceGroup


+---RunsOn ---> node1/Node/IBM.PeerNode


<---bind/HasMember ---- rg1/ResGroup/IBM.ResourceGroup"



Analyse des erreurs

Utilisez les scénarios d’erreur décrits dans cette rubrique pour savoir comment

résoudre efficacement des incidents signalés par System Automation.

Les scénarios d’erreurs traités dans cette section sont les suivants :

v «L’attribut OpState d’une ressource prend la valeur Echec hors ligne»

v «Un groupe de ressource prend la valeur OpState ou Echec hors ligne», à la

page 308

v «Une ressource prend la valeur OpState ou Arrêt en ligne», à la page 309

v «La commande StartCommand est arrivée à expiration», à la page 309

v «La commande StopCommand est arrivée à expiration», à la page 310

v «MonitorCommand est arrivé à expiration», à la page 311

L’attribut OpState d’une ressource prend la valeur Echec hors

ligne

Cette erreur possède trois causes possibles :

Le noeud de la grappe n’est pas en ligne

Si un noeud d’une grappe n’est pas en ligne, toutes les ressources définies

sur le noeud prennent la valeur OpState ou Echec hors ligne. En pareil cas,

l’incident n’est pas lié à la ressource mais au noeud.

L’attribut MonitorCommand de la ressource renvoie le code de retour 3 (==

Echec hors ligne)

Pour savoir si c’est le cas, exécutez manuellement MonitorCommand et

vérifiez le code de retour de la commande. Suivez cette procédure :

1. Extrayez la valeur de l’attribut MonitorCommand pour la ressource :

# lsrsrc –s ‘Name=”<nom_ressource” ‘ IBM.Application Name MonitorCommand

2. Exécutez MonitorCommand.

3. Extrayez le code de retour de MonitorCommand :

# echo $?

Si le code de retour est 3 (Echec hors ligne), recherchez pourquoi l’attribut

MonitorCommand proprement dit renvoie cette valeur et résolvez

l’incident. Une fois que l’incident a été résolu, la ressource doit prendre la

valeur OpState ou Hors ligne.

System Automation a défini la ressource sur ‘Echec hors ligne’ car les tentatives

précédentes de lancement de la ressource ont échoué.

Si MonitorCommand renvoie 2 (Hors ligne) mais que la valeur de l’attribut

OpState de la ressource prend la valeur ‘Echec hors ligne’, cela indique que

l’exécution de la commande StartCommand de cette ressource a été

renvoyée avec une erreur (pas 0 ni une expiration) ou que System

Automation n’a pas pu lancer la ressource dans le nombre de tentatives

défini dans l’attribut RetryCount (reportez-vous à la description de la

commande lssamctrl ci-dessus).

Pour en savoir plus sur l’incident :

1. Recherchez, dans le journal système, les messages indiquant une

expiration de la commande StartCommand pour cette ressource.

2. S’il n’y a pas de message de ce type, recherchez dans les fichiers

journaux appropriés l’application qui se trouve derrière la ressource.

Identifiez et corrigez tous les incidents.

3. Vérifiez la trace d’audit.



Les entrées de la trace d’audit ci-dessous indiquent des incidents dans

le script de lancement :

12:16:35.727970 T(1096711088) _RCD RMC

Rejected online request against RA on node saxb02

12:16:35.727970 T(1096711088) _RCD

Failed Offline Request against RA on node saxb02

Les entrées ci-dessous indiquent que la commande de lancement a

abouti de manière répétée à une expiration :

12:16:35.727970 T(1096711088) _RCD

Maximum timer cancelled for RA on node saxb02

12:16:35.727970 T(1096711088) _RCD

Failed Offline Request against RA on node saxb02

4. Enfin, utilisez la commande ci-dessous pour réinitialiser la ressource à

partir de l’état ‘Echec hors ligne’ :

# resetrsrc –s ‘Name=”<nom_ressource>” && NodeNameList={“nom_noeud”}’ \

IBM.Application

Maintenant la ressource doit prendre la valeur OpState ou Hors ligne et

System Automation relance la ressource si l’état souhaité de la

ressource est En ligne.

Un groupe de ressource prend la valeur OpState ou Echec hors

ligne

Si les ressources d’un groupe de ressources ne sont pas lancées et que la valeur de

l’attribut OpState du groupe de ressources est ‘Echec hors ligne’, le classeur n’a pas

pu trouver une position pour les ressources et de plus, l’attribut BindingState du

groupe de ressources prend la valeur Sacrificed. Vérifiez à l’aide de la commande

suivante :

# lsrg –Ab –V –g <nom_groupe_ressource>

Si l’attribut BindingState prend la valeur Sacrificed :

v Dans la trace d’audit, recherchez les entrées comme dans l’exemple ci-dessous :

9:22:46.520729 T(229390) _RCD Online request injected:

A/ResGroup/IBM.ResourceGroup

09:22:46.522817 T(229390) _RCD RIBME-Hist for <NULL>:

BINDER: Bind A/ResGroup/IBM.ResourceGroup


BINDER: Resource RA/Fixed/IBM.Test/saxb02 hsa no usable options


BINDER: Resource RB/Fixed/IBM.Test/saxb03 hsa no usable options

Resource RB/Fixed/IBM.Test/saxb02 hsa no usable options

Resource RA/Fixed/IBM.Test/saxb03 hsa no usable option

L’exemple présente un groupe de ressources qui est colocalisé mais possède

deux membres fixes sur différents noeuds, ce qui empêche le classeur de

positionner les ressources. Cela revient à n’avoir aucune option utilisable.

v Vérifiez qu’il n’y a pas de ressources dont l’attribut OpState prend la valeur

‘Echec hors ligne’ dans ce groupe.

v Vérifiez l’attribut ExcludedList (lssamctrl) pour les noeuds exclus.

v Vérifiez que toutes les relations de lancement du groupe sont complétées.

v Vérifiez que les équivalences de la règle d’automatisation possèdent toutes des

membres ‘valides’ et en ligne :

# lsequ –Ab

– Vérifiez les attributs Resource:Node[ValidSelectResources] et MemberClass.

Des ressources ‘valides’ doivent être répertoriées.



– Vérifiez l’attribut ‘OpState’ des ressources dans l’équivalence :

# lsrsrc <classe_ressource> Name NodeNameList OpState

où <classe_ressource> représente l’élément MemberClass ci-dessus.

Un attribut OpState égal à 1 indique que la ressource est en ligne. S’il est égal

à 2, cela indique qu’il est hors ligne.

Une ressource prend la valeur OpState ou Arrêt en ligne

Il y a deux raisons possibles pour lesquelles une ressource prend la valeur OpState

ou Arrêt en ligne :

v Dans de rares cas, l’attribut MonitorCommand d’une ressource est renvoyé avec

le code de retour 4 (== Arrêt en ligne). Cela peut être vérifié en exécutant

manuellement l’attribut MonitorCommand et en vérifiant le code de retour de la

commande :

1. Extrayez la valeur de l’attribut MonitorCommand pour cette ressource :

lsrsrc –s ‘Name=”<nom_ressource>” ‘ IBM.Application Name MonitorCommand

2. Exécutez MonitorCommand.

3. Extrayez le code de retour de l’attribut MonitorCommand :

echo $?

Si le code de retour est 4 (Arrêt en ligne), recherchez pourquoi l’attribut

MonitorCommand proprement dit a renvoyé cette valeur. Une fois que

l’incident a été résolu, la ressource doit prendre la valeur OpState ou Hors

ligne.v La seconde raison, qui est la plus probable, pour qu’une ressource ait la valeur

OpState ou Arrêt en ligne (si MonitorCommand renvoie 1 (En ligne) ou 6 (Arrêt

hors ligne), mais que la ressource prend la valeur ‘Arrêt en ligne’ pour OpState)

est que la ressource n’a pas pu être arrêtée auparavant par System Automation

for Multiplatforms et que System Automation for Multiplatforms a finalement

défini la ressource sur Arrêt en ligne. C’est le cas si l’exécution de

StopCommand pour cette ressource et une réinitialisation successive dans cette

ressource n’ont pas réussi à mettre la ressource hors ligne.

Cette erreur ne peut pas être restaurée par System Automation for

Multiplatforms et une intervention manuelle est nécessaire. Après avoir essayé

d’en savoir plus sur les raisons pour lesquelles la ressource ne s’est pas arrêté,

un opérateur doit arrêter la ressource. Lorsque l’attribut OpState de la ressource

est Hors ligne lors de l’exécution suivante de MonitorCommand, System

Automation for Multiplatforms reprend le contrôle de cette ressource et aucune

opération manuelle n’est nécessaire.

Messages d’expiration détectés dans le journal système

La commande StartCommand est arrivée à expiration : Un message est consigné

dans le journal système si l’attribut StartCommand d’une ressource n’est pas

terminé pendant la période définie dans l’attribut StartCommandTimeout de cette

ressource. Il y a deux causes possibles pour cet incident :

v La valeur définie dans l’attribut StartCommandTimeout est trop faible.

Pour vérifiez la valeur de l’attribut :

1. Déterminez le paramètre réel de cet attribut pour cette ressource :

# lsrsrc –s ‘Name=”<nom_ressource>” ‘ IBM.Application Name \

StartCommandTimeout

2. Déterminez le temps nécessaire à l’exécution de StartCommand pour cette

ressource.



Important : Cette opération ne doit jamais être effectuée sur un système de

production en cours d’exécution, mais uniquement au cours de la

maintenance ou sur un autre système de test.

N’oubliez pas que le temps nécessaire à l’exécution de la commande peut

augmenter en fonction de la charge du système.

3. Comparez le paramètre réel de la valeur du délai d’expiration avec le temps

nécessaire à l’exécution de la commande.

4. Si nécessaire, ajustez la valeur de StartCommandTimeout :

# chrsrc -s ’Name=="<resource_name>"’ \

IBM.Application StartCommandTimeout=<new_value_in_seconds>

Cette modification peut être effectuée de manière dynamique.v L’exécution de StartCommand entraîne une situation de blocage car l’une des

instructions dans le script exécuté est bloqué.

– L’investigation nécessite une exécution manuelle de StartCommand.



maintenance.

– Si le script n’est pas terminé (s’il est bloqué), un débogage supplémentaire

peut être activé en ajoutant set –x comme seconde ligne du script

StartCommand.

– Identifiez l’instruction qui entraîne le blocage et corrigez l’incident. Notez que

cette opération dépasse la portée de System Automation.

La commande StopCommand est arrivée à expiration : Un messages est consigné

dans le journal système si la commande StopCommand d’une ressource n’est pas

terminée dans la période définie dans l’attribut StopCommandTimeout de cette

ressource. Il y a deux causes possibles pour cet incident :

v La valeur définie dans l’attribut StopCommandTimeout est trop faible.

Pour vérifier si c’est le cas :

1. Déterminez le paramètre réel de cet attribut pour cette ressource :


StopCommandTimeout

2. Déterminez le temps nécessaire à l’exécution de la commande StopCommand

pour cette ressource.



maintenance ou sur un autre système de test.





4. Ajustez la valeur de SopCommandTimeout si nécessaire :

# chrsrc –c ‘Name=”<nom_ressource>” ‘ IBM.Application \

StopCommandTimeout=<nouvelle_valeur_en_secondes>

Cette modification peut être effectuée de manière dynamique.v L’exécution de la commande StopCommand entraîne une situation de blocage

car l’une des instructions dans le script exécuté est bloquée.

– L’investigation nécessite une exécution manuelle de la commande

StopCommand.





maintenance.



StopCommand.

– Identifiez l’instruction qui entraîne le blocage et corrigez l’incident. Notez que

cette opération dépasse la portée de System Automation.

MonitorCommand est arrivé à expiration : Un message est consigné sur le

système si l’attribut MonitorCommand d’une ressource n’est pas terminé pendant

la période définie dans l’attribut MonitorCommand de cette ressource. Il y a deux

causes possibles pour cet incident :

v La valeur définie dans l’attribut MonitorCommandTimeout est trop faible.

Pour vérifier si c’est le cas :

1. Déterminez les paramètres réels des attributs MonitorCommand pour cette

ressource :


MonitorCommand MonitorCommandTimout MonitorCommandPeriod

2. Déterminez le temps d’exécution de MonitorCommand pour cette ressource

en émettant MonitorCommand directement dans la ligne de commande.





4. Ajustez la valeur de MonitorCommandTimeout si nécessaire :

# chrsrc –c ‘Name=”<nom_ressource>” ‘ IBM.Application \

MonitorCommandTimeout=<nouvelle_valeur_en_secondes>

Cette modification peut être effectuée de façon dynamique, cependant, la

valeur de l’attribut MonitorCommandTimeout doit être inférieure ou égale à

la valeur de l’attribut MonitorCommandPeriod.v L’exécution de MonitorCommand entraîne une situation de blocage car l’une des

instructions dans le script exécuté est bloquée.

– L’investigation nécessite une exécution manuelle de MonitorCommand.



MonitorCommand.

– Déterminez l’instruction qui entraîne le blocage et corrigez l’incident. Notez

que cette opération dépasse la portée de System Automation.



Analyse des incidents

Utilisez cette section pour savoir comment analyser et résoudre les incidents

suivants :

v «Une ressource n’est pas lancée»

v «Un groupe de ressources n’est pas lancé», à la page 313

v «Une ressource ne peut pas être arrêtée», à la page 313

v «Un groupe de ressources ne peut pas être arrêté», à la page 314

v «Aucune reprise en ligne n’a lieu une fois qu’un noeud a été exclu», à la page

314

v «Aucune reprise de ligne n’a lieu après la panne ou le redémarrage d’un noeud», à la page 315

Une ressource n’est pas lancée

Si une ressource n’est pas lancée, suivez cette procédure :

1. Recherchez des messages liés à l’exécution de StartCommand pour cette

ressources dans le journal système, le journal de l’application approprié et la

table de processus (ps –ef). Si StartCommand n’a pas été exécutée du tout,

passez à l’étape 2. Autrement, recherchez pourquoi l’application n’est pas en

ligne.

2. Vérifiez le quorum opérationnel :

# lssrc –ls IBM.RecoveryRM | grep Quorum

Si le quorum opérationnel prend la valeur HAS_QUORUM, passez à l’étape 3.

Si ce n’est pas le cas, recherchez le nombre de noeuds en ligne, à l’aide de la

commande :

# lsrpnode

Le quorum opérationnel nécessite que plus de la moitié des noeuds d’une

grappe soient en ligne ou qu’exactement la moitié des noeuds soient en ligne et

que la condition de départage ait été réservée :

v Si moins de la moitié des noeuds sont en ligne, lancez des noeuds

supplémentaires.

v Si exactement la moitié des noeuds sont en ligne, vérifiez l’attribut de la

condition de départage active :

# lsrsrc –c IBM.PeerNode OpQuorumTieBreaker

Si la valeur de cet attribut est Operator, la condition de départage doit être

définie manuellement :

a. Refusez la propriété de la condition de départage au noeud qui ne doit

pas l’obtenir (si l’autre noeud est toujours en ligne) :

# runact –c IBM.PeerDomain ResolveOpQuorumTie Ownership=0

b. Accordez la propriété de la condition de départage au noeud qui doit

l’obtenir :


Le meilleur moyen de s’assurer que l’incident ne se reproduise pas est de

définir un disque automatique ou une condition de départage réseau, qui

assure que la condition de départage est réservée automatiquement.

A présent, vérifiez le paramètre de la condition de départage active :

# lsrsrc –s ‘Name=”<name-of-active-tie-breaker>”’ IBM.TieBreaker

Vérifiez que le disque est correctement alloué pour une condition de

départage de disque ou que l’adresse IP est disponible pour une condition de



départage réseau. Notez que ces paramètres ne peuvent être modifiés que si

le quorum de configuration est défini, ce qui signifie que plus de la moitié

des noeuds doivent être en ligne.3. Recherchez les requêtes dans la ressource ou le groupe de ressources qui la

contient :

# lsrgreq –L

# lsrgreq –L –m

# lssam

Si une requête d’arrêt a été émise dans la ressource ou le groupe de ressource,

cela explique pourquoi la ressource reste hors ligne. Pour résoudre l’incident,

annulez la requête.

4. Vérifiez que la grappe se trouve en mode d’automatisation et non en mode

manuel, ce qui empêcherait System Automation de lancer des ressources, et que

les noeuds ne figurent pas dans la liste des noeuds exclus car System

Automation ne peut pas lancer de ressources sur des noeuds exclus. Utilisez la

commande suivante :

# lssamctrl

Si la valeur de l’attribut Automation est Manual, la grappe est en mode

manuel. Le mode peut être défini sur Auto à l’aide de la commande :

# samctrl –M F

Si des noeuds figurent sur la liste des noeuds exclus, ils peuvent être

supprimés de la liste à l’aide de la commande :

# samctrl –u d <nom_noeud>

5. Vérifiez les attributs DesiredState, ObservedState et BindingState de la

ressource à l’aide de cette commande pour tous les noeuds :

# samdiag IBM.<resource-class>:<resource-name>[:<node-name>]

Si l’attribut BindingState de la ressource prend la valeur Sacrificed sur tous les

noeuds, cela indique que la classeur n’a pas pu trouver une position pour cette

ressource, qui satisfasse toutes les relations avec les autres ressources. En

général, cet incident se produit lorsqu’une règle d’automatisation est créée ou

modifiée.

Un groupe de ressources n’est pas lancé

Un groupe de ressources est composé d’un certain nombre de ressources. Si aucune

des ressources du groupe n’est lancée, suivez cette procédure :

1. Identifiez les ressources qui doivent être lancées en premier en évaluant les

relations.

2. Examinez pourquoi cette ressource n’est pas lancée en suivant les indications

de la section «Une ressource n’est pas lancée», à la page 312. Assurez-vous de

rechercher les requêtes dans le groupe de ressources et d’évaluer toutes les

relations dans lesquelles le groupe de ressources est défini comme ressource

source. Pour déterminer l’attribut BindingState du groupe de ressource, utilisez

l’une de ces commandes :

# lsrg –Ab –V –g <resource-group-name>

# samdiag –g <resource-group-name>

Une ressource ne peut pas être arrêtée

Si une ressource ne peut pas être arrêtée, suivez cette procédure :

1. Si une ressource n’est pas arrêtée une fois que la commande StopCommand a

été exécutée, System Automation for Multiplatforms émet une opération de



réinitialisation dans la ressource, ce qui déclenche l’exécution de la commande

StopCommand. Si l’attribut OpState de la ressource ne prend toujours pas la

valeur Hors ligne, il prend finalement la valeur Arrêt en ligne. Pour résoudre

cet incident, suivez les indications de «Une ressource prend la valeur OpState

ou Arrêt en ligne», à la page 309.

2. Si la commande StopCommand de la ressource n’a pas été exécutée, recherchez

les requêtes dans la ressource ou le groupe de ressources qui la contient, à

l’aide d’une de ces commandes :

# lsrgreq –L

# lsrgreq –L –m

# lssam

S’il y a une requête de lancement dans la ressource ou le groupe de ressources,

vérifiez si la ressource peut être annulée.

3. Vérifiez que la grappe est en mode d’automatisation et non en mode manuel :

# lssamctrl

Si la valeur de l’attribut Automation est Manual, la grappe est en mode manuel

et System Automation ne peut arrêter aucune ressource. Cette valeur peut être

définie sur Auto à l’aide de la commande :

# samctrl –M F

4. Vérifiez s’il existe des relations à partir des autres ressources, qui empêchent

l’arrêt de cette ressource, en particulier, recherchez les relations suivantes :

v StartAfter (une relation StartAfter maintient la ressource dépendante en

ligne)

v DependsOn et DependsOnAny (les deux relations incluent implicitement une

relation StartAfter, qui maintient la ressource dépendante en ligne)5. Vérifiez s’il y a des relations StopAfter vers d’autres ressources, qui empêchent

l’arrêt de cette ressource (si la ressource cible doit rester en ligne, la ressource

source reste elle aussi en ligne).

Un groupe de ressources ne peut pas être arrêté

Un groupe de ressources est composé d’un certain nombre de ressources. Si aucune

des ressources du groupe n’est arrêtée, suivez cette procédure :

1. Identifiez les ressources qui doivent être arrêtées en premier en évaluant les

relations.

2. Examinez pourquoi cette ressource n’est pas arrêtée en suivant les indications

de la section «Une ressource ne peut pas être arrêtée», à la page 313.

Assurez-vous de rechercher les requêtes dans le groupe de ressources et

d’évaluer toutes les relations dans lesquelles le groupe de ressources est défini

comme ressource cible.

Aucune reprise en ligne n’a lieu une fois qu’un noeud a été exclu

Si aucune reprise en ligne n’a lieu une fois qu’un noeud a été exclu, suivez cette

procédure :

1. Vérifiez que la grappe est en mode d’automatisation et non en mode manuel, et

qu’un noeud, dans lequel les ressources peuvent être lancées, est disponible :

# lssamctrl

Si la valeur de l’attribut Automation est Manual, la grappe est en mode manuel

et System Automation ne peut lancer aucune ressource. Cette valeur peut être

définie sur Auto à l’aide de la commande :

# samctrl –M F



Affichez la liste des noeuds en ligne et comparez-la à la liste des noeuds exclus,

à l’aide de la commande :

# lsrpnode

S’il y a trop de noeuds exclus ou si tous les noeuds de la liste sont exclus, vous

pouvez supprimer les noeuds de la liste à l’aide de la commande suivante :


2. Vérifiez s’il y a des ressources avec la valeur ‘Echec hors ligne’ pour l’attribut

OpState. S’il y en a, suivez les indications de la section «Une ressource n’est

pas lancée», à la page 312.

3. Vérifiez s’il y a des ressources avec la valeur ‘Arrêt en ligne’ pour l’attribut

OpState. S’il y en a, suivez les indications de «Une ressource prend la valeur

OpState ou Arrêt en ligne», à la page 309.

4. Vérifiez l’attribut BindingState du groupe de ressources à lancer en premier :

v Si l’attribut BindingState prend la valeur 'Sacrificed', System Automation n’a

pas pu trouver de position pour les ressources.

Vérifiez les équivalences pour les ressources de membres valides et vérifiez

que l’attribut OpState de ces ressources prend la valeur En ligne, à l’aide de

la commande :

# lsequ –Ab

Vérifiez l’attribut ValidSelectResources.

Vérifiez que les ressources sont en ligne :

# lsrsrc IBM.<classe_équivalence> Name NodeNameList OpState

v Si l’attribut BindingState prend la valeur 'Lié', System Automation n’a pas pu

lancer les ressources. Suivez les indications de la section «Une ressource n’est

pas lancée», à la page 312.5. Recherchez les relations qui ne peuvent pas être complétées sans le noeud

exclu.

Aucune reprise de ligne n’a lieu après la panne ou le

redémarrage d’un noeud

Pour analyser et résoudre l’incident, suivez cette procédure :

1. Vérifiez le quorum opérationnel :

# lssrc –ls IBM.RecoveryRM | grep Quorum

Si le quorum opérationnel prend la valeur HAS_QUORUM, passez à l’étape 2.

Si ce n’est pas le cas, recherchez le nombre de noeuds en ligne, à l’aide de la

commande :

# lsrpnode

Le quorum opérationnel nécessite que plus de la moitié des noeuds d’une

grappe soient en ligne ou qu’exactement la moitié des noeuds soient en ligne et

que la condition de départage ait été réservée :

v Si moins de la moitié des noeuds sont en ligne, lancez des noeuds

supplémentaires.

v Si exactement la moitié des noeuds sont en ligne, vérifiez l’attribut de la

condition de départage active :

# lsrsrc –c IBM.PeerNode OpQuorumTieBreaker



Si la valeur de cet attribut est Operator, la condition de départage doit être

définie manuellement :

a. Refusez la propriété de la condition de départage au noeud qui ne doit

pas l’obtenir (si l’autre noeud est toujours en ligne) :


b. Accordez la propriété de la condition de départage au noeud qui doit

l’obtenir :


Le meilleur moyen de s’assurer que l’incident ne se reproduise pas est de

définir un disque automatique ou une condition de départage réseau, qui

assure que la condition de départage est réservée automatiquement.

A présent, vérifiez le paramètre de la condition de départage active :

# lsrsrc –s ‘Name=”<name-of-active-tie-breaker>”’ IBM.TieBreaker

Vérifiez que le disque est correctement alloué pour une condition de

départage de disque ou que l’adresse IP est disponible pour une condition de

départage réseau. Notez que ces paramètres ne peuvent être modifiés que si

le quorum de configuration est défini, ce qui signifie que plus de la moitié

des noeuds doivent être en ligne.2. Vérifiez que la grappe se trouve en mode d’automatisation et non en mode

manuel, ce qui empêcherait System Automation de lancer des ressources, et que

les noeuds ne figurent pas dans la liste des noeuds exclus car System

Automation ne peut pas lancer de ressources sur des noeuds exclus. Utilisez la

commande suivante :

# lssamctrl

Si la valeur de l’attribut Automation est Manual, la grappe est en mode

manuel. Le mode peut être défini sur Auto à l’aide de la commande :

# samctrl –M F

S’il y a des noeuds dans la liste des noeuds exclus, vous pouvez supprimer les

noeuds de la liste à l’aide de la commande suivante :


3. Selon si le groupe de ressources tout entier ou un de de ses membres n’est pas

lancé, suivez les indications de la section appropriée ci-dessus.

Aucune réinitialisation n’est effectuée une fois le délai imparti

pour l’opération de contrôle de démarrage écoulé

Le temporisateur des opérations est lancé lorsqu’IBM Tivoli System Automation

envoie, pour la première fois, une opération de contrôle de démarrage pour une

ressource. Si la ressource n’atteint pas l’état souhaité (en ligne) dans le délai

imparti et qu’IBM Tivoli System Automation ne parvient pas à lancer une

opération de réinitialisation sur la ressource, procédez comme suit :

1. Arrêtez la grappe à l’aide de la commande stoprpdomain.

2. Redémarrez la grappe à l’aide de la commande startrpdomain.



Autres incidents

Si l’incident est plus probablement lié à un gestionnaire d’automatisation, vous

devez réessayer de réutiliser le gestionnaire d’automatisation (IBM.RecoveryRM)

avant de prendre contact avec le support IBM. Cette opération est possible à l’aide

des commandes suivantes :

1. Découvrez sur quel noeud le démon du maître est exécuté à l’aide de la

commande suivante :

lssrc –ls IBM.RecoveryRM | grep Master

2. Sur le noeud qui exécute le maître, extrayez le PID et détruisez le gestionnaire

d’automatisation :

lssrc –ls IBM.RecoveryRM | grep PID

kill -9 <PID>

Ensuite, un gestionnaire d’automatisation sur un autre noeud dans le domaine

reprend le rôle du maître et prend les décisions liées à l’automatisation. Le

sous-système src relance immédiatement le gestionnaire d’automatisation détruit.

Impossible de configurer la grappe

Pour obtenir des informations sur la manière d’éviter les problèmes de

configuration d’une grappe, voir «Etape 1 : Définition et administration d’une

grappe», à la page 12. Vous y trouverez également des informations sur un

problème classique, comme par exemple ne pas avoir configuré la variable

d’environnement CT_MANAGEMENT_SCOPE.

Suite à la défaillance d’un noeud, le noeud distant ne parvient

plus à accéder aux disques partagés

Si votre noeud AIX ne répond plus et que le noeud distant ne parvient pas à

accéder aux disques partagés (ceux-ci semblent être verrouillés), il se peut que vos

groupes de volumes partagés ne prennent pas en charge la fonction de concurrence

optimisée. Pour obtenir des instructions supplémentaires sur l’activation de la

fonction de concurrence optimisée sur des groupes de volumes partagés sous AIX,

voir Guide d’installation et de configuration d’IBM Tivoli System Automation for

Multiplatforms.

Signalement des incidents

Les incidents pour lesquels il n’existe pas d’informations de dépannage doivent

être signalés sous forme de PRM pour le produit IBM Tivoli System Automation

for Multiplatforms. Lorsque vous signalez l’incident, indiquez les informations

suivantes :

v Les données de débogage et de trace que vous collectez avant la résolution des

incidents (voir «Avant de commencer, collectez les données de débogage et de

trace», à la page 298).

v Une description rapide de la règle d’automatisation qui était active lorsque

l’incident s’est produit. Pour extraire les informations nécessaires, vous pouvez

utiliser la commande sampolicy -s.

v Une description rapide des tâches effectuées avant que l’erreur se soit produite.



Incidents recensés et limitations

La sortie tabulaire est alignée de manière incorrecte pour les

langages multi-octet

La sortie tabulaire des commandes risque de ne pas être correctement alignée si

elle est affichée dans un interpréteur de commandes défini sur un environnement

local destiné aux langages multi-octet. Ceci est dû à un problème lié au langage de

script Perl et qui entraîne un calcul incorrect de la largeur des caractères

multi-octet.



Identification et résolution des incidents liés à la console d’opérations

System Automation for Multiplatforms

Cette section comporte les rubriques suivantes :

v «Aucun domaine d’automatisation n’est affiché dans l’arborescence de la

topologie»

v «Les horodatages affichés dans la console des opérations ne sont pas à l’heure

locale», à la page 323

v «Après le redémarrage d’un noeud, les ressources fixes indiquent des états

d’erreur incorrects dans la console des opérations», à la page 324

v «Affichage des fichiers journaux dans un environnement multilingue», à la page

324

v «Récupération automatique des fichiers enregistrés dans l’éditeur de règles», à la

page 325

Aucun domaine d’automatisation n’est affiché dans

l’arborescence de la topologie

Si un domaine d’automatisation n’est pas visible dans l’arborescence de la

topologie dans la console des opérations, suivez cette procédure :

1. Vérifiez si l’adaptateur est exécuté. A cet effet, émettez la commande

ci-dessous sur l’un des noeuds du domaine :

samadapter status

Si l’adaptateur fonctionne, un message semblable à celui de l’exemple suivant

s’affiche :

samadapter is running on sapb13

Si l’adaptateur est automatisé, un message semblable à celui de l’exemple

suivant s’affiche :

Automated ResourceGroup ’samadapter-rg’ runs on sapb13

Notez le nom du noeud sur lequel l’adaptateur fonctionne (dans cet exemple,

il s’agit de sapb13) et passez à l’étape 4.

_________________________________________________________________

2. Si l’adaptateur ne fonctionne pas, exécutez la commande suivante pour

vérifier si le domaine est en ligne :

lsrpdomain

Un message semblable à celui de l’exemple suivant s’affiche :


domain1 Online 2.5.5.1 No 12347 12348

Si OpState n’est pas défini sur En ligne, démarrez le domaine.

_________________________________________________________________

3. Si le domaine est en ligne, démarrez l’adaptateur en exécutant la commande

suivante :

samadapter start

Une fois que le message est apparu, exécutez à nouveau la commande

suivante :

samadapter status

_________________________________________________________________



4. Si l’adaptateur est exécuté, vérifiez dans la console des opérations si le

domaine s’affiche maintenant dans l’arborescence de la topologie.

_________________________________________________________________

5. Si le domaine n’est toujours pas visible, vous avez besoin des informations de

connexion spécifiées dans la boîte de dialogue de configuration de

l’adaptateur pour résoudre l’incident.

Suivez cette procédure :

a. Lancez la boîte de dialogue de configuration de l’adaptateur de System

Automation for Multiplatforms. A cet effet, émettez la commande

ci-dessous sur l’un des noeuds du domaine :

cfgsamadapter

_________________________________________________________________

b. Sur le premier écran de la boîte de dialogue Configuration, cliquez sur

Configurer.

_________________________________________________________________

c. Ouvrez la page Adaptateur du panneau de configuration et enregistrez les

valeurs qui s’affichent dans les champs ci-dessous pour référence ultérieure

:

v Nom d’hôte ou adresse IP

v Numéro de port de requête

Il s’agit des informations de connexion que l’hôte qui exécute la console

d’opérations utilise pour atteindre l’adaptateur sur n’importe quel noeud

dans le domaine.

_________________________________________________________________

d. Ouvrez la page Hôte utilisant l’adaptateur et enregistrez les valeurs qui

s’affichent dans les champs ci-dessous pour référence ultérieure :

v Nom d’hôte ou adresse IP

v Numéro de port d’événement

Il s’agit des informations de connexion que l’adaptateur utilise sur

n’importe quel noeud dans le domaine pour atteindre l’hôte qui exécute la

console d’opérations

_________________________________________________________________

6. Vérifiez si console d’opérations est accessible à partir de chaque noeud du

domaine. La commande ping <console d’opérations host> constitue un test

simple.

S’il y a un pare-feu entre les noeuds du domaine et l’hôte qui exécute console

d’opérations, vérifiez auprès de l’administrateur réseau si le pare-feu autorise

la connexion entre le noeud (page Adaptateur : Nom d’hôte ou Adresse IP) et

l’hôte qui exécute console d’opérations (page Hôte utilisant l’adaptateur :

Nom d’hôte ou Adresse IP et Numéro de port d’événement).

_________________________________________________________________

7. L’adaptateur détermine si la couche SSL doit être utilisée afin d’établir la

communication avec la console d’opérations. Pour vérifier les paramètres de la

couche SSL de l’adaptateur, lancez la boîte de dialogue Configuration de

l’adaptateur à l’aide de la commande cfgsamadapter. Dans la page Sécurité de

la boîte de dialogue de configuration, vérifiez que les paramètres SSL sont

corrects. Si la case Activer SSL est cochée, la console d’opérations doit

également être sélectionnée pour prendre en charge SSL en mode d’accès

direct.



Vérifiez si c’est le cas en exécutant ./cfgdirect.sh dans le répertoire

<racine_exécution_isc>/AppServer/profiles/default/Tivoli/EEZ. Vérifiez

que les paramètres des touches eez-ssl-truststore, eez-ssl-keystore,

eez-ssl-keystore-password et eez-ssl-keystore-alias utilisés sont identiques à ceux

indiqués dans la page Sécurité de la boîte de dialogue de configuration. Pour

plus d’informations sur la boîte de dialogue de configuration de l’adaptateur,

voir IBM Tivoli System Automation for Multiplatforms Guide d’installation et de

configuration.

Vous ne serez peut-être pas en mesure d’arrêter l’adaptateur à l’aide de la

commande samadapter stop si la clé sélectionnée dans l’adaptateur est

incorrecte ou n’existe pas. Dans ce cas, déterminez l’ID processus à l’aide de

la commande suivante :

ps ax | grep sam.adapter

Ensuite, utilisez la commande ci-dessous pour mettre fin au processus

samdapter :

kill <process-ID>

_________________________________________________________________

8. Sur l’hôte exécutant la console d’opérations, utilisez netstat pour découvrir s’il

écoute les événements sur le port d’événement défini dans Numéro de port

d’événement.

Lorsque le numéro de port d’événement est défini sur 2002 sur un hôte

Windows, netstat affiche un message comme dans l’exemple suivant :

C:\>netstat

Active Connections

Proto Local Address Foreign Address State

...

TCP E2EHOST:2002 sapb13.boeblingen.de.ibm.com:45688 ESTABLISHED

...

Si netstat n’affiche pas d’informations sur le port d’événement défini dans

Numéro de port d’événement, ouvrez le fichier /etc/hosts (sous Windows, le

fichier se trouve dans le répertoire C:\WINDOWS\system32\drivers\etc\hosts)

et vérifiez que l’adresse de bouclage (127.0.0.1) n’est pas liée au nom d’hôte

réel. L’adresse de bouclage ne doit être liée qu’à l’hôte local.

Par exemple, l’entrée dans /etc/hosts peut se présenter de la manière

suivante :

127.0.0.1 localhost.localdomain localhost

_________________________________________________________________

9. Vérifiez que chaque noeud peut être atteint depuis la console d’opérations.

Pour se faire, effectuez un simple test ping en exécutant la commande <nom

d’hôte ou adresse IP>.

Si un pare-feu est installé entre l’hôte exécutant la console d’opérations et les

noeuds du domaine, vérifiez avec l’administrateur de réseau si le pare-feu

autorise l’établissement d’une connexion entre l’hôte exécutant la console

d’opérations (page hôte utilisant l’adaptateur : Nom d’hôte ou adresse IP et

Numéro de port de requête) et le noeud (page Adaptateur : Nom d’hôte ou

adresse IP).

_________________________________________________________________

10. Sur le noeud sur lequel l’adaptateur fonctionne, utilisez netstat pour

découvrir s’il écoute les événements sur le port d’événement défini dans

Numéro de port de requête.



Par exemple, lorsque la valeur du numéro de port de requête est 2001, la

commande netstat renvoie un message semblable à celui-ci sur les hôtes AIX,

Solaris et Linux :

sapb13:~ # netstat -atn |grep 2001

tcp 0 0 9.152.20.113:2001 :::* LISTEN

_________________________________________________________________

11. Lorsque la communication a été correctement établie entre tous les ports (voir

les descriptions ci-dessus), vérifiez que le diffuseur de publications EEZ

fonctionne. Le diffuseur de publications EEZ doit être en cours d’exécution sur

le noeud principal de System Automation for Multiplatforms.

Pour vérifier que le diffuseur de publications fonctionne correctement,


a. Exécutez la commande suivante sur l’un des noeuds du domaine

d’automatisation :

- exécutez lssamctrl

Si le diffuseur de publications est activé, le résultat suivant s’affiche :

safli03:~ # lssamctrl | grep Publisher

EnablePublisher = EEZ

b. Exécutez la commande suivante sur le noeud principal de System

Automation for Multiplatforms (pour connaitre le noeud principal, voir

«Administration du Recovery Resource Manager», à la page 18) :

ps ax

Vous devez recevoir la sortie comme dans l’exemple ci-dessous :

safli04:~ # ps ax | grep Publisher

25756 ? S 0:00 TECPublisher /etc/opt/IBM/tsamp/sam/cfg/EEZPublisher.conf EEZ




c. Exécutez la commande suivante sur le noeud d’IBM Tivoli System

Automation for Multiplatforms sur lequel l’adaptateur fonctionne :

netstat

Vous devez recevoir la sortie comme dans l’exemple ci-dessous :

Safli03:~ # netstat -atn | grep 5539

tcp 0 0 :::5539 :::* LISTEN

tcp 0 0 9.152.21.82:5539 9.152.20.92:32793 ESTABLISHED

Si le diffuseur de publications ne fonctionne pas ou si la communication sur le

port 5539 ne peut pas être établie, procédez comme suit :

a. Vérifiez que le fichier /etc/Tivoli/tec/samPublisher.conf comporte

l’entrée suivante :

#--SAMP-EEZ:

Publisher=EEZ

LibraryPath=libTECPublisher.so

ConfigPath=/etc/opt/IBM/tsamp/sam/cfg/EEZPublisher.conf

b. Vérifiez que le fichier /etc/opt/IBM/tsamp/sam/cfg/EEZPublisher.conf

comporte les entrées suivantes :

ServerLocation=adresse_ip_adaptateur

ServerPort=5539

La valeur spécifiée pour adresse_ip_adaptateur dans le fichier doit

correspondre à la valeur fournie sur l’onglet Adaptateur de la boîte de

dialogue configuration de l’adaptateur._________________________________________________________________



12. Si le domaine ne s’affiche toujours pas dans la console des opérations, prenez

contact avec le support IBM et indiquez les informations de diagnostic :

a. Sur chaque noeud dans le domaine, recherchez où résident les fichiers de

trace. Vous pouvez rechercher les fichiers de trace dans le sous-répertoire

/eez/logs de Tivoli Common Directory. Pour trouver le chemin d’accès

vers Tivoli Common Directory, exécutez la commande suivante :

cat /etc/ibm/tivoli/common/cfg/log.properties

La commande renvoie le chemin vers Tivoli Common Directory, par

exemple :

Rép_commun_Tivoli=/var/ibm/tivoli/common

Ceci signifie que vous trouverez les fichiers de trace dans le répertoire

suivant :

/var/ibm/tivoli/common/eez/logs

b. Utilisez tar pour compacter tous les fichiers dans le répertoire et envoyer

l’archive au service de support logiciel IBM.

_________________________________________________________________

Les horodatages affichés dans la console des opérations ne

sont pas à l’heure locale

Les valeurs qui s’affichent dans les horodatages dans la console des opérations

sont dérivées des paramètres de fuseau horaire du système d’exploitation, sur

lequel est installé le serveur Integrated Solutions Console. Si les horodatages ne

sont pas à l’heure locale, vérifiez les paramètres de fuseau horaire dans votre

serveur Integrated Solutions Console.

Généralement, vous utilisez les outils de configuration fournis avec le système

d’exploitation pour modifier les paramètres d’heure :

v Sur AIX, vous pouvez configurer les paramètres de fuseau horaire à l’aide de

l’outil de configuration système smit ou smitty. Utilisez les options du menu

System environments —> Change/Show Date and Time pour ajuster les

paramètres de fuseau horaire.

v Sur SuSE Linux, vous pouvez utiliser les outils de configuration système yast2

ou yast. Utilisez les options de menu System -> Date and Time (SLES-9) ou

System —> Set Time Zone (SLES-8).

v Sur les distributions Red Hat Linux, vous pouvez utilisez les outils de

configuration redhat-config-time ou system-config-time.

v Sur Windows, vous pouvez régler les paramètres de date et heure à l’aide de

l’option Date et heure dans le Panneau de configuration.

Vous serez peut-être amené à redémarrer votre système d’exploitation pour valider

les modifications effectuées.

Astuce :

AIX, Solaris, Linux : si vous avez modifié les paramètres de fuseau

horaire conformément aux instructions ci-dessus, mais que les valeurs

affichées dans les horodatages de la console d’opérations restent

incorrectes, vous pouvez définir la variable d’environnement TZ afin de

résoudre le problème.



Exemples :

v Pour définir le fuseau horaire pour Berlin en Allemagne, utilisez la

commande suivante :

export TZ="Europe/Berlin"

v Pour définir l’heure sur le fuseau horaire de la côte est des Etats-Unis,

utilisez la commande suivante :

export TZ="US/Eastern"

Après le redémarrage d’un noeud, les ressources fixes

indiquent des états d’erreur incorrects dans la console des

opérations

Les ressources fixes qui s’affichent dans la console des opérations indiquent des

états d’erreur incorrects après le redémarrage d’un noeud. Les états corrects sont

affichés une fois que les ressources sont lancées sur ce noeud.

Affichage des fichiers journaux dans un environnement

multilingue

Vous pouvez utiliser l’argument client.encoding.override=UTF-8 JVM pour

configurer un serveur d’applications au format de transformation UCS. Ce format

permet au serveur d’applications de prendre en charge la plupart des codages de

caractères. Vous pouvez indiquer cet argument si vous devez utiliser le codage

multilingue dans la console d’administration. Cela peut être le cas si plusieurs

domaines d’automatisation sont exécutés avec des codages autres que ceux

spécifiés dans le navigateur client.

Par exemple, si vous voulez utiliser la console d’opérations SA pour afficher le

journal d’un domaine d’automatisation de premier niveau exécuté dans un

environnement allemand, mais que vous avez défini la langue par défaut de votre

navigateur sur Japonais, certains caractères spéciaux allemands pouvant apparaître

dans le journal ne s’afficheront pas correctement dans le navigateur en langue

japonaise.

Pour configurer un serveur d’applications pour le format de transformation UCS,


1. Dans la console d’administration, cliquez sur Serveurs > Serveurs

d’applications et sélectionnez le serveur que vous voulez activer pour le format

de transformation UCS.

2. Puis, sous Infrastructure du serveur, cliquez sur Java et gestion de processus >

Définition des processus > Machine virtuelle Java.

3. Indiquez -Dclient.encoding.override=UTF-8 pour Arguments JVM génériques

et cliquez sur OK. Si cet argument est indiqué, le format de transformation

UCS est utilisé à la place du codage de caractères qui serait utilisé si l’option

autoRequestEncoding était activée.

4. Cliquez sur Enregistrer pour sauvegarder vos modifications.

5. Redémarrez le serveur d’applications.



Récupération automatique des fichiers enregistrés dans

l’éditeur de règles

Lorsque vous travaillez sur des règles d’automatisation, l’éditeur de règles

enregistre automatiquement votre travail en cours sur le système sur lequel la

console d’opérations est installée. Il crée ainsi des fichiers temporaires dans le

répertoire utilisé par le système d’exploitation pour le stockage des fichiers

temporaires. Par exemple :

Windows : C:\Documents and Settings\Administrateur\Local settings\Temp

(défini par la variable d’environnement %TEMP%).

AIX, Linux, z/OS : /tmp

Le nom des fichiers de sauvegarde automatique est défini comme suit :

.eezautosave_<horodatage>_<ID_utilisateur_ISC>_<ID_session_ISC>_<ID interne>.xml

Si la session expire ou qu’un autre problème survient dans l’éditeur de règles, vous

pouvez récupérer votre travail en utilisant le contenu des fichiers de sauvegarde

automatique.

1. Transférez le fichier de sauvegarde le plus récent sur votre ordinateur local, par

exemple en utilisant le protocole ftp.

2. Ouvrez l’éditeur de règles et sélectionnez Modifier une règle existante.

Chargez la règle enregistrée sur l’ordinateur local.

Remarques :

1. Sur les plateformes Unix, ces fichiers sont masqués au moyen d’un “.”. Pour les

voir, exécutez la commande ls –a.

2. Tous les fichiers enregistrés automatiquement sont supprimés lors de l’arrêt de

WebSphere Application Server.



Annexe C. Utilisation d’IBM Support Assistant

IBM Support Assistant est une application autonome gratuite que vous pouvez

installer sur n’importe quel poste de travail. IBM Support Assistant permet de

gagner du temps lors des recherches de ressources relatives aux produits, au

support et à la formation et permet de recueillir des informations d’assistance

lorsque vous devez ouvrir un ETR (problem management record) ou ETR

(Electronic Tracking Record), que vous pouvez ensuite utiliser pour suivre le

problème.

L’application peut être enrichie en installant les modules de plug-in spécifiques au

produit pour les produits IBM utilisés. Le plug-in spécialement conçu pour Tivoli

System Automation for Multiplatforms vous offre les ressources suivantes :

v Liens de support

v Liens éducatifs

v Possibilité de soumettre des rapports de gestion d’incident

Installation d’IBM Support Assistant et du plug-in Tivoli System


Pour installer IBM Support Assistant V3.0, procédez comme suit :

v Accédez au site Web d’IBM Support Assistant :

www.ibm.com/software/support/isa/

v Téléchargez le module d’installation correspondant à votre plateforme. Vous

devrez vous connecter avec un ID utilisateur IBM et un mot de passe (par

exemple, un ID utilisateur MySupport ou developerWorks). Si vous ne possédez

pas d’ID utilisateur IBM, vous pouvez exécuter la procédure d’enregistrement

gratuite en vue d’en obtenir un.

v Décompressez le module d’installation dans un répertoire temporaire.

v Suivez les instructions indiquées dans le guide d’installation et de résolution des

incidents, accompagnant le module d’installation, pour installer l’application IBM

Support Assistant.

Pour installer le plug-in d’Tivoli System Automation for Multiplatforms, procédez

comme suit :

1. Démarrez IBM Support Assistant. IBM Support Assistant est une application

Web qui s’affiche dans le navigateur Web configuré par défaut par le système.

2. Cliquez sur l’onglet Updater dans l’application IBM Support Assistant.

3. Cliquez sur l’onglet New Products and Tools. Les modules de plug-in sont

présentés par famille de produits.

4. Sélectionnez Tivoli > Tivoli Tivoli System Automation for Multiplatforms.

5. Sélectionnez les fonctions à installer, puis cliquez sur Installer. Veuillez

consulter les informations sur la licence et les instructions d’utilisation.

6. Redémarrez IBM Support Assistant.


Annexe D. Remarques

Le présent document peut contenir des informations ou des références concernant

certains produits, logiciels ou services dans ce pays.

Le présent document peut contenir des informations ou des références concernant

certains produits, logiciels ou services IBM non annoncés dans certains autres pays.

Pour plus de détails, référez-vous aux documents d’annonce disponibles dans votre

pays, ou adressez-vous à votre partenaire commercial IBM. Toute référence à un

produit, logiciel ou service IBM n’implique pas que seul ce produit, logiciel ou

service puisse être utilisé. Tout autre élément fonctionnellement équivalent peut

être utilisé, s’il n’enfreint aucun droit d’IBM. Il est de la responsabilité de

l’utilisateur d’évaluer et de vérifier lui-même les installations et applications

réalisées avec des produits, logiciels ou services non expressément référencés par

IBM.

IBM peut détenir des brevets ou des demandes de brevet couvrant les produits

mentionnés dans le présent document. La remise de ce document ne vous donne

aucun droit de licence sur ces brevets ou demandes de brevet. Si vous désirez

recevoir des informations concernant l’acquisition de licences, veuillez en faire la

demande par écrit à l’adresse suivante :

IBM Director of Licensing

IBM Corporation

North Castle Drive

Armonk, NY 10504-1785

U.S.A.

Pour le Canada, veuillez adresser votre courrier à :

IBM Director of Commercial Relations

IBM Canada Ltd.

3600 Steeles Avenue East

Markham, Ontario

L3R 9Z7

Canada

Les licenciés souhaitant obtenir des informations permettant : (i) l’échange des

données entre des logiciels créés de façon indépendante et d’autres logiciels (dont

celui-ci), et (ii) l’utilisation mutuelle des données ainsi échangées, doivent adresser

leur demande à :

IBM Corporation

Mail Station P300

2455 South Road

Poughkeepsie New York 12601-5400

U.S.A.

Ces informations peuvent être soumises à des conditions particulières, prévoyant

notamment le paiement d’une redevance.

Le logiciel sous licence décrit dans ce document et tous les éléments sous licence

disponibles s’y rapportant sont fournis par IBM conformément aux dispositions de

l’ICA, des Conditions internationales d’utilisation des logiciels IBM ou de tout

autre accord équivalent.


Les informations sur les licences concernant les produits utilisant un jeu de

caractères double octet peuvent être obtenues par écrit à l’adresse suivante :

IBM World Trade Asia Corporation

Licensing

2-31 Roppongi 3-chome, Minato-ku

Tokyo 106, Japan

Le paragraphe suivant ne s’applique ni au Royaume-Uni, ni dans aucun pays dans

lequel il serait contraire aux lois locales. LE PRESENT DOCUMENT EST LIVRE

EN L’ETAT SANS AUCUNE GARANTIE EXPLICITE OU IMPLICITE. IBM

DECLINE NOTAMMENT TOUTE RESPONSABILITE RELATIVE A CES

INFORMATIONS EN CAS DE CONTREFACON AINSI QU’EN CAS DE DEFAUT

D’APTITUDE A L’EXECUTION D’UN TRAVAIL DONNE. Certaines juridictions

n’autorisent pas l’exclusion des garanties implicites, auquel cas l’exclusion

ci-dessus ne vous sera pas applicable.

Le présent document peut contenir des inexactitudes ou des coquilles. Ce

document est mis à jour périodiquement. Chaque nouvelle édition inclut les mises

à jour. IBM peut, à tout moment et sans préavis, modifier les produits et logiciels

décrits dans ce document.

Les références à des sites Web non IBM sont fournies à titre d’information

uniquement et n’impliquent en aucun cas une adhésion aux données qu’ils

contiennent. Les éléments figurant sur ces sites Web ne font pas partie des

éléments du présent produit IBM et l’utilisation de ces sites relève de votre seule

responsabilité.

Si vous visualisez ces informations en ligne, il se peut que les photographies et

illustrations en couleur n’apparaissent pas à l’écran.

Marques

v IBM, le logo IBM, ibm.com, AIX, DB2, developerWorks, HACMP, NetView,

Tivoli, Tivoli Enterprise, Tivoli Enterprise Console, WebSphere et z/OS sont des

marques d’International Business Machines Corporation aux Etats-Unis et/ou

dans certains autres pays. IBM Redbooks et le logo IBM Redbooks sont des

marques d’IBM.

v Adobe, Acrobat, Portable Document Format (PDF) et PostScript sont des

marques d’Adobe Systems Incorporated aux Etats-Unis et/ou dans certains

autres pays.

v Microsoft, Windows et le logo Windows sont des marques de Microsoft

Corporation aux Etats-Unis et/ou dans certains autres pays.

v Java ainsi que tous les logos et toutes les marques incluant Java sont des

marques de Sun Microsystems, Inc. aux Etats-Unis et/ou dans certains autres

pays.

v Linux est une marque de Linus Torvalds aux Etats-Unis et/ou dans certains

autres pays.

v Red Hat et l’ensemble des marques associées à Red Hat sont des marques de

Red Hat, Inc., aux Etats-Unis et/ou dans certains autres pays.

v UNIX est une marque de The Open Group aux Etats-Unis et/ou dans certains

pays.

v Les autres noms de sociétés, de produits et de services peuvent appartenir à des

tiers.


Index

Caractères

spéciaux(EIF) fonction d’intégration

d’événements 223

Aà propos de ce manuel xiii

adresse e-mail xvi

ajout d’une ressource membre àgroupes de ressources 48

arborescence des topologiesColonne Etat 130

Colonne Situé(e) ici 130

masquage des domaines 129

présentation 129

Arrêtressources 141

arrêt d’un groupe de ressources 50

association d’interfaces 292

attribut AutomationDetails 45

attribut Condition 61

attribut d’équivalence MemberClass 55

attribut d’équivalence Membership 55

attribut d’équivalence

SelectFromPolicy 55

attribut d’équivalence SelectString 55

attribut de groupe de ressources

AllowedNode 39


MemberLocation 40


Name 41


NominalState 41


OpState 44


Priorité 42


TopGroup 44

attribut de la relation

DependsOnAny 76

attribut dynamique 30

AutomationDetails 38

ConfigValidity 230

définition 4

MoveStatus 46, 209

OpQuorumState 173

OpState 33, 38, 235, 252

TopGroup 38

attribut ExcludedList 43

attribut Mandatory de la classe

ManagedResource 47

attribut MemberOf 47

attribut Name 60

attribut NodeNameList de la

ressource 31

attribut OpState de ressource 33

attribut persistant 30

AllowedNode 39

Condition 61

définition 3

ExcludedList 43

ForceOpState 257

IPAddress 253

Mandatory 47

MemberClass 55

MemberLocation 40

MemberOf 47

membres 55

modification des valeurs 50

MonitorCommand 237

MonitorCommandPeriod 238

MonitorCommandTimeout 238

Name 41, 60, 235, 252, 257

NetMask 253

NodeNameList 31, 235, 252, 257

NominalState 41

OpQuorumOverride 186

Priorité 42

ProtectionMode 172, 240, 253

Relationship 61

ResourceType 32, 236, 253, 257

RunCommandsSync 238

SelectFromPolicy 55

SelectString 55

Source 60

StartCommand 236

StartCommandTimeout 238

StopCommand 236

StopCommandTimeout 238

Target 61

TimeToStart 258

TimeToStop 258

UserName 240

WriteToSyslog 258

Attribut ProtectionMode 172

attribut Relationship 61

attribut ResourceType de ressource 32

attribut SelectFromPolicy 31

attribut Source 60

attribut Target 61

attributsattributs de ressource, description

de 3, 30

dynamique 30

dynamiques 4

NodeNameList 31

SelectFromPolicy 31

utilisé par IBM.Application 235

utilisé par IBM.ServiceIP 252

utilisé par IBM.Test 256

utilisé par les équivalences 55

utilisé par les groupes de

ressources 38

utilisé par les relations gérées 60

utilisé par les ressources 31

variables 3, 30

automatisationévénements affectant

l’automatisation 97

paramètres 190

Cclasse de ressources

définition 4

classes de ressourcesdéfinition 29

IBM.Application 233

IBM.ServiceIP 249

IBM.Test 256

IBM.TieBreaker 174

classeurdéfinition 93

coffre d’accréditationIntegrated Solutions Console 144

commande addrgmbr 48

commande addrpnode 15

commande chequ 57

commande chrg 50

commande chrgmbr 50

Commande d’arrêtdélai d’attente de mise hors

ligne 101

SA_RESET 101

StopCommandTimeout 101

commande lsequ 57

commande lsrel 90

commande lsrg 49

commande lsrpnode 17

commande mkequ 56

commande mkrel 90

commande mkrg 48

commande mkrpdomain 12

commande preprpnode 12

commande rmequ 57

commande rmrel 91

commande rmrg 51

commande rmrgmbr 51

commande rmrpdomain 17

commande rmrpnode 17

commande samctrl 232

commande samdiag 220

commande startrpdomain 12, 17

commande startrpnode 15

commande stoprpdomain 16

commande stoprpnode 16, 17

commandesaddrgmbr 48

addrpnode 15

chequ 57

chrg 50

chrgmbr 50

lsequ 57

lsrel 90

lsrg 49

lsrpnode 17

mkequ 56


commandes (suite)mkrel 90

mkrg 48

mkrpdomain 12

preprpnode 12

rmequ 57

rmrel 91

rmrg 51

rmrgmbr 51

rmrpdomain 17

rmrpnode 17

samctrl 232

samdiag 220

startrpdomain 12, 17

startrpnode 15

stoprpdomain 16

stoprpnode 16, 17

comportement d’arrêt de la relation

Dépendant de 72

comportement d’arrêt forcé de la relation

Dépendant de 70

comportement de démarrage de la

relation Dépendant de 70

condition de départage 6, 174, 184

Condition de départage du réseau 184

condition de départage Fail 174

condition de départage Operator 174

condition IFNotOffline 80

condition IFNotOnline 80

condition IFOffline 80

condition IFOnline 80

conditions de départagetypes 169

conditions pour les relations

d’emplacement 80

configuration d’un réseau hautement

disponible 283

ConfigValidityattribut dynamique 230

résolution des incidents 301, 304

vérification des ressources 230

connaissances préalables à la lecture de

ce manuel xiii

connexionIntegrated Solutions Console 122

console d’opérationsarborescence des topologies 129

couche 127

gestion des requêtes 141

gestion des ressources 140

présentation 126

section des ressources 131

Zone d’information 136

contrôleur des ressources système 245

créationéquivalence 56

groupes de ressources 27, 48

relations 90

création d’un groupe de ressources 48

Ddéfinition

grappe 12

règles d’automatisation 25

relations 28

ressources RSCT 20

Démarrageressources 141

démarrage d’un groupe de

ressources 50

démon du maître de RecoveryRMjournal d’audit 300

Dépendant deattribut de relation 70

comportement d’arrêt 72

comportement de démarrage 70

modèles de comportement 70

détails de la requêteaffichage 143

diagnostic de ressources 220

données d’identification utilisateurgestion 144

Eéditeur de règles

couche 146

énumérationgroupes de ressources 49

relations 90

équivalencesattributs utilisés par 55

création 56

description de 4, 53

listage 57

modification 57

règles d’utilisation 54

suppression 57

établissement d’une équivalence 56

établissement d’une liste de noeuds pourmembres de groupes de

ressources 48

états des ressourcescycle d’état 117

présentation 296

états du classeur 296

événements affectant l’automatisation 97

Ffichier baroc 223

fichier de configuration du diffuseur de

publications 224

fichier de configuration EIF de TEC 225

fonction d’intégration d’événements de

Tivoli (EIF) 223

fonction du diffuseur de publications de

TEC 223

GGblResRM

journal d’audit 300

GDPS/PPRSMultiplatform Resiliency 228

gestion des règles d’automatisation 192

gestionnaire d’automatisationclasseur 296

module logique 296

présentation 295

gestionnaire de ressourcesclasse de ressources

IBM.Application 233

classe de ressources

IBM.ServiceIP 249

classe de ressources IBM.Test 256

Global Resource RM 233

test resource manager 256

gestionnaire de ressources de réponse à

événement (ERRRM) 232

grappesajout de noeuds dans 15

définition et administration 12

mise hors ligne 16

suppression 17

groupe de ressourcesajout d’une ressource membre à 48

arrêt 50

attributs utilisés par 38

création 48

démarrage 50

déplacement 208

description de 36

énumération (y compris de ses

membres ressource) 49

établissement d’une liste de noeuds

pour 48

états 41

modification des attributs de 50

permettant la mise en ligne 97

suppression 51

groupes d’utilisateurspour IBM Tivoli System Automation

for Multiplatforms 120

IIBM.Application 235

IBM.Equivalencyclasse de ressources 141

IBM.RecoveryRM 18

IBM.ServiceIP 285

attributs 252

définition 249

IBM.TestRM 256

Integrated Solutions Consolecoffre d’accréditation 144

connexion 122

interface d’événement TEC (Tivoli

Enterprise Console) 222

interface d’événement Tivoli Enterprise

Console (TEC) 222

interfaces de réseaudétection des incidents 285

ISO 9000 xv

Jjournal d’audit

démon du maître de

RecoveryRM 300

GblResRM 300


Llistage

équivalence 57

liste de noeuds, établissement 48

liste de noeuds d’une ressource 31

liste des requêtesaffichage 143

Mmarques 330

membres de groupes de ressourcesmodification des attributs de 50

méthodes de protection des ressourcessous Windows 169

mise en évidence xiv

modificationattributs des membres de groupes de

ressources 50

équivalence 57

un groupe de ressources 50

MoveStatus, attribut dynamique 46, 209

Nnavigateurs Web

configuration 121

niveau de sécurité 121

paramètres de sécurité 122

pris en charge 121

Navigateurs Webfenêtres de navigateur multiple 122

JavaScript 121

netmon.cfemplacement 285

noeudsarrêt d’un noeud 232

mise hors ligne 16

redémarrage d’un noeud 232

suppression d’une grappe 17

Oobtenir des informations du

quorum 173

PPage Général

présentation 137

page informations supplémentairesprésentation 138

Page Règlesprésentation 138

page relationsprésentation 138

paramètre ExcludedNodes 190

paramètre ResourceRestartTimeout 190

paramètresautomatisation 190

ExcludedNodes 190

ResourceRestartTimeout 190

TimeOut et RetryCount 188

paramètres TimeOut et RetryCount 188

passerelles, par défautnetmon.cf 285

public de ce manuel xiii

publication des attributs internes de


Multiplatforms 227

Qquorum

condition de départage 169

majorité de noeuds 167

obtenir des informations 173

quorum de configuration 5, 168

quorum opérationnel 5, 168

quorum de configuration 5, 168

quorum opérationnel 5, 168

Rrecovery resource manager

(IBM.RecoveryRM) 18

règleenregistrement et modification d’une

règle 192

gestion des règles

d’automatisation 192

modification d’une règle 192

remplacement d’une règle 192

règlesautomatisation basée sur des règles 1

exemples de règles 1

relationDépendant de 70

DependsOnAny 76

relation affinity 86

relation AntiAffinity 87

relation AntiCollocated 84

relation collocated 81

relation ForcedDownBy 77

relation IsStartable 88

relation StartAfter 62

relation StartAfter/IfPossible 65

relation StopAfter 68

relationsAffinity 86

AntiAffinity 87

AntiCollocated 84

Collocated 81

création 90

énumération 90

ForcedDownBy 77

IsStartable 88

relation location 79

StartAfter 62

StopAfter 68

suppression 91

relations géréesattributs utilisés par 60

description de 59

relations location 79

conditionsIfNotOffline 80

IFNotOnline 80

IFOffline 80

IFOnline 80

requêteannulation 144

RequêteActif 141

arrêt 141

requête d’arrêt 141

requête de démarrage 141

requêtesdémarrage et arrêt de groupes de

ressources et de ressources 200

traitement d’une requête de

déplacement 209

réseau hautement disponible 283

résolution des incidentscollecte d’informations 298

commande ctsnap 298

commandes 301

ConfigValidity 301, 304

journal d’audit 300

journal système 298

utilisation des journaux d’audit 300

ressourcecritique 167, 172

description d’une classe de

ressources 4

description de 3, 29

description de la classe de

ressources 29

description des attributs de

ressource 3, 30

état nominal 4, 34

vérification 230

ressource critique 167

ressource d’agrégat 234

ressource géréedescription de 4, 30

ressourcesattributs utilisés par 31

ressources constituantes 234

ressources fixesdéfinition 32

ressources flottantesdéfinition 32

ressources ombréesutilisation 210

rôles d’accèspour IBM Tivoli System Automation

for Multiplatforms 120

Ssection des ressources

présentation 131

suppressiond’une ressource membre d’un groupe

de ressources 51

équivalence 57

groupes de ressources 51

relations 91

suppression d’une ressource membregroupes de ressources 51

System Automation for Multiplatformsconfiguration d’un réseau hautement

disponible 283

mise en route 11

Index 333

TTEC (Tivoli Enterprise Console) 222

test resource manager 256

Tivoli Enterprise Console (TEC) 222

transitions d’état pour un groupe de

ressources 44

type de ressource 32

Uutilisation de ce guide xiii

Vvérification des ressources

ConfigValidity 230

VMTIMEBOMB 171

XxDR

distributions Linux prises en

charge 229

présentation 228

ZZone d’information

présentation 136


��

Numéro de programme : 5724-M00

SC11-6299-00

Guide d|mJadministration et...

Documents

Transcript of Guide d|mJadministration et...