Ao trabalhar pesadamente no

Transcrição

1 Tivoli e Linux: Gerenciamento de Infraestrutura de Redes e Servidores A multiplicidade do Tivoli Há tempos a IBM vem investindo pesadamente em Linux, não apenas no desenvolvimento de aplicações e na inclusão desse sistema operacional em suas soluções em ambientes distribuídos, como também no ambiente do mainframe. A suíte Tivoli é um excelente exemplo do que já foi feito nessas três linhas de investimentos. por Marcos Alves e Roberto Nozaki ANÁLISE Davide Guglielmo Ao trabalhar pesadamente no desenvolvimento de soluções e ferramentas para Linux, tanto em ambientes distribuídos quanto em mainframes, a IBM entende que é possível combinar a escalabilidade e a confiabilidade dos servidores de mainframe com a flexibilidade e os padrões abertos de Linux. Na IBM isto se reflete em uma linha chamada zlinux, ou o Linux que roda no mainframe. Mas, independentemente da plataforma, o investimento é intenso também no gerenciamento de infraestruturas de servidores e redes baseadas em Linux. Dentro da IBM, a iniciativa de ITSM (IT Service Management) engloba a família Tivoli de produtos, que vem sendo ampliada através de dois grandes caminhos: 1 Desenvolvimento interno: a IBM investe bilhões por ano em pesquisa e desenvolvimento, e detém o recorde de registro de patentes, ano após ano (foram nos EUA, em 2006); 2 Aquisições de empresas também focadas em gerenciamento, como Candle, Cyanea, Micromuse. Nessas ocasiões são incorporados os cérebros dessas companhias, o que redunda em evolução dos produtos da própria IBM. Esses fatores resultam em um leque bastante amplo de produtos, que, no caso específico do Tivoli em ambiente Linux, contam com ferramentas para controle de autenticação e autorização, becape, entre outros, passando por gerenciamento dos próprios servidores e aplicações e redes, e culminando no gerenciamento de linhas de serviço (veja no quadro 1). Este artigo se concentra nas soluções Tivoli para as seguintes áreas: 1 Gerenciamento de servidores e aplicações: Tivoli Monitoring e ITCAM; 2 Gerenciamento de redes: Tivoli Network Manager (ex-netcool/ Precision); 3 Gerenciamento de eventos: Tivoli Netcool/OMNIbus; 4 CMDB. Servidores e aplicações Dentro da família Tivoli, o ITM (IBM Tivoli Monitoring) é o responsável pelo gerenciamento de servidores e aplicações em rede, nas diversas plataformas do ambiente distribuído em que atua (Linux, outros Unix, Windows). No mainframe, a família mantém o nome OMEGAMON, herdado quando a IBM adquiriu a empresa Candle, em O ITM 6.1 no ambiente distribuído também é fruto desta incorporação, e possui monitores para recursos do sistema operacional (como uso de CPU, memória, disco, processos), aplicações (como SAP, Siebel, Lotus Domino, Exchange) e bancos de dados (DB2, Oracle, MS-SQL, Sybase). Os dados coletados a partir destas monitorações são armazenados Linux Magazine #71 Outubro de

