Entornos en clúster de alta disponibilidad - ibm.com · Información de soporte .....viii...

Workload SchedulerVersión 8.6

Entornos en clúster de altadisponibilidad

SC11-3450-04

��

NotaAntes de utilizar esta información y el producto al que da soporte, lea la información incluida en el apartado Avisos.

Esta edición se aplica a la versión 8, release 6 de IBM Tivoli Workload Scheduler (número de programa 5698-WSH)y a los siguientes releases y modificaciones hasta que se indique lo contrario en nuevas ediciones.

Esta edición sustituye a SC11-3450-03.

© Copyright IBM Corporation 1999, 2011.

Contenido

Figuras . . . . . . . . . . . . . . . v

Acerca de esta publicación . . . . . . viiNovedades de este release . . . . . . . . . viiNovedades en este release sobre el soporte declúster . . . . . . . . . . . . . . . . viiNovedades de esta publicación. . . . . . . . viiA quién va dirigida esta publicación . . . . . . viiPublicaciones . . . . . . . . . . . . . viiiAccesibilidad . . . . . . . . . . . . . viiiFormación técnica de Tivoli. . . . . . . . . viiiInformación de soporte . . . . . . . . . . viii

Capítulo 1. Tipos de alta disponibilidad 1Disponibilidad de agente frente a disponibilidad detrabajo . . . . . . . . . . . . . . . . 1Escenario de HACMP para AIX - Gestor de dominiode reserva . . . . . . . . . . . . . . . 2

Capítulo 2. Tivoli Workload Schedulercon clúster de Windows. . . . . . . . 3Visión global del clústeres de Windows . . . . . 3

Tivoli Workload Scheduler con entornos en clústerde Microsoft Windows . . . . . . . . . . 3Conocimientos sobre requisitos previos . . . . 3Limitaciones del diseño. . . . . . . . . . 4Sistemas operativos con soporte . . . . . . . 4Compatibilidad, actualización y coexistencia . . . 4Seguridad y autenticación . . . . . . . . . 5

Tivoli Workload Scheduler Windows Cluster Enabler 5Componentes . . . . . . . . . . . . . 5Instalación y configuración . . . . . . . . 7Aplicación de un fix pack o actualización a unanueva versión del habilitador de clústeres . . . 12Mandato twsClusterAdm con ejemplos de uso . 13Funcionamiento de Tivoli Workload Scheduler enentorno en clúster Windows . . . . . . . . 24Ampliación del Administrador de clústeres deTivoli Workload Scheduler . . . . . . . . 28Desinstalación de Tivoli Workload Scheduler . . 29

Resolución de problemas . . . . . . . . . . 29Rastreos . . . . . . . . . . . . . . 30Error 1314 al poner en línea el recurso y laestación de trabajo no tiene enlace . . . . . . 30La instancia de recursos de Tivoli WorkloadScheduler informa de un estado de anomalía olos trabajos del usuario de Tivoli WorkloadScheduler pasan al estado abend (terminaciónanómala) . . . . . . . . . . . . . . 31

Panel de informe de Windows con Jobmon.exe 31Clúster: Error de validación de IP en Netmanstdlist . . . . . . . . . . . . . . . 32

Capítulo 3. IBM Tivoli WorkloadScheduler con HACMP . . . . . . . . 33Multiproceso de clúster de alta disponibilidad . . . 33

Ventajas . . . . . . . . . . . . . . 33Componentes físicos de un clúster HACMP . . 34

Visión global del clústeres de UNIX . . . . . . 37Conocimientos sobre requisitos previos . . . . 37Configuraciones de espera y toma de control . . 37Limitaciones del diseño . . . . . . . . . 40Configuraciones con soporte. . . . . . . . 40

Apéndice. Resolución de problemas detamaño de almacenamiento dinámicode escritorio en estaciones de trabajocon más de tres agentes . . . . . . . 45Descripción del problema. . . . . . . . . . 45Soluciones . . . . . . . . . . . . . . . 46

Modifique los tamaños de almacenamientointermedio de almacenamiento dinámicocompartido . . . . . . . . . . . . . 46Configure el servicio Tivoli Workload Schedulerde Windows para que se inicie como una cuentadel sistema local . . . . . . . . . . . . 47Personalice el nombre del escritorio para que sepueda reutilizar . . . . . . . . . . . . 47

Implementación de las soluciones . . . . . . . 48Modifique la configuración del servicio deWindows . . . . . . . . . . . . . . 48Modifique las entradas del registro de Windowspara determinar el tamaño de almacenamientodinámico . . . . . . . . . . . . . . 48Modifique localopts para suministrar un nombrede escritorio compartido . . . . . . . . . 49

Avisos . . . . . . . . . . . . . . . 51Marcas registradas . . . . . . . . . . . . 52

Índice . . . . . . . . . . . . . . . 55

© Copyright IBM Corp. 1999, 2011 iii

|

iv IBM Tivoli Workload Scheduler: Entornos en clúster de alta disponibilidad

Figuras

1. Componentes principales de Tivoli WorkloadScheduler Cluster Enabler . . . . . . . . 6

2. Instalación en un clúster . . . . . . . . 83. Clústeres en una red de Tivoli Workload

Scheduler . . . . . . . . . . . . . 84. Ejemplo de agrupación de clústeres en

Windows Server 2003 . . . . . . . . . 125. Pestaña Dependencias de recursos (Windows

Server 2003) . . . . . . . . . . . . 256. Ejemplo de agrupación de clústeres en

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

7. Localopts – Bloc de notas . . . . . . . . 278. Separador Nuevos parámetros de propiedades 289. Disco compartido con duplicación (mirror) 35

10. Configuración activa-pasiva en funcionamientonormal . . . . . . . . . . . . . . 38

11. Migración tras error en una configuraciónactiva-pasiva . . . . . . . . . . . . 38

12. Volúmenes del sistema de archivos lógico 3913. Escenario de migración tras error . . . . . 39

© Copyright IBM Corp. 1999, 2011 v

|||||

vi IBM Tivoli Workload Scheduler: Entornos en clúster de alta disponibilidad

Acerca de esta publicación

En esta publicación se describe cómo los clústeres de Windows y HACMP paraAIX encajan en la topología de IBM® Tivoli Workload Scheduler. En estapublicación también se describen en Tivoli Workload Scheduler para dar soporte alentorno de clúster y de alta disponibilidad basado en Microsoft Windows.

Novedades de este release

Para obtener información sobre las funciones nuevas o modificadas de este release,consulte el manual Tivoli Workload Automation: Visión general.

Para obtener información sobre los APAR que soluciona este release, consulteTivoli Workload Scheduler Download Document en http://www.ibm.com/support/docview.wss?rs=672&uid=swg24027501.

Novedades en este release sobre el soporte de clúster

Se ha añadido lo siguiente al soporte de Tivoli Workload Scheduler para entornosde clúster y de alta disponibilidad en Microsoft Windows 2003 y Windows Server2008:v Soporte para Windows Server 2008.v Dos opciones nuevas genéricas para permitir la supervisión del agente de

planificación dinámica y el Gestor de trabajos.v Una llamada a un script nuevo de parada e inicio de Tivoli Workload Scheduler.

Novedades de esta publicación

En esta publicación se ha añadido o modificado la siguiente información:v Se ha añadido el soporte para HACMP para AIX en todo el manual.v Se ha eliminado el apartado sobre disponibilidad del agente y del servidor.

A quién va dirigida esta publicación

Esta publicación está pensada para la siguiente audiencia:v Personas que trabajen con Tivoli Workload Scheduler en un entorno en clúster

de Windows 2003 y 2008.v Personas que trabajen con Tivoli Workload Scheduler en un entorno en clúster

en UNIX y Linux.v Administradores de IT o administradores de IT de Tivoli Workload Scheduler

que planifiquen el diseño de la red de Tivoli Workload Scheduler.v Instaladores encargados de instalar los distintos paquetes de software que

forman la red de Tivoli Workload Scheduler.

© Copyright IBM Corp. 1999, 2011 vii

||||

|

|

|

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

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

Publicaciones

Encontrará más detalles sobre las publicaciones de Tivoli Workload Automation enTivoli Workload Automation: Publications. Este documento también contieneinformación sobre los convenios utilizados en las publicaciones.

Encontrará un glosario de términos del producto en Tivoli Workload Automation:Glossary.

Ambos están en el centro de información como distintas publicaciones.

Accesibilidad

Las funciones de accesibilidad son de ayuda para que los usuarios que padecenuna discapacidad física, como por ejemplo una movilidad o una visión limitadas,puedan utilizar satisfactoriamente los productos de software. Con este producto sepueden utilizar tecnologías de asistencia para oír y navegar por la interfaz.También se puede utilizar el teclado en lugar del ratón para usar todas lasfunciones de la interfaz gráfica de usuario.

Para obtener más información sobre Job Scheduling Console, consulte el apéndicesobre accesibilidad del manual Tivoli Workload Scheduler: Job Scheduling Console: Guíadel usuario.

Para obtener más información sobre Consola de carga de trabajo dinámica,consulte el apéndice sobre accesibilidad del manual Tivoli Workload Scheduler: Guíadel usuario y de consulta.

Formación técnica de Tivoli

Para obtener información sobre la formación técnica de Tivoli, consulte el siguientesitio web de formación de IBM Tivoli:

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

Información de soporte

Si tiene algún problema con el software de IBM, deseará resolverlo rápidamente.IBM brinda los medios siguientes para que obtenga el soporte que necesita:v Búsqueda en bases de conocimiento: puede realizar una búsqueda entre una

amplia recopilación de problemas conocidos y soluciones posibles, notas técnicas(Technotes) y otra información.

v Obtención de arreglos: Puede localizar los últimos arreglos que ya estándisponibles para el producto.

v Cómo contactar con el Centro de Soporte de software de IBM: Si todavía nopuede resolver su problema y necesita trabajar con alguien de IBM, puedeutilizar diversas maneras de ponerse en contacto con el Centro de soporte desoftware de IBM.

Para obtener más información sobre estos tres métodos de resolver problemas,consulte el apéndice sobre información de soporte del manual Tivoli WorkloadScheduler: Troubleshooting Guide.

viii IBM Tivoli Workload Scheduler: Entornos en clúster de alta disponibilidad

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

Capítulo 1. Tipos de alta disponibilidad

Los clústeres de servidor se han diseñado para conservar disponibles los recursos(como por ejemplo compartimiento de archivos, discos y aplicaciones). Ladisponibilidad es una medida de la posibilidad que tienen los clientes deconectarse y utilizar un recurso. Si un recurso no está disponible, los clientes no lopueden utilizar.

Es posible comparar la disponibilidad elevada con la tolerancia a errores, comoconjuntos de procedimientos distintos para medir la disponibilidad:

Tolerancia a erroresLa tolerancia a errores se define como un 100% de disponibilidad durantetodo el tiempo. Los sistemas con tolerancia a errores se han diseñado paragarantizar la disponibilidad de los recursos.

Alta disponibilidadUn sistema de disponibilidad elevada aumenta al máximo ladisponibilidad de los recursos. Un recurso altamente disponible estarádisponible en un porcentaje elevado de tiempo, cercano al 100%, pero esaceptable y previsible un porcentaje pequeño de tiempo de inactividad.

De esta forma, la disponibilidad elevada se puede definir como un recursoaltamente disponible que casi siempre está operativo y accesible a los clientes.

La sección explica el tipo siguiente de alta disponibilidad: “Escenario de HACMPpara AIX - Gestor de dominio de reserva” en la página 2

Disponibilidad de agente frente a disponibilidad de trabajoSi Tivoli Workload Scheduler está funcionado en un clúster de Windows y losentornos de HACMP para AIX no quiere decir que los trabajos que lance elplanificador tengan conocimiento automático de la existencia del clúster. No formaparte de la responsabilidad de Tivoli Workload Scheduler retrotraer ninguna de lasacciones que pudiera haber realizado un trabajo durante el tiempo en que seejecutó. Es responsabilidad del usuario crear el script o mandato que permita unaacción de retrotracción o de recuperación en caso de migración tras error.

Para una migración tras error, el agente de Tivoli Workload Scheduler informa detodos los trabajos que se estén ejecutando en ese momento en estado ABEND conel código de retorno RC=0. Así se evita que se liberen otras dependencias.Solamente es posible una recuperación (o volver a ejecutar) de los trabajos quepresentan anomalías.

En general, Tivoli Workload Scheduler no gestiona trabajos ni la interrupción desecuencias de trabajos. El usuario debe añadir más lógica para recuperar un trabajoe interrupciones de secuencias de trabajos (consulte las secciones 1.4.2 y 2.3.4 delRedbook High Availability Scenarios with IBM Tivoli Workload Scheduler and IBMTivoli Framework).

© Copyright IBM Corp. 1999, 2011 1

||

Escenario de HACMP para AIX - Gestor de dominio de reservaTivoli Workload Scheduler proporciona un grado de disponibilidad elevada graciasa la función del gestor de dominio de reserva el cual también se puedeimplementar como gestor de dominio maestro de reserva.

El gestor de dominio de reserva duplica los cambios efectuados en el plan deproducción del gestor de dominio. Cuando se detecta una anomalía, se emite elmandato switchmgr en todas las estaciones de trabajo del dominio en el servidordel gestor de dominio, haciendo que las estaciones de trabajo reconozcan el gestorde dominio de reserva.

Sin embargo, hay casos en que un entorno en clúster representa una alternativaadecuada:v La dificultad de implementar un conmutador de responsabilidad de dominios

automáticov La dificultad de pasar al gestor de dominio de reserva trabajos que se deberían

ejecutar en el gestor de dominiov La necesidad de notificar el paso de un gestor de dominio a la red de Tivoli

Workload Schedulerv Un producto de disponibilidad elevada solventa muchos de los problemas de

codificación que están relacionados con la detección de anomalías de hardwarev La implementación de la disponibilidad elevada para agentes con tolerancia a

errores (agentes ampliados y agentes estándar) no se puede llevar a caboutilizando la función del gestor de dominio de reserva

2 IBM Tivoli Workload Scheduler: Entornos en clúster de alta disponibilidad

|

Capítulo 2. Tivoli Workload Scheduler con clúster deWindows

En esta sección hay información sobre los temas siguientes:v “Visión global del clústeres de Windows”v “Tivoli Workload Scheduler Windows Cluster Enabler” en la página 5v “Resolución de problemas” en la página 29

Visión global del clústeres de WindowsEn esta sección se describe cómo encajan los clústeres de Windows en la topologíade Tivoli Workload Scheduler. Se ha dividido en las subsecciones siguientes:v “Tivoli Workload Scheduler con entornos en clúster de Microsoft Windows”v “Conocimientos sobre requisitos previos”v “Limitaciones del diseño” en la página 4v “Sistemas operativos con soporte” en la página 4v “Compatibilidad, actualización y coexistencia” en la página 4v “Seguridad y autenticación” en la página 5

Tivoli Workload Scheduler con entornos en clúster deMicrosoft Windows

Tivoli Workload Scheduler se puede integrar en entornos en clúster de Windowsusando recursos de clúster genéricos de Microsoft. En este documento se describecómo se consigue.

Para ayudarle a realizar esta integración, el producto proporciona:v Un programa de utilidad que configura de forma remota Tivoli Workload

Scheduler en todos los nodos del clúster sin volver a instalar Tivoli WorkloadScheduler en cada nodo. El programa de utilidad implementa la lógica paradefinir e instalar el recurso personalizado de Tivoli Workload Scheduler dentrode un grupo de clústeres.

v Una nueva DLL de recursos personalizados específicamente para TivoliWorkload Scheduler.

Conocimientos sobre requisitos previosPara comprender los problemas que se tratan en este documento, debe estarfamiliarizado con clústeres Tivoli Workload Scheduler y de Microsoft Windows:

Tivoli Workload SchedulerPara ver una visión general de Tivoli Workload Scheduler, consulte elmanual Tivoli Workload Scheduler: Guía de planificación e instalación

