IBM Tivoli System Automation Composant de base - Guide d'utilisation

IBM Tivoli System Automation Composant de base - Guide d'utilisation IBM Tivoli System Automation Composant de base - Guide d'utilisation

from as400bks.rochester.ibm.com More from this publisher

30.06.2013 Views

IBM Tivoli System Automation for Multiplatforms Composant de base - Guide d’utilisation Version 2.1 SC11-2269-00

IBM Tivoli System Automation for Multiplatforms

Composant de base - Guide d’utilisation

Version 2.1

SC11-2269-00

IBM Tivoli System Automation for Multiplatforms

Composant de base - Guide d’utilisation

Version 2.1

SC11-2269-00

Important

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

section «Notices», à la page 209.

Remarque

Certaines captures d’écrans de ce manuel ne sont pas disponibles en français à la date d’impression.

Première édition - novembre 2005

Réf. US : SC33-8210-04

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

Table des matières

Avis aux lecteurs canadiens . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

A propos de la bibliothèque IBM Tivoli System Automation for Multiplatforms . . . . . . . . xi

Présentation du manuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

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

Utilisation de ce guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

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

Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

ISO 9000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Rubriques connexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Comment obtenir des publications . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

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

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 . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Mouvement automatique des applications . . . . . . . . . . . . . . . . . . . . . . . 1

Regroupement de ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Termes d’IBM Tivoli System Automation . . . . . . . . . . . . . . . . . . . . . . . . . 2

Grappe / domaine homologue . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Ressource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Attribut de ressource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Classe de ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Groupe de ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Ressource gérée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Etat nominal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Equivalence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Quorum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Condition de départage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Composants d’IBM Tivoli System Automation . . . . . . . . . . . . . . . . . . . . . . . 4

Introduction aux gestionnaires de ressources intégrés dans IBM Tivoli System Automation . . . . . 4

Console des opérations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Adaptateur d’automatisation de bout en bout . . . . . . . . . . . . . . . . . . . . . . 6

Chapitre 2. Installation du composant de base d’IBM Tivoli System Automation . . . . . . . . 7

Planification de l’installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Coexistence avec d’autres produits : . . . . . . . . . . . . . . . . . . . . . . . . . 7

Contenu du CD : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

CD / archives pour le composant de base . . . . . . . . . . . . . . . . . . . . . . . 7

Envoi électronique d’IBM Tivoli System Automation . . . . . . . . . . . . . . . . . . . 8

Plateformes prises en charge : . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Interfaces de réseau prises en charge . . . . . . . . . . . . . . . . . . . . . . . . 9

Préparation de l’installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Conditions préalables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Configurations initiales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Installation et mise à jour du composant de base d’IBM Tivoli System Automation for Multiplatforms 12

Installation du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Installation de la Licence du produit . . . . . . . . . . . . . . . . . . . . . . . . . 12

Langues prises en charge par IBM Tivoli System Automation . . . . . . . . . . . . . . . 13

Migration du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Désinstallation d’IBM Tivoli System Automation . . . . . . . . . . . . . . . . . . . . . 16

Service d’installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Désinstallation du service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Chapitre 3. Mise en route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

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

Création d’une grappe à deux noeuds . . . . . . . . . . . . . . . . . . . . . . . . 20

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

Mise hors ligne d’une grappe entière ou de noeuds individuels . . . . . . . . . . . . . . . 22

Suppression des noeuds d’une grappe ou suppression d’une grappe entière . . . . . . . . . 23

Administration du Recovery Resource Manager . . . . . . . . . . . . . . . . . . . . 23

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

Création de la ressource d’application apache1 . . . . . . . . . . . . . . . . . . . . 25

Création de l’adresse IP de la ressource apache1IP . . . . . . . . . . . . . . . . . . . 26

Création d’une équivalence pour les cartes réseau . . . . . . . . . . . . . . . . . . . 26

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

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

Définition de relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Mise en ligne d’un groupe de ressources . . . . . . . . . . . . . . . . . . . . . . . 28

Chapitre 4. 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 ? . . . . . . . . . . . . . . . . . . . . . . . 29

Quelle est la différence entre des attributs persistants et des 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Attribut OpState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Etat nominal de la ressource . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Chapitre 5. Utilisation des groupes de ressources . . . . . . . . . . . . . . . . . . . 35

Qu’est ce qu’un groupe de ressources ? . . . . . . . . . . . . . . . . . . . . . . . . 35

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

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

Attribut AllowedNode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Attribut MemberLocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Attribut Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Attribut NominalState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Attribut Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Attribut ExcludedList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

ActivePeerDomain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

InfoLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Attribut OpState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Attribut TopGroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Attribut AutomationDetails . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

MoveStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

ConfigValidity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Attributs utilisés pour les membres de groupes de ressources . . . . . . . . . . . . . . . . 43

Attribut Mandatory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

iv IBM Tivoli System Automation Composant de base - Guide d’utilisation

Attribut MemberOf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Définition et administration d’un groupe de ressources . . . . . . . . . . . . . . . . . . . 44

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

Ajout d’une ressource membre dans un groupe de ressources . . . . . . . . . . . . . . . 45

Enumération d’un groupe de ressources ou de ses ressources membres . . . . . . . . . . . 45

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

Modification des attributs d’un groupe de ressources . . . . . . . . . . . . . . . . . . 46

Modification des attributs des membres d’un groupe de ressources . . . . . . . . . . . . . 47

Suppression d’une ressource membre d’un groupe de ressources . . . . . . . . . . . . . 47

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

Chapitre 6. Utilisation des équivalences . . . . . . . . . . . . . . . . . . . . . . . 49

Qu’est ce qu’une équivalence ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

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

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

Attribut MemberClass (classe de membres) . . . . . . . . . . . . . . . . . . . . . . 50

Attribut Membership (appartenance) . . . . . . . . . . . . . . . . . . . . . . . . 50

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

Attribut SelectFromPolicy (sélection à partir d’une règle) . . . . . . . . . . . . . . . . . 50

Attributs utilisés par les membres des équivalences . . . . . . . . . . . . . . . . . . . . 51

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

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

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

Modification d’une équivalence . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Suppression d’une équivalence . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Chapitre 7. Utilisation des relations gérées . . . . . . . . . . . . . . . . . . . . . . 53

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

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

Attribut Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Attribut Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Attribut Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Attribut Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Attribut Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

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

Relation StartAfter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Relation StopAfter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Relation DependsOn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Relation DependsOnAny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Relation ForcedDownBy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Relations Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Conditions IfOnline, IfOffline, IfNotOnline et IfNotOffline . . . . . . . . . . . . . . . . . 67

Règles relatives à l’utilisation des relations Location . . . . . . . . . . . . . . . . . . . 67

Relation Collocated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Relation AntiCollocated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Relation Affinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Relation IsStartable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

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

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

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

Modification d’une relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Suppression d’une relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Chapitre 8. Traitement des informations système par IBM Tivoli System Automation . . . . . . 77

Définition de la relation d’emplacement : algorithme de liaison . . . . . . . . . . . . . . . . 77

Evénements permettant la mise en ligne d’un groupe de ressources . . . . . . . . . . . . . . 79

Table des matières v

Modèles de comportement d’IBM Tivoli System Automation for Multiplatforms . . . . . . . . . . 81

Considérations générales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Réaction d’IBM Tivoli System Automation aux modifications éventuelles d’état opérationnel d’une

ressource en ligne sur un noeud . . . . . . . . . . . . . . . . . . . . . . . . . 83

Composition de l’état opérationnel d’un groupe de ressources par l’automatisation de système . . . 85

Réactions de l’automatisation de système aux modifications d’état opérationnel d’une ressource

démarrée ou arrêtée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Chapitre 9. Utilisation de la console des opérations . . . . . . . . . . . . . . . . . . 93

Vue d’ensemble - Qu’est-ce que la console des opérations ? . . . . . . . . . . . . . . . . 93

Installation de la console des opérations . . . . . . . . . . . . . . . . . . . . . . . . 94

Espace disque requis pour l’installation de la console des opérations . . . . . . . . . . . . 95

CD/archives pour la console des opérations . . . . . . . . . . . . . . . . . . . . . . 95

Procédure d’installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Configuration de l’adaptateur d’automatisation de bout en bout pour utiliser la console des opérations 102

Configuration de la console des opérations pour être utilisée en mode d’accès direct . . . . . . . 103

Planification de la configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Exécution du script de configuration pour la console des opérations en mode d’accès direct . . . 103

Démarrage et arrêt d’Integrated Solutions Console . . . . . . . . . . . . . . . . . . . . 104

Démarrage et arrêt des serveurs sous Windows . . . . . . . . . . . . . . . . . . . . 104

Démarrage et arrêt de la console des opérations sur AIX et Linux . . . . . . . . . . . . . 105

Création et autorisation d’utilisateurs et de groupes . . . . . . . . . . . . . . . . . . . 106

Création d’utilisateurs et de groupes dans Integrated Solutions Console . . . . . . . . . . . 106

Attribution des droits d’accès aux groupes d’utilisateurs dans la console Integrated Solutions

Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Modification et suppression des utilisateurs et des groupes . . . . . . . . . . . . . . . . 110

Connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Etapes à suivre pour accéder à la console des opérations . . . . . . . . . . . . . . . . 111

Comprendre les couches de la console des opérations . . . . . . . . . . . . . . . . . . 113

Ce qu’il faut savoir sur l’arborescence des topologies . . . . . . . . . . . . . . . . . . 113

Présentation de l’arborescence des ressources . . . . . . . . . . . . . . . . . . . . . 115

Eléments affichés dans la colonne Etat . . . . . . . . . . . . . . . . . . . . . . . 115

Limitation de l’étendue de l’arborescence des ressources . . . . . . . . . . . . . . . . 116

Présentation de la zone d’information . . . . . . . . . . . . . . . . . . . . . . . . . 116

Page Général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Page Règles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Page Informations supplémentaires . . . . . . . . . . . . . . . . . . . . . . . . 118

Page Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Gestion des ressources à l’aide de la console des opérations . . . . . . . . . . . . . . . . 118

Gestion des requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Chapitre 10. Protection de vos ressources – support réalisé par Quorum . . . . . . . . . 123

Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Quorum de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Quorum opérationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Fonction VMTIMEBOMB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Configuration des ressources critiques . . . . . . . . . . . . . . . . . . . . . . . 126

Pour obtenir des informations du quorum . . . . . . . . . . . . . . . . . . . . . . 127

Configuration et gestion d’une condition de départage . . . . . . . . . . . . . . . . . 128

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

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

Remplacement du quorum opérationnel . . . . . . . . . . . . . . . . . . . . . . . 137

vi IBM Tivoli System Automation Composant de base - Guide d’utilisation

Chapitre 11. Configuration d’un réseau hautement disponible . . . . . . . . . . . . . . 139

Considérations à propos de la planification de la configuration d’un réseau hautement disponible 139

Qu’est-ce qui rend une infrastructure de réseau hautement disponible difficile ? . . . . . . . . 139

Que faut-il clarifier avant de planifier un réseau hautement disponible . . . . . . . . . . . . 140

Installation d’une grappe à un ou deux noeuds : détection des échecs de l’interface réseau . . . . 140

Grappe à deux noeuds, chaque noeud possède une interface Ethernet . . . . . . . . . . . . 141

Grappe à deux noeuds, chaque noeud possède deux interfaces réseau . . . . . . . . . . . . 142

Deux réseaux séparés physiquement, déplacement de ServiceIP entre les noeuds . . . . . . . 143

Trois réseaux logiques dans un réseau physique, déplacement de ServiceIP entre les interfaces

réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

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

Interface de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Chapitre 12. Contrôle et administration d’IBM Tivoli System Automation . . . . . . . . . . 149

Configuration de l’adaptateur d’automatisation de bout en bout de System Automation for

Multiplatforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Configuration de l’adaptateur d’automatisation de bout en bout . . . . . . . . . . . . . . 152

Réplication des fichiers de configuration de l’adaptateur d’automatisation de bout en bout dans

d’autres noeuds du domaine . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Définition des règles d’automatisation de bout en bout de l’adaptateur . . . . . . . . . . . 161

Suppression des règles d’automatisation de bout en bout de l’adaptateur . . . . . . . . . . 161

Remarque pour les administrateurs . . . . . . . . . . . . . . . . . . . . . . . . 161

Contrôle d’IBM Tivoli System Automation . . . . . . . . . . . . . . . . . . . . . . . 162

TimeOut et RetryCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Opérations d’arrêt (Stop) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Automatisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

ExcludedNodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

ResourceRestartTimeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Gestion des règles d’automatisation . . . . . . . . . . . . . . . . . . . . . . . . . 165

Utilisation de la commande sampolicy pour gérer les règles . . . . . . . . . . . . . . . 165

Utilisation de la commande samcfg pour gérer des règles . . . . . . . . . . . . . . . . 165

Utilisation des requêtes de démarrage et d’arrêt des groupes de ressources et des ressources . . . 167

Portée d’une requête d’arrêt et de démarrage . . . . . . . . . . . . . . . . . . . . 167

Source d’une requête de démarrage ou d’arrêt . . . . . . . . . . . . . . . . . . . . 167

Priorité d’une requête de démarrage et d’arrêt . . . . . . . . . . . . . . . . . . . . 167

Déplacement des groupes de ressources à l’aide de la commande rgreq . . . . . . . . . . . 168

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

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

Déplacement et relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Etablissement de diagnostics de ressources IBM Tivoli System Automation . . . . . . . . . . . 169

Utilisation de l’interface d’événement TEC d’IBM Tivoli System Automation . . . . . . . . . . . 171

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

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

Envoi d’événements vers la TEC . . . . . . . . . . . . . . . . . . . . . . . . . 171

Activation de la fonction de diffuseur de publications de la TEC . . . . . . . . . . . . . . 172

Configuration d’un nouveau paramètre de lieu pour les messages d’événement de la TEC . . . . 175

Publication d’attributs internes d’IBM Tivoli System Automation dans l’infrastructure RSCT . . . . 176

Activation d’IBM Tivoli System Automation for GDPS/PPRC Multiplatform Resiliency for zSeries 176

Personnalisation de Tivoli Enterprise Integration Facility (EIF) . . . . . . . . . . . . . . . 177

Installation de l’interface Cpint . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Détection de présence xDR . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Démon de relevé des erreurs de l’unité de stockage à accès direct (DASD) . . . . . . . . . 178

Arrêt d’une grappe/d’un noeud xDR à des fins de maintenance . . . . . . . . . . . . . . 178

Vérification dynamique des ressources . . . . . . . . . . . . . . . . . . . . . . . . 179

IBM Tivoli System Automation - Conseils et astuces . . . . . . . . . . . . . . . . . . . 180

Table des matières vii

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

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

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

Chapitre 13. Gestionnaires de ressources fournis par IBM Tivoli System Automation . . . . . 181

Utilisation du Global Resource Manager (gestionnaire de ressources globales) . . . . . . . . . 181

Qu’est ce que la classe de ressources IBM.Application ? . . . . . . . . . . . . . . . . 181

Qu’est ce qu’une classe de ressources IBM.ServiceIP ? . . . . . . . . . . . . . . . . . 193

Utilisation du Test Resource Manager . . . . . . . . . . . . . . . . . . . . . . . . 198

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

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

Exemple : Création d’une ressource de test et manipulation de son état opérationnel (OpState) 200

Annexe. Identification et résolution des incidents . . . . . . . . . . . . . . . . . . . 201

Fichiers de diagnostic du gestionnaire de ressources . . . . . . . . . . . . . . . . . . . 201

Restauration des incidents du RMC et du gestionnaire de ressources . . . . . . . . . . . . . 201

Utilisation de la commande ctsnap . . . . . . . . . . . . . . . . . . . . . . . . . 202

Commandes contrôlées par le contrôleur des ressources système . . . . . . . . . . . . . 202

Un domaine System Automation for Multiplatforms est absent de l’arborescence . . . . . . . . . 203

Modification des paramètres de fuseau horaire pour la console des opérations . . . . . . . . . 206

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Marques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

viii IBM Tivoli System Automation Composant de base - Guide 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.

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.

x IBM Tivoli System Automation Composant de base - Guide d’utilisation

A propos de la bibliothèque IBM Tivoli System Automation for

Multiplatforms

IBM Tivoli System Automation for Multiplatforms comprend deux composants décrits dans deux manuels

distincts :

v Le composant de base qui englobe la partie relative à l’automatisation d’IBM Tivoli System Automation

for Multiplatforms et de l’adaptateur d’automatisation de bout en bout. La composant de base est décrit

dans les manuels IBM Tivoli System Automation for Multiplatforms Composant de base - Guide

d’utilisation, SC11-2269, et IBM Tivoli System Automation for Multiplatforms Base Component

Reference, SC33-8212.

v Le composant de la gestion de bout en bout de l’automatisation est décrit dans le manuel IBM Tivoli

System Automation for Multiplatforms : Gestion de l’automatisation de bout en bout - Guide d’utilisation

et de référence, SC11-2270.

Présentation du manuel

Ce manuel contient les informations nécessaires à l’implémentation de la fonction d’autorétablissement

des règles d’IBM Tivoli System Automation for Multiplatforms sous xSeries, zSeries, iSeries, pSeries et

AIX. Les éditions précédentes de ce manuel s’appelaient IBM Tivoli System Automation for Multiplatforms

Guide d’utilisation et de référence. A partir de cette édition, les données de référence telles que les

descriptions de commandes et les messages ont été placés dans un nouveau manuel intitulé IBM Tivoli

System Automation for Multiplatforms Base Component Reference.

A qui s’adresse ce manuel ?

Ce guide est destiné aux administrateurs système qui souhaitent utiliser les fonctions d’automatisation et

de reprise en ligne du composant de base d’IBM Tivoli System Automation for Multiplatforms.

Le composant de bout en bout d’IBM Tivoli System Automation for Multiplatforms est décrit dans le manuel

IBM Tivoli System Automation for Multiplatforms Gestion de l’automatisation de bout en bout,

SC11-2270-00.

Utilisation de ce guide

Ce guide contient toutes les informations nécessaires à la compréhension et à l’utilisation du produit IBM

Tivoli System Automation for Multiplatforms (IBM Tivoli System Automation).

v Le chapitre 1 est une introduction à IBM Tivoli System Automation. Il donne un aperçu d’IBM Tivoli

System Automation, introduit les composants et explique les termes techniques utilisés dans ce guide.

v Le chapitre 2 fournit des informations sur l’installation, la mise à niveau, la migration et la désinstallation

d’composant de base d’IBM Tivoli System Automation.

v Le chapitre 3 aborde les processus d’administration des grappes et des noeuds et de définition des

règles d’automatisation.

v Le chapitre 4 traite des attributs standard d’IBM Tivoli System Automation.

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

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

v Le chapitre 7 aborde les processus de création et d’utilisation des relations gérées.

v Le chapitre 8 aborde le processus de traitement des informations systèmes d’IBM Tivoli System

Automation.

v Le chapitre 9 aborde l’utilisation de la console des opérations.

v Le chapitre 10 aborde le processus de protection de vos ressources par IBM Tivoli System Automation.

v Le chapitre 11 aborde la configuration d’un réseau hautement disponible.

v Le chapitre 12 aborde les processus de contrôle et d’administration d’IBM Tivoli System Automation.

v Le chapitre 13 aborde les gestionnaires de ressources fournis par IBM Tivoli System Automation.

v L’annexe fournit des informations utiles pour l’identification et la résolution des incidents.

Où trouver des informations supplémentaires ?

Page d’accueil d’IBM Tivoli System Automation

IBM Tivoli System Automation possède une page d’accueil sur le Web qui contient des informations

récentes et des services ainsi que d’autres éléments d’intérêt pour les utilisateurs d’IBM Tivoli

System Automation.

Consultez la page d’accueil d’IBM Tivoli System Automation à l’adresse :

http://www-3.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.

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 :

Figure 1.

xii IBM Tivoli System Automation Composant de base - Guide d’utilisation

ISO 9000

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

Rubriques connexes

Les documents RSCT suivants sont inclus dans votre CD-ROM IBM Tivoli System Automation :

v IBM Reliable Scalable Cluster Technology for Linux, Administration Guide, SA22-7892.

v IBM Reliable Scalable Cluster Technology for Linux, Technical Reference, SA22-7893.

v IBM Reliable Scalable Cluster Technology for Linux, Messages, GA22-7894.

v A Practical Guide for Resource Monitoring and Control (RMC) , SG24-6615

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

http://www-1.ibm.com/servers/eserver/clusters/library/

Vous devrez peut-être vous reporter au Redpaper d’IBM :

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

Il est disponible sur le site Web suivant :

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

Comment obtenir des publications

Les publications IBM Tivoli System Automation sont également disponibles (valides ou moment de la

parution) sur les sites Web :

http://www-1.ibm.com/servers/eserver/clusters/library/

http://www-1.ibm.com/servers/eserver/zseries/software/sa/

http://www.tivoli.com/support/public/Prodman/public_manuals/td/TD_PROD_LIST.html

Comment nous contacter par e-mail

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

eservdoc@de.ibm.com

A propos de la bibliothèque IBM Tivoli System Automation for Multiplatforms xiii

xiv IBM Tivoli System Automation Composant de base - Guide d’utilisation

Chapitre 1. Introduction

Généralités

IBM Tivoli System Automation gère la disponibilité des applications exécutées sous Linux et AIX ou des

grappes de serveurs xSeries, zSeries, iSeries, pSeries. Il intègre les fonctions suivantes :

Haute disponibilité et moniteur de ressources

IBM Tivoli System Automation fournit un environnement à haute disponibilité. Un système à haute

disponibilité est un système toujours disponible intégrant une infrastructure d’autodépannage pour

empêcher les temps d’arrêt dus aux incidents système, de se produire. Une 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. IBM Tivoli System Automation offre un ordinateur à haute disponibilité

en mettant en place un système de détection rapide des indisponibilités et une gestion des connaissances

sophistiquée relatives aux composants des applications et à leurs relations. Il offre une reprise sur incident

rapide et cohérente des ressources qui ont échoué et de toutes les applications en place ou installées sur

un autre système d’une grappe Linux sans intervention de l’opérateur. Par conséquent, les opérateurs

n’ont plus à intervenir aussi fréquemment, ni à se souvenir des composants d’applications et des relations,

ce qui réduit le nombre possible d’erreurs.

Automatisation basée sur des règles

IBM Tivoli System Automation permet de configurer des systèmes à haute disponibilité grâce à l’utilisation

de règles définissant les relations entre plusieurs composants. Ces règles concernent les applications

existantes et ne requièrent qu’un nombre restreint de modifications. Lorsque les relations sont établies,

IBM Tivoli System Automation 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.

Des exemples de règles d’administration concernant IBM Tivoli System Automation sont disponibles. Vous

pouvez les télécharger à partir de la page suivanteftp://ftp.software.ibm.com/software/tivoli/products/sysauto-linux/.

Reprise sur incident automatique

IBM Tivoli System Automation effectue de manière constante et rapide un redémarrage automatique des

échecs de ressources ou de toutes les applications en place ou sur un autre système d’une grappe Linux

ou AIX. Ceci permet de remédier efficacement aux indisponibilités du système.

Mouvement automatique des applications

IBM Tivoli System Automation gère les relations entre les grappes de serveurs concernant les ressources

dont il est responsable. 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 IBM Tivoli System Automation. 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

Les ressources peuvent être regroupées ensemble dans IBM Tivoli System Automation. Une fois

regroupées, toutes les relations parmi les membres du groupe peuvent être établies, telles que les

relations d’emplacement, les relations de démarrage ou d’arrêt, et ainsi de suite. Lorsque le configuration

est terminée, les opérations peuvent être exécutées sur un groupe tout entier en tant qu’entité unique.

Ceci évite aux opérateurs de devoir mémoriser les composants de l’application et des relations, réduisant

ainsi le risque d’erreur.

Introduction

Termes d’IBM Tivoli System Automation

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

Automation.

Grappe / domaine homologue

Le groupe de systèmes hôte sur lequel IBM Tivoli System Automation gère les ressources, porte le nom

de grappe. Une grappe peut contenir un ou plusieurs système(s) ou noeud(s). Tout au long de ce manuel,

on utilise le terme de ’domaine homologue’ pour se référer à une grappe. Les deux termes sont

interchangeables. IBM Tivoli System Automation 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 IBM Tivoli

System Automation. Ces ressources peuvent soit être définies manuellement par l’administrateur à l’aide

de la commande mkrsrc (make resource) ou par le biais de la fonctionnalité de ’collecte’ de l’infrastructure

de la grappe, par laquelle les ressources sont automatiquement détectées et prêtes à l’emploi. Toutes les

ressources sont contrôlées par le biais de gestionnaires de ressources comme indiqué dans «Introduction

aux gestionnaires de ressources intégrés dans IBM Tivoli System Automation», à la page 4. 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 ressources : les ressources fixes et les ressources flottantes.

Ressource fixe

Une ressource fixe est une ressource qui ne possède qu’une seule instance à l’intérieur 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 flottante est une ressource qui peut fonctionner sur plusieurs noeuds à l’intérieur

d’une grappe. Vous pouvez trouver une définition détaillée d’une ressource flottante dans «Attribut

ResourceType», à la page 31.

Attribut de ressource

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

de ressource : les attributs persistants et les attributs dynamiques.

Attributs persistants

Les attributs de l’adresse IP susmentionnée (l’adresse IP en elle-même ainsi que le masque

réseau) sont des exemples d’attributs persistants – ils décrivent les caractéristiques persistantes

d’une ressource. Alors que vous pouvez modifier l’adresse IP et le masque réseau, ces

caractéristiques, en revanche, sont généralement stables et immuables.

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. Concernant les

applications, la classe des ressources peut définir des caractéristiques ayant trait à l’identification, telles

que le nom de l’application, et les caractéristiques variables telles que le fonctionnement ou non de ladite

application. Par conséquent, chaque ressource à l’intérieur d’une classe peut être notée par ses

2 IBM Tivoli System Automation Composant de base - Guide d’utilisation

caractéristiques à un moment donné. Les classes de ressources sont gérées par plusieurs gestionnaires

de ressources – voir «Introduction aux gestionnaires de ressources intégrés dans IBM Tivoli System

Automation», à la page 4.

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 d’IBM Tivoli System Automation. Les groupes de ressources

peuvent aussi être imbriqués, autrement dit, les applications peuvent être fractionnées en plusieurs

groupes de ressources, ces derniers étant déjà impliqués dans un autre groupe de ressources de niveau

supérieur. Vous pouvez aussi définir les groupes de ressources pour que leurs membres puissent se

trouver sur des systèmes différents au sein de la grappe.

Ressource gérée

Une ressource gérée est une ressource qui a été définie dans IBM Tivoli System Automation. Pour

effectuer cette opération, la ressource est ajoutée à un groupe de ressources. A partir de cet instant, elle

peut être gérée par IBM Tivoli System Automation.

Etat nominal

L’état nominal d’une ressource indique à IBM Tivoli System Automation si les ressources du groupe

doivent être En ligne ou Hors ligne à ce stade. Par conséquent, si vous définissez l’état nominal sur ″Hors

ligne″, vous souhaitez qu’IBM Tivoli System Automation 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 40.

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 réseau passe hors ligne, IBM Tivoli System Automation sélectionne un

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

Relations

IBM Tivoli System Automation 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, and ForcedDownBy

pour réaliser cette opération. Par exemple, vous ne pouvez démarrer une ressource qu’après en avoir

démarré une autre préalablement. Vous pouvez définir ceci en utilisant la relation de StartAfter.

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. IBM Tivoli System

Automation 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. Dans

le passé, ce comportement aurait été défini au moyen de scripts très complexes. IBM Tivoli System

Automation permet aujourd’hui d’utiliser une relation d’emplacement qui simplifie la définition de règles

d’administration pour l’administrateur.

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

Introduction

Chapitre 1. Introduction 3

Introduction

– 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

Ce quorum détermine le moment où les modifications de configuration à l’intérieur 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 124 pour obtenir davantage d’informations.

Quorum opérationnel

Ce quorum est utilisé pour s’assurer que les ressources peuvent être activées en toute sécurité

sans créer de conflits avec d’autres ressources. En cas de fractionnement de la grappe, les

ressources ne peuvent être démarrées que dans la sous-grappe contenant le plus de noeuds ou

ayant été soumise à une condition de départage. Voir «Quorum opérationnel», à la page 124 pour

plus d’informations à ce sujet.

Condition de départage

Si une grappe a été fractionnée en sous-grappe avec un nombre égal de noeuds, la condition de

départage sert à déterminer quelle sous-grappe aura un quorum opérationnel.

Composants d’IBM Tivoli System Automation

Reliable Scalable Cluster Technology, ou RSCT, est une application logicielle intégrée d’IBM Tivoli System

Automation. RSCT est un progiciel offrant un environnement groupé complet pour les systèmes AIX et

Linux. RSCT permet au système d’être toujours disponible, évolutif et facile à utiliser.

RSCT met trois composants de base, ou couche, de fonctionnalité à votre disposition :

v RMC (Resource Monitoring and Control), est une solution de configuration, gestion et contrôle des

ressources dans un domaine homologue.

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

v HATS (High Availability Topology Services), 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.

Introduction aux gestionnaires de ressources intégrés dans IBM Tivoli

System Automation

Les classes de ressources sont gérées par plusieurs gestionnaires de ressources, en fonction du type de

ressource qu’il doit gérer. Un gestionnaire de ressources est une couche logicielle située entre une

ressource et une classe de gestionnaire de ressources.

Les gestionnaires de ressources suivants sont intégrés dans IBM Tivoli System Automation:

Gestionnaire de ressources de reprise sur incident (IBM.RecoveryRM)

Ce gestionnaire de ressources sert de moteur de décision pour IBM Tivoli System Automation. Lorsque les

règles définissant les disponibilités des ressources et les relations sont définies, cette information est

envoyée au Gestionnaire de ressources de reprise sur incident. Ce Gestionnaire de ressources fonctionne

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

4 IBM Tivoli System Automation Composant de base - Guide d’utilisation

désignée comme document maître. Le document maître traite les informations de contrôle à partir des

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 181.

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 193.

Configuration du Gestionnaire de ressources

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 de ressources de réponse d’événement

Le Gestionnaire de ressource de réponse d’événement (IBM.ERRM) offre la possibilité de surveiller les

conditions au sein d’une grappe afin que le système RMC puisse réagir d’une certaine manière.

Gestionnaire de ressources de test

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 de ressources n’est

opérationnel qu’en mode domaine homologue et fournit la classe de ressources IBM.Test. Le gestionnaire

de ressources de Test ne contrôle pas les ressources réelles. Une description détaillée du Gestionnaire

des ressources de Test se trouve dans Chapitre 13, «Gestionnaires de ressources fournis par IBM Tivoli

System Automation», à la page 181.

figure 2, à la page 6 affiche un diagramme des composants décrits précédemment.

Introduction

Chapitre 1. Introduction 5

Introduction

Figure 2. Vue d’ensemble de l’architecture IBM Tivoli System Automation

Console des opérations

La console des opérations est une interface graphique d’utilisateur basée sur un navigateur. console des

opérations permet de surveiller et de gérer les ressources prises en charge par IBM Tivoli System

Automation. Il s’effectue en mode dit ″d’accès direct″.

Pour le composant de gestion d’automatisation de bout en bout d’IBM Tivoli System Automation for

Multiplatforms, deux modes supplémentaires sont fournis :

v Mode d’automatisation de bout en bout.

v Mode d’automatisation du premier niveau.

Ces modes sont décrits dans le Gestion de l’automatisation de bout en bout : Guide d’utilisation et de

référence.

Adaptateur d’automatisation de bout en bout

Dans le composant de base d’IBM Tivoli System Automation l’adaptateur d’automatisation de bout en bout

est utilisé pour faire fonctionner des ressources automatisées directement à partir d’une console de

commande des opérations. Voir «Configuration de l’adaptateur d’automatisation de bout en bout de

System Automation for Multiplatforms», à la page 149 pour en savoir plus sur adaptateur d’automatisation

de bout en bout.

Dans le composant de gestion d’automatisation de bout en bout d’IBM Tivoli System Automation

l’adaptateur d’automatisation de bout en bout est utilisé pour automatiser le fonctionnement des

ressources dans les domaines d’automatisation de premier niveau.

6 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Chapitre 2. Installation du composant de base d’IBM Tivoli

System Automation

Ce chapitre décrit les procédures d’installation, configuration et migration d’un composant de base d’IBM

Tivoli System Automation, dans les sections suivantes :

v «Planification de l’installation».

v «Préparation de l’installation», à la page 9

v «Installation et mise à jour du composant de base d’IBM Tivoli System Automation for Multiplatforms», à

la page 12.

v «Désinstallation d’IBM Tivoli System Automation», à la page 16

Il décrit aussi les étapes de sauvegarde des règles d’administration d’automatisation en cours dans la

section :

v «Service d’installation», à la page 17

Planification de l’installation

Coexistence avec d’autres produits :

IBM Tivoli System Automation peut coexister avec General Parallel File System (GPFS) ou Cluster

Systems Management (CSM). Si ces produits sont déjà installés, IBM Tivoli System Automation partage

des modules avec ces produits. Vous pouvez vérifier si l’un de ces logiciels est déjà installé à l’aide des

commandes

rpm -q gpfs

ou

rpm -q csm

respectivement.

Pour AIX, utilisez la commande lslpp -l product* pour vérifier si l’un de ces logiciels est déjà installé. Pour

savoir, par exemple, si CSM est déjà installé, exécutez la commande suivante :

root@boepb06 ~# lslpp -l csm*

Si une version GPFS antérieure à la version 2.2 est installée, IBM Tivoli System Automation ne peut pas

être utilisée avec cette version de GPFS simultanément.

Contenu du CD :

Le CD libellé ″IBM Tivoli System Automation for Multiplatforms 2.1 Base component all Platforms″

comprend ce manuel, les manuels IBM Tivoli System Automation for Multiplatforms Base Component

Reference et IBM Tivoli System Automation for Multiplatforms : Gestion de l’automatisation de bout en

bout - Guide d’utilisation et de référence, scripts, et les progiciels pour chaque plateforme ainsi que

l’architecture correspondante.

CD / archives pour le composant de base

Lorsque vous commandez le composant de base d’IBM Tivoli System Automation, vous le trouverez dans

le CD/archive suivant :

CD du composant de base

Le tableau suivant répertorie les CD disponibles pour le composant de base. Pour l’installer, utilisez le

fichier d’installation répertorié dans la colonne de droite du tableau.

Installation

Tableau 1. CD de versions du produit

Système

d’exploitation Nom du CD du produit Fichier d’installation

Linux & AIX IBM Tivoli System Automation Multiplatform

V2.1.0

Base component all platforms

SAM2100Base/installSAM

Envoi électronique d’IBM Tivoli System Automation

Si vous préférez recevoir une copie électronique du logiciel au lieu d’un CD, nous vous offrons la

possibilité de le télécharger via Internet. Après avoir acheté IBM Tivoli System Automation vous pouvez

télécharger un fichier TAR pour les systèmes d’exploitation Linux et AIX..

Archives

Linux :

Tableau 2. Archives pour les plateformes Linux

Nom de l’archive Description

C86P9ML.tar Il s’agit de l’archive que vous utilisez pour installer le produit.

AIX :

Tableau 3. Archives pour les plateformes AIX

