Tivoli Workload Scheduler Guia de Planejamento e Instalação Versão 7.0

Transcrição

1 Tivoli Workload Scheduler Guia de Planejamento e Instalação Versão 7.0

2

3 Tivoli Workload Scheduler Guia de Planejamento e Instalação Versão 7.0

4 Tivoli Workload Scheduler - Guia de Planejamento e Instalação (Maio de 2000) Observações sobre Copyright Copyright 2000 pela Tivoli Systems Inc., uma Empresa IBM, incluindo esta documentação e todo o software. Todos os direitos reservados. Somente pode ser utilizado de acordo com um Contrato de Licença de Software do Tivoli Systems ou Adendo para Produtos Tivoli para o Cliente ou Contrato de Licença da IBM. Nenhuma parte dessa publicação poderá ser reproduzida, transmitida, transcrita, armazenada em um sistema de recuperação ou convertida em qualquer linguagem de computador, de qualquer forma ou em hipótese alguma, eletrônica, mecânica, magnética, óptica, química, manual ou do contrário, sem permissão expressa por escrito do Tivoli Systems. A Tivoli Systems concede ao Cliente permissão limitada para efetuar cópia impressa ou outras reproduções de qualquer documentação lida por máquina para seu próprio uso, contanto que cada uma contenha o aviso de copyright da Tivoli Systems. Não será concedido nenhum outro direito sob copyright sem permissão prévia por escrito da Tivoli Systems. O documento não é planejado para produção e é fornecido como está sem garantia de nenhum tipo. Todas as garantias neste documento são, por meio deste, rejeitadas incluindo as garantias de mercado e adequação a um determinado objetivo. Marcas Os nomes de produtos a seguir são marcas da Tivoli Systems ou IBM Corporation: AIX, IBM, OPC, OS/390 e Tivoli. Tivoli é uma marca ou marca registrada da Tivoli Systems Inc. nos Estados Unidos e/ou em outros países. Na Dinamarca, a Tivoli é uma marca licenciada da Kjøbenhavns Sommer - Tivoli A/S. Microsoft, Windows, Windows NT e o logotipo Windows são marcas ou marcas registradas da Microsoft Corporation nos Estados Unidos e/ou em outros países. UNIX é uma marca registrada nos Estados Unidos e em outros países, licenciada exclusivamente através da The Open Group. Java e todas as marcas baseadas em Java ou logotipos são marcas da Sun Microsystems, Inc. nos Estados Unidos e/ou em outros países. Outra companhia, produto e nomes de serviço mencionados neste documento podem ser marcas ou marcas de serviço de terceiros. Observações Referências nesta publicação a produtos, programas ou serviços da Tivoli Systems ou IBM não significam que a Tivoli Systems ou a IBM pretendam torná-los disponíveis em todos os países onde operam. Qualquer referência a estes produtos, programas ou serviços da Tivoli Systems ou da IBM não significa que apenas os produtos, programas ou serviços da Tivoli Systems ou da IBM possam ser utilizados. Qualquer produto, programa ou serviço funcionalmente equivalente, que não infrinja nenhum direito de propriedade intelectual da IBM ou da Tivoli Systems ou outros direitos legalmente protegidos, poderá ser utilizado em substituição a este produto, programa ou serviço. A avaliação e verificação da operação em conjunto com outros produtos, exceto aqueles expressamente designados pela Tivoli Systems ou pela IBM, são de inteira responsabilidade do Cliente. O Tivoli Systems ou a IBM podem ter patentes ou solicitações de patentes relativas a assuntos tratados nesta publicação. O fornecimento desta publicação não garante ao Cliente nenhum direito sobre tais patentes. Pedidos de licença devem ser enviados, por escrito, à Gerência de Relações Comerciais e Industriais da IBM Brasil, Av. Pasteur, , Botafogo, CEP , Rio de Janeiro, RJ.

5 Índice Prefácio... Quem Deve Utilizar Este Guia... ix Pré-Requisitos e Documentos Relacionados... ix O Que Contém Este Guia... x Informações Específicas da Plataforma... x Como Entrar em Contato com o Suporte ao Cliente... xi Capítulo 1. Introdução... 1 Tivoli Workload Scheduler O que Há de Novo com o Tivoli Workload Scheduler Planejamento da Rede... 9 Visão Geral da Rede do TWS Funcionalidade de Domínio Processamento Localizado no Domínio Considerações sobre Redes Uma Rede de Domínio Simples Uma Rede de Domínio Múltiplo Como ir para o Gerenciador de Domínio de Backup Banco de Dados Expandido e Nomes de Objetos Longos Nomes de Estação de Trabalho Visão Geral da Instalação Grupos de Produtos Arquivo de Componentes Diretório Pessoal do Netman Após a Instalação Capítulo 2. Como Instalar o Mecanismo do TWS no Windows NT ix Tivoli Workload Scheduler Guia de Planejamento e Instalação iii

6 Requisitos do Sistema Como Preparar para uma Atualização Como Desligar e Encerrar o TWS Arquivos de Backup Como Instalar o Software O Programa de Instalação Como Executar a Instalação Como Continuar a Instalação e Atualização Como Concluir uma Atualização Como Definir a Variável PATH Diretórios e Serviços do TWS Como Configurar a Administração Descentralizada Como Criar a Conta do TWS Manualmente Tipos de Administração do TWS Como Remover a Instalação do TWS Como Utilizar a Ferramenta de Inclusão/Remoção do Windows NT O Programa Uninstal.exe Capítulo 3. Como Instalar o Mecanismo do TWS no UNIX Requisitos do Sistema Procedimento de Instalação Como Instalar o Mecanismo do Tivoli Workload Scheduler Etapas de Configuração Como Atualizar o Tivoli Workload Scheduler Preparação-Parar o TWS Backup Atualizar o Software e Executar Personalização Atualizar Perfil de Segurança iv Versão 7.0

