Composant de base - Guide d utilisation

Transcription

1 IBM Tivoli System Automation for Multiplatforms Composant de base - Guide d utilisation Version 2.1 SC

2

3 IBM Tivoli System Automation for Multiplatforms Composant de base - Guide d utilisation Version 2.1 SC

4 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 : SC 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 (serveur IBM en France) v (serveur IBM au Canada) v (serveur IBM aux Etats-Unis) Compagnie IBM France Direction Qualité Tour Descartes Paris-La Défense Cedex 50 Copyright IBM France Tous droits réservés. Copyright International Business Machines Corporation 2003, All rights reserved.

5 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 xiii Rubriques connexes xiii Comment obtenir des publications xiii Comment nous contacter par xiii Chapitre 1. Introduction Généralités Haute disponibilité et moniteur de ressources Automatisation basée sur des règles Reprise sur incident automatique Mouvement automatique des applications Regroupement de ressources Termes d IBM Tivoli System Automation Grappe / domaine homologue Ressource Attribut de ressource Classe de ressources Groupe de ressources Ressource gérée Etat nominal Equivalence Relations Quorum Condition de départage Composants d IBM Tivoli System Automation Introduction aux gestionnaires de ressources intégrés dans IBM Tivoli System Automation Console des opérations Adaptateur d automatisation de bout en bout Chapitre 2. Installation du composant de base d IBM Tivoli System Automation Planification de l installation Coexistence avec d autres produits : Contenu du CD : CD / archives pour le composant de base Envoi électronique d IBM Tivoli System Automation Plateformes prises en charge : Interfaces de réseau prises en charge Préparation de l installation Conditions préalables Configurations initiales Installation et mise à jour du composant de base d IBM Tivoli System Automation for Multiplatforms 12 Installation du produit Installation de la Licence du produit Langues prises en charge par IBM Tivoli System Automation Migration du produit Copyright IBM Corp. 2003, 2005 iii

6 Désinstallation d IBM Tivoli System Automation Service d installation Désinstallation du service Chapitre 3. Mise en route Etape 1 : Définition et administration d une grappe Création d une grappe à deux noeuds Ajout d un noeud dans une grappe existante Mise hors ligne d une grappe entière ou de noeuds individuels Suppression des noeuds d une grappe ou suppression d une grappe entière Administration du Recovery Resource Manager Etape 2 : Définition des ressources RSCT Création de la ressource d application apache Création de l adresse IP de la ressource apache1ip Création d une équivalence pour les cartes réseau Etape 3 : Définition des règles d automatisation Création d un groupe de ressources Définition de relations Mise en ligne d un groupe de ressources Chapitre 4. Utilisation des ressources Qu est ce qu une ressource? Qu est ce qu une classe de ressources? Qu est ce que les attributs de ressources? Quelle est la différence entre des attributs persistants et des attributs dynamiques? Qu est ce qu une ressource gérée? Travailler avec des ressources Attributs utilisés par les ressources Attribut NodeNameList Attribut SelectFromPolicy Attribut ResourceType Attribut OpState Etat nominal de la ressource Chapitre 5. Utilisation des groupes de ressources Qu est ce qu un groupe de ressources? Règles d utilisation des groupes de ressources Attributs utilisés par les groupes de ressources Attribut AllowedNode Attribut MemberLocation Attribut Name Attribut NominalState Attribut Priority Attribut ExcludedList ActivePeerDomain Description InfoLink Owner Subscription Attribut OpState Attribut TopGroup Attribut AutomationDetails MoveStatus ConfigValidity Attributs utilisés pour les membres de groupes de ressources Attribut Mandatory iv IBM Tivoli System Automation Composant de base - Guide d utilisation