Utilisez la commande tar xf pour extraire l’archive. Une fois les fichiers extraits,

vous trouverez l’assistant d’installation dans le répertoire suivant :

SAM2100Base/installSAM

Nom de l’archive Description

C85W5ML.tar Il s’agit de l’archive que vous utilisez pour installer le produit.

Utilisez la commande tar xf pour extraire l’archive. Une fois les fichiers extraits,

vous trouverez l’assistant d’installation dans le répertoire suivant :

SAM2100Base/installSAM

Plateformes prises en charge :

La Version 2.1 d’IBM Tivoli System Automation prend en charge les plateformes Linux pour les zSeries,

xSeries, pSeries, iSeries, AIX 5.2 et AIX 5.3.

Le site Web suivant met à votre disposition des informations mises à jour concernant les plateformes

prises en charge : http://www-3.ibm.com/software/tivoli/products/sys-auto-linux/platforms.html.

8 IBM Tivoli System Automation Composant de base - Guide d’utilisation

IBM Tivoli System Automation fonctionne sur toutes les machines IBM eServer exécutées sous Linux et

sur les machines IBM eServer pSeries exécutées sous AIX.

Vous trouverez des informations détaillées concernant les distributions Linux et les versions d’AIX dans le

tableau suivant :

Tableau 4. Plateformes prises en charge et distributions

SUSE SLSS/SLES 8 (32 Bits) United Linux

1.0

xSeries 1

x x 2

SUSE SLES 9 (32 Bits) x x 3

SUSE SLSS/SLES 8 (64 Bits) United Linux

1.0

SUSE SLES 9 (64 Bits) x x 3

RedHat RHEL 3.0 (32 Bits) x

RedHat RHEL 4.0 (32 Bits) x

RedHat RHEL 3.0 (64 Bits) x x 4

zSeries pSeries iSeries

AIX 5.2 x

AIX 5.3 x

Remarques :

1. xSeries et tout autre serveur Intel 32 bits ou serveur AMD Opteron (64 bits).

2. Nécessite SuSE SLES8 SP3.

3. Nécessite SuSE SLES9 SP1.

4. Nécessite RedHat RHEL 3.5 au minimum.

x 2

x x

Interfaces de réseau prises en charge

Toutes les plateformes supportent Ethernet 10 Megabit, Fast Ethernet, et Ethernet Gigabit. De plus, les

plateformes zSeries prennent aussi en charge les Hipersockets, CTC, et VM Guest LAN.

Préparation de l’installation

IBM Tivoli System Automation est composé de plusieurs modules qui doivent être installés sur chaque

noeud au sein d’une grappe à automatiser. Le type de modules et contenu dépend du système

d’exploitation :

Système d’exploitation Type de module Contenu

Linux ’rpm’ correspond à RedHat Packaging

Manager. Il gère l’installation et la

désinstallation de progiciels sous le

format RPM.

Installation

System Automation rpms et RSCT

rpms. RSCT correspond à

l’infrastructure sous-jacente.

Chapitre 2. Installation du composant de base d’IBM Tivoli System Automation 9

Installation

Système d’exploitation Type de module Contenu

AIX Ensembles de fichiers ’installp’ Uniquement pour les ensembles de

fichiers installp de System

Automation. RSCT est inclus dans

AIX. Toutefois, il peut vous être

demandé de mettre à jour le niveau

RSCT.

Assurez-vous que le module

optionnel de Java 1.4 32bits est

installé sur le CD AIX.

Notez que les scripts installSAM et uninstallSAM sont fournis afin d’assurer que les modules sont installés

ou désinstallés dans le bon ordre. Les modules et les fichiers RPM doivent être disponibles sur les noeuds

où IBM Tivoli System Automation est installé.Vous pouvez, par exemple, vous connecter au site FTP pour

télécharger les modules depuis un PC (avec le CD-ROM en place) vers le noeud. Vous pouvez également

installer les modules sur un système de fichiers de réseau partagé.

Conditions préalables

Avant de commencer l’installation, vous devez remplir ces conditions :

v Installer Public Domain Korn Shell (pdksh) (si ce n’est pas déjà fait).

v Si vous utilisez à la fois la plateforme AIX 5.2 et l’adaptateur d’automatisation de bout en bout de

System Automation for Multiplatforms (voir «Configuration de l’adaptateur d’automatisation de bout en

bout de System Automation for Multiplatforms», à la page 149), assurez-vous d’avoir un fichier de type

pam.conf dans le répertoire /etc. Vous pouvez trouver un fichier pam.conf dans le répertoire

SAM2100Base/AIX.

v Perl est requis pour utiliser l’interface de la ligne de commande d’IBM Tivoli System Automation for

Multiplatforms y compris les commandes RSCT régionales. Il est installé par défaut sur les sytèmes

Linux ou AIX, mais si vous utilisez IBM Tivoli System Automation dans une langue autre que l’anglais,

une version spéciale de Perl sera requise. En raison de certains problèmes rencontrés avec Perl 5.8.0

et de sa capacité à supporter les paramètres de lieu de l’encodage UTF-8, certains caractères risquent

de ne pas s’afficher correctement. Ceci peut se produire sur des systèmes où la version Perl 5.8.0 est

déjà installée, si vous utilisez les paramètres de lieu de l’encodage UTF-8. Si vous utilisez une version

précédente de Perl, ou un langage de programmation autre qu’UTF-8, ce problème ne se produira pas.

AIX 5.2 fonctionne avec Perl 5.8.0. Aucune autre version de Perl n’est disponible pour cette édition

d’AIX.

Si vous décidez de mettre à jour votre version Perl 5.8.0 sur une distribution Linux, effectuez les

opérations suivantes :

1. Téléchargez la source de Perl 5.8.1, en allant sur http://dev.perl.org/perl5/news/2003/perl-

5.8.1.html .

2. Extrayez le contenu du zip et compactez -xvf dans un répertoire.

3. Compilez et installez sur la machine UTF-8, en vous reportant aux instructions contenues dans les

fichiers téléchargés.

4. Modifiez le pointage du lien symbolique vers le répertoire de la version Perl utilisée par IBM Tivoli

System Automation à partir de : /usr/sbin/rsct/perl5/bin/perl->/usr/bin/perlvers le répertoire

où la nouvelle version de Perl est installée par défaut :

/usr/sbin/rsct/perl5/bin/perl->/usr/local/bin/perl.

v Assurez-vous aussi que les répertoires /usr/sbin et /opt disposent d’au moins 100 Mo d’espace

disponible et que le répertoire /var dispose aussi de 100Mo d’espace disponible.

v Sur le noeud où l’adaptateur devra s’exécuter, vous devrez disposer de 128 Mo au minimum.

v Lors de l’installation d’IBM Tivoli System Automation sur AIX, le niveau de tolérance de pannes RSCT

sera vérifié et une mise à jour de RSTC sera requise. Si vos systèmes l’exigent, téléchargez et installez

les ensembles de fichiers RSCT appropriés à partir du service d’assistance AIX.

10 IBM Tivoli System Automation Composant de base - Guide d’utilisation

v Pour en savoir plus sur les conditions propres à chaque système d’exploitation, consultez la page Web

en question en allant sur http://www-306.ibm.com/software/tivoli/products/sys-autolinux/requirements.html.

v Pour les langues qui utilisent le jeu de caractères codé sur deux octets (DBCS), la taille de la

mémoire-tampon Telnet doit être suffisamment importante pour permettre à de longs messages de

s’afficher correctement. Si tel n’est pas le cas, augmentez la taille de la mémoire-tampon Telnet.

Configurations initiales

Vous devez effectuer les configurations initiales suivantes :

v Définissez la variable d’environnement suivante pour tous les utilisateurs d’IBM Tivoli System

Automation sur tous les noeuds :

CT_MANAGEMENT_SCOPE=2 (champ du domaine homologue). Vous pouvez définir de façon

permanente la variable si vous définissez les paramètres dans le profil.

v Ne perdez pas de vue qu’il vous faudra suivre les étapes suivantes si vous utilisez à la fois la

distribution SUSE LINUX et une langue autre que l’anglais :

1. Démarrez YaST2.

2. Sélectionnez l’icône ″System″ dans une liste.

3. Sélectionnez ″Editor for /etc/sysconfig″ dans une sous-fenêtre.

4. Sélectionnez ″Base-Administration″ dans une liste. Cliquez sur l’icône ″+″.

5. Sélectionnez ″Localization″ dans une liste. Cliquez sur l’icône ″+″.

6. Sélectionnez “rc_lang” dans la liste et définissez les paramètres de lieu, en vous reportant à la table

correspondante, au paramètre RC_LANG.

7. Sélectionnez ″root_uses_lang″ dans une liste. Sélectionnez ″yes″ au niveau du paramètre

ROOT_USES_LANG.

8. Appuyez sur le bouton ″Save″. Lorsque la boîte de dialogue ″Save sysconfig variables″ s’affiche,

appuyez sur ″OK″.

9. Redémarrez le système.

v Afin de vérifier que les paramètres de lieu de votre système sont correctement définis pour pouvoir

supporter ce produit (voir nos tables de support concernant les paramètres de lieu), procédez comme

suit :

1. Connectez-vous en tant qu’utilisateur root et exécutez la commande suivante :

paramètre de lieu

Vérifiez que la valeur LANG figure dans la langue de votre choix.

2. Si les valeurs renvoyées ne sont pas définies sur un paramètre de lieu pris en charge par le

système (voir nos tables de support concernant les paramètres de lieu) ou définissez sur POSIX,

puis continuez de la façon suivante :

3. Exécutez la commande suivante :

export LANG=xx_XX

Vous devez sélectionner un paramètre de lieu que votre terminal peut afficher.

4. Afin de vérifier que le terminal a été paramétré en fonction de vos besoins, exécutez la commande :

paramètre de lieu

et assurez-vous que LANG est défini sur xx_XX.

5. Effectuez ensuite les tâches courantes relatives au produit.

Vous devez renouveler les étapes 3 à 5 à chaque fois que vous ouvrez une nouvelle fenêtre de

terminal afin d’exécuter les commandes IBM Tivoli System Automation.

Installation

Chapitre 2. Installation du composant de base d’IBM Tivoli System Automation 11

Installation

Installation et mise à jour du composant de base d’IBM Tivoli System

Automation for Multiplatforms

Si vous installez ce produit pour la première fois, allez dans «Installation du produit» ci-dessous. Si une

version précédente d’IBM Tivoli System Automation est déjà installée, vous devrez effectuer quelques

opérations de configuration avant de pouvoir installer la nouvelle version d’IBM Tivoli System Automation.

Pour effectuer une migration vers une nouvelle version de ce produit, allez dans «Migration du produit», à

la page 13.

Installation du produit

Si vous avez téléchargé le fichier TAR d’Internet, extrayez le fichier du zip à l’aide de la commande

suivante :

tar -xvf

Si vous vous êtes procuré ce produit sur CD, installez le CD et remplacez le répertoire où le CD est

installé.

Entrez :

cd SAM2100Base

Installez le produit et l’adaptateur d’automatisation avec le script installSAM :

./installSAM

Avant de démarrer l’installation, le Contrat de licence et les Informations sur la licence s’affichent. Vous

pouvez faire défiler le texte ligne par ligne à l’aide de la touche Entrée, et page par page à l’aide de la

barre d’espacement, cette dernière offrant ″davantage″ de fonctionnalité dans UNIX. Une fois que vous

êtes arrivé à la fin des Informations de licence et que vous souhaitez accepter lesdites Informations, tapez

’y’. Toute autre entrée entraînera l’annulation de l’installation.

Pour Linux, vous pouvez désormais exécuter la commande suivante pour voir quels modules ont déjà été

installés :

rpm -qa | grep -E “^src|^rsct|^sam”

Voir la page d’aide rpm pour plus de détails concernant la commande rpm.

Pour AIX, vous pouvez maintenant exécuter la commande suivante pour voir quels modules ont déjà été

installés :

lslpp -l sam*

Installation de la Licence du produit

IBM Tivoli System Automation exige qu’une Licence de produit valide soit installée sur chaque système sur

lequel il est exécuté. La licence se trouve sur le support d’installation dans le sous-répertoire ’licence’.

L’installation de la licence s’effectue généralement lors du processus d’installation du produit. Si le

processus échoue, ou si vous souhaitez passer d’une licence d’évaluation à une licence complète du

produit, exécutez la commande suivante pour installer la licence :

samlicm –i license_file

Afin d’afficher la licence, exécutez /

samlicm -s

Voir le manuel IBM Tivoli System Automation for Multiplatforms Base Component Reference pour afficher

une description détaillée de la commande samlicm.

12 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Langues prises en charge par IBM Tivoli System Automation

Cette section n’a d’intérêt que pour les utilisateurs souhaitant afficher IBM Tivoli System Automation for

Multiplatforms dans une langue autre que l’anglais comme il est fait mention dans les tableaux ci-dessous.

Le codage suivant est pris en charge par la distribution Linux :

Langue UTF-8 ISO-8859-1 EUC/GBK Euro GB18030/BIG5

Allemand de_DE.UTF-8 de_DE,

de_DE.ISO-8859-1

Espagnol es_ES.UTF-8 es_ES,

es_ES.ISO-8859-1

Français fr_FR.UTF-8 fr_FR,

fr_FR.ISO-8859-1

Italien it_IT.UTF-8 it_IT,

it_IT.ISO-8859-1

Japonais ja_JP.UTF-8 ja_JP.eucJP

Coréen ko_KR.UTF-8 ko_KR.eucKR

Portugais/

Brésilien

pt_BR.UTF-8 pt_BR

Chinois simplifié zh_CN.UTF-8 zh_CN.GBK,

zh_CN.GB2312

Chinois

traditionnel

de_DE@euro

es_ES@euro

fr_FR@euro

it_IT@euro

zh_CN.GB18030

zh_TW.UTF-8 zh_TW.Big5,

zh_TW

Le codage suivant est pris en charge par la distribution AIX :

Langue UTF-8 ISO-8859-1 EUC/GBK SJIS/GB18030/BIG5

Allemand DE_DE de_DE

Espagnol ES_ES es_ES

Français FR_FR fr_FR

Italien IT_IT it_IT

Japonais JA_JP ja_JP Ja_JP

Coréen KO_KR ko_KR

Portugais/brésilien PT_BR pt_BR

Chinois simplifié ZH_CN zh_CN Zh_CN

Chinois traditionnel ZH_TW zh_TW Zh_TW

Migration du produit

Si IBM Tivoli System Automation 1.2 est déjà installé, le produit pourra être migré vers la nouvelle version

d’IBM Tivoli System Automation 2.1.

Avant de procéder à la migration, prenez en considération ce qui suit :

v Le processus de migration démarre lorsqu’un noeud à l’intérieur d’une grappe active est mis à jour vers

un numéro de version supérieur.

v Vous pouvez toujours mettre à jour une version inférieure vers une version supérieure, mais il est

impossible d’effectuer une migration dans le sens inverse.

Installation

Chapitre 2. Installation du composant de base d’IBM Tivoli System Automation 13

Installation

v Le processus de migration est terminé une fois que le numéro de version actif est égal au numéro de

version le plus haut déjà installée. Jusque-là, plusieurs niveaux de version peuvent coexister. Voir

«Vérification du numéro de version d’installation et du numéro de version active», à la page 15 et «Fin

de processus de migration», à la page 15 pour savoir comment effectuer un processus de migration.

Vous pouvez utiliser l’une des options suivantes pour effectuer une migration d’IBM Tivoli System

Automation, mais nous vous recommandons d’utiliser la procédure décrite dans «Migration d’un domaine

tout entier», à la page 14:

Migration d’un domaine tout entier

Gardez ce qui suit toujours à l’esprit lors de la procédure de migration d’un domaine tout entier :

1. Le domaine sera indisponible lors de la mise à jour et ne pourra en conséquence être utilisé à des fins

d’automatisation. En d’autres termes, cette ressource sera hors ligne.

2. Vérifiez que l’adaptateur d’automatisation de bout en bout de System Automation for Multiplatforms

fonctionne :

samadapter status

S’il fonctionne, arrêtez-le :

samadapter stop

3. Arrête l’ensemble des groupes de ressources en ligne en définissant leur état nominal sur hors ligne :

chrg -o Offline

4. Si le domaine est en ligne, arrêtez le domaine :

stoprpdomain

5. Exécutez ./installSAM depuis le répertoire d’installation sur tous les noeuds.

6. Démarrez le domaine :

startrpdomain

7. Vérifiez les niveaux de code avec la commande lssrc –ls IBM.RecoveryRM (voir l’exemple dans

«Vérification du numéro de version d’installation et du numéro de version active», à la page 15). Tous

les noeuds devraient comporter le nouveau niveau de code, mais le niveau de code actif doit

correspondre au précédent.

8. Afin d’activer la nouvelle version, voir «Fin de processus de migration», à la page 15.

Migration d’un noeud étape par étape

Cette migration présente l’avantage qu’IBM Tivoli System Automation reste toujours disponible au cours du

processus de migration. Gardez ce qui suit à l’esprit lorsque vous effectuez un processus de migration

d’un noeud étape par étape :

1. Assurez-vous que le noeud à migrer est exclu du système d’automatisation, pour que les ressources

soient activées sur d’autres noeuds.

samctrl -u a

Notez que si un groupe de ressources fonctionnait sur le noeud à exclure, l’automatisation essaiera de

le déplacer vers un autre noeud. Cette opération peut prendre un certain temps.

2. Arrêtez le noeud depuis un autre noeud dans le domaine et vérifiez qu’il est bien arrêté :

stoprpnode ; lsrpnode

3. Exécutez ./installSAM à partir du répertoire d’installation pour mettre le noeud à jour.

4. Démarrez le noeud :

startrpnode

5. Prenez le nouveau noeud qui vient d’être mis à jour pour l’intégrer au système d’automatisation :

samctrl -u d

6. Le nouveau noeud mis à jour peut dorénavant rejoindre le domaine existant. Utilisez la commande

lssrc –ls IBM.RecoveryRM (voir l’exemple dans «Vérification du numéro de version d’installation et du

14 IBM Tivoli System Automation Composant de base - Guide d’utilisation

numéro de version active») pour afficher la version installée et la version active du produit. Les

nouvelles fonctions du code ne seront pas activées tant que le numéro de version actif d’IBM Tivoli

System Automation est égal au numéro de version le plus élevé d’IBM Tivoli System Automation

installée à l’intérieur de la grappe, et vous ne pourrez pas utiliser pleinement ces nouvelles fonctions

de code tant que tous les noeuds ne sont pas remis à jour.

7. Renouvelez les étapes 1-6 pour d’autres noeuds à l’intérieur de la grappe.

8. Afin d’activer la nouvelle version, voir «Fin de processus de migration».

Vérification du numéro de version d’installation et du numéro de version active

Au terme de la mise à jour, les nouvelles fonctions du nouveau noeud ne sont toujours pas activées. Les

niveaux de version précédente et les nouveaux niveaux de version peuvent coexister jusqu’au terme de la

migration. La commande lssrc –ls IBM.RecoveryRM affiche le numéro de version active AVN(1.2.0.0

dans l’exemple ci-dessous) et le numéro de version d’installation IVN (2.1.0.0. dans l’exemple ci-dessous)

du produit. Lorsque les numéros IVN et AVN sont identiques, la migration est terminée.

Le résultat se présente sous cette forme :

Sous-système : IBM.RecoveryRM

PID : 27973

Nom de la grappe : ws

Numéro du noeud : 1

Heure du début : Wed Apr 21 08:09:10 2004

Etat du démon:

Nom du noeud : lnxcm3x

Nom du noeud maître : lnxcm3x (node number = 1)

Notre IVN : 2.1.0.0

Notre AVN : 1.2.0.0

Notre CVN : 11082527751 {0x140861007}

Nombre total de noeuds : 1

Nombre de membre associé: 1

Nombre de quorum de configuration : 1

Nombre de quorum au démarrage : 1

Etat du quorum opérationnel : HAS_QUORUM

Dans Quorum de configuration: TRUE

Dans Etat de configuration : TRUE

Remplacement de l’état de configuration : FALSE

Figure 3. Vérification du numéro de version active et du numéro de version d’installation.

Afin d’activer la nouvelle version, voir «Fin de processus de migration».

Fin de processus de migration

Afin de vérifier et de finaliser la migration, effectuez les opérations suivantes :

1. Exécutez la commande lsrpdomain pour afficher le numéro de version active RSCT et l’état de la

version mixte :

Nom EtatOp VersionRSCTActive VersionsMixtes PortTS PortGS

SA_Domain Actif 2.4.1.3 Oui 12347 12348

2. Exécutez la commande lsrpnode pour afficher le numéro de version d’installation RSCT sur tous les

noeuds. Tous les noeuds doivent être en ligne :

Nom EtatOp Version RSCT

noeud01 En ligne 2.4.3.1

noeud02 En ligne 2.4.3.1

noeud03 En ligne 2.4.3.1

3. Si le domaine homologue RSCT fonctionne en mode version mixte (VersionsMixtes = Oui), exécutez la

commande suivante sur l’un des noeuds. Gardez à l’esprit que tous les noeuds doivent être en ligne.

runact -c IBM.PeerDomain CompleteMigration Options=0

Installation

Ceci met à jour la version active RSCT une fois que tous les noeuds ont été mis à jour dans la

nouvelle édition d’IBM Tivoli System Automation. Voir les procédures supplémentaires ayant trait à la

Chapitre 2. Installation du composant de base d’IBM Tivoli System Automation 15

Installation

préparation de migration RSCT décrites dans le Chapitre 3 d’IBM RSCT Administration Guide avant de

démarrer l’action RSCT CompleteMigration. Afin de vérifier la mise à niveau, exécutez de nouveau la

commande lsrpdomain :

Nom EtatOp Version RSCTActive VersionsMixtes PortTS PortGS

SA_Domain En ligne 2.4.3.1 Non 12347 12348

4. Exécutez la commande samctrl –m (voir la description de la commande dans le manuel IBM Tivoli

System Automation for Multiplatforms Base Component Reference) pour activer les nouvelles fonctions

du nouveau code et finaliser la migration.

Le numéro de version active et le numéro de version d’installation d’IBM Tivoli System Automation

devraient être le même pour tous les noeuds. Si tel n’était pas le cas, les nouvelles fonctions de la version

ne seront pas activées, et en conséquence, utilisées.

Désinstallation d’IBM Tivoli System Automation

Utilisez le script uninstallSAM fourni pour votre système d’exploitation pour désinstaller IBM Tivoli System

Automation. Vous pouvez, par exemple, exécuter ./uninstallSAM à partir du répertoire d’installation. Cette

opération assurera la désinstallation complète du produit. Avant de désinstaller le produit, il est

recommandé de sauvegarder votre configuration avec la commande samcfg –S. Voir «Gestion des règles

d’automatisation», à la page 165 et la description relative à la commande samcfg dans ce manuel IBM

Tivoli System Automation for Multiplatforms Base Component Reference sur la procédure de sauvegarde

d’IBM Tivoli System Automation.

Remarque : Cette commande supprimera aussi toutes les informations de configuration que vous avez

définies pour le domaine.

N’utilisez jamais uninstallSAM avant d’être sûr de vouloir mettre à jour votre version.

Vérifiez qu’un domaine est toujours en ligne en entrant la commande :

lsrpdomain

Afin d’arrêter un domaine, entrez la commande :

stoprpdomain

Désinstallez le produit avec le script uninstallSAM :

./uninstallSAM

Si CSM ou GPFS (qui utilise aussi RSCT et System Resource Controller (SRC)) est installé sur un

système Linux à partir duquel vous souhaitez effectuer la désinstallation d’IBM Tivoli System Automation,

RPM veillera à ne pas désinstaller RSCT et SRC au cours de la désinstallation d’IBM Tivoli System

Automation. Les messages RPM vous en informeront.

Si vous souhaitez vérifier quels modules ont été désinstallés du système d’exploitation Linux, utilisez la

commande suivante :

rpm -qa | grep -E “^src|^rsct|^sam”

Si vous souhaitez vérifier quels modules ont été désinstallés du système d’exploitation AIX, utilisez la

commande suivante :

lslpp -l sam*

Tout module resté installé sera répertorié. Si aucun module requis par d’autres produits n’est resté installé,

aucun module ne sera répertorié.

16 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Service d’installation

Le service d’installation renvoie à la mise à jour de l’édition 2.1.0 d’IBM Tivoli System Automation. En

conséquence, vous devez avoir installé préalablement l’édition 2.1.0 avant d’effectuer toute tâche de

maintenance. Sauvegardez d’abord votre configuration système. Voir «Gestion des règles

d’automatisation», à la page 165 pour savoir comment effectuer cette procédure. Puis, suivez les étapes

indiquées ci-dessous sur chaque noeud dans le domaine homologue :

1. Vérifiez que toutes les ressources sont en ligne sur le noeud sur lequel vous souhaitez intervenir.

2. Si les ressources sont en ligne et doivent être disponibles, vous devrez exclure le noeud de

l’automatisation à l’aide de cette commande

samctrl -u a Noeud

Les ressources seront ensuite réinitialisées sur d’autres noeuds au sein du domaine homologue.

3. Si les ressources doivent êtres disponibles lors de la maintenance, définissez les groupes de

ressources hors ligne.

4. Exécutez les mêmes étapes décrites dans «Installation du produit», à la page 12.

5. Si vous avez déjà exclu le noeud au cours de l’étape 2, vous devez inclure le noeud dans

l’automatisation à l’aide de la commande

samctrl -u d Noeud

6. Si les groupes de ressources doivent être inactifs, définissez les groupes de ressources sur inactif.

Sinon, effectuez cette étape une fois que vous êtes intervenu sur le dernier noeud au sein du domaine

homologue.

Désinstallation du service

Installation

La désinstallation du service signifie que vous devez désinstaller le produit dans son intégralité comme

décrit dans «Désinstallation d’IBM Tivoli System Automation», à la page 16. Puis, vous devrez réinstaller

IBM Tivoli System Automation for Multiplatforms et installer le niveau de service requis (niveau du

correctif).

Chapitre 2. Installation du composant de base d’IBM Tivoli System Automation 17

18 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Chapitre 3. Mise en route

Ce chapitre répertorie et décrit les étapes suivantes que vous devez réaliser pour démarrer IBM Tivoli

System Automation :

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

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

supprimer des noeuds d’une grappe et comment vérifier l’état du démon

IBM Tivoli System Automation.

Etape 2 : Définition des ressources RSCT

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

Cette étape indique comment définir des relations parmi les composants

créés aux étapes 1 et 2. Il s’agit de la définition des règles

d’automatisation.

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 broadcast 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.

Pour de plus amples informations, voir Chapitre 11, «Configuration d’un réseau hautement disponible», à

la page 139.

La section suivante donne un aperçu des commandes Reliable Scalable Cluster Technology (RSCT) for

Linux que vous utilisez lorsque vous travaillez avec des définitions de grappe. Vous aurez besoin de

quelques unes de ces commandes lorsque vous effectuerez les étapes 1 et 2.

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

Mise en route

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.

rmrpdomain Cette commande supprime une grappe définie.

rmrpnode Cette commande supprime un ou plusieurs noeuds d’une définition de la

grappe.

Pour obtenir les descriptions de ces commandes, reportez-vous aux pages d’aide appropriées ou aux

manuels suivants, que vous trouverez sur le CD d’IBM Tivoli System Automation :

v IBM Reliable Scalable Cluster Technology for Linux, Administration Guide, SA22-7892.

v IBM Reliable Scalable Cluster Technology for Linux, Technical Reference, SA22-7893.

v IBM Reliable Scalable Cluster Technology for AIX 5L: Administration Guide., SA22-7889.

v IBM Reliable Scalable Cluster Technology for AIX 5L: Technical Reference., SA22-7890.

Vous trouverez ces documents sur ce site Web d’IBM à l’adresse :

http://www-1.ibm.com/servers/eserver/clusters/library/

Le manuel IBM Tivoli System Automation for Multiplatforms Base Component Reference fournit une liste

complète ainsi qu’une description de chaque commande IBM Tivoli System Automation. Vous utiliserez

certaines de ces commandes au cours de l’étape 3.

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

Les scénarios suivants indiquent comment créer une grappe, ajouter des noeuds à une grappe et

comment vérifier l’état du démon IBM Tivoli System Automation (IBM.RecoveryRM).

Création d’une grappe à deux noeuds

Afin de créer cette grappe, vous avez besoin :

1. D’accéder à une console sur chaque noeud de la grappe et vous y connecter en tant que root.

2. De définir la variable d’environnement CT_MANAGEMENT_SCOPE=2 sur chaque noeud.

3. D’exécuter la commande preprpnode dans tous les noeuds afin d’autoriser la communication entre les

noeuds de grappe.

preprpnode node01 node02

4. 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

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).

5. Pour contrôler l’état de SA_Domain, exécutez la commande lsrpdomain :

lsrpdomain

Output:

Name OpState RSCTActiveVersion MixedVersions TSPort GSPort

SA_Domain Offline 2.4.3.1 No 12347 12348

La grappe est définie mais hors ligne.

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

startrpdomain SA_Domain

20 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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.

Name OpState RSCTActiveVersion MixedVersions TSPort GSPort

SA_Domain Pending online 2.4.3.1 No 12347 12348

Après un bref moment, la grappe sera démarrée ; aussi, lorsque vous exécuterez la commande

lsrpdomain une nouvelle fois, vous constaterez que la grappe est désormais en ligne :

Name OpState RSCTActiveVersion MixedVersions TSPort GSPort

SA_Domain Online 2.4.3.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 ces

incidents en exécutant la commande

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

sur le noeud cité dans le message d’erreur afin de réinitialiser l’ID du noeud. 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.

Ajout d’un noeud dans une grappe existante

Après avoir créé une grappe à deux noeuds, vous pouvez avoir envie d’ajouter un troisième noeud dans

SA_Domain. Pour ce faire, vous avez besoin :

1. d’émettre la commande lsrpdomain afin de voir si votre grappe est en ligne :

Name OpState RSCTActiveVersion MixedVersions TSPort GSPort

SA_Domain Online 2.4.3.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.4.3.1

node01 Online 2.4.3.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

Connectez-vous au noeud node01 et entrez :

preprpnode node03

Mise en route

Chapitre 3. Mise en route 21

Mise en route

Nous vous recommandons fortement d’exécuter une commande preprpnode dans chaque noeud de

tous les noeuds.

3. Afin d’ajouter le noeud node03 à la définition de grappe, exécutez la commande addrpnode sur le

noeud node01 ou node02, qui sont déjà en ligne sur la grappe.

addrpnode node03

Exécutez à nouveau la commande lsrpnode afin de voir le statut de tous les noeuds :

Name OpState RSCT Version

node02 Online 2.4.3.1

node03 Offline 2.4.3.1

node01 Online 2.4.3.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 :

Name OpState RSCTActiveVersion MixedVersions TSPort GSPort

SA_Domain Offline 2.4.3.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

devrez peut-être exécuter cette commande pour procéder aux mises à jour de l’application, à la

maintenance d’un noeud ou 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

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 10, «Protection de vos ressources – support réalisé par Quorum», à

la page 123 pour des informations supplémentaires.

Exécutez la commande lsrpnode afin de voir si le noeud node03 est hors ligne :

lsrpnode node03

Name OpState RSCT Version

node03 Offline 2.4.3.1

22 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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

Name OpState RSCT Version

node02 Online 2.4.3.1

node03 Offline 2.4.3.1

node01 Online 2.4.3.1

Puis exécutez la commande rmrpnode à partir de n’importe quel noeud de la grappe pour supprimer le

noeud node03.

rmrpnode node03

Exécutez la commande lsrpnode une nouvelle fois afin de voir si le noeud node03 a été supprimé.

lsrpnode

Name OpState RSCT Version

node02 Online 2.4.3.1

node01 Online 2.4.3.1

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 ou mettre en ligne

tous les noeuds hors ligne de la grappe à l’aide de 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. Si un noeud n’est pas accessible à partir du noeud sur lequel la commande

rmrpdomain est exécutée (par exemple, le noeud est hors ligne ou hors de fonctionnement), la

commande rmrpdomain ne sera pas capable de supprimer la définition de grappe de 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

Puis exécutez la commande rmrpdomain pour supprimer la grappe SA_Domain :

rmrpdomain SA_Domain

Administration du Recovery Resource Manager

Un démon IBM Tivoli System Automation (IBM.RecoveryRM) fonctionne sur chaque noeud en ligne de la

grappe. Vous pouvez vérifier l’état et l’ID processus du démon à l’aide de la commande lssrc :

lssrc -s IBM.RecoveryRM

Vous obtenez le résultat suivant :

Subsystem Group PID Status

IBM.RecoveryRM rsct_rm 18283 active

Mise en route

Chapitre 3. Mise en route 23

Mise en route

Ce démon fonctionne sur chaque noeud en ligne dans la grappe. Il est démarré automatiquement si le

noeud de grappe démarre. Si nécessaire, vous pouvez arrêter manuellement le démon à l’aide de la

commande :

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. Vous pouvez rechercher le noeud sur lequel le démon maître se trouve à l’aide de la

commande :

lssrc -ls IBM.RecoveryRM | grep Master

Vous obtenez le résultat suivant :

Master Node Name : node03 (node number = 3)

Dans notre exemple, le démon maître fonctionne sur le noeud node03.

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 d’IBM

Tivoli System Automation.

Etape 2 : Définition des ressources RSCT

L’exemple suivant illustre la procédure de définition d’un serveur Web à haute disponibilité dans trois

noeuds de la grappe SA_Domain. Voir l’«Etape 1 : Définition et administration d’une grappe», à la page 20

afin de voir comment cette grappe et les noeuds node01, node02 et node03 ont été définis.

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.

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.

24 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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.

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 13, «Gestionnaires de ressources fournis par

IBM Tivoli System Automation», à la page 181 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

Mise en route

Chapitre 3. Mise en route 25

Mise en route

Veillez à ce que le script soit accessible sur tous les noeuds à partir du même chemin d’accès au

répertoire.

Les définitions de ressources RSCT sont créées à l’aide de la commande mkrsrc. Toutes les

caractéristiques de ressources peuvent être fournies dans les paramètres de ligne de commande, mais la

commande mkrsrc accepte également un fichier de définition en texte normal. 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 l’adresse IP de la ressource 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 d’IBM Tivoli System Automation. L’adresse d’apache1IP est au contraire créée par IBM

Tivoli System Automation et représente une adresse d’alias supplémentaire sur une carte réseau

appropriée 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.

Nous utilisons cette fois les paramètres de ligne de commande avec la commande mkrsrc afin de créer

une 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.

Création d’une é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

26 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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 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 crée l’équivalence netequ qui contient une carte réseau provenant de chaque

noeud de la grappe :

mkequ netequ IBM.NetworkInterface:eth0:node01,eth0:node02,eth0:node03

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

Les exemples suivants illustrent comment les ressources apache1 et apache1IP sont transformées en

ressources gérées IBM Tivoli System Automation (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 24 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, IBM Tivoli System Automation lance

le contrôle du groupe de ressources et de ses ressources associées.

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 53).

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 ?

Création d’un groupe de ressources

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

Deux conditions permettent de relier les ressources apache1 et apache1I. Les ressources doivent tout

d’abord 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 67). 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.

Chapitre 3. Mise en route 27

Mise en route