Clústeres de Microsoft WindowsPara ver una guía de inicio rápido sobre clústeres de servidor y obtenerinformación sobre Windows Clustering Services, vaya al sitio web deMicrosoft Windows Server TechNet.


Limitaciones del diseñoSe aplican las siguientes limitaciones del diseño:v “El gestor de dominio maestro”v “Mandatos de Tivoli Workload Scheduler”v “Utilización con varios agentes”

El gestor de dominio maestroEl gestor de dominio maestro de Tivoli Workload Scheduler no tiene soporte comorecurso de clúster por los motivos siguientes:v El gestor de dominio maestro ejecuta la secuencia de trabajos críticos JnextPlan.

La responsabilidad de la secuencia de trabajos es crear un plan nuevo para eldía de producción en curso. Este proceso no se puede interrumpir. Unainterrupción podría causar un malfuncionamiento e interrupciones en el serviciode planificación. Solamente se pueden realizar pasos manuales para recuperaralgunos problemas de malfuncionamiento o interrupciones del servicio. Puestoque la migración tras error del grupo de clústeres que contiene el recurso deTivoli Workload Scheduler detiene el agente del nodo actual y lo inicia en unnodo distinto, si la migración tras error se produce mientras se ejecuta JnextPlanpodría resultar destructiva.

v Los programas de utilidad de línea de mandatos de Tivoli Workload Scheduler(conman, composer, etcétera) no detectan el clúster y si se interrumpen(mediante una migración tras error del grupo de clústeres que contiene elrecurso de Tivoli Workload Scheduler) podrían dañar cierta información vitalpara Tivoli Workload Scheduler.

Mandatos de Tivoli Workload SchedulerEl recurso de clústeres de Tivoli Workload Scheduler no pone automáticamentefuera de línea ningún mandato de Tivoli Workload Scheduler que se estéejecutando cuando se produce una migración tras error (a diferencia de losprocesos principales netman, mailman, batchman y jobman).

Esto puede resultar particularmente problemático si la migración tras error seproduce durante una acción de someter ad-hoc. El trabajo sometido podríapermanecer para siempre en el estado ADDING.

Utilización con varios agentesSi tiene pensado usar varios agentes en el mismo servidor Windows de 32 bits,debe realizar algunos pasos para reconfigurar la memoria de almacenamientodinámico del escritorio de Windows de forma que los distintos procesos de agentescompartan más memoria de almacenamiento dinámico de escritorio. Estos pasos sedescriben en el apartado “Resolución de problemas de tamaño de almacenamientodinámico de escritorio en estaciones de trabajo con más de tres agentes”, en lapágina 45.

Sistemas operativos con soporte

Tivoli Workload Scheduler Windows Cluster Enabler está disponible para sistemasWindows de 32 y de 64 bits.

Compatibilidad, actualización y coexistenciaEl agente de Tivoli Workload Scheduler configurado para que funcione en unentorno en clúster no tiene impacto alguno en la compatibilidad con versionesanteriores de Tivoli Workload Scheduler y no requiere configuración ni migraciónde datos.


|||||||

|

Un agente de Tivoli Workload Scheduler configurado para trabajar en un entornoen clúster de Windows 2003 se puede conectar tanto a una configuracióndistribuida como a una configuración de red de extremo a extremo.

La DLL que amplía el programa Administración de clústeres de Windows seactualiza de vez en cuando en fix packs y nuevos releases de Tivoli WorkloadScheduler. Por este motivo, el programa que instala Windows Cluster Enabler tieneuna opción de actualización que debe utilizar para actualizar la DLL con unanueva versión, menor (fix pack) o mayor (nuevo release de Tivoli WorkloadScheduler).

Seguridad y autenticación

Se aplican los mecanismos típicos de autenticación de seguridad y autorización deTivoli Workload Scheduler.

Tivoli Workload Scheduler Windows Cluster Enabler

En esta sección se describe la implementación de Windows Cluster Enabler. Constade las subsecciones siguientes:v “Componentes”v “Instalación y configuración” en la página 7v “Aplicación de un fix pack o actualización a una nueva versión del habilitador

de clústeres” en la página 12v “Mandato twsClusterAdm con ejemplos de uso” en la página 13v “Funcionamiento de Tivoli Workload Scheduler en entorno en clúster Windows”

en la página 24v “Desinstalación de Tivoli Workload Scheduler” en la página 29

Componentes

Tivoli Workload Scheduler Windows Cluster Enabler consta de los elementossiguientes:v Un programa de utilidad para:

– Instalar y configurar de forma remota Tivoli Workload Scheduler en todos losdemás nodos del clúster

– Instalar y configurar el tipo de recurso de clúster de Tivoli WorkloadScheduler para un determinado servidor virtual

v Un tipo de recurso personalizado del gestor de Tivoli Workload Scheduler paragestionar sucesos de clúster para instancias de IBM Tivoli Workload Scheduler(nuevas DLL)

v Una DLL de ampliación de Tivoli Workload Scheduler para ampliar el programaAdministración de clústeres de Windows

Capítulo 2. Tivoli Workload Scheduler con clúster de Windows 5

El componente principal es la DLL de recursos personalizados. Ofrece lascaracterísticas siguientes:v Se puede poner en línea y fuera de líneav Se puede gestionar en un clústerv Solamente un nodo cada vez puede alojarla (poseerla)

Tal como ilustra la Figura 1, el servicio de clúster se comunica con una DLL derecursos personalizados mediante el supervisor de recursos para gestionarrecursos. Como respuesta a una solicitud del servicio de clúster, el supervisor derecursos llama a la correspondiente función de punto de entrada de la DLL derecursos personalizados para comprobar y controlar el estado de los recursos(posiblemente el agente de Tivoli Workload Scheduler).

La DLL de recursos personalizados bien efectúa la operación, bien señala elsupervisor de recursos para aplicar el proceso predeterminado (si lo hay), o ambascosas. La DLL de recursos personalizados es responsable de proporcionarimplementaciones de punto de entrada que cubren las necesidades de los recursosde Tivoli Workload Scheduler.

La DLL de recursos personalizados del gestor de Tivoli Workload Schedulerproporciona los siguientes puntos de entrada (o servicios):

IsAliveDetermina si el agente de Tivoli Workload Scheduler está activo en estosmomentos.

OfflineConcluye de manera ordenada el agente de Tivoli Workload Scheduler.

OnlineInicia el agente de Tivoli Workload Scheduler, enlaza el agente a la red ydeja los recursos disponibles para el clúster.

Figura 1. Componentes principales de Tivoli Workload Scheduler Cluster Enabler


|

|||

TerminateConcluye el recurso de forma inmediata.

La DLL de recursos personalizados del gestor de Tivoli Workload Scheduler es unpuente entre el supervisor de recursos (parte del servicio de clúster Windows) y elagente de Tivoli Workload Scheduler. El objetivo más importante de la DLL derecursos personalizados es comprender el estado del agente y ponerlo en línea ofuera de línea utilizando la secuencia de mandatos correcta.

Instalación y configuración

Esta sección describe la instalación y la configuración de Windows Cluster Enabler.Se ha dividido en las subsecciones siguientes:v “Windows Cluster Enabler”v “Instalación en un clúster”v “Requisitos previos” en la página 9v “Instalación y configuración de un nuevo agente de Tivoli Workload Scheduler”

en la página 10

Tivoli Workload Scheduler Windows Cluster Enabler lo insala automáticamenteTivoli Workload Scheduler versiones 8.6. Se crea una carpeta nueva, de nombrecluster, se crea dentro del directorio de instalación de Tivoli Workload Scheduler.

Windows Cluster Enabler

Tivoli Workload Scheduler Windows Cluster Enabler contiene los archivossiguientes:

ITWSWorkstationEx.dllLa ampliación del Administrador de clústeres de Tivoli WorkloadScheduler. Añade en la consola del Administrador de clústeres una nuevahoja de propiedad y páginas del asistente para el tipo de recurso de TivoliWorkload Scheduler. Consulte el apartado “Ampliación del Administradorde clústeres de Tivoli Workload Scheduler” en la página 28 para obtenermás detalles.

twsClusterAdm.exeUtilizado para instalar y configurar Tivoli Workload Scheduler.

ITWSResources.dllLa biblioteca de enlace dinámico que contiene la implementación de la APIde recursos para el tipo de recurso ITWSWorkstation de Tivoli WorkloadScheduler. Implemente la lógica que permite que el Supervisor de recursossupervise y gestione al agente de Tivoli Workload Scheduler

ITWSExInst.cmdEl script de ejemplo que registra la ampliación del Administrador declústeres de Tivoli Workload Scheduler.

Instalación en un clúster

Una configuración de clúster mínima está compuesta por dos nodos. Enconformidad con la tecnología de disco utilizada, un clúster de Windows puedetener de 2 a 36 nodos.


||||

En cada nodo se ejecuta uno, más de uno o ninguno de los grupos de recursos declúster. En el caso de anomalía, por ejemplo, del nodo A todos los grupos derecursos de clúster asociados al nodo que presenta la anomalía se sustituirán por elnodo B. De este modo, B ejecuta todas las aplicaciones con detección de clústerque se ejecutaban en A

Para que Tivoli Workload Scheduler funcione en un entorno en clúster se puede:v Instalar el agente de Tivoli Workload Scheduler de forma local en el disco duro

de uno de los nodos si tiene que realizar alguna planificación solamente en esenodo de clúster (como un solo sistema). Así funciona como una instalaciónnormal. No es necesaria ninguna función para detectar clústeres.

v Instalar el agente de Tivoli Workload Scheduler en uno o varios servidoresvirtuales si tiene que planificar trabajos en ese servidor virtual. Es necesaria unafunción para detectar clústeres.

Figura 2. Instalación en un clúster

Figura 3. Clústeres en una red de Tivoli Workload Scheduler


|

|||

Un servidor virtual es un grupo que contiene un recurso de nombre de red, unrecurso de dirección IP y recursos adicionales necesarios para ejecutar una o másaplicaciones o servicios. Los clientes pueden utilizar el nombre de red para accedera los recursos del grupo, igual que utilizan un nombre de sistema para acceder alos servicios de un servidor físico. Sin embargo, puesto que un servidor virtual esun grupo, se puede migrar tras error a otro nodo sin que ello afecte al nombre o ala dirección subyacentes.

Para configurar Tivoli Workload Scheduler de forma que funcione en un entornoen clúster de Windows, es necesario que cree un servidor virtual, que lo añada aun tipo de recurso de disco físico y que instale de Tivoli Workload Scheduler endicho disco.

El nuevo tipo de recursos de clúster creado para gestionar un agente de TivoliWorkload Scheduler concluirá el agente de manera ordenada y lo iniciará duranteuna migración tras error.

Requisitos previos

A continuación se encuentran los requisitos previos para la correcta configuraciónde IBM Tivoli Workload Scheduler en el clúster:

Windows Cluster ServerDebe existir un servidor de clústeres de Windows completamenteconfigurado y en ejecución.

Un grupo de servidores virtuales del clúster configurado.El grupo de servidores virtuales del clúster es un grupo que contiene almenos el recurso de dirección IP virtual, el recurso de nombre de red y elrecurso de disco físico. El grupo de servidores virtuales del clúster puedecontener otros recursos de aplicaciones, no solamente los de IBM TivoliWorkload Scheduler.

Para crear el servidor virtual del clúster puede utilizar la consola delAdministrador de clústeres. Tiene que hacer lo siguiente:v Crear el grupo Clústerv Añadir el disco compartido al grupo Clúster que ha creadov Añadir el recurso de IP y crear la dependencia del discov Añadir el recurso de red y crear la dependencia del recurso de IP

Consulte la documentación de Windows para obtener más información.

Un usuario administrador de dominiosUn usuario administrador de dominios listo para su utilización (el usuariodebe pertenecer al grupo Administrador de todos los nodos del clúster) ysu contraseña.

Un usuario de dominiosEspecifique un usuario de dominios como usuario de IBM Tivoli WorkloadScheduler durante la instalación. Si no se especifica un dominio válido, secreará de forma predeterminada un usuario local.

Otorgar derechos de acceso al administrador de clústeresVerifique que la cuenta del administrador del clúster disponga delsiguiente derecho: Sustitución de una señal de nivel de proceso. Paraañadir este derecho a la cuenta del administrador del clúster abra Panel decontrol → Herramientas administrativas → Directiva de seguridad local →Directivas locales → Asignación de derechos de usuario y añada la cuentade usuario administrador del clúster en la lista de directivas de seguridad


Sustitución de una señal de nivel de proceso. Este derecho es necesariopara poder habilitar el administrador del clúster de forma que actúe comousuario de Tivoli Workload Scheduler. De esta forma, el recursopersonalizado de Tivoli Workload Scheduler, que se ejecuta con lospermisos del usuario administrador del clúster, podrá detener, iniciar yenlazar Tivoli Workload Scheduler. Reinicie los nodos del clúster para queel cambio entre en vigor. Esta operación solamente es necesaria la primeravez que se configura Tivoli Workload Scheduler para que funcione en losentornos de clúster de Windows.

Instalar Microsoft Visual C++ 2005 Redistributable Package (x86) en otros nodosde clúster

Todos los nodos del clúster deben poder dar soporte al uso de C++. Estose consigue en un nodo determinado instalando Microsoft Visual C++ 2005Redistributable Package (x86). La instalación de Tivoli Workload SchedulerCluster Enabler instala este paquete en el nodo en el que se instala elhabilitador, pero para poder conmutar a los otros nodos del clúster, elpaquete debe estar también instalado en los mismos.

Siga este procedimiento:1. Descargue Visual C++ 2005 Redistributable Package (x86) desde

http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en. O vaya a http://www.microsoft.com y busque elpaquete por su nombre. Descargue el archivo del paquete(vcredist_x86.exe)

2. Copie el paquete en cada nodo del grupo de servidores virtuales delclúster:

3. En cada nodo del grupo (que no sea aquel en el que va a instalar elcomponente Cluster Enabler), haga lo siguiente:a. Inicie una sesión como administrador de dominiosb. Ejecute vcredist_x86.exe

Instalación y configuración de un nuevo agente de TivoliWorkload Scheduler

Nota: Durante la instalación del clúster de Tivoli Workload Scheduler 8.6 no sedeben especificar los parámetros siguientes en caracteres DBCS (juego decaracteres de doble byte):v Usuariov Dominio

Para instalar Tivoli Workload Scheduler en una configuración que detecta clústeres,emplee el procedimiento siguiente:1. Instale el agente de Tivoli Workload Scheduler:

a. Seleccione un nodo del clúster. Este nodo se debe utilizar para todas lasoperaciones posteriores (como instalaciones de fixpack).

b. Inicie la sesión en el nodo utilizando un usuario con privilegios deadministrador de dominios.

c. Elija el servidor virtual de Microsoft en el que desee instalar el agente deIBM Tivoli Workload Scheduler.

d. Instale Tivoli Workload Scheduler, versión 8.6:v Especifique un usuario de dominio como usuario para el que desea

instalar Tivoli Workload Scheduler


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



http://www.microsoft.com

v Especifique el disco asociado a ese servidor virtual como directorio dedestino

e. Instale Tivoli Workload Scheduler, versión 8.6.2. Consiga que Tivoli Workload Scheduler detecte clústeres:

a. Ejecute el indicador de mandatos de Windows.b. Vaya al directorio inicial de Tivoli Workload Scheduler (en el disco

compartido).c. Ejecute tws_env.cmd para cargar las variables de entorno de Tivoli Workload

Scheduler.d. Ejecute Shutdown.cmd para detener Tivoli Workload Scheduler.e. Vaya al directorio cluster.f. Ejecute el programa de utilidad twsClusterAdm.exe para configurar Tivoli

Workload Scheduler de forma remota en todos los nodos del clúster y parainstalar el recurso de clústeres de Tivoli Workload Scheduler. Consulte elapartado “Ejemplo 1: Primera instalación de Tivoli Workload Scheduler enun entorno de clúster de Windows” en la página 20 si desea un ejemplo dela instalación.