7 Attribut MemberOf Définition et administration d un groupe de ressources Création d un groupe de ressources Ajout d une ressource membre dans un groupe de ressources Enumération d un groupe de ressources ou de ses ressources membres Démarrage et arrêt d un groupe de ressources Modification des attributs d un groupe de ressources Modification des attributs des membres d un groupe de ressources Suppression d une ressource membre d un groupe de ressources Suppression d un groupe de ressources Chapitre 6. Utilisation des équivalences Qu est ce qu une équivalence? Règles d utilisation des équivalences Attributs utilisés par les équivalences Attribut MemberClass (classe de membres) Attribut Membership (appartenance) Attribut SelectString (chaîne sélection) Attribut SelectFromPolicy (sélection à partir d une règle) Attributs utilisés par les membres des équivalences Définition et administration des équivalences Création d une équivalence Liste d une ou plusieurs équivalences Modification d une équivalence Suppression d une équivalence Chapitre 7. Utilisation des relations gérées Qu est ce qu une relation gérée? Attributs utilisés dans les relations gérées Attribut Name Attribut Source Attribut Target Attribut Relationship Attribut Condition Relations du comportement de démarrage/d arrêt Relation StartAfter Relation StopAfter Relation DependsOn Relation DependsOnAny Relation ForcedDownBy Relations Location Conditions IfOnline, IfOffline, IfNotOnline et IfNotOffline Règles relatives à l utilisation des relations Location Relation Collocated Relation AntiCollocated Relation Affinity Relation IsStartable Création et administration des relations Création d une relation Enumération d une relation Modification d une relation Suppression d une relation Chapitre 8. Traitement des informations système par IBM Tivoli System Automation Définition de la relation d emplacement : algorithme de liaison Evénements permettant la mise en ligne d un groupe de ressources Table des matières v

8 Modèles de comportement d IBM Tivoli System Automation for Multiplatforms Considérations générales Réaction d IBM Tivoli System Automation aux modifications éventuelles d état opérationnel d une ressource en ligne sur un noeud Composition de l état opérationnel d un groupe de ressources par l automatisation de système Réactions de l automatisation de système aux modifications d état opérationnel d une ressource démarrée ou arrêtée 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 Chapitre 9. Utilisation de la console des opérations Vue d ensemble - Qu est-ce que la console des opérations? Installation de la console des opérations Espace disque requis pour l installation de la console des opérations CD/archives pour la console des opérations Procédure d installation 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 Planification de la configuration Exécution du script de configuration pour la console des opérations en mode d accès direct Démarrage et arrêt d Integrated Solutions Console Démarrage et arrêt des serveurs sous Windows Démarrage et arrêt de la console des opérations sur AIX et Linux Création et autorisation d utilisateurs et de groupes Création d utilisateurs et de groupes dans Integrated Solutions Console Attribution des droits d accès aux groupes d utilisateurs dans la console Integrated Solutions Console Modification et suppression des utilisateurs et des groupes Connexion Etapes à suivre pour accéder à la console des opérations Comprendre les couches de la console des opérations Ce qu il faut savoir sur l arborescence des topologies Présentation de l arborescence des ressources Eléments affichés dans la colonne Etat Limitation de l étendue de l arborescence des ressources Présentation de la zone d information Page Général Page Règles Page Informations supplémentaires Page Relations Gestion des ressources à l aide de la console des opérations Gestion des requêtes Chapitre 10. Protection de vos ressources support réalisé par Quorum Généralités Quorum de configuration Quorum opérationnel Fonction VMTIMEBOMB Configuration des ressources critiques Pour obtenir des informations du quorum Configuration et gestion d une condition de départage Utilisation d une condition de départage Condition de départage du réseau Remplacement du quorum opérationnel vi IBM Tivoli System Automation Composant de base - Guide d utilisation

