Environnements cluster à haute disponibilité · Table des matières Figures .....v Avis aux lecteurs canadiens .....vii A propos de cette édition .....ix Nouveautés de cette version

Workload SchedulerVersion 8.6

Environnements cluster à hautedisponibilité

SC11-2858-04

��

Workload SchedulerVersion 8.6

Environnements cluster à hautedisponibilité

SC11-2858-04

��

ImportantAvant d'utiliser le présent document et le produit associé, prenez connaissance des informations générales figurant à lasection Remarques.

RemarqueCertaines illustrations de ce manuel ne sont pas disponibles en français à la date d'édition.

Cinquième édition - septembre 2011

Réf. US : SC23-6119-04

LE PRESENT DOCUMENT EST LIVRE EN L'ETAT SANS AUCUNE GARANTIE EXPLICITE OU IMPLICITE. IBMDECLINE NOTAMMENT TOUTE RESPONSABILITE RELATIVE A CES INFORMATIONS EN CAS DECONTREFACON 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 ysont fournies sont susceptibles d'être modifiées avant que les produits décrits ne deviennent eux-mêmesdisponibles. En outre, il peut contenir des informations ou des références concernant certains produits, logiciels ouservices 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 partenairecommercial.

Vous pouvez également consulter les serveurs Internet suivants :v http://www.fr.ibm.com (serveur IBM en France)

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

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

Compagnie IBM FranceDirection Qualité17, avenue de l'Europe92275 Bois-Colombes Cedex

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

© Copyright IBM Corporation 1999, 2011.

http://www.fr.ibm.com

http://www.can.ibm.com

http://www.ibm.com

Table des matières

Figures . . . . . . . . . . . . . . . v

Avis aux lecteurs canadiens . . . . . vii

A propos de cette édition . . . . . . . ixNouveautés de cette version . . . . . . . . . ixNouveautés de cette édition concernant la prise encharge des clusters . . . . . . . . . . . . ixNouveautés de cette publication . . . . . . . ixA qui s'adresse cette publication . . . . . . . ixPublications . . . . . . . . . . . . . . xAccessibilité . . . . . . . . . . . . . . xFormation technique Tivoli . . . . . . . . . xInformations sur le support technique . . . . . . x

Chapitre 1. Types de haute disponibilité 1Disponibilité de l'agent par rapport à la disponibilitédu travail . . . . . . . . . . . . . . . 1Scénario HACMP pour AIX - Gestionnaire dedomaine de secours . . . . . . . . . . . . 1

Chapitre 2. Tivoli Workload Scheduleravec cluster Windows. . . . . . . . . 3Présentation des clusters Windows . . . . . . . 3

Tivoli Workload Scheduler avec desenvironnements cluster Microsoft Windows . . . 3Connaissances requises . . . . . . . . . . 3Limites de conception . . . . . . . . . . 3Systèmes d'exploitation pris en charge . . . . . 4Compatibilité, mise à niveau et coexistence . . . 4Sécurité et authentification. . . . . . . . . 5

Tivoli Workload Scheduler Windows Cluster Enabler 5Composants . . . . . . . . . . . . . 5Installation et configuration . . . . . . . . 7Application d'un groupe de correctifs ou mise àniveau de Cluster Enabler vers une nouvelleversion . . . . . . . . . . . . . . . 12Commande twsClusterAdm avec exemplesd'utilisation . . . . . . . . . . . . . 13Exploitation de Tivoli Workload Scheduler dansun environnement cluster Windows . . . . . 24Extension Tivoli Workload Scheduler ClusterAdministrator . . . . . . . . . . . . 28Désinstallation de Tivoli Workload Scheduler . . 29

Identification et résolution des problèmes . . . . 29Traces . . . . . . . . . . . . . . . 30Erreur 1314 de mise en ligne de la ressource et leposte de travail n'effectue pas de liaison . . . . 30

L'instance de ressource Tivoli WorkloadScheduler signale un statut d'échec ou lestravaux utilisateur Tivoli Workload Schedulerpassent à l'état abend . . . . . . . . . . 31Panneau de rapport Windows avec Jobmon.exe 31Cluster : erreur de validation IP sur Netmanstdlist . . . . . . . . . . . . . . . 32

Chapitre 3. IBM Tivoli WorkloadScheduler avec HACMP . . . . . . . 33Outil HACMP (High-Availability ClusterMulti-Processing) . . . . . . . . . . . . 33

Avantages . . . . . . . . . . . . . . 33Composants physiques d'un cluster HACMP . . 34

Présentation des clusters UNIX . . . . . . . . 37Connaissances requises . . . . . . . . . 37Configurations de secours et de reprise . . . . 37Limites de conception . . . . . . . . . . 40Configurations prises en charge . . . . . . 40

Annexe. Résolution des problèmes detaille de segment de mémoire dubureau électronique sur les postes detravail ayant plus de trois agents . . . 45Description du problème . . . . . . . . . . 45Solutions . . . . . . . . . . . . . . . 46

Modifier les tailles de la mémoire tampon dusegment de mémoire partagé . . . . . . . 46Configurer le service Tivoli Workload SchedulerWindows pour qu'il démarre comme un comptesystème local.. . . . . . . . . . . . . 47Personnaliser le nom du bureau électroniquepour pouvoir le réutiliser . . . . . . . . . 47

Implémentation des solutions . . . . . . . . 48Modifier la configuration du service Windows. . 48Modifier les entrées du registre Windows quidéterminent la taille de segment de mémoire. . . 48Modifier localopts pour fournir un nom debureau électronique partagé . . . . . . . . 49

Remarques . . . . . . . . . . . . . 51Marques . . . . . . . . . . . . . . . 52

Index . . . . . . . . . . . . . . . 55

© Copyright IBM Corp. 1999, 2011 iii

|

iv IBM Tivoli Workload Scheduler - Environnements cluster à haute disponibilité

Figures

1. Composants principaux de Tivoli WorkloadScheduler Cluster Enabler . . . . . . . . 6

2. Installation dans un cluster. . . . . . . . 83. Clusters dans un réseau Tivoli Workload

Scheduler . . . . . . . . . . . . . 84. Exemple de groupe de clusters sous Windows

Server 2003 . . . . . . . . . . . . 125. Onglet Dépendances de ressource (Windows

Server 2003) . . . . . . . . . . . . 256. Exemple de groupe de clusters sous Windows

Server 2003 . . . . . . . . . . . . 27

7. Localopts – Bloc-notes . . . . . . . . . 278. Nouvel onglet Paramètres de propriétés 289. Disque partagé avec fonction miroir . . . . 35

10. Configuration active-passive enfonctionnement normal . . . . . . . . 38

11. Reprise sur une configuration active-passive 3812. Volumes de système de fichiers logique 3913. Scénario de reprise . . . . . . . . . . 39

© Copyright IBM Corp. 1999, 2011 v

|||||

vi IBM Tivoli Workload Scheduler - Environnements cluster à haute disponibilité

Avis aux lecteurs canadiens

Le présent document a été traduit en France. Voici les principales différences etparticularités dont vous devez tenir compte.

Illustrations

Les illustrations sont fournies à titre d'exemple. Certaines peuvent contenir desdonnées propres à la France.

Terminologie

La terminologie des titres IBM peut différer d'un pays à l'autre. Reportez-vous autableau 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, etle 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éesdifféremment selon qu'il s'agit du clavier de la France, du clavier du Canada ou duclavier des États-Unis. Reportez-vous à ce tableau pour faire correspondre lestouches françaises figurant dans le présent document aux touches de votre clavier.

© Copyright IBM Corp. 1999, 2011 vii

Brevets

Il est possible qu'IBM détienne des brevets ou qu'elle ait déposé des demandes debrevets portant sur certains sujets abordés dans ce document. Le fait qu'IBM vousfournisse le présent document ne signifie pas qu'elle vous accorde un permisd'utilisation de ces brevets. Vous pouvez envoyer, par écrit, vos demandes derenseignements relatives aux permis d'utilisation au directeur général des relationscommerciales 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, deslogiciels et des publications IBM, contactez IBM direct au 1 800 465-1234.

viii IBM Tivoli Workload Scheduler - Environnements cluster à haute disponibilité

A propos de cette édition

La présente publication décrit la manière dont les clusters Windows et HACMPpour AIX s'adaptent à la topologie d'IBM® Tivoli Workload Scheduler. Elle décritégalement les améliorations apportées à Tivoli Workload Scheduler pour prendreen charge l'environnement de mise en cluster à haute disponibilité basé surMicrosoft Windows.

Nouveautés de cette version

Pour obtenir des informations sur les fonctions nouvelles ou modifiées de laprésente édition, voir Tivoli Workload Automation - Présentation.

Pour plus d'informations sur les APAR résolus par la présente édition, voir TivoliWorkload Scheduler Document de téléchargement à l'adresse http://www.ibm.com/support/docview.wss?rs=672&uid=swg24027501.

Nouveautés de cette édition concernant la prise en charge desclusters

Les améliorations suivantes ont été apportées à la prise en charge de TivoliWorkload Scheduler pour l'environnement de mise en clusters et de hautedisponibilité en fonction de Microsoft Windows Server 2003 et Windows Server2008 :v Prise en charge de Windows Server 2008.v Deux nouvelles options génériques permettant d'activer la surveillance de l'agent

de planification dynamique et de Job Manager.v Appel d'un nouveau script pour arrêter et démarrer Tivoli Workload Scheduler.

Nouveautés de cette publication

Les informations suivantes ont été ajoutées ou modifiées dans la présentepublication :v Prise en charge supplémentaire pour HACMP pour AIX dans tout le manuel.v La section concernant la disponibilité de Server et de l'agent a été supprimée.

A qui s'adresse cette publication

Cette publication est destinée au public suivant :v Utilisateurs de Tivoli Workload Scheduler dans un environnement cluster

Windows 2003 et 2008.v Utilisateurs de Tivoli Workload Scheduler dans un environnement cluster UNIX

et Linux.v Administrateurs informatiques ou administrateurs informatiques de Tivoli

Workload Scheduler, qui planifient l'agencement du réseau Tivoli WorkloadScheduler.

© Copyright IBM Corp. 1999, 2011 ix

|||||

||

|

|

http://www.ibm.com/support/docview.wss?rs=672&uid=swg24027501

http://www.ibm.com/support/docview.wss?rs=672&uid=swg24027501

v Responsables de l'installation, qui installent les différents progiciels sur lesordinateurs qui composent le réseau Tivoli Workload Scheduler.

Publications

De plus amples informations sur les publications Tivoli Workload Automation sontdisponibles dans Tivoli Workload Automation - Publications. Ce document contientégalement des informations sur les conventions utilisées dans les publications.

Un glossaire des termes utilisés dans le produit est disponible dans Tivoli WorkloadAutomation - Glossaire.

Ces informations sont présentes dans le centre de documentation dans deuxpublications distinctes.

Accessibilité

Les fonctions d'accessibilité aident les handicapés physiques à utiliser correctementles logiciels. Elles visent notamment les utilisateurs limités par leur mobilité ouleur vue. Avec ce produit, vous pouvez utiliser les technologies d'assistance pourparcourir l'interface à l'aide de messages sonores. Vous pouvez également utiliserle clavier au lieu de la souris pour toutes les fonctions de l'interface graphique.

Pour plus d'informations concernant Job Scheduling Console, consultez l'annexesur l'accessibilité du manuel Tivoli Workload Scheduler: Job Scheduling Console User'sGuide.

Pour des informations complètes concernant Dynamic Workload Console, consultezl'annexe sur l'accessibilité du manuel Tivoli Workload Scheduler : Guide d'utilisation etde référence.

Formation technique Tivoli

Pour plus d'informations sur la formation technique Tivoli, reportez-vous au siteWeb IBM Tivoli Education suivant :

http://www.ibm.com/software/tivoli/education

Informations sur le support technique

Si vous rencontrez un problème avec un logiciel IBM, vous pouvez le résoudrerapidement. IBM vous permet d'obtenir l'assistance dont vous avez besoin deplusieurs manières :v En faisant des recherches dans les bases de connaissances : elles contiennent un

grand nombre de problèmes recensés et de solutions, de remarques d'ordretechnique et autres informations adéquates.

v En vous procurant des correctifs : vous trouverez les versions les plus récentesdisponibles pour votre produit.

v En contactant le service de support logiciel IBM : si vous ne pouvez toujourspas résoudre le problème et devez collaborer avec une personne d'IBM, vouspouvez contacter de diverses manières le service de support logiciel IBM.

x IBM Tivoli Workload Scheduler - Environnements cluster à haute disponibilité

http://www.ibm.com/software/tivoli/education

Pour plus d'informations sur ces trois manières de résoudre un problème,consultez l'annexe sur les informations de support dans le manuel Tivoli WorkloadScheduler - Guide d'identification et de résolution des problèmes.

A propos de cette édition xi

xii IBM Tivoli Workload Scheduler - Environnements cluster à haute disponibilité

Chapitre 1. Types de haute disponibilité

Les clusters de serveurs sont conçus pour conserver des ressources (comme lesapplications, les disques et les partages de fichiers) disponibles. La disponibilitémesure l'aptitude des clients à se connecter à une ressource et à l'utiliser. Si uneressource n'est pas disponible, les clients ne peuvent pas l'utiliser.

Il est possible de mettre en contraste la haute disponibilité avec la tolérance auxpannes, ainsi que différents tests de performances permettant de mesurer ladisponibilité :

Tolérance aux pannesLa tolérance aux pannes correspond à une disponibilité permanente à100 %. Les systèmes tolérants aux pannes sont conçus pour garantir ladisponibilité des ressources.

Haute disponibilitéUn système à haute disponibilité maximise la disponibilité des ressources.Une ressource à haute disponibilité se caractérise par un pourcentage élevéde disponibilité susceptible d'approcher une disponibilité maximale de100 %, mais avec un pourcentage de temps d'arrêt acceptable et prévu.

En ce sens, la haute disponibilité peut être définie comme une ressource hautementdisponible, presque toujours opérationnelle et accessible aux clients.

Cette section décrit le type de haute disponibilité suivant : «Scénario HACMPpour AIX - Gestionnaire de domaine de secours»

Disponibilité de l'agent par rapport à la disponibilité du travailLe fait d'avoir Tivoli Workload Scheduler fonctionnant dans des environnementscluster Windows et HACMP pour AIX ne signifie pas que les travaux lancés par leplanificateur soient automatiquement sensibles au cluster. Il n'est pas de laresponsabilité de Tivoli Workload Scheduler d'annuler des actions qu'un travailaurait effectué lors de son fonctionnement. Il est de la responsabilité de l'utilisateurde créer le script ou la commande permettant une action de reprise oud'annulation en cas de reprise en ligne.

Pour une reprise en ligne, l'agent Tivoli Workload Scheduler signale tout travail encours d'exécution à ce moment avec l'état ABEND et le code retour RC=0. Celaempêche la libération de dépendances supplémentaires. Seule une reprise (ouréexécution) des travaux défectueux est possible.

De manière générale, Tivoli Workload Scheduler ne gère pas l'interruption destravaux ou flots de travaux. Une logique supplémentaire doit être ajoutée parl'utilisateur pour effectuer une reprise après des interruptions de travaux ou flotsde travaux (voir les sections 1.4.2 et 2.3.4 du Redbook High Availability Scenarioswith IBM Tivoli Workload Scheduler and IBM Tivoli Framework).

Scénario HACMP pour AIX - Gestionnaire de domaine de secoursTivoli Workload Scheduler fournit un haut degré de disponibilité via sa fonction degestionnaire de domaine de secours, qui peut également être implémentée en tantque gestionnaire de domaine maître de sauvegarde.

© Copyright IBM Corp. 1999, 2011 1

||

|

Le gestionnaire de domaine de secours duplique les changements apportés au plande production du gestionnaire de domaine. Lorsqu'un incident est détecté, lacommande switchmgr est émise sur tous les postes de travail dans le domaine duserveur de gestionnaire de domaine, de telle sorte que les postes de travailreconnaissent le gestionnaire de domaine de secours.

Un environnement cluster peut toutefois constituer une bonne alternative danscertains cas :v Difficulté à implémenter le basculement de la responsabilité du domaine

automatiquev Difficulté à faire basculer les travaux qui doivent être exécutés sur le

gestionnaire de domaine vers le gestionnaire de domaine de secoursv Nécessité de notifier le basculement d'un gestionnaire de domaine vers le réseau

Tivoli Workload Schedulerv Le produit à haute disponibilité corrige la plupart des problèmes de codage

relatifs à la détection des incidents matérielv L'implémentation de la haute disponibilité pour les agents tolérants aux pannes

(agents étendus et agents standard) ne peut pas être effectuée à l'aide de lafonction de gestionnaire de domaine de secours