IBM Tivoli System Automation offre un type de relation DependsOn (voir section «Relation DependsOn», à

la page 60) 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 24, 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 d’un groupe de ressources

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 d’IBM Tivoli System Automation afin de :

v créer, supprimer, modifier et répertorier les groupes de ressources. Voir le Chapitre 5, «Utilisation des

groupes de ressources», à la page 35 pour des informations supplémentaires.

v créer, supprimer et modifier les ressources membres du groupe de ressources. Voir le Chapitre 4,

«Utilisation des ressources», à la page 29 pour obtenir des informations supplémentaires.

v créer, supprimer et modifier des ressources d’équivalence. Voir le Chapitre 6, «Utilisation des

équivalences», à la page 49 pour obtenir des informations supplémentaires.

v créer, supprimer, modifier et répertorier les ressources de relations gérées. Voir le Chapitre 7,

«Utilisation des relations gérées», à la page 53 pour obtenir des informations supplémentaires.

Une liste complète des commandes IBM Tivoli System Automation est fournie dans le manuel IBM Tivoli

System Automation for Multiplatforms Base Component Reference.

28 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Chapitre 4. Utilisation des ressources

Ce chapitre décrit comment utiliser les ressources dans les sections principales suivantes :

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 IBM Tivoli System Automation que vous utilisez conjointement aux ressources

gérées :

Tableau 5. Commandes IBM Tivoli System Automation utilisées avec les ressources gérées

Commande Description Pour des

informations

addrgmbr Ajouter une ou plusieurs ressources à un groupe de ressources. supplémentaires,

chrgmbr Modifier la valeur de l’attribut persistant d’une ressource gérée dans un

groupe de ressources

consultez les

descriptions de

commandes dans le

lsrg Répertorier un groupe de ressources déjà défini ou ses ressources

membres

manuel IBM Tivoli

System Automation

for Multiplatforms

rmrgmbr Supprimer une ou plusieurs ressources du groupe de ressources

Base Component

Reference.

Qu’est ce qu’une ressource ?

Une ressource est un élément matériel ou logiciel défini dans le RMC (Contrôle et gestion des ressources)

d’IBM à l’aide de la :

v commande RMC mkrsrc (“Créer Ressource”).

v fonction de “récolte” de RMC, dans laquelle les ressources sont détectées automatiquement et

préparées en vue de leur utilisation avec IBM Tivoli System Automation.

Comme décrit dans la section «Composants d’IBM Tivoli System Automation», à la page 4, IBM Tivoli

System Automation 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, 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.

Utilisation des ressources

Quelle est la différence entre des attributs persistants et des attributs

dynamiques ?

Il existe deux types d’attribut de ressource : les attributs persistants et les attributs dynamiques. Les

attributs de la machine hôte mentionnés (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. Alors

que vous pouvez 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.

Les attributs dynamiques, d’un autre côté, représentent les attributs modifiables 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 IBM Tivoli System Automation (mentionnée simplement

comme une ressource gérée) dès que la ressource a été insérée dans un groupe de ressources IBM Tivoli

System Automation. Cette insertion est effectuée à l’aide de la commande IBM Tivoli System Automation

addrgmbr (décrite dans le manuel IBM Tivoli System Automation for Multiplatforms Base Component

Reference). A partir de ce point de vue, la ressource peut être gérée à l’aide de commandes et

programmes d’IBM Tivoli System Automation.

Les ressources gérées sont fournies dans la classe de ressources IBM.ManagedResource d’IBM Tivoli

System Automation.

Travailler avec des ressources

Notez qu’IBM Tivoli System Automation 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 46 et «Attribut NominalState», à la page 40.

30 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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.

Il s’agit d’un attribut d’une ressource RSCT.

SelectFrom Policy Définit la liste de noeuds dans lesquels la ressource est disponible. Il

s’agit d’un attribut d’une ressource gérée.

ResourceType Indique si la ressource est autorisée à fonctionner dans plusieurs noeuds

ou dans un seul. Il s’agit d’un attribut d’une ressource RSCT.

OpState Spécifie l’état opérationnel de la ressource ou du groupe de ressources. Il

s’agit d’un attribut 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 IBM Tivoli System Automation 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 à IBM Tivoli System

Automation 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’IBM Tivoli System Automation 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’IBM Tivoli System Automation 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

Attributs utilisés par les ressources

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.

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.

Chapitre 4. Utilisation des ressources 31

Attributs utilisés par les ressources

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é automatisable 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 des 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.

32 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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.

Attributs utilisés par les ressources

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 IBM Tivoli System Automation 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 des informations détaillées, reportez-vous à

la page d’aide de cette commande.

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. IBM Tivoli System

Automation peut procéder de la sorte car il possède des données d’état différentes pour le noeud des

ressources.

Etat nominal de la ressource

Les ressources ne possèdent pas d’informations relatives à l’état nominal. Vous ne pouvez pas définir

directement l’état nominal d’une ressource. Les ressources doivent être définies au sein des groupes de

ressources. Chaque groupe possède un état nominal. Il est défini sur En ligne ou Hors ligne et indique à

IBM Tivoli System Automation si les ressources au sein du groupe de ressources doivent être définies sur

En ligne ou Hors ligne à cette étape. Vous pouvez modifier la valeur d’état nominal du groupe de

ressources.

Chapitre 4. Utilisation des ressources 33

34 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Chapitre 5. 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 ?»

v «Attributs utilisés par les groupes de ressources», à la page 37

v «Création d’un groupe de ressources», à la page 44

v «Modification des attributs d’un groupe de ressources», à la page 46

v «Suppression d’un groupe de ressources», à la page 47

v «Enumération d’un groupe de ressources ou de ses ressources membres», à la page 45

v «Ajout d’une ressource membre dans un groupe de ressources», à la page 45

v «Suppression d’une ressource membre d’un groupe de ressources», à la page 47

v «Modification des attributs des membres d’un groupe de ressources», à la page 47

Section connexe :

v «Evénements permettant la mise en ligne d’un groupe de ressources», à la page 79

ressources :

Tableau 6. Commandes IBM Tivoli System Automation utilisées avec les groupes de ressources

Commande Description Pour des

mkrg Créer un groupe de ressources

informations

supplémentaires,

rmrg Supprimer un groupe de ressources

consultez les

chrg Modifier les attributs persistants d’un groupe de ressources (y compris le

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

descriptions de

commandes dans

le manuel IBM

lsrg Répertorier un ou plusieurs groupes de ressources

Tivoli System

addrgmbr

rmrgmbr

Ajouter des ressources membres dans un groupe de ressources

Supprimer des ressources membres d’un groupe de ressources

Automation for

Multiplatforms

Base Component

chrgmbr Modifier les attributs des ressources membres d’un groupe de ressources Reference.

rgreq Démarrer, arrêter, annuler ou déplacer un groupe de ressources

rmrgmbr Supprimer une ou plusieurs ressources d’un groupe de ressources

Qu’est ce qu’un groupe de ressources ?

Dans IBM Tivoli System Automation les groupes de ressources sont l’unité centrale. Il s’agit d’un

conteneur logique pour un ensemble de ressources pouvant être traitées comme une seule instance

logique. 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. De même, si vous définissez l’état nominal

(NominalState) sur Hors ligne, tous les membres sont arrêtés et gérés hors ligne. Autre aspect des

groupes de ressources : il est possible de contrôler et de consolider l’état opérationnel (OpState) des

membres individuels du groupe 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.

Groupes de ressources

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 illustre également qu’IBM Tivoli System Automation peut gérer des

membres de groupe de ressources répartis sur plusieurs noeuds à l’intérieur d’une grappe.

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.

36 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Les groupes de ressources sont définis dans la classe de ressources IBM.ResourceGroup d’IBM Tivoli

System Automation.

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.

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. IBM Tivoli System

Automation tente d’amener et de conserver le groupe de ressources sur

l’état nominal.

Priority 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.

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.

Owner 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.

Subscription 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 Owner, qui

peuvent également être modifiés lorsque le groupe de ressources est En ligne.

Un groupe de ressources fournit les attributs dynamiques suivants :

Groupes de ressources

OpState Spécifie l’état opérationnel général de l’ensemble des ressources gérées.

Chapitre 5. Utilisation des groupes de ressources 37

Groupes de ressources

TopGroup Affiche le nom du groupe de ressources de niveau supérieur d’un groupe

de ressources.

AutomationDetails Affiche les états internes IBM Tivoli System Automation du groupe de

ressources.

MoveStatus Indique l’état de progression de déplacement d’un groupe de ressources

lancé à l’aide de la commande rgreq.

ConfigValidity Indique si une règle est devenue invalide.

Attribut AllowedNode

Utilisez le paramètre AllowedNode pour définir un ensemble de noeuds dans une grappe qui n’autorise le

fonctionnement que d’un nombre limité de membres du groupe de ressources.

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 6, «Utilisation des équivalences», à la page 49.

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 d’IBM Tivoli

System Automation, 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 IBM Tivoli

System Automation.

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}.

38 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Le résultat de ce scénario est le suivant :

Groupes de ressources

v FixA peut uniquement être démarré par IBM Tivoli System Automation sur le noeud node1.

v FloatB peut uniquement être démarré par IBM Tivoli System Automation 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 IBM Tivoli System Automation sur les noeuds node2 et

node4.

v FloatD peut uniquement être démarré par IBM Tivoli System Automation 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 ’Collocated’ 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 7, «Utilisation des relations gérées», à la

page 53 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.

Chapitre 5. Utilisation des groupes de ressources 39

Groupes de ressources

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 55.

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 manuel IBM Tivoli System Automation for Multiplatforms Base

Component Reference). La valeur numérique de cet attribut est

1 Hors ligne

0 En ligne

Attribut Priority

Utilisez l’attribut persistant Priority pour spécifier la priorité relative du groupe de ressources par rapport

aux autres groupes de ressources.

L’attribut Priority 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 7, «Utilisation des relations gérées», à la

page 53) 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.

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. IBM Tivoli System Automation utilise

désormais la valeur de l’attribut Priority 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.

40 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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 Priority est zéro, c.-à-d. la valeur la plus faible. La valeur maximale est

200.

Astuce : IBM Tivoli System Automation utilise également l’attribut Mandatory des ressources gérées

(décrit à la section «Attributs utilisés pour les membres de groupes de ressources», à la page 43) 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é. Elle peuvent être déplacées au moyen de la commande

rgreq.

Cela signifie que lorsque vous placez un noeud dans la liste d’exclusion, IBM Tivoli System Automation ne

considère pas le noeud comme un candidat potentiel pour héberger la ressource. Vous pouvez utiliser cet

attribut pour éloigner graduellement des ressources d’un noeud sans provoquer aucune perturbation en

préparation d’une exclusion (EXCLUDE) (au moyen de la commande samctrl) ultérieure.

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.

Groupes de ressources

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.

Owner

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.

Subscription

Cet attribut contient des informations relatives à l’abonnement dans une gestion de bout en bout.

Chapitre 5. Utilisation des groupes de ressources 41

Groupes de ressources

Attribut OpState

IBM Tivoli System Automation 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.

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

Utilisez l’attribut dynamique TopGroup pour visualiser le groupe de ressources de niveau supérieur d’un

groupe de ressources.

Dans IBM Tivoli System Automation, les groupes de ressources peuvent être membres d’un autre groupe

de ressources ce qui signifie que les groupes de ressources peuvent ê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 manuel IBM Tivoli System Automation for

Multiplatforms Base Component Reference et indiqué ci-dessous.

Remarque : Lorsque vous utilisez la commande lsrg –g pour interroger un groupe de ressources, l’état

nominal (NominalState) du groupe supérieur est affiché dans le résultat avec l’attribut

TopGroup pour le confort de l’utilisateur. Le résultat se présente sous cette forme :

TopGroup = apacherg

TopGroupNominalState = Offline

42 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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, l’état ’En veille’ indique qu’IBM Tivoli System Automation

n’est pas en train d’essayer de démarrer ou d’arrêter le groupe de

ressources.

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 de l’automatisation comme indiqué ci avant, utilisez la commande lsrg

conjointement aux options –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

MoveStatus

Indique l’état de progression de déplacement d’un groupe de ressources lancé à l’aide de la commande

rgreq.

Pour afficher l’état de progression, utilisez la commande lsrg conjointement aux options –A d et –V. Par

exemple, pour afficher l’état de progression d’un groupe de ressources ″apacherg″, utilisez la commande :

lsrg –A d –V –g apacherg

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.

Groupes de ressources

Chapitre 5. Utilisation des groupes de ressources 43

Groupes de ressources

SelectFromPolicy

Utilisé pour indiquer à IBM Tivoli System Automation 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 IBM

Tivoli System Automation :

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 Priority, comme indiqué à la section «Attribut Priority», à la page 40).

v La relation Location entre les ressources membres du groupe de ressources (détaillé dans la section

«Relations Location», à la page 66).

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

44 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Pour des informations supplémentaires, consultez la page d’aide de la commande mkrg ou une

description de la commande dans le manuel IBM Tivoli System Automation for Multiplatforms Base

Component Reference.

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 un nom de noeud lorsque vous utilisez la commande mkrg/chrg.

v établir 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. Utilisez ensuite la

commande mkrg/chrg et l’équivalence requise sera jointe au groupe de ressources. (Pour obtenir des

informations supplémentaires sur les équivalences, consultez le Chapitre 6, «Utilisation des

équivalences», à la page 49).

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 des informations supplémentaires, consultez la page d’aide de la commande addrgmbr ou une

Component Reference.

Enumération d’un groupe de ressources ou de ses ressources

membres

Pour répertorier un groupe de ressources ou ses membres, utilisez 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 groupe de

ressources est spécifié à l’aide de l’option -m , les noms des ressources membres et des 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 :

Groupes de ressources

Chapitre 5. Utilisation des groupes de ressources 45

Groupes de ressources

Affichage des informations liées aux ressources membre :

Classe:Ressource:Noeud[ManagedResource] Mandatory MemberOf OpState

IBM.Application:apache1 True apacherg2 Offline

Exemple 3 : apacherg2 contient une ressource. Pour répertorier les membres d’apacherg2, la commande

suivante est saisie :

lsrg -m -g apacherg2

Cette information s’affiche :

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

Cette information s’affiche :

Resource Group 1:

Name = apacherg2

MemberLocation = None

Priority = 0

AllowedNode = node03

NominalState = Offline

OpState = Offline

Pour des informations supplémentaires, consultez la page d’aide de la commande lsrg ou une description

de la commande dans le manuel IBM Tivoli System Automation for Multiplatforms Base Component

Reference.

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 des informations supplémentaires, consultez la page d’aide de la commande chrg ou une description

Reference.

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

46 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Pour des informations supplémentaires, consultez la page d’aide de la commande chrg ou une description

Reference.

Modification des attributs des membres d’un groupe de ressources

Pour modifier les membres des ressources membres spécifiées, utilisez la commande chrgmbr.

Cette commande vous permet également de spécifier les modifications à apporter à l’attribut Mandatory

d’une ressource gérée à l’aide de l’option-m et de modifier le groupe de ressources auquel appartient la

ressource 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 des informations supplémentaires, consultez la page d’aide de la commande chrgmbr ou une

Component Reference.

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.

IBM Tivoli System Automation 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 des informations supplémentaires, consultez la page d’aide de la commande rmrgmbr ou une

Component Reference.

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 IBM Tivoli System Automation. 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.

Par exemple, pour supprimer les groupes de ressources apacherg2 et apacherg3, entrez :

rmrg apacherg2 apacherg3

Groupes de ressources

Pour des informations supplémentaires, consultez la page d’aide de la commande rmrg ou une

Component Reference.

Chapitre 5. Utilisation des groupes de ressources 47

48 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Chapitre 6. 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 50

v «Règles d’utilisation des équivalences», à la page 50

v «Création d’une équivalence», à la page 51

v «Modification d’une équivalence», à la page 51

v «Suppression d’une équivalence», à la page 52

v «Liste d’une ou plusieurs équivalences», à la page 51

Tableau 7. Commandes IBM Tivoli System Automation utilisées conjointement aux équivalences

Commande Description Pour des

informations

mkequ Créer une ressource d’équivalence

supplémentaires,

consultez les

descriptions de

rmequ Supprimer une ressource d’équivalence

commandes

dans le manuel

IBM Tivoli

chequ Modifier une ressource d’équivalence

System

Automation for

Multiplatforms

lsequ Répertorier les ressources d’équivalence

Base Component

Reference

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, consultez le Chapitre 7, «Utilisation des relations gérées»,

à la page 53.

Il existe deux types d’équivalence :

1. un type possédant une liste d’appartenance statique. Ce type d’équivalence contient un ensemble

spécifique de ressources qu’un utilisateur a ajouté de manière explicite à l’équivalence.

2. un type possédant une liste SelectString qui, à l’exécution, détermine de manière dynamique les

ressources qui seront contenues au sein de l’équivalence. Si des ressources RMC créées

correspondent à la chaîne de sélection dynamique, elles sont automatiquement présentes dans

l’équivalence. Il n’est pas recommandé de spécifier une règle pour ce type d’équivalence car les

ressources ne sont pas classées.

Les équivalences sont fournies dans la classe de ressources IBM.Equivalency d’IBM Tivoli System

Automation.

Equivalences

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.

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)

IBM Tivoli System Automation utilise l’attribut persistant MemberClass afin de déterminer la classe de

ressources de toutes les ressources membres.

Attribut Membership (appartenance)

IBM Tivoli System Automation 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)

IBM Tivoli System Automation 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, IBM Tivoli System Automation 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)

IBM Tivoli System Automation utilise l’attribut persistant SelectFromPolicy afin de déterminer la règle à

utiliser lors de la sélection à partir d’une équivalence. Cet attribut peut être modifié lorsque les groupes de

ressources référençant l’équivalence sont hors ligne. La règle peut être :

Ordered Dans ce cas de figure, si une ressource de l’équivalence échoue, IBM

Tivoli System Automation démarre toujours à partir du début de la liste de

sélection.

Any (par défaut) Dan ce cas de figure, si une ressource de l’équivalence échoue, IBM

Tivoli System Automation choisit une ressource sans se référer à un ordre

de sélection pré-sélectionné.

Remarque : N’utilisez pas une règle Ordered avec un attribut SelectString dynamique.

50 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Attributs utilisés par les membres des équivalences

v Une ressource devant être ajoutée à une équivalence doit posséder cet attribut :

– OpState

v 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 des informations supplémentaires, consultez la page d’aide de la commande mkequ ou la

description de la commande mkequ dans le manuel IBM Tivoli System Automation for Multiplatforms Base

Component Reference.

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

Dans une grappe de systèmes AIX, entrez :

mkequ -D "Name like ’en%’" NetworkInterfacesDynamic IBM.NetworkInterface

Liste d’une ou plusieurs équivalences

Pour répertorier une ou plusieurs équivalences, utilisez la commande lsequ.

Pour des informations supplémentaires, consultez la page d’aide de la commande lsequ ou la description

de la commande lsequ dans le manuel IBM Tivoli System Automation for Multiplatforms Base Component

Reference.

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.

Equivalences

Pour des informations supplémentaires, consultez la page d’aide de la commande chequ ou une

Component Reference.

Chapitre 6. Utilisation des équivalences 51

Equivalences

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 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 des informations supplémentaires, consultez la page d’aide de la commande rmequ ou une

Component Reference.

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

52 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Chapitre 7. 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 54

v «Relations du comportement de démarrage/d’arrêt», à la page 55

v «Relations Location», à la page 66

v «Création et administration des relations», à la page 74

Tableau 8. Commandes IBM Tivoli System Automation utilisées avec les relations gérées

Commande Description Pour des

informations

mkrel Créer une relation gérée

supplémentaires,

consultez les

lsrel Répertorier les relations gérées

descriptions de

commandes dans le

manuel IBM Tivoli

rmrel Supprimer une relation gérée

System Automation

for Multiplatforms

chrel Modifier une relation gérée

Base Component

Reference.

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 54).

Les attributs de relation peuvent être utilisés avec des attributs Condition (décrit dans la section «Attribut

Condition», à la page 55). 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 54, l’attribut Condition

est décrit dans la section «Attribut Condition», à la page 55.

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

Relations gérées

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 DependsOn (Dépendant de) 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 à IBM Tivoli System

Automation de le faire.

Les relations gérées sont fournies dans la classe de ressources IBM Tivoli System Automation

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 37

v «Attributs utilisés par les équivalences», à la page 50

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.

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

54 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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 66), à l’exception de la relation gérée IsStartable. 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 None

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

IBM Tivoli System Automation 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 35 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.

Relations gérées

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 DependsOn (Dépendant de) 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.

Chapitre 7. Utilisation des relations gérées 55

Relations gérées

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.

La relation StartAfter ne propose pas de comportement d’arrêt forcé (voir la section «Relation

DependsOn», à la page 60).

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. IBM

Tivoli System Automation 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, IBM Tivoli System Automation démarre la ressource A. 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.

56 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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 peut 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’IBM Tivoli System Automation 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.

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.

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.

Relations gérées

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.

Chapitre 7. Utilisation des relations gérées 57

Relations gérées

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.

La ressource C doit être En 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 DependsOn 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 66), vous

devez créer une relation supplémentaire à cet effet.

3. Si IBM Tivoli System Automation 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.

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.

58 IBM Tivoli System Automation Composant de base - Guide d’utilisation

La relation StopAfter présente le modèle de comportement suivant :

Relations gérées

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 56 et «Relation DependsOn», à la page 60).

Informations détaillées sur le comportement d’arrêt de la relation 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.

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.

Chapitre 7. Utilisation des relations gérées 59

Relations gérées

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.

Relation DependsOn

IBM Tivoli System Automation utilise la relation DependsOn 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 DependsOn inclut également une colocalisation implicite (détaillé dans la section «Relation

Collocated», à la page 67) entre les ressources source et cible.

v Si une ressource cible échoue, la ressource source sera également arrêtée.

La relation DependsOn 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 DependsOn, 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 DependsOn, 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

DependsOn

La séquence de démarrage de la relation DependsOn 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 DependsOn 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

DependsOn correspond au comportement de la relation colocalisée. Pour des informations

supplémentaires sur ce comportement, consultez la section «Relation Collocated», à la page 67.

60 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Généralement, les ressources A et B sont membres du même groupe de ressources.

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 DependsOn 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 DependsOn est définie entre A et B, le comportement de démarrage

de la relation DependsOn 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

DependsOn, 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 DependsOn force son démarrage. IBM Tivoli System Automation 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, IBM Tivoli

System Automation 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 peut englober la possibilité que la ressource A possède une relation DependsOn avec

les ressources B et C.

Dans ce cas, le démarrage de A implique la mise en ligne des ressources

B et C avant qu’IBM Tivoli System Automation 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.

Chapitre 7. Utilisation des relations gérées 61

Relations gérées

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 DependsOn 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.

Informations détaillées sur le comportement d’arrêt de la relation DependsOn

Vous ne pouvez pas contrôler la séquence d’arrêt de la relation DependsOn à l’aide de l’état opérationnel

(OpState) de la ressource source.

peut alors être arrêtée.

Lorsque l’état opérationnel de la ressource A est hors ligne, la ressource B

Généralement, les ressources A et B sont membres du même groupe de ressources.

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 DependsOn, 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 DependsOn est définie entre A et B. Vous pouvez déclencher le

comportement de démarrage de la relation DependsOn en définissant l’état nominal du groupe de

ressources RG_B sur En ligne (l’arrêt direct des ressources est impossible dans IBM Tivoli System

Automation). En raison de la relation DependsOn, 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 DependsOn provoque son arrêt.

IBM Tivoli System Automation 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

62 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Relations gérées

de démarrage émise sur le groupe de ressources RG_A et a été propagée à l’aide de la relation

DependsOn 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 DependsOn 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.

Des ressources A et B possédant une relation DependsOn 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 DependsOn. 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 DependsOn 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

DependsOn

Le principe de base de la relation DependsOn 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.

Par exemple, définissez une ressource A possédant une relation DependsOn 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.

Chapitre 7. Utilisation des relations gérées 63

Relations gérées

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 (DependsOn) 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

DependsOn :

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 DependsOn

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 DependsOn 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 IBM Tivoli System Automation, 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 DependsOn.

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. Laressource C est membre du groupe de ressources RG_C et les

relations suivantes sont définies : A dépend de (DependsOn) B et B dépend de (DependsOn) C.

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 DependsOn

Il existe une règle d’utilisation de la relation DependsOn :

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 DependsOn à

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 :

64 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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 DependsOn 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, à la page 64.

Consultez la section relative à la relation DependsOn 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

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 :

Relations gérées

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 56, «Relation StopAfter», à la page 58 et «Relation DependsOn», à la

page 60).

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

Chapitre 7. Utilisation des relations gérées 65

Relations gérées

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 IBM Tivoli System

Automation.

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 IBM Tivoli System Automation.

Relations Location

IBM Tivoli System Automation 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’.

66 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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.

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 relatives à l’utilisation des relations Location

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 35 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. La ressource cible de la relation Location ne peut pas être une équivalence.

Relations gérées

4. Si les ressources source et cible forment un groupe, tous les membres du groupe doivent être

colocalisés.

Relation Collocated

IBM Tivoli System Automation 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.

Chapitre 7. Utilisation des relations gérées 67

Relations gérées

La relation Collocated peut être utilisée conjointement à l’attribut Condition, comme indiqué à la page 69.

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 IBM Tivoli System Automation 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.

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, IBM Tivoli System

Automation 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 d’IBM Tivoli System Automation est le suivant :

lorsque la ressource A doit être démarrée, IBM Tivoli System Automation 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, IBM Tivoli System Automation 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.

68 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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, IBM Tivoli System Automation 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.

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

Relations gérées

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.

Relation AntiCollocated

IBM Tivoli System Automation 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

71.

Chapitre 7. Utilisation des relations gérées 69

Relations gérées

Informations détaillées sur le comportement de principe de la 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 IBM Tivoli System Automation 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 .

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, IBM Tivoli

System Automation 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),

IBM Tivoli System Automation 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.

70 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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.

Les relations et conditions suivantes peuvent être définies :

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.

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 d’emplacement est

uniquement valide lorsque la ressource B ne possède pas un é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 55).

Les relations et conditions suivantes peuvent être définies :

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

Relations gérées

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.

Chapitre 7. Utilisation des relations gérées 71

Relations gérées

v Affinity/IfNotOnline

La relation A ---> Affinity/IfNotOnline -----> B signifie que la relation d’emplacement est uniquement

valide lorsque la ressource B ne possède pas un état En ligne.

v Affinity/IfNotOffline

La relation A ---> Affinity/IfNotOffline -----> B signifie que la relation d’emplacement est uniquement

valide lorsque la ressource B ne possède pas un état Hors ligne, Echec hors ligne ou Inconnu.

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 55).

Voir également la section «Relations Location», à la page 66.

Les relations et conditions suivantes peuvent être définies :

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 d’emplacement est uniquement

valide lorsque la ressource B ne possède pas un état En ligne.

v AntiAffinity/IfNotOffline

La relation A ---> AntiAffinity/IfNotOffline -----> B signifie que la relation d’emplacement est uniquement

valide lorsque la ressource B ne possède pas un état Hors ligne, Echec hors ligne ou Inconnu.

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.

72 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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.

Consultez également la section «Relations Location», à la page 66.

Informations détaillées sur le comportement de principe de la 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.

La section suivante illustre les états éventuels de cet exemple :

Relations gérées

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 IBM Tivoli System Automation 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

Chapitre 7. Utilisation des relations gérées 73

Relations gérées

défini sur En ligne, IBM Tivoli System Automation 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.

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 des informations supplémentaires, consultez la page d’aide de la commande mkrel ou la description

de la commande mkrel dans le manuel IBM Tivoli System Automation for Multiplatforms Base Component

Reference.

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 spécifiez le nom de relation à l’aide de l’option -M, les attributs persistants de la relation spécifiée

seront répertoriés. 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

Vous pouvez obtenir un résultat similaire si vous répertoriez toutes les relations dans lesquelles

IBM.Application:FloatWebServerA est la source de (l’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

74 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Classe:Ressource:Noeud[Cible] = {IBM.Application:FloatWebServerB}

Relation = AntiCollocated

Conditionnel = IfOnline

ResourceGroup[Source] = RG_WebApp

Pour des informations supplémentaires, consultez la page d’aide de la commande lsrel ou la description

de la commande lsrel dans le manuel IBM Tivoli System Automation for Multiplatforms Base Component

Reference.

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 des informations supplémentaires, consultez la page d’aide de la commande chrel ou la description

de la commande chrel dans le manuel IBM Tivoli System Automation for Multiplatforms Base Component

Reference.

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

Relations gérées

Pour des informations supplémentaires, consultez la page d’aide de la commande rmrel ou la description

de la commande rmrel dans le manuel IBM Tivoli System Automation for Multiplatforms Base Component

Reference.

Chapitre 7. Utilisation des relations gérées 75

76 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Chapitre 8. Traitement des informations système par IBM

Tivoli System Automation

Ce chapitre décrit tout d’abord l’algorithme de liaison également appelé ″classeur″. Il s’agit d’une fonction

interne d’IBM Tivoli System Automation 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 d’IBM Tivoli System

Automation.

Définition de la relation d’emplacement : algorithme de liaison

Le classeur est appelé lors d’un lancement de ressources pour lesquelles IBM Tivoli System Automation

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 IBM Tivoli System Automation 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 évident que des relations d’emplacement peuvent donner lieu à des

conflits devant être résolus.

Par exemple, deux ressources flottantes A et B peuvent être situées sur les noeuds node1 et node2. En

raison d’une contrainte de performances, les deux ressources ne doivent jamais être exécutées sur le

même noeud. Par conséquent, vous devez spécifier une relation AntiCollocated entre A et B et entre B et

A. Il est supposé que la ressource A fonctionne déjà sur le noeud node1. Le noeud node2 échoue. Si un

utilisateur lance la ressource B, un conflit de relation d’emplacement aura lieu puisque les ressources A et

B ne peuvent être lancées sur le même noeud. Une solution idéale dans laquelle les deux ressources

peuvent fonctionner ne peut être trouvée dans cette situation. Par conséquent, IBM Tivoli System

Automation procède à une résolution spécifique de conflits appelée ″étape d’élimination″ afin de résoudre

la situation.

Il se peut que des ressources déjà en ligne soient impliquées dans le problème. Ces ressources reçoivent

une prime de propriété supplémentaire de 10 dans leur propriété définie par le groupe de ressources.

La section suivante décrit en détail le processus de recherche de solution d’IBM Tivoli System Automation

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)

Logique d’IBM Tivoli System Automation

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 trouver des liaisons comme indiqué dans la rubrique «Relations Location», à la

page 66. 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éé. IBM Tivoli System Automation 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, IBM Tivoli System Automation

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, IBM Tivoli System Automation 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

78 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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, IBM Tivoli System Automation 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, IBM Tivoli System Automation 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.

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 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 membres du

groupe de ressources sont effectués en deux sous-étapes : tout d’abord, seuls les membres

facultatifs du niveau de priorité du groupe sont arrêtés et ignorés dans la solution de liaison. Cette

seule opération ne suffit pas à résoudre le conflit, les membres obligatoires du même niveau de

priorité du groupe doivent ensuite être arrêtés et supprimés de l’évaluation de la liaison. Si le conflit

persiste, le prochain groupe avec la priorité la plus faible est sélectionné et tous les membres de

groupe sont arrêtés comme indiqué ci-dessus. Cette opération est réalisée de manière itérative

jusqu’à ce qu’une solution de liaison soit trouvée.

Astuces :

Logique d’IBM Tivoli System Automation

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 membres facultatifs doivent posséder une priorité inférieure à celle des membres

obligatoires. Le cas échéant, les membres obligatoires peuvent être supprimés.

Evénements permettant la mise en ligne d’un groupe de ressources

Tous les groupes de ressources “root” dont l’attribut NominalState est En ligne seront automatisés :

c’est-à-dire qu’une tentative de démarrage des groupes de ressources “root” 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 IBM Tivoli System Automation qu’il doit à nouveau essayer de lancer le groupe de ressources.

Chapitre 8. Traitement des informations système par IBM Tivoli System Automation 79

Logique d’IBM Tivoli System Automation

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 38) du groupe de

ressources, par exemple, afin d’inclure un noeud supplémentaire à l’endroit où le groupe de ressources

peut être lancé. Pour obtenir des informations détaillées, consultez la description de la commande chrg

dans le manuel IBM Tivoli System Automation for Multiplatforms Base Component Reference.

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

obtenir des informations détaillées, consultez la description de la commande rmrgmbr dans le manuel

IBM Tivoli System Automation for Multiplatforms Base Component Reference.

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 IBM Tivoli System Automation. Par conséquent, les ressources membres peuvent être

démarrées car une relation gérée peut être satisfaite. Pour obtenir des informations détaillées, consultez

la description de la commande addrgmbr dans le manuel IBM Tivoli System Automation for

Multiplatforms Base Component Reference.

v Lancement d’une ressource non contrôlable par IBM Tivoli System Automation 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 à IBM Tivoli System Automation 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 obtenir des informations

détaillées, consultez la description de la commande chrgmbr dans le manuel IBM Tivoli System

Automation for Multiplatforms Base Component Reference.

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 IBM Tivoli System

Automation. Pour des informations détaillées, consultez la page d’aide de la commande RMC

resetrsrc.

v Un noeud Hors ligne est désormais En ligne. IBM Tivoli System Automation 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

Priority», à la page 40). 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.

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 obtenir des

informations détaillées, consultez la description de la commande chrg dans le manuel IBM Tivoli

System Automation for Multiplatforms Base Component Reference.

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.

80 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Modèles de comportement d’IBM Tivoli System Automation for

Multiplatforms

Cette section décrit comment IBM Tivoli System Automation se comporte et comment il réagit dans

certaines situations.

Considérations générales

La section suivante décrit 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 spécifiée dans l’attribut de démarrage

d’une ressource pour mettre une ressource En ligne. La commande de démarrage d’une ressource est

exécutée dans les situations suivantes :

v Immédiatement après la modification de l’attribut NominalState d’un groupe de ressources à l’état En

ligne et satisfaction de toutes les dépendances de démarrage de cette ressource.

v Immédiatement après la modification de l’état opérationnel d’une ressource de En ligne à Hors ligne

lors d’un incident de ressource (remarque : cette remarque ne s’applique pas si l’état nominal d’un

groupe de ressources est passé à Hors ligne ou si la ressource a été arrêtée par IBM Tivoli System

Automation afin de répondre à une dépendance d’une autre ressource.)

v 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 restant (RetryCount) pour exécuter la commande de démarrage n’a pas été atteint. Le délai

d’attente de mise en ligne d’une ressource est calculé à l’aide de la formule suivante :

MAX( Délai d’expiration de la commande de démarrage, Durée de la commande de contrôle ) + 10

Notez qu’il ne s’agit pas d’une valeur absolue, car IBM Tivoli System Automation n’utilise pas de

véritable temporisateur. Les démons IBM Tivoli System Automation sont réveillés plus fréquemment,

aussi, le délai d’attente de mise en ligne peut être compris entre 10 et 13 secondes. Notez également

que ce délai d’attente de mise en ligne est calculé uniquement si l’état opérationnel de la ressource n’a

pas été modifié lors des dernières exécutions de la commande de démarrage (par exemple : si l’état est

passe de En attente à En ligne ou Hors ligne). Alors 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.

La commande de démarrage est exécutée de manière synchrone par IBM Tivoli System Automation, ce