9 Chapitre 11. Configuration d un réseau hautement disponible 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? Que faut-il clarifier avant de planifier un réseau hautement disponible Installation d une grappe à un ou deux noeuds : détection des échecs de l interface réseau Grappe à deux noeuds, chaque noeud possède une interface Ethernet Grappe à deux noeuds, chaque noeud possède deux interfaces réseau Deux réseaux séparés physiquement, déplacement de ServiceIP entre les noeuds Trois réseaux logiques dans un réseau physique, déplacement de ServiceIP entre les interfaces réseau Deux réseaux séparés physiquement, routage dynamique et VIPA Interface de connexion Chapitre 12. Contrôle et administration d IBM Tivoli System Automation Configuration de l adaptateur d automatisation de bout en bout de System Automation for Multiplatforms Configuration de l adaptateur d automatisation de bout en bout Réplication des fichiers de configuration de l adaptateur d automatisation de bout en bout dans d autres noeuds du domaine Définition des règles d automatisation de bout en bout de l adaptateur Suppression des règles d automatisation de bout en bout de l adaptateur Remarque pour les administrateurs Contrôle d IBM Tivoli System Automation TimeOut et RetryCount Opérations d arrêt (Stop) Automatisation ExcludedNodes ResourceRestartTimeout Exemples Gestion des règles d automatisation Utilisation de la commande sampolicy pour gérer les règles Utilisation de la commande samcfg pour gérer des règles Utilisation des requêtes de démarrage et d arrêt des groupes de ressources et des ressources Portée d une requête d arrêt et de démarrage Source d une requête de démarrage ou d arrêt Priorité d une requête de démarrage et d arrêt Déplacement des groupes de ressources à l aide de la commande rgreq Portée d un mouvement Traitement d une requête de déplacement Déplacement et relations Etablissement de diagnostics de ressources IBM Tivoli System Automation Utilisation de l interface d événement TEC d IBM Tivoli System Automation Qu est-ce que Tivoli Enterprise Console? Qu est-ce que les événements? Envoi d événements vers la TEC Activation de la fonction de diffuseur de publications de la TEC Configuration d un nouveau paramètre de lieu pour les messages d événement de la TEC Publication d attributs internes d IBM Tivoli System Automation dans l infrastructure RSCT Activation d IBM Tivoli System Automation for GDPS/PPRC Multiplatform Resiliency for zseries 176 Personnalisation de Tivoli Enterprise Integration Facility (EIF) Installation de l interface Cpint Détection de présence xdr Démon de relevé des erreurs de l unité de stockage à accès direct (DASD) Arrêt d une grappe/d un noeud xdr à des fins de maintenance Vérification dynamique des ressources IBM Tivoli System Automation - Conseils et astuces Table des matières vii

10 Redémarrage d un noeud Arrêt d un noeud Génération d événements en cas d incidents Chapitre 13. Gestionnaires de ressources fournis par IBM Tivoli System Automation Utilisation du Global Resource Manager (gestionnaire de ressources globales) Qu est ce que la classe de ressources IBM.Application? Qu est ce qu une classe de ressources IBM.ServiceIP? Utilisation du Test Resource Manager Qu est ce que la classe de ressources IBM.Test? Attributs utilisés par IBM.Test Exemple : Création d une ressource de test et manipulation de son état opérationnel (OpState) 200 Annexe. Identification et résolution des incidents Fichiers de diagnostic du gestionnaire de ressources Restauration des incidents du RMC et du gestionnaire de ressources Utilisation de la commande ctsnap Commandes contrôlées par le contrôleur des ressources système Un domaine System Automation for Multiplatforms est absent de l arborescence Modification des paramètres de fuseau horaire pour la console des opérations Notices Marques Index viii IBM Tivoli System Automation Composant de base - Guide d utilisation

11 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. Copyright IBM Corp. 2003, 2005 ix

12 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 x IBM Tivoli System Automation Composant de base - Guide d utilisation

13 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, SC , et IBM Tivoli System Automation for Multiplatforms Base Component Reference, SC 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, SC 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, SC 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. Copyright IBM Corp. 2003, 2005 xi

14 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 : 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

15 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, SA v IBM Reliable Scalable Cluster Technology for Linux, Technical Reference, SA v IBM Reliable Scalable Cluster Technology for Linux, Messages, GA v A Practical Guide for Resource Monitoring and Control (RMC), SG Les documents RSCT sont également disponibles sur le site Web suivant : 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 : Comment obtenir des publications Les publications IBM Tivoli System Automation sont également disponibles (valides ou moment de la parution) sur les sites Web : Comment nous contacter par Si vous souhaitez nous contacter par , envoyez vos commentaires à l adresse eservdoc@de.ibm.com A propos de la bibliothèque IBM Tivoli System Automation for Multiplatforms xiii

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

17 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. Copyright IBM Corp. 2003,

18 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

19 Introduction 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 : Chapitre 1. Introduction 3

20 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

21 Introduction 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. Chapitre 1. Introduction 5

22 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

23 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. Copyright IBM Corp. 2003,