2 IBM Tivoli Workload Scheduler - Environnements cluster à haute disponibilité

Chapitre 2. Tivoli Workload Scheduler avec cluster Windows

Cette section contient des informations sur les rubriques suivantes :v «Présentation des clusters Windows»v «Tivoli Workload Scheduler Windows Cluster Enabler», à la page 5v «Identification et résolution des problèmes», à la page 29

Présentation des clusters WindowsCette section décrit la manière dont les clusters Windows s'adaptent à la topologiede Tivoli Workload Scheduler. Elle comprend les sous-sections suivantes :v «Tivoli Workload Scheduler avec des environnements cluster Microsoft

Windows»v «Connaissances requises»v «Limites de conception»v «Systèmes d'exploitation pris en charge», à la page 4v «Compatibilité, mise à niveau et coexistence», à la page 4v «Sécurité et authentification», à la page 5

Tivoli Workload Scheduler avec des environnements clusterMicrosoft Windows

Tivoli Workload Scheduler peut être intégré aux environnements cluster Windowsà l'aide des ressources de cluster génériques Microsoft. Le présent documentindique comment procéder.

Pour vous aider à exécuter cette intégration, le produit fournit :v Un utilitaire qui configure à distance Tivoli Workload Scheduler sur tous les

noeuds du cluster sans réinstaller Tivoli Workload Scheduler sur chaque noeud.L'utilitaire implémente la logique pour définir et installer la ressourcepersonnalisée Tivoli Workload Scheduler au sein du groupe de clusters.

v Une nouvelle DLL de ressources personnalisée spécifique à Tivoli WorkloadScheduler.

Connaissances requisesPour comprendre les points abordés dans le présent document, vous devezconnaître les clusters Tivoli Workload Scheduler et Microsoft Windows 2003 :

Tivoli Workload SchedulerPour une présentation de Tivoli Workload Scheduler, reportez-vous aumanuel Tivoli Workload Scheduler - Guide de planification et d'installation

Clusters Microsoft WindowsPour obtenir un guide de démarrage rapide des clusters de serveurs et desinformations à propos de Windows Clustering Services, allez sur le siteWeb de Microsoft Windows Server TechNet.

Limites de conceptionLes limites de conception suivantes s'appliquent :v «Le gestionnaire de domaine maître», à la page 4


v «Commandes Tivoli Workload Scheduler»v «Utilisation de plusieurs agents»

Le gestionnaire de domaine maîtreLe gestionnaire de domaine maître Tivoli Workload Scheduler n'est pas pris encharge en tant que ressource de cluster pour les raisons suivantes :v Le gestionnaire de domaine maître exécute le flot de travaux critique JnextPlan.

La responsabilité du flot de travaux est de créer un plan pour le jour deproduction en cours. Ce processus ne peut pas être interrompu. Une interruptionpourrait provoquer des problèmes de fonctionnement et des interruptions duservice de planification. Seule une procédure manuelle peut être utilisée poureffectuer une reprise à partir de tels incidents ou interruptions de service.Puisque la reprise en ligne du groupe de clusters contenant la ressource TivoliWorkload Scheduler arrête l'agent sur le noeud en cours et le démarre sur unnoeud différent, si la reprise en ligne se produit lors de l'exécution de JnextPlan,cela peut être préjudiciable.

v Les utilitaires de ligne de commande Tivoli Workload Scheduler (conman,composer, etc.) ne sont pas compatibles cluster et s'ils sont interrompus (via unereprise en ligne du groupe de clusters contenant la ressource Tivoli WorkloadScheduler), ils peuvent corrompre certaines informations cruciales pour TivoliWorkload Scheduler.

Commandes Tivoli Workload SchedulerToute commande Tivoli Workload Scheduler en cours d'exécution lors d'une repriseen ligne n'est pas automatiquement mise hors ligne (contrairement aux processusprincipaux netman, mailman, batchman et jobman) par la ressource de cluster TivoliWorkload Scheduler.

Cela peut s'avérer particulièrement problématique si la reprise en ligne se produitlors d'une soumission ad-hoc. Le travail soumis pourrait rester pour toujours àl'état ADDING.

Utilisation de plusieurs agentsSi vous prévoyez d'utiliser plusieurs agents sur le même serveur Windows 32 bits,vous devez suivre les étapes nécessaires pour reconfigurer la mémoire du bureauélectronique Windows afin que les différents processus d'agent partagentdavantage de mémoire électronique du bureau. Ces mesures sont décrites dans«Résolution des problèmes de taille de segment de mémoire du bureauélectronique sur les postes de travail ayant plus de trois agents», à la page 45.

Systèmes d'exploitation pris en charge

Tivoli Workload Scheduler Windows Cluster Enabler est disponible pour lessystèmes Windows 32 bits et 64 bits.

Compatibilité, mise à niveau et coexistenceL'agent Tivoli Workload Scheduler configuré pour fonctionner dans unenvironnement cluster n'affecte pas la compatibilité avec les versions précédentesde Tivoli Workload Scheduler et ne nécessite pas de configuration ou de migrationde données.

Un agent Tivoli Workload Scheduler configuré pour fonctionner dans unenvironnement cluster Windows 2003 peut être connecté aux configurationsréparties et aux configurations réseau de bout en bout.


||||||

|

La DLL développant le programme d'administration de cluster Windows estparfois mise à jour dans des modules de correction et de nouvelles éditions deTivoli Workload Scheduler. Pour cette raison, le programme qui installe leWindows Cluster Enabler inclut une option utilisée pour mettre à jour la DLL avecune nouvelle version, mineure (module de correction) ou majeure (nouvelle éditionde Tivoli Workload Scheduler).

Sécurité et authentification

Les mécanismes habituels d'autorisation et d'authentification de sécurité TivoliWorkload Scheduler s'appliquent.

Tivoli Workload Scheduler Windows Cluster Enabler

Cette section décrit l'implémentation de Windows Cluster Enabler. Elle contient lessous-sections suivantes :v «Composants»v «Installation et configuration», à la page 7v «Application d'un groupe de correctifs ou mise à niveau de Cluster Enabler vers

une nouvelle version», à la page 12v «Commande twsClusterAdm avec exemples d'utilisation», à la page 13v «Exploitation de Tivoli Workload Scheduler dans un environnement cluster

Windows», à la page 24v «Désinstallation de Tivoli Workload Scheduler», à la page 29

Composants

Le Windows Cluster Enabler de Tivoli Workload Scheduler comprend les élémentssuivants :v Un utilitaire pour :

– Installer et configurer à distance Tivoli Workload Scheduler sur tous les autresnoeuds du cluster

– Installer et configurer le type de ressource de cluster Tivoli WorkloadScheduler pour un serveur virtuel donné

v Un type de ressource personnalisée de gestionnaire Tivoli Workload Schedulerpour gérer les événements de cluster pour les instances IBM Tivoli WorkloadScheduler (nouvelles bibliothèques de liaison dynamique)

v Une bibliothèque de liaison dynamique d'extension Tivoli Workload Schedulerpour étendre le programme Windows Cluster Administration

Chapitre 2. Tivoli Workload Scheduler avec cluster Windows 5

Le composant principal est la bibliothèque de liaison dynamique de ressourcepersonnalisée. Elle présente les caractéristiques suivantes :v Elle peut être mise en ligne et hors lignev Elle peut être gérée dans un clusterv Elle peut être hébergée (détenue) par un seul noeud à la fois