2 ANÁLISE Tivoli Quadro 1: Produtos IBM Tivoli para gerenciamento em Linux IBM Tivoli Access Manager for e-business Atua como coordenador central das funções de autenticação e autorização para aplicações (sejam elas web ou não). IBM Tivoli Access Manager for Operating Systems Protege os recursos de aplicações e sistemas operacionais endereçando vulnerabilidades relacionadas com o uso de contas de superusuário em ambientes UNIX/Linux. IBM Tivoli Composite Application Manager for Response Time Tracking Uma solução para gerenciamento de transações fim-a-fim capaz de, proativamente, reconhecer, isolar e resolver problemas de tempo de resposta para usuários finais. IBM Tivoli Configuration Manager Solução integrada para distribuição de software e para inventário de configurações de software e hardware nas empresas. IBM Tivoli Enterprise Console Correlaciona eventos de servidores, redes e e-business, para rapidamente identificar a causa raiz de problemas em ambiente de TI. IBM Tivoli Monitoring Gerencia de forma pró-ativa a saúde e a disponibilidade da infraestrutura de TI, fim-afim, através de ambientes distribuídos e no mainframe. IBM Tivoli Monitoring Express Uma versão light do IBM Tivoli Monitoring, voltada para pequenas e médias empresas. IBM Tivoli Monitoring for Microsoft.NET Monitora e garante disponibilidade e desempenho ao ambiente.net da Microsoft. IBM Tivoli Network Manager Gerencia recursos de redes nas camadas OSI 2 e 3 da rede. IBM Tivoli OMEGAMON XE for Linux on zseries Gerencia o desempenho e a disponibilidade do sistema operacional Linux nas plataformas mainframe e distribuídas (OS/390, zseries e Intel). IBM Tivoli OMEGAMON XE for WebSphere Application Server for Linux on zseries Um monitor especializado em WebSphere para Linux. IBM Tivoli Risk Manager Simplifica em um único console os eventos e alertas gerados por diversos produtos antes desconectados, para gerenciar incidentes de segurança e vulnerabilidades. IBM Tivoli Service Level Advisor Viabiliza o gerenciamento de nível de Serviço, para que seja possível alinhar os serviços entregues pela sua empresa com as necessidades de seus clientes. IBM Tivoli Storage Manager Automatiza funções de becape e restauração de becape, suportando uma ampla gama de plataformas e dispositivos de armazenamento. IBM Tivoli Storage Manager for Databases Protege bancos de dados Informix, Oracle e Microsoft SQL. IBM Tivoli System Automation for Multiplatforms Provê solução de alta disponibilidade para aplicações e middlewares de missão crítica em Linux, AIX e plataformas zlinux. IBM Tivoli Workload Scheduler Automatiza e controla o fluxo de trabalho por meio de toda infraestrutura de TI da empresa. pelo ITM em um banco de dados, e podem ser visualizados em tempo real através do console web do TEP (Tivoli Enterprise Portal) ou, por meio do acesso a históricos, através do TDW (Tivoli Data Warehouse). Um exemplo do console do TEP é mostrado na figura 1. Este console também é utilizado para definir thresholds (valor mínimo de um parâmetro utilizado para ativar um dispositivo ou ação) de monitoração, assim como ações automáticas a serem executadas quando um threshold é ultrapassado. Para exemplificar, definimos que, quando um determinado disco de um certo servidor atingir 80% de utilização, a ação automática executada será a remoção dos arquivos no diretório temporário. Além disso, caso a utilização ultrapasse 90%, o pager do analista de suporte é acionado e um ticket é automaticamente aberto no sistema de help desk da empresa. Com isso, ganha-se em pró-atividade e evita-se, posteriormente, maiores dores de cabeça, já que, em geral, o problema tem conse quências mais sérias e custa mais caro para ser diagnosticado e resolvido, sobretudo quando uma aplicação importante pára de funcionar por falta de espaço em disco. No caso de recursos para os quais não existe um monitor out-of-the-box, é possível ainda utilizar o agente universal do ITM, bastante customizável e capaz de capturar seus dados via API, arquivos de log, ODBC, HTTP, SNMP, scripts, sockets, portas TCP, entre outras opções. Os dados capturados dessa forma podem também ser monitorados para disparar ações corretivas, ou visualizados em relatórios no TEP e no TDW. Usuários podem criar e compartilhar monitores ou scripts para customização do agente universal no site da IBM/ OPAL [1]. Mas, para haver um gerenciamento efetivo da saúde de uma aplicação, 58