3. Defina un nuevo objeto de estación de trabajo en el gestor de dominio maestroutilizando composer o la Consola de carga de trabajo dinámica. Verifique queel nombre de nodo especificado lo haya podido resolver DNS y que se puedaemitir un mandato ping de la dirección IP desde el gestor de dominio maestro.Si utiliza una configuración de red de extremo a extremo, deberá especificar ladirección IP que ha especificado para el valor de recursos de clústeres NET/IP.

4. Inicie el recurso de clústeres de Tivoli Workload Scheduler. Desde la consoladel Administrador de clústeres, seleccione el grupo de clústeres (en la Figura 4en la página 12 es el servidor virtual F).

5. Seleccione el tipo de recurso ITWSWorkstation (en la Figura 4 en la página 12el nombre de la instancia es ITWSWorkstation_CLUSTER_SA_DM1), según semuestra en el ejemplo siguiente en Windows Server 2003. Pulse el botónderecho del ratón y seleccione Poner en línea.


6. ITWSWorkstation es el nombre del tipo de recurso personalizado de TivoliWorkload Scheduler. ITWSWorkstation_CLUSTER_SA_DM1 es el nombre de lainstancia. De forma predeterminada, cuando se crea utilizando la línea demandatos twsClusterAdm, el nombre de instancia esITWSWorkstation_<nombre_dominio>_<nombre_usuario>.No utilice caracteres DBCS (juego de caracteres de doble byte) en el nombre dedominio ni en el nombre de usuario.

7. Espere hasta la secuencia de trabajos final o genere un nuevo plan que añadirla nueva estación de trabajo al plan.

Aplicación de un fix pack o actualización a una nueva versióndel habilitador de clústeres

Si ya tiene instalado Tivoli Workload Scheduler versión 8.4 o posterior y elhabilitador de clústeres está instalado, puede aplicar un fix pack o puede actualizarel agente y el habilitador a Tivoli Workload Scheduler, versión 8.6. Siga estospasos:1. Desde la consola del Administrador de clústeres, ponga fuera de línea el

recurso ITWSWorkstation que guarda relación con la instalación que pretendeactualizar.

2. Aplique el fix pack o actualice el agente de Tivoli Workload Scheduler a laversión 8.6.

Figura 4. Ejemplo de agrupación de clústeres en Windows Server 2003


||

|

Consulte el archivo readme del fix pack o el manual Tivoli Workload Scheduler:Guía de planificación e instalación para ver instrucciones y para obtener másinformación.

3. Desde el directorio <TWS_HOME>\cluster, inicie el programa de utilidadtwsclusteradm.exe con la opción –update (twsclusteradm.exe –update).

Nota: Si va a actualizar a una versión mayor, como la versión 8.5, debe utilizartambién la subopción –twsupd (twsclusteradm.exe –update –twsupd)para actualizar el registro de servicios de Windows con el cambio deversión.

4. Desde la consola del Administrador de clústeres ponga el recursoITWSWorkstation en línea.

Consulte el “Ejemplo 10: Actualizar de Tivoli Workload Scheduler versión 8.4 oposterior, habilitado para clústeres” en la página 22 para ver un ejemplo deactualización.

Mandato twsClusterAdm con ejemplos de uso

El mandato twsClusterAdm es el programa de utilidad para configurar TivoliWorkload Scheduler en entornos en clúster de Microsoft Windows.

El mandato twsClusterAdm:v Configura Tivoli Workload Scheduler en todos los nodos del clúster o en un

nuevo nodo de unión de clústeres.v Instala el nuevo tipo de recurso de clúster de Tivoli Workload Scheduler para

una primera instalación. El nombre de este nuevo tipo de recurso de clúster esITWSWorkstation.

v Crea una instancia del tipo de recurso de clúster de Tivoli Workload Schedulerdentro de un grupo de clústeres.

v Elimina la configuración de Tivoli Workload Scheduler de uno o más nodos delclúster.

v Actualiza el tipo de recurso de clústeres de Tivoli Workload Scheduler si hayuna nueva versión disponible.

Funciona en varios pasos para llevar a cabo una instalación que detecta clústeres:v Determina si la configuración se está ejecutando en un entorno en clúster.v Copia la DLL de recursos de Tivoli Workload Scheduler en los nodos del clúster.v Actualiza la modalidad de arranque de servicios de Tivoli Workload Scheduler

de automática a manual.v Instala los servicios de Tivoli Workload Scheduler y la clave de registro en los

otros nodos (puesto que los servicios actuales y la clave de registro se haninstalado con la instalación normal del producto).

v Registra los tipos de recurso de Tivoli Workload Scheduler.v Crea una nueva instancia del recurso de Tivoli Workload Scheduler dentro de un

determinado grupo de clústeres (servidor virtual) y registra el nombre de lainstancia en el archivo localopts.

v Instala la tecnología de inventario común en los otros nodos

Configuración de un gestor de dominio con detección de clúster

Si desea instalar un gestor de dominio en un entorno de clúster, debe especificar laopción link utilizando el parámetro de twsClusterAdm opts (que se describe en el


|

apartado “Sintaxis”). Especifique el dominio padre del gestor de dominio y laestación de trabajo del gestor de dominio padre, de modo que el proceso deinstalación pueda gestionar correctamente el desenlace y reenlace necesarios.Consulte el “Ejemplo 9: Primera instalación del gestor de dominio de un entornode clúster de Windows, especificando opciones genéricas” en la página 22 para verun ejemplo.

Si se omite la opción link o se suministra con valores incorrectos, la configuraciónno terminará correctamente. Sin embargo, no es necesario que repita la instalaciónpara solucionar el problema. En su lugar, vaya al panel de propiedades de lainstancia de recurso de Tivoli Workload Scheduler y, bajo el separador Parámetros,añada el enlace en el campo genericOpts. Cuando active el clúster, se utilizará lainformación de la opción link para completar la configuración.

Sintaxis

twsClusterAdm.exe –newdomain=<dominio_Windows>user=<usuario_TWS>pwd=<contraseña_usuario_TWS>[hosts=<nombrehost1,nombrehost2...>][twshome=<dir_inicial_TWS>][ –res

group=<nombre_grupo_clúster>ip=<nombre_recurso_IP>net=<nombre_recurso_red>disk=<nombre_recurso_disco>[resname=<nombre_instancia_recurso>][check_interval=<intervalo_sondeo_TWS>][failover=yes|no][looksalive=<intervalo_lookalive>][isalive=<intervalo_isalive>][tcpport=<puerto_tcp>][opts=<opciones_genéricas>]

][–notwsinst][–dll

[path=<víaacceso_recurso_DLL>]]

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

twsClusterAdm.exe –uninstdomain=<dominio_Windows>user=<nombre_usuario_TWS>[hosts=< nombrehost1,nombrehost2...>]

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

twsClusterAdm.exe –changeResName"<nombre_instancia_recurso>""<nuevo_nombre_instancia_recurso>"


Parámetros y argumentos–new El parámetro –new configura Tivoli Workload Scheduler en todos los

nodos del clúster o en un nuevo nodo de clúster. Acepta los siguientesargumentos:

Domain=<dominio_Windows>El dominio de usuario de Windows del usuario de Tivoli WorkloadScheduler. Este parámetro es obligatorio si se especifica –new o–uninst. Este parámetro no se debe especificar con caracteres DBCS(juego de caracteres de doble byte).

user=<usuario_TWS>El nombre de usuario Windows del usuario de Tivoli WorkloadScheduler. Este parámetro es obligatorio si se especifica –new o–uninst. Este parámetro no se debe especificar con caracteres DBCS(juego de caracteres de doble byte).

pwd=<contraseña_usuario_TWS>La contraseña de Windows del usuario de Tivoli WorkloadScheduler. Este parámetro es obligatorio si se especifica –new.

hosts=<nombrehost1,nombrehost2...>Los nombres de host de los nodos del clúster en el que deseaconfigurar Tivoli Workload Scheduler. Los nombres de host se hande separar con comas. Este parámetro es opcional. Se puedeutilizar para configurar un nuevo nodo de unión del clúster.

twshome=<directorio_inicial_TWS>El directorio en el que se ha instalado Tivoli Workload Scheduler.Este parámetro es opcional. Si no especifica este directorio, elmandato detectará el directorio de instalación.

–res El parámetro –res añade una nueva instancia del tipo de recurso de TivoliWorkload Scheduler a un grupo de clúster existente. Acepta los siguientesargumentos:

group=<nombre_grupo_clúster>El nombre del grupo (servidor virtual) en el que se ha configuradoTivoli Workload Scheduler como recurso de clúster. Este parámetroes obligatorio.

ip=<nombre_recurso_IP>El nombre del tipo de recurso IP del clúster del cual depende elrecurso de Tivoli Workload Scheduler. Este parámetro esobligatorio.

net=<nombre_recurso_red>El nombre del tipo de recurso de red del cual depende el recursode Tivoli Workload Scheduler. Este parámetro es obligatorio.

disk=<nombre_recurso_disco>El nombre del tipo de recurso de disco del cual depende el recursode IBM Tivoli Workload Scheduler. Este parámetro es obligatorio.

resname=<nombre_instancia_recurso>El nombre de la instancia del recurso, tal como aparece en eladministrador de clúster (consulte la Figura 4 en la página 12). Sino se especifica este parámetro, se utiliza el valor predeterminadode ITWSWorkstation_<nombre_dominio>_<nombre_usuario>.


failover=yes|noSi especifica yes, puede ocurrir que Tivoli Workload Schedulerprovoque la migración tras error del grupo de servidores virtuales.Si no especifica esta opción, Tivoli Workload Scheduler noprovocará la migración tras error del grupo de servidores virtuales.Este parámetro es opcional. Observe que es posible modificar estevalor directamente desde la consola del Administrador declústeres. Si se modifican los valores umbral y período desde elseparador de propiedades de recursos podrá habilitar o inhabilitarla migración automática tras error en el caso que se produjera unaanomalía de recurso. Consulte el manual Windows Cluster Guidepara obtener más información.

check_interval=<intervalo_sondeo_TWS>El intervalo en milisegundos que el recurso de Tivoli WorkloadScheduler espera entre dos comprobaciones de estado. Esteparámetro es opcional. Utilice valores mayores que 60.000. El valorpredeterminado es 100.000. Puede cambiar este valor desde laconsola del Administrador de clústeres: pulse el botón derecho delratón sobre el recurso y seleccione Propiedades → Parámetros.

lookalive=<intervalo_lookalive>El intervalo en milisegundos en que el servicio de clúster realiza elsondeo en el recurso para determinar si parece operativo. Esteparámetro es opcional. Utilice valores mayores que 10.000. El valorpredeterminado es 10.000. Puede cambiar este valor desde laconsola del Administrador de clústeres: pulse el botón derecho delratón sobre el recurso y seleccione Propiedades → Avanzadas.

Isalive=<intervalo_isalive>El intervalo en milisegundos en que el servicio de clúster realiza elsondeo en el recurso para determinar si está operativo. Esteparámetro es opcional. Utilice valores mayores que 10.000. El valorpredeterminado es 60.000. Puede cambiar este valor desde laconsola del Administrador de clústeres: pulse el botón derecho delratón sobre el recurso y seleccione Propiedades → Avanzadas.

tcpport=puerto_tcpEste parámetro está reservado para su uso posterior.

opts=opciones_genéricasLas opciones de recurso genéricas se utilizan para especificar unconjunto de opciones. Cada opción se separa mediante un signo depunto y coma ";". El parámetro opts aceptará las opcionessiguientes:v ftaOff

Utilice esta opción para habilitar la supervisión del agente deplanificación dinámico. Si no se especifica, el comportamientopredeterminado se mantiene sin cambios: sólo se supervisa elagente de tolerancia de fallos.

v lwaOn

Utilice esta opción para habilitar la supervisión del agente deplanificación dinámico y el Gestor de trabajos. Si no seespecifica, el comportamiento predeterminado se mantiene sincambios: sólo se supervisa el agente de tolerancia de fallos.

v killjob


Utilice esta opción para matar todo trabajo (y los hijos deltrabajo) que se esté ejecutando en el momento en que se producela anomalía del recurso.

v link=<dominio_padre>!<gestor_dominio_padre>

Utilice esta opción si está configurando un gestor de dominioque detecta clústeres. Especifique el dominio padre y el gestordel agente que está configurando.Por ejemplo, si está configurando un gestor de dominio que esun hijo del gestor de dominio maestro (llamado MyMasterWS enel dominio MASTERDOM), el valor que debe especificar eslink=MASTERDOM!MyMasterWS.

Las opciones kill y link se pueden utilizar juntas (por ejemplo,opts=killjob;link=MASTERDM!MASTERWS;). Puede cambiar este valordesde la consola del Administrador de clústeres: pulse el botónderecho del ratón sobre el recurso y seleccione Propiedades →Parámetros. Cambie los valores en el campo genericOpts.

–notwsinstEl parámetro –notwsinst especifica opcionalmente que está instalando lainstancia de recurso de clúster para una instancia existente de TivoliWorkload Scheduler.

–dll El parámetro –dll especifica que el archivo ITWSResources.dll queimplementa el nuevo tipo de recurso de Tivoli Workload Scheduler se tieneque instalar. Este parámetro es obligatorio la primera vez que configuraTivoli Workload Scheduler en el clúster o si hay un nuevo nodo que se uneal clúster. Este parámetro acepta un argumento opcional:

[path=<víaacceso_recurso_DLL>]La vía de acceso en la que se debe instalar ITWSResources.dll. Esteparámetro es opcional. Si no especifica la vía de acceso, se utiliza elvalor predeterminado,\%systemRoot%\cluster. No especifique laletra de unidad de la vía de acceso. La vía de acceso especificadadebe existir y debe ser accesible en cada nodo del clúster.

–force El parámetro –force fuerza opcionalmente la instalación del archivo DLLde recurso de Tivoli Workload Scheduler (ITWSResources.dll) sincomprobar la versión. El parámetro se pasa por alto si no ha especificadoel parámetro –dll.

–sharedDesktopEl parámetro –sharedDesktop especifica opcionalmente que Jobmon utilizaun nombre de escritorio compartido para gestionar la asignación dememoria de almacenamiento dinámico de escritorio en el que se instalanvarios agentes en un sistema (consulte el apartado “Resolución deproblemas de tamaño de almacenamiento dinámico de escritorio enestaciones de trabajo con más de tres agentes”, en la página 45 para verdetalles). Utilice el mismo nombre para al menos dos agentes en estesistema para que la opción entre en vigor.

name=<nombre_escritorio>El nombre de escritorio opcional. Si especifica un nombre, debeestar en caracteres de un solo byte (alfabeto inglés) sin caracteresespeciales, excepto espacios, en cuyo caso debe especificarlo entrecomillas dobles. El nombre predeterminado (si no se especifica elargumento name=<nombre_escritorio>) es TWS_JOBS_WINSTA.

–uninst


El parámetro –uninst desinstala la instancia de recurso de clúster y aceptalos siguientes argumentos:

Domain=<dominio_Windows>El dominio de usuario de Windows del usuario de Tivoli WorkloadScheduler. Este parámetro es obligatorio si especifica –new o–uninst. Este parámetro no se debe especificar con caracteres DBCS(juego de caracteres de doble byte).

user=<usuario_TWS>El nombre de usuario Windows del usuario de Tivoli WorkloadScheduler. Este parámetro es obligatorio si especifica –new o–uninst. Este parámetro no se debe especificar con caracteres DBCS(juego de caracteres de doble byte).

hosts=<nombrehost1,nombrehost2...>Los nombres de host de los nodos del clúster del que deseadesinstalar Tivoli Workload Scheduler. Los nombres de host se hande separar con comas. Este parámetro es opcional. Si no seespecifica este parámetro, Tivoli Workload Scheduler sedesinstalará de todos los nodos del clúster salvo del nodo actual.

–update

El parámetro –update actualiza el archivo DLL de recurso de TivoliWorkload Scheduler de una instancia existente y acepta los siguientesargumentos:

resource=<nombre_instancia_recurso>El nombre de la instancia del recurso de Tivoli Workload Schedulertal como aparece en el grupo del clúster. El nombrepredeterminado es ITWSWorkstation_<dominio>_<usuario>. Esteparámetro es obligatorio.

–ask={yes|no}Define si el actualizador debe preguntar antes de reiniciar elarchivo DLL de recurso después de actualizarlo. Especifique yespara determinar que el actualizador debe detenerse y preguntar alsolicitar al operador que confirme que puede reiniciar el archivoDLL de recurso de clúster. El valor predeterminado. Especifique nopara reiniciar automáticamente el archivo DLL de recurso declúster después de actualizarlo, sin intervención manual. Esteparámetro es opcional.

–force Fuerza la instalación de la DLL del recurso de Tivoli WorkloadScheduler (ITWSResources.dll) sin comprobar la versión. Esteparámetro es opcional.

–twsupdDefine si se debe actualizar el registro de servicios de Windowsdespués de actualizar el archivo DLL del recurso. Utilice esteparámetro solo cuando actualice el archivo DLL después deactualizar Tivoli Workload Scheduler a una versión mayor, comopor ejemplo 8.6. Este parámetro es opcional.

–changeResName

El parámetro –changeResName cambia el nombre del recurso de lainstancia de clúster y acepta los siguientes argumentos:

"<nombre_instancia_recurso>"El nombre de la instancia del recurso de Tivoli Workload Scheduler


tal como aparece en el grupo del clúster. El nombrepredeterminado es ITWSWorkstation_<dominio>_<usuario>. Esteargumento es obligatorio para –changeResName.

"<nuevo_nombre_instancia_recurso>"El nuevo nombre que desea utilizar para la instancia del recurso deTivoli Workload Scheduler. Este argumento también es obligatoriopara –changeResName.

Ejemplos

Para todos los ejemplos descritos a continuación, se da por supuesto que se hainstalado Tivoli Workload Scheduler 8.6.

En todos los ejemplos que se describen a continuación se utilizan las siguientesdefiniciones:

mydom Es el dominio de usuario de Windows del usuario de Tivoli WorkloadScheduler.

mytwsuserEs el nombre de usuario de Tivoli Workload Scheduler.

mytwspwdEs la contraseña del usuario de dominio de MYDOM\mytwsuser.

myresgroupEs el nombre del grupo de recursos de clúster seleccionado.

myip Es el nombre del tipo de recurso Dirección IP dentro del grupo de recursosmyresgroup.

mynetnameEs el nombre del tipo de recurso Nombre de red dentro del grupo derecursos myresgroup.

mydisk Es el nombre del tipo de recurso Disco físico dentro del grupo de recursosmyresgroup.

mi escritorio compartidoEs el nombre del escritorio compartido que utilizarán todas las instanciasde jobmon.

myResNameEs el nombre personalizado de la instancia del recurso.

Los ejemplos son los siguientes:v “Ejemplo 1: Primera instalación de Tivoli Workload Scheduler en un entorno de

clúster de Windows” en la página 20v “Ejemplo 2: Instalación y configuración del nuevo recurso personalizado para

una instalación existente de Tivoli Workload Scheduler” en la página 20v “Ejemplo 3: Adición de un nuevo agente en un entorno en clúster con Tivoli

Workload Scheduler ya instalado” en la página 21v “Ejemplo 4: Añadir un tipo de instancia de recurso personalizado a un grupo de

clúster existente” en la página 21v “Ejemplo 5: Configuración de Tivoli Workload Scheduler en un nuevo nodo de

unión del clúster” en la página 21v “Ejemplo 6: Deshacer el registro de Tivoli Workload Scheduler en todos los

nodos del clúster salvo en el nodo actual” en la página 21


v “Ejemplo 7: Instalar una nueva versión de la DLL de recurso del clúster en elclúster” en la página 22

v “Ejemplo 8: Forzar la actualización/descarga de la DLL de recurso del clúster enel clúster” en la página 22

v “Ejemplo 9: Primera instalación del gestor de dominio de un entorno de clústerde Windows, especificando opciones genéricas” en la página 22

v “Ejemplo 10: Actualizar de Tivoli Workload Scheduler versión 8.4 o posterior,habilitado para clústeres” en la página 22

v “Ejemplo 11: Primera instalación de Tivoli Workload Scheduler en un entorno declúster de Windows, definiendo escritorio compartido” en la página 23

v “Ejemplo 12: Primera instalación de Tivoli Workload Scheduler en entorno declúster de Windows, utilizando nombre personalizado de instancia de recurso”en la página 23

v “Ejemplo 13: Cambio del nombre de la instancia de recurso” en la página 23

Ejemplo 1: Primera instalación de Tivoli Workload Scheduler en un entorno declúster de Windows:

Instalación por primera vez de Tivoli Workload Scheduler en un entorno de clústerWindows.twsClusterAdm.exe –new domain=MYDOM user=mytwsuser pwd=mytwspwd–res group=myresgroup ip=myip net=mynetname disk=mydisk –dll

El mandato:v Configura Tivoli Workload Scheduler en todos los nodos del clúster.v Instala el nuevo tipo de recurso Clúster de Tivoli Workload Scheduler

(denominado ITWSWorkstation) en todos los nodos del clúster.v Copia el archivo ITWSResources.dll en la carpeta \%systemRoot%\cluster.v Crea una instancia del tipo de recurso Clúster de Tivoli Workload Scheduler

dentro del grupo de clústeres especificado.v Añade una dependencia de myip, mynetname y mydisk en el recurso.

Ejemplo 2: Instalación y configuración del nuevo recurso personalizado para unainstalación existente de Tivoli Workload Scheduler:

Instale y configure el nuevo recurso personalizado de Tivoli Workload Schedulerpara una instalación existente de Tivoli Workload Scheduler.

Nota: Este ejemplo solamente se aplica si el agente de Tivoli Workload Schedulerya está instalado para la misma instancia en todos los nodos del clúster y sitodos los tipos de arranque de servicios de Tivoli Workload Scheduler estánestablecidos en Manual.

twsClusterAdm.exe –new domain=MYDOM user=mytwsuser pwd=mytwspwd–res group=myresgroup ip=myip net=mynetname disk=mydisk –dll –notwsinst

El mandato:v Instala el nuevo tipo de recurso Clúster de Tivoli Workload Scheduler




|

Ejemplo 3: Adición de un nuevo agente en un entorno en clúster con TivoliWorkload Scheduler ya instalado:

Añada un nuevo agente de Tivoli Workload Scheduler en un entorno en clúster enel que ya se ha instalado un agente de Tivoli Workload Scheduler y se haconfigurado en un servidor virtual distinto.twsClusterAdm.exe –new domain=MYDOM user=mytwsuser pwd=mytwspwd–res group=myresgroup ip=myip net=mynetname disk=mydisk

El mandato:v Configura Tivoli Workload Scheduler en todos los nodos del clúster.v Crea una instancia del tipo de recurso Clúster de Tivoli Workload Scheduler


Ejemplo 4: Añadir un tipo de instancia de recurso personalizado a un grupo declúster existente:

Añada una instancia del tipo de recurso personalizado de Tivoli WorkloadScheduler a un grupo de clústeres existente.

Nota: Este ejemplo solamente se aplica si se ha instalado y configurado el agentede Tivoli Workload Scheduler y si se ha instalado el tipo de recursopersonalizado de Tivoli Workload Scheduler y se ha registrado.

twsClusterAdm.exe –new domain=MYDOM user=mytwsuser pwd=mytwspwd–res group=myresgroup ip=myip net=mynetname disk=mydisk –notwsinst

El mandato:v Crea una instancia del tipo de recurso Clúster de Tivoli Workload Scheduler


Ejemplo 5: Configuración de Tivoli Workload Scheduler en un nuevo nodo deunión del clúster:

Configure Tivoli Workload Scheduler en un nuevo nodo de unión del clúster.

Nota: En este ejemplo solamente se ha instalado y configurado el agente de TivoliWorkload Scheduler en el entorno en clúster. Posiblemente ha utilizadoTivoli Workload Scheduler durante mucho tiempo, ha adquirido un nuevonodo para este clúster y desea que Tivoli Workload Scheduler pueda accederal mismo en el caso de una anomalía.

twsClusterAdm.exe –new domain=MYDOM user=mytwsuser pwd=mytwspwdhosts=my_new_joining_host_name -dll

El mandato configuraTivoli Workload Scheduler e instala la DLL de recurso declúster de Tivoli Workload Scheduler en el nodo my_new_joining_host_name.

Ejemplo 6: Deshacer el registro de Tivoli Workload Scheduler en todos los nodosdel clúster salvo en el nodo actual:

Deshaga el registro de Tivoli Workload Scheduler de todos los nodos del clústersalvo en el nodo actual. Consulte la sección relacionada con el procedimiento dedesinstalación si desea más detalles.twsClusterAdm.exe –uninst domain=MYDOM user=mytwsuser


El mandato elimina la configuración de Tivoli Workload Scheduler de todos losnodos del clúster salvo del nodo actual.

Para desinstalar Tivoli Workload Scheduler del nodo actual debe utilizar elprocedimiento normal de desinstalación que se describe en la publicación IBMTivoli Workload Scheduler: Guía de planificación e instalación.

Ejemplo 7: Instalar una nueva versión de la DLL de recurso del clúster en elclúster:

Instale en el clúster una nueva versión de la DLL de recursos del clúster de TivoliWorkload Scheduler.twsClusterAdm.exe –update resource=<resource_name>

El mandato actualiza el tipo de recursos Clúster de Tivoli Workload Scheduler sihay disponible una nueva versión.

Ejemplo 8: Forzar la actualización/descarga de la DLL de recurso del clúster en elclúster:

Efectúe una actualización o una descarga forzada de la DLL de recursos del clústerde Tivoli Workload Scheduler en el clúster.twsClusterAdm.exe –update resource=<resource name> –force

El mandato actualiza el recurso del clúster de Tivoli Workload Scheduler sinverificar si la versión es posterior a la versión instalada.

Ejemplo 9: Primera instalación del gestor de dominio de un entorno de clústerde Windows, especificando opciones genéricas:

Instalación por primera vez de un gestor de dominio Tivoli Workload Scheduler enun entorno de clúster de Windows, especificando las opciones genéricas kill ylink

twsClusterAdm.exe –new domain=MYDOM user=mytwsuser pwd=mytwspwd –resgroup=myresgroup ip=myip net=mynetname disk=mydiskopts=killjob;link=MASTERDM!MASTER; –dll



dentro del grupo de clústeres especificado.v Añade una dependencia de myip, mynetname y mydisk en el recurso.v Establece las opciones genéricas kill y link.

Ejemplo 10: Actualizar de Tivoli Workload Scheduler versión 8.4 o posterior,habilitado para clústeres:

Actualice desde Tivoli Workload Scheduler versión 8.4 o posterior, habilitado paraclúster, a la versión 8.6 del siguiente modo:


|

v Desde la consola de administración del clúster, coloqueITWSWorkstation_mydomain_mytwsuser fuera de línea (el recurso deITWSWorkstation que desea actualizar).

v Elija la instalación del agente relacionada con el usuario mytwsuser y actualícelaa Tivoli Workload Scheduler versión 8.6.

v Desde el directorio <TWS_HOME>\cluster, inicietwsClusterAdm.exe –update resource=<nombre recurso> –twsupd –ask=no

El archivo DLL del recurso y el registro de servicios de Windows se actualizan yel archivo DLL se reinicia sin intervención del operador.

v Desde la consola del Administrador de clústeres ponga el recursoITWSWorkstation_mydomain_mytwsuser en línea.

Ejemplo 11: Primera instalación de Tivoli Workload Scheduler en un entorno declúster de Windows, definiendo escritorio compartido:

Instalación por primera vez de Tivoli Workload Scheduler en un entorno de clústerWindows, definiendo un escritorio compartido que utilizará Jobmon (éste es comoen el ejemplo 1, pero añadiendo el escritorio compartido):twsClusterAdm.exe –new domain=MYDOM user=mytwsuser pwd=mytwspwd–res group=myresgroup ip=myip net=mynetname disk=mydisk –dll –sharedesktop



dentro del grupo de clústeres especificado.v Añade una dependencia de myip, mynetname y mydisk en el recurso.v Define que jobmon utiliza el nombre de escritorio compartido predeterminado

Ejemplo 12: Primera instalación de Tivoli Workload Scheduler en entorno declúster de Windows, utilizando nombre personalizado de instancia de recurso:

Instalación por primera vez de Tivoli Workload Scheduler en un entorno de clústerWindows, utilizando un nombre de instancia personalizado (éste es como elejemplo 1, pero añadiendo el nombre de instancia de recurso personalizado):twsClusterAdm.exe –new domain=MYDOM user=mytwsuser pwd=mytwspwd–res group=myresgroup ip=myip net=mynetname disk=mydisk resname=myResName –dll



dentro del grupo de clústeres especificado.v Añade una dependencia de myip, mynetname y mydisk en el recurso.v Define que el nombre de la instancia de recurso es myResName.

Ejemplo 13: Cambio del nombre de la instancia de recurso:


Cambio del nombre de una instancia de recurso existente:twsClusterAdm.exe –changeResName "ITWSWorkstation_CLUSTER_SA_DM1"

"myResName"

El mandato cambia el nombre de la instancia de recursoITWSWorkstation_CLUSTER_SA_DM1 por myResName.

Ejemplo 14: Primera instalación del gestor de dominio en un entorno de clústerde Windows, especificando opciones de supervisión de planificación dinámica:

Instalación por primera vez de un gestor de dominios de Tivoli WorkloadScheduler en un entorno de clúster Windows, especificando la opción genéricaftaOff.twsClusterAdm.exe –new domain=MYDOM user=mytwsuser pwd=mytwspwd –resgroup=myresgroup ip=myip net=mynetname disk=mydiskopts=ftaOff



dentro del grupo de clústeres especificado.v Añade una dependencia de myip, mynetname y mydisk en el recurso.v Establece una opción genérica ftaOff para habilitar la supervisión del agente de

planificación dinámica.

Funcionamiento de Tivoli Workload Scheduler en entorno enclúster Windows

Esta sección describe cómo utilizar Tivoli Workload Scheduler en entornos enclúster de Windows. Se ha dividido en las subsecciones siguientes:v “Dependencias de recursos del clúster”v “Arranque y conclusión de Tivoli Workload Scheduler” en la página 25v “La nueva opción local “nombre instancia clúster”” en la página 26

Dependencias de recursos del clúster

Uno de los pasos más importantes al ejecutar Tivoli Workload Scheduler en losentornos de clúster de Windows es verificar que las dependencias se han definidocorrectamente.

Para asegurarse de que Tivoli Workload Scheduler funciona correctamente, lainstancia de recursos del clúster de Tivoli Workload Scheduler debe depender delos tipos de recursos siguientes:v Dirección IP

v Disco físico

v Nombre de red

según se muestra en el ejemplo siguiente en Windows Server 2003


||

|

|

|

Puede añadir más dependencias para asegurarse de que Tivoli Workload Schedulerinicia los trabajos solamente cuando haya un servicio indicado disponible. Estoocurre cuando Tivoli Workload Scheduler planifica trabajos que tienen comorequisito previo otras aplicaciones que detectan clústeres. Por ejemplo, paraasegurarse de que el trabajo de SQL se inicie solamente cuando haya disponibleuna base de datos relacional que detecta clústeres, añada una dependencia delrecurso del clúster de la base de datos relacional al recurso del clúster de TivoliWorkload Scheduler.

Arranque y conclusión de Tivoli Workload Scheduler

Los métodos siguientes ya no se pueden utilizar para detener Tivoli WorkloadScheduler porque provocarían una anomalía del recurso de clúster del TivoliWorkload Scheduler:v Conman shut

v Shutdown.cmd

v StartUp.cmd

v Conman start si el recurso ITWSWorkstation está fuera de línea.v StartupLwa.cmd