24 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. 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 AIX : Tableau 3. Archives pour les plateformes AIX 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 : 8 IBM Tivoli System Automation Composant de base - Guide d utilisation

25 Installation 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 zseries pseries iseries SUSE SLSS/SLES 8 (64 Bits) United Linux 1.0 SUSE SLES 9 (64 Bits) x x 3 x 2 x x x x RedHat RHEL 3.0 (32 Bits) x RedHat RHEL 4.0 (32 Bits) x RedHat RHEL 3.0 (64 Bits) x x 4 x x 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. 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. 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

26 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 bits 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 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 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 Aucune autre version de Perl n est disponible pour cette édition d AIX. Si vous décidez de mettre à jour votre version Perl sur une distribution Linux, effectuez les opérations suivantes : 1. Téléchargez la source de Perl 5.8.1, en allant sur 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

27 Installation v Pour en savoir plus sur les conditions propres à chaque système d exploitation, consultez la page Web en question en allant sur 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 Sélectionnez Localization dans une liste. Cliquez sur l icône 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. Chapitre 2. Installation du composant de base d IBM Tivoli System Automation 11

28 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 <tar file> 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

29 Installation 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 EUC/GBK Euro GB18030/BIG5 Allemand de_de.utf-8 de_de, de_de.iso Espagnol es_es.utf-8 es_es, es_es.iso Français fr_fr.utf-8 fr_fr, fr_fr.iso Italien it_it.utf-8 it_it, it_it.iso de_de@euro es_es@euro fr_fr@euro it_it@euro 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 zh_cn.gb18030 Chinois traditionnel zh_tw.utf-8 zh_tw.big5, zh_tw Le codage suivant est pris en charge par la distribution AIX : Langue UTF-8 ISO 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. Chapitre 2. Installation du composant de base d IBM Tivoli System Automation 13

30 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 <resource-group-name> 4. Si le domaine est en ligne, arrêtez le domaine : stoprpdomain <domain-name> 5. Exécutez./installSAM depuis le répertoire d installation sur tous les noeuds. 6. Démarrez le domaine : startrpdomain <domain-name> 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 <node> 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 <node>; lsrpnode 3. Exécutez./installSAM à partir du répertoire d installation pour mettre le noeud à jour. 4. Démarrez le noeud : startrpnode <node> 5. Prenez le nouveau noeud qui vient d être mis à jour pour l intégrer au système d automatisation : samctrl -u d <node> 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