qui signifie que IBM Tivoli System Automation attend la fin de l’exécution de la commande et prend

connaissance de tout code retour éventuel. En outre, il existe un attribut StartCommandTimeout pour

chaque ressource qui détermine le temps d’exécution maximal 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 IBM Tivoli System Automation à l’aide de la commande SIGKILL. Si cette éventualité se

produit, un message est consigné dans le journal système de ce noeud. Des incidents peuvent toutefois

se produire si un processus applicatif lancé au sein de la commande de démarrage ne renvoie aucun

contrôle. Dans ce cas, le processus applicatif est détruit chaque fois que le délai d’attente

StarCommandTimeout arrive à expiration et qu’IBM Tivoli System Automation ne peut démarrer cette

application en tant que ressource. Pour un bon fonctionnement, 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 &

Logique d’IBM Tivoli System Automation

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,

Chapitre 8. Traitement des informations système par IBM Tivoli System Automation 81

Logique d’IBM Tivoli System Automation

IBM Tivoli System Automation 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. Dans ce cas de figure, IBM Tivoli System Automation 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. En lieu et place, la commande de démarrage est exécutée à nouveau si la

ressource n’est pas remise en ligne au cours du délai d’attente de mise en ligne une fois le nombre de

tentatives restant (RetryCount) expiré.

Problèmes liés à la commande de contrôle (Monitor)

La commande de contrôle d’une ressource IBM.Application est utilisée par IBM Tivoli System Automation

afin de déterminer l’état opérationnel de cette ressource sur un noeud. IBM Tivoli System Automation

lance le contrôle d’une ressource lorsqu’elle est ajoutée à un groupe de ressources. Le contrôle est

effectué sur un noeud quelconque que cette ressource est autorisée à exécuter dans (Liste des noms de

noeuds). Après une première exécution, la commande de contrôle est exécutée à une fréquence définie

dans l’attribut MonitorCommandPeriod. Le contrôle de cette ressource sera effectué indéfiniment sur

chaque noeud dans lequel la ressource est définie jusqu’à ce que la ressource soit supprimée du groupe

de ressources.

A partir de la version 1.2 d’IBM Tivoli System Automation, 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 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. 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 bizarres :

1. La commande de contrôle est exécutée dans tous les noeuds sur lesquels la ressource est autorisée à

fonctionner (ces noeuds sont définis dans l’attribut NodeNameList des ressources). Si une ressource

doit être fermée (c.-à-d. si l’état nominal du groupe de ressources est Hors ligne) et qu’un opérateur

lance cette ressource manuellement, IBM Tivoli System Automation en prend note à l’aide de la

commande de contrôle (MonitorCommand) de cette ressource et exécute finalement la commande

d’arrêt (StopCommand) de cette ressource pour la remettre Hors ligne.IBM Tivoli System Automation

est conçu à cette fin : automatiser les ressources. 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 d’IBM Tivoli System Automation (la commande rgreq). L’état nominal du groupe de

ressources sera rejeté ce qui permettra le démarrage d’une ressource du groupe de ressources même

si l’état nominal de la ressource est Hors ligne.

2. Il existe un attribut MonitorCommandTimeout qui provoque l’exécution d’une commande SIGKILL sur la

commande de contrôle si celle-ci n’est pas achevée avant l’expiration du délai d’attente. Si la

commande de contrôle a été supprimée, un message sera consigné dans le journal système de ce

noeud et l’état opérationnel de la ressource sera défini sur Inconnu. Dans ce cas, IBM Tivoli System

Automation n’automatisera plus ce procédé ni les ressources dépendantes tant qu’un état important ne

peut être de nouveau déterminé. 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)

La commande d’arrêt est exécutée par défaut de manière synchrone par IBM Tivoli System Automation, ce

qui signifie qu’IBM Tivoli System Automation 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 IBM

Tivoli System Automation à l’aide de la commande SIGKILL. Si cette éventualité se produit, un message

est consigné dans le journal système de ce noeud. Cependant, comme la commande d’arrêt est appelée

une seule fois, des incidents peuvent se produire, car la valeur de l’attribut RetryCount (Nombre de

82 IBM Tivoli System Automation Composant de base - Guide d’utilisation

tentatives) n’est pas respectée. Si une ressource ne peut être arrêtée en raison du délai d’expiration de la

commande d’arrêt ou pour toute autre raison, IBM Tivoli System Automation ne peut poursuivre

l’automatisation, ni celle des ressources dépendantes. Par conséquent, il importe de choisir une valeur

appropriée pour l’attribut StopCommandTimeout (délai d’expiration de la commande d’arrêt) et de

s’assurer que la commande d’arrêt (StopCommand) provoquera réellement l’arrêt de la ressource, si elle

est appelée par IBM Tivoli System Automation.

Réaction d’IBM Tivoli System Automation 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 4. 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 DependsOn Res2

v Les ressources sont En ligne sur le noeud Node1.

Logique d’IBM Tivoli System Automation

Chapitre 8. Traitement des informations système par IBM Tivoli System Automation 83

Logique d’IBM Tivoli System Automation

Le diagramme suivant illustre à titre de référence le flot habituel des états opérationnels des ressources

gérées par IBM Tivoli System Automation :

Figure 5. Diagramme de l’état des ressources d’IBM Tivoli System Automation

Il existe sept états opérationnels (OpState) pour une ressource. L’état opérationnel d’une ressource est

déterminé par IBM Tivoli System Automation à l’aide de la commande de contrôle. L’état courant d’une

ressource est fourni par IBM Tivoli System Automation à 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 à IBM Tivoli System

Automation 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 IBM Tivoli System Automation. Par exemple, si l’état opérationnel Inconnu est défini pour une

ressource et si le délai d’exécution de la commande de contrôle est arrivé à expiration. IBM Tivoli System

Automation ne connaît par conséquent plus l’état opérationnel de cette ressource.

Les deux tableaux suivants illustrent les réactions d’IBM Tivoli System Automation 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 IBM Tivoli System Automation en fonction de la valeur retour de la commande de contrôle de

Res1.

Tableau 9. 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

84 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Deuxième action d’automatisation de

système

Tableau 9. Actions d’automatisation de système en fonction des modifications d’état opérationnel de la ressource

Res1 (suite)

RC=0 (Inconnu) => Aucune, attendre la prochaine

commande de contrôle avec RC0

Aucune

RC=1 (En ligne => Aucune Aucune

RC=2 (Hors ligne) => Lancer 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

Res2.

Tableau 10. Actions d’automatisation de système en fonction des modifications d’état opérationnel de la ressource

Res2

Commande de contrôle

(état opérationnel)

Première action d’automatisation de

système

RC=0 (Inconnu) => Aucune, attendre la prochaine

commande de contrôle avec RC0

Deuxième action d’automatisation de

système

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

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

Logique d’IBM Tivoli System Automation

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 cet attribut, IBM Tivoli System Automation détermine les ressources qui doivent être

démarrées ou arrêtées afin de respecter les principes de la règle modifiée.

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

Chapitre 8. Traitement des informations système par IBM Tivoli System Automation 85

Logique d’IBM Tivoli System Automation

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.

Le tableau suivant montre comment IBM Tivoli System Automation 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 11. 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

groupe de ressources

Inconnu Inconnu => Inconnu Aucune

Hors ligne Hors ligne => Hors ligne Aucune

Action d’automatisation

de système

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

IBM Tivoli System Automation automatise généralement les ressources en fonction de l’état nominal du

groupe de ressources et des valeurs d’état opérationnel des ressources. Le but est d’atteindre un état où

l’état opérationnel de la ressource et l’état nominal du groupe de ressources de la ressource sont

identiques. En outre, IBM Tivoli System Automation 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, IBM Tivoli System Automation agit également et procède au basculement de la

ressource vers un autre noeud autorisé. Les sections suivantes décrivent les actions effectuées par IBM

Tivoli System Automation 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) de la ressource.

Commande de démarrage (StartCommand)

Les tableaux suivants illustrent les réactions d’IBM Tivoli System Automation 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).

86 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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 12. 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

Commande de démarrage lancée

mais pas terminée.

Action d’automatisation de

système

RC=0 (Inconnu) Aucune, attendre que la commande

de contrôle renvoie RC0

RC=1 (En ligne Démarrer une autre ressource, si elle

existe

RC=2 (Hors ligne) Attendre En ligne

RC=3 (Echec Hors ligne) Exécuter la commande d’arrêt sur la

ressource et basculer vers un autre

noeud, procéder probablement à

l’arrêt forcé d’autres ressources

dépendantes

RC=4 (Arrêt en ligne) Improbable, attendre action de

l’opérateur

RC=5 (En attente en ligne) Attendre En ligne

RC=6 (En attente hors ligne) Improbable, attendre En ligne

Notez que lorsque la commande de contrôle a déclaré la ressource comme étant en ligne, IBM Tivoli

System Automation ne prend pas en considération le fait que la commande de démarrage soit toujours en

cours d’exécution ou non, car l’objectif de mise en ligne de la ressource est déjà atteint.

La commande de démarrage s’est achevée avec succès : Ce tableau décrit le comportement habituel

d’IBM Tivoli System Automation :

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

Commande de démarrage Commande de contrôle

RC=0 (succès) et nombre de

tentatives actuel < RetryCount

(samctrl)

Logique d’IBM Tivoli System Automation

Action d’automatisation de

système

RC=0 (Inconnu) Aucune, attendre que la commande

de contrôle renvoie RC0

RC=1 (En ligne) Démarrer une autre ressource, si elle

existe

RC=2 (Hors ligne) Après expiration du délai d’attente de

mise en ligne : effectuer une nouvelle

tentative de démarrage, augmenter le

nombre de tentatives

RC=3 (Echec Hors ligne) Exécuter la commande d’arrêt sur la

ressource et basculer vers un autre

noeud, procéder probablement à

l’arrêt forcé d’autres ressources

dépendantes

RC=4 (Arrêt en ligne) Improbable, attendre action de

l’opérateur

RC=5 (En attente en ligne) Attendre En ligne

RC=6 (En attente hors ligne) Improbable, attendre En ligne

Chapitre 8. Traitement des informations système par IBM Tivoli System Automation 87

Logique d’IBM Tivoli System Automation

Tableau 13. Actions d’automatisation de système et commande de démarrage achevée avec succès (suite)

Commande de démarrage Commande de contrôle

RC=0 (succès) et nombre de

tentatives actuel = RetryCount

(samctrl) après expiration du délai

d’attente de mise en ligne

Action d’automatisation de

système

Définir la ressource sur Echec hors

ligne, envoyer la commande d’arrêt

pour la ressource et basculer vers un

autre noeud. Probablement : procéder

à l’arrêt forcé d’autres ressources

dépendantes

La commande de démarrage s’est achevée avec une erreur ou a expiré : Le tableau suivant décrit le

comportement d’IBM Tivoli System Automation lorsque la commande de démarrage d’une ressource

renvoie une erreur ou expire, en fonction de l’état opérationnel de la ressource :

Tableau 14. 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

RC=0 (Inconnu) RC=1 (autre que zéro) échec ou

expiration

RC=1 (En ligne) RC=1 (autre que zéro) échec ou

expiration

RC=2 (Hors ligne) RC=1 (autre que zéro) échec ou

expiration

RC=3 (Echec Hors ligne) RC=1 (autre que zéro) échec ou

expiration

RC=4 (Arrêt en ligne) RC=1 (autre que zéro) échec ou

expiration

88 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Action d’automatisation de

système

Lorsque la commande de contrôle

rapporte l’état Inconnu, IBM Tivoli

System Automation attend le renvoi

de RC0 par la commande de

contrôle, notamment lorsque la

commande de démarrage RC (ou le

délai d’attente) est ignoré.

Si le prochain contrôle valide est En

ligne, la ressource reste En ligne, si

le prochain contrôle valide est Hors

ligne, la commande de démarrage est

exécutée à nouveau.

Après renvoi de En ligne par la

commande de contrôle, la

commande de démarrage RC (ou le

délai d’attente) est ignorée. Aucune

autre action, la ressource reste En

ligne.

Immédiatement après renvoi de RC=1

par la commande de démarrage, IBM

Tivoli System Automation arrête la

ressource et un basculement a lieu.

Immédiatement après renvoi de RC=1

par la commande de démarrage, un

basculement de la ressource a lieu

(pas d’exécution de la commande

d’arrêt, car la ressource a déjà

échoué).

Improbable, immédiatement après

renvoi de RC=1 par la commande de

démarrage, IBM Tivoli System

Automation arrête la ressource et

attend une action de l’opérateur

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

expire (suite)

Commande de contrôle Commande de démarrage

RC=5 (En attente en ligne) RC=1 (autre que zéro) échec ou

expiration

RC=6 (En attente hors ligne) RC=1 (autre que zéro) échec ou

expiration

Action d’automatisation de

système

Immédiatement après renvoi de RC=1

par la commande de démarrage, IBM

Tivoli System Automation arrête la

ressource et un basculement a lieu

lorsque la ressource est déclarée

Hors ligne.

Improbable, immédiatement après

renvoi de RC=1 par la commande de

démarrage, IBM Tivoli System

Automation arrête la ressource et un

basculement a lieu lorsque la

ressource est déclarée Hors ligne.

Notez que le code retour de la commande de démarrage du tableau ci-dessus est ignoré si la commande

de contrôle a déjà déclaré la commande de contrôle comme étant En ligne. Les résultats des deux

commandes sont incompatibles : la commande de démarrage déclare à IBM Tivoli System Automation que

le démarrage de la ressource a échoué alors que la commande de contrôle a déjà déclaré la ressource

comme étant En ligne. Il s’agit d’une erreur de script dans la commande de démarrage ou de contrôle.

Notez également que le code retour de la commande de démarrage n’a aucun effet si la ressource est

déclarée Inconnue. Dans ce cas, IBM Tivoli System Automation attend un état opérationnel valide (autre

qu’Inconnu) pour la ressource et l’automatisation aura lieu après réception d’un autre code retour valide

(autre qu’Inconnu) de la commande de contrôle.

Commande d’arrêt (StopCommand)

Les tableaux suivants illustrent les réactions d’IBM Tivoli System Automation aux modifications d’état

opérationnel lors de l’exécution de la commande d’arrêt. Un tableau est présent 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 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 15. 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

Commande d’arrêt lancée mais pas

terminée.

Logique d’IBM Tivoli System Automation

Action d’automatisation de

système

RC=0 (Inconnu) Aucune, attendre la prochaine

commande de contrôle avec RC0

RC=1 (En ligne Attendre 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) Improbable, attendre Hors ligne

RC=6 (En attente hors ligne) Attendre Hors ligne

Chapitre 8. Traitement des informations système par IBM Tivoli System Automation 89

Logique d’IBM Tivoli System Automation

Notez que lorsque la commande de contrôle a déclaré la ressource comme possédant l’état hors ligne ou

échec hors ligne, IBM Tivoli System Automation ne prend pas en considération le fait que la commande

d’arrêt soit toujours en cours d’exécution ou non, car l’objectif de mise en ligne de la ressource est déjà

atteint.

La commande d’arrêt s’est achevée avec succès : Ce tableau décrit le comportement habituel d’IBM

Tivoli System Automation :

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

Commande d’arrêt Commande de contrôle

Action d’automatisation de

système

RC=0 (Succès) RC=0 (Inconnu) Aucune, attendre la commande de

contrôle avec RC0

RC=1 (En ligne) Attendre 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) Improbable, attendre Hors ligne

RC=6 (En attente hors ligne) Attendre Hors ligne

La commande d’arrêt s’est achevée avec une erreur ou a expiré :

Tableau 17. 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

RC=1 (autre que zéro : échec ou

expiration)

Action d’automatisation de

système

RC=0 (Inconnu) Aucune, attendre la commande de

contrôle avec RC0

RC=1 (En ligne) Attendre 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) Improbable, attendre Hors ligne

RC=6 (En attente hors ligne) Attendre Hors ligne

IBM Tivoli System Automation ne respecte pas le code retour de la commande d’arrêt. Dans tous les cas,

la commande d’arrêt est appelée une seule fois et IBM Tivoli System Automation attend la mise hors ligne

de la ressource. Si la mise hors ligne n’a pas lieu, aucune action d’automatisation ne peut être exécutée ni

aucune autre ressource dépendante. Le nombre de tentatives (RetryCount) n’a aucun effet sur l’exécution

de la commande d’arrêt.

90 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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 IBM Tivoli System Automation 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 18. 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 Action 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 RC0.

RC=1 (En ligne) Les ressources dans les deux noeuds sont arrêtées (et

toutes les ressources qui dépendent de ces ressources).

Ensuite, les ressources sont 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

Logique d’IBM Tivoli System Automation

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’IBM Tivoli System Automation 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 DependsOn (Dépendant de) 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 IBM Tivoli System Automation.

Chapitre 8. Traitement des informations système par IBM Tivoli System Automation 91

92 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Chapitre 9. Utilisation de la console des opérations

Ce chapitre présent un aperçu de la console des opérations et explique comment l’installer et l’utiliser en

mode d’accès direct, mode disponible pour les utilisateurs d’composant de base d’IBM Tivoli System

Automation.

Pour les utilisateurs de la gestion intégrale de l’automatisation composant d’IBM Tivoli System Automation

for Multiplatforms, deux autres noeuds sont disponibles. Ils sont décrits dans le manuel Gestion de

l’automatisation de bout en bout : Guide d’utilisation et de référence.

Vue d’ensemble - Qu’est-ce que la console des opérations ?

La console des opérations est une interface graphique d’utilisateur basée sur un navigateur fonctionnant

sur une console IBM ISC. Vous utilisez la console des opérations pour contrôler et gérer les ressources

gérées par IBM Tivoli System Automation. Elle comprend les éléments suivants :

v Serveur d’applications WebSphere intégré dans la console ISC

v Console ISC, fonctionnant en tant qu’application dans le serveur d’applications WebSphere. La console

ISC (Integrated Solutions Console) peut héberger plusieurs interfaces d’applications. La console des

opérations d’IBM Tivoli System Automation for Multiplatforms est l’une de ces applications.

v La console des opérations, représentant l’interface utilisée par les opérateurs, s’exécute dans la console

ISC.

v Les opérateurs utilisent un navigateur Web pour contacter la console ISC et afficher la console des

opérations.

La figure suivante illustre la configuration de la console des opérations pour l’utilisateur du composant de

base et pour l’utilisateur du composant de la gestion de l’automatisation de bout en bout d’IBM Tivoli

System Automation.

Figure 6. Présentation de la console des opérations

Le composant de base d’IBM Tivoli System Automation concerne la figure de gauche qui illustre comment

la console des opérations est utilisée en mode d’accès direct sans avoir recours à l’automatisation de bout

en bout. 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. Le composant gestion intégrale de l’automatisation

d’IBM Tivoli System Automation for Multiplatforms dispose de deux autres 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 manuel Gestion de l’automatisation de bout en bout : Guide d’utilisation et de référence.

Les domaines d’IBM Tivoli System Automation for Multiplatforms peuvent être soit contrôlés par la console

des 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.

Installation de la console des opérations

Cette section décrit comment installer la console des opérations. L’installation fait appel à un programme

d’installation graphique portant le nom d’assistant d’installation. Les étapes à suivre sont décrites

ci-dessous.

Remarque : Bien que les écrans se rapportent à une installation sous Linux, les écrans qui s’affichent

pour d’autres systèmes d’exploitation se présentent de manière similaire. Veillez à respecter

les conditions requises par votre plateforme lorsque vous spécifiez les répertoires, les noms

de fichiers, etc.

94 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Espace disque requis pour l’installation de la console des opérations

Le tableau suivant répertorie l’espace disque requis pour les systèmes Windows.

Tableau 19. Espace disque requis pour une installation sous Windows

Description Répertoire par défaut

Répertoire d’installation du

composant de base

Répertoire d’installation de la console

des opérations

Historique de l’installation et fichiers

de réponses

Espace disque temporaire requis

pour l’installation

Espace

disque

C:\Program Files\IBM\tsamp\eez 60 Mo

C:\Program Files\IBM\ISC 700 Mo

Valeur de la variable système %TEMP%. Il s’agit généralement

de :

C:\Documents and Settings\Administrateur\

Local Settings\Temp

Valeur de la variable système %TEMP%. Il s’agit généralement

de :

C:\Documents and Settings\Administrateur\

Local Settings\Temp

75 Mo

100 Mo

Tivoli Common Directory C:\Program Files\IBM\tivoli\common\eez 250 Mo

Responsable de l’installation du

registre

C:\Windows\vpd.properties 10 Ko

Le tableau suivant répertorie l’espace disque requis sur les systèmes AIX et Linux :

Tableau 20. Espace disque requis pour l’installation sur les systèmes AIX et Linux

Description Répertoire par défaut Espace disque

Répertoire d’installation du

composant de base

Répertoire d’installation de la console

des opérations

Historique de l’installation et fichiers

de réponses

Espace disque temporaire requis

pour l’installation

/opt/IBM/tsamp/eez 60 Mo

/opt/IBM/ISC 700 Mo

/tmp 75 Mo

/tmp 100 Mo

Tivoli Common Directory /var/ibm/tivoli/common/eez 250 Mo

Responsable de l’installation du

registre

-root/vpd.properties 10 Ko

CD/archives pour la console des opérations

opérations se trouve sur le CD/archive suivant :

CD de la console des opérations

Le tableau ci-dessous répertorie les versions des CD de la console des opérations actuellement

disponibles pour le composant de base. Pour installer la console des opérations, lancez l’assistant

d’installation à partir du fichier répertorié dans la colonne de droite du tableau.

Chapitre 9. Utilisation de la console des opérations 95

Tableau 21. Versions du produit sur CD

Système

d’exploitation Nom du produit sur le CD Fichier d’installation

Windows IBM Tivoli System Automation Multiplatform

V2.1.0

Base component Operations Console for

Windows

AIX IBM Tivoli System Automation Multiplatform

V2.1.0

Base component Operations Console for AIX

Linux for IBM

x/Series

IBM Tivoli System Automation Multiplatform

V2.1.0

Base component Operations Console for Linux

xSeries

Linux PPC IBM Tivoli System Automation Multiplatform

V2.1.0

Base component Operations Console for Linux

PPC

Linux for IBM

z/Series

IBM Tivoli System Automation Multiplatform

V2.1.0

Base component Operations Console for Linux

zSeries

EEZ2100E2EWindows/Windows/setup.exe

EEZ2100E2EAIX/AIX/setup

EEZ2100E2EI386/i386/setup

EEZ2100E2EPPC/ppc/setup

EEZ2100E2ES390/s390/setup

Envoi électronique

Vous pouvez également vous procurer le composant de base par voie électronique. Dans ce cas,

téléchargez les produits livrables à partir de l’URL que vous avez reçue après avoir acheté le produit.

Archives :

Windows :

Tableau 22. Archives pour les plateformes Windows

Nom de l’archive Description

C84Q3ML.exe Il s’agit de l’archive que vous utilisez pour installer la console des opérations.

AIX :

Tableau 23. Archives pour les plateformes AIX

Nom de l’archive Description

L’archive se décompresse automatiquement.Une fois les fichiers décompressés,

l’assistant d’installation se trouve dans le répertoire suivant :

EEZ2100E2EWindows/Windows/setup.exe

C84Q4ML.bin Il s’agit de l’archive que vous utilisez pour installer la console des opérations.

L’archive se décompresse automatiquement.Une fois les fichiers décompressés,

l’assistant d’installation se trouve dans le répertoire suivant :

EEZ2100E2EAIX/AIX/setup

96 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Linux sur IBM x/Series :

Tableau 24. Archives pour Linux sur IBM x/Series

Nom de l’archive Description

C84Q5ML.tar Il s’agit de l’archive que vous devez utiliser pour installer le produit.

PPC Linux :

Tableau 25. Archives pour PPC Linux

Nom de l’archive Description

Utilisez la commande tar xf pour décompresser l’archive. Une fois les fichiers

décompressés, l’assistant d’installation se trouve dans le répertoire suivant :

EEZ2100E2EI386/i386/setup

C84Q6ML.tar Il s’agit de l’archive que vous devez utiliser pour installer le produit.

Linux sur z/Series :

Tableau 26. Archives pour Linux sur z/Series

Nom de l’archive Description

Utilisez la commande tar xf pour décompresser l’archive. Une fois les fichiers

décompressés, l’assistant d’installation se trouve dans le répertoire suivant :

EEZ2100E2EPPC/ppc/setup

C84Q7ML.tar Il s’agit de l’archive que vous devez utiliser pour installer le produit.

Utilisez la commande tar xf pour décompresser l’archive. Une fois les fichiers

décompressés, l’assistant d’installation se trouve dans le répertoire suivant :

EEZ2100E2ES390/s390/setup

Procédure d’installation

Pour installer la console des opérations, procédez comme suit :

1. Insérez le CD suivant dans le lecteur CD :

IBM Tivoli System Automation Multiplatform V2.1.0 Base component Operations

Console

Il y a plusieurs CD.Assurez-vous d’utiliser le CD correspondant à votre plateforme.

__________________________________________________________________________

2. Lancez l’assistant d’installation en démarrant le programme suivant à partir du répertoire de base du

CD :

v Windows: setup.exe

v AIX, Linux: setup

Si l’assistant a été correctement lancé, l’écran d’accueil s’affiche.

__________________________________________________________________________

Chapitre 9. Utilisation de la console des opérations 97

3. Sur l’écran d’accueil, cliquez sur Next pour afficher l’écran du contrat de licence.

__________________________________________________________________________

4. Sélectionnez I accept the terms of the license agreement et cliquez sur Next

__________________________________________________________________________

5. Indiquez le répertoire dans lequel vous souhaitez installer la console des opérations ou accepter

l’emplacement par défaut.

Cliquez sur Next.

98 IBM Tivoli System Automation Composant de base - Guide d’utilisation

__________________________________________________________________________

6. Précisez les paramètres pour le serveur de réseau Cloudscape intégré ou accepter les paramètres

par défaut.

Cliquez sur Next.

__________________________________________________________________________

7. Choisissez un ID et un mot de passe utilisateur pour l’administrateur de la console des opérations.

Cliquez sur Next.

Chapitre 9. Utilisation de la console des opérations 99

__________________________________________________________________________

8. Désignez les ports que vous souhaitez utiliser pour la console des opérations ou accepter les valeurs

par défaut. Cliquez sur Next.

__________________________________________________________________________

9. Indiquez le numéro de port pour le serveur Eclipse Help System ou accepter la valeur par défaut , et

cliquez sur Next.

100 IBM Tivoli System Automation Composant de base - Guide d’utilisation

__________________________________________________________________________

10. Si vous souhaitez enregistrer le serveur de la console des opérations et le serveur Eclipse Help

System en tant que services système, indiquez les ID de service et cliquez sur Next.

__________________________________________________________________________

11. Une fois les informations requises entrées dans les écrans de l’assistant, un écran récapitulatif

apparaît. Cliquez sur Install. L’assistant d’installation commence à installer la console des opérations.

Remarque : Notez que le délai d’installation peut prendre deux heures.

Chapitre 9. Utilisation de la console des opérations 101

__________________________________________________________________________

12. Une fois la console des opérations correctement installée, un écran récapitulatif apparaît.Cliquez sur

Finish pour fermer l’assistant d’installation.

__________________________________________________________________________

Configuration de l’adaptateur d’automatisation de bout en bout pour

utiliser la console des opérations

L’adaptateur d’automatisation de bout en bout de System Automation for Multiplatforms doit être configuré

afin de pouvoir accéder directement à la console des opérations. La section «Onglet Hôte utilisant

l’adaptateur», à la page 155 décrit la procédure de configuration correspondante.

Voir «Configuration de l’adaptateur d’automatisation de bout en bout de System Automation for

Multiplatforms», à la page 149 pour en savoir plus sur l’adaptateur d’automatisation de bout en bout de

System Automation for Multiplatforms .

102 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Configuration de la console des opérations pour être utilisée en mode

d’accès direct

Cette configuration est nécessaire si votre console des opérations ne peut utiliser de port 2002 pour

recevoir des événements à partir des adaptateurs, ou si vous souhaitez qu’une couche SSL (Secure

Socket Layer) transmette les requêtes à partir de la console des opérations à l’adaptateur.

Planification de la configuration

Si vous souhaitez modifier le port, procurez-vous un numéro de port valide de la part de votre

administrateur de réseau. Notez que les adaptateurs connectés à la console des opérations doivent

comporter le même 'Port d’événement' spécifié.

La console des opérations prend en charge la couche SSL mais elle ne l’applique pas sur les

adaptateurs.Si la couche SSL est utilisée à des fins de transfert, elle est spécifiée dans la configuration de

l’adaptateur sous la rubrique ’Sécurité’ (voir «Onglet Sécurité», à la page 158). Tous les adaptateurs qui

utilisent SSL doivent avoir le même magasin de certificats, magasin de clés, nom d’alias et mot de passe

pour le fichier du magasin de clés spécifié. La console des opérations utilise les mêmes informations. Par

conséquent, le fichier de magasin de certificats et le fichier de magasin de clés doivent être placés sur

l’hôte de la console des opérations.

Si aucun magasin de certificat ou de clé n’a été généré jusqu’à présent, vous devrez utiliser l’outil

’ikeyman’ dans AppServer/bin de l’installation de la console des opérations pour les générer. Suite à cela,

vous devriez obtenir les informations concernant les fichiers de magasin de certificats et de clés, ainsi que

le nom d’alias et le mot de passe pour accéder au magasin de clés.

Exécution du script de configuration pour la console des opérations

en mode d’accès direct

Dans une invite de commande (sous Windows) ou dans un shell de commandes (sous Linux ou AIX),

allez dans le répertoire suivant, si vous avez préalablement installé la console des opérations dans le

sous-répertoire .

Sous Windows :

\AppServer\profiles\default\Tivoli\EEZ

Sous Linux ou AIX :

/opt//AppServer/profiles/default/Tivoli/EEZ

Pour exécuter le script et obtenir les paramètres actuels, tapez :

cfgdirect

sous Windows et

./cfgdirect.sh

sous Linux ou AIX.

Cette commande sert à configurer la console des opérations pour accéder directement aux domaines

d’automatisation d’IBM Tivoli System Automation for Multiplatforms.

Vous pouvez obtenir de l’aide par le biais de l’option -h de la commande cfgdirect (cfgdirect -h). Le format

de cette commande se présente sous cette forme :

cfgdirect [port:n] [truststore:t] [keystore:k] [alias:a] [password:p]

Chapitre 9. Utilisation de la console des opérations 103

où

n correspond au numéro du port chargé de recevoir les événement issus de l’adaptateur.

t correspond au chemin d’accès au fichier de clés publiques.

k correspond au chemin d’accès vers le fichier de clés privées.

a correspond au nom d’alias pour accéder à la clé privée dans le magasin de clés.

p correspond au mot de passe pour accéder au magasin de clés.

Si la configuration n’a jamais été exécutée jusqu’à présent, vous obtiendrez la sortie suivante :

C:\ISC\AppServer\profiles\default\Tivoli\EEZ> cfgdirect

Il n’existe aucune mise à jour de configuration à enregistrer.

Fichier de configuration : C:\ISC\AppServer\profiles\default\Tivoli\EEZ\directui.properties

eif-receive-from-port = 2002

eez-ssl-truststore =

eez-ssl-keystore =

eez-ssl-keystore-password =

eez-ssl-keystore-alias =

Utilisez l’outil C:\ISC\bin\ikeyman.bat pour générer les clés.

Au lieu d’indiquer ces informations dans une commande, vous pouvez également indiquer une instruction

à la la fois :

cfgdirect port:12002

cfgdirect truststore:C:\ISC\AppServer\profiles\default\Tivoli\EEZ\directui.ssl.truststore.jks

cfgdirect truststore:C:\ISC\AppServer\profiles\default\Tivoli\EEZ\directui.ssl.clientkeys.jks

cfgdirect alias:clientkeys password:passphrase

Démarrage et arrêt d’Integrated Solutions Console

Pour pouvoir utiliser la console des opérations et afficher l’aide en ligne concernant la console, les deux

serveurs Integrated Solutions Console et Eclipse Help System doivent être démarrés. Les rubriques

suivantes expliquent comment démarrer et arrêter les serveurs.

Démarrage et arrêt des serveurs sous Windows

La procédure de démarrage et d’arrêt du serveur Integrated Solutions Console et du serveur Eclipse Helps

System sous Windows dépend de si vous exécutez ces serveurs en tant que services Windows.

Serveurs exécutés en tant que services Windows

Si vous exécutez les serveurs en tant que services Windows, procédez de l’une des façons suivantes :

v Vous pouvez démarrer et arrêter les serveurs à partir de l’écran Services de Windows. Voici les

entrées correspondantes figurant dans la liste des services :

– CS01 (ID du serveur de Console de Solutions intégrées)

– HS01 (ID du serveur d’clipse Help System)

v Si vous souhaitez démarrer ou arrêter les serveurs à partir d’une invite de commande lorsque vous

exécutez les serveurs en tant que services Windows, vous devez démarrer ou arrêter les serveurs

séparément. Pour vous assurer que l’état des serveurs figure dans Windows Services, utilisez les

commandes décrites ci-dessous pour démarrer et arrêter les serveurs.

Remarque : N’utilisez pas les scripts StartEclipse.bat et StopEclipse.bat pour démarrer ou arrêter le

serveur Eclipse Help System, car l’état du serveur ne figurera pas dans Windows

Services.

Démarrage des serveurs :

104 IBM Tivoli System Automation Composant de base - Guide d’utilisation

– Pour démarrer le serveur de la console Integrated Solutions Console, exécutez cette commande :

\AppServer\bin\startserver ISC_Portal

Par exemple :

C:\Program Files\IBM\WebSphere\AppServer\bin\startserver ISC_Portal

– Pour démarrer le serveur Eclipse Help System, exécutez cette commande :

\PortalServer\ISCEclipse\EclipseServiceStart.bat

Par exemple :

C:\Program Files\IBM\ISC\PortalServer\bin\EclipseServiceStart.bat

Arrêt des serveurs :

– Pour arrêter le serveur de la console Integrated Solutions Console, exécutez cette commande :

\AppServer\bin\stopserver ISC_Portal -username -password

où et sont les autorisations d’accès utilisateur de l’administrateur de la

console Integrated Solutions Console.

– Pour arrêter le serveur Eclipse Help System, exécutez la commande :

\PortalServer\ISCEclipse\EclipseServiceStop.bat

Par exemple :

C:\Program Files\IBM\ISC\PortalServer\bin\EclipseServiceStop.bat

Les serveurs ne s’exécutent pas en tant que services Windows

Si vous n’ exécutez pas les serveurs en tant que services Windows, exécutez les commandes suivantes

pour démarrer ou arrêter le serveur de la console Integrated Solutions Console et le serveur Eclipse.

Pour démarrer les serveurs, exécutez la commande suivante :

\PortalServer\bin\startISC.bat ISC_Portal

Par exemple :

C:\Program Files\IBM\ISC\PortalServer\bin\startISC.bat ISC_Portal

Pour arrêter les serveurs, exécutez la commande suivante :

\PortalServer\bin\stopISC.bat ISC_Portal

où et sont les autorisations utilisateur de l’administrateur de la console Integrated

Solutions Console. Par exemple :

C:\Program Files\IBM\ISC\PortalServer\bin\stopISC.bat ISC_Portal iscadmin pw4iscadmin