Utilice los scripts siguientes para detener e iniciar Tivoli Workload Scheduler(seguidamente puede renombrarlos si lo desea):v ShutDown_clu.cmd

v StartUp_clu.cmd

v ShutdownLwa.cmd

El programa twsClusterAdm.exe creará automáticamente los scripts anteriores bajoel directorio de instalación de Tivoli Workload Scheduler.

Figura 5. Pestaña Dependencias de recursos (Windows Server 2003)


Si no utiliza estos scripts, deberá ejecutar los mandatos siguientes para detener einiciar los servicios de Tivoli Workload Scheduler.

Stop:

cluster res <nombre instancia TWSresource> /offline

Start:

cluster res <nombre instancia TWS>/online

Ejemplos:

Si ITWSWorkstation_DOMAIN_MST_UserR es el nombre de la instancia de recursos deTWS para concluir Tivoli Workload Scheduler, deberá utilizar:cluster res ITWSWorkstation_DOMAIN_MST_UserR /offline

Para iniciar los servicios de Tivoli Workload Scheduler tiene que utilizar:cluster res ITWSWorkstation_DOMAIN_MST_UserR /online

donde clúster es el mandato de Windows para administrar el clúster (ejecutadodesde el indicador de mandatos de Windows).

La nueva opción local “nombre instancia clúster”

Uno de los pasos del programa de utilidad twsClusterAdmin es el registro delnombre de la instancia del recurso de clúster de Tivoli Workload Scheduler dentrodel archivo localopts de la opción local.

El agente de Tivoli Workload Scheduler utiliza el valor de esta nueva opción localpara señalar al recurso de clúster de Tivoli Workload Scheduler que el agente harecibido un mandato de detención.

Es importante cambiar el valor de la opción local nombre instancia clúster cadavez que se cambie el nombre de la instancia del recurso de Tivoli WorkloadScheduler. Si la opción local nombre instancia clúster no apunta al nombrecorrecto, el recurso de Tivoli Workload Scheduler se establecerá en el estadoanomalía en el supervisor de recursos del clúster. No especifique este nombre encaracteres DBCS (juego de caracteres de doble byte).

Para cambiar el nombre de la instancia del recurso de Tivoli Workload Schedulerutilice el procedimiento siguiente:1. Ponga la instancia de recursos de Tivoli Workload Scheduler en estado de fuera

de línea utilizando la consola del Administrador de clústeres. Para verificar siTivoli Workload Scheduler se ha detenido correctamente, puede utilizar laconsola del Administrador de clústeres y comprobar el estado de la instancia derecursos de Tivoli Workload Scheduler. Si no se ha conseguido detener elrecurso puede consultar los registros del clúster y de Tivoli Workload Schedulerpara saber el motivo. Consulte el apartado “Rastreos” en la página 30 paraobtener más detalles sobre los archivos de registro.

2. Modifique el nombre del recurso del clúster de Tivoli Workload Schedulerdirectamente desde la consola del Administrador de clústeres, según se muestraen el ejemplo siguiente de Windows Server 2003. No especifique este nombreen caracteres DBCS (juego de caracteres de doble byte).


3. Abra el archivo localopts utilizando el Bloc de notas. Modifique el valor de laopción local nombre instancia clúster. Compruebe que el nombre sea elmismo que el que ha especificado para el recurso del clúster de TivoliWorkload Scheduler en el paso 2 en la página 26.

4. Modifique el nombre de la instancia del clúster en los scripts StartUp_clu.cmdy ShutDown_clu.cmd.

5. Ponga la instancia de recursos de Tivoli Workload Scheduler en estado en líneaen la consola del Administrador de clústeres.

Figura 6. Ejemplo de agrupación de clústeres en Windows Server 2003

Figura 7. Localopts – Bloc de notas


Ampliación del Administrador de clústeres de Tivoli WorkloadScheduler

Esta sección describe la ampliación del Administrador de clústeres. Se ha divididoen las subsecciones siguientes:v “Visión general de la ampliación del Administrador de clústeres”v “Instalación de la ampliación del Administrador de clústeres”

Visión general de la ampliación del Administrador de clústeresEl Administrador de clústeres es un programa de utilidad de sistemas con unainterfaz gráfica de usuario que permite que los administradores gestiones objetosdel clúster, gestionen el mantenimiento y supervisen la actividad del clúster.

La ampliación del Administrador de clústeres de Tivoli Workload Scheduler es unabiblioteca de enlace dinámico que, cuando se ha instalado, amplía la consola delAdministrador de clústeres con una nueva hoja de propiedades y con una páginade asistente que le permite ver y editar las propiedades de los recursos de TivoliWorkload Scheduler.

El gráfico muestra el separador Parámetros de la nueva página de propiedades quele permite modificar los parámetros de recursos del clúster ITWSWorkstation.

Instalación de la ampliación del Administrador de clústeres

Instala este componente solamente si desea editar las propiedades directamentedesde la consola del Administrador de clústeres.

Si no instala la ampliación de Administración de clústeres, el separador Parámetros(vea la Figura 8) no estará disponible. Para modificar los parámetros de recursosdel clúster ITWSWorkstation, tendrá que cambiar estas propiedades utilizando elprograma de utilidad del sistema cluster.exe.

Figura 8. Separador Nuevos parámetros de propiedades


Instale la ampliación del Administrador de clústeres en un sistema donde se vayaa utilizar la consola del Administrador de clústeres.

Utilice el procedimiento siguiente para instalar una nueva ampliación delAdministrador de clústeres:1. Copie los archivos ITWSWorkstationEx.dll y ITWSExInst.cmd del directorio

<TWS_HOME>\cluster en el directorio en el que desee instalar la ampliación delAdministrador de clústeres. Puede utilizar el directorio predeterminado para elclúster: \%systemRoot%\cluster.

2. Efectúe una doble pulsación sobre ITWSExInst.cmd, o ejecútelo desde un shellde mandatos para instalar la ampliación del Administrador de clústeres.

Desinstalación de Tivoli Workload Scheduler

Los pasos para eliminar el producto se tienen que iniciar desde el mismo nodo quese ha utilizado anteriormente para instalar Tivoli Workload Scheduler y losposteriores fixpack.

El procedimiento es el siguiente:1. Elimine manualmente la instancia de recursos personalizada de Tivoli

Workload Scheduler del grupo de clústeres. Para ello, puede utilizar la consoladel Administrador de clústeres.

2. De forma opcional, deshaga el registro del tipo de recurso utilizando elmandato:cluster restype ITWSWorkstation /delete

No deshaga el registro del recurso si hay instancias en otros grupos declústeres.

3. De forma opcional, suprima el archivo DLL ITWSResources.dll del directoriode instalación (el directorio predeterminado es \%systemRoot%\cluster).

4. Ejecute el programa de utilidad TwsClusterAdm –uninst. Este programa deutilidad elimina los servicios de Tivoli Workload Scheduler y registra clavesprocedentes de nodos de clúster distintos del nodo actual.

Para eliminar Tivoli Workload Scheduler del nodo actual, puede ejecutar elprograma de desinstalación normal (consulte la publicación IBM Tivoli WorkloadScheduler: Guía de planificación e instalación).

Resolución de problemasEsta parte de la guía proporciona información sobre resolución de problemas deTivoli Workload Scheduler en un entorno de clúster de Windows. Esta informacióncorresponde al motor de Tivoli Workload Scheduler y a la instalación para esteentorno. Para obtener más información sobre la resolución de problemas de TivoliWorkload Scheduler, consulte la publicación IBM Tivoli Workload SchedulerAdministration and Troubleshooting.

Este capítulo contiene las secciones siguientes:v “Rastreos” en la página 30v “Error 1314 al poner en línea el recurso y la estación de trabajo no tiene enlace”

en la página 30v “La instancia de recursos de Tivoli Workload Scheduler informa de un estado de

anomalía o los trabajos del usuario de Tivoli Workload Scheduler pasan alestado abend (terminación anómala)” en la página 31


v “Panel de informe de Windows con Jobmon.exe” en la página 31v “Clúster: Error de validación de IP en Netman stdlist” en la página 32

RastreosTivoli Workload Scheduler conserva registros de diferentes actividades endiferentes lugares. Consulte la publicación IBM Tivoli Workload SchedulerAdministration and Troubleshooting para obtener más información.

El pack de habilitación del nuevo clúster presenta dos archivos de rastreo en eldirectorio Directorio instalación TWS\stdlist\traces:

clu_offline.logCuando el recurso personalizado de Tivoli Workload Scheduler pasa afuera de línea (cada vez que se produce una migración tras error), elrecurso personalizado de Tivoli Workload Scheduler inicia la línea demandatos conman para detener y desenlazar la instancia. En este registropuede encontrar la salida del mandato.

clu_online.logCuando el recurso personalizado de Tivoli Workload Scheduler pasa aestar en línea (cada vez que se produce una migración tras error), elrecurso personalizado de Tivoli Workload Scheduler inicia la línea demandatos conman para enlazar la estación de trabajo a su gestor dedominio. En este registro puede encontrar la salida del mandato conmanlink @!@;noask.

Toda acción emprendida por el recurso personalizado de Tivoli WorkloadScheduler se registra dentro del archivo de registro de clústeres del sistema. Setrata de un archivo denominado cluster.log ubicado bajo la carpeta\%systemRoot%\cluster.

Error 1314 al poner en línea el recurso y la estación de trabajono tiene enlace

El problema podría estar relacionado con los permisos del administrador declústeres. Para comprobarlo:1. Abra el archivo de registro del clúster (cluster.log) situado en la carpeta

\%systemRoot%\cluster.2. Busque las series que contengan ITWSWorkstation. Son los mensajes registrados

por el recurso personalizado de Tivoli Workload Scheduler.3. Si aparece un mensaje similar al siguiente:

<time> ERR ITWSWorkstation <nombre instancia recurso>: SubmitTwsCommand:CreateProcessWithLogonW failed <TWS_HOME>\conman.exe> < start;noask>’1314’

Significa que se ha producido el error 1314 del sistema, El cliente no disponede un privilegio necesario, al iniciar el mandato conman.

4. Para resolver el problema, deberá conceder al usuario del clúster privilegiossuficientes para permitir que la instancia del recurso personalizado envíe unenlace de mandatos de Tivoli Workload Scheduler.

Para resolver este problema, añada el derecho Sustitución de una señal de nivelde proceso a la cuenta de administrador del clúster (es el nombre del usuario quese haya elegido cuando se ha configurado el clúster). Para añadir este derecho a lacuenta del administrador del clúster abra Panel de control → Herramientas


administrativas → Directiva de seguridad local → Directivas locales → Asignaciónde derechos de usuario y añada la cuenta de usuario administrador del clúster enla lista de directivas de seguridad Sustitución de una señal de nivel de proceso.Este derecho es necesario para poder habilitar el administrador del clúster deforma que actúe como usuario de Tivoli Workload Scheduler. De esta forma, elrecurso personalizado de Tivoli Workload Scheduler, que se ejecuta con lospermisos del usuario administrador del clúster, podrá detener, iniciar y enlazarTivoli Workload Scheduler. Reinicie los nodos del clúster para que el cambio entreen vigor. Esta operación solamente es necesaria la primera vez que se configuraTivoli Workload Scheduler para que funcione en el entorno en clúster de Windows2003.

Deberá rearrancar los nodos del clúster para que este cambio entre en vigor.

La instancia de recursos de Tivoli Workload Schedulerinforma de un estado de anomalía o los trabajos del usuariode Tivoli Workload Scheduler pasan al estado abend(terminación anómala)

Problema: Si ejecuta más de tres instancias de Tivoli Workload Scheduler en elmismo nodo y hay trabajos en ejecución, es posible que suceda lo siguiente:v La instancia de recursos del clúster de Tivoli Workload Scheduler está en estado

de anomalía. Consulte el estado de los recursos en la consola del Administradorde clústeres (Figura 6 en la página 27).

v Los trabajos del usuario de Tivoli Workload Scheduler pasan al estado abend ofail. En tal caso, puede encontrar el siguiente mensaje de error en<TWS_HOME>\stdlist\date\TWSUSERNAME:++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AWSBIJ139E Se ha producido un error interno. Jobmon no ha podido crear un+ nuevo escritorio en la estación de la ventana asociada al proceso de llamada.+ El error se ha producido en el siguiente archivo de código fuente:+ ../../src/jobmon/monutil.c at line: 2454. El mensaje de error+ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++AWSBIJ140E Se ha producido un error interno. Jobmon no ha podido crear elentorno de proceso de Windows para iniciar trabajos. El error se ha producido en elsiguiente archivo de código origen: ../../src/jobmon/monutil.c en la línea: 830.

El siguiente mensaje de error está en el archivo <TWS_HOME>\stdlist\logs\date_TWSMERGE.log: 06:00:28 19.05.2006|BATCHMAN:* AWSBHT061E Batchman harecibido un registro de buzón de correo que indica que el siguientetrabajo ha terminado inesperadamente: El sistema se ha quedado sinalmacenamiento dinámico de escritorio.06:00:28 19.05.2006|BATCHMAN:*AWSBHT061E Batchman ha recibido un registro de buzón que indica que el siguientetrabajo ha terminado de forma inesperada:

El sistema ha agotado el almacenamiento dinámico del escritorio.

Solución: La solución a este problema ofrece varias opciones, que se describenen el apartado “Resolución de problemas de tamaño de almacenamientodinámico de escritorio en estaciones de trabajo con más de tres agentes”, en lapágina 45

Panel de informe de Windows con Jobmon.exe

Problema: Después de una migración tras error del nodo A al nodo B, en ocasionesJobmon provoca un volcado del núcleo con un error de violación de segmentaciónque se produce en el nodo A. Puede visualizar la segmentación tras rearrancar el


|

nodo A, o cuando se registre con el usuario Tivoli Workload Scheduler. Esto noocasiona ningún problema porque Tivoli Workload Scheduler en el nodo Bfunciona correctamente después de una segunda migración tras error y TivoliWorkload Scheduler también funciona en el nodo A.

Clúster: Error de validación de IP en Netman stdlist

Este problema se produce cuando el campo del nodo de una definición de estaciónde trabajo se ha definido como una dirección IP real en lugar de con un recurso denombre de red de clúster.

El problema es que la validación de IP se realiza utilizando la dirección IP delnodo cuando se arranca Tivoli Workload Scheduler y no la dirección IP de losrecursos fta del clúster.

Puede ver este aviso cuando el agente padre/hijo está instalado en un clúster yhay una discrepancia entre la dirección IP real que se ha detectado desde el canalTCP/IP y la dirección IP declarada en la definición de la estación de trabajo (nodode propiedades). Si el nodo de propiedades es un nombre host, se resolverá enprimer lugar (realizando una consulta del DNS).


Capítulo 3. IBM Tivoli Workload Scheduler con HACMP

Este capítulo contiene los temas siguientes:v “Multiproceso de clúster de alta disponibilidad”v “Visión global del clústeres de UNIX” en la página 37

Multiproceso de clúster de alta disponibilidadIBM utiliza la Herramienta multiproceso de clúster de alta disponibilidad(High-Availability Cluster Multi-Processing, HACMP) para construir sistemasoperativos de computación fundamentales para los objetivos de la organización,basados en UNIX. HACMP asegura que los recursos críticos, como aplicaciones,estén disponibles para proceso. HACMP tiene dos componentes principales: altadisponibilidad (high availability, HA) y multiproceso en clúster (clustermulti-processing, CMP).

El motivo principal para crear clústeres HACMP es proprocionar un entorno dealta disponibilidad para aplicaciones fundamentales de la empresa u organización.Por ejemplo, un clúster HACMP podría eejcutar un programa servidor de bases dedatos para dar servicio a aplicaciones de clientes. Los clientes envían consultas alprograma de servidor, el cual las responde accediendo a una base de datosalmacenada en un disco externo compartido.