31 Installation 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( dans l exemple ci-dessous) et le numéro de version d installation IVN ( 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 : Nom de la grappe : ws Numéro du noeud : 1 Heure du début : Wed Apr 21 08:09: Etat du démon: Nom du noeud : lnxcm3x Nom du noeud maître : lnxcm3x (node number = 1) Notre IVN : Notre AVN : Notre CVN : {0x } 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 Oui 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 noeud02 En ligne noeud03 En ligne 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 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

32 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 Non 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 <domain> 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

33 Installation Service d installation Le service d installation renvoie à la mise à jour de l édition d IBM Tivoli System Automation. En conséquence, vous devez avoir installé préalablement l édition 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 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 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

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

35 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 Copyright IBM Corp. 2003,

36 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, SA v IBM Reliable Scalable Cluster Technology for Linux, Technical Reference, SA v IBM Reliable Scalable Cluster Technology for AIX 5L: Administration Guide., SA v IBM Reliable Scalable Cluster Technology for AIX 5L: Technical Reference., SA Vous trouverez ces documents sur ce site Web d IBM à l adresse : 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 No 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

37 Mise en route 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 No 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 No Remarques : 1. Le message d erreur suivant peut apparaître : 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 : 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 : 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 : 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 No d émettre la commande lsrpnode afin de voir les noeuds qui sont en ligne : Name OpState RSCT Version node02 Online node01 Online 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 Chapitre 3. Mise en route 21

38 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 node03 Offline node01 Online 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 No 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 IBM Tivoli System Automation Composant de base - Guide d utilisation

39 Mise en route 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 node03 Offline node01 Online 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 node01 Online 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 active Chapitre 3. Mise en route 23

40 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

41 Mise en route 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 Chapitre 3. Mise en route 25

42 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 v Masque de réseau 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= \ IPAddress= 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

43 Mise en route 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 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

44 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

45 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 addrgmbr Description Ajouter une ou plusieurs ressources à un groupe de ressources. Pour des informations supplémentaires, chrgmbr consultez les Modifier la valeur de l attribut persistant d une ressource gérée dans un descriptions de groupe de ressources commandes dans le lsrg manuel IBM Tivoli Répertorier un groupe de ressources déjà défini ou ses ressources System Automation membres 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. Copyright IBM Corp. 2003,

46 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 IBM Tivoli System Automation Composant de base - Guide d utilisation

47 Attributs utilisés par les ressources Attributs utilisés par les ressources Les ressources peuvent posséder les attributs suivants : NodeNameList Indique les noeuds dans lesquels la ressource est autorisée à fonctionner. 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 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

48 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. Attribut 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. 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

49 Attributs utilisés par les ressources En attente en ligne La ressource a été démarrée, mais elle n est pas prête à fonctionner. En ligne La ressource est prête à fonctionner. En attente hors ligne La ressource est en cours d arrêt. Certains états opérationnels font état d un problème : Echec hors ligne La ressource est cassée et ne peut être utilisée. Vous devez réinitialiser la ressource lorsque elle est réparée. Arrêt en ligne La ressource a été démarrée, mais n est pas devenue disponible dans l intervalle de temps escompté et ne peut être mise hors ligne. Une autre possibilité est que la ressource était en ligne et qu une requête de mise hors ligne n est pas parvenue à la mettre hors ligne. Inconnu 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

50 34 IBM Tivoli System Automation Composant de base - Guide d utilisation

51 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 Il s agit des commandes IBM Tivoli System Automation que vous utilisez conjointement aux groupes de 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 descriptions de démarrage et l arrêt d un groupe de ressources) commandes dans le manuel IBM lsrg Répertorier un ou plusieurs groupes de ressources Tivoli System addrgmbr Ajouter des ressources membres dans un groupe de ressources Automation for Multiplatforms rmrgmbr Supprimer des ressources membres d un groupe de ressources 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. Copyright IBM Corp. 2003,

52 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

53 Groupes de ressources 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é à 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 : 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

54 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

55 Groupes de ressources Le résultat de ce scénario est le suivant : 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

56 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 Attribut 1 Hors ligne 0 En ligne 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

57 Groupes de ressources 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. 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

58 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

59 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

60 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

61 Groupes de ressources 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 description de la commande dans le manuel IBM Tivoli System Automation for Multiplatforms Base 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 : Chapitre 5. Utilisation des groupes de ressources 45

62 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 de la commande dans le manuel IBM Tivoli System Automation for Multiplatforms Base Component 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

63 Groupes de ressources Pour des informations supplémentaires, consultez la page d aide de la commande chrg ou une description de la commande dans le manuel IBM Tivoli System Automation for Multiplatforms Base Component 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 description de la commande dans le manuel IBM Tivoli System Automation for Multiplatforms Base 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 description de la commande dans le manuel IBM Tivoli System Automation for Multiplatforms Base 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 Pour des informations supplémentaires, consultez la page d aide de la commande rmrg ou une description de la commande dans le manuel IBM Tivoli System Automation for Multiplatforms Base Component Reference. Chapitre 5. Utilisation des groupes de ressources 47

64 48 IBM Tivoli System Automation Composant de base - Guide d utilisation

65 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 Il s agit des commandes IBM Tivoli System Automation que vous utilisez conjointement aux équivalences : Tableau 7. Commandes IBM Tivoli System Automation utilisées conjointement aux équivalences Commande mkequ Description Créer une ressource d équivalence Pour des informations 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 lsequ Répertorier les ressources d équivalence Automation for Multiplatforms 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. Copyright IBM Corp. 2003,

66 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

67 Equivalences 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. Pour des informations supplémentaires, consultez la page d aide de la commande chequ ou une description de la commande dans le manuel IBM Tivoli System Automation for Multiplatforms Base Component Reference. Chapitre 6. Utilisation des équivalences 51

68 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 description de la commande dans le manuel IBM Tivoli System Automation for Multiplatforms Base 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