7 Restaurar Arquivos Reinicializar o TWS O Script de Personalização Como Remover a Instalação do TWS Capítulo 4. Como Definir a Segurança do TWS Como Editar o Arquivo de Segurança Capítulo 5. Como Instalar o Conector do TWS Antes da Instalação Requisitos do Sistema Plataformas Suportadas Procedimento de Instalação Como Instalar o Job Scheduling Services (JSS) Como Instalar o Conector do TWS Como Instalar as Correções do JSS e do Conector do TWS Como Atualizar a Segurança do TWS Como Remover a Instalação do Conector do TWS Como Remover a Instalação do Servidor JSS Comandos Úteis do Framework Capítulo 6. Como Instalar o Tivoli Job Scheduling Console Requisitos do Sistema Plataformas Suportadas Pré-requisitos para HP-UX e AIX Como Instalar o Job Scheduling Console Como Iniciar o Job Scheduling Console Como Remover a Instalação do Job Scheduling Console Tivoli Workload Scheduler Guia de Planejamento e Instalação v

8 Remoção da Instalação do UNIX Remoção da Instalação do Windows Capítulo 7. Tópicos de Personalização do TWS Opcionais Como Definir Opções Globais Como Definir Opções Locais Como Automatizar o Ciclo de Produção Como Personalizar o Fluxo de Job final Como Adicionar o Fluxo de Job final Como Iniciar um Ciclo de Produção Como Gerenciar o Ambiente de Produção Como Escolher o Início do Dia do TWS Como Alterar o Início do Dia Como Criar um Plano para Datas Futuras ou Passadas Apêndice. Como Migrar para o TWS O Tivoli Management Framework para usuários não-tivoli Considerações de Instalação Onde o JS Console Client Pode Ser Instalado Onde os Conectores do TWS Devem Ser Instalados Considerações de Backup Mestre Como Lidar com Mestres de Escalão diferentes de 1 em uma Rede do Maestro Existente Como Mover um Backup Mestre Com Criar um Backup Mestre Como Montar Bancos de Dados do MDM Como Lidar com Backups Mestres de Escalão diferentes de 1 em uma Rede do Maestro Existente Como Executar Várias Janelas no JS Console vi Versão 7.0

9 Como Criar um Trabalho de Arquivo de Segurança Existente Como Incluir Administradores TME Como Gerenciar a Segurança Como Encerrar os Conectores para Implementar Alterações Limitações da GUI Existente Como Utilizar a GUI Existente no AIX Considerações de Fuso Horário Como Propagar Preferências de Usuários para Outros Usuários (Personalizar Exibições/Consultas) Como Restaurar um Banco de Dados Expandido Como Migrar no Windows NT Como Migrar do Maestro 5.2 em Agentes do Windows NT Apêndice. Sistema de Redes com o MPE Considerações sobre Redes Considerações sobre Planejamento Instalação Instalação e Configuração Como Configurar um agente UNIX com o MPE Mestre Como Configurar um MPE FTA com o UNIX ou Windows NT Diferenças Operacionais Entre as Plataformas No MPE Mestre Em Agentes de Tolerância a Falhas do UNIX No UNIX ou Windows NT Mestre Nos MPEs Dependentes Glossário Índice Remissivo Tivoli Workload Scheduler Guia de Planejamento e Instalação vii

10 viii Versão 7.0

11 Prefácio O Tivoli Workload Scheduler - Guia de Planejamento e Instalação fornece informações sobre como instalar uma rede do Tivoli Workload Scheduler 7.0. Isto inclui informações sobre como planejar uma rede, instalar o mecanismo do TWS, software do conector e a interface gráfica com o usuário.ele também fornece instruções para personalizar opções e segurança do TWS para iniciar uma rede do TWS. Finalmente, fornece dicas e informações sobre como migrar de versões anteriores do Maestro. Quem Deve Utilizar Este Guia Este manual é intencionado ao seguinte público: Administradores TWS - aqueles que planejam o layout da rede do TWS. Instaladores - aqueles que instalam os vários pacotes de software nos computadores que constituem a rede do TWS. Pré-Requisitos e Documentos Relacionados A seguir encontram-se os documentos relacionados: Tivoli Workload Scheduler - Guia do Usuário Fornece informações sobre como configurar e utilizar o Tivoli Workload Scheduler. Ele contém informações sobre redes do TWS, segurança, arquivos de opções globais e locais, uma visão geral do ciclo de produção e descrições de tarefas do banco de dados e do plano. Tivoli Workload Scheduler - Manual de Referência Fornece informações sobre as interfaces de linha de comandos do Tivoli Workload Scheduler, incluindo composer, conman, o idioma de planejamento e comandos utilitários. Tivoli Workload Scheduler Guia de Planejamento e Instalação ix

12 O Que Contém Este Guia O Tivoli Workload Scheduler - Guia de Planejamento e Instalação contém o seguinte: Capítulo 1, Introdução Fornece informações sobre planejamento para configurar uma rede do TWS e uma visão geral do processo de instalação. Capítulo 2, Como Instalar o Mecanismo do TWS no Windows NT Explica como instalar o mecanismo do TWS no Windows NT. Capítulo 3, Como Instalar o Mecanismo do TWS no UNIX Explica como instalar o mecanismo do TWS no UNIX. Capítulo 4, Como Configurar a Segurança do TWS Explica como personalizar o arquivo de Segurança. Capítulo 5, Como Instalar o Conector do TWS Explica como instalar o Conector do TWS. Capítulo 6, Como Instalar o Job Scheduling Console Explica como instalar o Job Scheduling Console. Capítulo 7, Tópicos de Personalização do TWS Opcionais Descreve as opções de personalização para uma rede do TWS. Apêndice A, Como Migrar para o TWS 7.0 Fornece informações úteis para migrar do Maestro 5.x e 6.x. Informações Específicas da Plataforma A tabela a seguir identifica as versões suportadas para cada uma das plataformas listadas conhecidas no momento da publicação. Para obter informações mais detalhadas e atualizadas, consulte o Tivoli Workload Scheduler - Notas sobre Release. Plataforma Mecanismo do TWS Conector do TWS AIX 4.2 X X X JS Console x Versão 7.0