En un clúster HACMP, para asegurar la disponibilidad de estas aplicaciones, lasaplicaciones se ponen bajo control HACMP. HACMP asegura que las aplicacionespermanecen disponibles para procesos de clientes, incluso si un componente delclúster falla. Para asegurar la disponibilidad, en caso de fallo de un componente,HACMP desplaza la aplicación (junto con los recursos necesarios para acceder a lamisma) a otro nodo del clúster.

En los temas siguientes hallará más detalles:v “Ventajas”v “Componentes físicos de un clúster HACMP” en la página 34

Ventajas

HACMP proporciona las ventajas siguientes:v El proceso de planificación y documentación de HACMP incluye sugerencias y

consejos sobre los métodos recomendados para la instalación y mantenimientode un clúster HACMP de alta disponibilidad.

v Cuando el clúster está operativo, HACMP proporciona supervisión yrecuperación automáticos para todos los recursos que la aplicación necesite.

v HACMP proporciona un conjunto completo de herramientas para elmantenimiento del clúster y asegura que la aplicación esté disponible para losclientes.

Use HACMP para:v Configurar un entorno HACMP usando las hojas de trabajo de planificación en

línea que simplifican la planificación y configuración iniciales.


v Asegurar la alta disponibilidad de aplicaciones mediante la eliminación depuntos únicos de error en un entorno HACMP.

v Usar las funciones de alta disponibilidad disponibles en AIX.v Gestionar la forma en la que un clúster gestiona los errores de los componentes.v Asegurar comunicaciones de clúster.v Configurar la sustitución rápida de disco para grupos de volúmenes gestionados

por el gestor de volúmenes lógicos (LVM).v Gestionar el proceso de sucesos para un entorno HACMP.v Supervisar componentes HACMP y diagnosticar problemas que puedan

producirse.

Componentes físicos de un clúster HACMP

HACMP proporciona un entorno de alta disponibilidad mediante la identificaciónde un conjunto de recursos que son esenciales para un funcionamientoininterrumpido y, mediante la definición de un protocolo que los nodos utilizanpara colaborar para asegurar que dichos recursos estén disponibles. HACMPamplía el modelo de clústering mediante la definición de relaciones entreprocesadores que cooperan, en las que un procesador proporciona el servicioofrecido por un igual, cuando el igual no puede hacerlo.

Un clúster HACMP está compuesto de los siguientes componentes físicos:v “Nodos” en la página 35v “Dispositivos de disco externo compartido” en la página 36v “Redes” en la página 36v “Clientes” en la página 36

HACMP le permite combinar componentes físicos en un amplio rango deconfiguraciones de clúster, proporcionándole flexibilidad a la hora de construir unclúster que se ajuste a sus necesidades de procesamiento. Figura 9 en la página 35muestra un ejemplo de un clúster HACMP. Otros clústeres HACMP pueden tenerun aspecto muy distinto, según el número de procesadores, las opciones de red ytecnologías de disco, etc.


Nodos

Los nodos forman el núcleo de un clúster HACMP. Un nodo es un procesador queejecuta tanto AIX como HACMP. HACMP tiene soporte para sistemas deprocesador único y multiprocesadores simétricos (SMP) de pSeries, y sistemas deprocesador POWERParallel escalable (SP) como nodos de clúster. HACMP, unsistema SMP, parece un sistema de procesador único. Los sistemas SMPproporcionan una forma óptima de aumentar el rendimiento de clúster. Cada nododel clúster puede ser una gran máquina SMP, ampliando un clúster HACMP másallá de los límites, o un único sistema que permita a miles de usuarios conectarse auna única base de datos.

En un clúster HACMP, hasta 32 equipos o nodos cooperan para proporcionar unconjunto de servicios o recursos a otros clientes remotos. La agrupación en clústerde estos servidores para hacer de respaldo a aplicaciones fundamentales es unaopción rentable para disponer de alta disponibilidad. Un negocio puede utilizarmás su capacidad de computación para asegurarse de que sus aplicaciones críticasreanudan su ejecución tras una interrupción provocada por un error de hardware osoftware.

Buses de disco

Disco compartido con duplicados

LAN1 Publica

LAN2 Publica

Clientes

Nodos

LANprivada

Figura 9. Disco compartido con duplicación (mirror)

Capítulo 3. Tivoli Workload Scheduler con HACMP 35

En un clúster HACMP, cada nodo se identifica por un nombre exclusivo. Un nodopodría ser propietario de un conjunto de recursos (discos, grupos de volúmen,sistemas de archivos, redes, direcciones de red y aplicaciones). Por lo general, unnodo ejecuta un servidor o aplicación "de fondo" que accede a los datos en losdiscos externos compartidos.

HACMP tiene soporte de 2 a 32 nodos en un clúster, según la tecnología de discosutilizada para los discos externos compartidos. Un nodo de un clúster HACMPtiene varias capas de componentes de software.

Dispositivos de disco externo compartido

Cada nodo debe tener acceso a uno o más dispositivos de disco externocompartido. Un dispositivo de disco externo compartido es un disco físicamenteconectado a varios nodos. El disco compartido almacena datos fundamentales delproceso global, y se suele replicar (mirror) o configurar en RAID con redundanciade datos. Un nodo en un clúster HACMP también debe tener discos internos quealmacenan el sistema operativo y los binarios de la aplicación, pero dichos discosno están compartidos.

Según el tipo de disco usado, HACMP tiene soporte para dos tipos de acceso adispositivos de disco externo compartido: acceso concurrente y acceso noconcurrente.v En entornos de acceso no concurrentes, sólo hay activa una conexión en cada

momento y el nodo con la conexión activa es el propietario del disco. Cuandofalla un nodo, se produce la toma de control por parte del disco cuando el nodoque actualmente es propietario del disco deja el clúster y un nodo en estadocorrecto asume la propiedad del disco compartido.

v En entornos de acceso concurrente, los discos están contectados activamente amás de un nodo de forma simultánea. Por lo tanto, cuando un nodo falla, no esnecesaria la toma de control del disco.

Redes

Como componentes por capas independiente de AIX, HACMP está diseñado paratrabajar con cualquier red basada en TCP/IP. Los nodos de un clúster de HACMPutilizan la red para permitir a los clientes acceder a los nodos en clúster,habilitarlos para intercambiar mensajes de pulsación y, en entornos de accesoconcurrente, serializar el acceso a datos.

HACMP define dos tipos de redes de comunicación, caracterizadas por si dichasredes utilizan interfaces de comunicación basadas en el subsistema TCP/IP (basadoen TCP/IP), o dispositivos de comunicación basados en subsistemas que no seanTCP/IP (basados en el dispositivo).

Clientes

Un cliente es un procesador que puede acceder a los nodos de un clúster a travésde una red de área local. Los clientes ejecutan una interfaz o aplicación de clienteque consulta a la aplicación de servidor en ejecución en el nodo de clúster.

HACMP proporciona un entorno de alta disponibilidad para datos y aplicacionescríticos en nodos de clúster. Tenga en cuenta que HACMP no hace que los propiosclientes tengan alta disponibilidad. Los clientes AIX pueden utilizar los servicios deClient Information (Clinfo) para recibir notificación de sucesso de clúster. Clinfoproporciona una API que muestra la información de estado de clúster. El programa


de utilidad /usr/es/sbin/cluster/clstat, un cliente Clinfo proporcionado conHACMP, proporciona información sobre todas las interfaces del servicio de clúster.

Visión global del clústeres de UNIXEn esta sección se describe el procedimiento para otorgar alta disponibilidadusando el Multi-procesamiento de clústeres de alta disponibilidad(High-Availability Cluster Multi-processing, HACMP), en los sistemas operativosAIX, UNIX y Linux para IBM. Se ha dividido en las subsecciones siguientes:v “Conocimientos sobre requisitos previos”v “Configuraciones de espera y toma de control”v “Limitaciones del diseño” en la página 40v “Configuraciones con soporte” en la página 40

Conocimientos sobre requisitos previosPara entender los temas de esta sección, debe estar familiarizado con los clústeresde HACMP y Tivoli Workload Scheduler:

Tivoli Workload SchedulerPara ver una visión general de Tivoli Workload Scheduler, consulte elmanual Tivoli Workload Scheduler: Guía de planificación e instalación

Clústeres HACMPPara ver una Guía de inicio rápido para clústeres HACMP, consulte elCluster Multi-Processing for AIX Version 7.3 en

http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=/com.ibm.aix.doc/doc/base/aixinformation.htm (Multiproceso de clústeresde alta disponibilidad para AIX, versión 7.3)

Configuraciones de espera y toma de controlHay dos tipos básicos de configuración de clúster:

EsperaEsta es la configuración de hardware redundante tradicional. Uno o másnodos en espera se configuran aparte, desocupados, esperando a que unservidor primario del clúster falle. Esto también se conoce como esperaactiva. De aquí en adelante nos referiremos a una configuraciónactiva/pasiva para indicar un clúster de dos nodos con una configuraciónde espera activa.

Toma de controlEn esta configuración, todos los nodos del clúster procesan parte de lacarga de trabajo del clúster. No se configuran nodos en espera aparte.Cuando un nodo primario falla, uno de los otros nodos asume la carga detrabajo del nodo que ha fallado, además de su carga de trabajo principalactual. Esto también se conoce como toma de control mutua.

Por lo general, las implementaciones de ambas configuraciones implicarán el usode recursos compartidos. Los discos o almacenamientos masivos, como una red deárea de almacenamiento (Storage Area Network, SAN) son los que se configurancon más frecuencia como recurso compartido.

Según se muestra en Figura 10 en la página 38, el Nodo A es el nodo primario, y elNodo b es el nodo en espera actualmente desocupado. Aunque el nodo B tiene unaconexión al recurso de almacenamiento masivo compartido, no está activo durante


|||

|||

||||||

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

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

el funcionamiento normal del sistema.

Una vez que el Nodo A migra tras error al Nodo B, la conexión al recurso dealmacenamiento masivo desde el nodo B se activa, y el Nodo A no está estádisponible, su conexión al recurso de almacenamiento masivo está inactiva. Esto semuestra en Figura 11.

Por contra, en la siguiente configuración de toma de control, tanto el nodo A comoel nodo B acceden al recurso de disco compartido de forma simultánea. Paraconfiguraciones de alta disponibilidad de Tivoli Workload Scheduler, esto sueleimplicar que el recurso de disco compartido tiene volúmenes del sistema dearchivos lógico separados, a los que se accede mediante nodos diferentes. Esto semuestra en Figura 12 en la página 39.

Almacenamientomasivo

Nodo A Nodo B

En espera(inactivo)

Figura 10. Configuración activa-pasiva en funcionamiento normal

Nodo A FS

Nodo A Nodo B

Apl2

Apl1X

Nodo B FS

Almacenamiento masivoFigura 11. Migración tras error en una configuración activa-pasiva


Durante el funcionamiento normal de este clúster de alta disponibilidad de dosnodos en una configuración de toma de control, al sistema de archivos FS del nodoA se accede mediante la aplicación 1 (App 1) en el nodo A, y al sistema dearchivos FS del nodo B se accede mediante App 2 en el nodo B. Si alguno de ellosfalla, el otro nodo asume la carga de trabajo. Por ejemplo, si el nodo A falla, laaplicación 1 (App 1) se reinicia en el nodo B, y el nodo B abre una conexión alsistema de archivos FS del nodo A. Esto se muestra en Figura 13.

Las configuraciones de toma de control son más eficaces que las configuraciones enespera con recursos de hardware, ya que no hay nodos desocupados. No obstante,el rendimiento se puede ver afectado tras un error de nodo, ya que la carga globalde los nodos restantes aumenta.

Nodo A FS

Nodo B FS

Almacenamiento masivo

Nodo A Nodo B

Apl1 Apl2

Figura 12. Volúmenes del sistema de archivos lógico

Nodo A FS

Nodo A Nodo B

Apl2

Apl1

Nodo B FS

Almacenamiento masivo

X

Figura 13. Escenario de migración tras error


Limitaciones del diseñoSe aplican las siguientes limitaciones del diseño:v “El gestor de dominio maestro”v “Mandatos de Tivoli Workload Scheduler”v “Estado final de los trabajos en ejecución”

El gestor de dominio maestroEl gestor de dominio maestro de Tivoli Workload Scheduler tiene soporte en elservidor virtual de clúster, pero tiene dos limitaciones importantes:v El gestor de dominio maestro ejecuta la secuencia de trabajos final, lo que crea

un nuevo plan para el día de producción actual. Este proceso no se puedeinterrumpir. Una interrupción podría causar un malfuncionamiento einterrupciones en el servicio de planificación. Solamente se pueden realizarpasos manuales para recuperar algunos problemas de malfuncionamiento ointerrupciones del servicio. Como la recuperación frente a errores del grupo declústeres que contiene el recurso Tivoli Workload Scheduler detiene el agente enel nodo actual y lo inicia en un nodo distinto, si se produce la recuperaciónfrente a errores cuando se ejecuta la secuencia de trabajos final, podría serdestructiva.

v Las utilidades de línea de mandatos de Tivoli Workload Scheduler (conman,composer, ...) no reconocen la presencia del clúster y, si se interrumpen(mediante una migración tras error del grupo de clústeres que contiene elrecurso Tivoli Workload Scheduler) podrían corromper información fundamentalde Tivoli Workload Scheduler.

Mandatos de Tivoli Workload SchedulerEl recurso de clústeres de Tivoli Workload Scheduler no pone automáticamentefuera de línea ningún mandato de Tivoli Workload Scheduler que se estéejecutando cuando se produce una migración tras error (a diferencia de losprocesos principales netman, mailman, batchman y jobman).

Esto resulta particularmente problemático si la migración tras error se producedurante una acción de someter ad-hoc. El trabajo sometido permanecería parasiempre en el estado ADDING.

Cuando el mandato Examinar registro de trabajos a través de la línea de mandatosconman está activo, el mandato de recuperación frente a errores manual nofunciona correctamente y debe cerrar todas las ventanas cuando el mandato está enejecución.

Estado final de los trabajos en ejecuciónSi un trabajo se ejecutan druante una migración frente a errores, su estado final esABEND con código de retorno cero. Es porque el proceso Jobman no puederecuperar el estado final verdadero del trabajo.

Configuraciones con soporte

En esta sección se describe la arquitectura de HACMP que hemos configurado parael entorno de prueba seguido de descripciones detalladas del escenario.

Para los escenarios, hemos definido:v 2 nodosv 3 discos compartidos


||||||||||

v 1 grupo de volúmenesv 1 servidor de aplicacionesv 1 dirección IP de serviciov 1 grupo de recursos

También hemos configurado la pulsación en el disco (Heartbeat on Disk).

El servidor de aplicaciones contiene la definición de los scripts start_tws.sh ystop_tws.sh que se describen con detalle en cada sección y que se deben crear enambos nodos.

Los scripts start_tws.sh y stop_tws.sh pueden encontrarse en el directorioTWSHome/config y deben personalizarse definiendo los valores TWS_USERyTWS_HOME, así como el valor DB2 INFO si es necesario. Tras personalizar losscripts, muévalos a otro directorio, ya que cualquier versión o fixpack posterior lossobrescribirá.

La configuración Ethernet que hemos implementado es IP Replacement(Sustitución de IP), para tener una dirección de arranque por cada nodo y ladirección IP de servicio "sustituye" a la activa. En esta configuración, la direcciónde arranque del nodo activo no se puede alcanzar, para evitar problemas durantela instalación de Tivoli Workload Scheduler, hemos configurado un alias para lainterfaz de red Ethernet con el valor de la propia dirección de arranque. Si se usala configuración de alias de IP (IP Aliasing), este paso adicional no es necesario.

Los escenarios siguientes de HACMP tienen soporte con Tivoli WorkloadScheduler:v “Escenario: disco compartido, migración tras error pasiva-activa en un gestor de

dominio maestro”v “Disco compartido, Pasivo - Migraciones frente a errores activas en el agente

tolerante a errores” en la página 44v “Conmutación de gestores de dominios” en la página 44