69 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 Il s agit des commandes IBM Tivoli System Automation que vous utilisez pour les relations gérées : 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 rmrel Supprimer une relation gérée manuel IBM Tivoli System Automation chrel Modifier une relation gérée for Multiplatforms 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 Copyright IBM Corp. 2003,

70 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

71 Relations gérées 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 v v v v IfOnline IfNotOnline IfOffline IfNotOffline 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 v v v v StartAfter StopAfter DependsOn DependsOnAny 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. 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

72 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

73 Relations gérées 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. 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

74 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

75 Relations gérées La relation StopAfter présente le modèle de comportement suivant : v La ressource A n est pas arrêtée tant que la ressource cible B n est pas hors ligne (y compris Echec hors ligne). La relation StopAfter ne propose pas de comportement de démarrage ou d arrêt forcé. (voir sections «Relation StartAfter», à la page 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

76 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 IBM Tivoli System Automation Composant de base - Guide d utilisation

77 Relations gérées 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 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

78 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

79 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

80 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

81 Relations gérées 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 : 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

82 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 v v v v Collocated AntiCollocated Affinity AntiAffinity 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

83 Relations gérées 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. 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

84 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

85 Relations gérées 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 v v 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. 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. 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. Collocated/IfNotOffline La relation A ---> Collocated/IfNotOffline -----> B signifie que la relation d emplacement est uniquement valide lorsque la ressource B ne possède pas l état Hors ligne, Echec hors ligne ou Inconnu. 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

86 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

87 Relations gérées 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 v v 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. 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. 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. 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 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. Affinity/IfOffline La relation A ---> Affinity/IfOffline -----> B signifie que la relation d emplacement est uniquement valide lorsque la ressource B possède un état Hors ligne, Echec hors ligne ou Inconnu. Chapitre 7. Utilisation des relations gérées 71

88 Relations gérées v 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. 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 v v 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. 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. 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. 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

89 Relations gérées 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 : 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

90 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

91 Relations gérées 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 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

92 76 IBM Tivoli System Automation Composant de base - Guide d utilisation

93 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) Copyright IBM Corp. 2003,

94 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

95 Logique d IBM Tivoli System Automation 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 : 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

96 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

97 Logique d IBM Tivoli System Automation 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 & 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

98 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

99 Logique d IBM Tivoli System Automation 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. Chapitre 8. Traitement des informations système par IBM Tivoli System Automation 83

100 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 Deuxième action d automatisation de système 84 IBM Tivoli System Automation Composant de base - Guide d utilisation

101 Logique d IBM Tivoli System Automation 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 RC<>0 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 lancées par IBM Tivoli System Automation en fonction de la valeur retour de la commande de contrôle de 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 RC<>0 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 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

102 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

103 Logique d IBM Tivoli System Automation 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 RC<>0 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) Action d automatisation de système RC=0 (Inconnu) Aucune, attendre que la commande de contrôle renvoie RC<>0 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

104 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 Action d automatisation de système Lorsque la commande de contrôle rapporte l état Inconnu, IBM Tivoli System Automation attend le renvoi de RC<>0 par la commande de contrôle, notamment lorsque la commande de démarrage RC (ou le délai d attente) est ignoré. 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 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 88 IBM Tivoli System Automation Composant de base - Guide d utilisation

105 Logique d IBM Tivoli System Automation 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. Action d automatisation de système RC=0 (Inconnu) Aucune, attendre la prochaine commande de contrôle avec RC<>0 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

106 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 RC<>0 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 RC<>0 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

107 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 RC<>0. 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

108 92 IBM Tivoli System Automation Composant de base - Guide d utilisation

109 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. Copyright IBM Corp. 2003,

110 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

111 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 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 : 75 Mo Espace disque temporaire requis pour l installation C:\Documents and Settings\Administrateur\ Local Settings\Temp Valeur de la variable système %TEMP%. Il s agit généralement de : 100 Mo C:\Documents and Settings\Administrateur\ Local Settings\Temp 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 Lorsque vous commandez le composant de base d IBM Tivoli System Automation, la console des 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

112 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. 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 AIX : Tableau 23. Archives pour les plateformes AIX Nom de l archive Description 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