3 Tivoli ANÁLISE Figura 1 Console do TEP (Tivoli Enterprise Portal). não basta gerenciar os recursos dos quais ela depende. É necessário, de alguma forma, gerenciar também a experiência do usuário, inclusive com testes fim-a-fim simulando um usuário real. Para atender a esta necessidade, a Tivoli conta com a família ITCAM (IBM Tivoli Composite Application Management). Por definição, aplicações compostas são todas aquelas que permeiam mais de um ambiente ou Figura 2 O ITNM mostrando a causa raiz de um problema de rede. sistema operacional, ou que se utilizam de múltiplos recursos existentes na infraestrutura da empresa, como servidores web, bancos de dados, servidores de aplicações ou mesmo o mainframe. Há módulos ITCAM prontos para gerenciar servidores de aplicação WebSphere ou outros servidores J2EE, como WebLogic, JBoss, Oracle, SAP NetWeaver e Tomcat. Esse gerenciador permite que se faça monitoramento e diagnósticos detalhados destes servidores, e pode utilizar a mesma infraestrutura do TEP, que atua como console unificado para as funções de monitoração. O ITCAM possui também monitores no mainframe para CICS e IMS, uma configuração muito comum em aplicações bancárias. Para prover a capacidade de gerenciamento fim-a-fim, há também o ITCAM para RTT (Response Time Tracking), que nos permite monitorar o tempo de resposta a partir da máquina do usuário final, seja de forma robótica (um teste é executado periodicamente, independentemente de haver alguém usando a máquina ou por amostras reais (à medida que um usuário real efetua as transações). É possível gravar uma transação para agendar sua reprodução nos testes, e podem ser monitoradas tanto aplicações com interface web como aplicações Windows. Podemos definir thresholds ideais para os tempo de respostas, e solicitar a geração de alarmes quando estes tempos estiverem fora do desempenho desejado. E mais: os dados coletados das transações do usuário podem ser usados pela equipe de desenvolvimento para localizar os gargalos da aplicação. Gerenciamento de Redes Até cerca de um ano e meio atrás, a ferramenta para descoberta e gerenciamento de redes da Tivoli em ambiente distribuído era o NetView, que por sua vez foi desenvolvido a partir de uma versão mais antiga do HP/OpenView. Com a aquisição da Micromuse, em fevereiro de 2006, a IBM incorporou o produto Netcool/ Precision, que agora é o carro-chefe da IBM para este tipo de gerenciamento, e passou a se chamar IBM Tivoli Network Manager (ITNM). É neste produto que o time de de- Linux Magazine #71 Outubro de

4 ANÁLISE Tivoli Figura 3: Imagem do status da rede e eventos no Netcool/WebTop. senvolvimento está focado, ficando o NetView voltado para ambientes menores e menos complexos. O caminho natural é que novos usuários comecem diretamente com o ITNM, e que os antigos usuários de NetView migrem pouco a pouco seus ambientes para ITNM. É bastante comum utilizarmos o ITNM rodando em Linux, desde simples provas de conceito, onde demonstramos as funcionalidades da ferramenta, até a implementação de grandes projetos, com literalmente centenas de milhares de elementos sendo gerenciados. O ITNM é um produto de concepção mais moderna que seus antecessores, e foi amadurecido em ambientes extremamente exigentes: empresas de telecomunicações no mundo todo, que o utilizam para monitorar redes altamente complexas. A IBM percebeu que as características do ITNM seriam úteis não apenas neste tipo de empresa, mas também em qualquer empresa de TI que tivesse de gerenciar múltiplas tecnologias de rede, com centenas de milhares de elementos. O ITNM é capaz de descobrir e monitorar redes nos níveis 2 e 3 da camada OSI (enlace e rede), suportando tecnologias como MPLS, OSPF, SNMPv1/2/3, ATM, Frame Relay, CDP, HSRP, VLAN e NAT estático. Um ponto forte desta ferramenta é a escalabilidade: com apenas um servidor de ITNM, pode-se gerenciar até elementos (considerando como elemento uma interface de rede, uma VLAN ou um servidor, por exemplo). E uma arquitetura de ITNM pode combinar mais servidores ITNM, monitorando mais elementos ainda. Uma vez descobertos os elementos de rede, o ITNM utiliza algoritmos pré-definidos para estabelecer a relação entre estes objetos, alimentando um banco de dados interno com a topologia da rede. Isto permite mapear quem está ligado a quem, e de que forma (seja como um caminho único por um roteador ou por caminhos redundantes). Este mapeamento da topologia permite ao ITNM fazer algo além em relação a outras ferramentas similares: a análise de causa raiz (RCA, em inglês). Um exemplo disso pode ser visto na figura 2. Em um primeiro momento, todos os dispositivos afetados são mostrados como eventos críticos (ficariam em vermelho na lista de eventos e no mapa de topologia). Em alguns segundos, porém, o ITNM detecta que diversos elementos estão inacessíveis em função da falha em um dispositivo do qual todos dependem. Imediatamente, apenas o dispositivo causador do problema permanece na cor vermelha, e os demais são mostrados na cor púrpura, indicando-os como sintomas de uma causa em comum. Assim, a operação da rede pode atuar diretamente no problema real, em vez de procurar entre inúmeros problemas. Uma característica que os fãs do Linux provavelmente vão apreciar é o ITNM ser uma ferramenta bastante aberta, e portanto altamente configurável. Modificando os scripts shell e Perl que fazem parte do produto, é possível configurar desde o discovery (caso você possua elementos incomuns em sua rede), até a forma como os elementos serão costurados na topologia, além da maneira como os elementos serão monitorados. Os DBs que contêm todas estas informações e parâmetros são abertos, podendo ser visualizados e até mesmo refinados pelos administradores mais experientes. Gerenciamento de eventos A coleta, consolidação e correlação dos eventos de falha é efetuada pelos produtos Netcool/OMNIbus, também incorporados com a aquisição da Micromuse. Assim como o ITNM, estes produtos amadureceram no ambiente de empresas de telecomunicações, sendo muito comum observá-los nos NOCs (sigla em inglês para Centro de Operações de Redes) destas operadoras. De fato, a totalidade das vinte maiores empresas deste ramo no mundo projetam consoles do Netcool em seus telões, nas mesas dos operadores da rede e também dos executivos. Hoje o seu uso não se restringe às empresas de telecomunicação, estando também presente em bancos, órgãos de defesa e indústrias. O Netcool/WebTop acrescenta ao OMNIbus a funcionalidade de visualização de eventos, mapas e gráficos via web, exemplificada na figura 3. O OMNIbus captura os eventos de falhas utilizando suas mais de 300 probes softwares especializados em coletar eventos das mais variadas fontes, como: arquivos de log, bancos de dados, elementos 60

5 Tivoli ANÁLISE de rede que enviam traps SNMP, PABX, portas seriais, ou até mesmo outros gerenciadores de rede. As probes são desenvolvidas em parceria com os próprios fabricantes dos equipamentos monitorados e possuem arquivos de regras que permitem selecionar quais eventos serão enviados para o Netcool, através de filtros (expressões regulares). Uma vez coletados, os eventos são concentrados no ObjectServer, peça central do OMNIbus, onde são eliminadas as duplicidades (mesmo tipo de problema para o mesmo elemento). O ObjectServer é um banco de dados residente em memória, construído para tratar grandes volumes de eventos (dezenas de milhões de eventos por dia) com alta performance e escalabilidade. O ObjectServer automaticamente correlaciona eventos de problema com eventos que indicam a resolução do mesmo problema. Por exemplo, quando da chegada de um evento de Node Up para um dispositivo para o qual havia sido gerado um Node Down anteriormente, ambos os eventos são marcados como resolvidos e eliminados da lista dos operadores. Esta automação é genérica e pode ser aplicada a qualquer par de eventos problema/resolução, bastando configurar as probes (o que já é feito por padrão nas probes padrão). Assim, os operadores da rede podem se concentrar apenas nos eventos que ainda requerem sua atenção. Como o ObjectServer é um banco de dados relacional, basta ter um bom conhecimento de SQL para criar ou adaptar as automações. Projetos de Netcool em ambientes complexos são geralmente rápidos por não exigirem conhecimentos específicos de programação em alguma linguagem obscura. Outras automações (como a execução de scripts) podem ser disparadas por tempo ou pela chegada de eventos definidos pelo administrador, minimizando a necessidade de intervenções manuais por parte dos operadores da rede. CMDB Você já se deparou com uma solicitação de mudança, como fazer um upgrade em um roteador ou em um servidor, ou tirar o cabo de rede do switch para liberação de um ponto para uma instalação emergencial? E você então prontamente atende à solicitação, mas de repente o telefone do departamento não para de tocar, com reclamações sobre uma filial que parou de funcionar, ou uma aplicação ou um serviço que estão com problemas depois daquela mudança? Imagine como seria se você possuísse uma forma de, antes da mudança, saber que o roteador X está ligado às redes A, B e C ou que o Servidor Y é responsável por autenticar todos os usuários do serviço de Internet Banking. É sobre esta abordagem que a IBM vem investindo fortemente em uma ferramenta capaz de realizar um discovery dos componentes de rede, sejam roteadores, switches, servidores, links, sistemas operacionais e aplicações ou banco de dados, Web, correio eletrônico, Figura 4 Imagem da topologia de uma aplicação. CRM, ferramentas de gestão etc. e montar um mapa de relacionamento entre estes componentes. Ou seja, descobrir quais componentes de rede estão ligados a um determinado roteador, ou em quais portas do switches estão conectados os servidores, ou em qual servidor a aplicação X está sendo executada e a quais outros servidores ou aplicações a mesma aplicação se conecta, ou, ainda, em relação a quais ela possui uma dependência. Essa ferramenta deve ser totalmente aderente ao ITIL (Information Technology Infrastructure Library), que define as melhores práticas para a implementação de um CMDB (Configuration Manager Database), que é uma base de dados com todas as informações sobre os relacionamentos e dependências do seu ambiente de TI. Desta forma, todas as vezes em que existir uma alteração no ambiente, esta base deverá ser consultada para que se saiba exatamente o impacto desta mudança. A ferramenta capaz de montar este CMDB chama-se IBM Tivoli Application Depedency Discovery Manager, ou ITADDM, fruto da aquisição pela IBM Software Group da empresa Collation em novembro de Linux Magazine #71 Outubro de

6 ANÁLISE Tivoli Como funciona? O ITADDM é uma ferramenta não intrusiva, ou seja, não necessita de agentes instalados nos componentes para que estes sejam descobertos. Para tal, a ferramenta dispõe de quatro recursos que são chamados de sensors: SNMP, sockets, scripts e usuário e senha da aplicação ou componente. Todas estas informações são configuradas para uso da ferramenta por meio de um módulo chamado Access List, com acesso permitido apenas para o administrador do ITADDM. Depois da definição da Access List deve ser definido o escopo que, no caso do ITADDM, pode ser uma faixa de endereços IP, subrrede, ou um único IP. Uma vez definido o escopo, podese iniciar o processo de discovery dos componentes, que será realizado utilizando os sensors, seja via GET SNMP, porta Sockets, scripts onde se pode definir assinaturas para que seja identificado um determinado componente (muito utilizado em caso de aplicações customizadas) e usuário e senha para acesso às informações do componente que pode ser: um sistema operacional, um banco de dados, um servidor web, roteador ou switch. Após o processo de descoberta, o ITADDM armazena os componentes encontrados bem como os relacionamentos e as dependências entre eles em um banco de dados DB2. É possível consultar estas informações através de sua interface gráfica via browser (via Internet Explorer ou Firefox). Na interface do ITADDM as informações sobre relacionamento e dependências são apresentadas em três níveis: Infraestrutura, Aplicações e Negócios (figura 4). É provida uma visão completa de como cada nível influencia ou é influenciado pelos componentes de cada um dos três níveis, permitindo comparações entre os componentes e das mudanças (lógicas ou físicas) de um determinado componente em um período de tempo. Portanto, o ITADDM é uma ferramenta que responde à seguinte pergunta: Quais são as aplicações e serviços afetados se o componente parar ou tiver sua configuração alterada?. Com relação ao sistema operacional, o ITADDM é bem democrático, podendo ser executado em diversas plataformas, incluindo Linux em ambiente distribuído e mainframe (RedHat e Suse Linux Enterprise Server). Vale ressaltar que o ITADDM não está só essa ferramenta tem integração total com o Tivoli Service Desk, podendo, assim, ser implementado o CCMDB (Change and Configuration Management Database). Mais informações Outro ponto importante é que o ITADDM pode ser integrado com outros fornecedores de Service Desk, preenchendo uma grande lacuna que é descobrir as dependências e relacionamentos de todos os componentes de TI. Conclusão A família de produtos Tivoli é uma plataforma aberta, que permite que os administradores das ferramentas as adaptem para atender as necessidades de suas empresas. Administradores Linux, habituados a ter este nível de controle nos seus sistemas operacionais, podem certamente se beneficiar desta combinação de melhores práticas e flexibilidade existente nas ferramentas de gerenciamento de infraestrutura do Tivoli. n [1] OPAL (IBM Tivoli Open Process Automation Library): [2] Linux na IBM: [3] Soluções para gerenciamento de Linux da IBM: ibm.com/software/tivoli/solutions/linux/products.html/ [4] Tivoli Information Center (contém produtos para Linux e outros sistemas operacionais): developerworks/wikis/display/tivolidoccentral/home/ Sobre os autores Marcos Alves é especialista em TI e membro do IBM Tivoli World Wide SWAT Team. Possui certificação ITIL. Há 16 anos trabalha na área de Informática e há 9 anos trabalha com ferramentas de gerência de TI. Atualmente é membro do time de Software Advanced Technology da IBM Tivoli Software. Roberto Nozaki é especialista em TI no time de SWG da IBM Brasil. Trabalha há mais de 20 anos na área de TI e há 12 com soluções de gerência de redes, servidores e aplicações. É certificado em ITIL Foundations, ITM e Netcool/OMNIbus. Gostou do artigo? Queremos ouvir sua opinião. Fale conosco em cartas@linuxmagazine.com.br Este artigo no nosso site:

7 Inclua em seu currículo a principal certificação Linux no mundo LPI. Em tempos de crise, soluções de código aberto como o Linux se destacam na adoção por empresas de todos os tamanhos, como solução ideal para aumentar eficiência nos negócios e reduzir custos. Atualmente há no mercado uma carência por profissionais certificados para atender a essa demanda crescente. Aproveite essa oportunidade e inclua em seu Inscrições e mais informações: treinamentos@vectory.com.br Tel (11) R Linux Professional Institute