Como escenario adicional, también podemos pensar en la posibilidad de tener unainstancia de DB2 local o remota en el Gestor de dominio maestro.

Escenario: disco compartido, migración tras error pasiva-activaen un gestor de dominio maestro

En este escenario se describe cómo configurar Tivoli Workload Scheduler(versiones 8.5.1 o 8.6) y una base de datos DB2 remota o local de forma que unclúster HACMP pueda gestionar la migración tras error de un gestor de dominiomaestro activo.

Configuración de Tivoli Workload Scheduler en una base de datos DB2remota

En el procedimiento siguiente se explica cómo configurar Tivoli WorkloadScheduler y una base de datos DB2 remota de forma que un nodo pasivodesocupado del clúster pueda tomar el control sobre un gestor de dominio maestroactivo que falle. El requisito previo para este procedimiento es que debe tenerconfigurado HACMP.


|||||

||||

Instale Tivoli Workload Scheduler usando uno de los métodos de instalacióndescritos en Tivoli Workload Scheduler: Guía de planificación e instalación. Durante lainstalación, realice los pasos de configuración siguientes:1. Cree el mismo usuario y grupo de administrador TWS en todos los nodos del

clúster. Asegúrese de que el usuario tiene la misma ID en todos los nodos yapunta al mismo directorio de inicio en el disco compartido en el que va ainstalar Tivoli Workload Scheduler.Ejemplo: desea crear el grupo llamado twsadm para todos los administradoresTivoli Workload Scheduler y el usuario administrador de TWS denominó atwsusr con la ID de usuario 518 y el inicio /cluster/home/twsusr” en el discocompartido:mkgroup id=518 twsadmmkuser id=518 pgrp=twsadm home=/cluster/home/twsusr twsusrpasswd twsusr

Si desea instalar Tivoli Workload Scheduler en un directorio distinto al deldirectorio de inicio del usuario en el disco compartido, asegúrese de que laestructura del directorio es la misma en todos los nodos y de que el archivouseropts se encuentra disponible para todos los nodos. Asimismo, en este casodebe asegurarse de que el usuario tenga la misma ID en todos los nodos delclúster.

2. Inicie el nodo que quiera utilizar para ejecutar la instalación de Tivoli WorkloadScheduler y establezca los parámetros de forma que HACMP monte el discocompartido automáticamente.

3. Instale el cliente administrativo de DB2 en ambos nodos o en un discocompartido configurándolo para la migración tras error según se describe en ladocumentación de DB2.

4. Cree la instancia db2inst1 en el nodo activo para crear un enlace directo entreTivoli Workload Scheduler y el servidor remoto de DB2.

5. Continúe con la instalación de Tivoli Workload Scheduler utilizando twsusercomo el directorio de inicio y la instancia de db2inst1 local.

Una vez instalado Tivoli Workload Scheduler, debe ejecutar la herramienta derecopilador de clúster para recopilar automáticamente archivos del gestor dedominio maestro activo. Estos archivos incluyen los archivos de registro, elcatálogo de distribución de software y las bibliotecas externas de Tivoli WorkloadScheduler. La herramienta de recopilador de clúster crea un archivo .tar quecontiene los archivos recopilados. Para copiar estos archivos a los nodos pasivos,debe extraer este archivo .tar en ellos.

Para configurar Tivoli Workload Scheduler para rendimiento de HACMP, realicelos pasos siguientes:1. Ejecute la herramienta de recopilador de clúster2. Desde el directorio TWA_home/TWS/bin, ejecute ./twsClusterCollector.sh

-collect -tarFileName tarFileName

donde nombre_archivo_tar es la vía de acceso absoluta en la que se almacenael archivo.

3. Copie <tws_user_home>/useropts_twsuser del nodo activo al gestor dedominio maestro desde los directorios de inicio de raíz y usuario a los otrosnodos.

4. Sustituya el nombre de host del nodo por la dirección IP de servicio para: lasdefiniciones gestor de dominio maestro, el WebSphere Application Server, el


||||

||||

|||

||||||

|||

||

|

||

||

|||

||

Intermediario de carga de trabajo dinámica y el agente dinámico, como sedescribe en la Administration Guide, apartado Changing the workstation hostname or IP address.

5. Copie los scripts start_tws.sh y stop_tws.sh del directorioTWA_home/TWS/config al directorio TWA_home.

6. Personalice los scripts start_tws.sh y stop_tws.sh especificando los valorespara las variables MAESTRO_USER y MHOME.

7. Pruebe los scripts start_tws.sh y stop_tws.sh para verificar Tivoli WorkloadScheduler los inicios y las paradas correctamente.

8. Mueva el volumen compartido en el segundo nodo de clúster (si ya hadefinido el grupo de clúster, puede moverlo utilizando el mandato clRGmoveHACMP).

9. Ejecute la herramienta de recopilador para extraer las bibliotecas TivoliWorkload Scheduler. Desde el directorio TWA_home/TWS/bin, ejecute:./twsClusterCollector.sh -deploy -tarFileName tarFileName

donde nombre_archivo_tar es la vía de acceso absoluta en la que se almacena elarchivo.

10. Configure un nuevo recurso de controlador de aplicaciones en el multiprocesode clúster de alta disponibilidad utilizando los scripts start_tws.sh ystop_tws.sh personalizados.

Cuando el multiproceso de clúster de alta disponibilidad invoca los scripts durantela migración tras error, éstos inician o detienen automáticamente WebSphereApplication Server y Tivoli Workload Scheduler, y enlazan o desenlazan todas lasestaciones de trabajo.

DB2 local

Este escenario está basado en todos los pasos descritos en “Configuración de TivoliWorkload Scheduler en una base de datos DB2 remota” en la página 41, pero deberealizar pasos adicionales.1. Instale DB2 de forma local en ambos nodos o en el disco compartido, sin crear

una instancia nueva.2. Cree una instancia nueva en el disco compartido, defina todos los usuarios de

DB2 también en el segundo nodo y modifique los dos archivos siguientes:v /etc/hosts.equiv

Añada una línea nueva únicamente con el valor de la dirección IP de serviciov <db2-instance-home>/sqllib/db2nodes.cfg

Añada una línea nueva parecida a la siguiente:0 <Service IP address> 0

En este escenario, personalice los scripts start_tws.sh y stop_tws.sh estableciendoel valor DB2_INST_USER a utilizar para ejecutar el inicio y parada de la instanciade DB2 durante la fase de "migración tras error".

La única diferencia afecta al proceso monman utilizado para la función EventDriven Workload Automation (Automatización de la carga de trabajo dirigida porsucesos), de forma que hay un paso adicional en el script start_tws.sh ostop_tws.sh para iniciar o detener dicho servicio. En las versiones 8.5.1 y 8.6 deTivoli Workload Scheduler, hay pasos adicionales respecto al inicio y parada delagente dinámico.


|||

||

||

||

|||

||

|

||

|||

awsadchgwshostorip.htm

awsadchgwshostorip.htm

Disco compartido, Pasivo - Migraciones frente a errores activasen el agente tolerante a errores

Este escenario es casi el mismo que “Escenario: disco compartido, migración traserror pasiva-activa en un gestor de dominio maestro” en la página 41, pero no haypasos adicionales que realizar en DB2 y WebSphere Application Server, y losscripts start_tws.sh y top_tws.sh sólo ejecutan link/unlink y los mandatos deinicio y parada.

Conmutación de gestores de dominios

En este escenario, la base de datos DB2 está instalada en un servidor remoto y elcliente de administración de DB2 está instalado en ambos nodos. La configuraciónestá basada en una instalación Maestra en el primer nodo y un Maestro derespaldo en el segundo. Ambos nodos están conectados al mismo servidor DB2remoto.

En este escenario, no se necesitan pasos adicionales posteriores a la instalación. Elscript stop_tws.sh puede dejarse vacío y el start_tws.sh puede crearse desdeTWA_home/TWS/config/switch_tws.sh. Debe estar personalizado con TivoliWorkload Scheduler

Nombre de usuario, nombre de usuario y contraseña de DB2 Tivoli WorkloadScheduler y el nombre de alias de DB de Tivoli Workload Scheduler. El scriptstart_tws.sh ejecuta el mandato de gestor de conmutador y, como paso adicional,modifica la definición de la estación de trabajo en la DB2, para así soportar deforma más conveniente un conmutador que dure más de un día de producción.


||||

|||||

Apéndice. Resolución de problemas de tamaño dealmacenamiento dinámico de escritorio en estaciones detrabajo con más de tres agentes

En este apéndice se describe cómo solucionar el problema en el que laslimitaciones de memoria de almacenamiento dinámico del escritorio de Windowshacen que los procesos fallen si hay más de tres instancias de Tivoli WorkloadScheduler instaladas en una estación de trabajo en un entorno de clúster deWindows 2003.

Utilice esta descripción si desea evitar que se produzca el problema (antes deinstalar la cuarta instancia de agente) o si se ha producido un problema ocasionadopor esta limitación.

Esta sección contiene los siguientes temasv “Descripción del problema”v “Soluciones” en la página 46v “Implementación de las soluciones” en la página 48

Descripción del problema

El problema se produce debido a la forma en que Windows maneja su memoria dealmacenamiento dinámico de escritorio y a la forma en que Tivoli WorkloadScheduler crea escritorios. En el contexto de seguridad, un escritorio se utiliza paraencapsular procesos de Windows, evitando que el proceso realice actividades noautorizadas.

La cantidad total de memoria disponible para la creación de escritorios ladeterminad la entrada del registro de Windows llamada:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory Managment\SessionViewSize

El valor predeterminado es 20 MB.

La compartición de este almacenamiento intermedio para cada escritorio ladetermina la entrada del registro de Windows llamada:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows

Por ejemplo, el valor de esta entrada puede ser:%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

En esta entrada, tras la palabra clave SharedSection, hay tres entradas de memoriaseparadas por comas (en KB):

Memoria común (primera entrada)Define el tamaño del almacenamiento dinámico compartido común a todoslos escritorios (1024 en el ejemplo).


Memoria de escritorio interactiva (segunda entrada)Define la memoria adicional de almacenamiento dinámico de escritorioasignada a cada proceso interactivo (3072 en el ejemplo). Por ejemplo, eneste momento el proceso que se ejecuta como foreground (proceso defondo). Normalmente se ejecutan tres procesos interactivossimultáneamente.

Memoria de escritorio no interactiva (tercera entrada)Define la memoria adicional de escritorio asignada a procesos nointeractivos (512 en el ejemplo). Por ejemplo, cualquier proceso que seejecute en primer plano.

Los procesos de Tivoli Workload Scheduler utilizan los escritorios del siguientemodo:

Servicio Tivoli Netman de WindowsCrea un escritorio no interactivo compartido entre todos los agentes que seejecutan en el sistema físico.

Servicio Tivoli Token Service de WindowsCrea un escritorio no interactivo para TWSUser para cada agente.

Servicio Tivoli Workload Scheduler de WindowsCrea un escritorio no interactivo para TWSUser para cada agente.

Gestor de trabajos (jobmon.exe)Crea un escritorio no interactivo para todos los trabajos iniciados por cadaagente.

Por lo tanto, para cada agente adicional, se crean tres escritorios no interactivos. Elproblema se produce cuando Windows utiliza toda la memoria para crearescritorios.

Soluciones

Para reducir el riesgo de que un proceso de Tivoli Workload Scheduler noencuentre suficiente memoria para crear un escritorio, realice una, o varias, deestas tareas:v “Modifique los tamaños de almacenamiento intermedio de almacenamiento

dinámico compartido”v “Configure el servicio Tivoli Workload Scheduler de Windows para que se inicie

como una cuenta del sistema local” en la página 47v “Personalice el nombre del escritorio para que se pueda reutilizar” en la página

47

Modifique los tamaños de almacenamiento intermedio dealmacenamiento dinámico compartido

Si reduce el tamaño de la memoria común o interactiva, deja más memoriadisponible para escritorios no interactivos. Sin embargo, la reducción de lostamaños de cualquiera de estos puede ocasionar problemas de rendimiento.Microsoft establece estos valores de forma predeterminada porque las pruebasmuestran que son los valores necesarios. No se recomienda cambiar estos valores.

La reducción de la memoria utilizada para un escritorio no interactivo permite lacreación de más escritorios. Los procesos individuales que necesitan más memoria


pueden verse afectados, pero la mayoría de los procesos se ejecutaráncorrectamente. Si la memoria de escritorio no interactiva predeterminada (terceraentrada) es 512, intente reducirla a 256. Consulte el apartado “Modifique lasentradas del registro de Windows para determinar el tamaño de almacenamientodinámico” en la página 48 para ver cómo se hace.

Configure el servicio Tivoli Workload Scheduler de Windowspara que se inicie como una cuenta del sistema local

De forma predeterminada, el servicio Tivoli Workload Scheduler de Windows seconfigura para TWSUser de cada agente. Al cambiarlo para que se inicie comocuenta del sistema local, solo se crea una instancia de escritorio en el sistema, nouno por agente. La solución se implementa del siguiente modo:v Para los agentes instalados con la versión 8.6 o posterior, este cambio se

consigue utilizando el parámetro de instalación opcional –sharedDesktop

v Para los agentes instalados con versiones anteriores, o para agentes yainstalados, realice el cambio manualmente. Consulte el apartado “Modifique laconfiguración del servicio de Windows” en la página 48 para ver cómo se hace.

Personalice el nombre del escritorio para que se puedareutilizar

Cuando Jobmon abre un escritorio, le asigna un nombre exclusivo, asegurándosede que se cree un escritorio diferente para cada agente. Sin embargo, si crea elescritorio utilizando el nombre de un escritorio que ya está abierto, el proceso seabre dentro del escritorio existente. Para evitarlo, tiene que personalizar el nombreque utiliza Jobmon cuando crea su escritorio. Si se utiliza el mismo nombre paratodos los agentes, cada instancia de Jobmon se abre en el mismo escritorio.

Para asegurar que esta opción resulte efectiva, el nombre suministrado debe ser elmismo para al menos dos de los agentes instalados. Cuantos más agentes seejecuten con el mismo escritorio compartido, más memoria habrá disponible parala creación del escritorio. Sin embargo, si hay demasiados agentes que utilizan elmismo escritorio compartido, puede verse reducida la capacidad de Windows degestionar los trabajos que se ejecutan correctamente en el escritorio compartido. Eneste caso, debe optar por un término medio. Por ejemplo si tuviera cuatro agentesinstalados en el mismo sistema, podría establecer dos pares que compartieran elmismo escritorio.

La solución se implementa del siguiente modo:v Para los agentes instalados con la versión 8.6 o posterior, este cambio se

consigue utilizando el parámetro de instalación opcional –sharedDesktop. Siañade esta opción sin argumento, la instalación aplica el nombrepredeterminado, TWS_JOBS_WINSTA. De lo contrario, especifique su propionombre, por ejemplo –sharedDesktop name="nombre de mi escritoriowindows".Consulte el apartado “Mandato twsClusterAdm con ejemplos de uso” en lapágina 13 para ver cómo se hace.

v Para los agentes instalados con versiones anteriores, o para agentes yainstalados, realice el cambio manualmente. Consulte el apartado “Modifiquelocalopts para suministrar un nombre de escritorio compartido” en la página 49para ver cómo se hace.

Apéndice. Resolución de problemas de tamaño de almacenamiento dinámico de escritorio en estaciones de trabajo con más de tres

agentes 47

Implementación de las soluciones

Hay varias soluciones posibles. Elija la que mejor se adapte a sus circunstancias:v “Modifique la configuración del servicio de Windows”v “Modifique las entradas del registro de Windows para determinar el tamaño de

almacenamiento dinámico”v “Modifique localopts para suministrar un nombre de escritorio compartido” en

la página 49

Modifique la configuración del servicio de Windows

Para modificar el servicio de Tivoli Workload Scheduler Windows para que se abracomo una cuenta local, haga lo siguiente:1. En el botón Inicio, seleccione el panel Servicios (por ejemplo, seleccione

Programas → Herramientas administrativas → Servicios)2. Seleccione el servicio Tivoli Workload Scheduler y realice una doble pulsación