Démarrage et arrêt de la console des opérations sur AIX et Linux

Pour démarrer le serveur de la console ISC et le serveur Eclipse Help, exécutez la commande suivante :

/PortalServer/bin/startISC.sh ISC_Portal

Par exemple :

/opt/IBM/ISC/PortalServer/bin/startISC.sh ISC_Portal

Pour arrêter le serveur de la console ISC et le serveur Eclipse Help System, exécutez cette commande :

/PortalServer/bin/stopISC.sh ISC_Portal

où and sont les autorisations utilisateur de l’administrateur de la console Integrated

Solutions Console. Par exemple :

/opt/IBM/ISC/PortalServer/bin/stopISC.sh ISC_Portal iscadmin pw4iscadmin

Chapitre 9. Utilisation de la console des opérations 105

Création et autorisation d’utilisateurs et de groupes

La tâche d’installation a créé un utilisateur autorisé (ID utilisateur par défaut : iscadmin). Pour permettre à

un autre utilisateur d’utiliser la console console des opérations en mode d’accès direct, procédez comme

suit :

1. Créez un nouvel utilisateur dans Integrated Solutions Console. Les tâches à effectuer sont décrites

dans «Création d’utilisateurs dans Integrated Solutions Console».

2. Créez un nouveau groupe d’utilisateurs ou utilisez un groupe d’utilisateurs existant.Les tâches à

effectuer figurent sont décrites dans «Création de groupes dans Integrated Solutions Console», à la

page 107.

3. Attribuez un nouvel utilisateur au groupe d’utilisateurs.Les tâches à effectuer sont décrites dans

«Attribution des utilisateurs à un groupe dans la console Integrated Solutions Console», à la page 107.

4. Attribuez des droits d’accès au nouveau groupe d’utilisateurs dans la console Integrated Solutions

Console. Vous devez octroyer aux groupes d’utilisateurs le droit d’accéder aux pages de la console

Integrated Solutions Console et à la console des opérations d’IBM Tivoli System Automation. Les

tâches à effectuer sont décrites dans «Attribution des droits d’accès aux groupes d’utilisateurs dans la

console Integrated Solutions Console», à la page 107.

Création d’utilisateurs et de groupes dans Integrated Solutions

Console

Les chapitres suivants expliquent comment créer des utilisateurs et des groupes dans la Integrated

Solutions Console. Des informations supplémentaires sont disponibles sur les aides en ligne de Integrated

Solutions Console Pour accéder aux aides en ligne, ouvrez le menu Aide de la console Integrated

Solutions Console et sélectionnez Bases de la console ISC. Agrandissez la page Paramètres et cliquez

sur Gestion des utilisateurs et des groupes.

Création d’utilisateurs dans Integrated Solutions Console

Pour créer des utilisateurs, procédez comme suit :

1. Connectez-vous à la console Integrated Solutions Console avec les droits d’accès administrateur.(Par

défaut : utilisateur ISC : iscadmin, groupe ISC : iscadmins). Utilisez l’ID utilisateur que vous avez créé

au cours de la procédure d’installation de la console des opérations comme décrit à l’étape 7, à la

page 99.

__________________________________________________________________________

2. Cliquez sur l’onglet Paramètres de la console pour ouvrir la page des Paramètres.

__________________________________________________________________________

3. Dans le menu, sélectionnez Gestion des utilisateurs et des groupespour afficher la page Gestion

des utilisateurs et des groupes.

__________________________________________________________________________

4. Dans la table figurant sur la page, cliquez sur Tous les utilisateurs authentifiés du portail.

__________________________________________________________________________

5. Cliquez sur Nouvel utilisateur.

__________________________________________________________________________

6. Entrez l’ID utilisateur et le mot de passe ainsi que le nom, le prénom et l’adresse électronique, et

cliquez sur OK.

__________________________________________________________________________

Renouvelez ces étapes en commençant par l’étape 4 pour chaque utilisateur que vous souhaitez autoriser.

106 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Création de groupes dans Integrated Solutions Console

Pour créer des groupes, suivez ces étapes :

1. Connectez-vous à la console Integrated Solutions Console avec les droits d’accès administrateur.(Par

défaut : utilisateur ISC : iscadmin, groupe ISC : iscadmins).

Utilisez l’ID utilisateur que vous avez créé au cours de l’installation de la console des opérations.

__________________________________________________________________________

2. Cliquez sur l’onglet Paramètres de la console pour ouvrir la page des Paramètres.

__________________________________________________________________________

3. Sélectionnez Gestion des utilisateurs et des groupes.

__________________________________________________________________________

4. Cliquez sur Nouveau groupe.

__________________________________________________________________________

5. Tapez le nom du groupe d’utilisateur que vous souhaitez créer et cliquez sur OK.

__________________________________________________________________________

Attribution des utilisateurs à un groupe dans la console Integrated Solutions

Console

Pour attribuer des utilisateurs à un groupe, procédez comme suit :

1. Connectez-vous à la console Integrated Solutions Console avec les droits d’accès administrateur.(Par

défaut : utilisateur ISC : iscadmin, groupe ISC : iscadmins). Utilisez l’ID utilisateur que vous avez créé

au cours de la procédure d’installation de la console console des opérations.

__________________________________________________________________________

2. Cliquez sur l’onglet Paramètres pour ouvrir la page Paramètres.

__________________________________________________________________________

3. Sélectionnez Gestion des utilisateurs et des groupes dans le menu.

__________________________________________________________________________

4. Sélectionnez Tous les groupes d’utilisateurs du portails dans le menu.

__________________________________________________________________________

5. Sélectionnez le groupe dans lequel vous souhaitez attribuer des utilisateurs et cliquez sur Ajouter un

membre.

__________________________________________________________________________

6. Sélectionnez les utilisateurs que vous souhaitez ajouter au groupe et cliquez sur OK.

__________________________________________________________________________

Renouvelez ces étapes jusqu’à ce que vous ayez terminé d’attribuer les utilisateurs aux groupes.

Attribution des droits d’accès aux groupes d’utilisateurs dans la

console Integrated Solutions Console

Après avoir créé les groupes d’utilisateurs dans la console Integrated Solutions Console, vous devez

effectuer les tâches suivantes :

v «Octroyer aux groupes d’utilisateurs l’accès aux pages de la console Integrated Solutions Console», à

la page 108.

v «Autoriser l’accès à la console des opérations d’IBM Tivoli System Automation for Multiplatforms aux

groupes d’utilisateurs», à la page 109.

Chapitre 9. Utilisation de la console des opérations 107

Octroyer aux groupes d’utilisateurs l’accès aux pages de la console Integrated

Solutions Console

Procédez comme suit :

1. Connectez-vous à la Integrated Solutions Console en tant qu’administrateur (par défaut : ID utilisateur

iscadmin, groupe iscadmins)

__________________________________________________________________________

2. Dans l’arborescence de la console Integrated Solutions Console, déroulez Paramètres de la console

.

__________________________________________________________________________

3. Cliquez sur Droits d’accès aux ressources pour afficher la liste des Types de ressources.

__________________________________________________________________________

4. Dans la liste Types de ressource, cliquez sur Pages pour afficher la liste des ressources.

__________________________________________________________________________

5. Dans la liste Ressources, cliquez sur l’icône

pour Content Root.

__________________________________________________________________________

6. Dans la liste Rôles, cliquez sur l’icône

pour l’Utilisateur.

__________________________________________________________________________

7. Cliquez sur Ajouter. Sur la page qui s’affiche, seuls les groupes pour lesquels l’accès a été autorisé

sont répertoriés. Si vous effectuez cette tâche pour la première fois, la page risque d’être vide.

__________________________________________________________________________

8. Cliquez sur Rechercher. (Dans la zone Rechercher les utilisateurs ou les groupes d’utilisateurs,

l’option Groupes d’utilisateurs doit être sélectionné.)

__________________________________________________________________________

9. Dans la liste Utilisateurs et groupes d’utilisateurs, sélectionnez les cases pour les groupes

spécifiques à l’automatisation :

__________________________________________________________________________

10. Cliquez sur OK. L’écran suivant s’affiche :

108 IBM Tivoli System Automation Composant de base - Guide d’utilisation

__________________________________________________________________________

11. Redémarrez la console Integrated Solutions Console.

__________________________________________________________________________

Autoriser l’accès à la console des opérations d’IBM Tivoli System Automation for

Multiplatforms aux groupes d’utilisateurs

Procédez comme suit :

1. Connectez-vous à la console Integrated Solutions Console en tant qu’administrateur (par défaut : ID

utilisateur iscadmin, groupe iscadmins)

__________________________________________________________________________

2. Dans l’arborescence de la console Integrated Solutions Console, déroulez Paramètres de la

console.

__________________________________________________________________________

3. Cliquez sur Droits d’accès aux ressources pour afficher la liste Types de ressource.

__________________________________________________________________________

4. Dans la liste Types de ressource, cliquez sur Applications de portlets pour afficher la liste des

ressources.

__________________________________________________________________________

5. Dans la liste Ressources, cliquez sur l’icône

Multiplatforms Operations Console.

pour Tivoli System Automation for

__________________________________________________________________________

6. Dans la liste Rôles, cliquez sur l’icône

pour l’Utilisateur.

__________________________________________________________________________

7. Cliquez sur Ajouter.

__________________________________________________________________________

8. Cliquez sur Rechercher. (Dans la zone Rechercher des utilisateurs et des groupes d’utilisateurs,

l’option Groupes d’utilisateurs doit être sélectionnée.)

Chapitre 9. Utilisation de la console des opérations 109

__________________________________________________________________________

9. Dans la liste Utilisateurs et groupes d’utilisateurs, sélectionnez les cases relatives aux groupes

spécifiques à l’automatisation.

__________________________________________________________________________

10. Cliquez sur OK.

__________________________________________________________________________

11. Redémarrez Integrated Solutions Console.

__________________________________________________________________________

Modification et suppression des utilisateurs et des groupes

Les chapitres suivants expliquent comment modifier des utilisateurs et des groupes.

Modification des mots de passe pour les utilisateurs de la console Integrated

Solutions Console

Pour modifier les mots de passe des utilisateurs, procédez comme suit :

1. Connectez-vous à la console Integrated Solutions Console en tant qu’administrateur (par défaut : ID

utilisateur iscadmin, groupe iscadmins). Utilisez l’ID utilisateur qui a été créé au cours de l’installation

de la console des opérations.

__________________________________________________________________________

2. Ouvrez la page des Paramètres.

__________________________________________________________________________

3. Sélectionnez l’option Gestion des groupes et des utilisateurs.

__________________________________________________________________________

4. Sélectionnez Tous les utilisateurs authentifiés du portail dans le menu.

__________________________________________________________________________

5. Cliquez sur le bouton Editer pour modifier l’ID utilisateur souhaité.

__________________________________________________________________________

6. Tapez le nouveau mot de passe dans les zones d’entrée.

__________________________________________________________________________

7. Cliquez sur OK.

__________________________________________________________________________

Suppression des ID utilisateur au niveau de la console Integrated Solutions

Console

Pour supprimer des utilisateurs, procédez comme suit :

1. Connectez-vous à la console Integrated Solutions Console en tant qu’administrateur (par défaut : ID

utilisateur iscadmin, groupe iscadmins). Utilisez l’ID utilisateur qui a été créé au cours de l’installation

de la console des opérations.

__________________________________________________________________________

2. Ouvrez la page des Paramètres.

__________________________________________________________________________

3. Sélectionnez l’option Gestion des groupes et des utilisateurs dans le menu.

__________________________________________________________________________

4. Sélectionnez Tous les utilisateurs authentifiés du portail dans le menu.

__________________________________________________________________________

110 IBM Tivoli System Automation Composant de base - Guide d’utilisation

5. Cliquez sur le bouton Supprimer pour supprimer l’ID utilisateur souhaité.

__________________________________________________________________________

6. Cliquez sur OK.

__________________________________________________________________________

Suppression de groupes au niveau de la Integrated Solutions Console

Pour supprimer un groupe, procédez comme suit :

1. Connectez-vous à la console Integrated Solutions Console en tant qu’administrateur (par défaut : ID

utilisateur iscadmin, groupe iscadmins).Utilisez l’ID utilisateur qui a été créé au cours de l’installation

de la console des opérations.

__________________________________________________________________________

2. Ouvrez la page des Paramètres.

__________________________________________________________________________

3. Sélectionnez l’option Gestion des groupes et des utilisateurs dans le menu.

__________________________________________________________________________

4. Sélectionnez Tous les groupes d’utilisateurs du portaildans le menu.

__________________________________________________________________________

5. Cliquez sur le bouton Supprimer pour supprimer le groupe souhaité.

__________________________________________________________________________

6. Cliquez sur OK.

__________________________________________________________________________

Connexion

Pour accéder à la console des opérations, procédez comme suit :

1. Ouvrez la console Integrated Solutions Console dans une fenêtre du navigateur Web.

2. Connectez-vous à la console Integrated Solutions Console à l’aide de votre ID utilisateur et votre mot

de passe.

3. Connectez-vous à la console des opérations.

Le chapitre suivant explique comment se connecter à la console Integrated Solutions Console et à la

console des opérations.

Etapes à suivre pour accéder à la console des opérations

Pour accéder à la console des opérations, procédez comme suit :

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://:/ibm/console

Dans cette entrée, vous devez remplacer par le nom de l’hôte sur lequel la console

Integrated Solutions Console est exécutée et par un numéro de port spécifique, le port par

défaut est le 8421 (voir étape 8, à la page 100).

Chapitre 9. Utilisation de la console des opérations 111

L’écran de connexion de la console Integrated Solutions Console s’affiche dans la fenêtre du

navigateur :

Figure 7. Ecran de connexion de la console Integrated Solutions Console

2. Entrez votre ID utilisateur et votre mot de passe, puis cliquez sur Connexion. La page d’accueil de la

console Integrated Solutions Console s’ouvre. Sur la page des Eléments de travail, toutes les suites

installées y seront répertoriées. Le nom de la suite et le numéro de version y figureront :

3. Dans l’arborescence située à gauche, agrandissez le dossier de Tivoli System Automation for

Multiplatforms.

4. Cliquez sur TSA operations console.

5. L’écran principal de la console des opérations s’affiche.

112 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Comprendre les couches de la console des opérations

L’écran principal de la console des opérations de IBM Tivoli System Automation est divisé en plusieurs

zones :

Figure 8. Ecran principal de la console des opérations

v Arborescence des topologies

v Arborescence des ressources

v Zone d’information

Ces zones sont liées entre elles, autrement dit, les informations affichées dans une zone dépendent de la

sélection effectuée au sein des autres zones.

Les chapitres suivants présentent la console des opérations et les fonctions de base.

Ce qu’il faut savoir sur l’arborescence des topologies

La colonne Topologie affiche les domaines d’automatisation et les noeuds qui appartiennent à

un domaine dans une vue hiérarchique. L’arborescence des topologies est divisée de la façon suivante :

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.

Chapitre 9. Utilisation de la console des opérations 113

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 élément a une

incidence sur les éléments qu’affiche l’arborescence des ressources et la zone d’informations.

v L’arborescence 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.

Affichage du menu contextuel d’un élément dans l’arborescences des topologies.

Pour afficher le menu contextuel d’un domaine ou d’un noeud, cliquez sur le bouton à deux flèches qui

apparaît à droite de l’élément dans la colonne des topologies. Les entrées figurant dans le menu vous

permettent d’effectuer des opérations sur l’élément. Les actions qui sont disponibles dépendent du type

d’élément pour lequel vous affichez le menu contextuel et de son état.

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.

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 27. 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.

Par défaut, l’état de fonctionnement d’un domaine est correct si aucune des ressources de premier niveau

appartenant au domaine ne présente d’incident retenant votre attention. Toutefois, vous pouvez aussi

définir dans la fenêtre Préférences un autre ensemble de ressources pour indiquer si un domaine

fonctionne normalement.

Si une ressource utilisée comme indicateur d’état de fonctionnement d’un domaine rencontre un problème,

l’une des icônes suivantes apparaît dans la colonne Etat :

Tableau 28. 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.

114 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Tableau 28. Icônes figurant dans la colonne Etat de l’arborescence des topologies (suite)

Icône L’icône indique ...

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.

Par exemple, si vous voyez un signe d’avertissement en regard du nom du domaine, l’ID utilisateur et le

mot de passe pour le domaine d’IBM Tivoli System Automation sont certainement absents. 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.

Au fur et à mesure que vous rencontrez des problèmes dans un domaine ou sur un noeud dans

l’arborescence des topologies, vous pouvez l’utiliser en tant que point d’entrée pour surveiller les

ressources.

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 l’arborescence des ressources. Une fois l’élément séléctionné, 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 les ressources résident.

Présentation de l’arborescence des ressources

L’arborescence des ressources est une vue hiérarchique des ressources fondée sur l’appartenance aux

groupes. Vous pouvez influer sur la manière de présenter les ressources dans l’arborescence des

ressources de différentes façons :

v selon les éléments que vous sélectionnez dans l’arborescence des topologies :

– lorsque vous sélectionnez un domaine d’automatisation, les ressources hébergées y figurent

– lorsque vous sélectionnez un noeud, les ressources qui résident dans ce noeud y figurent

v selon la vue que vous sélectionnez dans la liste déroulante Vue.

v selon le filtre de nom que vous appliquez à un domaine ou à un noeud. Dans ce cas, seules les

ressources qui correspondent aux critères de filtrage et qui sont hébergées par le domaine ou qui

résident sur le noeud que vous avez sélectionné, figurent dans l’arborescence des topologies.

Eléments affichés dans la colonne Etat

Les types de ressources affichées dans l’arborescence des ressources sont les suivantes :

Tableau 29. Icônes de ressources dans l’arborescence des ressources

Icône Description

ressource

Groupe de ressources

groupe de déplacement, également appelé ressource flottante.

De plus, vous pouvez immédiatement savoir si :

v les ressources sont en ligne ou hors ligne. Lorsque la ressource est en ligne, l’icône est active ; lorsque

la ressource est hors ligne, l’icône est grisée.

Chapitre 9. Utilisation de la console des opérations 115

v Quand une requête d’opérateur a été envoyée sur une ressource. Ceci est indiqué par une icône

d’opérateur . La couleur de l’icône 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.

v si un message d’avertissement ou d’erreur a été émis pour une ressource ou un groupe de ressources.

Dans ce cas, une icône d’avertissement ou une icône d’erreur apparaîtra à côté de l’icône de

ressource.

Icône Description

Un avertissement a été émis.

L’icône rouge d’erreur indique qu’une erreur s’est produite.

L’icône noire indique qu’une erreur irréparable s’est produite.

Limitation de l’étendue de l’arborescence des ressources

Lorsque vous contrôlez ou gérez les ressources, vous ne souhaitez probablement pas afficher toutes les

ressources contenues dans l’arborescence des ressources hébergées par un domaine ou un noeud. Vous

avez la possibilité de limiter l’étendue des ressources affichées dans l’arborescence des ressources de

différentes manières :

v Vous pouvez sélectionner une vue prédéfinie dans la liste déroulante Vue. La zone Vue est située

au-dessus de l’arborescence des ressources. Voici ce qui s’affiche lorsque vous sélectionnez l’une des

vues :

– Toutes les ressources

Toutes les ressources disponibles.

– Erreurs et avertissements

ressources pour lesquelles une erreur ou un avertissement a été émis(e)

– Requêtes de l’opérateur

ressources pour lesquelles une requête a été envoyée par l’opérateur

v Vous pouvez indiquer et appliquer un filtre de nom.

Lorsque vous appliquez un filtre de nom, seules les ressources d’un domaine ou d’un noeud qui

contiennent un terme correspondant à vos spécifications sont affichées.

Vous pouvez indiquer des filtres de nom dans la zone Nom, située sous l’arborescence des ressources

ou sur la page Filtres de nom de la fenêtre Préférences. Les filtres de nom correspondent à un

domaine et à un utilisateur. Tous les filtres de nom que vous définissez sont enregistrés sous votre ID

utilisateur. Ils sont accessibles pour le domaine dans la liste déroulante de la zone Filtre de nom. Pour

gérer ces filtres, vous pouvez vous rendre sur la page des Filtres de nom de la fenêtre Préférences.

v Vous pouvez associer des filtres de nom et des vues, par exemple, pour afficher uniquement les

ressources d’un domaine correspondant à un filtre de nom spécifique et pour lequel une erreur a été

émise.

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 l’arborescence 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 l’arborescence des

116 IBM Tivoli System Automation Composant de base - Guide d’utilisation

essources :

Lorsque vous sélectionnez ... ...les pages suivantes sont disponibles

un domaine d’automatisation dans la topologie v Général

une ressource ou un groupe de ressources

dans l’arborescence des ressources

v Règle

v Informations complémentaires

v Général

v Relations (disponible uniquement si la ressource possède des

relations)

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 l’arborescence 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 l’arborescence 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 présente le nom des règles et la date et l’heure à laquelle elles ont été activées.

Chapitre 9. Utilisation de la console des opérations 117

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

l’arborescence des ressources et que des relations en aval et en amont ont été définies.

Gestion des ressources à l’aide de la console des opérations

En mode d’accès direct, la gestion des ressources équivaut à :

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 «Utilisation des requêtes de démarrage et d’arrêt des groupes de ressources et des ressources», à

la page 167.

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.

Envoi des requêtes de démarrage

Pour envoyer une requête de démarrage, procédez comme suit :

1. Dans l’arborescence 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.

__________________________________________________________________________

4. Cliquez sur Envoyer pour envoyer la requête.

__________________________________________________________________________

Résultats :

v L’icône d’opérateur apparaît afin d’indiquer qu’une requête a été émise sur la ressource.

v Le traitement de la requête se termine lorsque la ressource a démarré. L’icône de l’opérateur devient

vert.

118 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Envoi des requêtes d’arrêt

Pour envoyer une requête d’arrêt, procédez comme suit :

1. Dans l’arborescence 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 Inactif.

__________________________________________________________________________

4. Cliquez sur Envoyer pour envoyer la requête.

__________________________________________________________________________

Résultats :

v L’icône de couleur jaune apparaît afin d’indiquer qu’une requête a été émise sur la ressource.

v 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 30. Icônes des requêtes d’opérateur de la zone d’information

Icône Requête

d’opérateur Description

(jaune)

(vert)

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.

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.

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.

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.

Chapitre 9. Utilisation de la console des opérations 119

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.

Etapes à suivre pour afficher une liste de requêtes et les détails de la requête : Procédez comme

suit :

1. Dans l’arborescence 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 l’arborescence 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 :

120 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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.

__________________________________________________________________________

Chapitre 9. Utilisation de la console des opérations 121

122 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Chapitre 10. Protection de vos ressources – support réalisé

par Quorum

Ce chapitre explique comment IBM Tivoli System Automation 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. Puisque

chaque sous-grappe n’a pas connaissance de l’autre sous-grappe, IBM Tivoli System Automation risque

de démarrer une nouvelle instance d’application fonctionnant dans l’une des sous-grappes. Si l’application

a besoin d’accéder à un disque partagé, pour effectuer par exemple une reprise sur incident, les données

risquent d’être corrompues si plusieurs applications tentent d’accéder en même temps 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, IBM Tivoli System Automation veille à ne conserver qu’une seule sous-grappe et à supprimer les

autres. Par conséquent, IBM Tivoli System Automation 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.

Figure 9. Quorum – majorité de noeuds

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 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

Support réalisé par Quorum

Quorum de configuration

Le quorum de configuration détermine le moment où les modifications de configuration seront acceptées à

l’intérieur de la grappe. 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 aussi utiliser

l’option -f de cette commande pour remplacer la règle majoritaire.

v La règle du quorum pour la commande startrpdomain est n/2, mais vous pouvez la remplacer par

l’option (-A) tous les noeuds ou l’option (-L) noeud local.

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 en savoir plus sur cette opération, voir IBM Reliable Scalable Cluster Technology for Linux,

Administration Guide, SA22-7892, and IBM Reliable Scalable Cluster Technology for Linux, Technical

Reference, SA22-7893.

Quorum opérationnel

Le quorum opérationnel permet de déterminer si les ressources peuvent être activées en toute sécurité,

sans créer de conflits 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 comprend un quorum opérationnel si plus de la moitié des noeuds présents sont actifs.

Pourvue d’un quorum opérationnel, IBM Tivoli System Automation peut manipuler les ressources ou les

groupes de ressources et les mettre en ligne. Sans quorum, IBM Tivoli System Automation ne peut pas

intervenir sur une ressource.

Si des ressources critiques sont actives sur une sous-grappe dépourvue d’un quorum, ConfigRM va avoir

recours à l’attribut ″CritRsrcProtMethod″ de chaque noeud à l’intérieur d’une sous-grappe pour déterminer

de quelle façon le système devrait prendre fin. Les méthodes de protection reposent sur l’arrêt immédiat

du système de Kernel Panic. Il existe 6 méthodes de protection :

Signification Valeur

Réinitialisation à froid et redémarrage du système d’exploitation (par défaut). 1

Arrête le 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.

124 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Indépendamment de 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.

Dans une situation de parité où la grappe est fractionnée en sous-grappes -chacune d’elle 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.

Il existe plusieurs types de condition de départage qui sont :

Support réalisé par Quorum

1. Operator - 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.

2. Fail - 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.

3. SCSI - cette condition de départage correspond à Linux on iSeries, Linux on pSeries, et Linux on

xSeries. Il sous-entend 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’.

4. ECKD - cette condition de départage s’applique à Linux on zSeries. Cette condition de départage

présume que le disque ECKD est partagé par tous les noeuds de la grappe.On accède au disque au

moyen de la commande ’ECKD reserve’.

5. DISK - cette condition de départage s’applique à 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.

6. EXEC - cette condition de départage est une condition de départage de type générique qui 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 134

pour savoir comment configurer la condition de départage EXEC afin d’utiliser la commande

exécutable samtb_net.

Si vous obtenez un nombre étrange de noeuds à l’intérieur de la grappe, 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 dans l’attribut ″CritRsrcProtMethod″ sera appliquée au noeud.

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

Chapitre 10. Protection de vos ressources – support réalisé par Quorum 125

Support réalisé par Quorum

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 effectuer un

départage automatique sans que l’opérateur n’ait à intervenir, vous avez besoin d’un disque de départage

(SCSI pour Linux on xSeries, pSeries et iSeries, ou ECKD pour Linux on zSeries, ou DISK pour AIX). Un

disque de départage est un disque partagé accessible par tous les noeuds à l’intérieur d’une grappe.

Fonction VMTIMEBOMB

La fonction vmtimebomb qui fonctionne pour zLinux 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 lsrsc dans RSCT pour répertorier la valeur de l’attribut de ProtectionMode :

lsrsrc IBM.Application Name NodeNameList ProtectionMode

Exécutez la commande chrsrc dans RSCT pour définir la ressource en tant que ″critique″ en paramétrant

ProtectionMode sur 1 :

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

126 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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

Vous obtenez la sortie suivante :

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.

Support réalisé par Quorum

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.

Chapitre 10. Protection de vos ressources – support réalisé par Quorum 127

Support réalisé par Quorum

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 IBM Tivoli

System Automation.

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 IBM Tivoli System Automation 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 IBM Tivoli System Automation 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. IBM Tivoli System Automation ne

démarre aucune ressource.

2 – NO_QUORUM IBM Tivoli System Automation 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 IBM Tivoli

System Automation. 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 IBM Tivoli

System Automation sera rejetée.

Entrez ce qui suit dans OpQuorumState :

lsrsrc IBM.PeerDomain Name OpQuorumState

Vous obtenez la sortie suivante :

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

128 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Vous obtenez la sortie suivante sur un système Linux fonctionnant sur xSeries, pSeries ou iSeries :

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

Vous obtenez la sortie suivante :

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 = ""

ReleaseRetryPeriod = 0

HeartbeatPeriod = 0

PreReserveWaitTime = 0

PostReserveWaitTime = 0

NodeInfo = {}

ressource 3:

Name = "myTieBreaker"

Type = "SCSI"

DeviceInfo = "ID=0 LUN=0 CHAN=0 HOST=2"

ReprobeData = ""

ReleaseRetryPeriod = 0

HeartbeatPeriod = 5

PreReserveWaitTime = 0

PostReserveWaitTime = 0

NodeInfo = {}

ressource 4:

Name = "mytb"

Type = "EXEC"

DeviceInfo = "PATHNAME=/usr/sbin/rsct/bin/samtb_net Address=192.168.177.2"

ReprobeData = ""

ReleaseRetryPeriod = 0

HeartbeatPeriod = 30

PreReserveWaitTime = 0

PostReserveWaitTime = 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

Vous obtenez la sortie suivante :

Support réalisé par Quorum

Chapitre 10. Protection de vos ressources – support réalisé par Quorum 129

Support réalisé par Quorum

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 on zSeries. 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

130 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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

resource 1:

Name = "Operator"

Type = "Operator"

DeviceInfo = ""

ReprobeData = ""

ReleaseRetryPeriod = 0

HeartbeatPeriod = 0

PreReserveWaitTime = 0

PostReserveWaitTime = 0

NodeInfo = {}

resource 2:

Name = "Fail"

Type = "Fail"

DeviceInfo = ""

ReprobeData = ""

ReleaseRetryPeriod = 0

HeartbeatPeriod = 0

PreReserveWaitTime = 0

PostReserveWaitTime = 0

NodeInfo = {}

resource 3:

Name = "myTieBreaker"

Type = "ECKD"

DeviceInfo = "ID=50de"

ReprobeData = ""

ReleaseRetryPeriod = 0

HeartbeatPeriod = 5

PreReserveWaitTime = 0

PostReserveWaitTime = 0

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"

Astuce : 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é :

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

50de(ECKD) at ( 94: 8) is dasdc : active at blocksize: 4096, 601020 blocks, 2347 MB

Support réalisé par Quorum

v être réinitialisé, si le noeud a été réinitialisé et ne peut plus reconnaître le disque à départager :

Chapitre 10. Protection de vos ressources – support réalisé par Quorum 131

Support réalisé par Quorum

node01:~ # cat /proc/subchannels

Device sch. Dev Type/Model CU in use PIM PAM POM CHPIDs

--------------------------------------------------------------

50DE 0A6F FFFF/00 F0 A0 FF 7475E6E7 FFFFFFFF

node01:~ # cat /proc/dasd/devices

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 de la condition de départage de SCSI pour une grappe à

deux noeuds

Le type de condition de départage de SCSI correspond aux serveurs des familles pSeries et iSeries pour

Linux on xSeries. 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 HearbeatPeriod de la ressource lors de la création

d’une condition de départage de ce type. L’attribut persistant HeartbeatPeriod de la ressource définit

l’intervalle auquel la requête de réservation est de nouveau émise.

Les périphériques SCSI peuvent être identifiés par quatre valeurs entières pour les 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"]}’

IBM Tivoli System Automation 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

132 IBM Tivoli System Automation Composant de base - Guide d’utilisation

"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

Exemple 3 : configuration d’une condition de départage de DISK sous 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 HearbeatPeriod lors de la création d’une condition de départage de ce type. L’attribut

persistant HearbeatPeriod définit l’intervalle dans lequel la requête de réservation est émise à nouveau.

Pour imprimer chaque volume physique connu dans le système avec son nom de disque physique, entrez

la commande lspv :

lspv

Une sortie de ce type s’affichera :

hdisk0 000000371e5766b8 rootvg active

hdisk1 000069683404ed54 None

Afin de vérifier qu’il s’agit d’un disque SCSI ou de type SCSI et qu’il peut être départagé, utilisez la

commandelsdev. 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

Support réalisé par Quorum

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

Chapitre 10. Protection de vos ressources – support réalisé par Quorum 133

Support réalisé par Quorum

disques répertoriés par la commande lspv command 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 : 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"

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.

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 :

134 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Tableau 31. 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

- Il peut y avoir les conditions d’erreur dans

lesquelles une situation de parité se produit mais

où plusieurs noeuds peuvent communiquer.

Dans ce cas, il y a une petite chance pour que

les deux sous grappes puissent être soumises à

la condition de départage.

- Si l’instance IP externe n’est pas disponible en

cas de fractionnement d’une grappe, aucune

sous-grappe n’aura de quorum.

- Il peut y avoir les conditions d’erreur dans

lesquelles une situation de parité se produit mais

où plusieurs noeuds peuvent communiquer.

Dans ce cas, il y a une petite chance pour que

les deux sous-grappes puissent être soumises à

la condition de départage.

+ 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.

- 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= 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= 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= 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

oscille 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"

Support réalisé par Quorum

Chapitre 10. Protection de vos ressources – support réalisé par Quorum 135

Support réalisé par Quorum

Vous pouvez utiliser n’importe quelle commande normale RSCT pour manipuler la définition de la

condition de départage du réseau. Utilisez la commande ″rmrsrc″ pour supprimer la définition de la

condition de départage.

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 qu’un noeud met quelque chose de côté

(reserve) et que, par conséquent, l’autre noeud ne peut désormais plus disposer de ce quelque chose car

il n’est plus disponible.

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 de nouveau 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 :

Ci-dessous, vous trouverez les points concernant les options de configuration les plus importantes pour

définir la condition de départage RSCT. Ils donnent une idée sur la procédure de configuration à suivre.

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.