Comme illustré à la figure 1, le service de cluster communique avec la bibliothèquede liaison dynamique de ressource personnalisée via le moniteur de ressourcespour gérer les ressources. En réponse à une requête de service de cluster, lemoniteur de ressources appelle la fonction de point d'entrée appropriée dans labibliothèque de liaison dynamique de ressource personnalisée pour vérifier etcontrôler l'état de la ressource (éventuellement l'agent Tivoli Workload Scheduler).

La bibliothèque de liaison dynamique de ressource personnalisée effectuel'opération ou signale au moniteur de ressources d'appliquer le traitement pardéfaut (le cas échéant), ou les deux. La bibliothèque de liaison dynamique deressource personnalisée fournit les implémentations de point d'entrée qui serventles besoins des ressources Tivoli Workload Scheduler.

La bibliothèque de liaison dynamique de ressource personnalisée du gestionnaireTivoli Workload Scheduler fournit les points d'entrée suivants (ou services) :

IsAliveDétermine si l'agent Tivoli Workload Scheduler est actuellement actif.

OfflineProcède à un arrêt de l'agent Tivoli Workload Scheduler.

OnlineDémarre l'agent Tivoli Workload Scheduler, connecte l'agent au réseau etrend la ressource disponible pour le cluster.

Figure 1. Composants principaux de Tivoli Workload Scheduler Cluster Enabler


|

|||

TerminateProcède à un arrêt immédiat de la ressource.

La bibliothèque de liaison dynamique de ressource personnalisée de TivoliWorkload Scheduler Manager est un pont entre le moniteur de ressources (faisantpartie du service de cluster Windows) et l'agent Tivoli Workload Scheduler.L'objectif le plus important de la bibliothèque de liaison dynamique de ressourcepersonnalisée est de comprendre l'état de l'agent et de le mettre en ligne ou horsligne à l'aide de la séquence de commandes correcte.

Installation et configuration

Cette section décrit l'installation et la configuration de Windows Cluster Enabler.Elle comprend les sous-sections suivantes :v «Windows Cluster Enabler»v «Installation dans un cluster»v «Configuration requise», à la page 9v «Installation et configuration d'un nouvel agent Tivoli Workload Scheduler», à la

page 10

Tivoli Workload Scheduler Windows Cluster Enabler est installé automatiquementpar Tivoli Workload Scheduler versions 8.6. Un nouveau dossier, nommé cluster,est créé au sein du répertoire d'installation de Tivoli Workload Scheduler.

Windows Cluster Enabler

Le Windows Cluster Enabler de Tivoli Workload Scheduler inclut les fichierssuivants :

ITWSWorkstationEx.dllL'extension Tivoli Workload Scheduler Cluster Administrator. Elle ajouteune nouvelle feuille de propriétés et des pages d'assistant pour le type deressource Tivoli Workload Scheduler à la console Cluster Administrator.Pour plus d'informations, voir «Extension Tivoli Workload SchedulerCluster Administrator», à la page 28.

twsClusterAdm.exeUtilisé pour installer et configurer Tivoli Workload Scheduler.

ITWSResources.dllBibliothèque de liaison dynamique contenant l'implémentation de l'API deressource pour le type de ressource Tivoli Workload SchedulerITWSWorkstation. Elle implémente la logique qui active le moniteur deressources afin de surveiller et gérer l'agent Tivoli Workload Scheduler

ITWSExInst.cmdExemple de script qui enregistre l'extension Tivoli Workload SchedulerCluster Administrator.

Installation dans un cluster

Une configuration en clusters est constituée de deux noeuds. En fonction de latechnologie de disque utilisée, un cluster Windows peut comporter de 2 à 36noeuds.


||||

Sur chaque noeud sont exécutés zéro, un ou plusieurs groupes de ressources decluster. En cas d'incident, par exemple, du noeud A, tous les groupes de ressourcesde cluster associés au noeud défectueux basculent vers le noeud B. De cettemanière, le noeud B exécute toutes les applications compatibles cluster qui étaientexécutées sur le noeud A.

Pour faire fonctionner Tivoli Workload Scheduler dans un environnement cluster,vous pouvez :v Installer l'agent Tivoli Workload Scheduler en local sur le disque dur de l'un des

noeuds si vous devez effectuer des tâches de planification sur ce noeud decluster uniquement (en tant qu'ordinateur unique). Cela fonctionne comme uneinstallation normale. Aucune sensibilisation au cluster n'est requise.

Figure 2. Installation dans un cluster

Figure 3. Clusters dans un réseau Tivoli Workload Scheduler


|

|||

v Installer l'agent Tivoli Workload Scheduler sur un ou plusieurs serveurs virtuelssi vous avez besoin de planifier des travaux sur ce serveur virtuel. Unesensibilisation au cluster est requise.

Un serveur virtuel est un groupe contenant une ressource de nom de réseau, uneressource d'adresse IP et des ressources supplémentaires nécessaires pour exécuterune ou plusieurs applications ou services. Les clients peuvent utiliser le nom deréseau pour accéder aux ressources du groupe, de manière analogue à l'utilisationd'un nom d'ordinateur pour accéder aux services sur un serveur physique.Cependant, puisqu'un serveur virtuel est un groupe, il peut être basculé vers unautre noeud sans affecter l'adresse ou le nom sous-jacent.

Pour configurer Tivoli Workload Scheduler pour fonctionner dans unenvironnement cluster Windows, vous devez créer un serveur virtuel, en l'ajoutantau type de ressource du disque physique et en installant Tivoli WorkloadScheduler sur ce disque.

Le nouveau type de ressource de cluster créé pour gérer un agent Tivoli WorkloadScheduler procédera à un arrêt en douceur et démarrera l'agent lors d'une repriseen ligne.

Configuration requise

Les conditions préalables à la configuration correcte d'IBM Tivoli WorkloadScheduler sur le cluster sont les suivantes :

Windows Cluster ServerUn serveur Windows Cluster Server configuré et en cours defonctionnement doit être prêt.

Un groupe de serveurs virtuels de clusterLe groupe de serveurs virtuels de cluster est un groupe contenant aumoins la ressource d'adresse IP virtuelle, la ressource de nom de réseau etla ressource de disque physique. Le groupe de serveurs virtuels de clusterpeut contenir d'autres ressources d'application, pas uniquement cellesd'IBM Tivoli Workload Scheduler.

Pour créer le serveur virtuel de cluster, vous pouvez utiliser la consoleadministrateur de cluster. Procédez comme suit :v Créez le groupe de clustersv Ajoutez le disque partagé au groupe de clusters créév Ajoutez la ressource IP et créez une dépendance à partir du disquev Ajoutez la ressource réseau et créez une dépendance à partir de la

ressource IP

Reportez-vous à la documentation Windows pour plus de détails.

Un utilisateur administrateur de domaineUn utilisateur administrateur de domaine prêt à être utilisé (l'utilisateurdoit appartenir au groupe administrateur de tous les noeuds du cluster) etun mot de passe.

Un utilisateur de domaineSpécifiez un utilisateur de domaine en tant qu'utilisateur IBM TivoliWorkload Scheduler lors de l'installation. Si un domaine valide n'est passpécifié, un utilisateur local est créé par défaut.

Accorder des droits d'accès à l'administrateur de clusterVérifiez que le compte administrateur de cluster dispose du droit suivant :


Remplacement d'un marqueur de niveau du processus. Pour ajouter cedroit au compte administrateur de cluster, ouvrez Panneau deconfiguration → Outils d'administration → Stratégie de sécurité locale →Stratégies locales → Attribution des droits utilisateur et ajoutez le compteutilisateur Administrateur de cluster à la liste de la stratégie de sécuritéRemplacer un jeton niveau de processus. Ce droit est nécessaire pour quel'administrateur de cluster puisse agir en tant qu'utilisateur TivoliWorkload Scheduler. De cette manière, la ressource personnalisée TivoliWorkload Scheduler exécutée avec les droits de l'utilisateur administrateurde cluster est capable d'arrêter, de démarrer et de lier Tivoli WorkloadScheduler. Redémarrez les noeuds de cluster pour que cette modificationprenne effet. Cette opération n'est nécessaire que la première fois que vousconfigurez Tivoli Workload Scheduler pour travailler dans lesenvironnements cluster Windows.

Installer le module Microsoft Visual C++ 2005 Redistributable Package (x86) surd'autres noeuds de cluster

Tous les noeuds du cluster doivent pouvoir prendre en charge l'utilisationde C++. Pour ce faire, installez le module Microsoft Visual C++ 2005Redistributable Package (x86). L'installation de la tâche d'activation du clusterTivoli Workload Scheduler installe ce module sur le noeud sur lequel ellese trouve. Cependant, pour pouvoir basculer vers d'autres noeuds ducluster, le module doit également être installé sur ces noeuds.

Procédez comme suit :1. Téléchargez le module Visual C++ 2005 Redistributable Package (x86) à

partir de http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en. Vous pouvez également accéder àhttp://www.microsoft.com et rechercher le module selon son nom.Téléchargez le fichier du module (vcredist_x86.exe).

2. Copiez le module pour chaque noeud dans le groupe Cluster VirtualServer Group :

3. Dans chaque noeud du groupe (autre que celui sur lequel vous allezinstaller la tâche d'activation du cluster), procédez comme suit :a. Connectez-vous en tant qu'administrateur de domaine.b. Exécutez vcredist_x86.exe.

Installation et configuration d'un nouvel agent Tivoli WorkloadScheduler

Remarque : Lors de l'installation du cluster Tivoli Workload Scheduler 8.6, lesparamètres suivants ne doivent pas être spécifiés avec un jeu decaractères codé sur deux octets (DBCS):v Userv Domaine, zone

Pour installer Tivoli Workload Scheduler dans une configuration compatiblecluster, procédez comme suit :1. Installez l'agent Tivoli Workload Scheduler :

a. Sélectionnez un noeud du cluster. Ce noeud doit être utilisé pour toutes lesopérations consécutives (telles que les installations de groupe de correctifs).

b. Connectez-vous au noeud à l'aide d'un utilisateur ayant des privilègesd'administrateur de domaine.


http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en



http://www.microsoft.com

c. Choisissez le serveur virtuel Microsoft où vous voulez installer l'agent IBMTivoli Workload Scheduler.

d. Installez Tivoli Workload Scheduler version 8.6 :v Spécifiez un utilisateur de domaine comme utilisateur pour lequel vous

voulez installer Tivoli Workload Schedulerv Spécifiez le disque associé à ce serveur virtuel en tant que répertoire de

destinatione. Installez Tivoli Workload Scheduler version 8.6.

2. Rendez Tivoli Workload Scheduler compatible cluster :a. Exécutez l'invite de commande Windows.b. Accédez au répertoire de base de Tivoli Workload Scheduler (sur le disque

partagé).c. Exécutez tws_env.cmd pour charger les variables d'environnement Tivoli

Workload Scheduler.d. Exécutez Shutdown.cmd pour arrêter Tivoli Workload Scheduler.e. Accédez au répertoire cluster.f. Exécutez l'utilitaire twsClusterAdm.exe pour configurer Tivoli Workload

Scheduler à distance sur tous les noeuds du cluster et pour installer laressource de cluster Tivoli Workload Scheduler. Voir «Exemple 1 : premièreinstallation de Tivoli Workload Scheduler dans un environnement clusterWindows», à la page 20 pour un exemple d'installation.

3. Définissez un nouvel objet de poste de travail sur le gestionnaire de domainemaître en utilisant composer ou Dynamic Workload Console. Vérifiez que lenom de node spécifié est converti par le DNS et que l'adresse IP peut êtresoumise à une commande ping depuis le gestionnaire de domaine maître. Sivous utilisez une configuration réseau de bout en bout, vous devez spécifierl'adresse IP que vous aviez spécifiée pour la valeur de ressource de clusterNET/IP.

4. Démarrez la ressource de cluster Tivoli Workload Scheduler. Depuis la consoleadministrateur de cluster, sélectionnez le groupe de clusters (dans la figure 4, àla page 12 il s'agit du serveur virtuel F).

5. Sélectionnez le type de ressource ITWSWorkstation (dans la figure 4, à la page12, le nom d'instance est ITWSWorkstation_CLUSTER_SA_DM1), comme illustrédans l'exemple ci-après sous Windows Server 2003. Cliquez avec le boutondroit de la souris et sélectionnez Bring Online.


6. ITWSWorkstation est le nom du type de ressource personnalisé TivoliWorkload Scheduler. ITWSWorkstation_CLUSTER_SA_DM1 est le nom de l'instance.Par défaut, lorsqu'il est créé à l'aide de la ligne de commande twsClusterAdm,le nom d'instance est ITWSWorkstation_<nom_domaine>_<nom_utilisateur>.N'utilisez pas un jeu de caractères codé sur deux octets (DBCS) pour le nom dedomaine et le nom d'utilisateur.

7. Patientez jusqu'à l'exécution du flot de travaux final ou générez un nouveauplan pour ajouter le nouveau poste de travail dans le plan.

Application d'un groupe de correctifs ou mise à niveau deCluster Enabler vers une nouvelle version

Si Tivoli Workload Scheduler version 8.4 ou ultérieure et Cluster Enabler sont déjàinstallés, vous pouvez appliquer un groupe de correctifs ou mettre à niveau l'agentet Enabler vers Tivoli Workload Scheduler, version 8.6. Procédez comme suit :1. A partir de la console Cluster Administrator, déconnectez la ressource

ITWSWorkstation associée à l'installation que vous voulez mettre à niveau.2. Appliquez le groupe de correctifs ou mettez à niveau l'agent Tivoli Workload

Scheduler vers la version 8.6.Pour obtenir des instructions et plus d'informations, reportez-vous au fichierLisez-moi du groupe de correctifs ou au manuel Tivoli Workload Scheduler -Guide de planification et d'installation.

Figure 4. Exemple de groupe de clusters sous Windows Server 2003


||

|

3. A partir du répertoire <TWS_HOME>\cluster, lancez l'utilitaire twsclusteradm.exeà l'aide de l'option –update (twsclusteradm.exe –update).

Remarque : Si vous procédez à la mise à niveau vers une version principale,telle que la version 8.5, vous pouvez utiliser la sous-option –twsupd(twsclusteradm.exe –update –twsupd) pour mettre à jour leregistre des services Windows avec la modification de la version.

4. A partir de la console Cluster Administrator, mettez la ressourceITWSWorkstation en ligne.

Pour un exemple de mise à niveau, voir «Exemple 10 : Mise à niveau à partir deTivoli Workload Scheduler version 8.4 ou ultérieure, cluster activé», à la page 22.

Commande twsClusterAdm avec exemples d'utilisation

La commande twsClusterAdm est l'utilitaire permettant de configurer TivoliWorkload Scheduler dans des environnements cluster Microsoft Windows.

La commande twsClusterAdm :v Configure Tivoli Workload Scheduler sur tous les noeuds du cluster ou sur un

noeud de cluster nouvellement joint.v Installe le nouveau type de ressource de cluster Tivoli Workload Scheduler pour

la première fois. Le nom de ce nouveau type de ressource de cluster estITWSWorkstation.

v Crée une instance du type de ressource de cluster Tivoli Workload Scheduler ausein d'un groupe de clusters.

v Supprime la configuration Tivoli Workload Scheduler à partir d'un ou plusieursnoeuds du cluster.

v Met à niveau le type de ressource de cluster Tivoli Workload Scheduler si unenouvelle version est disponible.

Elle fonctionne en plusieurs étapes pour accomplir une installation compatiblecluster :v Détermine si la configuration fonctionne dans un environnement cluster.v Copie la bibliothèque de liaison dynamique de ressource Tivoli Workload

Scheduler vers les noeuds du cluster.v Met à jour le mode de démarrage des services Tivoli Workload Scheduler

d'automatique à manuel.v Installe la clé de registre et les services Tivoli Workload Scheduler sur les autres

noeuds (car les services en cours et la clé de registre ont été installés parl'installation normale du produit).

v Enregistre les types de ressource Tivoli Workload Scheduler.v Crée une instance de la ressource Tivoli Workload Scheduler au sein d'un

groupe de clusters donné (serveur virtuel) et enregistre le nom d'instance dans lefichier localopts.

v Installe Common Inventory Technology sur les autres noeuds

Configuration d'un gestionnaire de domaine avec cluster

Si vous voulez installer un gestionnaire de domaine sur un environnement cluster,vous devez spécifier l'option link en utilisant le paramètre twsClusterAdm opts(décrit dans «Syntaxe», à la page 14). Spécifiez le domaine parent du gestionnairede domaine ainsi que le poste de travail du gestionnaire de domaine parent, de


|

sorte que le processus d'installation puisse correctement gérer la suppression desliaisons et le renouvellement des liaisons requis. Voir «Exemple 9 : premièreinstallation du gestionnaire de domaine en environnement cluster Windows, enspécifiant des options génériques», à la page 22 pour un exemple illustré.

Si l'option link n'est pas sélectionnée, ou est sélectionnée avec des valeursincorrectes, la configuration ne peut pas se terminer correctement. Vous n'aveztoutefois pas à répéter l'installation pour résoudre cet incident. A la place, accédezau panneau de propriété d'instance de ressource Tivoli Workload Scheduler etajoutez le lien à la zone genericOpts sous l'onglet Paramètres. Lorsque vousactivez le cluster, les informations de l'option link sont utilisées pour terminer laconfiguration.

Syntaxe

twsClusterAdm.exe –newdomain=<domaine_Windows>user=<utilisateur_TWS>pwd=<motdepasse_utilisateur_TWS>[hosts=<nomhôte1,nomhôte2...>][twshome=<rép_base_TWS>][ –res

group=<nom_groupe_clusters>ip=<nom_ressource_IP>net=<nom_ressource_réseau>disk=<nom_ressource_disque>[resname=<nom_instance_ressource>][check_interval=<intervalle_interrogation_TWS>][failover=yes|no][looksalive=<intervalle_lookalive>][isalive=<intervalle_isalive>][tcpport=<port_tcp>][opts=<options_génériques>]

][–notwsinst][–dll

[path=<chemin_ressource_DLL>]]

[–force][–sharedDesktop [name=<nom_bureau>]]

twsClusterAdm.exe –uninstdomain=<domaine_Windows>user=<nom_utilisateur_TWS>[hosts=<nomhôte1,nomhôte2...>]

twsClusterAdm.exe –updateresource=<nom_instance_ressource>[–ask={yes|no}][–force][–twsupd]

twsClusterAdm.exe –changeResName"<nom_instance_ressource>""<nom_nouvelle_instance_ressource>"


Paramètres et arguments–new Le paramètre –new configure Tivoli Workload Scheduler sur tous les

noeuds du cluster ou sur un nouveau noeud de cluster. Il accepte lesarguments suivants :

Domain=<domaine_Windows>Domaine utilisateur Windows de l'utilisateur Tivoli WorkloadScheduler. Ce paramètre est obligatoire si –new ou –uninst estspécifié. Ce paramètre ne doit pas être spécifié avec un jeu decaractères codé sur deux octets (DBCS).

user=<utilisateur_TWS>Nom d'utilisateur Windows de l'utilisateur Tivoli WorkloadScheduler. Ce paramètre est obligatoire si –new ou –uninst estspécifié. Ce paramètre ne doit pas être spécifié avec un jeu decaractères codé sur deux octets (DBCS).

pwd=<motdepasse_utilisateur_TWS>Mot de passe Windows de l'utilisateur Tivoli Workload Scheduler.Ce paramètre est obligatoire si –new est spécifié.

hosts=<nomhôte1,nomhôte2...>Noms d'hôte des noeuds de cluster où vous voulez configurerTivoli Workload Scheduler. Les noms d'hôte doivent être séparéspar des virgules. Ce paramètre est facultatif. Il peut être utilisépour configurer un nouveau noeud se joignant au cluster.

twshome=<rép_base_TWS>Répertoire où Tivoli Workload Scheduler est installé. Ce paramètreest facultatif. Si vous ne spécifiez pas ce répertoire, la commanderecherchera le répertoire d'installation.

–res Le paramètre –res ajoute une instance du type de ressource TivoliWorkload Scheduler à un groupe de clusters existant. Il accepte lesarguments suivants :

group=<nom_groupe_clusters>Nom du groupe de clusters (serveur virtuel) où Tivoli WorkloadScheduler est configuré comme ressource de cluster. Ce paramètreest obligatoire.

ip=<nom_ressource_IP>Nom du type de ressource IP du cluster dont la ressource TivoliWorkload Scheduler resource dépend. Ce paramètre est obligatoire.

net=<nom_ressource_réseau>Nom du type de ressource du réseau dont la ressource TivoliWorkload Scheduler dépend. Ce paramètre est obligatoire.

disk=<nom_ressource_disque>Nom du type de ressource du disque dont la ressource IBM TivoliWorkload Scheduler dépend. Ce paramètre est obligatoire.

resname=<nom_instance_ressource>Nom de l'instance de ressource, tel qu'il apparaît dansl'administrateur de cluster (voir figure 4, à la page 12). Si ceparamètre n'est pas fourni, la valeur par défaut deITWSWorkstation_<domain_name>_<user_name> est utilisée.

failover=yes|noSi vous spécifiez yes, Tivoli Workload Scheduler peut provoquer la


reprise en ligne du groupe de serveurs virtuels. Si vous nespécifiez pas cette option, Tivoli Workload Scheduler neprovoquera pas la reprise en ligne du groupe de serveurs virtuels.Ce paramètre est facultatif. Notez que vous pouvez modifier ceparamètre directement à partir de la console Cluster Administrator.En modifiant les valeurs de seuil et de période à partir de l'ongletde propriété de la ressource, vous pouvez activer ou désactiver lareprise en ligne automatique en cas de défaillance de la ressource.Pour plus d'informations, voir le manuel Windows Cluster Guide.

check_interval=<intervalle_interrogation_TWS>Intervalle en millisecondes que la ressource Tivoli WorkloadScheduler attend entre deux vérifications de santé. Ce paramètreest facultatif. Utilisez des valeurs supérieures à 60000. La valeurpar défaut est 100000. Vous pouvez modifier cette valeur à partirde la console Cluster Administrator : cliquez avec le bouton droitde la souris sur la ressource et sélectionnez Propriétés →Paramètres.

lookalive=<intervalle_lookalive>Intervalle en millisecondes auquel le service du cluster interroge laressource pour déterminer si elle semble opérationnelle. Ceparamètre est facultatif. Utilisez des valeurs supérieures à 10000.La valeur par défaut est 10000. Vous pouvez modifier cette valeurà partir de la console Cluster Administrator : cliquez avec lebouton droit de la souris sur la ressource et sélectionnez Propriétés→ Avancées.

Isalive=<intervalle_isalive>Intervalle en millisecondes auquel le service du cluster interroge laressource pour déterminer si elle semble opérationnelle. Ceparamètre est facultatif. Utilisez des valeurs supérieures à 10000.La valeur par défaut est 60000. Vous pouvez modifier cette valeurà partir de la console Cluster Administrator : cliquez avec lebouton droit de la souris sur la ressource et sélectionnez Propriétés→ Avancées.

tcpport=port_tcpCe paramètre est réservé pour une utilisation future.

opts=options_génériquesLes options de ressource génériques sont utilisées pour spécifier unensemble d'options. Chaque option est séparée par unpoint-virgule (";"). Le paramètre opts acceptera les optionssuivantes :v ftaOff

Utilisez cette option pour activer la surveillance de l'agent deplanification dynamique. Si elle n'est pas spécifiée, lecomportement par défaut reste inchangé : seul l'agent tolérantaux pannes est surveillé.

v lwaOn

Utilisez cette option pour activer la surveillance de l'agent deplanification dynamique et de Job Manager. Si elle n'est passpécifiée, le comportement par défaut reste inchangé : seull'agent tolérant aux pannes est surveillé.

v killjob


Utilisez cette option pour mettre fin à un travail (et enfant dutravail) en cours d'exécution au moment de l'incident de laressource.

v link=<domaine_parent>!<gestionnaire_domaine_parent>

Utilisez cette option si vous configurez un gestionnaire dedomaine compatible cluster. Spécifiez le domaine parent et legestionnaire de l'agent que vous configurez.Par exemple, si vous configurez un gestionnaire de domaineenfant du gestionnaire de domaine maître (appelé MyMasterWSdans le domaine MASTERDOM), la valeur à spécifier estlink=MASTERDOM!MyMasterWS.

Les options kill et link peuvent être utilisées ensemble (parexemple, opts=killjob;link=MASTERDM!MASTERWS;). Vous pouvezmodifier cette valeur à partir de la console Cluster Administrator :cliquez avec le bouton droit de la souris sur la ressource etsélectionnez Propriétés → Paramètres. Modifiez les valeurs de lazone genericOpts.

–notwsinstLe paramètre –notwsinst peut éventuellement spécifier que vous installezl'instance de ressource de cluster pour une instance existante de TivoliWorkload Scheduler.

–dll Le paramètre –dll spécifie que le fichier ITWSResources.dll quiimplémente le nouveau type de ressource Tivoli Workload Scheduler doitêtre installé. Ce paramètre est obligatoire la première fois que vousconfigurez Tivoli Workload Scheduler sur le cluster ou si un nouveaunoeud se joint au cluster. Ce paramètre utilise un argument facultatif :

[path=<chemin_ressource_DLL>]Chemin d'accès où ITWSResources.dll doit être installé. Ceparamètre est facultatif. Si vous ne spécifiez pas le chemin d'accès,la valeur par défaut \%systemRoot%\cluster est utilisée. Nespécifiez pas d'identificateur d'unité pour le chemin d'accès. Lechemin d'accès doit exister et doit être accessible sur chaque noeuddu cluster.

–force Le paramètre –force peut forcer l'installation de la bibliothèque dechargement dynamique de la ressource Tivoli Workload Scheduler(ITWSResources.dll) sans vérification de la version. Le paramètre estignoré si vous n'avez pas spécifié le paramètre –dll.

–sharedDesktopLe paramètre –sharedDesktop peut spécifier que Jobmon utilise un nomde bureau électronique partagé pour gérer l'allocation de mémoire dusegment de mémoire du bureau électronique si plusieurs agents sontinstallés sur un même ordinateur (voir «Résolution des problèmes de taillede segment de mémoire du bureau électronique sur les postes de travailayant plus de trois agents», à la page 45 pour plus de détails). Utilisez lemême nom pour au moins deux agents sur cet ordinateur afin de rendrel'option effective.

name=<nom_bureau>Nom facultatif du bureau électronique. Si vous fournissez un nom,il doit être en caractères mono-octet (alphabet anglais), sanscaractères spéciaux, sauf les espaces, auquel cas vous devez leplacer entre guillemets. Le nom par défaut (si vous ne fournissezpas l'argument name=<nom_bureau>) est TWS_JOBS_WINSTA.


–uninst

Le paramètre –uninst désinstalle l'instance de ressource de cluster etaccepte les arguments suivants :

Domain=<domaine_Windows>Domaine utilisateur Windows de l'utilisateur Tivoli WorkloadScheduler. Ce paramètre est obligatoire si vous spécifiez –new ou–uninst. Ce paramètre ne doit pas être spécifié avec un jeu decaractères codé sur deux octets (DBCS).

user=<utilisateur_TWS>Nom d'utilisateur Windows de l'utilisateur Tivoli WorkloadScheduler. Ce paramètre est obligatoire si vous spécifiez –new ou–uninst. Ce paramètre ne doit pas être spécifié avec un jeu decaractères codé sur deux octets (DBCS).

hosts=<nomhôte1,nomhôte2...>Noms d'hôte des noeuds de cluster où vous voulez désinstallerTivoli Workload Scheduler. Les noms d'hôte doivent être séparéspar des virgules. Ce paramètre est facultatif. Si vous ne spécifiezpas ce paramètre, Tivoli Workload Scheduler est désinstallé à partirde tous les noeuds dans le cluster excepté le noeud en cours.

–update

Le paramètre –update met à jour la DLL de ressource Tivoli WorkloadScheduler d'une instance existante et accepte les arguments suivants :

resource=<nom_instance_ressource>Nom d'instance de ressource Tivoli Workload Scheduler tel qu'ilapparaît au sein du groupe de clusters. Le nom par défaut estITWSWorkstation_<domaine>_<utilisateur>. Ce paramètre estobligatoire.

–ask={yes|no}Définit si le programme de mise à jour doit demander avant deredémarrer la DLL de ressource après sa mise à jour. Indiquez yespour signaler que le programme de mise à jour doit s'arrêter etdemander à l'opérateur une confirmation pour qu'il redémarre laDLL de ressource de cluster. Valeur par défaut. Indiquez no pourredémarrer automatiquement la DLL de ressource de cluster aprèssa mise à jour sans intervention manuelle. Ce paramètre estfacultatif.

–force Force l'installation de la bibliothèque de liaison dynamique de laressource Tivoli Workload Scheduler (ITWSResources.dll) sansvérification de la version. Ce paramètre est facultatif.

–twsupdDéfinit si le registre du service Windows doit être mis à jour aprèsla mise à jour de la DLL de ressource. Utilisez ce paramètreuniquement lors de la mise à jour de la DLL après la mise à niveaude Tivoli Workload Scheduler vers une nouvelle version majeure,telle que 8.6. Ce paramètre est facultatif.

–changeResName

Le paramètre –changeResName modifie le nom de l'instance de ressourcede cluster et accepte les arguments suivants :


"<nom_instance_ressource>"Nom d'instance de ressource Tivoli Workload Scheduler tel qu'ilapparaît au sein du groupe de clusters. Le nom par défaut estITWSWorkstation_<domaine>_<utilisateur>. Cet argument estobligatoire pour –changeResName.

"<nom_nouvelle_instance_ressource>"Le nouveau nom que vous voulez utiliser pour l'instance deressource Tivoli Workload Scheduler. Cet argument est aussiobligatoire avec –changeResName.

Exemples

Tous les exemples décrits ci-dessous supposent que Tivoli Workload Scheduler 8.6a été installé.

Pour tous les exemples décrits ci-dessous, les définitions suivantes sont utilisées :

mondom Domaine utilisateur Windows de l'utilisateur Tivoli Workload Scheduler.

monutiltwsNom utilisateur Tivoli Workload Scheduler.

monmdptwsMot de passe du domaine utilisateur MYDOM\mytwsuser.

mongperessNom du groupe de ressources du cluster sélectionné.

monip Nom du type de ressource d'adresse IP au sein du groupe de ressourcesmyresgroup.

monnomresNom du type de ressource de nom de réseau au sein du groupe deressources myresgroup.

mondisqNom du type de ressource de disque physique au sein du groupe deressources myresgroup.

mon bureau partagéNom du bureau électronique partagé que toutes les instances de jobmonutiliseront.

monNomResNom personnalisé de l'instance de ressource.

Les exemples sont les suivants :v «Exemple 1 : première installation de Tivoli Workload Scheduler dans un

environnement cluster Windows», à la page 20v «Exemple 2 : Installation et configuration de la nouvelle ressource personnalisée

pour une installation existante de Tivoli Workload Scheduler», à la page 20v «Exemple 3 : Ajout d'un nouvel agent dans un environnement cluster avec Tivoli

Workload Scheduler déjà installé», à la page 21v «Exemple 4 : Ajout d'une instance de type de ressource personnalisée à un

groupe de clusters existant», à la page 21v «Exemple 5 : Configuration de Tivoli Workload Scheduler dans un nouveau

noeud de liaison du cluster», à la page 21v «Exemple 6 : Désenregistrement de Tivoli Workload Scheduler sur tous les

noeuds du cluster excepté pour le noeud en cours», à la page 21


v «Exemple 7 : Installation d'une nouvelle version de la bibliothèque de liaisondynamique de ressource de cluster dans le cluster», à la page 22

v «Exemple 8 : Forcer la mise à niveau/la rétromigration de la bibliothèque deliaison dynamique de ressource du cluster dans le cluster», à la page 22

v «Exemple 9 : première installation du gestionnaire de domaine enenvironnement cluster Windows, en spécifiant des options génériques», à la page22

v «Exemple 10 : Mise à niveau à partir de Tivoli Workload Scheduler version 8.4ou ultérieure, cluster activé», à la page 22

v «Exemple 11 : première installation de Tivoli Workload Scheduler dans unenvironnement cluster Windows, avec définition de bureau électronique partagé», à la page 23

v «Exemple 12 : première installation de Tivoli Workload Scheduler enenvironnement cluster Windows, avec utilisation de nom d'instance de ressourcepersonnalisé», à la page 23

v «Exemple 13 : Modification du nom de l'instance de ressource», à la page 24

Exemple 1 : première installation de Tivoli Workload Scheduler dans unenvironnement cluster Windows :

Première installation de Tivoli Workload Scheduler dans un environnement clusterWindows.twsClusterAdm.exe –new domain=MONDOM user=monutiltws pwd=monmdptws–res group=mongperess ip=monip net=monnomres disk=mondisq –dll

La commande :v Configure Tivoli Workload Scheduler sur tous les noeuds du cluster.v Installe le nouveau type de ressource du cluster Tivoli Workload Scheduler

(appelé ITWSWorkstation) sur tous les noeuds du cluster.v Copie le fichier ITWSResources.dll dans le dossier \%systemRoot%\cluster.v Crée une instance du type de ressource de cluster Tivoli Workload Scheduler au

sein d'un groupe de clusters spécifié.v Ajoute un dépendance à partir de monip, monnomres et mondisq à la ressource.

Exemple 2 : Installation et configuration de la nouvelle ressource personnaliséepour une installation existante de Tivoli Workload Scheduler :

Installation et configuration de la nouvelle ressource personnalisée Tivoli WorkloadScheduler pour une installation existante de Tivoli Workload Scheduler.

Remarque : Cet exemple n'est applicable que si l'agent Tivoli Workload Schedulera déjà été installé pour la même instance sur tous les noeuds ducluster et que tous les types de démarrage des services TivoliWorkload Scheduler sont définis sur Manual.

twsClusterAdm.exe –new domain=MONDOM user=monutiltws pwd=monmdptws–res group=mongperess ip=monip net=monnomres disk=mondisq –dll –notwsinst

La commande :v Installe le nouveau type de ressource du cluster Tivoli Workload Scheduler


sein d'un groupe de clusters spécifié.


|

v Ajoute un dépendance à partir de monip, monnomres et mondisq à la ressource.

Exemple 3 : Ajout d'un nouvel agent dans un environnement cluster avec TivoliWorkload Scheduler déjà installé :

Ajout d'un nouvel agent Tivoli Workload Scheduler dans un environnement clusteroù un agent de Tivoli Workload Scheduler a été installé et configuré dans unserveur virtuel différent.twsClusterAdm.exe –new domain=MONDOM user=monutiltws pwd=monmdptws–res group=mongperess ip=monip net=monnomres disk=mondisq

La commande :v Configure Tivoli Workload Scheduler sur tous les noeuds du cluster.v Crée une instance du type de ressource de cluster Tivoli Workload Scheduler au

sein d'un groupe de clusters spécifiév Ajoute un dépendance à partir de monip, monnomres et mondisq à la ressource.

Exemple 4 : Ajout d'une instance de type de ressource personnalisée à un groupede clusters existant :

Ajout d'une instance de type de de ressource personnalisée Tivoli WorkloadScheduler à un groupe de clusters existant.

Remarque : Cet exemple n'est applicable que si l'agent Tivoli Workload Schedulera été installé et configuré et que le type de ressource personnaliséeTivoli Workload Scheduler a été installé et enregistré.

twsClusterAdm.exe –new domain=MONDOM user=monutiltws pwd=monmdptws–res group=mongperess ip=monip net=monnomres disk=mondisq –notwsinst

La commande :v Crée une instance du type de ressource de cluster Tivoli Workload Scheduler au

sein d'un groupe de clusters spécifiév Ajoute un dépendance à partir de monip, monnomres et mondisq à la ressource.

Exemple 5 : Configuration de Tivoli Workload Scheduler dans un nouveaunoeud de liaison du cluster :

Configuration de Tivoli Workload Scheduler dans un nouveau noeud de liaison ducluster.

Remarque : Cet exemple n'est applicable que si l'agent Tivoli Workload Schedulera été installé et configuré dans l'environnement cluster. Il est possibleque vous utilisiez Tivoli Workload Scheduler depuis longtemps, quevous ayez acheté un nouveau noeud pour ce cluster et que voussouhaitiez que Tivoli Workload Scheduler soit capable de s'y déplaceren cas d'incident.

twsClusterAdm.exe –new domain=MONDOM user=monutiltws pwd=monmdptwshosts=mon_nouvel_hôte_de_liaison -dll

Cette commande configure Tivoli Workload Scheduler et installe la bibliothèque deliaison dynamique (DLL) de ressource de cluster Tivoli Workload Scheduler sur lenoeud mon_nouvel_hôte_de_liaison.

Exemple 6 : Désenregistrement de Tivoli Workload Scheduler sur tous lesnoeuds du cluster excepté pour le noeud en cours :


Désenregistrement de Tivoli Workload Scheduler sur tous les noeuds du clusterexcepté pour le noeud en cours. Voir la section relative à la procédure dedésinstallation pour plus de détails.twsClusterAdm.exe –uninst domain=MONDOM user=monutiltws

La commande supprime la configuration Tivoli Workload Scheduler à partir detous les noeuds excepté pour le noeud en cours.

Pour désinstaller Tivoli Workload Scheduler à partir du noeud en cours, vousdevez utiliser la procédure de désinstallation normale décrite dans le manuel IBMTivoli Workload Scheduler - Guide de planification et d'installation.

Exemple 7 : Installation d'une nouvelle version de la bibliothèque de liaisondynamique de ressource de cluster dans le cluster :

Installation d'une nouvelle version de la bibliothèque de liaison dynamique deressource de cluster Tivoli Workload Scheduler dans le cluster.twsClusterAdm.exe –update resource=<nom_ressource>

La commande met à niveau le type de ressource de cluster Tivoli WorkloadScheduler si une nouvelle version est disponible.

Exemple 8 : Forcer la mise à niveau/la rétromigration de la bibliothèque deliaison dynamique de ressource du cluster dans le cluster :

Forcer la mise à niveau/la rétromigration de la bibliothèque de liaison dynamiquede ressource du cluster Tivoli Workload Scheduler dans le cluster.twsClusterAdm.exe –update resource=<nom de la ressource> –force

La commande met à niveau la ressource du cluster Tivoli Workload Scheduler sansvérifier si la version est supérieure à celle de la version installée.

Exemple 9 : première installation du gestionnaire de domaine en environnementcluster Windows, en spécifiant des options génériques :

Première installation d'un gestionnaire de domaine Tivoli Workload Scheduler dansun environnement cluster Windows, en spécifiant les options génériques kill etlink.twsClusterAdm.exe –new domain=MONDOM user=monutiltws pwd=monmdptws –resgroup=mongperess ip=monip net=monnomres disk=mondisqopts=killjob;link=MASTERDM!MASTER; –dll



sein d'un groupe de clusters spécifié.v Ajoute un dépendance à partir de monip, monnomres et mondisq à la ressource.v Configure les options génériques kill et link.

Exemple 10 : Mise à niveau à partir de Tivoli Workload Scheduler version 8.4 ouultérieure, cluster activé :


|

Pour effectuer une mise à niveau à partir de Tivoli Workload Scheduler version 8.4ou ultérieure, cluster activé, vers la version 8.6, procédez comme suit :v A partir de la console Cluster Administrator, mettez hors ligne

ITWSWorkstation_mondomaine_monutiltws (la ressource ITWSWorkstation quevous voulez mettre à niveau).

v Choisissez l'installation de l'agent associée à l'utilisateur monutiltws et mettez-la àniveau vers Tivoli Workload Scheduler version 8.6.

v A partir du répertoire <TWS_HOME>\cluster, lanceztwsClusterAdm.exe –update resource=<nom de la ressource> –twsupd –ask=no

La DLL de ressource et le registre de services Windows sont mis à jour et la DLLest redémarrée sans intervention d'opérateur.

v A partir de la console Cluster Administrator, mettez la ressourceITWSWorkstation_mondomaine_monutiltws en ligne.

Exemple 11 : première installation de Tivoli Workload Scheduler dans unenvironnement cluster Windows, avec définition de bureau électroniquepartagé :

Première installation de Tivoli Workload Scheduler dans un environnement clusterWindows, en définissant un bureau partagé utilisé par Jobmon (comme dansl'exemple 1, mais avec l'ajout d'un bureau partagé) :twsClusterAdm.exe –new domain=MONDOM user=monutiltws pwd=monmdptws–res group=mongperess ip=monip net=monnomres disk=mondisq –dll –sharedesktop



sein d'un groupe de clusters spécifié.v Ajoute un dépendance à partir de monip, monnomres et mondisq à la ressource.v Définit que jobmon utilise le nom du bureau électronique partagé par défaut

Exemple 12 : première installation de Tivoli Workload Scheduler enenvironnement cluster Windows, avec utilisation de nom d'instance de ressourcepersonnalisé :

Première installation de Tivoli Workload Scheduler dans un environnement clusterWindows, à l'aide d'un nom d'instance de ressource personnalisé (comme dansl'exemple 1, mais avec l'ajout du nom d'instance de ressource personnalisé) :twsClusterAdm.exe –new domain=MONDOM user=monutiltws pwd=monmdptws–res group=mongperess ip=monip net=monnomres disk=mondisq resname=myResName –dll



sein d'un groupe de clusters spécifié.v Ajoute un dépendance à partir de monip, monnomres et mondisq à la ressource.


v Définit que le nom de l'instance de ressource est monNomRes.

Exemple 13 : Modification du nom de l'instance de ressource :

Modification du nom d'une instance de ressource existante :twsClusterAdm.exe –changeResName "ITWSWorkstation_CLUSTER_SA_DM1"

"monNomRes"

La commande modifie le nom de l'instance de ressource deITWSWorkstation_CLUSTER_SA_DM1 en monNomRes.

Exemple 14 : Première installation du gestionnaire de domaine dans unenvironnement cluster Windows, en spécifiant les options de surveillance de laplanification dynamique :

Première installation d'un gestionnaire de domaine Tivoli Workload Scheduler dansun environnement cluster Windows, en spécifiant l'option générique ftaOff.twsClusterAdm.exe –new domain=MONDOM user=monutiltws pwd=monmdptws –resgroup=mongperess ip=monip net=monnomres disk=mondisqopts=ftaOff



sein d'un groupe de clusters spécifié.v Ajoute un dépendance à partir de monip, monnomres et mondisq à la ressource.v Définit l'option générique ftaOff pour activer la surveillance de l'agent

planificateur dynamique.

Exploitation de Tivoli Workload Scheduler dans unenvironnement cluster Windows

Cette section décrit comment exploiter Tivoli Workload Scheduler enenvironnements cluster Windows. Elle comprend les sous-sections suivantes :v «Dépendances de ressource du cluster»v «Démarrage et arrêt de Tivoli Workload Scheduler», à la page 25v «Nouvelle option locale “cluster instance name”», à la page 26

Dépendances de ressource du cluster

L'une des étapes importantes lors de l'exécution de Tivoli Workload Schedulerdans les environnements cluster Windows consiste à vérifier que les dépendancesont été correctement définies.

Pour garantir le bon fonctionnement de Tivoli Workload Scheduler, l'instance deressource du cluster Tivoli Workload Scheduler doit dépendre des types deressource suivants :v Adresse IP

v Disque physique

v Nom de réseau


||

|

|

|

comme illustré dans l'exemple ci-après sous Windows Server 2003

Vous pouvez décider d'ajouter plus de dépendances pour s'assurer que TivoliWorkload Scheduler ne lance les travaux qu'une fois qu'un service donné estdisponible. Cela se produit lorsque Tivoli Workload Scheduler planifie des travauxqui nécessitent d'autres applications compatibles cluster. Par exemple, pours'assurer que le travail SQL n'est lancé qu'une fois que la base de donnéesrelationnelle compatible cluster est disponible, ajoutez une dépendance à partir dela ressource de cluster de la base de données relationnelle à la ressource de clusterTivoli Workload Scheduler.

Démarrage et arrêt de Tivoli Workload Scheduler

Les méthodes suivantes ne peuvent plus être utilisées pour arrêter Tivoli WorkloadScheduler car elles provoqueront une défaillance de la ressource du cluster TivoliWorkload Scheduler :v Conman shut

v Shutdown.cmd

v StartUp.cmd

v Conman start si la ressource ITWSWorkstation est hors ligne.v StartupLwa.cmd

Utilisez les scripts suivants pour arrêter et démarrer Tivoli Workload Scheduler(vous pouvez les renommer si nécessaire) :v ShutDown_clu.cmd

v StartUp_clu.cmd

v ShutdownLwa.cmd

Les scripts ci-dessus seront automatiquement créés sous le répertoire d'installationde Tivoli Workload Scheduler par le programme twsClusterAdm.exe program.

Figure 5. Onglet Dépendances de ressource (Windows Server 2003)


Si vous n'utilisez pas ces scripts, vous devez exécuter les commandes suivantespour arrêter et démarrer les services Tivoli Workload Scheduler.

Arrêter :

cluster res <nom de l'instance de ressource TWS> /offline

Démarrer :

cluster res <nom de l'instance de ressource TWS>/online

Exemples :

Si ITWSWorkstation_DOMAIN_MST_UserR est le nom d'instance de ressource TWS,pour arrêter Tivoli Workload Scheduler vous devez utiliser :cluster res ITWSWorkstation_DOMAIN_MST_UserR /offline

Pour démarrer les services Tivoli Workload Scheduler, vous devez utiliser :cluster res ITWSWorkstation_DOMAIN_MST_UserR /online

où cluster est la commande Windows pour administrer le cluster (exécuté à partirde l'invite de commande Windows).

Nouvelle option locale “cluster instance name”

Une des étapes de l'utilitaire twsClusterAdmin est l'enregistrement du nomd'instance de la ressource de cluster Tivoli Workload Scheduler au sein du fichierlocalopts de l'option locale.

L'agent Tivoli Workload Scheduler utilise la valeur de cette nouvelle option localepour signaler à la ressource de cluster Tivoli Workload Scheduler que l'agent a reçuune commande d'arrêt.

Il est important de changer la valeur de l'option locale cluster instance namechaque fois que le nom d'instance de ressource Tivoli Workload Scheduler estmodifié. Si l'option locale cluster instance name ne pointe pas vers le nomcorrect, la ressource Tivoli Workload Scheduler sera défini sur l'état incident àpartir du moniteur de ressource du cluster. Ne spécifiez pas ce nom en utilisant unjeu de caractères codé sur deux octets (DBCS).

Pour modifier le nom d'instance de ressource Tivoli Workload Scheduler, procédezcomme suit :1. Mettez l'instance de ressource Tivoli Workload Scheduler hors ligne en utilisant

la console Cluster Administrator. Pour vérifier si Tivoli Workload Schedulers'est arrêté correctement, vous pouvez utiliser la console Cluster Administratoret vérifier le statut de l'instance de ressource Tivoli Workload Scheduler. Sil'arrêt de la ressource a échoué vous pouvez chercher la raison de cet échecdans le cluster et dans les journaux Tivoli Workload Scheduler. Voir «Traces», àla page 30 pour plus d'informations sur les fichiers journaux.

2. Modifiez le nom de la ressource en cluster Tivoli Workload Schedulerdirectement à partir de la console Cluster Administrator, comme illustré dansl'exemple ci-après sous Windows Server 2003. Ne spécifiez pas ce nom enutilisant un jeu de caractères codé sur deux octets (DBCS).


3. Ouvrez le fichier localopts à l'aide du bloc-notes. Modifiez la valeur del'option locale cluster instance name. Vérifiez que le nom est le même quecelui que vous aviez spécifié pour la ressource de cluster Tivoli WorkloadScheduler à l'étape 2, à la page 26.

4. Modifiez le nom d'instance de cluster dans les scripts StartUp_clu.cmd etShutDown_clu.cmd.

5. Mettez l'instance de ressource Tivoli Workload Scheduler en ligne en utilisant laconsole Cluster Administrator.

Figure 6. Exemple de groupe de clusters sous Windows Server 2003

Figure 7. Localopts – Bloc-notes


Extension Tivoli Workload Scheduler Cluster AdministratorCette section décrit l'extension Cluster Administrator. Il comprend les sous-sectionssuivantes :v «Présentation de l'extension Cluster Administrator»v «Installation de l'extension Cluster Administrator»

Présentation de l'extension Cluster AdministratorCluster Administrator est un utilitaire système avec une interface utilisateurgraphique qui permet aux administrateurs de gérer les objets de cluster, lamaintenance et de surveiller l'activité du cluster.

L'extension Tivoli Workload Scheduler Cluster Administrator est une bibliothèquede liaison dynamique qui, lorsqu'elle est installée, ajoute à la console ClusterAdministrator une nouvelle feuille de propriétés et une page d'assistant vouspermettant d'afficher et d'éditer les propriétés de ressource Tivoli WorkloadScheduler.

Le graphique affiche le nouvel onglet Paramètres de la page de propriétés vouspermettant de modifier les paramètres de ressource de cluster ITWSWorkstation.

Installation de l'extension Cluster Administrator

Installez ce composant si vous voulez éditer les propriétés directement à partir dela console Cluster Administrator.

Si vous n'installez pas l'extension Cluster Administration, l'onglet Paramètres (voirfigure 8) n'est pas disponible. Pour modifier les paramètres de ressource du clusterITWSWorkstation, vous devrez modifier ces propriétés en utilisant l'utilitairesystème cluster.exe.

Figure 8. Nouvel onglet Paramètres de propriétés


Installez l'extension Cluster Administrator sur un ordinateur où la console ClusterAdministrator sera utilisée.

Procédez comme suit pour installer une nouvelle extension Cluster Administrator :1. Copiez les fichiers ITWSWorkstationEx.dll et ITWSExInst.cmd à partir du

répertoire <TWS_HOME>\cluster dans le répertoire dans lequel vous voulezinstaller l'extension Administrateur. Vous pouvez utiliser le répertoire pardéfaut pour le cluster : \%systemRoot%\cluster.

2. Cliquez deux fois sur ITWSExInst.cmd ou exécutez-le à partir du shell decommandes pour installer l'extension Administrateur.

Désinstallation de Tivoli Workload Scheduler

Les étapes à suivre pour supprimer le produit doivent être lancées à partir dumême noeud que celui précédemment utilisé pour installer Tivoli WorkloadScheduler et les groupes de correctifs consécutifs.

La procédure est la suivante :1. Supprimez manuellement l'instance de ressource personnalisée Tivoli Workload

Scheduler à partir du groupe de clusters. Pour ce faire, vous pouvez utiliser laconsole Cluster Administrator.

2. Désenregistrez éventuellement le type de ressource en utilisant la commande :cluster restype ITWSWorkstation /delete

Ne désenregistrez pas les ressources si des instances sont présentes dansd'autres groupes de clusters.

3. Supprimez éventuellement la bibliothèque de liaison dynamiqueITWSResources.dll à partir du répertoire d'installation (le répertoire par défautest \%systemRoot%\cluster).

4. Exécutez l'utilitaire TwsClusterAdm –uninst. Cet utilitaire supprime les clés deregistre et le services Tivoli Workload Scheduler à partir de noeuds de clusterdifférents du noeud en cours.

Pour supprimer Tivoli Workload Scheduler à partir du noeud en cours, vouspouvez exécuter le programme de désinstallation normale (référez-vous au manuelIBM Tivoli Workload Scheduler - Guide de planification et d'installation).

Identification et résolution des problèmesCette partie du guide vous donne des informations sur l'identification et larésolution des problèmes concernant Tivoli Workload Scheduler dans unenvironnement cluster Windows. Les informations données s'appliquent au moteurTivoli Workload Scheduler et à son installation pour cet environnement. Pour plusd'informations sur l'identification et la résolution des problèmes concernant TivoliWorkload Scheduler, référez-vous au manuel IBM Tivoli Workload SchedulerAdministration and Troubleshooting.

Ce chapitre contient les sections suivantes :v «Traces», à la page 30v «Erreur 1314 de mise en ligne de la ressource et le poste de travail n'effectue pas

de liaison», à la page 30v «L'instance de ressource Tivoli Workload Scheduler signale un statut d'échec ou

les travaux utilisateur Tivoli Workload Scheduler passent à l'état abend», à lapage 31


v «Panneau de rapport Windows avec Jobmon.exe», à la page 31v «Cluster : erreur de validation IP sur Netman stdlist», à la page 32

TracesTivoli Workload Scheduler gère les journaux concernant différentes activités àdifférents emplacements. Voir IBM Tivoli Workload Scheduler Administration andTroubleshooting pour plus d'informations.

Le nouveau module d'activation du cluster se caractérise par deux fichiers de tracedans le répertoire rép_install_TWS\stdlist\traces :

clu_offline.logLorsque la ressource personnalisée Tivoli Workload Scheduler est mise horsligne (chaque fois qu'une reprise en ligne se produit), la ressourcepersonnalisée Tivoli Workload Scheduler lance la ligne de commandeconman pour arrêter et supprimer le lien de l'instance. Dans ce journal,vous pouvez trouver la sortie de la commande.

clu_online.logLorsque la ressource personnalisée Tivoli Workload Scheduler est mise enligne (chaque fois qu'une reprise en ligne se produit), la ressourcepersonnalisée Tivoli Workload Scheduler lance la ligne de commandeconman pour lier le poste de travail à son gestionnaire de domaine. Dansce journal, vous pouvez trouver la sortie de la commande conman link@!@;noask.

Toute action effectuée par la ressource personnalisée Tivoli Workload Scheduler estconsignée au sein du fichier journal du cluster système. Il s'agit d'un fichier appelécluster.log qui se trouve sous le dossier \%systemRoot%\cluster.

Erreur 1314 de mise en ligne de la ressource et le poste detravail n'effectue pas de liaison

Cet incident peut être lié aux droits d'administrateur du cluster. Pour le vérifier :1. Ouvrez le fichier journal du cluster (cluster.log) situé dans le dossier

\%systemRoot%\cluster.2. Recherchez les chaînes contenant ITWSWorkstation. Ce sont les messages

consignés par la ressource personnalisée Tivoli Workload Scheduler.3. Si vous voyez un message comme celui-ci :

<heure> ERR ITWSWorkstation <nom d’instance de ressource>:SubmitTwsCommand: CreateProcessWithLogonW failed <TWS_HOME>\conman.exe>< start;noask> ’1314’

Cela signifie que l'erreur système 1314, Un privilège requis n’est pas détenupar le client s'est produite lors du lancement de la commande conman.

4. Pour résoudre l'incident, vous devez accorder à l'utilisateur de cluster desprivilèges suffisants pour autoriser l'instance de ressource personnalisée àsoumettre le lien de commande Tivoli Workload Scheduler.

Pour résoudre cet incident, ajoutez le droit Remplacement d'un marqueur deniveau du processus au compte administrateur de cluster (il s'agit du nomd'utilisateur que vous avez choisi lorsque vous avez configuré le cluster). Pourajouter ce droit au compte administrateur de cluster, ouvrez Panneau deconfiguration → Outils d'administration → Stratégie de sécurité locale → Stratégieslocales → Attribution des droits utilisateur et ajoutez le compte utilisateur


Administrateur de cluster à la liste de la stratégie de sécurité Remplacer un jetonniveau de processus. Ce droit est nécessaire pour que l'administrateur de clusterpuisse agir en tant qu'utilisateur Tivoli Workload Scheduler. De cette manière, laressource personnalisée Tivoli Workload Scheduler exécutée avec les droits del'utilisateur administrateur de cluster est capable d'arrêter, de démarrer et de lierTivoli Workload Scheduler. Redémarrez les noeuds de cluster pour que cettemodification prenne effet. Cette opération n'est nécessaire que la première fois quevous configurez Tivoli Workload Scheduler pour travailler dans un environnementcluster Windows 2003.

Vous devez réamorcer les noeuds de cluster pour que cette modification prenneeffet.

L'instance de ressource Tivoli Workload Scheduler signale unstatut d'échec ou les travaux utilisateur Tivoli WorkloadScheduler passent à l'état abend

Problème : si vous exécutez plus de trois instances de Tivoli Workload Schedulersur le même noeud avec des travaux en cours d'exécution, vous pouvez obtenir lecomportement suivant :v L'instance de ressource de cluster Tivoli Workload Scheduler a le statut d'échec.

Voir le statut de la ressource sur la console d'administrateur de cluster (figure 6,à la page 27).

v Les travaux d'utilisateur Tivoli Workload Scheduler passent à l'état abend oufail. Dans ce cas, le message d'erreur suivant peut s'afficher dans<TWS_HOME>\stdlist\date\TWSUSERNAME :++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AWSBIJ139E An internal error has occurred. Jobmon was unable to create a+ new desktop on the window station associated with the calling process.+ The error occurred in the following source code file:+ ../../src/jobmon/monutil.c at line: 2454. The error mess+ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++AWSBIJ140E An internal error has occurred. Jobmon was unable to create theWindows process environment to launch jobs. The error occurred in thefollowing source code file: ../../src/jobmon/monutil.c at line: 830.

Le message d'erreur suivant figure dans le fichier <TWS_HOME>\stdlist\logs\date_TWSMERGE.log : 06:00:28 19.05.2006|BATCHMAN:* AWSBHT061E Batchman areçu un enregistrement de boîte aux lettres indiquant que le travailsuivant s’est terminé d’une manière inattendue : Le système n'a plus assezde place dans le segment de mémoire du bureau électronique.06:00:28 19.05.2006|BATCHMAN:*AWSBHT061E Batchman a reçu un enregistrement de boîte aux lettres indiquantque le travail suivants’est terminé d’une manière inattendue :

Le système n’a plus assez de place dans le segment de mémoire dubureau électronique.

Solution : la solution de cet incident comporte un certain nombre d'optionsdifférentes et est décrite dans «Résolution des problèmes de taille de segment demémoire du bureau électronique sur les postes de travail ayant plus de troisagents», à la page 45

Panneau de rapport Windows avec Jobmon.exe

Problème : Après une reprise en ligne du noeud A vers le noeud B, il peut arriverque Jobmon provoque un cliché du processus core avec une erreur de violation de


|

segmentation sur le noeud A. Vous pouvez voir la segmentation une fois le noeudA réinitialisé, ou lors de la connexion avec l'utilisateur Tivoli Workload Scheduler.Cela ne pose pas de problème puisque Tivoli Workload Scheduler sur le noeud Bfonctionne correctement après une deuxième reprise en ligne et Tivoli WorkloadScheduler fonctionne également sur le noeud A.

Cluster : erreur de validation IP sur Netman stdlist

Cet incident survient lorsque la zone du noeud dans une définition de poste detravail est définie en tant qu'adresse IP réelle plutôt qu'en tant que ressource denom de réseau du cluster

Le problème est que la validation IP est effectuée en utilisant l'adresse IP du noeudlorsque Tivoli Workload Scheduler démarre et non pas l'adresse IP des ressourcesfta dans le cluster.

Vous pouvez voir cet avertissement lorsque l'agent parent/enfant est installé surun cluster et qu'il n'y a pas de correspondance entre l'adresse IP réelle détectée àpartir du canal TCP/IP et l'adresse IP déclarée dans la définition du poste detravail (noeud de propriété). Si le noeud de propriété est un nom d'hôte, cela serarésolu en premier (en demandant le DNS).


Chapitre 3. IBM Tivoli Workload Scheduler avec HACMP

Le présent chapitre contient les rubriques suivantes :v «Outil HACMP (High-Availability Cluster Multi-Processing)»v «Présentation des clusters UNIX», à la page 37

Outil HACMP (High-Availability Cluster Multi-Processing)IBM utilise l'outil HACMP (High-Availability Cluster Multi-Processing) pourgénérer des systèmes d'exploitations informatiques sensibles basés sur UNIX.HACMP garantit que les ressources essentielles, par exemple les applications, sontdisponibles pour traitement. HACMP comprend deux composants principaux : HA(High Availability) et CMP (Cluster Multi-Processing).

La création de clusters HACMP a pour objectif principal de fournir unenvironnement à haute disponibilité pour les applications essentielles. Par exemple,un cluster HACMP peut exécuter un programme serveur de base de données pourgérer les applications client. Les clients envoient des requêtes au programmeserveur, qui répond à ces requêtes en accédant à une base de données hébergée surun disque externe partagé.

Dans un cluster HACMP, pour garantir la disponibilité de ces applications, cesapplications sont sous le contrôle de HACMP. HACMP garantit la disponibilité desapplications pour les processus client même en cas d'échec d'un composant dansun cluster. Ainsi, en cas d'échec d'un composant, HACMP déplace l'application (ycompris les ressources nécessaires pour accéder à l'application) sur un autre noeuddu cluster.

Pour plus d'informations, consultez les rubriques suivantes :v «Avantages»v «Composants physiques d'un cluster HACMP», à la page 34

Avantages

HACMP offre les avantages suivants :v Le processus de planification de HACMP et la documentation contiennent des

conseils et astuces sur les meilleures pratiques recommandées pour l'installationet la gestion d'un cluster HACMP à haute disponibilité.

v Lorsque le cluster est opérationnel, HACMP fournit des fonctions desurveillance et de reprise pour toutes les ressources nécessaires à l'application.

v HACMP fournit un ensemble d'outils complet pour la gestion du cluster etgarantit la disponibilité de l'application pour les clients.

Utilisez HACMP pour :v Configurer un environnement HACMP à l'aide de feuilles de travail qui

simplifient la planification et la configuration initiales.v Garantir la haute disponibilité des applications en éliminant les points de

défaillance uniques dans un environnement HACMP.v Utiliser les fonctions de haute disponibilité disponibles dans AIX.v Gérer comment le cluster traite les composants défaillants.


v Sécuriser les communications du cluster.v Configurer la reprise de disque rapide pour les groupes de volumes gérés par

un gestionnaire de volume logique.v Gérer le traitement d'événement dans le cadre d'un environnement HACMP.v Surveiller les composants HACMP et diagnostiquer les problèmes potentiels.

Composants physiques d'un cluster HACMP

HACMP offre un environnement à haute disponibilité en identifiant un ensemblede ressources essentielles à un traitement ininterrompu et en définissant unprotocole utilisé par les noeuds pour collaborer en vue de garantir la disponibilitéde ces ressources. HACMP étend le modèle de groupement en définissant lesrelations entre les processeurs qui coopèrent de sorte qu'un processeur fournisse leservice offert par un homologue, lorsque cet homologue n'est pas en mesure de lefaire.

Un cluster HACMP est constitué des composants physiques suivants :v «Noeuds», à la page 35v «Unités de disque externes partagées», à la page 36v «Réseaux», à la page 36v «Clients», à la page 36

HACMP vous permet de combiner des composants physiques en une large gammede configurations de cluster, offrant ainsi une plus grande flexibilité dans lagénération d'un cluster répondant à vos besoins de traitement. La figure 9, à lapage 35 affiche un exemple de cluster HACMP. D'autres clusters HACMP peuventavoir une apparence différente, en fonction du nombre de processeurs, du choixdes technologies de réseau et de disque, etc.


Noeuds

Les noeuds constituent le coeur d'un cluster HACMP. Un noeud est un processeurqui exécute à la fois AIX et HACMP. HACMP prend en charge les systèmesmonoprocesseur et les systèmes multiprocesseur symétriques (SMP) pSeries, ainsique les systèmes SP (POWERParallel Processor) en tant que noeuds de cluster.Pour HACMP, un système SMP ressemble à un monoprocesseur. Les systèmes SMPoffrent une solution économique pour augmenter la capacité de traitement ducluster. Chaque noeud du cluster peut être une grosse machine SMP, qui étend uncluster HACMP au-delà des limites d'un système unique et permet ainsi à desmilliers de clients de se connecter à une même base de données.

Dans un cluster HACMP, il peut y avoir jusqu'à 32 ordinateurs ou noeuds quicoopèrent pour fournir un ensemble de services ou de ressources à d'autres clientsà distance. Le groupement de ces serveurs pour sauvegarder des applicationscritiques constitue une solution économique de haute disponibilité. Une entreprisepeut davantage tirer parti de sa puissance de calcul pour garantir que sesapplications critiques soient à nouveau fonctionnelles après une brève interruptiondue à une défaillance matérielle ou logicielle.

Disk busses

Shared disk with mirrors

PublicLAN1

PublicLAN2

Clients

Nodes

PrivateLAN

Figure 9. Disque partagé avec fonction miroir

Chapitre 3. Tivoli Workload Scheduler avec HACMP 35

Dans un cluster HACMP, chaque noeud est identifié par un nom unique. Unnoeud peut détenir un ensemble de ressources (disques, groupes de volumes,systèmes de fichiers, réseaux, adresses réseau et applications). En principe, unnoeud exécute un serveur ou une application “dorsale” ayant accès aux donnéessur les disques externes partagés.

HACMP prend en charge de 2 à 32 noeuds dans un cluster, en fonction de latechnologie de disque utilisée pour les disques externes partagés. Un noeud decluster HACMP comporte plusieurs couches de composants logiciels.

Unités de disque externes partagées

Chaque noeud doit avoir accès à une ou plusieurs unités de disque externespartagées. Une unité de disque externe partagée est un disque connectéphysiquement à plusieurs noeuds. Le disque partagé stocke les donnéesessentielles, en principe en miroir ou avec une configuration RAID pour laredondance des données. Un noeud de cluster HACMP doit également comporterdes disques internes pour stocker le système d'exploitation et les fichiers binairesde l'application, mais ces disques ne sont pas partagés.

En fonction du type de disque utilisé, HACMP prend en charge deux types d'accèsaux unités de disque externes partagées : accès non simultané et accès simultané.v Dans les environnements à accès non simultané, il n'y a qu'une seule connexion

active à la fois, et le noeud auquel appartient la connexion active est propriétairedu disque. Lorsqu'un noeud échoue, une prise de contrôle du disque intervientlorsque le noeud auquel appartient le disque quitte le cluster et qu'un noeudencore fonctionnel endosse la propriété du disque partagé.

v Dans les environnements à accès simultané, les disques partagés sont connectésde manière active sur plusieurs noeuds à la fois. C'est pourquoi, en cas d'échecd'un noeud, la prise de contrôle du disque n'est pas nécessaire.

Réseaux

En tant que composant indépendant à couches d'AIX, HACMP est conçu pour uneutilisation avec n'importe quel réseau TCP/IP. Les noeuds d'un cluster HACMPutilisent le réseau pour permettre aux clients d'accéder aux noeuds de cluster, pouractiver ces noeuds afin d'échanger des messages de contact, et, dans lesenvironnements à accès simultané, sérialiser l'accès aux données.

HACMP définit deux types de réseaux de communication, caractérisés parl'utilisation d'interfaces de communication par ces réseaux en fonction dusous-système TCP/IP (basé sur TCP/IP), ou des unités de communication baséessur des sous-systèmes non TCP/IP (basés sur l'unité).

Clients

Un client est un processeur pouvant accéder aux noeuds d'un cluster via un réseaulocal. Les clients exécutent chacun une application client ou une applicationfrontale qui interroge l'application serveur en cours d'exécution sur le noeud decluster.

HACMP fournit un environnement à haute disponibilité pour les données critiqueset les applications sur les noeuds de cluster. Notez que HACMP ne rend pas lesclients hautement disponibles. Les clients AIX peuvent utiliser les services Clinfo(Client Information) pour recevoir des notifications sur les événements de cluster.Les services Clinfo fournissent une API qui affiche les informations de statut du


cluster. L'utilitaire /usr/es/sbin/cluster/clstat, un client Clinfo livré avecHACMP, fournit des informations sur toutes les interfaces de service du cluster.

Présentation des clusters UNIXCette section décrit la procédure utilisée pour offrir la haute disponibilité à l'aidede l'outil HACMP (High-Availability Cluster Multi-processing), sur les systèmesd'exploitation AIX, UNIX et Linux pour IBM. Elle comprend les sous-sectionssuivantes :v «Connaissances requises»v «Configurations de secours et de reprise»v «Limites de conception», à la page 40v «Configurations prises en charge», à la page 40

Connaissances requisesPour appréhender les rubriques de cette section, vous devez connaître TivoliWorkload Scheduler et les clusters HACMP :

Tivoli Workload SchedulerPour obtenir une présentation de Tivoli Workload Scheduler, voir TivoliWorkload Scheduler - Guide de planification et et d'installation

Clusters HACMPPour obtenir un guide de démarrage rapide sur les clusters HACMP, voirHigh Availability Cluster Multi-Processing for AIX Version 7.3 dans

http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=/com.ibm.aix.doc/doc/base/aixinformation.htm

Configurations de secours et de repriseIl y a deux types de base de configuration de cluster :

SecoursIl s'agit de la configuration matérielle redondande classique. Un ouplusieurs noeuds de secours sont mis de côté à l'état inactif, en attented'échec d'un serveur principal du cluster. C'est ce que l'on appelle lesecours automatique. A partir de maintenant, nous faisons référence à uneconfiguration active/passive pour désigner un cluster à deux noeuds avecune configuration de secours automatique.

RepriseDans cette configuration, tous les noeuds de cluster traitent une partie dela charge de travail du cluster. Aucun noeud n'est mis de côté en tant quenoeud de secours. Lorsqu'un noeud principal est défaillant, l'un des autresnoeuds prend en charge la charge de travail du noeud défaillant en plusde la charge principale qu'il a déjà. C'est ce que l'on appelle aussi la reprisemutuelle.

En principe, l'implémentation de ces deux configurations implique l'existence deressources partagées. Les disques ou le stockage de masse, tels qu'un réseau destockage (SAN) sont les ressources partagées configurées le plus fréquemment.

Comme indiqué dans la figure 10, à la page 38, le noeud A est le noeud principalet le noeud B est le noeud de secours actuellement à l'état inactif. Bien que lenoeud B soit relié à la ressource de stockage de masse partagée, il n'est pas actif en


|||

||

||||||



fonctionnement normal.

Après la reprise du noeud A par le noeud B, la connexion à la ressource destockage de masse du noeud B est activée, et comme le noeud A n'est pasdisponible, sa connexion à la ressource de stockage de masse est inactive. Voirfigure 11.

En revanche, dans la configuration de reprise suivante, les deux noeuds, noeud Aet noeud B ont accès à la ressource de disque partagé simultanément. Pour lesconfigurations à haute disponibilité de Tivoli Workload Scheduler, cela indique engénéral que la ressource de disque partagé comporte des volumes de système defichiers logique distincts, dont l'accès à chacun d'entre eux s'effectue via un noeud

Figure 10. Configuration active-passive en fonctionnement normal

Figure 11. Reprise sur une configuration active-passive


différent. Voir figure 12.

En fonctionnement normal de ce cluster haute disponibilité à deux noeuds, dansune configuration de reprise, le noeud A FS du système de fichier est accédé parl'application App 1 sur le noeud A, et le noeud B FS du système de fichiers estaccédé par l'application App 2 sur le noeud B. Si l'un de ces noeuds est défaillant,l'autre noeud prend en charge la charge de travail du noeud défaillant. Parexemple, si le noeud A est défaillant, l'application App 1 est redémarrée sur lenoeud B, et le noeud B établit une connexion au noeud A FS du système defichiers. Voir figure 13.

Les configurations de reprise sont plus efficaces que les configurations de secoursavec des ressources matérielles car il n'y a pas de noeuds à l'état de veille. Les

Figure 12. Volumes de système de fichiers logique

Figure 13. Scénario de reprise


performances peuvent toutefois diminuer après la défaillance d'un noeud, enraison de l'augmentation de la charge globale sur les noeuds restants.

Limites de conceptionLes limites de conception suivantes s'appliquent :v «Le gestionnaire de domaine maître»v «Commandes Tivoli Workload Scheduler»v «Statut final sur les travaux en cours d'exécution»

Le gestionnaire de domaine maîtreLe gestionnaire de domaine maître Tivoli Workload Scheduler est pris en chargesur Cluster Virtual Server, mais avec deux restrictions importantes :v Le gestionnaire de domaine maître exécute le flot de travaux final qui crée un

plan pour le jour de production en cours. Ce processus ne peut pas êtreinterrompu. Une interruption pourrait provoquer des problèmes defonctionnement et des interruptions du service de planification. Seule uneprocédure manuelle peut être utilisée pour effectuer une reprise à partir de telsincidents ou interruptions de service. Puisque la reprise en ligne du groupe declusters contenant la ressource Tivoli Workload Scheduler arrête l'agent sur lenoeud en cours et le démarre sur un noeud différent, si la reprise en ligne seproduit lors de l'exécution du flot de travaux final, cela peut être préjudiciable.

v Les utilitaires de ligne de commande Tivoli Workload Scheduler (conman,composer, etc) ne prennent pas en compte le cluster et s'ils sont interrompus (viaune reprise en ligne du groupe de clusters contenant la ressource TivoliWorkload Scheduler), ils peuvent endommager des informations cruciales pourTivoli Workload Scheduler.

Commandes Tivoli Workload SchedulerToute commande Tivoli Workload Scheduler en cours d'exécution lors d'une repriseen ligne n'est pas automatiquement mise hors ligne (contrairement aux processusprincipaux netman, mailman, batchman et jobman) par la ressource de clusterTivoli Workload Scheduler.

Cela s'avère particulièrement problématique si la reprise en ligne se produit lorsd'une soumission ad-hoc. Le travail soumis risque de toujours rester à l'étatADDING.

Lorsque la commande Parcourir le journal des travaux via la ligne de commandeconman est active, la commande de reprise en ligne manuelle ne fonctionne pascorrectement et vous devez fermer toutes les fenêtres lorsque la commande est encours d'exécution.

Statut final sur les travaux en cours d'exécutionSi un travail est en cours d'exécution lors d'une reprise, son état final est ABENDavec un code retour égal à zéro. Car le processus Jobman est incapable derécupérer le véritable état final du travail.

Configurations prises en charge

Cette section décrit l'architecture HACMP que nous avons configurée pourl'environnement de test suivie de descriptions de scénario approfondies.

Pour les scénarios, nous avons défini :v 2 noeuds


|||||||||

v 3 disques partagésv 1 groupe de volumesv 1 serveur d'applicationsv 1 adresse IP de servicev 1 groupe de ressources

Nous avons également configuré le signal de présence sur le disque.

Le serveur d'applications contient la définition des scripts start_tws.sh etstop_tws.sh décrits en détail dans chaque section et qui doivent être créés sur lesdeux noeuds.

Les scripts start_tws.sh et stop_tws.sh sont disponibles dans le répertoireTWSHome/config et doivent être personnalisés en définissant les valeursUTILISATEUR_TWS et REP_BASE_TWS, et également la valeur INFO DB2 sinécessaire. Une fois que vous avez personnalisé les scripts, déplacez-les dans unautre répertoire car toute édition ou tout groupe de correctifs plus récent(e) lesécrase.

La configuration Ethernet que nous avons implémentée est le remplacement del'adresse IP, pour avoir une adresse d'amorçage 1 pour chaque noeud et pour quel'adresse IP de service “remplace” l'adresse active. Dans cette configurationl'adresse d'amorçage du noeud actif n'est plus accessible, donc pour éviter d'avoirdes problèmes lors de l'installation de Tivoli Workload Scheduler, nous avonsconfiguré un alias sur l'interface réseau Ethernet avec la valeur de l'adressed'amorçage même. Avec la configuration d'alias IP, cette étape supplémentaire n'estpas nécessaire.

Les scénarios HACMP suivants sont pris en charge avec Tivoli WorkloadScheduler :v «Scénario : Disque partagé, reprise en ligne passive-active sur un gestionnaire

de domaine maître»v «Disque partagé - Reprises passives-actives sur un agent tolérant aux pannes», à

la page 44v «Changement de gestionnaires de domaine», à la page 44

En guise de scénario supplémentaire, nous pouvons également envisager lapossibilité d'avoir une instance DB2 locale ou distante sur le gestionnaire dedomaine maître.

Scénario : Disque partagé, reprise en ligne passive-active sur ungestionnaire de domaine maître

Ce scénario décrit comment configurer Tivoli Workload Scheduler (versions 8.5.1ou 8.6) et une base de données DB2 distante ou locale de sorte à ce qu'un clusterHACMP puisse gérer la reprise en ligne d'un gestionnaire de domaine maître actif.

Configuration de Tivoli Workload Scheduler et d'une base de donnéesDB2 distante

La procédure suivante montre comment configurer Tivoli Workload Scheduler etune base de données DB2 distante de sorte qu'un noeud passif du cluster à l'état


||||||

|||

de veille puisse assurer la reprise en cas d'échec d'un gestionnaire de domainemaître actif. Pour pouvoir exécuter cette procédure, vous devez avoir configuréHACMP.

Installez Tivoli Workload Scheduler à l'aide d'une des méthodes d'installationdécrites dans Tivoli Workload Scheduler : Guide de planification et d'installation. Lorsde l'installation, vous pouvez effectuer les étapes de configuration suivantes :1. Créez le même utilisateur administrateur TWS et regroupez tous les noeuds du

cluster. Assurez-vous que l'utilisateur possède le même ID sur tous les noeudset pointe vers le même répertoire de base sur le disque partagé où voussouhaitez installer Tivoli Workload Scheduler.Exemple : vous souhaitez créer le groupe nommé twsadm pour tous lesadministrateurs Tivoli Workload Scheduler et l'utilisateur Administrateur TWSnommé twsusr avec l'ID utilisateur 518 et le répertoire de base/cluster/home/twsusr” sur le disque partagé :mkgroup id=518 twsadmmkuser id=518 pgrp=twsadm home=/cluster/home/twsusr twsusrpasswd twsusr

Pour installer Tivoli Workload Scheduler dans un autre répertoire que lerépertoire de base de l'utilisateur sur le disque partagé, vous devez vérifier quela structure de répertoire est la même sur tous les noeuds et que le fichieruseropts est disponible sur tous les noeuds. Dans ce cas, assurez-vouségalement que l'utilisateur possède le même ID sur tous les noeuds du cluster.

2. Démarrez le noeud que vous voulez utiliser pour exécuter l'installation deTivoli Workload Scheduler et définissez les paramètres de sorte que HACMPeffectue le montage automatique du disque partagé.

3. Installez le client d'administration DB2 sur les deux noeuds ou sur un disquepartagé en le configurant en vue d'une reprise comme indiqué dans ladocumentation DB2.

4. Créez l'instance db2inst1 sur le noeud actif pour créer un lien direct entreTivoli Workload Scheduler et le serveur DB2 distant.

5. Continuez avec l'installation de Tivoli Workload Scheduler, à l'aide de twsuseren tant que répertoire de base et de l'instance db2inst1 locale.

Après avoir installé Tivoli Workload Scheduler, vous devez exécuter l'outil decollecte de cluster pour collecter automatiquement des fichiers du gestionnaire dedomaine maître actif. Ces fichiers comprennent les fichiers de registre, le catalogueSoftware Distribution et les bibliothèques externes Tivoli Workload Scheduler.L'outil de collecte de cluster crée un fichier .tar contenant les fichiers collectés.Pour copier ces fichiers sur les noeuds passifs, vous devez extraire ce fichier .tardans ces fichiers.

Pour configurer Tivoli Workload Scheduler pour HACMP, procédez comme suit :1. Exécutez l'outil de collecte de cluster2. A partir du répertoire TWA_home/TWS/bin, exécutez ./twsClusterCollector.sh

-collect -tarFileName nomFichierTar

où nomFichierTar est le chemin absolu dans lequel est stockée l'archive.3. Copiez <rép_principal_tws>/useropts_twsuser du noeud actif vers le

gestionnaire de domaine maître passif à partir du répertoire principal et durépertoire de base de l'utilisateur, vers les autres noeuds.

4. Remplacez le nom d'hôte du noeud avec l'adresse IP de service pour : lesdéfinitions du gestionnaire de domaine maître, WebSphere Application Server


||||

||||

|||

|||||

|||

|

|

||

|

|||

||

, Dynamic Workload Broker et l'agent dynamique, comme décrit dans le Guided'administration, section Changing the workstation host name or IP address(Modification du nom d'hôte du poste de travail ou de l'adresse IP).

5. Copiez les scripts start_tws.sh et stop_tws.sh à partir du répertoireTWA_home/TWS/config dans le répertoire TWA_home.

6. Personnalisez les scripts start_tws.sh et stop_tws.sh en spécifiant les valeurspour les variables MAESTRO_USER et MHOME.

7. Essayez les scripts start_tws.sh et stop_tws.sh pour vérifier que TivoliWorkload Scheduler démarre et s'arrête correctement.

8. Déplacez le volume partagé sur le second noeud de cluster (si vous avez déjàdéfini le groupe de clusters, vous pouvez le déplacer à l'aide de la commandeclRGmove HACMP).

9. Exécuter l'outil de collecte pour extraire les bibliothèques Tivoli WorkloadScheduler. A partir du répertoire TWA_home/TWS/bin, exécutez :./twsClusterCollector.sh -deploy -tarFileName nomFichierTar

où nomFichierTar est le chemin absolu dans lequel est stockée l'archive.10. Configurez une nouvelle ressource de contrôleur d'application (Application

Controller) sur HACMP à l'aide des scripts personnalisés start_tws.sh etstop_tws.sh.

Lorsqu'ils sont invoqués par HACMP durant la reprise en ligne, les scriptsdémarrent ou arrêtent automatiquement WebSphere Application Server et TivoliWorkload Scheduler, et associent ou dissocient tous les postes de travail.

DB2 local

Ce scénario s'appuie sur toutes les étapes décrites dans «Configuration de TivoliWorkload Scheduler et d'une base de données DB2 distante», à la page 41 maisvous devez effectuer des étapes supplémentaires.1. Installez DB2 en local sur les noeuds et sur le disque partagé, sans créer une

nouvelle instance.2. Créez une instance sur le disque partagé, définissez tous les utilisateurs DB2

également sur le second noeud, et modifiez les deux fichiers suivants :v /etc/hosts.equiv

Ajoutez une nouvelle ligne contenant uniquement la valeur de l'adresse IPdu service

v <rép_principal_instance_db2>/sqllib/db2nodes.cfg

Ajoutez une nouvelle ligne similaire à celle-ci :0 <Adresse IP du service> 0

Dans ce scénario, personnalisez les scripts start_tws.sh et stop_tws.sh endéfinissant la valeur de DB2_INST_USER de sorte à l'utiliser pour exécuter laphase de démarrage ou d'arrêt de l'instance DB2 lors de la “reprise en ligne”.

La seule différence réside dans le processus monman utilisé pour la fonction EventDriven Workload Automation, de sorte qu'il existe une étape supplémentaire dansle script start_tws.sh ou stop_tws.sh pour démarrer ou arrêter ce service. DansTivoli Workload Scheduler versions 8.5.1 et 8.6, figurent les étapes supplémentairesrelatives à l'arrêt et au démarrage de l'agent dynamique.


|||

||

||

||

|||

||

|

|

|||

awsadchgwshostorip.htm

awsadchgwshostorip.htm

Disque partagé - Reprises passives-actives sur un agent tolérantaux pannes

Ce scénario est pratiquement le même que «Scénario : Disque partagé, reprise enligne passive-active sur un gestionnaire de domaine maître», à la page 41, maissans aucune étape supplémentaire à effectuer sur DB2 et WebSphere ApplicationServer. Les scripts start_tws.sh et top_tws.sh exécutent seulement les commandeslink/unlink et les commandes de démarrage et d'arrêt.

Changement de gestionnaires de domaine

Dans ce scénario, la base de données DB2 est installée sur un serveur distant et leclient d'administration DB2 est installé sur les deux noeuds à la fois. Laconfiguration est basée sur un modèle d'installation sur le premier noeud et sur unmodèle de sauvegarde sur le second noeud. Les deux noeuds sont connectés aumême serveur distant DB2.

Dans ce scénario, des étapes de post-installation sont nécessaires. Le scriptstop_tws.sh peut rester vide et start_tws.sh peut être créé à partir deTWA_home/TWS/config/switch_tws.sh. Il doit être personnalisé avec

le nom d'utilisateur Tivoli Workload Scheduler, le nom d'utilisateur DB2 et le motde passe, et le nom d'alias de base de données Tivoli Workload Scheduler. Le scriptstart_tws.sh exécute la commande de changement de gestionnaire et, en étapesupplémentaire, modifie la définition du poste de travail sur DB2, de sorte àfaciliter la prise en charge d'un changement allant au-delà d'un jour de production.


|||

|||||

Annexe. Résolution des problèmes de taille de segment demémoire du bureau électronique sur les postes de travailayant plus de trois agents

Cette annexe décrit comment résoudre le problème lorsque les limitations de lataille du segment de mémoire du bureau électronique Windows entraînent deséchecs de processus lorsqu'il y a plus de trois instances de Tivoli WorkloadScheduler installées sur un poste de travail dans un environnement clusterWindows 2003.

Utilisez cette description que vous vouliez éviter que cet incident se produise(avant l'installation de la quatrième instance d'agent) ou qu'un incident ait étécausé par cette limitation.

Cette section comporte les rubriques suivantes :v «Description du problème»v «Solutions», à la page 46v «Implémentation des solutions», à la page 48

Description du problème

Le problème se produit à cause de la façon dont Windows traite le segment demémoire du bureau électronique et de la façon dont Tivoli Workload Schedulercrée les bureaux électroniques. Dans le contexte de sécurité, un bureau électroniqueest utilisé pour encapsuler les processus Windows en empêchant les processusd'exécuter des activités non autorisées.

Le volume total de mémoire disponible pour la création de bureaux électroniquesest déterminé par une entrée du registre Windows appelée :HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory Managment\SessionViewSize

La valeur par défaut est 20 Mo.

La part de cette mémoire tampon pour chaque bureau électronique est déterminéepar une entrée du registre Windows appelée :HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows

Par exemple, la valeur de cette entrée pourrait être :%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16

Dans cette entrée, après le mot clé SharedSection, il y a trois entrées de mémoireséparées par des virgules (en ko) :

Mémoire commune (première entrée)Définit la taille du segment de mémoire partagé commune à tous lesbureaux électroniques (1024 dans l'exemple).


Mémoire du bureau électronique interactive (seconde entrée)Définit la mémoire du segment de mémoire du bureau électroniquesupplémentaire attribuée à chaque traitement interactif (3072 dansl'exemple). Par exemple, le processus qui est en avant-plan pour le moment.Trois processus interactifs sont normalement exécutés à tout moment.

Mémoire du bureau électronique non-interactive (troisième entrée)Définit la mémoire du bureau électronique supplémentaire attribuée auxprocessus non-interactifs (512 dans l'exemple). Par exemple, tout processusexécuté en arrière-plan.

Les processus Tivoli Workload Scheduler utilisent les bureaux électroniques de lamanière suivante :

Service Windows Tivoli NetmanCrée un bureau électronique non interactif partagé entre tous les agentsexécutés sur l'ordinateur physique.

Service Windows Tivoli Token ServiceCrée un bureau électronique non interactif pour l'utilisateur TWS dechaque agent.

Service Tivoli Workload Scheduler WindowsCrée un bureau électronique non interactif pour l'utilisateur TWS dechaque agent.

Gestionnaire de travaux (jobmon.exe)Crée un bureau électronique non interactif pour tous les travaux lancés parchaque agent.

Pour chaque agent supplémentaire, trois bureaux électroniques non interactifsseront donc créés. Cet incident se produit lorsque Windows utilise toute lamémoire pour créer des bureaux électroniques.

Solutions

Pour réduire le risque qu'un processus Tivoli Workload Scheduler ne trouve pasassez de mémoire pour créer un bureau électronique, appliquez une ou plusieursdes mesures suivantes :v «Modifier les tailles de la mémoire tampon du segment de mémoire partagé»v «Configurer le service Tivoli Workload Scheduler Windows pour qu'il démarre

comme un compte système local.», à la page 47v «Personnaliser le nom du bureau électronique pour pouvoir le réutiliser», à la

page 47

Modifier les tailles de la mémoire tampon du segment demémoire partagé

Si vous réduisez la taille de la mémoire commune ou de la mémoire interactive,vous laissez plus de mémoire disponible pour les bureaux électroniques noninteractifs. Cependant, une réduction de la taille de l'une de ces deux mémoirespourrait entraîner des problèmes de performances. Microsoft définit ces valeurs pardéfaut parce que ses tests démontrent que ce sont les valeurs requises. Il n'est pasrecommandé de modifier ces valeurs.


La réduction de la mémoire utilisée pour un bureau électronique non interactifpermettra de créer plus de bureaux électroniques. Certains processus qui ontbesoin de plus de mémoire pourraient en être affectés, mais la plupart desprocessus s'exécuteront avec succès. Si votre mémoire du bureau électronique noninteractif par défaut (la troisième entrée) est de 512, essayez de la réduire à 256.Voir «Modifier les entrées du registre Windows qui déterminent la taille desegment de mémoire.», à la page 48 pour savoir comment faire.

Configurer le service Tivoli Workload Scheduler Windowspour qu'il démarre comme un compte système local.

Par défaut, le service Tivoli Workload Scheduler Windows est configuré pourl'utilisateur TWS de chaque agent. Si vous le modifiez pour qu'il démarre commeun compte système local, une seule instance du bureau électronique est créée surl'ordinateur et non une par agent. La solution est mise en oeuvre comme suit :v Pour les agents installés avec la version 8.6 ou ultérieure, ce changement est

obtenu à l'aide du paramètre d'installation facultatif –sharedDesktop.v Pour les agents installés avec des versions antérieures ou pour les agents déjà

installés, effectuez le changement manuellement. Voir «Modifier la configurationdu service Windows», à la page 48 pour savoir comment faire.

Personnaliser le nom du bureau électronique pour pouvoir leréutiliser

Lorsque Jobmon ouvre un bureau électronique, il attribue un nom unique aubureau électronique, afin qu'un bureau électronique différent soit créé pour chaqueagent. Cependant, s'il crée le bureau électronique en utilisant le nom d'un bureauélectronique déjà ouvert, ce processus s'ouvrira à l'intérieur du bureau électroniqueexistant. Pour éviter cette situation, vous devez personnaliser le nom utilisé parJobmon lorsqu'il crée son bureau électronique. Si vous utilisez le même nom pourtous les agents, chaque instance de Jobmon s'ouvre dans le même bureauélectronique.

Pour que cette option s'applique bien, le nom fourni doit être le même pour aumoins deux des agents installés. Plus il y a d'agents exécutés avec le même bureauélectronique partagé, plus il y aura de mémoire disponible pour la création debureaux électroniques. Cependant, si trop d'agents utilisent le même bureauélectronique partagé, il pourrait y avoir une incidence sur la capacité de Windowsà gérer correctement les travaux exécutés dans le bureau électronique partagé.Dans ce cas, vous aurez intérêt à trouver un compromis. Par exemple, si vousaviez quatre agents installés sur le même ordinateur, vous pourriez décider quechaque paire d'agents partage le même bureau électronique.

La solution est mise en oeuvre comme suit :v Pour les agents installés avec la version 8.6 ou ultérieur, ce changement est

obtenu à l'aide du paramètre d'installation facultatif –sharedDesktop. Si vousajoutez cette option sans argument, l'installation applique le nom par défautTWS_JOBS_WINSTA. Sinon, indiquez le nom de votre choix, par exemple,–sharedDesktop name="mon nom de bureau windows".Voir «Commande twsClusterAdm avec exemples d'utilisation», à la page 13 poursavoir comment faire.

Annexe. Résolution des problèmes de taille de segment de mémoire du bureau électronique sur les postes de travail 47

v Pour les agents installés avec des versions antérieures ou pour les agents déjàinstallés, effectuez le changement manuellement. Voir «Modifier localopts pourfournir un nom de bureau électronique partagé», à la page 49 pour savoircomment faire.

Implémentation des solutions

Il y a plusieurs solutions possibles. Choisissez celle correspondant le mieux à votresituation :v «Modifier la configuration du service Windows»v «Modifier les entrées du registre Windows qui déterminent la taille de segment

de mémoire.»v «Modifier localopts pour fournir un nom de bureau électronique partagé», à la

page 49

Modifier la configuration du service Windows

Pour modifier le service Tivoli Workload Scheduler Windows afin qu'il s'ouvrecomme un compte local, procédez comme suit :1. A partir du menu du bouton Démarrer, sélectionnez le panneau Services (par

exemple, sélectionnez Tous les programmes → Outils d'administration →Services).

2. Sélectionnez le service Tivoli Workload Scheduler et cliquez deux fois pourl'éditer.

3. Sélectionnez l'onglet Connexion

4. Cliquez sur Compte système local, puis sur Appliquer.5. Cliquez avec le bouton droit de la souris sur le service et sélectionnez Arrêter.6. Une fois le service arrêté, cliquez de nouveau dessus avec le bouton droit de la

souris et sélectionnez Démarrer

7. Vérifiez que le service a démarré correctement et fermez la fenêtre Services.

Modifier les entrées du registre Windows qui déterminent lataille de segment de mémoire.

Pour modifier les entrées du registre Windows qui déterminent la taille dusegment de mémoire, exécutez regedit.exe et modifiez la clé :HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows

Les données par défaut pour cette valeur de registre ressembleront à ce qui suit(tout sur une ligne) :%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16

Les valeurs numériques qui suivent SharedSection= contrôlent la manière dont lesegment de mémoire du bureau est affecté. Ces valeurs SharedSection sontspécifiées en kilooctets. Voir «Description du problème», à la page 45 pour unedescription des valeurs.


La troisième valeur SharedSection (512 dans l'exemple de ci-dessus) est la taille dusegment de mémoire du bureau électronique pour chaque bureau électronique noninteractif. Réduisez la valeur à 256 kilooctets.

Remarque : Une diminution de l'une des valeurs SharedSection augmentera lenombre de bureaux électroniques qui peuvent être créés dans lespostes Windows correspondants. Des valeurs plus petites limiteront lenombre de points d'ancrage, de menus, de chaînes et de fenêtres quipeuvent être créés au sein du bureau. En revanche, une augmentationdes valeurs SharedSection réduira le nombre de bureaux électroniquesqui peuvent être créés, mais augmentera le nombre de pointsd'ancrage, de menus, de chaînes et de fenêtre qui peuvent être créés àl'intérieur d'un bureau électronique. Cette modification ne prend effetque lorsque vous réamorcez les noeuds de cluster.

Modifier localopts pour fournir un nom de bureau électroniquepartagé

Pour utiliser un nom de bureau électronique partagé pour un agent déjà installé,procédez comme suit :1. Ouvrez le fichier localopts pour l'agent concerné (voir Tivoli Workload Scheduler

- Guide de planification et d'installation pour l'emplacement de ce fichier).2. Ajoutez la clé jm windows station name = <mon_nom>. Vérifiez que <mon_nom>

est le même nom que celui utilisé dans un autre agent pour enregistrer lamémoire du bureau électronique.

3. Enregistrez le fichier.4. Arrêtez et redémarrez Tivoli Workload Scheduler pour rendre la modification

effective.

Annexe. Résolution des problèmes de taille de segment de mémoire du bureau électronique sur les postes de travail 49


Remarques

Le présent document peut contenir des informations ou des références concernantcertains produits, logiciels ou services IBM non annoncés dans ce pays. Pour plusde détails, référez-vous aux documents d'annonce disponibles dans votre pays, ouadressez-vous à votre partenaire commercial IBM. Toute référence à un produit,logiciel ou service IBM n'implique pas que seul ce produit, logiciel ou service IBMpuisse être utilisé. Tout autre élément fonctionnellement équivalent peut êtreutilisé, s'il n'enfreint aucun droit d'IBM. Il est de la responsabilité de l'utilisateurd'évaluer et de vérifier lui-même les installations et applications réalisées avec desproduits, logiciels ou services non expressément référencés par IBM.

IBM peut détenir des brevets ou des demandes de brevet couvrant les produitsmentionnés dans le présent document. La remise de ce document ne vous donneaucun droit de licence sur ces brevets ou demandes de brevet. Si vous désirezrecevoir des informations concernant l'acquisition de licences, veuillez en faire lademande par écrit à l'adresse suivante :

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785 U.S.A.

Pour le Canada, veuillez adresser votre courrier à :

IBM Director of Commercial RelationsIBM Canada Ltd3600 Steeles Avenue EastMarkham, OntarioL3R 9Z7 Canada

Les informations sur les licences concernant les produits utilisant un jeu decaractères double octet peuvent être obtenues par écrit auprès d'IBM à l'adressesuivante :

IBM World Trade Asia CorporationLicensing2-31 Roppongi 3-chome, Minato-kuTokyo 106, Japon

Le paragraphe suivant ne s'applique ni au Royaume-Uni, ni dans aucun paysdans lequel il serait contraire aux lois locales :

LE PRESENT DOCUMENT EST LIVRE "EN L'ETAT" SANS AUCUNE GARANTIEEXPLICITE OU IMPLICITE. IBM DECLINE NOTAMMENT TOUTERESPONSABILITE RELATIVE A CES INFORMATIONS EN CAS DECONTREFACON AINSI QU'EN CAS DE DEFAUT D'APTITUDE A L'EXECUTIOND'UN TRAVAIL DONNE.

Certaines juridictions n'autorisent pas l'exclusion des garanties implicites ouexplicites, auquel cas l'exclusion ci-dessus ne vous sera pas applicable.


Le présent document peut contenir des inexactitudes ou des coquilles. Cedocument est mis à jour périodiquement. Chaque nouvelle édition inclut les misesà jour. IBM peut, à tout moment et sans préavis, modifier les produits et logicielsdécrits dans ce document.

Les références à des sites Web non IBM sont fournies à titre d'informationuniquement et n'impliquent en aucun cas une adhésion aux données qu'ilscontiennent. Les éléments figurant sur ces sites Web ne font pas partie deséléments du présent produit IBM et l'utilisation de ces sites relève de votre seuleresponsabilité.

IBM pourra utiliser ou diffuser, de toute manière qu'elle jugera appropriée et sansaucune obligation de sa part, tout ou partie des informations qui lui serontfournies.

Les licenciés souhaitant obtenir des informations permettant : (i) l'échange desdonnées entre des logiciels créés de façon indépendante et d'autres logiciels (dontcelui-ci), et (ii) l'utilisation mutuelle des données ainsi échangées, doivent adresserleur demande à :

IBM Corporation2Z4A/10111400 Burnet RoadAustin, TX 78758Etats-Unis

Ces informations peuvent être soumises à des conditions particulières, prévoyantnotamment le paiement d'une redevance.

Le logiciel sous licence décrit dans ce publication et tous les éléments sous licencedisponibles s'y rapportant sont fournis par IBM conformément aux dispositions del'accord client IBM (ICA), des Conditions internationales d'utilisation des logicielsIBM ou de tout autre accord équivalent.

Les informations concernant des produits non IBM ont été obtenues auprès desfournisseurs de ces produits, par l'intermédiaire d'annonces publiques ou viad'autres sources disponibles. IBM n'a pas testé ces produits et ne peut confirmerl'exactitude de leurs performances ni leur compatibilité. Elle ne peut recevoiraucune réclamation concernant des produits non IBM. Toute question concernantles performances de produits non IBM doit être adressée aux fournisseurs de cesproduits.

Le présent document peut contenir des exemples de données et de rapports utiliséscouramment dans l'environnement professionnel. Ces exemples mentionnent desnoms fictifs de personnes, de sociétés, de marques ou de produits à des finsillustratives ou explicatives uniquement. Toute ressemblance avec des noms depersonnes, de sociétés ou des données réelles serait purement fortuite.

Marques

IBM, le logo IBM et ibm.com sont des marques commerciales ou déposéesd'International Business Machines Corporation aux Etats-unis et/ou dans certainspays. Si ces marques ou d'autres marques d'IBM sont marquées sur leur premièreoccurrence dans ces informations par un symbole de marque (® ou ™), cessymboles indiquent des marques de droit commun américaines \ appartenant à


IBM au moment de la publication de ces informations. Ces marques peuvent aussiêtre des marques enregistrées ou de droit commun dans d'autres pays. Une listedes marques d'IBM est disponible sur le Web sur "Informations sur le copyright etles marques" à l'adresse suivante : http://www.ibm.com/legal/copytrade.shtml

Adobe et toutes les marques incluant Adobe sont des marques d'Adobe SystemsIncorporated aux Etats-Unis et/ou dans certains autres pays.

Microsoft et Windows sont des marques de Microsoft Corporation aux Etats-Uniset/ou dans certains autres pays.

Les autres noms de sociétés, de produits et de services peuvent appartenir à destiers.

Remarques 53

http://www.ibm.com/legal/copytrade.shtml


Index

Caractèresspéciaux–ask, argument twsClusterAdm.exe 18–changeResName, paramètre

twsClusterAdm.exe 18–dll, paramètre twsClusterAdm.exe 17–force, argument twsClusterAdm.exe 18–force, paramètre twsClusterAdm.exe 17–new, paramètre twsClusterAdm.exe 15–notwsinst, paramètre

twsClusterAdm.exe 17–res, paramètre twsClusterAdm.exe 15–sharedDesktop, paramètre

twsClusterAdm.exe 17–twsupd, argument

twsClusterAdm.exe 18–uninst, paramètre

twsClusterAdm.exe 18–update, paramètre

twsClusterAdm.exe 18

Aaccessibilité xaction de reprise en cas de reprise en

ligneautorisation 1

action de reprise ou d'annulationautorisation 1

adresse IP 24agent, installation dans une configuration

compatible cluster 10agent Tivoli Workload Scheduler

installationdans une configuration compatible

cluster 10mise à niveau

dans une configuration compatiblecluster 12

arguments, dans twsClusterAdm.exe 15ask, argument twsClusterAdm.exe 18

Bbibliothèque de liaison dynamique

bibliothèque de liaison dynamique deressources personnalisée 6

bibliothèque de liaison dynamique deressources personnalisée 6

points d'entréeIsAlive 6Offline 6Online 6Terminate 7

CchangeResName, paramètre

twsClusterAdm.exe 18check_interval, argument

twsClusterAdm.exe 16cliché du processus core 31clu_offline.log 30clu_online.log 30cluster instance name

modificationdans le fichier localopts 27dans le script

ShutDown_clu.cmd 27dans le script StartUp_clu.cmd 27

option locale 26cluster.log 30clusters Windows 2003

où trouver des informations 3commandes

cluster res 26ShutDown_clu.cmd 25Shutdown.cmd 11StartUp_clu.cmd 25tws_env.cmd 11twsClusterAdm.exe 13twsClusterAdmin.exe, option

locale 26compatibilité

avec des versions précédentes 4configuration 37configuration requise 9Conman shut 25Conman start 25console Cluster Administrator,

utilisation 26contenu, Windows 2003 Cluster

Enabler 7conventions utilisées dans les

publications x

Dde reprise 37dépendances de ressource du cluster 24

adresse IP 24disque physique 24nom de réseau 24

disk, argument twsClusterAdm.exe 15disque physique 24dll, paramètre twsClusterAdm.exe 17domain, argument

twsClusterAdm.exe 15, 18Dynamic Workload Console

accessibilité x

Eerreur 1314 30état abend 31

exemplestwsClusterAdm.exe 19

extension Cluster Administratorinstallation 28présentation 28

Onglet Paramètres 28

Ffailover, argument

twsClusterAdm.exe 15fichier localopts

modification 27fichiers de trace 30

clu_offline.log 30clu_online.log 30cluster.log 30

fichiers DLLITWSResources.dll 7ITWSWorkstationEx.dll 7

force, argument twsClusterAdm.exe 18force, paramètre twsClusterAdm.exe 17formation x

technique x

Ggestionnaire de domaine de secours

Tivoli Workload Scheduler 1gestionnaire de domaine maître 40

non pris en charge sur Cluster VirtualServer

raisons 4glossaire xgroup, argument twsClusterAdm.exe 15

Hhaute disponibilité

définition 1types de 1

hosts, argument twsClusterAdm.exe 15,18

Iidentification et résolution des

problèmes 29erreur 1314 30état abend 31fichiers de trace 30Jobmon

cliché du processus core 31installation

agent Tivoli Workload Scheduler 10configuration requise 9extension Cluster Administrator 28installation dans un cluster 7Windows Cluster Enabler 7


installation dans un cluster 7ip, argument twsClusterAdm.exe 15Isalive, argument twsClusterAdm.exe 16ITWSExInst.cmd 7ITWSResources.dll 7ITWSWorkstationEx.dll 7

JJob Scheduling Console

accessibilité x

Llookalive, argument


Mmanuels xmise à niveau 12

agent Tivoli Workload Scheduler 12

Nname, argument twsClusterAdm.exe 17net, argument twsClusterAdm.exe 15new, paramètre twsClusterAdm.exe 15nom d'instance de ressource

modification 26nom de réseau 24nom_instance_ressource, argument

twsClusterAdm.exe 19nom_nouvelle_instance_ressource,

argument twsClusterAdm.exe 19notwsinst, paramètre


Oonglet Paramètres

extension Cluster Administrator 28opts, argument twsClusterAdm.exe 16

Pparamètres, dans twsClusterAdm.exe 15path, argument twsClusterAdm.exe 17pwd, argument twsClusterAdm.exe 15

Rremplacement d'un niveau du processus

stratégie de sécurité 30remplacer un jeton de niveau de

processusstratégie de sécurité 9

res, paramètre twsClusterAdm.exe 15resname, argument

twsClusterAdm.exe 15resource, argument


Sscripts

ShutDown_clu.cmd 25StartUp_clu.cmd 25

sharedDesktop, paramètretwsClusterAdm.exe 17

ShutDown_clu.cmd 25Shutdown.cmd 11, 25ShutdownLwa.cmd 25StartUp_clu.cmd 25StartUp.cmd 25StartupLwa.cmd 25stratégie de sécurité

remplacement d'un niveau duprocessus 9, 30

syntaxetwsClusterAdm.exe 14

systèmes d'exploitation 4

Ttcpport, argument

twsClusterAdm.exe 16technique, formation xTivoli, formation technique xTivoli Workload Scheduler 36, 37, 40

action de reprise en cas de reprise enligne 1

action de reprise ou d'annulation 1arrêt 25

commande cluster res 26authentification de sécurité 5autorisation 5avantages 33clients 36compatibilité

avec des versions précédentes 4composants physiques 34configuration

avec twsClusterAdm 13de ligne de commande

non automatiquement mis horsligne lors d'une reprise enligne 4, 40

de secours 37démarrage 25

commande cluster res 26dépendances de ressource du

cluster 24désinstallation 29disque externe partagé 36en environnements cluster

Windows 24environnement cluster

intégration à 3extension Cluster Administrator 28

installation 28présentation 28

gestionnaire de domaine desecours 1

gestionnaire de domaine maître 40non pris en charge sur Cluster

Virtual Server 4HACMP 33, 34, 35identification et résolution des

problèmes 29

Tivoli Workload Scheduler (suite)cliché du processus core 31erreur 1314 30état abend 31fichiers de trace 30

intégration àenvironnement cluster 3

limites de conception du produit 3,40

noeuds 35nom d'instance de ressource

modification 26où trouver des informations 3, 37rendre compatible cluster 11réseaux 36Unix 33Windows 3Windows 2003 Cluster Enabler 5

composants 5configuration requise 4

tolérance aux pannesdéfinition 1

tws_env.cmd 11twsClusterAdm

agent Tivoli Workload Scheduler 13twsClusterAdm.exe 7, 11, 13

arguments 15exemples 19paramètres 15syntaxe 14

twsClusterAdmin.execluster instance name

option locale 26twshome, argument

twsClusterAdm.exe 15twsupd, argument


Uuninst, paramètre

twsClusterAdm.exe 18Unix 33UNIX

où trouver des informations 37update, paramètre

twsClusterAdm.exe 18utilisateur, argument

twsClusterAdm.exe 15, 18utilitaire

Shutdown.cmd 11

WWindows 3Windows 2003 Cluster Enabler

composants 5contenu 7

Windows 2003 et 2008 Cluster Enablercontenu

ITWSExInst.cmd 7ITWSResources.dll 7ITWSWorkstationEx.dll 7twsClusterAdm.exe 7


Windows Cluster Enablercomposants

bibliothèque de liaison dynamiquede ressources personnalisée 6

configuration requise 9installation 7installation dans un cluster 7

Index 57


��

Numéro de programme : 5698-WSH

SC11-2858-04

Spineinformation:

Wor

kloa

dSc

hedu

ler

Vers

ion

8.6

IBM

Tivo

liW

orkl

oad

Sche

dule

r-En

viro

nnem

ents

clus

terà

haut

edi

spon

ibili

té��

�

Documents

Environnements cluster à haute disponibilité · Table des matières Figures .....v Avis aux lecteurs canadiens .....vii A propos de cette édition .....ix Nouveautés de cette version