13 Plataforma Mecanismo do TWS Conector do TWS AIX 4.3 X X X HP-UX X X X HP-UX 11.0 X X X Solaris 2.6 X X X Solaris 2.7 X X X Windows NT 4.0 X X X w/ SP 4 ou superior Windows 2000 X Digital UNIX X Plataformas em conformidade com a Intel ABI X Plataformas em conformidade com MIPS ABI X JS Console Nota: No AIX 4.3, você deve instalar a correção bos.rte.commands bff. Para saber se essa correção já está ou não instalada em seu sistema, execute o seguinte comando: lslpp -l bos.rte.commands Se o comando retornar um valor abaixo de , você deverá instalar a correção. Como Entrar em Contato com o Suporte ao Cliente Se você está autorizado a receber o suporte ao cliente Tivoli, poderá encontrar informações atualizadas com freqüência sobre a configuração e utilização dos produtos Tivoli na home page do Tivoli Customer Support no endereço Este site inclui os seguintes links: Tivoli Workload Scheduler Guia de Planejamento e Instalação xi

14 Versões atualizadas destas notas sobre o release: Versões atualizadas da documentação do Tivoli: Bancos de Dados de suporte para pesquisa: Acesso a correções do produto: Acesso a agendas de treinamento: Acesso à análise da documentação do Tivoli: Visite o site Tivoli Customer Support para obter essas informações e assistência adicional a clientes. Essas URLs requerem uma senha e um ID. Se não tiver privilégios de acesso ou estiver inseguro sobre seu ID ou senha, envie um para o Customer_Support_Web_Registration@tivoli.com. Coloque seu nome e o nome de sua empresa nesta correspondência. Você pode solicitar cópias adicionais da documentação do produto enviando um ou chamando uma das seguintes localizações: do Cliente nos Estados Unidos: swdist@tivoli.com Telefone nos Estados Unidos: Telefone no Canadá: Telefone Internacional: (770) Forneça o título e o número da versão do documento que está sendo solicitado. xii Versão 7.0

15 1 1. Introdução Introdução Este guia contém instruções para instalação e atualização do Tivoli Workload Scheduler 7.0. Tivoli Workload Scheduler 7.0 O Tivoli Workload Scheduler 7.0 é composto de três partes: Mecanismo do Tivoli Workload Scheduler O produto Maestro existente. Instale o Mecanismo no Mestre e em todas as CPUs do Agente físico. Conector do TWS Mapeia comandos do Job Scheduling Console para o Mecanismo do TWS. Instale o Conector do TWS no Mestre e em quaisquer agentes de tolerância a falhas (FTA) que irá utilizar como máquinas backup para a CPU Mestre. O Conector requer anteriormente que o Tivoli Management Framework (TMF) seja configurado para um servidor ou nó gerenciado Tivoli Management Region (TMR). Job Scheduling (JS) Console Uma interface gráfica com o usuário (GUI) baseada em Java para o TWS. Instale o JS Console em qualquer máquina a partir da qual deseja gerenciar objetos de plano e do banco de dados do TWS. O JS Console não requer que o Mecanismo do TWS ou que o Conector do TWS seja instalado na mesma máquina. Você pode utilizar o JS Tivoli Workload Scheduler Guia de Planejamento e Instalação 1

16 Tivoli Workload Scheduler 7.0 Console a partir de qualquer máquina, contanto que ele tenha um link do TCP/IP com a máquina executando o Conector do TWS. Uma rede do TWS é constituída de estações de trabalho ou CPUs, nas quais jobs e fluxos de job são executados. Primeiramente, as definições da estação de trabalho referem-se às estações de trabalho físicas. Entretanto, no caso de agentes estendidos e agentes de rede, as estações de trabalho são definições lógicas que devem ser alojadas por uma estação de trabalho do TWS física. Uma rede do Tivoli Workload Scheduler 7.0 é criada dos seguintes tipos de estações de trabalho: Gerenciador de Domínio Mestre (MDM) O gerenciador de domínio no domínio mais elevado de uma rede do TWS. Ele contém os arquivos do banco de dados centralizado utilizados para documentar objetos de planejamento. Ele cria o plano de Produção no início de cada dia e executa todo registro e relatório da rede. Backup Mestre Um agente de tolerância a falhas capaz de assumir as responsabilidades do gerenciador de domínio mestre. Gerenciador de Domínio O hub de gerenciamento em um domínio. Todas as comunicações para e dos agentes em um domínio são roteadas através do gerenciador de domínio. Gerenciador de Domínio de Backup Um agente de tolerância a falhas capaz de assumir as responsabilidades do gerenciador de domínio. Agente de Tolerância a Falhas (FTA) Uma estação de trabalho capaz de resolver dependências locais e lançar seus jobs na ausência de um gerenciador de domínio. 2 Versão 7.0

17 Tivoli Workload Scheduler 7.0 Agente Padrão Uma estação de trabalho que lança jobs somente na direção de seu gerenciador de domínio. Agente Estendido Uma definição da estação de trabalho lógica que permite que você lance e controle jobs em outros sistemas e aplicativos, tais como Baan, Peoplesoft, Oracle Applications, SAP e MVS JES2 e JES3. Agente de Rede Uma definição da estação de trabalho lógica para criação de dependências entre jobs e fluxos de job em redes TWS separadas. Cliente do JS Console Qualquer estação de trabalho que executa a interface gráfica com o usuário a partir da qual os programadores e operadores podem gerenciar objetos de plano e do banco de dados do TWS. 1. Introdução Tipo de estação de trabalho Gerenciador de Domínio Mestre A tabela a seguir resume qual componente do TWS 7.0 se aplica a que tipo de estação de trabalho: Mecanismo de TWS Conector do TMF/TWS JS Console Sim Sim Opcional Backup Mestre Sim Sim Opcional Gerenciador de Domínio Sim Opcional Opcional Gerenciador de Domínio Sim Opcional Opcional de Backup Agente de Tolerância a Sim Opcional Opcional Falhas Agente Padrão Sim Não Opcional Agente Estendido Não Aplicável Não Aplicável Não Aplicável Agente de Rede Não Aplicável Não Aplicável Não Aplicável Cliente do JS Console Não Não Sim Tivoli Workload Scheduler Guia de Planejamento e Instalação 3