136 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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 (noeud n1 et noeud 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.

Figure 10. Journaux système d’une grappe à deux noeuds

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

Support réalisé par Quorum

Dans ce cas, l’état de quorum opérationnel est toujours HAS_QUORUM et la protection de la ressource

n’est plus assurée.

Chapitre 10. Protection de vos ressources – support réalisé par Quorum 137

138 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Chapitre 11. 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

:

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

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.

configuration du réseau

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.

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.

Installation d’une grappe à un ou deux noeuds : détection des échecs

de l’interface réseau

Lors de l’installation d’une grappe à un ou deux noeuds, vous avez besoin d’une configuration

supplémentaire pour détecter les échecs de l’interface réseau. Le logiciel de la grappe essaie

périodiquement d’atteindre chaque interface réseau de la grappe. S’il s’agit d’une grappe à deux noeuds

et qu’une interface échoue à un noeud, l’autre interface située à l’autre noeud ne pourra obtenir de

réponse de la part de son homologue et fonctionnera de façon autonome.

Pour éviter tout comportement de ce type, le logiciel de la grappe devra 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 au niveau de chaque noeud :

/usr/sbin/cluster/netmon.cf

Chaque ligne de ce fichier doit contenir le nom de la machine ou l’adresse IP de l’instance externe.

L’adresse IP spécifiée devra être exprimée en notation décimale.

Voici un exemple d’un fichier /usr/sbin/cluster/netmon.cf fichier :

# il s’agit de la passerelle de noeud par défaut pour toutes les interfaces au sein du réseau 192.168.1.0

192.168.1.1

# il s’agit de la passerelle de noeud pour toutes les interfaces au sein du réseau 192.168.2.0

gw.de.ibm.com

140 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Grappe à deux noeuds, chaque noeud possède une interface Ethernet

La configuration du réseau suivante s’affiche :

Nom : Périphérique : 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

Figure 12. Une interface à deux noeuds

configuration du réseau

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

l’une des interfaces é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 10, «Protection de vos ressources – support réalisé par Quorum», à la page 123. Si la

communication échoue comme décrit dans figure 13, à la page 142, 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.

Chapitre 11. Configuration d’un réseau hautement disponible 141

configuration du réseau

Figure 13. Une interface réseau à deux noeuds – échec de l’interface

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 d’IBM Tivoli System Automation :

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.

Grappe à deux noeuds, chaque noeud possè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.

142 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Deux réseaux séparés physiquement, déplacement de ServiceIP entre

les noeuds

La configuration réseau suivante concerne :

Nom : Périphérique : IP :

Noeud de grappe lnxcm1 eth0

eth1

Noeud de grappe lnxcm2 eth0

eth1

9.152.172.1/24

192.168.1.1/24

9.152.172.2/24

192.168.1.2/24

Routeur gw eth0 9.152.172.254/24

ServiceIP - – 9.152.172.3/24

Figure 14. Deux interfaces à deux noeuds, deux réseaux séparés physiquement

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 correspondant au service informatique hautement

disponible.

v Le réseau 192.168.1.0 rend la communication interne entre les grappes plus fiable.

configuration du réseau

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.

Chapitre 11. Configuration d’un réseau hautement disponible 143

configuration du réseau

L’exemple des règles d’IBM Tivoli System Automation est le même que celui décrit à la page , à la page

142.

Avantage Inconvénient

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.

La configuration réseau suivante concerne :

Nom : Périphérique : IP :

Noeud de grappe lnxcm1 eth0

eth1

Noeud de grappe lnxcm2 eth0

eth1

192.168.1.1/24

192.168.2.1/24

192.168.1.2/24

192.168.2.2/24

Routeur gw eth0 9.152.172.254/24

ServiceIP - – 9.152.172.3/24

Figure 15. Un réseau physique à deux noeuds et deux interfaces

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.

144 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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 d’IBM Tivoli System Automation :

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

Avantage Inconvénient

Configuration simplifiée. 3 réseaux logiques dans 1 réseau physique.

Redondance dans la communication à l’intérieur de la Trafic entre trois réseaux sur 1 moyen physique.

grappe.

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 ne concerne pas exclusivement 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.

La configuration réseau suivante concerne :

Nom : Périphérique : IP :

Noeud de grappe lnxcm1 eth0

eth1

Noeud de grappe lnxcm2 eth0

eth1

Routeur gw eth0

eth1

configuration du réseau

9.152.170.1/24

9.152.171.1/24

9.152.170.2/24

9.152.171.2/24

9.152.170.254/24

9.152.171.254/24

ServiceIP - – 9.152.172.3/24

Chapitre 11. Configuration d’un réseau hautement disponible 145

configuration du réseau

Figure 16. Deux réseaux séparés physiquement, routage dynamique et VIPA

Avantage Inconvénient

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. Puisque la détection d’échecs de l’interface est effectuée par le

périphérique de connexion lui-même, vous ne devez pas configurer IMB.ServiceIP avec des interfaces

réseau équivalentes.

La configuration réseau suivante concerne :

Nom : Périphérique : IP :

Noeud de grappe lnxcm1 eth0

eth1

Noeud de grappe lnxcm2 eth0

eth1

9.152.172.1/24

9.152.172.2/24

Routeur gw eth0 9.152.172.254/24

ServiceIP - - 9.152.172.3/24

146 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Figure 17. Interfaces de réseau connectées ensemble à un périphérique de réseau logique

Avantage Inconvénient

Configuration simplifiée. Le système d’exploitation doit supporter l’interface de

connexion.

Redondance au sein de la communication à l’intérieur

des grappes.

Il est inutile de déplacer ServiceIP entre les périphériques

sur le même noeud.

configuration du réseau

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)

Chapitre 11. Configuration d’un réseau hautement disponible 147

configuration du réseau

148 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Chapitre 12. Contrôle et administration d’IBM Tivoli System

Automation

Ce chapitre décrit les divers paramètres pouvant être utilisés pour contrôler et modifier les comportement

général d’IBM Tivoli System Automation. Il donne également un aperçu général de l’infrastructure d’IBM

Tivoli System Automation et donne quelques conseils et astuces judicieux.

Configuration de l’adaptateur d’automatisation de bout en bout de

System Automation for Multiplatforms

Cette section décrit les étapes nécessaires à la mise en oeuvre de la configuration de l’adaptateur

d’automatisation de bout en bout de System Automation for Multiplatforms (également appelé adaptateur

d’automatisation de bout en bout).

Vous devez configurer l’adaptateur d’automatisation de bout en bout lorsque vous utilisez le composant de

la gestion de bout en bout de l’automatisation d’IBM Tivoli System Automation for Multiplatforms (consultez

le manuel IBM Tivoli System Automation for Multiplatforms : Gestion de l’automatisation de bout en bout -

Guide d’utilisation et de référence) ou si vous souhaitez faire fonctionner des ressources automatisées

directement à partir d’une console de commande des opérations.

Vous pouvez utiliser l’Automatisation de bout en bout afin d’automatiser le fonctionnement des ressources

dans des environnements homogènes (domaines d’automatisation de premier niveau) qui possèdent

chacun une technologie d’automatisation locale qui leur est propre. Un domaine d’automatisation de

premier niveau est défini en tant que ressources gérées par IBM Tivoli System Automation. Chaque

domaine de premier niveau est connecté au gestionnaire d’automatisation de bout en bout ou à une

console de commande des opérations via un adaptateur d’automatisation de bout en bout.

L’objet d’une carte d’automatisation est de

v Gérer les ressources au sein de leur domaine d’automatisation de premier niveau

v Propager les modifications d’attributs des ressources au gestionnaire d’automatisation de bout en bout.

v Démarrer et arrêter des ressources au sein d’un domaine d’automatisation de premier niveau via une

requête du gestionnaire d’automatisation de bout en bout ou d’un opérateur.

v Fournir des informations sur les ressources disponibles au sein du domaine d’automatisation de premier

niveau.

L’adaptateur d’automatisation de bout en bout utilise la fonction d’intégration d’événements de Tivoli (EIF)

pour communiquer avec le gestionnaire d’automatisation de bout en bout.

Les aides en ligne fournies avec la boîte de dialogue de configuration de l’adaptateur d’automatisation de

bout en bout de System Automation for Multiplatforms offrent également des informations utiles sur

l’utilisation et la configuration de l’adaptateur d’automatisation de bout en bout.

Contrôle et administration d’IBM Tivoli System Automation

La figure suivante présente un aperçu des environnements dans lesquels l’adaptateur d’automatisation de

bout en bout peut fonctionner :

Cette figure illustre les conditions de configuration requises pour l’adaptateur d’automatisation de bout en

Figure 18. Présentation de l’environnement dans lequel l’adaptateur d’automatisation de bout en bout fonctionne

bout et les environnements dans lesquels adaptateur d’automatisation de bout en bout peut

fonctionner.L’utilisateur du composant de base d’IBM Tivoli System Automation peut utiliser la console des

opérations en mode d’accès direct uniquement, l’utilisateur de la section gestion d’automatisation de bout

en bout d’IBM Tivoli System Automation peut utiliser la console des opérations en mode d’automatisation

de bout en bout et en mode d’automatisation de premier niveau. Ces deux modes sont décrits dans le

manuel Gestion de l’automatisation de bout en bout : Guide d’utilisation et de référence.

Il est fortement recommandé de rendre l’adaptateur hautement disponible si la grappe IBM Tivoli System

Automation for Multiplatforms se compose de plusieurs noeuds. La section «Onglet Automatisation», à la

page 156 décrit comment rendre l’adaptateur hautement disponible.

Par automatisation, il faut comprendre que l’adaptateur peut fonctionner sur n’importe quel noeud

disponible. Ceci est nécessaire puisque l’adaptateur est connecté à deux composants comme décrit dans

la figure 18:

1. Le module de publication d’événements, qui envoie les événements à l’adaptateur, par exemple, si

l’état d’une ressource change. Le module de publication d’événements fonctionne sur le noeud

150 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Contrôle et administration d’IBM Tivoli System Automation

principal, qui peut cependant être modifié à tout moment. Ceci peut se produire, par exemple, si un

noeud devient inactif ou si une erreur grave survient. Si l’adaptateur a reçu uniquement les

événements à partir du module de publication d’événements, il pourra fonctionner sur le noeud

principal. Toutefois, l’adaptateur communique également avec l’hôte à l’aide de l’adaptateur.

2. L’hôte qui utilise l’adaptateur, tenant lieu de console des opérations pour le composant de base ou la

gestion de bout en bout pour le composant de base gestion intégrale de l’automatisation d’IBM Tivoli

System Automation. D’une part, l’adaptateur envoie les événements sur les modifications de la

ressource à l’hôte, d’autre part il reçoit les requêtes de l’hôte.

De ce fait, l’adaptateur doit toujours être capable de recevoir des requêtes depuis l’hôte par le biais de

l’adaptateur mais aussi recevoir des événements depuis le module de publication d’événements

fonctionnant sur le noeud principal. A des fins d’automatisation, le module de publication d’événements et

l’hôte utilisant l’adaptateur doivent accéder à l’adaptateur via une adresse IP unique, cette dernière devant

être entrée dans l’onglet Adaptateur comme décrit dans «Onglet Adaptateur», à la page 153.

L’administrateur doit demander cette adresse IP.

Voici ce qui peut se produire si l’adaptateur n’a pas été automatisé mais qu’il fonctionne sur le noeud

principal :

1. Si le noeud sur lequel l’adaptateur fonctionne s’arrête, l’hôte utilisant l’adaptateur ne peut plus y

accéder. Par conséquent, il est impossible de connaître le comportement des ressources.

2. Bien que l’état des ressources puisse être modifié, la console des opérations ou la gestion de bout en

bout risque de ne pas faire apparaître ces modifications. Sélectionnez 'Régénération' pour obtenir l’état

le plus récent au niveau de la console des opérations affichée. La raison de ce comportement

s’explique par le fait que le module de publication d’événements s’est déplacé automatiquement vers

un autre noeud.

La section suivante de ce chapitre décrit les procédures de configuration et de fonctionnement de

l’adaptateur d’automatisation de bout en bout.

L’adaptateur d’automatisation de bout en bout peut être configuré avec l’utilitaire cfgsamadapter. Etant

donné qu’il s’agit d’une application X, elle doit être utilisée à partir d’un poste de travail intégrant des

fonctions de serveur X. Il peut s’agir d’un des noeuds à l’intérieur de la grappe, si la fonction X11 en

option est installée sur ce noeud.

Exécutez la commande cfgsamadapter pour appeler la boîte de dialogue de configuration de

l’adaptateur de System Automation for Multiplatforms.

Chapitre 12. Contrôle et administration d’IBM Tivoli System Automation 151

Contrôle et administration d’IBM Tivoli System Automation

Figure 19. Panneau de configuration principal de System Automation for Multiplatforms

La boite de dialogue vous permet d’effectuer les tâches suivantes :

1. Configuration de l’adaptateur d’automatisation de bout en bout, voir section «Configuration de

l’adaptateur d’automatisation de bout en bout», à la page 152.

2. Réplication des fichiers de configuration de l’adaptateur d’automatisation de bout en bout dans des

noeuds différents, voir section «Réplication des fichiers de configuration de l’adaptateur

d’automatisation de bout en bout dans d’autres noeuds du domaine», à la page 160.

3. Définition des règles d’automatisation de bout en bout de l’adaptateur qui résultent en la création de

ressources afin d’automatiser l’adaptateur, voir section «Définition des règles d’automatisation de bout

en bout de l’adaptateur», à la page 161.

4. Suppression des règles d’automatisation de bout en bout de l’adaptateur, voir section «Suppression

des règles d’automatisation de bout en bout de l’adaptateur», à la page 161.

Configuration de l’adaptateur d’automatisation de bout en bout

152 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Contrôle et administration d’IBM Tivoli System Automation

L’utilisation du bouton Configurer fait apparaître le panneau ci-dessous dans lequel vous pouvez choisir

parmi plusieurs onglets décrits dans les sections suivantes. xpp:break>Dans la description suivante,

l’expression ’Hôte utilisant l’adaptateur’ signifie ’gestion d’automatisation de bout en bout’ ou ’console

des opérations d’accès direct’.

Figure 20. configuration de l’adaptateur de bout en bout de System Automation for Multiplatforms

Onglet Adaptateur

La sélection de l’onglet Adaptateur vous permet de configurer l’hôte de l’adaptateur.

Nom d’hôte ou adresse IP Le nom d’hôte du noeud sur lequel l’adaptateur fonctionne si l’adaptateur

n’est pas automatisé, ou, s’il est automatisé, l’adresse IP qui sera utilisée

en tant que ressource serviceIP pour automatiser l’adaptateur. Vous devez

obtenir cette adresse IP auprès de votre administrateur réseau. Elle doit

être capable de recevoir des requêtes quel que soit le noeud sur lequel

l’adaptateur d’automatisation de bout en bout fonctionne. Notez que

l’adresse IP ne doit être ni une adresse hôte réelle, ni un hôte local réel.

Vous devez entrer la même adresse IP dans l’onglet d’automatisation. La

section «Qu’est ce qu’une classe de ressources IBM.ServiceIP ?», à la

page 193 fournit des informations supplémentaires sur les adresses

Service IP.

Numéro de port de requête Le port sur lequel l’adaptateur d’automatisation de bout en bout écoute les

requêtes de l’hôte de gestion de bout en bout. Le port par défaut est

’2001’.

Numéro de port d’événement Le port sur lequel l’adaptateur d’automatisation de bout en bout écoute les

événements du gestionnaire d’automatisation de premier niveau. Le port

par défaut est ’5539’.

Lorsque vous cliquez sur le bouton Avancé, vous pouvez spécifier le comportement d’exécution de

l’adaptateur :

Chapitre 12. Contrôle et administration d’IBM Tivoli System Automation 153

Contrôle et administration d’IBM Tivoli System Automation

Différé de l’arrêt de l’adaptateur

Retarde l’arrêt de l’adaptateur d’automatisation de bout en bout pendant

un nombre de secondes défini. Cela permet à l’adaptateur de transmettre

l’événement ″quitter le domaine″. La valeur par défaut est 5, l’échelle des

valeurs est comprise entre 3 et 60. Vous devrez peut être augmenter cette

valeur pour les systèmes plus lents.

Intervalle d’activité du contact distant

Définit le délai au terme duquel l’adaptateur d’automatisation de bout en

bout s’arrête si aucune connexion n’est établie avec l’hôte utilisant

l’adaptateur. Si la valeur 0 est attribuée à ce paramètre, l’adaptateur

continue de s’exécuter et ne s’arrête jamais. La valeur par défaut est 360

secondes.

Etablir le contact initial Si cette case est cochée, l’adaptateur d’automatisation de bout en bout

tente plusieurs fois d’établir un contact avec l’hôte utilisant l’adaptateur.

Autrement, l’adaptateur d’automatisation de bout en bout tente d’établir un

contact avec l’ hôte utilisant l’adaptateur puis attend d’être contacté par

l’ hôte utilisant l’adaptateur.

Intervalle entre les nouvelles tentatives de contact initial

Au cours de cette période (définie en minutes) l’adaptateur

d’automatisation de bout en bout tente de contacter l’hôte utilisant

l’adaptateur. Cette opération se poursuit jusqu’à l’établissement du

contact ou l’expiration du délai défini. La valeur par défaut 0 signifie que

l’adaptateur tente toujours de contacter l’hôte utilisant l’adaptateur.

Intervalle de tentative de reconnexion EIF

Si la connexion à l’hôte utilisant l’adaptateur est interrompue, cette

option indique le temps d’attente que l’adaptateur d’automatisation de bout

en bout laissera s’écouler avant toute nouvelle tentative de reconnexion.

La durée par défaut est 30 secondes.

154 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Onglet Hôte utilisant l’adaptateur

Figure 21. Hôte utilisant l’adaptateur

Contrôle et administration d’IBM Tivoli System Automation

L’adaptateur d’automatisation de bout en bout peut être utilisé avec deux modes :

1. Configurer l’hôte de gestion de bout en bout qui utilise l’adaptateur pour gérer un domaine du premier

niveau.

2. Configurer la console des opérations qui permet d’accéder directement à l’adaptateur.

Les deux modes s’excluent mutuellement.

Configurer l’hôte de gestion de bout en bout :

Nom d’hôte ou adresse IP Nom ou adresse IP de l’hôte sur lequel le gestionnaire d’automatisation de

bout en bout s’exécute.

Numéro de port d’événement Le port sur lequel le gestionnaire d’automatisation de bout en bout écoute

les événements de l’adaptateur d’automatisation de bout en bout. Le port

par défaut est 2002.

Configurer la console des opérations d’accès direct :

Nom d’hôte ou adresse IP Nom ou adresse IP de l’hôte sur lequel la console des opérations

s’exécute.

Numéro de port d’événement Le port sur lequel la console des opérations écoute les événements de

l’adaptateur d’automatisation de bout en bout. Le port par défaut est 2002.

Chapitre 12. Contrôle et administration d’IBM Tivoli System Automation 155

Contrôle et administration d’IBM Tivoli System Automation

Onglet Automatisation

Figure 22. Automatisation de l’adaptateur

Cet onglet vous permet de configurer les règles d’automatisation de l’adaptateur. Vous pouvez ainsi rendre

l’adaptateur d’automatisation de bout en bout hautement disponible, ce qui signifie que si le noeud sur

lequel l’adaptateur fonctionne s’arrête, l’adaptateur sera redémarré sur un autre noeud du domaine.

Remarque :

Tous les noeuds sur lesquels l’adaptateur peut fonctionner doivent être accessibles à l’aide des même ID

utilisateur et mot de passe.

Automatiser l’adaptateur dans le domaine d’automatisation du système

Cochez cette case si l’adaptateur d’automatisation de bout en bout

fonctionne dans un domaine homologue RSCT comportant plusieurs

noeuds. Consultez la section concernant l’automatisation à la page 150.

Interroger le domaine Si le noeud dans lequel la boîte de dialogue fonctionne se trouve dans le

domaine homologue RSCT, cette fonction permet d’interroger les règles

d’automatisation courantes. Si le domaine est actif, tous les noeuds actifs

s’affichent dans le tableau ’Noeuds définis’. Ce tableau fournit les

informations suivantes :

v Noeud défini

Si le domaine homologue RSCT est actif, tous les noeuds actifs

s’affichent ici.

v Automatisé sur le noeud

Indique si l’adaptateur d’automatisation de bout en bout doit être

automatisé sur ce noeud.

v Interface réseau

156 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Nom de l’interface réseau utilisée pour les requêtes issues de l’ hôte

utilisant l’adaptateur.

Les boutons situés en bas du tableau vous permettent d’effectuer les

tâches suivantes :

v Haut

Déplace le noeud sélectionné d’une ligne vers le haut dans l’ordre des

noeuds. La position détermine l’ordre dans lequel l’automatisation

sélectionne le noeud sur lequel l’adaptateur d’automatisation de bout en

bout peut fonctionner.

v Bas

Déplace le noeud sélectionné d’une ligne vers le bas dans l’ordre des

noeuds. La position détermine l’ordre dans lequel l’automatisation

sélectionne le noeud sur lequel l’adaptateur d’automatisation de bout en

bout peut fonctionner.

v Ajouter

Affiche le volet ’Ajouter noeud pour l’automatisation de l’adaptateur’ qui

vous permet de définir le nom du noeud à ajouter, de déterminer si le

noeud doit être ajouté à l’automatisation de l’adaptateur et d’indiquer le

nom de l’interface réseau.

v Supprimer

Supprime le noeud sélectionné de la liste. L’adaptateur d’automatisation

de bout en bout ne doit donc pas être démarré sur ce noeud.

v Modifier

Contrôle et administration d’IBM Tivoli System Automation

Affiche le volet ’Modifier noeud pour l’automatisation de l’adaptateur’ qui

vous permet de modifier le nom du noeud, d’ajouter ou de supprimer le

noeud de l’automatisation de l’adaptateur et modifier le nom de

l’interface réseau.

Préfixe des ressources automatisées

Cette option permet d’afficher le préfixe du nom des ressources ou des

groupes de ressources dans la règle d’automatisation. Vous pouvez

modifier le préfixe. Notez que les règles de l’adaptateur de bout en bout

ont été définies à l’aide d’un préfixe existant ; vous devez supprimer ces

règles avant de modifier le préfixe.

Adresse IP de l’adaptateur Indépendamment du noeud sur lequel il fonctionne, l’adaptateur

d’automatisation de bout en bout utilise cette adresse pour écouter et

recevoir les requêtes du serveur de gestion de bout en bout. Il s’agit d’une

adresse IP qui sera utilisée en tant que ressource ServiceIP afin

d’automatiser l’adaptateur. Vous devez obtenir cette adresse IP auprès de

votre administrateur réseau et il ne doit jamais s’agir d’une adresse hôte

ou d’un hôte local réel(le).

Masque de réseau Demande une valeur provenant de votre administrateur réseau.

Lorsque vous appuyez sur le bouton Enregistrer, toutes les modifications apportées aux fichiers de

configuration de l’adaptateur sont enregistrées et celles en cours de réalisation sont affichées dans un

panneau d’état de mise à jour de la configuration.

Chapitre 12. Contrôle et administration d’IBM Tivoli System Automation 157

Contrôle et administration d’IBM Tivoli System Automation

Onglet Sécurité

Figure 23. Configuration de la sécurité au niveau de l’adaptateur

Cet onglet vous permet de configurer la sécurité de l’interface entre l’adaptateur d’automatisation de bout

en bout et l’hôte de gestion de bout en bout.

Cochez la case Activer SSL si vous souhaitez utiliser le protocole SSL (Secure Socket Layer). Si vous

cochez cette case, les zones de saisie suivantes doivent être complétées.

Magasin de certificats Nom du fichier de stockage des certificats pour la couche SSL.

Magasin de clés Nom du fichier de stockage de clés utilisées pour la couche SSL.

Mot de passe du magasin de clés

Mot de passe du fichier de stockage de clés. Cette zone est obligatoire si

vous avez spécifié un fichier de stockage de clés.

Alias de magasin de clés Nom d’alias du certificat que le serveur doit utiliser. S’il n’est pas indiqué,

le fichier de stockage de clés doit contenir uniquement un nom qui sera le

seul nom à être utilisé.

Cochez également la case Forcer l’authentification de l’utilisateur pour activer l’authentification de

l’utilisateur avec le module PAM (Pluggable Access Module).

Service PAM Il s’agit du nom d’un fichier dans le répertoire /etc/pam.d (SUSE) ou d’une

entrée dans le fichier pam.d (RedHat) qui détermine les contrôles

effectués pour valider l’utilisateur.

Onglet Journal d’événements

Cet onglet vous permet de sélectionner le niveau de consignation des messages, le niveau de traçage

ainsi que les premières options des paramètres FFDC (first failure data capture).

158 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Figure 24. informations de consignation et de trace de l’adaptateur

Niveau de consignation des messages :

Erreur Messages des journaux relatifs au niveau d’erreur.

Avertissement Messages des journaux relatifs aux niveaux d’erreur et d’avertissement.

Informations Messages des journaux relatifs aux niveaux d’erreur, d’avertissement et

d’information.

Niveau de consignation de la fonction de trace :

Désactivé Aucune information de trace n’est conservée.

Minimum Rassemble les informations de trace relatives au niveau d’erreur.

Moyen Rassemble les informations de trace relatives aux niveaux d’erreur et

d’avertissement.

Maximum Fournit des historiques de trace et des messages et rassemble des

informations supplémentaires sur les niveaux d’erreur, d’avertissement et

d’information.

Paramètres FFDC (First Failure Data Capture) :

v Niveau d’enregistrement :

Contrôle et administration d’IBM Tivoli System Automation

Désactivé Ne rassemble aucune information sur les outils de diagnostic de

premier niveau (FFDC).

Minimum Fournit des historiques de trace et des messages et rassemble des

informations supplémentaires sur le niveau d’erreur.

Moyen Fournit des historiques de trace et des messages et rassemble des

informations supplémentaires sur les niveaux d’erreur et

d’avertissement.

Chapitre 12. Contrôle et administration d’IBM Tivoli System Automation 159

Contrôle et administration d’IBM Tivoli System Automation

Maximum Fournit des historiques de trace et des messages et rassemble des

informations supplémentaires sur les niveaux d’erreur, d’avertissement

et d’information.

v Espace disque :

Espace disque maximal Indique l’espace disque maximal en octet utilisé par les traces d’outil de

diagnostic de premier niveau écrites dans le répertoire de trace FFDC.

L’espace par défaut est de 10.485.760 (10 Mo).

Règle d’espace dépassé Sélectionne l’opération à effectuer lorsque l’espace disque maximal est

dépassé.

v ID message :

Mode de filtrage Lance le traçage de données FFDC en fonction des ID message

répertoriés dans la ’liste ID message’.

Liste des ID message : Indique les ID message qui déclenchent le traçage des données FFDC.

Des caractères génériques, tels que *E, qui signifie que tous les

messages d’erreur sont autorisés.

Si vous n’avez pas enregistré les modifications apportées dans l’onglet Automatisation, appuyez sur le

bouton Enregistrer une nouvelle fois pour passer dans le panneau d’état de mise à jour de la

configuration.

Réplication des fichiers de configuration de l’adaptateur

d’automatisation de bout en bout dans d’autres noeuds du domaine

Cliquez sur le bouton Répliquer de la figure 19, à la page 152 pour faire apparaître le volet suivant :

Figure 25. Panneau de réplication des fichiers de configuration de System Automation for Multiplatforms

Cette boîte de dialogue vous permet de distribuer (répliquer) la configuration ou les mises à jour du

gestionnaire d’automatisation de bout en bout dans d’autres noeuds du domaine homologue RSCT.

Sélectionnez les fichiers de configuration que vous souhaitez répliquer ou cliquez sur le bouton

Sélectionner tout pour sélectionner tous les fichiers de configuration.

Entrez l’ID utilisateur et le mot de passe des noeuds cible dans lesquels vous souhaitez répliquer les

fichiers.

Sélectionnez chaque noeud dans lequel vous souhaitez répliquer la configuration.

Lancez la réplication en cliquant sur le bouton Répliquer.

160 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Contrôle et administration d’IBM Tivoli System Automation

Lorsque la réplication est terminée, un panneau affiche l’état de chaque fichier de configuration pour

chaque noeud cible.

Définition des règles d’automatisation de bout en bout de l’adaptateur

Lorsque vous appuyez sur le bouton Définir du panneau (figure 19, à la page 152), des ressources

portant le nom de ressource (Ressource-/préfixe du groupe) sont créées comme indiqué à la page 157.

Notez que si des ressources automatisées portant le même nom existent, elles seront supprimées avant

de procéder à la création des nouvelles ressources.

Si vous spécifiez, par exemple, un nom ressource-/préfixe du groupe samadapter, le groupe de

ressources samadapter -rg, les ressources et les relations indiquées dans le tableau suivant seront créés.

Classe de ressources Nom de ressource Description

IBM.ResourceGroup samadapter-rg Le groupe de ressources se compose

de toutes les ressources

automatisées.

IBM.Application samadapter Application samadapter.

IBM.ServiceIP samadapter-ip L’adresse IP virtuelle à partir de

laquelle vous pouvez accéder à

l’adaptateur depuis l’hôte de gestion

de bout en bout et le module de

publication d’événements EIF.

IBM.Equivalency samadapter-nieq Interfaces réseau disponibles sur

chaque noeud.

IBM.ManagedRelationship samadapter-on-ip Dépendance de samadapter sur

l’adresse IP.

IBM.ManagedRelationship samadapter-ip-on-nieq Dépendance de l’adresse IP sur

l’interface réseau.

Il peut arriver que la définition et la suppression des règles générales d’IBM Tivoli System Automation for

Multiplatforms affectent la définition et la suppression des règles de l’adaptateur d’automatisation de bout

en bout. Pour obtenir des informations détaillées, consultez la description de la commande sampolicy dans

le manuel IBM Tivoli System Automation for Multiplatforms Base Component Reference.

Suppression des règles d’automatisation de bout en bout de

l’adaptateur

Lorsque vous appuyez sur le bouton Supprimer du panneau (figure 19, à la page 152), toutes les

ressources affichées dans le tableau précédent seront supprimées. Notez que vous devez supprimer les

règles d’automatisation de bout en bout de l’adaptateur avant de modifier le nom Ressource-/préfixe du

groupe, comme indiqué à la page 157.

Si l’adaptateur d’automatisation de bout en bout est toujours en cours d’exécution, le groupe de

ressources automatisées sera arrêté. Les ressources sont ensuite supprimées.

Remarque pour les administrateurs

Afin de pouvoir utiliser la boîte de dialogue de configuration de l’adaptateur de System Automation

for Multiplatforms, vous devez vous connecter au système avec l’ID utilisateur root ou vous devez

disposer des droits d’écriture dans les répertoires /etc/opt/IBM/tsamp/sam/cfg et /etc/Tivoli.

Chapitre 12. Contrôle et administration d’IBM Tivoli System Automation 161

Contrôle et administration d’IBM Tivoli System Automation

Contrôle d’IBM Tivoli System Automation

Vous pouvez utiliser plusieurs attributs pour modifier le comportement général d’IBM Tivoli System

Automation. Vous pouvez démarrer/arrêter la fonction d’automatisation, définir des délais d’attente ou

exclure certains 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 IBM Tivoli System Automation. 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 IBM Tivoli System Automation.

v ExcludedNodes

Liste de noeuds sur lesquels IBM Tivoli System Automation exclut de manière active les ressources ou

les arrête. Par exemple, cet attribut peut être utilisé à des fins de maintenance.

v ResourceRestartTimeOut

Délai en secondes au cours duquel IBM Tivoli System Automation attend avant de redémarrer les

ressources situées sur un noeud défectueux dans un autre noeud.

Les valeurs courantes des attributs décrits ci-dessus peuvent être répertoriées à l’aide de la commande

lssamctrl. Les attributs sont modifiés à l’aide de la commande samctrl. Reportez-vous au guide IBM Tivoli

System Automation for Multiplatforms Base Component Reference pour obtenir une liste et une description

de ces commandes.

TimeOut et RetryCount

Les paramètres TimeOut et RetryCount sont toujours utilisés de concert. Ils contrôlent le délai d’attente au

cours duquel IBM Tivoli System Automation attend que le gestionnaire de ressources entreprenne une

action et le nombre de fois qu’il avertira le gestionnaire de ressources de lancer une nouvelle tentative

lorsque la première a échoué. En règle générale, si une opération ne fonctionne pas la première fois, il y a

peu de chance qu’elle réussisse lors de la seconde tentative et des tentatives suivantes.

Opérations de démarrage

Le temporisateur des opérations est lancé lorsqu’IBM Tivoli System Automation envoie une opération de

contrôle de démarrage pour une ressource. Lorsque le temporisateur s’enclenche, il existe trois cas de

figure :

1. La ressource est modifiée avec l’état souhaité (en ligne ou hors ligne) au cours du délai d’attente. La

ressource possède l’état qu’IBM Tivoli System Automation lui a affecté et aucune autre action n’est

déclenchée.

2. La ressource rejette le contrôle de démarrage au cours du délai d’attente. La procédure qui suit

dépend du code de rejet. Si ce code indique que l’erreur est remédiable, IBM Tivoli System Automation

lance une nouvelle opération de contrôle de démarrage sur la ressource. Chaque tentative d’opération

de contrôle est comptabilisée et IBM Tivoli System Automation arrête d’émettre des opérations de

contrôle lorsque le nombre de tentatives autorisées (RetryCount) est dépassé. Si l’erreur n’est pas

remédiable, la ressource entrera dans un état de défectuosité. S’il s’agit d’une ressource fixe, aucune

action n’aura lieu. S’il s’agit d’une ressource flottante, IBM Tivoli System Automation essaiera une

autre instance, si tant est que l’instance sur laquelle portait la tentative de démarrage possédait l’état

Hors ligne ou Echec en ligne. Pour sortir la ressource de l’état défectueux, lancez une opération de

réinitialisation pour cette ressource.

162 IBM Tivoli System Automation Composant de base - Guide d’utilisation

3. La ressource n’atteint pas l’état souhaité (en ligne) à la fin du délai d’attente. IBM Tivoli System

Automation é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, IBM

Tivoli System Automation é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 IBM Tivoli System Automation 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.

Si IBM Tivoli System Automation 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 en

ligne. Cet état indique que cette ressource ne peut plus être utilisée. Une intervention manuelle est

obligatoire, la cause de l’échec doit être supprimée et la ressource réinitialisée à l’aide de la commande

RMC resetrsrc.

Notez qu’aucun seuillage n’est mis en oeuvre, le temporisateur de tentatives est réinitialisé si la ressource

atteint l’état souhaité. Par exemple, si la ressource lancée est En ligne pendant une courte période puis

s’arrête, IBM Tivoli System Automation la redémarrera en boucle.

Les valeurs par défaut sont les suivantes :

v TimeOut = 60

v RetryCount = 3

Contrôle et administration d’IBM Tivoli System Automation

Utilisez 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 telle

ressource dans un groupe, le délai d’expiration (TimeOut) n’est pas utilisé pour cette ressource. Le 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)

Si une ressource doit être arrêtée, aucun délai d’expiration n’est actif. Si l’opération de contrôle d’arrêt est

rejetée et que le code de rejet indique une erreur remédiable, cette opération pourra être tentée à

nouveau à condition que le paramètre RetryCount ne soit pas dépassé. Lorsque l’opération d’arrêt a été

acceptée, ou lorsque l’opération est en cours de validation/rejet, IBM Tivoli System Automation ne renvoie

pas d’opération de contrôle d’arrêt.

Lorsque l’opération de contrôle d’arrêt a été acceptée, l’utilisation d’un délai d’expiration et d’un cycle de

tentatives n’aurait aucun sens. Si l’ordre a été accepté, il est transmis et le RMC procède à l’arrêt de la

ressource. Il n’y a aucune raison de croire qu’un ordre d’arrêt secondaire ne fera aucune différence (ou ne

pourra pas être traité) ou de croire qu’un ordre de réinitialisation ne pourra pas être traité. S’il est

suspendu au cours d’un arrêt, il est probablement en attente d’une intervention de verrouillage ou d’une

intervention de l’utilisateur (ou alors la commande d’arrêt a été codée de manière incorrecte). Il ne sert à

rien de relancer l’opération de mise en ligne, cela pourrait engendrer la perte ou la corruption de données.

Automatisation

Cette coche indique si la fonction d’automatisation d’IBM Tivoli System Automation est activée ou non. Si

l’automatisation est désactivée, IBM Tivoli System Automation 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.

Chapitre 12. Contrôle et administration d’IBM Tivoli System Automation 163

Contrôle et administration d’IBM Tivoli System Automation

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 IBM Tivoli System Automation 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, IBM Tivoli System Automation

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 provoque l’arrêt du groupe entier.

La valeur par défaut est une liste vide, ce qui signifie que tous les noeuds du 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

Le paramètre ResourceRestartTimeout représente le délai exprimé en seconde pendant lequel IBM Tivoli

System Automation attend avant de redémarrer les ressources situées sur un noeud défectueux dans un

noeud en ligne. 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 valeur par défaut est de 5 secondes.

Utilisez la commande samctrl –o pour spécifier le délai d’attente de redémarrage.

Exemples

Pour répertorier les paramètres de contrôle courants d’IBM Tivoli System Automation, utilisez la

commande lssamctrl.

lssamctrl

Affichage des informations de contrôle d’IBM Tivoli System Automation :

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 = Disabled