113 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. 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 PPC Linux : Tableau 25. Archives pour PPC Linux Nom de l archive Description C84Q6ML.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 : EEZ2100E2EPPC/ppc/setup Linux sur z/series : Tableau 26. Archives pour Linux sur z/series Nom de l archive Description 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<nom_système_exploitation> 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

114 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

115 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

116 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

117 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

118 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

119 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 <ISC>. Sous Windows : <Disque :><ISC>\AppServer\profiles\default\Tivoli\EEZ Sous Linux ou AIX : /opt/<isc>/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

120 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

121 Pour démarrer le serveur de la console Integrated Solutions Console, exécutez cette commande : <isc_home>\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 : <isc_home>\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 : <isc_home>\appserver\bin\stopserver ISC_Portal -username <user_id> -password <password> où <user_id> et <password> 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 : <isc_home>\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 : <isc_home>\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 : <isc_home>\portalserver\bin\stopisc.bat ISC_Portal <user_id> <password> où <user_id> et <password> 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 : <isc_home>/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 : <isc_home>/portalserver/bin/stopisc.sh ISC_Portal <user_id> <password> où <user_id> and <password> 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

122 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 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 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 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

123 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

124 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

125 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 pour Tivoli System Automation for Multiplatforms Operations Console. 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

126 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

127 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 : Dans cette entrée, vous devez remplacer <hostname> par le nom de l hôte sur lequel la console Integrated Solutions Console est exécutée et <port> 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

128 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

129 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

130 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

131 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

132 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

133 ressources : Lorsque vous sélectionnez......les pages suivantes sont disponibles un domaine d automatisation dans la topologie v Général v Règle v Informations complémentaires une ressource ou un groupe de ressources dans l arborescence des ressources 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. Page 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. 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

134 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

135 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 (jaune) (jaune) (vert) (vert) Description 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

136 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

137 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

138 122 IBM Tivoli System Automation Composant de base - Guide d utilisation

139 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 Copyright IBM Corp. 2003,

140 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, SA , and IBM Reliable Scalable Cluster Technology for Linux, Technical Reference, SA 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 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 Valeur 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

141 Support réalisé par Quorum 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 : 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