18 Tivoli Workload Scheduler 7.0 O que Há de Novo com o Tivoli Workload Scheduler 7.0 O TWS 7.0 inclui os seguintes novos recursos: Integração com o Tivoli Management Region Utilização de uma nova interface gráfica com o usuário Auditoria Internacionalização Fusos Horários O Tivoli Management Framework A nova versão do TWS requer que você instale o Tivoli Management Framework pelo menos na CPU Mestre e no FTA designados como seu backup. Isso tem duas razões principais: 1. O Conector é um produto baseado em Framework. Ele é baseado no Job Scheduling Services (JSS), que fornece uma interface de estrutura comum para aplicativos de planejamento do job. Os conectores para TWS e para OPC compartilham uma fundação comum do JSS, que é, por sua vez, baseada no Tivoli Management Framework. Isso permite que usuários do TWS e do OPC acessem os mecanismos de planejamento do job através de uma interface comum, o JS Console. 2. Visto que o Mestre e pelo menos um FTA de backup deve ser instalado em máquinas que executam o TMF, a rede do TWS compartilha os benefícios de gerenciamento de empresa baseado no Framework. Você pode optar por instalar o Mestre em um servidor TMR independente ou em um nó gerenciado que pertence a um Tivoli Management Region maior. Neste caso, o nó gerenciado pode ser o cliente de um número de outros serviços do Tivoli nas áreas de distribuição, administração ou disponibilidade. Em qualquer caso, o Mestre eoftadebackup irão se beneficiar com as capacidades de segurança e administrativas do Tivoli Management Framework. 4 Versão 7.0

19 Tivoli Workload Scheduler 7.0 O Job Scheduling Console O Job Scheduling Console é uma interface gráfica com o usuário a partir da qual você pode gerenciar objetos de plano e do banco de dados. Ele fornece, através do Conector do TWS, funcionalidade Conman e Composer. Ele pode executar ambos independente ou simultaneamente com as interfaces de linha de comandos (CLI). Enquanto a utilização de comandos CLI é limitada para CPUs do TWS, você pode instalar o JS Console em máquinas fora da rede do TWS. Para executar o JS Console, você tem que conseguir somente iniciar sessão em uma CPU do TWS que executa o Conector. Isto significa que você pode gerenciar objetos de plano e do banco de dados não somente a partir de CPUs do Mestre ou do Agente, mas também a partir de qualquer sistema, incluindo um laptop no qual o JS Console está instalado e a partir do qual você pode alcançar usando o TCP/IP, o Mestre ou o FTA que executa o Conector. 1. Introdução Do mesmo Job Scheduling Console, é possível também gerenciar objetos de plano e do banco de dados de Planejamento e Controle de Operações (OPC) do Tivoli, desde que você possa iniciar uma sessão em uma máquina que executa o Conector OPC. A instalação do JS Console é explicada com detalhes em Como Instalar o Tivoli Job Scheduling Console na página 105. A figura a seguir mostra as relações entre o Tivoli Management Framework, o Job Scheduling Services, o TWS, mecanismos de Tivoli Workload Scheduler Guia de Planejamento e Instalação 5

20 Tivoli Workload Scheduler 7.0 planejamento do job do OPC e o JS Console. Terminologia do JS Console A terminologia utilizada no Job Scheduling Console difere daquela utilizada na linha de comandos e versões anteriores do Workload Scheduler. A tabela a seguir lista os termos antigos e seus equivalentes do Job Scheduling Console. Consulte o glossário para obter mais definições. Linha de Comandos Job Scheduling Definição Console Schedule Fluxo de Job Uma unidade de trabalho que consiste em um conjunto de jobs e suas dependências. Ocorrência do Fluxo de Job A ocorrência de um fluxo de job no plano. Job Job Um arquivo executável, tarefa ou comando e seus atributos. É planejado para ser executado como parte de um fluxo de job. Ocorrência do Job A ocorrência de um job no plano. 6 Versão 7.0

21 Tivoli Workload Scheduler 7.0 Linha de Comandos Job Scheduling Definição Console Cpu Estação de Trabalho Um processador lógico tipicamente um computador que executa jobs. Tipos de estações de trabalho incluem Gerenciadores de Domínio, Gerenciadores de Domínio de Backup, Agentes de Tolerância a Falhas, Agentes Padrão e Agentes Estendidos. Arquivos Mozart Banco de Dados Uma coleção de objetos de planejamento incluindo jobs, fluxos de job, parâmetros, calendários e recursos. Ele é acessado pelo composer, anteriormente conhecido como gcomposer. Arquivo Symphony Plano A atividade planejada por um período, geralmente 24 horas. O plano é continuamente atualizado para mostrar o status atual de todas as atividades do Workload Scheduler. Ele é acessado pelo conman, anteriormente conhecido como gconman. Hora AT Hora de Início A primeira hora em que um job ou fluxo de job será iniciado. Hora UNTIL Tempo Final A última hora em que um job ou fluxo de job iniciará a execução. Datas ON e EXCEPT Ciclos de Execução As datas em que um fluxo de job é executado ou excluído da execução. 1. Introdução Auditoria Uma opção de auditoria foi implementada para rastrear as alterações no banco de dados e no plano: Para o banco de dados, todas as modificações do usuário são registradas. No entanto, o delta das modificações, ou imagem anterior e imagem posterior, não serão registrados. Se um objeto for aberto e salvo, a ação será registrada mesmo se nenhuma modificação tiver sido feita. Tivoli Workload Scheduler Guia de Planejamento e Instalação 7

22 Tivoli Workload Scheduler 7.0 Para o plano, todas as modificações feitas no plano pelo usuário são registradas. As ações são registradas, quer obtenham ou não êxito. Os logs de auditoria são criados nos seguintes diretórios: TWShome/audit/plan TWShome/audit/database Os arquivos de auditoria são registrados em um arquivo de texto simples em máquinas individuais na rede do TWS. Isso minimiza o risco de falha de auditoria devido a problemas na rede e permite uma abordagem direta na gravação do log. Geralmente os formatos de log são os mesmos para o plano e o banco de dados. Os logs consistem em uma parte de cabeçalho que é igual para todos os registros, um ID da ação e uma seção dos dados que variam de acordo com o tipo de ação. Todos os dados são mantidos em texto limpo e formatados para serem legíveis e editáveis em um editor de texto, tais como vi ou bloco de notas. Consulte o TWS - Guia do Usuário para obter detalhes sobre a definição do recurso de auditoria. Internacionalização O TWS 7.0 é convertido em vários idiomas diferentes do inglês. São eles: alemão, francês, italiano, espanhol, português do Brasil, chinês, coreano e japonês. Considerações sobre Fuso Horário O suporte ao fuso horário é um recurso que pode ser ativado ou desativado. Os fusos horários serão ativados se o sinalizador de ativação de fuso horário no arquivo globalopts estiver definido como sim e se a estação de trabalho mestre tiver uma definição de fuso horário. Os fusos horários são desativados, por padrão, na instalação do produto. Se os fusos horários forem ativados, os campos de fuso horário no Scheduling Console serão ativados. Se você deixar um fuso horário 8 Versão 7.0