Pour ajouter un noeud node05 dans 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

164 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Gestion des règles d’automatisation

L’élément central d’IBM Tivoli System Automation sont les règles définissant le comportement du système.

Les règles se composent des groupes de ressources, des relations entre les ressources et/ou des

groupes et équivalences. La tâche principale de l’administrateur consiste à maintenir ces règles et à veiller

à leur exactitude et au fait qu’elles puissent être recréées.

Pour gérer une ou plusieurs règles, utilisez la commande samcfg ou sampolicy. Ces commandes peuvent

être utilisées dans les deux cas de figure suivants :

1. Pour enregistrer une règle et la restaurer ultérieurement.

2. Pour remplacer complètement une règle.

Nous vous recommandons d’utiliser la commande sampolicy, nouveauté de la version 2 d’IBM Tivoli

System Automation. Elle gère les groupes de ressources, les relations, les équivalences, les ressources

IBM.Application, IBM.ServiceIP etIBM.Test, les paramètres de contrôle (samctrl), et les ressources

IBM.TieBreaker, tout en offrant une meilleure facilité d’utilisation.

La commande samcfg gère uniquement les groupes de ressources, les relations et les équivalences. Etant

donné que cette commande est toujours valide, le chapitre correspondant à son mode d’utilisation est

toujours d’actualité et disponible dans ce manuel.

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

obtenir des informations détaillées, consultez la description de la commande sampolicy dans le manuel

IBM Tivoli System Automation for Multiplatforms Base Component Reference.

Enregistrement d’une règle

IBM Tivoli System Automation utilise un fichier XML pour définir la règle d’automatisation.Voir le chapitre

’Policy Reference’ dans IBM Tivoli System Automation for Multiplatforms Base Component Reference pour

savoir comment définir un fichier de règles XML.

Utilisez la commande sampolicy pour enregistrer la règle dans un fichier appelé mypolicy.xml:

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 qui, par

exemple, est spécifiée dans un fichier XML appelé myPolicy.xml:

sampolicy -a /usr/xml/myPolicy.xml

Désactivation d’une règle en cours de fonctionnement

Désactivez la règle en cours de fonctionnement :

sampolicy -d

Contrôle et administration d’IBM Tivoli System Automation

Utilisation de la commande samcfg pour gérer des règles

Les chapitres suivants décrivent comment gérer les règles à l’aide de la commande samcfg.

Enregistrement des éléments de configuration

Les éléments enregistrés à l’aide de la commande samcfg sont les éléments d’une règle créés à l’aide

des commandes mkrg, addrgmbr, mkequ et mkrel. La commande samcfg ne peut procéder à

l’enregistrement d’éléments fournis par le RSCT, tels que les ressources des classes IBM.Application,

IBM.ServiceIP, ou IBM.Test.

La règle est enregistrée dans un fichier en tant que séquence de commandes mkrg, addrgmbr, mkequ et

mkrel d’IBM Tivoli System Automation avec les options et paramètres correspondants pour chaque entité.

Chapitre 12. Contrôle et administration d’IBM Tivoli System Automation 165

Contrôle et administration d’IBM Tivoli System Automation

Vous pouvez sélectionner le nom de fichier par défaut ou définir vous-même le nom du fichier. Ce fichier

est enregistré dans le noeud initiateur dans lequel la commande samcfg a été appelée. L’administrateur

peut copier ou enregistrer manuellement ce fichier dans plusieurs noeuds et emplacements.

Lorsque la règle est écrite dans le fichier, vous pouvez éditer manuellement le fichier pour modifier la

règle.

Par exemple, pour enregistrer la règle pour votre grappe SA_Domain, entrez :

samcfg -S

et la configuration sera enregistrée dans un fichier avec le nom de fichier par défaut

/var/ct/SA_Domain/cfg/SA_Domain030904.135022

Comme indiqué ci-dessus, les ressources qui ont été définies à l’aide de la commande RSCT mkrsrc ne

sont pas enregistrées par la commande samcfg.

Néanmoins, les définitions de ressources RSCT doivent également être enregistrées. Aucune

fonctionnalité de RSCT n’est comparable à la commande samcfg. Le procédé le plus simple pour

enregistrer les définitions RSCT consiste à placer les commandes de création de ressource (mkrsrc) avant

de les définir dans un script et d’exécuter ce script pour créer des ressources.

Restauration d’une configuration enregistrée ou remplacement de la configuration

enregistrée par une nouvelle configuration

Utilisez la commande samcfg –R pour restaurer une configuration enregistrée.

Avant d’exécuter la commande de restauration samcfg, assurez-vous de posséder toutes les ressources

RSCT nécessaires ou la restauration échouera.

Avant de procéder à la restauration, IBM Tivoli System Automation effectue une validation limitée des

règles et arrête également toutes les activités d’automatisation. Cela ne signifie pas que les ressources

gérées par IBM Tivoli System Automation sont arrêtées. Elles demeurent intactes jusqu’à l’implémentation

de la nouvelle configuration.

Vous pouvez utiliser cette fonction pour modifier une configuration en ligne.

Le fichier contenant la configuration enregistrée doit se trouver sur le noeud dans lequel la commande –R

sera invoquée. Par exemple, pour restaurer la configuration d’une grappe SA_Domain, entrez :

samcfg -R SA_Domain030904.135022

Vous obtenez les informations et questions suivantes :

Lecture de la configuration à partir du fichier SA_Domain030904.135022:

......

Vérification de la configuration SAM :

......

Prêt à valider la nouvelle configuration. Confirmez-vous l’opération ? [Y/N]:

y (où y=oui)

Lorsque vous avez entré ″y″ pour implémenter la nouvelle configuration, le démon maître actuel prend fin

et un démon homologue contenant la nouvelle règle le remplace avant de devenir à son tour le démon

maître. Le démon qui a pris fin sera redémarré automatiquement. Suite à l’arrêt du démon, un message

similaire au message suivant est généré dans le journal système :

Mar 10 15:51:42 lnxcm10x srcmstr: src_error=-9035, errno=0,

module=’srchevn.c’@line:’248’, 0513-035 Fin anormale du sous-système IBM.RecoveryRM.

SRC va faire une tentative et le redémarrer.

Vous pouvez ignorer ce message.

166 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Contrôle et administration d’IBM Tivoli System Automation

A l’aide d’un éditeur de texte, vous pouvez modifier une configuration enregistrée existante ou en créer

une toute nouvelle. Utilisez la commande samcfg –R comme indiqué ci-dessus pour remplacer la

configuration actuelle par une nouvelle ou par une configuration modifiée.

Utilisation des requêtes de démarrage et d’arrêt des groupes de

ressources et des ressources

Dans certaines situations, l’utilisateur aura besoin de pouvoir démarrer et arrêter des groupes de

ressources individuels sans modifier l’état nominal (NominalState) d’un groupe de ressources ou

l’utilisateur souhaitera démarrer ou arrêter des ressources individuelles au sein d’un groupe de ressources.

Par exemple, si une application appartenant à un groupe de ressources doit être arrêtée tandis qu’un

système de fichiers appartenant au même groupe de ressources doit rester En ligne pour effectuer une

sauvegarde des données. L’arrêt et le démarrage d’un groupe de ressources entier peut être atteint à

l’aide de la commande rgreq –o . Utilisez la commande rgmbrreq –o

pour démarrer ou arrêter la ressource individuelle.

Les requêtes d’arrêt et de démarrage sont persistantes, c’est-à-dire qu’il faut supprimer ces requêtes pour

les retirer du système à l’aide des commandes rgreq –o cancel ou rgmbrreq –o cancel. Les requêtes

priment toujours sur la valeur de l’état nominal d’un groupe de ressources.

Portée d’une requête d’arrêt et de démarrage

La portée d’une requête d’arrêt ou de démarrage sur un groupe de ressources affecte tous les membres

de ce groupe de ressources, tandis que la portée d’une requête d’arrêt ou de démarrage sur une

ressource unique n’affecte qu’une ressource en particulier. Les ressources dépendantes d’une ou de

plusieurs ressources impliquées dans une requête de démarrage ou d’arrêt peuvent être affectées, c.-à-d.

arrêtées ou démarrées. Cela signifie que toutes les relations sur d’autres ressources sont également

respectées lorsqu’un groupe de ressources ou une ressource est démarré ou arrêté par le biais d’une

requête.

Source d’une requête de démarrage ou d’arrêt

Une requête peut avoir plusieurs sources, pouvant être indiquées à l’aide de l’option –S au niveau des

commandes rgreq et rgmbrreq. La valeur de la source identifie la personne qui est à l’origine d’une

certaine requête. Les valeurs possibles sont Automation, ExtSched et Operator, qui est la valeur par

défaut.

Une requête soumise à partir de la source Automation est destiné à tout composant en dehors de

l’automatisation qui procède à la configuration d’une requête sur une ressource ou un groupe de

ressources dans IBM Tivoli System Automation for Multiplatforms, comme le composant de la gestion de

bout en bout de l’automatisation du produit. La source ExtSched, correspondant à 'external scheduler' est

destinée à tout programmateur comme le programme 'cron', également disponible sur les systèmes

d’exploitation Linux et AIX. Par exemple, si un travail Cron génère une requête d’arrêt sur une ressource

d’application avant d’avoir effectué une sauvegarde du système de fichiers, nous vous recommandons

d’utiliser la source ExtSched pour préciser l’origine de la requête.Enfin, la source Operator devra être

utilisée lorsqu’un utilisateur émet la requête sur un groupe de ressources ou une ressource.

Les requêtes de démarrage et d’arrêt effectuées depuis la même source se remplacent mutuellement, de

sorte qu’une seule requête ne puisse exister à partir d’une source sur un groupe de ressources ou une

ressource unique.

Priorité d’une requête de démarrage et d’arrêt

Les requêtes peuvent être émises avec différents niveaux de priorité tels que ″faible″ (par défaut), ″élevé″

et ″forcer″. Si des requêtes sont émises à partir de différentes sources sur une ressource, seule une

requête peut être active, et les requêtes à priorité élevée priment sur les requêtes à priorité inférieure. Le

Chapitre 12. Contrôle et administration d’IBM Tivoli System Automation 167

Contrôle et administration d’IBM Tivoli System Automation

schéma ci-dessous illustre le classement des niveaux de priorité des requêtes émises à partir de

différentes sources sur un groupe de ressources ou une ressource. Deux faits sont évidents :

1. 1. Toute requête est prioritaire sur l’état nominal (NominalState) d’un groupe de ressources.

2. 2. La source operator peut rejeter l’une ou l’autre source en configurant une requête avec un niveau

de priorité 'Forcer'.

Vous pouvez utiliser la commande lsrgreq comme décrit dans le manuel IBM Tivoli System Automation for

Multiplatforms Base Component Reference pour répertorier les requêtes en attente appliquées sur les

groupes de ressources ou les ressources gérées.

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

rgreq

Dans certaines situations, l’utilisateur aura besoin de pouvoir déplacer des groupes de ressources

individuels dans un autre noeud de grappe sans affecter toutes les ressources fonctionnant actuellement

sur le même noeud. Par exemple, en cas d’équilibrage de charges, le déplacement d’un ou de plusieurs

groupes de ressources dans un autre noeud peut affecter les objectifs de charge de travail et de

performances de l’utilisateur. 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 du mouvement se situe au niveau de tous les membres de niveau supérieur du groupe de

ressources. 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 l’attribut MemberLocation du groupe de ressources de niveau supérieur est défini sur colocalisé, aucune

liste de noeud ne doit être fournie avec 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

colocalisé, une liste composée d’un ou de plusieurs noeuds doit être spécifiée à l’aide 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 acceptée, elle ne peut être

annulée par son auteur. 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.

168 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Traitement d’une requête de déplacement

Une phase de mise hors ligne est effectuée lors de la requête de déplacement, au cours de laquelle tous

les membres du groupe de ressources déplacé seront stoppés en premier lieu, même s’ils fonctionnent

dans des noeuds qui ne se trouvent pas dans la liste des noeuds à déplacer. Cette opération est effectuée

afin d’éviter des complications lors du placement ultérieur de ressources. Le classeur affecte un nouveau

placement de noeud pour tous les membres du groupe de ressources et le groupe est redémarré. Il s’agit

de la phase de mise en ligne du déplacement. 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.

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.

Etablissement de diagnostics de ressources IBM Tivoli System

Automation

Pour obtenir des informations supplémentaires sur les ressources gérées par IBM Tivoli System

Automation, vous pouvez utiliser la commande samdiag documentée dans le manuel IBM Tivoli System

Automation for Multiplatforms Base Component Reference. 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 fournie avec la version 1 d’IBM Tivoli System Automation ne pouvait

être exécutée que dans le noeud sur lequel le démon principal fonctionnait. Aussi, l’exécution

de la commande samdiag sur un démon de version 2 générera une erreur si des démons

des versions 1 et 2 coexistent dans la même grappe et si le démon principal se trouve dans

un noeud de 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)

Contrôle et administration d’IBM Tivoli System Automation

Chapitre 12. Contrôle et administration d’IBM Tivoli System Automation 169

Contrôle et administration d’IBM Tivoli System Automation

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:

+---InCluster ---> Cluster

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 d’IBM Tivoli System Automation (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 DependsOn, 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.

170 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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énement TEC d’IBM Tivoli System

Automation

Lorsqu’IBM Tivoli System Automation modifie sa configuration, l’état de ressources ou rencontre un

problème, l’interface d’événement de Tivoli Enterprise Console (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 la TEC», à la page

172).

2. Via la publication d’attributs internes d’IBM Tivoli System Automation 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. Reportez-vous au manuel IBM Reliable Scalable Cluster Technology for

Linux,Technical Reference, SA22–7983, comment faire ; reportez-vous également à la description de

la section précédente «Génération d’événements en cas d’incidents», à la page 180.

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, IBM

Tivoli System Automation 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 la TEC

IBM Tivoli System Automation utilise la fonction d’intégration d’événements (EIF) Tivoli de l’interface

d’événements TEC pour envoyer des événements vers la TEC. Les événements seront envoyés sur le

port d’événements non TME du serveur de la TEC.

Les raisons suivantes sont à l’origine d’envoi d’événements d’IBM Tivoli System Automation vers la 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.

Contrôle et administration d’IBM Tivoli System Automation

Chapitre 12. Contrôle et administration d’IBM Tivoli System Automation 171

Contrôle et administration d’IBM Tivoli System Automation

Activation de la fonction de diffuseur de publications de la 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 la TEC en

effectuant les étapes suivantes :

1. Importez, compilez, chargez et activez le fichier baroc de la TEC dans le serveur TEC

(/usr/sbin/rsct/samples/tec/SystemAutomation.baroc). Reportez-vous au manuel IBM Tivoli Enterprise

Console Rule Builder’s Guide, GC32–0669, Procédure.

2. Copiez les fichiers /usr/sbin/rsct/samples/tec/samPublisher.conf et

/usr/sbin/rsct/samples/tec/TECPublisher.conf dans /etc/Tivoli/tec sur n’importe quel noeud de la grappe

IBM Tivoli System Automation.

3. Personnalisez le fichier de configuration du diffuseur de publications /etc/Tivoli/tec/samPublisher.conf et

le fichier EIF de la TEC /etc/Tivoli/tec/TECPublisher.conf dans chaque noeud de grappe.

4. Activez le diffuseur de publications à l’aide de la commande samctrl –e P sur un noeud de la grappe

IBM Tivoli System Automation. Par défaut, le diffuseur de publications est désactivé.

Fichier de configuration du diffuseur de publications

/etc/Tivoli/tec/samPublisher.conf

Le fichier de configuration du diffuseur de publications spécifie une liste de tous les clients cible et leurs

paramètres. Il s’agit du format de syntaxe du fichier de configuration du diffuseur de publications :

#

# Publisher configuration file

# file name: /etc/Tivoli/tec/samPublisher.conf

#

# File format:

# =

#

# 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 la 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 26. Format de syntaxe et exemple de fichier de configuration du diffuseur de publications

Les règles de syntaxe suivantes sont d’application :

v les lignes commençant par # et les lignes blanches seront ignorées.

v format de paramètre : =.

v le mot clé ″Publisher″ lance un nouveau triplet des paramètres ″Publisher″, ″LibraryPath″ et

″ConfigPath″.

v le mot clé ″Publisher″ spécifie le nom unique du diffuseur de publications.

172 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Contrôle et administration d’IBM Tivoli System Automation

v le mot clé ″LibraryPath″ spécifie le chemin d’accès absolu à la bibliothèque du diffuseur de

publications.

v le mot clé ″ConfigPath″ spécifie le chemin d’accès absolu au fichier de configuration EIF de la TEC.

v la valeur du mot clé "Publisher" doit comporter un nombre de caractères compris entre 1 et 8.

v la valeur du mot clé "Publisher" ne peut contenir que les caractères suivants : '0'-'9', 'A'-'Z', 'a'-'z' et '_'.

v seuls 15 diffuseurs peuvent être spécifiés dans ce fichier de configuration.

Fichier de configuration EIF de la TEC /etc/Tivoli/tec/TECPublisher.conf

Le fichier de configuration EIF de la 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 la TEC.

Le format de syntaxe du fichier EIF de la TEC pour le diffuseur de publications de la TEC est la syntaxe

existante du fichier de configuration EIF de la TEC.

Chapitre 12. Contrôle et administration d’IBM Tivoli System Automation 173

Contrôle et administration d’IBM Tivoli System Automation

# TEC EIF configuration file

#

# File format:

# =

#

# 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)

# 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)

# 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 User’s Guide”, GC32-0691,

# Chapitre : “Appendix B. Keywords for Configuration Files“.

#Indiquez le nom de serveur ou l’adresse IP du serveur sur lequel la TEC fonctionne

#champ “ServerLocation”.

ServerLocation=tecserver.ibm.com

ServerPort=5529

ConnectionMode=connection_less

BufferEvents=YES

BufEvtPath=/etc/Tivoli/tec/TECPublisher.cache

# 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 27. Format de syntaxe et exemple du fichier de configuration de la TEC

Pour éviter l’encombrement de la TEC par un flot important de messages, les filtres sont fournis dans le

fichier de configuration EIF # de la TEC. Tous les filtres sont activés par défaut ; seuls les messages

critiques sont envoyés à la TEC. Si vous souhaitez envoyer des messages supplémentaires à la TEC,

désactivez le filtre correspondant en utilisant le caractère de commentaire #.

Activation du diffuseur de publications

Par défaut, le diffuseur de publications est désactivé. Pour interroger 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 d’IBM Tivoli System Automation s’affichent :

SAMControl:

TimeOut = 60

RetryCount = 3

174 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Automation = Auto

ExcludedNodes = {}

ResourceRestartTimeOut = 5

ActiveVersion = [1.2.0.0,Fri Apr 16 16:05:50 2004]

EnablePublisher = Disabled

Pour activer le diffuseur de publications, exécutez la commande dans le noeud principal :

node1:/usr/sbin/rsct/samples/tec # samctrl –e P

Pour désactiver le diffuseur de publications, exécutez la commande dans le noeud principal :

node1:/usr/sbin/rsct/samples/tec # samctrl –d P

Configuration d’un nouveau paramètre de lieu pour les messages

d’événement de la TEC

Les messages d’événement de la 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 la TEC peuvent être

endommagés si l’utilisateur a créé les ressources (mkrg, mkrsrc) dans un shell 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 du shell.

Pour résoudre ce problème, les paramètres de lieu du système et du shell 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 du shell 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 contenant les paramètres de lieu du système par défaut, définissez les valeurs

appropriées et enregistrez le fichier.

SuSE Linux

File: /etc/sysconfig/language

Keywords: RC_LANG="" (remplacez 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 ces modifications sur 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="" (remplacez par vos paramètres régionaux)

AIX

Contrôle et administration d’IBM Tivoli System Automation

Chapitre 12. Contrôle et administration d’IBM Tivoli System Automation 175

Contrôle et administration d’IBM Tivoli System Automation

File: /etc/environment

Keywords: LANG="" (remplacez par vos paramètres régionaux)

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 d’IBM Tivoli System Automation dans

l’infrastructure RSCT

Cette fonction porte les attributs internes d’IBM Tivoli System Automation à 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’IBM Tivoli System Automation 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.

Toute modification de la valeur de ces attributs indique une modification d’état de la ressource qui sera

publiée dans le RSCT. Si le diffuseur de publications de la TEC est activé (voir «Activation de la fonction

de diffuseur de publications de la TEC», à la page 172), ces modifications d’état sont également indiquées

en tant qu’événements de la TEC.

Activation d’IBM Tivoli System Automation for GDPS/PPRC

Multiplatform Resiliency for zSeries

De nos jours, les marchés et les entreprises dépendent des solutions de reprise après incident afin de

récupérer des données vitales.

Par conséquent, IBM Tivoli System Automation prend en charge GDPS/PPRC Multiplatform Resiliency for

zSeries (xDR). xDR for zSeries est basé sur une fonctionnalité prévue pour Geographically Dispersed

Parallel Sysplex (GDPS) 3.1.

xDR for zSeries offre une solution coordonnée de reprise après incident pour les systèmes fonctionnant

sous zSeries, notamment z/OS et Linux for zSeries sous z/VM.

Notez que si vous souhaitez utiliser la fonction xDR, certaines versions de z/VM, Linux for zSeries, GDPS

et IBM Tivoli System Automation doivent être installées. Cette fonction et ces versions sont expliquées et

décrites en détail dans les manuels GDPS (Geographically Dispersed Parallel Sysplex).

176 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Notez également que la convention de dénomination xDR requiert que le noms de grappes et de noeuds

ne dépassent pas 32 caractères. Pour xDR, les noms des grappes ne sont pas sensibles à la casse.

Pour utiliser xDR, IBM Tivoli System Automation doit être personnalisé comme décrit ci-après.

Personnalisation de Tivoli Enterprise Integration Facility (EIF)

xDR utilise l’interface d’événement ’Tivoli Enterprise Integration Facility (EIF)’ de la TEC (Tivoli Enterprise

Console) pour envoyer des événements. Afin d’activer xDR pour l’envoi d’événements, ajoutez les lignes

suivantes dans le fichier de configuration du diffuseur de publications /etc/Tivoli/tec/samPublisher.conf (voir

«Fichier de configuration du diffuseur de publications /etc/Tivoli/tec/samPublisher.conf», à la page 172 pour

consulter un exemple de ce fichier).

Publisher=XDR_GDPS

LibraryPath=/usr/sbin/rsct/lib/libXDRPublisher.so

ConfigPath=/etc/Tivoli/tec/xdr.conf

Créez respectivement les fichiers de configuration xDR /etc/Tivoli/tec/xdr.conf et /etc/Tivoli/tec/xdr2.conf

similaires au fichier de configuration EIF de la TEC, (voir la section «Fichier de configuration EIF de la

TEC /etc/Tivoli/tec/TECPublisher.conf», à la page 173), avec le contenu et les valeurs de ServerLocation

et ServerPort affichés ici :

#

# XDR EIF configuration file

#

# File format:

# =

#

# ServerLocation - nom de l’hôte sur lequel le serveur GDPS fonctionne

# ServerPort - numéro de port du NetView Event Receiver

# 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)

ServerLocation=netview.ksys.ibm.com

ServerPort=5529

BufferEvents=NO

BufEvtPath=/etc/Tivoli/tec/xdrBuffer.cache

Figure 28. Format de syntaxe et exemple de fichier de configuration EIF de xDR

Cette opération doit être effectuée sur chaque noeud de la grappe.

Activez le diffuseur de publications à l’aide de la commande samctrl –e P. Par défaut, le diffuseur de

publications est désactivé.

Installation de l’interface Cpint

Cpint est une interface servant à appeler des commandes du programme de contrôle de la machine

virtuelle à partir de Linux. Elle est fournie avec la distribution SUSE LINUX. xDR requiert que l’interface

Cpint soit installée et chargée sur tous les noeuds de la grappe. Si vous ne la trouvez pas dans la

distribution, vous pouvez télécharger le tout dernier code à partir de l’adresse

http://linuxvm.org/Patches/index.html.

Exemple d’installation du module cpint-1.1.5.tar.gz:

1. Décompressez le fichier :

Contrôle et administration d’IBM Tivoli System Automation

Chapitre 12. Contrôle et administration d’IBM Tivoli System Automation 177

Contrôle et administration d’IBM Tivoli System Automation

gunzip -d cpint-1.1.5.tar.gz

tar -xvf cpint-1.1.5.tar

2. Générez l’interface cpint :

cd cpint-1.1.5

make

3. Installez l’interface cpint :

make install

Exécutez la commande cpint_load afin de charger l’unité et d’utiliser l’interface cpint.

Détection de présence xDR

Assurez-vous que l’EIF a été personnalisée comme indiqué dans la rubrique «Personnalisation de Tivoli

Enterprise Integration Facility (EIF)», à la page 177 et que la grappe a été redémarrée à chaque

modification des fichiers de configuration. Arrêtez la grappe à l’aide des commandes xdrStopCluster et

xdrstoperpd sur chaque noeud. Redémarrez la grappe à l’aide de la commande startrpdomain

nomgrappe. Activez le diffuseur de publications à l’aide de la commande samctrl –e P. Par défaut, le

diffuseur de publications est désactivé.

Ajoutez la ligne suivante dans le fichier /etc/inittab :

xdr:2345:respawn:/usr/bin/XDRHeartbeat

Utilisez ensuite la commande telinit q afin d’activer cette nouvelle entrée et de démarrer les détections de

présence. Vous devez effectuer cette opération pour chaque noeud de la grappe.

Démon de relevé des erreurs de l’unité de stockage à accès direct

(DASD)

Le démon de relevé des erreurs de l’unité de stockage à accès direct (erpd) doit être disponible à l’aide

d’IBM Tivoli System Automation. Veillez à ce que les fichiers de configuration du diffuseur de publications

et EIF de la TEC soient configurés comme indiqué ci-avant. Afin d’exécuter le script enableErpd qui définit

une ressource et un groupe de ressources, ajoute la ressource dans ce groupe et démarre ce groupe,

entrez la commande :

enableErpd

Exécutez cette commande dans chaque noeud de la grappe. Cette opération garantit le bon

fonctionnement du démon de relevé des erreurs de l’unité de stockage à accès direct.

Utilisez la commande chrg pour arrêter le démon et définir le groupe de ressources sur hors ligne :

chrg –o Offline

où nomgroupe est le groupe xdrerpd.

Arrêt d’une grappe/d’un noeud xDR à des fins de maintenance

Pour arrêter une grappe xDR entière, utilisez le script xdrStopCluster. Ce script utilise la commande

stoprpdomain pour arrêter la grappe et envoie un événement EIF au GDPS, désactivant ainsi xDR pour

cette grappe. Pour exécuter ce script, entrez simplement :

xdrStopCluster

Puis, arrêtez le démon de relevé des erreurs en exécutant la commande xdrstoperpd sur chaque noeud.

Pour arrêter xDR sur un seul noeud, utilisez la commande samctrl, par exemple :

samctrl –u a

Pour redémarrer xDR dans ce noeud, entrez :

samctrl –u d

178 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Vérification dynamique des ressources

En règle générale, les vérifications de ressources sont effectuées lors de la configuration, lorsque la

ressource est définie dans IBM Tivoli System Automation. 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. IBM Tivoli System Automation 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 être le cas lorsque, par exemple, vous définissez une ressource à l’aide de la commande

mkrsrc, que vous modifiez les valeurs de la ressource à l’aide de la commande chrsrc ou que vous

supprimez une ressource définie à l’aide de 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″. Dans ce cas, l’attribut dynamique ″ConfigValidity″ du groupe de ressources contiendra

la chaîne ″AllowedNode vide″.

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

Contrôle et administration d’IBM Tivoli System Automation

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

Chapitre 12. Contrôle et administration d’IBM Tivoli System Automation 179

Contrôle et administration d’IBM Tivoli System Automation

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″.

IBM Tivoli System Automation - Conseils et astuces

Cette section propose divers conseils et astuces utiles lors du fonctionnement d’une grappe avec System

Automation for Linux.

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

Vous pouvez à présent redémarrer votre 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

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

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

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 obtenir des explications supplémentaires sur la génération d’événements,

consultez le chapitre relatif au contrôle de ressources de base du manuel IBM Reliable Scalable Cluster

Technology for Linux, Technical Reference, SA22–7893.

180 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Chapitre 13. Gestionnaires de ressources fournis par IBM

Tivoli System Automation

Ce chapitre indique les gestionnaires de ressources fournis par IBM Tivoli System Automation.

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’IBM Tivoli System Automation.

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. IBM Tivoli System Automation 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 IBM Tivoli System Automation. 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. Divers délais 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.

Global resource RM

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 29 illustre la différence

entre des ressources d’agrégat et constituantes.

Figure 29. Ressource d’agrégat et ressources 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.

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

182 IBM Tivoli System Automation Composant de base - Guide d’utilisation

v MonitorCommandPeriod

v RunCommandsSync

v ProtectionMode

Global resource RM

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.

Attribut NodeNameList

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 (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.

Attribut ResourceType

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

Chapitre 13. Gestionnaires de ressources fournis par IBM Tivoli System Automation 183

Global resource RM

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.

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 StartCommand, StopCommand et

MonitorCommand par le gestionnaire de ressources», à la page 188.

Attribut StopCommand

La valeur de l’attribut persistant StopCommand contient la 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.

Cet attribut doit être spécifié lorsqu’une nouvelle ressource IBM.Application est définie.

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 StartCommand, StopCommand et

MonitorCommand par le gestionnaire de ressources», à la page 188.

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.

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).

Cet attribut doit être spécifié lorsqu’une nouvelle ressource 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 187 et «Gestion des codes retour des commandes

StartCommand, StopCommand et MonitorCommand par le gestionnaire de ressources», à

la page 188.

184 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Global resource RM

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.

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 de l’attribut doit être

inférieure ou égale à celle de l’attribut MonitorCommandPeriod. La valeur par défaut de

cet attribut est de 5 secondes.

Attribut StartCommandTimeout

A l’aide de l’attribut persistant StartCommandTimeout, vous pouvez spécifier la durée

d’exécution autorisée pour une commande de démarrage avant qu’elle ne soit supprimée

à l’aide de la commande killpg(). En outre, cet attribut indique également la durée au bout

de laquelle IBM Tivoli System Automation s’attend à ce que la ressource soit en ligne,

c.-à-d qu’IBM Tivoli System Automation utilise cette valeur au lieu du délai d’expiration par

défaut communiqué par 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

RunCommandSync 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 pouvez spécifier la durée

d’exécution autorisée pour une 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 par

défaut, alors 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 StartCommand 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 StartCommand arrivé à expiration. Utilisez CommandsSync=1 lorsque vous

connaissez la durée d’exécution de StartCommand. 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

Chapitre 13. Gestionnaires de ressources fournis par IBM Tivoli System Automation 185

Global resource RM

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 StartCommand 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.

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 (AIX ou Linux), l’environnement réduit pour

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

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 du

shell) 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

MonitorCommand, StartCommand et StopCommand 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.

Cet attribut doit être spécifié lorsqu’une nouvelle ressource IBM.Application est définie.

L’attribut doit être de type ″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

186 IBM Tivoli System Automation Composant de base - Guide d’utilisation

comportement, consultez le Chapitre 10, «Protection de vos ressources – support réalisé

par Quorum», à la page 123).

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.

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 :

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

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

Réservé pour une utilisation ultérieure.

HealthCommandTimeout

Réservé pour une utilisation ultérieure.

InstanceName

Réservé pour une utilisation ultérieure.

InstanceLocation

Réservé pour une utilisation ultérieure.

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 :

Chapitre 13. Gestionnaires de ressources fournis par IBM Tivoli System Automation 187

Global resource RM

1. Afin de satisfaire l’objectif d’automatisation, les ressources d’IBM Tivoli System Automation 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 tentez d’automatiser des systèmes de base, tels que des spoules d’impression ou des agents

de transfert de courrier, veillez à ce que ces services soient uniquement démarrés/arrêtés par

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

Gestion des codes retour des commandes StartCommand, StopCommand et

MonitorCommand par le gestionnaire de ressources

Le gestionnaire de ressources traite les codes retour des commandes StartCommand, StopCommand et

MonitorCommand comme suit:

StartCommand :

1. Si la commande StartCommand 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 StartCommand 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 StartCommand échoue, l’automatisation émet une commande StopCommand

afin de garantir que les restes du démarrage défectueux sont supprimés.

3. Si la commande StartCommand s’achève avec succès et renvoie la valeur 0, mais que la commande

MonitorCommand 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

188 IBM Tivoli System Automation Composant de base - Guide d’utilisation

tentera de redémarrer la ressource. Trois tentatives auront lieu, et si la ressource n’est toujours pas en

ligne après la troisième tentative, une commande StopCommand sera exécutée et la ressource sera

définie sur Echec hors ligne.

4. Si la commande StartCommand 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 StartCommand et considérera le démarrage comme une commande de démarrage

défectueuse, comme décrit au point 2, à la page 188.

5. Si la commande StartCommand é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 StartCommand, comme décrit au point

2, à la page 188.

StopCommand :

1. Si la commande StopCommand 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 StopCommand défectueuse dans

IBM Tivoli System Automation for Multiplatforms. La commande StopCommand peut indiquer un arrêt

défectueux de l’application en renvoyant une valeur autre que 0, mais cela ne générera aucune action

d’automatisation. Aucune autre tentative d’exécution de la commande StopCommand n’aura lieu.

3. Si la commande StopCommand 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 StopCommand défectueuse, comme décrit au

point 2.

4. Si la commande d’arrêt é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 une commande StopCommand défectueuse, comme décrit au point 2.

MonitorCommand :

Global resource RM

1. Si la commande MonitorCommand 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 187). 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

MonitorCommand 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

MonitorCommand 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 MonitorCommand 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.

Création de processus à partir de Global Resource Manager (gestionnaire de

ressources globales) pour les commandes StartCommand, StopCommand, et

MonitorCommand d’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 d’IBM Tivoli System Automation.

Chapitre 13. Gestionnaires de ressources fournis par IBM Tivoli System Automation 189

Global resource RM

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 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 elle-même, comme mycommand dans le pseudo-code précédent, peut être n’importe quelle

commande exécutable y compris les procédures du shell qui peuvent générer des processus

supplémentaires ou utiliser un contrôle de travail.

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

190 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Dans cette configuration, le shell utilisateur par défaut ne pourra prendre fin tant que tous les

processus enfant qui ont des descripteurs d’ouverture de fichier dans le shell, sont Le délai spécifié ici

pour l’attribut StartCommandTimeout s’applique également à mycommand, même s’il s’exécute en

arrière-plan du shell utilisateur. Ainsi, si le délai d’exécution de mycommand dépasse le délai spécifié

dans l’attribut StartCommandTimeout, le Gestionnaire de ressources globales enverra la commande

SIGKILL au shell utilisateur et propagera SIGKILL à l’ensemble du processus en arrière-plan.

Si vous souhaitez que cette configuration fonctionne, vous devez vous assurer que tous les

descripteurs de fichier du processus enfant du shell soient détachés du shell. 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 comme décrit 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 IBM Tivoli System Automation.

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 d’IBM Tivoli System Automation. 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é. Consultez le manuel IBM Tivoli System Automation

for Multiplatforms Base Component Reference pour obtenir une description détaillée de cette

commande.

MonitorCommand: /root/lpmon

ou