142 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 (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

143 Support réalisé par Quorum 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 : Nombre total de noeuds: 2 Nombre de membre associé : 2 Nombre de quorum de configuration : 2 Nombre de quorum au démarrage : 1 Etat du quorum opérationnel : HAS_QUORUM Dans Quorum de configuration : TRUE Dans Etat de configuration: TRUE La signification des différents attributs est la suivante : Nombre total de noeuds correspond au nombre de noeuds définis dans la grappe. Nombre de membre associé est le nombre de démons IBM.RecoveryRM fonctionnant dans la grappe. Il équivaut au nombre de noeuds actifs dans la (sous)grappe. Chapitre 10. Protection de vos ressources support réalisé par Quorum 127

144 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

145 Support réalisé par Quorum 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= " 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 : Chapitre 10. Protection de vos ressources support réalisé par Quorum 129

146 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 DE 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, blocks, 2347 MB 50dd(ECKD) at ( 94: 4) is : active at blocksize: 4096, blocks, 2347 MB 50de(ECKD) at ( 94: 8) is : active at blocksize: 4096, blocks, 2347 MB 50df(ECKD) at ( 94: 12) is : active at blocksize: 4096, blocks, 2347 MB 130 IBM Tivoli System Automation Composant de base - Guide d utilisation

147 Support réalisé par Quorum 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 DE 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, blocks, 2347 MB 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

148 Support réalisé par Quorum node01:~ # cat /proc/subchannels Device sch. Dev Type/Model CU in use PIM PAM POM CHPIDs DE 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

149 Support réalisé par Quorum "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 : hdisk e5766b8 rootvg active hdisk ed54 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 ,0 16 Bit SCSI Disk Drive Pour servir de disque à départager, le disque doit être partagé par tous les noeuds dans le domaine homologue. Vérifiez l ID du volume physique issu de la commande lspv pour déterminer si le disque est partagé par plusieurs noeuds (dans la sortie précédente pour la commande lspv, l ID du volume physique est répertorié dans la seconde colonne ; l ID du volume pour hdisk1 est ed54.) 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

150 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 ,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

151 Support réalisé par Quorum 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. + 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. - 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. Configuration d une condition de départage s appliquant au réseau La condition de départage du réseau est réalisée en tant que condition de départage exec du RSCT. Voir la documentation sur RSCT si vous souhaitez en savoir plus concernant la commande exec de la condition de départage - La commande exécutable de la condition de départage samtb_net se trouve dans le répertoire /usr/sbin/rsct/bin. Lors de l implémentation, les options suivantes devront être spécifiées en tant que mots clés au cours de la création de la condition de départage d une commande exec RSCT. Address=<IP address> Adresse de l instance IP externe qui devrait être utilisée pour résoudre une situation de parité. Indiquez une adresse IPv4 en format point, par exemple N utilisez pas de nom DNS car en cas de problèmes de communication, survenant généralement lors du fractionnement de la grappe, DNS ne pourra fonctionner correctement. L adresse doit impérativement figurée, aucune option par défaut n est disponible. Log=<1/0> Indiquez 1 si vous souhaitez que la condition de départage du réseau rédige des journaux systèmes dans la fonction journal système (syslog). La valeur par défaut est 1. Les valeurs autorisées sont 1 et 0. Count=<number> Nombre de demandes d écho dans ICMP envoyées pour déterminer le quorum. Si la première requête obtient une réponse, aucune autre requête n est envoyée. La valeur par défaut est 2. La gamme de valeurs autorisée 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= Log=1 PostReserveWaitTime=30; Activez votre condition de départage du réseau comme suit : # chrsrc -c IBM.PeerNode OpQuorumTieBreaker="mynetworktb" Chapitre 10. Protection de vos ressources support réalisé par Quorum 135

152 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 Il comprend l horodatage de l échec de l opération de réservation. # cat /var/ct/samtb_net_blockreserve_ 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 IBM Tivoli System Automation Composant de base - Guide d utilisation

153 Support réalisé par Quorum 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 ( ). 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 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

154 138 IBM Tivoli System Automation Composant de base - Guide d utilisation

155 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. Copyright IBM Corp. 2003,

156 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 # il s agit de la passerelle de noeud pour toutes les interfaces au sein du réseau gw.de.ibm.com 140 IBM Tivoli System Automation Composant de base - Guide d utilisation

157 configuration du réseau 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 eth /24 Noeud de grappe lnxcm2 eth /24 Routeur gw eth /24 ServiceIP /24 Figure 12. Une interface à deux noeuds 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 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

158 configuration du réseau Figure 13. Une interface réseau à deux noeuds échec de l interface Dans cet exemple, le réseau 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=" " NetMask=" " 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

159 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 configuration du réseau / / / /24 Routeur gw eth /24 ServiceIP /24 Figure 14. Deux interfaces à deux noeuds, deux réseaux séparés physiquement Il existe maintenant deux réseaux et 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 représente le réseau correspondant au service informatique hautement disponible. v Le réseau rend la communication interne entre les grappes plus fiable. 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

160 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 eth / / / /24 Routeur gw eth /24 ServiceIP /24 Figure 15. Un réseau physique à deux noeuds et deux interfaces v Le réseau représente le réseau pour le service informatique hautement disponible. v Le réseau 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

161 configuration du réseau v Le réseau 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=" " NetMask=" " 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 eth / / / / / /24 ServiceIP /24 Chapitre 11. Configuration d un réseau hautement disponible 145

162 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 eth / / / /24 Routeur gw eth /24 ServiceIP / IBM Tivoli System Automation Composant de base - Guide d utilisation

163 configuration du réseau 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. 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

164 configuration du réseau 148 IBM Tivoli System Automation Composant de base - Guide d utilisation

165 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. Copyright IBM Corp. 2003,

166 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

167 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

168 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 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 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 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

169 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 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 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

170 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

171 Contrôle et administration d IBM Tivoli System Automation Onglet Hôte utilisant l adaptateur Figure 21. Hôte utilisant l adaptateur 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 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 Chapitre 12. Contrôle et administration d IBM Tivoli System Automation 155

172 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

173 Contrôle et administration d IBM Tivoli System Automation 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 v v v v 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. 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. 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. 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. Modifier 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

174 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

175 Contrôle et administration d IBM Tivoli System Automation 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 : 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