23 Tivoli Workload Scheduler 7.0 de definição de estação de trabalho em branco, será assumido como padrão o fuso horário da estação de trabalho do gerenciador de domínios mestre. Se os fusos horários forem desativados, todos os campos de fuso horário serão desativados por meio do aplicativo. No composer e conman, ocorrerá um erro, se você tentar especificar um fuso horário junto com uma hora. No Job Scheduling Console, os campos de fuso horário são desativados para o banco de dados e o plano. A única exceção para isso são as estações de trabalho no banco de dados, que têm fusos horários sempre ativados. 1. Introdução Ao ativar o fuso horário para a estação de trabalho mestre, recomenda-se que você digite um fuso horário para os FTAs que não estejam no mesmo fuso horário que o mestre. Supõe-se que um fuso horário de FTA em branco seja igual ao fuso horário mestre. Quando os fusos horários tiverem sido ativados, você pode digitar um fuso horário juntamente com uma hora no conman, composer ou no Job Scheduling Console. Se você digitar uma hora sem fuso horário, o fuso horário será obtido da estação de trabalho na qual o job ou fluxo de job é executado, ou do fuso horário da estação de trabalho mestre se o fuso horário da estação de trabalho em execução estiver em branco. Planejamento da Rede Antes de começar a instalar o Tivoli Workload Scheduler, determine as respostas para as perguntas a seguir. As próximas seções fornecem informações para ajudá-lo a determinar as respostas que melhor se adequam às suas necessidades. 1. Você irá utilizar estrutura de rede de múltiplos domínios ou de um único domínio? 2. Se utilizar múltiplos domínios, como irá dividir seus domínios: por localizações geográficas, por exemplo, domínios de Londres e Paris? Tivoli Workload Scheduler Guia de Planejamento e Instalação 9

24 Planejamento da Rede por fuso horário, por exemplo, Hora Local do Pacífico (pst) e Hora Local do Leste (est)? por unidade de negócios, por exemplo marketing e contabilidade? 3. Você irá utilizar bancos de dados expandidos ou não-expandidos? 4. Você irá ativar o recurso de fuso horário? Visão Geral da Rede do TWS Uma rede do Workload Scheduler contém pelo menos um domínio do Workload Scheduler, o domínio mestre, no qual o gerenciador de domínio mestre é o hub de gerenciamento. Os domínios adicionais podem ser utilizados para dividirem uma rede amplamente distribuída em grupos gerenciados menores e localmente. Utilizar múltiplos domínios reduz a quantidade de tráfego de rede, por meio da redução das comunicações entre o gerenciador de domínio mestre e outros computadores. Em uma configuração de domínio simples, o gerenciador de domínio mestre mantém comunicações com todas as estações de trabalho na rede do Workload Scheduler. Em uma configuração de domínio múltiplo, o gerenciador de domínio mestre comunica-se com as estações de trabalho em seu domínio e subordina gerenciadores de domínio. Os gerenciadores de domínio subordinados, por sua vez, comunicam-se com as estações de trabalho em seus domínios e subordinam gerenciadores de domínio. Os domínios múltiplos também fornecem tolerância a falhas limitando os problemas causados pela perda de um gerenciador de domínio para um único domínio. Para limitar os efeitos adicionais, é possível designar gerenciadores de domínio de backup para assumirem no caso dos gerenciadores de domínio falharem. Funcionalidade de Domínio Quando você define um novo domínio, é necessário identificar o domínio pai e o gerenciador de domínio. O domínio pai é o domínio 10 Versão 7.0

25 Planejamento da Rede diretamente acima do novo domínio na hierarquia de domínio. Todas as comunicações para e de um domínio são roteadas através do gerenciador de domínio pai. Antes do início de cada novo dia, o gerenciador de domínio pai cria um arquivo de controle de produção, chamado Symphony. Em seguida, o Tivoli Workload Scheduler é reiniciado na rede e o gerenciador de domínio mestre envia uma cópia do novo arquivo Symphony para cada um de seus agentes ligados automaticamente e gerenciadores de domínio subordinados. Os gerenciadores de domínio, por sua vez, envia cópias para seus agentes ligados automaticamente e gerenciadores de domínio subordinados. 1. Introdução Quando a rede é iniciada, as mensagens de planejamento como inícios e conclusões dos jobs são transmitidas dos agentes para seus gerenciadores de domínio, através dos gerenciadores de domínio pai para o gerenciador de domínio mestre. Em seguida, o gerenciador de domínio mestre difunde as mensagens através da árvore hierárquica, para atualizar os arquivos Symphony de gerenciadores de domínio e de agentes de tolerância a falhas sendo executados no modo Status Completo. Processamento Localizado no Domínio Uma chave para escolher como configurar os domínios do Tivoli Workload Scheduler é o conceito do processamento localizado. A idéia é separar ou localizar suas necessidades de planejamento baseadas em um conjunto comum de características. As características comuns são itens, tais como localizações geográficas, funções de negócios e agrupamentos de aplicativos. O processamento relacionado ao agrupamento pode limitar a quantidade de informações de interdependência que precisa ser comunicada entre domínios. Os benefícios do processamento de localização em domínios são: Tráfego de rede diminuído. Manter o processamento localizado para domínios elimina a necessidade de comunicações freqüentes entre domínios. Tivoli Workload Scheduler Guia de Planejamento e Instalação 11