sobre el mismo para editarlo3. Seleccione el separador Inicio de sesión

4. Pulse Cuenta de sistema local y luego Aplicar

5. Pulse con el botón derecho del ratón en el servicio y seleccione Detener

6. Cuando el servicio se haya detenido, pulse con el botón derecho del ratón sobreel mismo y seleccione Iniciar

7. Compruebe que el servicio se inicie correctamente y cierre la ventana Servicios.

Modifique las entradas del registro de Windows paradeterminar el tamaño de almacenamiento dinámico

Para modificar las entradas del registro de Windows para determinar el tamaño dealmacenamiento dinámico, ejecute regedit.exe y modifique la clave:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows

Los datos predeterminados para este valor de registro serán similares a los que semuestran a continuación (todo en una línea):%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

Los valores numéricos que van después de SharedSection= controlan el modo enque se asigna el almacenamiento dinámico del escritorio. Estos valoresSharedSection se especifican en kilobytes. Consulte el apartado “Descripción delproblema” en la página 45 para ver una descripción de los valores.

El tercer valor de SharedSection (512 en el ejemplo anterior) es el tamaño delalmacenamiento dinámico de escritorio para cada escritorio no interactivo.Disminuya el valor a 256 kilobytes.

Nota: Si se reduce alguno de los valores de SharedSection, aumentará el númerode escritorios que se pueden crear en las estaciones de la ventanacorrespondiente. Los valores más pequeños limitarán la cantidad deenganches, menús, series y ventanas que se crearán dentro de un escritorio.


Por otro lado, si se aumentan los valores de SharedSection, disminuirá lacantidad de escritorios que se pueden crear pero aumentará la cantidad deenganches, menús, series y ventanas que se pueden crear dentro de unescritorio. Este cambio solo entrará en vigor después de rearrancar los nodosdel clúster.

Modifique localopts para suministrar un nombre de escritoriocompartido

Para utilizar un nombre de escritorio compartido para un agente ya instalado, hagalo siguiente:1. Abra el archivo localopts correspondiente al agente en cuestión (consulte el

manual Tivoli Workload Scheduler: Guía de planificación e instalación para ver laubicación de este archivo)

2. Añada la clave jm windows station name = <my_name>. Asegúrese de que<my_name> sea el mismo nombre que se ha utilizado en otro agente paraguardar la memoria del escritorio.

3. Guarde el archivo.4. Detenga y reinicie Tivoli Workload Scheduler para que el cambio entre en

vigor.

Apéndice. Resolución de problemas de tamaño de almacenamiento dinámico de escritorio en estaciones de trabajo con más de tres

agentes 49

Avisos

Esta información ha sido desarrollada para productos y servicios ofrecidos enEE.UU. Es posible que en otros países IBM no ofrezca los productos, los servicios olas características que se describen en esta publicación. Consulte con elrepresentante local de IBM para obtener información sobre los productos yservicios actualmente disponibles en su zona. Cualquier referencia a un producto,programa o servicio de IBM no pretende afirmar ni implicar que sólo se puedautilizar ese producto, programa o servicio de IBM. En su lugar, se puede utilizarcualquier producto, programa o servicio funcionalmente equivalente que noinfrinja ningún derecho de propiedad intelectual de IBM. Sin embargo, laevaluación y la verificación del funcionamiento de cualquier producto, programa oservicio no IBM son responsabilidad del usuario.

IBM puede tener patentes o solicitudes de patentes pendientes que incluyan eltema principal descrito en esta publicación. La posesión de esta publicación noconfiere ninguna licencia sobre dichas patentes. Puede enviar las consultas sobrelicencias, por escrito, a:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785 EE.UU.

Para realizar consultas sobre licencias referentes a información de doble byte(DBCS), puede ponerse en contacto con el Departamento de Propiedad Intelectualde IBM de su país o escribir a:

IBM World Trade Asia CorporationLicensing2-31 Roppongi 3-chome, Minato-kuTokio 106, Japón

El párrafo siguiente no es aplicable al Reino Unido ni a ningún país o región endonde tales disposiciones sean incompatibles con la legislación local:

INTERNATIONAL BUSINESS MACHINES CORPORATION PROPORCIONAESTA PUBLICACIÓN "TAL CUAL", SIN GARANTÍA DE NINGUNA CLASE, NIEXPLÍCITA NI IMPLÍCITA, INCLUIDAS, PERO SIN LIMITARSE A ELLAS, LASGARANTÍAS IMPLÍCITAS DE NO VULNERACIÓN DE DERECHOS,COMERCIALIZACIÓN O IDONEIDAD PARA UN FIN DETERMINADO.

Algunos estados no permiten la exclusión de garantías explícitas o implícitas endeterminadas transacciones, por lo que es posible que esta declaración no seaaplicable en su caso.

Esta publicación puede contener inexactitudes técnicas o errores tipográficos.Periódicamente se efectúan cambios en la información aquí contenida; dichoscambios se incorporarán a las nuevas ediciones de la publicación. IBM puedeefectuar, en cualquier momento y sin previo aviso, mejoras y cambios en losproductos y programas descritos en esta publicación.


Las referencias hechas en esta publicación a sitios web que no son de IBM seproporcionan sólo para la comodidad del usuario y no constituyen un aval de esossitios web. La información contenida en esos sitios web no forma parte de lainformación del presente producto IBM. El usuario es responsable de la utilizaciónde dichos sitios web.

IBM puede utilizar o distribuir cualquier información que se le facilite de lamanera que considere adecuada, sin contraer por ello ninguna obligación con elremitente.

Los propietarios de una licencia de este programa que deseen obtener informaciónsobre él con el fin de permitir: (i) el intercambio de información entre programascreados de forma independiente y otros programas (incluido éste) y (ii) el usomutuo de la información intercambiada, deben ponerse en contacto con:

IBM Corporation2Z4A/10111400 Burnet RoadAustin, TX 78758 EE.UU.

Dicha información puede estar disponible, sujeta a los términos y condicionesapropiados, incluido en algunos casos el pago de una tarifa.

El programa bajo licencia descrito en esta publicación y todo el material bajolicencia asociado a él los proporciona IBM según los términos del Acuerdo deCliente de IBM, el Acuerdo Internacional de Programas Bajo Licencia de IBM ocualquier acuerdo equivalente entre el usuario e IBM.

La información referente a productos que no son de IBM procede de losproveedores de esos productos, de sus anuncios publicados o de otras fuentesdisponibles públicamente. IBM no ha probado esos productos y no puedeconfirmar la veracidad del rendimiento, la compatibilidad, ni ninguna otraafirmación relacionada con productos que no sean de IBM. Las preguntas sobre lascaracterísticas de productos que no sean de IBM deben dirigirse a los proveedoresde esos productos.

Este manual contiene ejemplos de datos e informes que se utilizan en operacionescomerciales diarias. Para ilustrarlos de la forma más completa posible, los ejemplosincluyen nombres de personas, empresas, marcas y productos. Todos estosnombres son ficticios y cualquier similitud con nombres y direcciones utilizadospor una empresa real es totalmente fortuita.

Marcas registradas

IBM, el logotipo de IBM e ibm.com son marcas registradas de InternationalBusiness Machines Corporation en Estados Unidos y/o en otros países. Si estos yotros términos propiedad de IBM aparecen marcados en su primera aparición conun símbolo de marca registrada (® o ™), significa que se trata de marcas registradaspropiedad de IBM en el momento de publicar esta información. Dichas marcasregistradas pueden también estar registradas o ser de legislación común en otrospaíses. Encontrará una lista actualizada de las marcas registradas de IBM en la webbajo "Copyright and trademark information" en http://www.ibm.com/legal/copytrade.shtml.


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

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

Adobe y todas las marcas registradas basadas en Adobe son marcas registradas deAdobe Systems Incorporated en Estados Unidos y/o en otros países.

Microsoft y Windows son marcas registradas de Microsoft Corporation en EstadosUnidos y/o en otros países.

Otros nombres de empresas, productos y servicios pueden ser marcas registradas omarcas de servicio de otros fabricantes.

Avisos 53

Índice

CaracteresEspeciales–ask, argumento de

twsClusterAdm.exe 18–changeResName, parámetro de

twsClusterAdm.exe 18–dll, parámetro de

twsClusterAdm.exe 17–force, argumento de

twsClusterAdm.exe 18–force, parámetro de

twsClusterAdm.exe 17–new, parámetro de

twsClusterAdm.exe 15–notwsinst, parámetro de

twsClusterAdm.exe 17–res, parámetro de

twsClusterAdm.exe 15–sharedDesktop, parámetro de

twsClusterAdm.exe 17–twsupd, argumento de

twsClusterAdm.exe 18–uninst, parámetro de

twsClusterAdm.exe 18–update, parámetro de

twsClusterAdm.exe 18

Aaccesibilidad viiiacción de recuperación en caso de

migración tras errorpermiso para 1

acción de retrotracción o de recuperaciónpermiso para 1

actualización 12agente de Tivoli Workload

Scheduler 12agente, instalación en una configuración

que detecta clústeres 10agente de Tivoli Workload Scheduler

actualizaciónen una configuración que detecta

clústeres 12instalación

en una configuración que detectaclústeres 10

ampliación del Administrador declústeres

instalación 28visión general 28

Separador Parámetros 28archivo localopts

modificación 27archivos de rastreo 30

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

archivos DLLITWSResources.dll 7ITWSWorkstationEx.dll 7

argumentos, a twsClusterAdm.exe 15ask, argumento de

twsClusterAdm.exe 18changeResName, parámetro de

twsClusterAdm.exe 18check_interval, argumento de


Cclu_offline.log 30clu_online.log 30cluster.log 30clústeres de Windows 2003

dónde encontrar más información 3compatibilidad

con versiones anteriores 4configuración 37Conman shut 25Conman start 25Consola de trabajo dinámica

accesibilidad viiiconsola del Administrador de clústeres,

utilización 26contenido, Windows 2003 Cluster

Enabler 7convenios utilizados en esta

publicación viii

Ddependencias de recursos del clúster 24

Dirección IP 24Disco físico 24Nombre de red 24

Dirección IP 24Disco físico 24disk, argumento de

twsClusterAdm.exe 15disponibilidad elevada

definición 1tipos de 1

DLLDLL de recursos personalizados 6

dll, parámetro de twsClusterAdm.exe 17DLL de recursos personalizados 6

puntos de entradaIsAlive 6Offline 6Online 6Terminate 7

domain, argumento detwsClusterAdm.exe 15, 18

Eejemplos

twsClusterAdm.exe 19error 1314 30estado abend 31

Ffailover, argumento de

twsClusterAdm.exe 16force, argumento de

twsClusterAdm.exe 18force, parámetro de

twsClusterAdm.exe 17formación viii

técnica viiiformación técnica viiiformación técnica de Tivoli viii

Ggestor de dominio de reserva

Tivoli Workload Scheduler 2gestor de dominio maestro 40

no permitido en el servidor virtual delclúster

motivos 4glosario viiigroup, argumento de


Hhosts, argumento de

twsClusterAdm.exe 15, 18

Iinstalación

agente de Tivoli WorkloadScheduler 10

ampliación del Administrador declústeres 28

instalación en un clúster 7requisitos previos 9Windows Cluster Enabler 7

instalación en un clúster 7ip, argumento de twsClusterAdm.exe 15Isalive, argumento de

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

JJob Scheduling Console

accesibilidad viii


Llookalive, argumento de


Mmandatos

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

local 26

Nname, argumento de

twsClusterAdm.exe 17net, argumento de

twsClusterAdm.exe 15new, parámetro de

twsClusterAdm.exe 15Nombre de red 24nombre instancia clúster

modificaciónen el archivo localopts 27en el script

ShutDown_clu.cmd 27en el script StartUp_clu.cmd 27

opción local 26nombre_instancia_recurso, argumento de

twsClusterAdm.exe 18nombre instancia recursos

cambio 26notwsinst, parámetro de

twsClusterAdm.exe 17nuevo_nombre_instancia_recurso,

argumento de twsClusterAdm.exe 19

Oopts, argumento de


Pparámetros, a twsClusterAdm.exe 15path, argumento de

twsClusterAdm.exe 17política de seguridad

Sustitución de una señal de nivel deproceso 9, 30

programa de utilidadShutdown.cmd 11

publicaciones viiipwd, argumento de


Rrequisitos previos 9res, parámetro de

twsClusterAdm.exe 15resname, argumento de

twsClusterAdm.exe 15resolución de problemas 29

archivos de rastreo 30error 1314 30estado abend 31Jobmon

volcado del núcleo 31resource, argumento de


Sscripts

ShutDown_clu.cmd 25StartUp_clu.cmd 25

Separador Parámetrosampliación del Administrador de

clústeres 28sharedDesktop, parámetro de

twsClusterAdm.exe 17ShutDown_clu.cmd 25Shutdown.cmd 11, 25ShutdownLwa.cmd 25sintaxis

twsClusterAdm.exe 14sistemas operativos 4StartUp_clu.cmd 25StartUp.cmd 25StartupLwa.cmd 25Sustitución de una señal de nivel de

procesopolítica de seguridad 9, 30

Ttcpport, argumento de

twsClusterAdm.exe 16Tivoli Workload Scheduler 36, 37, 40

acción de recuperación en caso demigración tras error 1

acción de retrotracción o derecuperación 1

ampliación del Administrador declústeres 28

instalación 28visión general 28

autenticación de la seguridad 5autorización 5clientes 36compatibilidad

con versiones anteriores 4componentes físicos 34configuración

con twsClusterAdm 13dependencias de recursos del

clúster 24desinstalación 29detención 25

mandato cluster res 26disco externo compartido 36

Tivoli Workload Scheduler (continuación)dónde encontrar más información 3,

37en entornos en clúster de

Windows 24entorno en clúster

integración en 3espera 37gestor de dominio de reserva 2gestor de dominio maestro 40

no permitido en el servidor virtualdel clúster 4

hacer que detecte clústeres 11HACMP 33, 34, 35inicio 25

mandato cluster res 26integración en

entorno en clúster 3limitaciones del diseño del

producto 4, 40línea de mandatos

no se pasa automáticamente fuerade línea durante una migracióntras error 4, 40

nodos 35nombre instancia recursos

cambio 26redes 36resolución de problemas 29

archivos de rastreo 30error 1314 30estado abend 31volcado del núcleo 31

Unix 33ventajas 33Windows 3Windows 2003 Cluster Enabler 5

componentes 5requisitos previos 4

tolerancia a erroresdefinición 1

toma de control 37tws_env.cmd 11twsClusterAdm

agente de Tivoli WorkloadScheduler 13

twsClusterAdm.exe 7, 11, 13argumentos 15ejemplos 19parámetros 15sintaxis 14

twsClusterAdmin.exenombre instancia clúster

opción local 26twshome, argumento de

twsClusterAdm.exe 15twsupd, argumento de


Uuninst, parámetro de

twsClusterAdm.exe 18Unix 33UNIX

dónde encontrar más información 37


update, parámetro detwsClusterAdm.exe 18

user, argumento detwsClusterAdm.exe 15, 18

Vvolcado del núcleo 31

WWindows 3Windows 2003 Cluster Enabler

componentes 5contenido 7

Windows 2003 y 2008 Cluster Enablercontenido

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

Windows Cluster Enablercomponentes

DLL de recursos personalizados 6instalación 7instalación en un clúster 7requisitos previos 9

Índice 57

��

Número de Programa: 5698-WSH

Impreso en España

SC11-3450-04

Spineinformation:

IBM

Tivo

liW

orkl

oad

Sche

dule

rVe

rsió

n8.

6En

torn

osen

clús

terd

eal

tadi

spon

ibili

dad

��

�

Entornos en clúster de alta disponibilidad - ibm.com · Información de soporte .....viii...

Documents

Transcript of Entornos en clúster de alta disponibilidad - ibm.com · Información de soporte .....viii...