MonitorCommand: /usr/sbin/rsct/bin/pidmon ’/usr/sbin/lpd’

Global resource RM

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

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.

Chapitre 13. Gestionnaires de ressources fournis par IBM Tivoli System Automation 191

Global resource RM

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

DependsOn, l’automatisation choisira une ressource dans l’équivalence et mettra cette ressource à

disposition en tant que ressource de support pour IBM.Application.

Figure 30. Configuration d’une ressource de support pour une ressource IBM.Application

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 6, «Utilisation des

équivalences», à la page 49 et Chapitre 7, «Utilisation des relations gérées», à la page 53). Etant donné

que la plupart des ressources à partir de l’équivalence peuvent remplir les contraintes d’emplacement de

la relation DependsOn (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.

192 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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" ]

alors

# démarre la ressource B et la connecte à la ressource de support

# ressource A1

...

si

si [ $SA_SUPPORTING_RESOURCE_NAME = "A2" ]

# démarre la ressource B et la connecte à la ressource de support

# ressource A2

...

alors

si

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 fonctionnant au sein du 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 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.

Global resource RM

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

Chapitre 13. Gestionnaires de ressources fournis par IBM Tivoli System Automation 193

Global resource RM

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 :

IPAddress=192.168.1.5

NetMask="255.255.255.0"

NodeNameList="{’node01’,’node02’}"

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

NodeNameList="{’node02’}"

3. IPAddress=192.168.2.1

Netmask=255.255.255.0

NodeNameList="{’node03’}"

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

DependsOn», à la page 60) avec une équivalence des interfaces réseau (voir Chapitre 6, «Utilisation

des équivalences», à la page 49 relatif aux ressources de support). Si IBM Tivoli System Automation

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.

194 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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 :

IPAddress=9.152.192.1

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

NodeNameList="{’node01’}"

2. IPAddress=192.168.1.2

Netmask=255.255.255.0

NodeNameList="{’node02’}"

3. IPAddress=192.168.1.3

Netmask=255.255.255.0

NodeNameList="{’node03’}"

Les trois interfaces réseau forment une équivalence.

La figure suivante illustre la configuration :

Si IBM Tivoli System Automation 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.

les attributs suivants :

v Name

v IPAddress

Les ressources de cette classe peuvent posséder les attributs suivants :

v NodeNameList

Global resource RM

Chapitre 13. Gestionnaires de ressources fournis par IBM Tivoli System Automation 195

Global resource RM

v ResourceType

v NetMask

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 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 de type ″chaîne de caractères″.

Attribut NodeNameList

L’attribut persistant NodeNameList est un tableau de chaînes indiquant les noeuds sur

lesquels la ressource IBM.ServiceIP est disponible.

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.

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 (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.

La valeur de cet attribut pour les ressources d’agrégat 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.

Attribut ResourceType

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.

Attribut ProtectionMode

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

196 IBM Tivoli System Automation Composant de base - Guide d’utilisation

demandé. (Pour des informations supplémentaires sur ce comportement, consultez le

Chapitre 10, «Protection de vos ressources – support réalisé par Quorum», à la page 123.

L’attribut peut posséder les valeurs d’entier 0 (non vitale) ou 1 (vitale). La valeur par

défaut est ″Vitale″.

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 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. Sur Linux pour zSeries 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"

NodeNameList="{’node05’,’node06’}"

IPAddress=9.152.172.11

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"

NodeNameList="{’node05’,’node06’}"

IPAddress=9.152.172.11

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

Vous pouvez désormais vous connecter à l’IP de service ServiceIP avec l’équivalence :

Global resource RM

mkrel -p dependson -S IBM.ServiceIP:WebServerIP -G IBM.Equivalency:MyInterfaces WebIp_depon_MyInterfaces

Chapitre 13. Gestionnaires de ressources fournis par IBM Tivoli System Automation 197

Test resource manager

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. Ces ressources ne sont pas des ressources réelles

mais juste les conteneurs servant à définir, gérer et contrôler ces ressources. Ces ressources peuvent être

automatisées ou récupérées par IBM Tivoli System Automation. L’objet d’une classe IBM.Test est de

fournir une ressource simple et facile à gérer afin de simuler des scénarios d’automatisation sans la

surcharge des ressources réelles. 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 29, à la page 182 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.

l’attribut persistant suivant :

v Name

Les ressources de cette classe peuvent posséder les attributs suivants :

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

Attribut Name

L’attribut persistant Name est un nom défini par l’utilisateur pour 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.

198 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Attribut NodeNameList

L’attribut persistant NodeNameList est un tableau de chaînes 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.

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.

Attribut ResourceType

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 :

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

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 est capable de consigner des événements online,

offline et ForceOpState dans la fonction démon système de Linux. 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

Test resource manager

Chapitre 13. Gestionnaires de ressources fournis par IBM Tivoli System Automation 199

Test resource manager

Attribut OpState

La valeur de cet attribut d’état dynamique contient l’état 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 :

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

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 IBM Tivoli System Automation, le

gestionnaire d’automatisation démarre la ressource sur un autre noeud.

chrsrc -s "Name=’myTest’ && NodeNameList={’node02’}" IBM.Test ForceOpState=3

200 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Annexe. Identification et résolution des incidents

Cette section traite des diagnostics ainsi que de l’identification des problèmes et se rapporte à l’annexe

relative aux messages.

Les fichiers sont créés dans le répertoire "/var/ct//log/mc/IBM.RecoveryRM" qui contient le

résultat de traçage interne utile à la division des services opérations pour la résolution de problèmes.

L’utilitaire de traçage interne piste toutes les activités du démon du gestionnaire de ressources. Des

niveaux de détail multiples sont disponibles pour le diagnostic de problèmes. Un niveau minimum de

traçage est constamment actif. Le traçage complet peut être activé à l’aide de la commande :

traceson -s IBM.RecoveryRMd

Le traçage minimal peut être activé à l’aide de la commande :

tracesoff -s IBM.RecoveryRMd

Fichiers de diagnostic du gestionnaire de ressources

Tous les fichiers de trace sont écrits par l’utilitaire de traçage dans le répertoire

"/var/ct//log/mc/IBM.RecoveryRM". Chaque fichier présent dans ce répertoire appelé

trace correspond à une exécution du gestionnaire de ressources. Le dernier fichier correspondant à

l’exécution en cours du gestionnaire de ressources est appelé trace. Les fichiers de trace des exécutions

précédentes possèdent le suffixe .n, où n débute à 0 et augmente pour les exécutions les plus anciennes.

Utilisez la commande rpttr pour faire apparaître ces fichiers. Les enregistrements peuvent être affichés au

fur et à mesure qu’ils sont ajoutés au processus actif en ajoutant l’option –f à la commande rpttr.

Tout fichier core généré par une erreur de programme est inscrit par l’utilitaire de traçage dans le

répertoire "/var/ct//run/mc/IBM.RecoveryRM". Tout comme les fichiers de trace, les fichiers

core les plus anciens possèdent le suffixe .n qui est incrémenté au fur et à mesure. Les fichiers core et les

fichiers de trace possédant le même suffixe correspondent à la même instance d’exécution.

Le journal et les répertoires d’exécution ont une limite par défaut de 10 Mo. Les gestionnaires de

ressources garantissent que la quantité totale d’espace disque utilisée est inférieure à cette limite. Les

fichiers de trace qui ne possèdent pas de fichiers core correspondants sont supprimés en premier lieu

lorsque le gestionnaire de ressources dépasse cette limite. Ensuite, les paires de fichiers de trace et de

fichiers core sont supprimées, en commençant par les plus anciennes. Au moins une paire de fichier trace

et de fichier core est toujours conservée.

Restauration des incidents du RMC et du gestionnaire de ressources

Cette section décrit les outils que vous pouvez utiliser pour récupérer les incidents dans l’infrastructure.

Elle vous apprend à déterminer si les composants du système de contrôle fonctionnent ainsi que les

procédures à exécuter lorsque le sous-système RMC ou l’un des gestionnaires de ressources venaient à

s’arrêter de manière anormale. Les problèmes d’identification et de résolution des incidents ainsi que les

solutions générales sont également décrits.

Les gestionnaires de ressources de journal d’audit (Audit Log), de réponse à événement (Event

Response), de système de fichiers (File System) et hôte (Host) surmontent la plupart des erreurs, car ils

ne possèdent que peu de dépendances. Dans certains cas, la reprise sur incident consiste à mettre fin et

à redémarrer le démon approprié. Ces gestionnaires de ressources peuvent au minimum récupérer les

erreurs suivantes :

1. Perte de connexion au démon RMC, provoquée probablement par l’arrêt du démon RMC ou un autre

incident système.

Identification et résolution des incidents

2. Erreurs de programmation provoquant la fin anormale du processus. Dans ce cas, le sous-système

SRC redémarre le démon. Ces erreurs incluent les erreurs telles que des références de mémoire

incorrectes ou des fuites de mémoire.

3. Remplissage des répertoires /var ou /tmp. Les fichiers de trace et les fichiers core ne peuvent alors

être capturés.

En outre, tous les paramètres provenant du sous-système RMC sont vérifiés afin d’éviter des

répercussions chez d’autres clients utilisant le même gestionnaire de ressources.

Les outils suivants sont décrits :

1. Commande ctsnapd

2. Commandes contrôlées par le contrôleur des ressources système

3. Commande rmcctrl du sous-système RMC

4. Journal d’audit

Utilisation de la commande ctsnap

Vous pouvez utiliser la commande ctsnap à des fins de débogage afin de compacter les programmes

des gestionnaires de ressources et RSTC et de les envoyer à la division des services opérations. La

commande ctsnap rassemble les données relatives à la configuration système et les compresse dans un

fichier tar que vous pouvez télécharger sur un disque ou une bande magnétique et transmettre à un

système éloigné. Les données rassemblées à l’aide de la commande ctsnap peuvent être requises pour

l’identification et la résolution des incidents système. Consultez la page d’aide de la commande ctsnap

pour obtenir des informations supplémentaires.

Commandes contrôlées par le contrôleur des ressources système

Le sous-système RMC et les gestionnaires de ressources sont contrôlés par le contrôleur des ressources

système (SRC). Vous pouvez les afficher et les manipuler à l’aide des commandes du SRC. Par exemple :

Pour afficher l’état de tous les gestionnaires de ressources, entrez :

lssrc -g rsct_rm

Pour afficher l’état d’un gestionnaire de ressources individuel, entrez :

lssrc -s rmname

où rmname peut être :

v IBM.AuditRM

v IBM.DMSRM

v IBM.ERRM

v IBM.FSRM

v IBM.HostRM

v IBM.Sensor

Pour afficher l’état des sous-systèmes contrôlés par le contrôleur des ressources système sur la machine

locale, entrez :

lssrc -a

Le résultat de lssrc -a peut ressembler au suivant. Ce n’est pas un problème si certains sous-systèmes ne

sont actifs.

Subsystem Group PID Status

IBM.ConfigRM rsct_rm 387 active

ctcas rsct 419 active

cthats cthats 523 active

202 IBM Tivoli System Automation Composant de base - Guide d’utilisation

cthags cthags 524 active

ctrmc rsct 600 active

IBM.ERRM rsct_rm 615 active

IBM.RecoveryRM rsct_rm 637 active

IBM.AuditRM rsct_rm 662 active

IBM.GblResRM rsct_rm 695 active

IBM.TestRM rsct_rm 696 active

IBM.SensorRM rsct_rm inoperative

IBM.HostRM rsct_rm inoperative

Tous les sous-systèmes ne sont pas actifs par défaut. Certains sous-systèmes démarrent

automatiquement et certains sont démarrés lorsqu’ils sont tout d’abord référencés.

Pour afficher l’état d’un sous-système particulier, par exemple, le sous-système RMC connu par le SRC en

tant que ctrmc, entrez :

lssrc -s ctrmc

Le SRC dispose des commandes suivantes :

v lssrc

v startsrc

v stopsrc

v traceson

v tracesoff

Pour des informations supplémentaires, consultez les pages d’aide des commandes.

Pour des informations supplémentaires sur le SRC, consultez la rubrique System Management Concepts:

Operating System and Devices ou le guide d’administration IBM RSCT Administration Guide.

Un domaine System Automation for Multiplatforms est absent de

l’arborescence

Si un domaine d’automatisation de premier niveau ne figure pas dans l’arborescence de la console des

opérations, procédez comme suit pour analyser et résoudre le problème :

1. Vérifiez que l’adaptateur fonctionne en exécutant la commande suivante 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 :

Name OpState RSCTActiveVersion MixedVersions TSPort GSPort

domain1 Online 2.4.3.1 No 12347 12348

Si OpState n’est pas défini sur Online, démarrez le domaine.

Identification et résolution des incidents

Annexe. Identification et résolution des incidents 203

Identification et résolution des incidents

__________________________________________________________________________

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 fonctionne, vérifiez de nouveau au niveau de la console des opérations si le domaine

figure dans l’arborescence.

__________________________________________________________________________

5. Si le domaine n’y figure toujours pas, vous aurez besoin des informations de connexion que vous

avez indiquées dans la boîte de dialogue de configuration de l’adaptateur pour résoudre ce problème.

Procédez comme suit :

a. Lancez la boîte de dialogue de configuration de l’adaptateur d’IBM Tivoli System Automation for

Multiplatforms en exécutant la commande suivante sur un noeud dans le domaine :

cfgsamadapter

__________________________________________________________________________

b. Sur le premier écran de la boîte de dialogue Configuration, cliquez sur Configurer.

__________________________________________________________________________

c. Ouvrez la page Adaptateur à partir du panneau Configuration et entrez les valeurs qui s’affichent

dans les zones suivantes :

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 des 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 entrez les valeurs qui figurent dans les zones

suivantes :

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 des opérations

__________________________________________________________________________

6. Vérifiez que la gestion d’automatisation de bout en bout peut être atteinte à partir de n’importe quel

noeud dans le domaine. Pour se faire, effectuez un simple test en exécutant la commande ping

.

Si un pare-feu est installé entre les noeuds du domaine et l’hôte exécutant la console des opérations,

vérifiez avec l’administrateur de réseau si le pare-feu autorise une connexion entre le noeud (page

Adaptateur : Nom d’hôte ou adresse IP) et l’hôte exécutant la console des 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 des 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. Sur la page

Sécurité (voir «Onglet Sécurité», à la page 158), vérifiez que les paramètres de la couche SSL sont

corrects. Si la case Activer SSL est cochée, la console des opérations doit également être

sélectionnée pour prendre en charge SSL en mode d’accès direct.

Vérifiez ceci en exécutant la commande ./cfgdirect.sh dans le répertoire

/AppServer/profiles/default/Tivoli/EEZ. Vérifiez que les paramètres pour les clés

204 IBM Tivoli System Automation Composant de base - Guide d’utilisation

eez-ssl-truststore , eez-ssl-keystore, eez-ssl-keystore-password , et eez-ssl-keystore-alias utilisées

sont les mêmes que ceux indiqués dans l’onglet Sécurité (voir «Onglet Sécurité», à la page 158.

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. Si tel est le cas, utilisez la

commande

ps ax | grep sam.adapter

pour déterminer l’ID processus puis utilisez

kill

pour finaliser le processus samdapter.

__________________________________________________________________________

8. Sur l’hôte exécutant la console des 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

...

__________________________________________________________________________

9. Vérifiez que chaque noeud peut être atteint depuis la console des opérations. Pour se faire, effectuez

un simple test ping en exécutant la commande .

Si un pare-feu est installé entre l’hôte exécutant la console des 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 des 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 le numéro de port de la requête est défini sur 2001, netstat affiche un

message comme celui-ci sur les hôtes AIX 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 fonctionner sur le noeud principal du composant de base d’IBM Tivoli System Automation for

Multiplatforms

Pour vérifier que le diffuseur de publications fonctionne correctement, procédez comme suit :

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 du composant de base d’IBM Tivoli

System Automation for Multiplatforms (voir «Administration du Recovery Resource Manager», à la

page 23 pour savoir quel est le noeud principal) :

ps ax

Le résultat suivant devrait s’afficher :

Identification et résolution des incidents

Annexe. Identification et résolution des incidents 205

Identification et résolution des incidents

safli04:~ # ps ax | grep Publisher

25756 ? S 0:00 TECPublisher /etc/opt/IBM/tsamp/sam/cfg/EEZPublisher.conf EEZ

25757 ? S 0:00 TECPublisher /etc/opt/IBM/tsamp/sam/cfg/EEZPublisher.conf EEZ

25758 ? S 0:00 TECPublisher /etc/opt/IBM/tsamp/sam/cfg/EEZPublisher.conf EEZ

25759 ? 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

Le résultat suivant devrait s’afficher :

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=adapter_ip_address

ServerPort=5539

La valeur spécifiée pour adapter_ip_address 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 n’apparaît toujours pas au niveau de la console des opérations, contactez le service de

support logiciel IBM et entrez 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 :

Tivoli_common_dir=/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.

__________________________________________________________________________

Modification des paramètres de fuseau horaire pour la console des

opérations

La zone horaire qui apparaît dans les horodatages sur la console des opérations découlent des

paramètres de fuseau horaire du système d’exploitation sur lequel le serveur Integrated Solutions Console

est installé.Si les horodatages affichés sont différents du fuseau horaire local, vérifiez les paramètres de

fuseau horaire sur votre serveur Integrated Solutions Console.

Les paramètres de fuseau horaire peuvent généralement être définis à l’aide des outils de configuration

disponibles dans le système d’exploitation :

206 IBM Tivoli System Automation Composant de base - Guide d’utilisation

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.

Remarque :

AIX, Linux :

Si vous avez modifié les paramètres de fuseau horaire comme décrits ci-dessus mais que

les fuseaux horaires affichés dans les horodatages de la console des opérations ne

correspondent toujours pas, vous pouvez définir la variable d’environnement TZ pour

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"

Identification et résolution des incidents

Annexe. Identification et résolution des incidents 207

Identification et résolution des incidents

208 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Notices

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 :

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, Japon

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. IBM DECLINE TOUTE RESPONSABILITE,

EXPLICITE OU IMPLICITE, RELATIVE AUX INFORMATIONS QUI Y SONT CONTENUES, Y COMPRIS

EN CE QUI CONCERNE LES GARANTIES DE VALEUR MARCHANDE OU D’ADAPTATION A VOS

BESOINS. 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. Il est mis à jour périodiquement.

Chaque nouvelle édition inclut les mises à jour. IBM peut modifier sans préavis les produits et logiciels

décrits dans ce document.

IBM pourra utiliser ou diffuser, de toute manière qu’elle jugera appropriée et sans aucune obligation de sa

part, tout ou partie des informations qui lui seront fournies.

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

Department LJEB/P905

2455 South Road 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 concernant des produits non IBM ont été obtenues auprès des fournisseurs de ces

produits, par l’intermédiaire d’annonces publiques ou via d’autres sources disponibles. IBM n’a pas testé

ces produits et ne peut confirmer l’exactitude de leurs performances ni leur compatibilité. Elle ne peut

recevoir aucune réclamation concernant des produits non IBM. Toute question concernant les

performances de produits non IBM doit être adressée aux fournisseurs de ces produits.

Le présent document peut contenir des exemples de données et de rapports utilisés couramment dans

l’environnement professionnel. Ces exemples mentionnent des noms fictifs de personnes, de sociétés, de

marques ou de produits à des fins illustratives ou explicatives uniquement. Toute ressemblance avec des

noms de personnes, de sociétés ou des données réelles serait purement fortuite.

LICENCE DE COPYRIGHT :

Le présent logiciel contient des exemples de programmes d’application en langage source destinés à

illustrer les techniques de programmation sur différentes plateformes d’exploitation. Vous avez le droit de

copier, de modifier et de distribuer ces exemples de programmes sous quelque forme que ce soit et sans

paiement d’aucune redevance à IBM, à des fins de développement, d’utilisation, de vente ou de

distribution de programmes d’application conformes aux interfaces de programmation des plateformes

pour lesquels ils ont été écrits ou aux interfaces de programmation IBM. Ces exemples de programmes

n’ont pas été rigoureusement testés dans toutes les conditions. Par conséquent, IBM ne peut garantir

expressément ou implicitement la fiabilité, la maintenabilité ou le fonctionnement de ces programmes.

Vous avez le droit de copier, de modifier et de distribuer ces exemples de programmes sous quelque

forme que ce soit et sans paiement d’aucune redevance à IBM, à des fins de développement, d’utilisation,

de vente ou de distribution de programmes d’application conformes aux interfaces de programmation IBM.

Marques

Les termes suivants sont des marques d’International Business Machines Corporation aux Etats-Unis et/ou

dans certains autres pays :

v IBM, AIX, AIX 5L, Netfinity, RS/6000, SP, et le ’e’ (logo) sont des marques d’International Business

Machines Corporation.

v Equinox est une marque d’Equinox Systems, Inc.

v Linux est une marque de Linus Torvalds aux Etats-Unis et/ou dans certains autres pays.

v Myrinet est une marque de Myricom, Inc.

v Red Hat et RPM sont des marques de Red Hat, Incorporated.

v Java et toutes les marques et logos incluant Java sont des marques de Sun Microsystems, 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 autres pays.

v D’autres sociétés sont propriétaires des autres marques, noms de produits ou logos qui pourraient

apparaître dans ce document.

210 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Index

Caractères spéciaux

(EIF) fonction d’intégration d’événements 171

A

à propos de ce manuel xi

adaptateur d’automatisation de bout en bout 149

automatisation de l’adaptateur 150, 156

configuration 152

configuration pour console des opérations 102

définition des règles 161

onglet adaptateur 153

onglet hôte utilisant l’adaptateur 155

onglet journal d’événements 159

onglet sécurité 158

présentation 150

réplication des fichiers de configuration 160

adresse e-mail xiii

ajout d’une ressource membre à

groupes de ressources 45

arborescence des ressources

filtres de nom 116

icônes 115

présentation 115

arborescence des topologies

Colonne Etat 114

Colonne Situé(e) ici 115

masquage des domaines 114

présentation 113

arrêt

Integrated Solutions Console 104

serveur Eclipse Help System 104

Arrêt

ressources 119

arrêt d’un groupe de ressources 46

attribut AutomationDetails 43

attribut Condition 55

attribut d’équivalence MemberClass 50

attribut d’équivalence Membership 50

attribut d’équivalence SelectFromPolic 50

attribut d’équivalence SelectString 50

attribut de groupe de ressources AllowedNode 38

attribut de groupe de ressources MemberLocation 39

attribut de groupe de ressources Name 40

attribut de groupe de ressources NominalState 40

attribut de groupe de ressources OpState 42

attribut de groupe de ressources Priority 40

attribut de groupe de ressources TopGroup 42

attribut de la relation DependsOnAny 64

attribut dynamique 30

AutomationDetails 38

ConfigValidity 179

définition 2

MoveStatus 43, 169

OpQuorumState 128

OpState 32, 37, 183, 196

attribut dynamique (suite)

TopGroup 38

attribut ExcludedList 41

attribut Mandatory de la classe ManagedResource 44

attribut MemberOf 44

attribut Name 54

attribut NodeNameList de la ressource 31

attribut OpState de ressource 32

attribut persistant 30

AllowedNode 38

Condition 55

définition 2

ExcludedList 41

ForceOpState 199

IPAddress 196

Mandatory 44

MemberClass 50

MemberLocation 39

MemberOf 44

membres 50

modification des valeurs 46

MonitorCommand 184

MonitorCommandPeriod 185

MonitorCommandTimeout 185

Name 40, 54, 183, 196, 198

NetMask 196

NodeNameList 31, 183, 196, 199

NominalState 40

OpQuorumOverride 137

Priority 40

ProtectionMode 126, 186, 196

Relationship 54

ResourceType 31, 183, 196, 199

RunCommandsSync 185

SelectFromPolicy 50

SelectString 50

Source 54

StartCommand 183

StartCommandTimeout 185

StopCommand 184

StopCommandTimeout 185

Target 54

TimeToStart 199

TimeToStop 199

UserName 186

WriteToSyslog 199

Attribut ProtectionMode 126

attribut Relationship 54

attribut ResourceType de ressource 31

attribut SelectFromPolicy 31

attribut Source 54

attribut Target 54

attributs

attributs de ressource, description de 2, 29

dynamique 30

dynamiques 2

NodeNameList 31

SelectFromPolicy 31

attributs (suite)

utilisé par IBM.Application 182

utilisé par IBM.ServiceIP 195

utilisé par IBM.Test 198

utilisé par les équivalences 50

utilisé par les groupes de ressources 37

utilisé par les relations gérées 54

utilisé par les ressources 31

variables 2, 30

automatisation

événements affectant l’automatisation 79

paramètres 163

C

carte d’automatisation 149

classe de ressources

définition 2

classes de ressources

définition 29

IBM.Application 181

IBM.ServiceIP 193

IBM.Test 198

IBM.TieBreaker 128

classeur

définition 77

Cluster Systems Management (CSM) 7

commande addrgmbr 45

commande addrpnode 21

commande chequ 51

commande chrg 46

commande chrgmbr 47

commande ctsnap 202

commande lsequ 51

commande lsrel 74

commande lsrg 45

commande lsrpnode 23

commande mkequ 51

commande mkrel 74

commande mkrg 44

commande mkrpdomain 20

commande preprpnode 20

commande rmequ 52

commande rmrel 75

commande rmrg 47

commande rmrgmbr 47

commande rmrpdomain 23

commande rmrpnode 23

commande samctrl 180

commande samdiag 169

commande startrpdomain 20, 23

commande startrpnode 21

commande stoprpdomain 22

commande stoprpnode 22, 23

commandes

addrgmbr 45

addrpnode 21

chequ 51

chrg 46

chrgmbr 47

ctsnap 202

212 IBM Tivoli System Automation Composant de base - Guide d’utilisation

commandes (suite)

lsequ 51

lsrel 74

lsrg 45

lsrpnode 23

mkequ 51

mkrel 74

mkrg 44

mkrpdomain 20

preprpnode 20

rmequ 52

rmrel 75

rmrg 47

rmrgmbr 47

rmrpdomain 23

rmrpnode 23

samctrl 180

samdiag 169

startrpdomain 20, 23

startrpnode 21

stoprpdomain 22

stoprpnode 22, 23

comportement d’arrêt de la relation DependsOn 62

comportement d’arrêt forcé de la relation

DependsOn 60

comportement de démarrage de la relation

DependsOn 60

condition de départage 4, 128, 135

Condition de départage du réseau 135

condition de départage Fail 128

condition de départage Operator 128

condition IFNotOffline 67

condition IFNotOnline 67

condition IFOffline 67

condition IFOnline 67

conditions pour les relations d’emplacement 67

configuration d’un réseau hautement disponible 139

ConfigValidity, attribut dynamique 179

connaissances préalables à la lecture de ce manuel xi

connexion 111

console des opérations

accès 111

arborescence des ressources 115

arborescence des topologies 113

CD et archives 7, 95

Configuration de l’adaptateur d’automatisation de

bout en bout 102

configuration pour être utilisée en mode d’accès

direct 103

connexion 111

couche 113

création et autorisation d’utilisateurs et de

groupes 106

démarrage et arrêt 105

espace disque requis 95

gestion des requêtes 118

gestion des ressources 118

installation 94

planification de la configuration 103

présentation 93

procédure d’installation 97

console des opérations (suite)

script de configuration 103

Zone d’information 116

Console ISC (Integrated Solutions Console)

connexion 111

contrôleur des ressources système 189

création

équivalence 51

groupes de ressources 27, 44

relations 74

création d’un groupe de ressources 44

D

définition

grappe 20

règles d’automatisation 27

relations 27

ressources RSCT 24

démarrage

Integrated Solutions Console 104

serveur Eclipse Help System 104

Démarrage

ressources 118

démarrage d’un groupe de ressources 46

DependsOn

attribut de relation 60

comportement d’arrêt 62

comportement de démarrage 60

modèles de comportement 60

désinstallation d’IBM Tivoli System Automation 16

diagnostic de ressources 169

domaine d’automatisation de premier niveau 149

E

enregistrement d’une règle 166

énumération

groupes de ressources 45

relations 74

équivalences

attributs utilisés par 50

création 51

description de 3, 49

listage 51

modification 51

règles d’utilisation 50

suppression 52

établissement d’une équivalence 51

établissement d’une liste de noeuds pour

membres de groupes de ressources 45

événements affectant l’automatisation 79

F

fichier baroc 172

fichier de configuration du diffuseur de

publications 172

fichier de configuration EIF de la TEC 173

fichiers core 201

fichiers de diagnostic du gestionnaire de

ressources 201

fichiers de trace 201

fonction d’intégration d’événements de Tivoli

(EIF) 149, 171

fonction du diffuseur de publications de la TEC 172

G

General Parallel File System (GPFS) 7

gestion des règles d’automatisation 165

gestionnaire de ressources

classe de ressources IBM.Application 181

classe de ressources IBM.ServiceIP 193

classe de ressources IBM.Test 198

Global Resource RM 181

test resource manager 198

gestionnaire de ressources de réponse à événement

(ERRRM) 180

grappes

ajout de noeuds dans 21

définition et administration 20

mise hors ligne 22

restauration d’une configuration 166

suppression 23

groupe de ressources

ajout d’une ressource membre à 45

arrêt 46

attributs utilisés par 37

création 44

démarrage 46

déplacement 168

description de 35

énumération (y compris de ses membres

ressource) 45

établissement d’une liste de noeuds pour 45

états 40

modification des attributs de 46

permettant la mise en ligne 79

suppression 47

groupes d’utilisateurs

suppression au niveau de la console Integrated

Solutions Console 111

I

IBM.Application 182

IBM.Equivalency

classe de ressources 118

IBM.RecoveryRM 23

IBM.ServiceIP

attributs 195

définition 193

détection des échecs de l’interface réseau 140

IBM.TestRM 198

IBM Tivoli System Automation

coexistence avec d’autres produits 7

configuration d’un réseau hautement disponible 139

désinstallation 16

installation 7, 12

migration 13

Index 213

IBM Tivoli System Automation (suite)

mise en route 19

planification de l’installation 7

plateformes prises en charge 8

ID utilisateur

suppression au niveau de la console Integrated

Solutions Console 110

installation d’IBM Tivoli System Automation 7, 12, 19

configurations initiales 11

désinstallation du service 17

langues prises en charge par IBM Tivoli System

Automation 12

préparation en vue de l’installation 9

prérequis 10

service d’installation 17

Integrated Solutions Console

arrêt 104

démarrage 104

modification des mots de passe 110

suppression des groupes d’utilisateurs 111

suppression des ID utilisateur 110

interface d’événement TEC (Tivoli Enterprise

Console) 171

interface d’événement Tivoli Enterprise Console

(TEC) 171

ISO 9000 xiii

L

listage

équivalence 51

liste de noeuds, établissement 45

liste de noeuds d’une ressource 31

liste des requêtes

M

marques 210

membres de groupes de ressources

modification des attributs de 47

Mémoire-tampon Telnet 11

migration d’IBM Tivoli System Automation 13

considérations 13

fin de processus de migration 15

migration d’un domaine tout entier 14

migration d’un noeud étape par étape 14

mise à jour d’IBM Tivoli System Automation 12

mise en évidence xii

modification

attributs des membres de groupes de

ressources 47

équivalence 51

un groupe de ressources 46

modification d’une règle 167

module pdksh 10

mots de passe

modification au niveau de la console Integrated

Solutions Console 110

MoveStatus, attribut dynamique 43, 169

214 IBM Tivoli System Automation Composant de base - Guide d’utilisation

N

noeuds

arrêt d’un noeud 180

mise hors ligne 22

redémarrage d’un noeud 180

suppression d’une grappe 23

numéro de version d’IBM Tivoli System Automation 15

O

obtenir des informations du quorum 127

P

Page Général

présentation 117

page informations supplémentaires

présentation 118

Page Règles

présentation 117

page relations

présentation 118

paramètre ExcludedNodes 164

paramètre ResourceRestartTimeout 164

paramètres

automatisation 163

ExcludedNodes 164

ResourceRestartTimeout 164

TimeOut et RetryCount 162

paramètres TimeOut et RetryCount 162

prise en charge des reprises sur incident 201

prise en charge des reprises sur incident pour les

gestionnaires de ressources 201

public de ce manuel xi

Public Domain Korn Shell (pdksh) packag 10

publication des attributs internes d’IBM Tivoli System

Automation 176

Q

quorum

condition de départage 125

majorité de noeuds 123

obtenir des informations 127

quorum de configuration 4, 124

quorum opérationnel 4, 124

quorum de configuration 4, 124

quorum opérationnel 4, 124

R

recovery resource manager (IBM.RecoveryRM) 23

règle

enregistrement et modification d’une règle 165

gestion des règles d’automatisation 165

modification d’une règle 165

remplacement d’une règle 165

relation

DependsOn 60

DependsOnAny 64

elation affinity 71

relation AntiAffinity 72

relation AntiCollocated 69

relation collocated 67

relation ForcedDownBy 65

relation IsStartable 72

relation StartAfter 56

relation StopAfter 58

relations

Affinity 71

AntiAffinity 72

AntiCollocated 69

Collocated 67

création 74

énumération 74

ForcedDownBy 65

IsStartable 72

relation location 66

StartAfter 56

StopAfter 58

suppression 75

relations gérées

attributs utilisés par 54

description de 53

relations location 66

requête

annulation 120

Requête

Actif 118

arrêt 119

requête d’arrêt 119

requête de démarrage 118

requêtes

démarrage et arrêt de groupes de ressources et de

ressources 167

traitement d’une requête de déplacement 169

réseau hautement disponible 139

ressource

attributs utilisés par 31

critique 123, 126

description d’une classe de ressources 2

description de 2, 29

description de la classe de ressources 29

description des attributs de ressource 2, 29

état nominal 3, 33

vérification 179

ressource critique 123

ressource d’agrégat 182

ressource gérée

description de 3, 30

ressources constituantes 182

ressources fixes

définition 31

ressources flottantes

définition 32

restauration d’une configuration en grappe 166

restauration d’une règle 166

S

Serveur Eclipse Help System

arrêt 104

démarrage 104

service d’installation 17

suppression

d’une ressource membre d’un groupe de

ressources 47

équivalence 52

groupes de ressources 47

relations 75

suppression d’une ressource membre

groupes de ressources 47

T

tâches à effectuer après l’installation

pour les administrateurs

attribution des droits d’accès 107

TEC (Tivoli Enterprise Console) 171

test resource manager 198

Tivoli Enterprise Console (TEC) 171

transitions d’état pour un groupe de ressources 42

type de ressource 31

U

utilisation de ce guide xi

V

vérification des ressources 179

vérification du numéro de version 15

VMTIMEBOMB 126

Z

Zone d’information

présentation 116

Index 215

216 IBM Tivoli System Automation Composant de base - Guide d’utilisation

Numéro de programme : 5724-M00

SC11-2269-00

Spine information:

Version 2.1

SC11-2269-00

IBM Tivoli System Automation Composant de

base - Guide d’utilisation

IBM Tivoli System Automation

for Multiplatforms

IBM Tivoli System Automation Composant de base - Guide d'utilisation

IBM Tivoli System Automation Composant de base - Guide d'utilisation ... View more IBM Tivoli System Automation Composant de base - Guide d'utilisation

Delete template?

Save as template ?

IBM Tivoli System Automation Composant de base - Guide d'utilisation IBM Tivoli System Automation Composant de base - Guide d'utilisation