26 Planejamento da Rede Fornece uma maneira conveniente de ajustar a segurança e simplificar a administração. A segurança e a administração podem ser definidas e limitadas, no nível de domínio. Em vez da administração ampla da rede ou específica da estação de trabalho, você pode ter a administração de domínio. A tolerância a falhas da rede e da estação de trabalho pode ser otimizada. Em uma rede do de múltiplo domínio, é possível definir backups para cada gerenciador de domínio, para que os problemas em um domínio não interrompam operações em outros domínios. Considerações sobre Redes As perguntas a seguir irão ajudar a tomar decisões sobre como configurar a rede do Tivoli Workload Scheduler. Algumas perguntas envolvem aspectos da rede e outros envolvem os aplicativos controlados pelo Tivoli Workload Scheduler. É possível consultar outras pessoas em sua organização para resolver alguns assuntos. Qual o tamanho da rede do Tivoli Workload Scheduler? Quantos computadores ela contém? Quantos aplicativos e jobs ela executa? O tamanho da rede irá ajudá-lo a decidir se vai utilizar um domínio simples ou uma arquitetura de múltiplo domínio. Se você tiver um número pequeno de computadores ou um número pequeno de aplicativos para controlar com o Tivoli Workload Scheduler, pode não ser uma necessidade ter múltiplos domínios. Quantas localizações geográficas serão abrangidas na rede do Tivoli Workload? Quão confiável e eficiente é a comunicação entre as localizações? Este é um dos motivos principais para escolher uma arquitetura de múltiplo domínio. Um domínio para cada localização geográfica é uma configuração comum. Se você escolher a arquitetura de domínio simples, ficará mais confiante na rede para manter o processamento contínuo. Você precisa de gerenciamento centralizado ou descentralizado do Tivoli Workload Scheduler? 12 Versão 7.0

27 Planejamento da Rede Uma rede do Tivoli Workload Scheduler, com um domínio simples ou múltiplos domínios, concede a você a capacidade de gerenciar o Tivoli Workload Scheduler a partir de um nó simples do gerenciador de domínio mestre. Se desejar gerenciar múltiplas localizações separadamente, será possível considerar a instalação de uma rede separada do Tivoli Workload Scheduler em cada localização. Observe que algum grau de gerenciamento descentralizado é possível em uma rede independente do Tivoli Workload Scheduler através da montagem ou compartilhamento de sistemas de arquivos. 1. Introdução Você possui várias entidades físicas ou lógicas em um único site? Existem edifícios diferentes e vários andares em cada edifício? Existem diferentes departamentos ou funções de negócios? Existem diferentes aplicativos? Podem existir motivos para escolher uma configuração de domínio múltiplo. Por exemplo, um domínio para cada edifício, departamento, função da empresa ou cada aplicativo (industrial, financeiro, engenharia, etc.). Você executa aplicativos, como SAP R/3 ou Baan, que irão operar com o Tivoli Workload Scheduler? Se eles forem distintos e separados de outros aplicativos, você poderá optar por colocá-los em um domínio separado do Tivoli Workload Scheduler. Deseja que os domínios do Tivoli Workload Scheduler se espelhem nos domínios do Windows NT? Isso não é requerido, mas pode ser útil. Deseja isolar ou diferenciar um conjunto de sistemas baseado no desempenho ou em outros critérios? Isso pode fornecer outro motivo para definir múltiplos domínios do Tivoli Workload Scheduler, para localizar sistemas baseados no desempenho ou tipo de plataforma. Quanto tráfego de rede você possui agora? Se o tráfego de rede for gerenciável, a necessidade de múltiplos domínios será menos importante. Tivoli Workload Scheduler Guia de Planejamento e Instalação 13

28 Planejamento da Rede As dependências do sistema cruzam limites do sistema, limites geográficos ou limites de aplicativos? Por exemplo, o início do Job1 na CPU3 depende da conclusão do Job2 sendo executado na CPU4? O grau de interdependência entre jobs é uma consideração importante ao se preparar a rede do Tivoli Workload Scheduler. Se você utilizar múltiplos domínios, deverá tentar manter objetos interdependentes no mesmo domínio. Isso irá diminuir o tráfego de rede e tirar melhor vantagem da arquitetura de domínio. Qual nível de tolerância a falhas você requer? Uma desvantagem óbvia da configuração de domínio simples é a confiança em um gerenciador de domínio simples. Em uma rede de domínio múltiplo, a perda de um gerenciador de domínio simples afeta somente os agentes em seu domínio. Uma Rede de Domínio Simples Uma rede do Tivoli Workload Scheduler de domínio simples consiste em um gerenciador de domínio mestre e quaisquer números de agentes. O diagrama abaixo mostra um exemplo da rede de domínio simples. Uma rede de domínio simples é bem adequada às companhias que possuem poucas localizações e funções de negócios. Todas as comunicações na rede são roteadas através do gerenciador de domínio mestre. Com uma localização simples, você se preocupa somente com a confiabilidade de sua rede local e a quantidade de tráfego que ela pode manipular. 14 Versão 7.0

29 Planejamento da Rede É importante observar que as redes de domínio simples podem ser combinadas com outras redes, domínio simples ou múltiplo, para atenderem vários requisitos do site. O Tivoli Workload Scheduler suporta dependências entre redes e entre jobs que são executados em diferentes redes do Tivoli Workload Scheduler. 1. Introdução O exemplo à esquerda acima mostra uma rede de domínio simples. O gerenciador de domínio mestre está localizado em Atlanta, juntamente com vários agentes. Existem também agentes localizados em Denver. Os agentes em Denver dependem do gerenciador de domínio mestre em Atlanta para resolverem todas as dependências entre agentes, mesmo que as dependências possam estar em jobs que são executados em Denver. Uma alternativa seria criar redes do TWS de domínio simples separadas em Atlanta e Denver, conforme mostrado à direita. As vantagens de redes de domínio simples são: Arquitetura simples. Controle e gerenciamento centralizado. As desvantagens de redes de domínio simples são: Tivoli Workload Scheduler Guia de Planejamento e Instalação 15

30 Planejamento da Rede Todas as comunicações devem ser transmitidas através do gerenciador de domínio mestre. Isso pode resultar em uma carga pesada em uma rede amplamente distribuída. A falha do gerenciador de domínio mestre impacta toda a rede do Tivoli Workload Scheduler. Uma Rede de Domínio Múltiplo As redes de Domínio Múltiplo são especialmente adequadas às companhias que se estendem a múltiplas localizações, departamentos ou funções de negócios. Uma rede do Tivoli Workload Scheduler de domínio múltiplo consiste em um gerenciador de domínio mestre, qualquer número de gerenciadores de domínio de escalão inferior e qualquer número de agentes em cada domínio. Os agentes se comunicam somente com os gerenciadores de domínio e os gerenciadores de domínio se comunicam com os gerenciadores de domínio pai. O diagrama mostra um exemplo de uma rede de domínio múltiplo. Este diagrama é criado no exemplo mostrado para redes de domínio simples. O gerenciador de domínio mestre está localizado em 16 Versão 7.0

31 Planejamento da Rede Atlanta; ele contém os arquivos do banco de dados utilizados para documentar os objetos de planejamento e distribui o arquivo Symphony para seus agentes e os gerenciadores de domínio em Denver e Los Angeles. Em seguida, os gerenciadores de domínio de Denver e Los Angeles distribuem o arquivo Symphony para seus agentes e subordinam os gerenciadores de domínio em Boulder, Aurora e Burbank. O gerenciador de domínio mestre em Atlanta é responsável pela difusão de informações entre domínios por toda a rede. 1. Introdução Todas as comunicações para e do gerenciador de domínio de Boulder são roteadas através do gerenciador de domínio pai em Denver. Se existirem agendas ou jobs no domínio de Boulder que são dependentes de agendas ou jobs no domínio de Aurora, estas dependências serão resolvidas pelo gerenciador de domínio de Denver. A maioria das dependências entre agentes são manipuladas localmente pelos gerenciadores de domínio de escalão inferior, reduzindo muito o tráfego na WAN (Rede Remota). As vantagens de redes de domínio múltiplo: Agendas e jobs especiais podem ser submetidos a partir do gerenciador de domínio mestre ou de qualquer outro gerenciador de domínio ou agente que possui acesso aos arquivos do banco de dados no gerenciador de domínio mestre. Tráfego de rede reduzido devido ao processamento localizado. Resolução local de dependências entre agentes. Segurança e administração localizadas. Topologia flexível que mapeia o modelo do negócio. No fly switchover para o gerenciador de domínio de backup. Como ir para o Gerenciador de Domínio de Backup Cada domínio possui um gerenciador de domínio e, opcionalmente, um ou mais gerenciadores de domínio de backup. Um gerenciador de domínio de backup deve estar no mesmo domínio que o gerenciador de domínio que está sendo feito o backup. Os gerenciadores de domínio de backup devem ser agentes de tolerância Tivoli Workload Scheduler Guia de Planejamento e Instalação 17

32 Planejamento da Rede a falhas executando o Tivoli Workload Scheduler 7.x e devem ter as opções Resolver Dependências e Status Completo ativadas nas definições da estação de trabalho. Se um gerenciador de domínio falhar durante o dia de produção, você poderá utilizar o Job Scheduling Console ou o comando switchmgr na linha de comandos do Console Manager (conman), para ir para um gerenciador de domínio de backup. Uma ação Alternar Gerenciador pode ser executada por alguém com acesso de início e de encerramento ao gerenciador de domínio e estações de trabalho do gerenciador de domínio. Uma operação do gerenciador de alternação encerra o gerenciador de backup, em seguida, reinicializa-o como o novo gerenciador de domínio e converte o gerenciador de domínio antigo para um agente de tolerância a falhas. As identidades dos gerenciadores de domínio atuais são transportadas no arquivo Symphony de um dia de processamento para o próximo, assim, qualquer chave permanece em vigor até que você volte para o gerenciador de domínio original. Banco de Dados Expandido e Nomes de Objetos Longos Os bancos de dados do Tivoli Workload Scheduler e o arquivo Symphony foram expandidos para acomodar mais registros e nomes de objetos mais longos. Isso permite mais flexibilidade ao nomear objetos de planejamento, especialmente com pacotes tais como SAP R/3, Baan, etc. Os bancos de dados expandidos são o padrão no Tivoli Workload Scheduler 7.0. Eles permitem a utilização de nomes longos para objetos de planejamento -- por exemplo, nomes de jobs podem conter até quarenta caracteres em vez de oito como nas versões anteriores. Os bancos de dados não-expandidos são utilizados para permanecerem inadvertidamente compatíveis com as estações de trabalho do Maestro 5.x, que não suportam bancos de dados expandidos. 18 Versão 7.0

33 Planejamento da Rede Notas: 1. Sugerimos que o mestre esteja executando uma versão igual ou inferior do TWS do que os FTAs no domínio. 2. Se você tiver agentes do MPE (HP3000), certifique-se de executar bancos de dados não-expandidos. Criação do Banco de Dados Para novas instalações, os bancos de dados do Tivoli Workload Scheduler são criados no gerenciador de domínio mestre da primeira vez que você executa o mecanismo do TWS. O tipo de banco de dados criado, expandido ou não-expandido, é determinado marcando-se a Opção Global versão expandida = [sim não]. Essa opção é definida pelo script personalizado quando você instalou o Mecanismo do TWS. O padrão é o conjunto expandido para sim. 1. Introdução Você pode selecionar os bancos de dados não-expandidos quando primeiro instalar o TWS 7.0 e expandir os bancos de dados posteriormente. Para expandir os bancos de dados, execute o comando dbexpand no gerenciador de domínio mestre. O programa define a versão expandida da Opção Global como sim, faz cópias de backup dos bancos de dados existentes, expande os bancos de dados para aceitar nomes de objetos longos. Execute somente o dbexpand uma vez, do contrário, a cópia de backup dos bancos de dados existentes será perdida. As cópias de backup são colocadas em um diretório chamado mozart.old no diretório mozart. Nomes de Estação de Trabalho O planejamento dos jobs em uma rede do Tivoli Workload Scheduler é distribuído através de múltiplos computadores. Para rastrear jobs, agendas e outros objetos com precisão, a cada computador é fornecido um único nome de estação de trabalho. Os nomes podem ser os mesmos que os nomes de nós da rede, contanto que eles estejam de acordo com as regras de nomeação do Tivoli Workload Scheduler: Para redes não-expandidas, os nomes de estação de trabalho podem conter até oito caracteres alfanuméricos, traço (-) e sublinhado (_) que começam com uma letra. Tivoli Workload Scheduler Guia de Planejamento e Instalação 19

34 Planejamento da Rede Para redes expandidas, o comprimento máximo é dezesseis caracteres alfanuméricos, traço (-) e sublinhado (_) que começam com uma letra. Visão Geral da Instalação Abaixo encontra-se um resumo do processo de instalação do TWS 7.0. Este guia fornece instruções detalhadas para cada etapa. 1. Em todos os Gerenciadores de Domínio (incluindo Mestre e Backup), siga esta ordem: a. Se estiver instalando em uma versão anterior do Maestro ou TWS, desconecte as outras estações de trabalho no domínio e encerre o Maestro ou TWS. Consulte Como Desligar e Encerrar o TWS na página 26 para NT e Como Atualizar o Tivoli Workload Scheduler na página 58 para UNIX. Instale o TWS 7.0 Engine. Consulte Como Instalar o Mecanismo do TWS no Windows NT na página 25 ou Como Instalar o Mecanismo do TWS no UNIX na página 51.Você pode, realmente, inverter a ordem na qual o executa e a próxima etapa. b. Instale o Tivoli Management Framework. Se você ainda não tiver um Tivoli Management Region em sua empresa, instale como um servidor TMR. Se um TMR já existir, será possível optar por instalar como um nó gerenciado. Consulte a documentação de instalação do TMF para obter detalhes. c. Instale o Job Scheduling Services e o Conector do TWS no Tivoli Framework. Consulte Como Instalar o Conector do TWS na página 83. d. No Desktop Tivoli, crie um Administrador Tivoli para TWS. Em outras palavras, inclua o usuário do TWS ou Maestro como um início de sessão para o administrador TMF ou crie um novo administrador TMF com o início de sessão do TWS ou Maestro. e. Atualize a segurança do TWS, para incluir o Administrador Tivoli. 20 Versão 7.0

35 Visão Geral da Instalação No NT, é necessário encerrar o TWS antes de executar o comando makesec. No UNIX, é possível executar makesec sem encerrar o TWS anteriormente, mas é necessário encerrar e reinicializar o TWS para ativar o recurso de segurança. f. Opcionalmente, instale o Job Scheduling Console. Consulte Como Instalar o Tivoli Job Scheduling Console na página Instale o seguinte em cada estação de trabalho que deseja incluir como um agente na rede do TWS: TWS 7.0 Engine. O Job Scheduling Console (opcional). Você também pode instalar o JS Console em estações de trabalho e não na rede do TWS, que possui uma conexão TCP/IP com um Gerenciador de Domínio que executa o Conector do TWS. 3. Inicie sessão no Job Scheduling Console e defina as estações de trabalho na rede do TWS para o banco de dados do TWS. 4. Agora, você pode utilizar o Job Scheduling Console para definir os jobs, fluxos de job e outros objetos de planejamento. 1. Introdução Grupos de Produtos Os produtos do Tivoli são organizados em grupos de produtos. Cada grupo possui um processo Netman para manipular os serviços requeridos por todos os produtos no grupo. Este também permite várias cópias de um produto a ser instalado em um único computador, designando um grupo diferente para cada cópia. Arquivo de Componentes Os grupos de produtos são definidos no arquivo de componentes. Se o arquivo não existir antes da instalação, ele será criado pelo script de personalização no UNIX ou programa de Configuração no Windows NT. Uma amostra de UNIX a seguir: <produto> <versão> <diretório pessoal> <grupo de produtos> Tivoli Workload Scheduler Guia de Planejamento e Instalação 21

36 Grupos de Produtos Maestro Destiny Netman /opt/maestro /opt/destiny /opt/netman produção produção produção As entradas no arquivo são automaticamente criadas e atualizadas pela personalização ou Configuração. O grupo de produtos workstation_user será utilizado como padrão no NT, se você não especificar um grupo. No UNIX, o nome do arquivo do arquivo de componentes é definido na variável: UNISON_COMPONENT_FILE Se a variável não for definida, a personalização utilizará o nome do arquivo: /usr/unison/components No Windows NT, o nome do arquivo de componentes, netmanhome\components, é gravado no registro a primeira vez que esta versão do Workload Scheduler for instalada. Consulte Diretório Pessoal do Netman. Como Exibir o Arquivo de Componentes Ao seguir a instalação ou atualização, é possível exibir o conteúdo do arquivo de componentes através da execução do programa ucomp como segue: ucomp -l Diretório Pessoal do Netman Uma opção no script de personalização no UNIX e uma tela de Configuração no Windows NT, permite que você especifique um diretório pessoal do Netman. Se saltado, o padrão no UNIX será diretório pessoal do Workload Scheduler e no Windows NT o padrão será: c:\win32app\unison\netman. 22 Versão 7.0

37 Grupos de Produtos Opções Locais do Netman Se o diretório pessoal do Netman não for igual ao diretório pessoal do Workload Scheduler, as seguintes opções locais serão movidas de um arquivo localopts do Workload Scheduler para um arquivo localopts separado no diretório Netman: nm mortal nm port nm read nm retry merge stdlistsstdlist width syslog local 1. Introdução Após a Instalação E, a opção a seguir poderá ser incluída, se desejado: nm ipvalidate Consulte a seção 2 no Guia do Tivoli Workload Scheduler Administrator, para obter mais informações sobre as Opções Locais. Após a instalação do Workload Scheduler, consulte o Tivoli Workload Scheduler - Guia do Usuário para obter informações sobre configuração e instalação. Tivoli Workload Scheduler Guia de Planejamento e Instalação 23

38 24 Versão 7.0

39 2 Como Instalar o Mecanismo do TWS no Windows NT Este capítulo descreve o processo de instalação do Tivoli Workload Scheduler (TWS) em sistemas e redes Windows NT. Requisitos do Sistema A seguir encontram-se os requisitos de sistema do TWS para sistemas Windows NT. Windows NT versão 4.0 com Service Pack 4 ou superior. Unidade de CD-ROM para instalação. Partição NTFS para instalar o TWS. Aproximadamente 100 MB de espaço livre em disco para gerenciadores de domínio e agentes de tolerância a falhas. Aproximadamente 40 MB para agentes padrão. Além disso, o TWS produz arquivos de log e arquivos temporários, que são colocados na unidade de disco rígido local. A quantidade de espaço requerida depende do número de jobs gerenciados pelo TWS e o período de tempo escolhido para reter arquivos de log. RAM de 128 MB e espaço de troca de 128 MB para gerenciadores de domínio e agentes de tolerância a falhas. Os agentes padrão requerem menos. Comunicações de rede TCP/IP. 2. Como Inst. Mecan. TWS no Windows NT Tivoli Workload Scheduler Guia de Planejamento e Instalação 25