57Linux Magazine #71 | Outubro de 2010

AN

ÁLIS

E

Tivoli e Linux: Gerenciamento de Infraestrutura de Redes e Servidores

A multiplicidade do TivoliHá 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

Ao trabalhar pesadamente no desenvolvimento de soluções e ferramentas para Linux, tan-

to 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 chama-da zLinux, ou o Linux que roda no mainframe.

Mas, independentemente da pla-taforma, o investimento é intenso também no gerenciamento de in-fraestruturas de servidores e redes baseadas em Linux. Dentro da IBM, a iniciativa de ITSM (IT Service Ma-nagement) 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 3.621 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 auten-ticação e autorização, becape, entre outros, passando por gerenciamento dos próprios servidores e aplicações e redes, e culminando no gerencia-mento 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: Ti-voli Netcool/OMNIbus;

4 CMDB.

Servidores e aplicaçõesDentro 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 2004.

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 da-dos (DB2, Oracle, MS-SQL, Sybase).

Os dados coletados a partir des-tas monitorações são armazenados

Davide Guglielmo – www.sxc.hu

58 http://www.linuxmagazine.com.br

ANÁLISE  | Tivoli

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íni-mo de um parâmetro utilizado para ativar um dispositivo ou ação) de monitoração, assim como ações au-tomáticas a serem executadas quan-do 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 ge-ral, 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 uni-versal 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 captu-rados dessa forma podem também ser monitorados para disparar ações corretivas, ou visualizados em rela-tórios no TEP e no TDW. Usuários podem criar e compartilhar moni-tores 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,

Quadro 1: Produtos IBM Tivoli para gerenciamento em Linux

IBM Tivoli Access Manager for e-businessAtua como coordenador central das funções de autenticação e autorização para apli-cações (sejam elas web ou não).

IBM Tivoli Access Manager for Operating SystemsProtege os recursos de aplicações e sistemas operacionais endereçando vulnerabili-dades relacionadas com o uso de contas de superusuário em ambientes UNIX/Linux.

IBM Tivoli Composite Application Manager for Response Time TrackingUma 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 ManagerSolução integrada para distribuição de software e para inventário de configurações de software e hardware nas empresas.

IBM Tivoli Enterprise ConsoleCorrelaciona eventos de servidores, redes e e-business, para rapidamente identificar a causa raiz de problemas em ambiente de TI.

IBM Tivoli MonitoringGerencia de forma pró-ativa a saúde e a disponibilidade da infraestrutura de TI, fim-a-fim, através de ambientes distribuídos e no mainframe.

IBM Tivoli Monitoring ExpressUma versão “light” do IBM Tivoli Monitoring, voltada para pequenas e médias empresas.

IBM Tivoli Monitoring for Microsoft .NETMonitora e garante disponibilidade e desempenho ao ambiente .NET da Microsoft.

IBM Tivoli Network ManagerGerencia recursos de redes nas camadas OSI 2 e 3 da rede.

IBM Tivoli OMEGAMON XE for Linux on zSeriesGerencia o desempenho e a disponibilidade do sistema operacional Linux nas platafor-mas mainframe e distribuídas (OS/390, zSeries e Intel).

IBM Tivoli OMEGAMON XE for WebSphere Application Server for Linux on zSeriesUm monitor especializado em WebSphere para Linux.

IBM Tivoli Risk ManagerSimplifica em um único console os eventos e alertas gerados por diversos produtos an-tes desconectados, para gerenciar incidentes de segurança e vulnerabilidades.

IBM Tivoli Service Level AdvisorViabiliza 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 ManagerAutomatiza funções de becape e restauração de becape, suportando uma ampla gama de plataformas e dispositivos de armazenamento.

IBM Tivoli Storage Manager for DatabasesProtege bancos de dados Informix, Oracle e Microsoft® SQL.

IBM Tivoli System Automation for MultiplatformsProvê solução de alta disponibilidade para aplicações e middlewares de missão crítica em Linux, AIX e plataformas zLinux.

IBM Tivoli Workload SchedulerAutomatiza e controla o fluxo de trabalho por meio de toda infraestrutura de TI da empresa.

59

| ANÁLISETivoli

Linux Magazine #71 | Outubro de 2010

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

sistema operacional, ou que se utili-zam 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 We-bSphere ou outros servidores J2EE, como WebLogic, JBoss, Oracle, SAP NetWeaver e Tomcat. Esse geren-

ciador permite que se faça monito-ramento 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 mo-nitores no mainframe para CICS e IMS, uma configuração muito comum em aplicações bancárias.

Para prover a capacidade de ge-renciamento 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 perio-dicamente, 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 apli-cações Windows. Podemos definir thresholds ideais para os tempo de respostas, e solicitar a geração de alarmes quando estes tempos estive-rem fora do desempenho desejado. E mais: os dados coletados das tran-sações do usuário podem ser usados pela equipe de desenvolvimento para localizar os gargalos da aplicação.

Gerenciamento de RedesAté cerca de um ano e meio atrás, a ferramenta para descoberta e ge-renciamento 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 gerencia-mento, e passou a se chamar IBM Tivoli Network Manager (ITNM). É neste produto que o time de de-Figura 2 O ITNM mostrando a causa raiz de um problema de rede.

Figura 1 Console do TEP (Tivoli Enterprise Portal).

60 http://www.linuxmagazine.com.br

ANÁLISE  | Tivoli

senvolvimento está focado, ficando o NetView voltado para ambientes menores e menos complexos. O ca-minho natural é que novos usuários comecem diretamente com o ITNM, e que os antigos usuários de NetView migrem pouco a pouco seus ambien-tes 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 con-cepção mais moderna que seus an-tecessores, e foi amadurecido em ambientes extremamente exigentes: empresas de telecomunicações no mundo todo, que o utilizam para monitorar redes altamente comple-xas. A IBM percebeu que as carac-terí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 ca-mada OSI (enlace e rede), suportan-

do 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é 250.000 elementos (considerando como elemento uma interface de rede, uma VLAN ou um servidor, por exemplo). E uma arquitetura de ITNM pode combinar mais ser-vidores 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 ma-pear “quem” está ligado a “quem”, e de que forma (seja como um cami-nho ú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 simi-lares: 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 mostra-dos como eventos críticos (ficariam em vermelho na lista de eventos e

no mapa de topologia). Em alguns segundos, porém, o ITNM detec-ta que diversos elemen-tos estão inacessíveis em função da falha em um dispositivo do qual todos dependem. Imediatamente, apenas o dispositivo causador do problema perma-nece na cor vermelha, e os demais são mos-trados na cor púrpu-ra, 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 bas-tante aberta, e portanto altamente configurável. Modificando os scripts shell e Perl que fazem parte do pro-duto, é possível configurar desde o discovery (caso você possua elementos incomuns em sua rede), até a forma como os elementos serão “costura-dos” na topologia, além da maneira como os elementos serão monitora-dos. Os DBs que contêm todas estas informações e parâmetros são abertos, podendo ser visualizados e até mes-mo refinados pelos administradores mais experientes.

Gerenciamento de eventosA coleta, consolidação e correla-ção dos eventos de falha é efetuada pelos produtos Netcool/OMNIbus, também incorporados com a aqui-sição da Micromuse. Assim como o ITNM, estes produtos amadure-ceram 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 empre-sas 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 defe-sa e indústrias. O Netcool/WebTop acrescenta ao OMNIbus a funcionali-dade de visualização de eventos, ma-pas e gráficos via web, exemplificada na figura 3.

O OMNIbus captura os eventos de falhas utilizando suas mais de 300 probes – softwares especiali-zados em coletar eventos das mais variadas fontes, como: arquivos de log, bancos de dados, elementos Figura 3: Imagem do status da rede e eventos no Netcool/WebTop.

61

| ANÁLISETivoli

Linux Magazine #71 | Outubro de 2010

de rede que enviam traps SNMP, PABX, portas seriais, ou até mes-mo outros gerenciadores de rede. As probes são desenvolvidas em parceria com os próprios fabrican-tes dos equipamentos monitorados e possuem arquivos de regras que permitem selecionar quais eventos serão enviados para o Netcool, atra-vé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 ele-mento). O ObjectServer é um ban-co de dados residente em memória, construído para tratar grandes volu-mes de eventos (dezenas de milhões de eventos por dia) com alta perfor-mance 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 even-tos são marcados como resolvidos e eliminados da lista dos operadores. Esta automação é genérica e pode ser aplicada a qualquer par de even-tos problema/resolução, bastando configurar as probes (o que já é feito por padrão nas probes padrão). As-sim, os operadores da rede podem se concentrar apenas nos eventos que ainda requerem sua atenção.

Como o ObjectServer é um ban-co de dados relacional, basta ter um bom conhecimento de SQL para criar ou adaptar as automações. Projetos de Netcool em ambientes comple-xos são geralmente rápidos por não exigirem conhecimentos específicos de programação em alguma lingua-gem obscura.

Outras automações (como a exe-cução de scripts) podem ser dispa-radas por tempo ou pela chegada de eventos definidos pelo adminis-

trador, minimizando a necessidade de intervenções manuais por parte dos operadores da rede.

CMDBVocê já se deparou com uma solici-taçã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 te-lefone 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ê pos-suísse uma forma de, antes da mu-dança, saber que o “roteador X” está ligado às redes “A, B e C” ou que o “Servidor Y” é responsável por au-tenticar 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 opera-cionais e aplicações ou banco de dados, Web, correio eletrônico,

CRM, ferramentas de gestão etc. e montar um mapa de relaciona-mento entre estes componentes. Ou seja, descobrir quais compo-nentes 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 total-mente 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 relaciona-mentos e dependências do seu am-biente de TI. Desta forma, todas as vezes em que existir uma alteração no ambiente, esta base deverá ser consultada para que se saiba exata-mente 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 2005.

Figura 4 Imagem da topologia de uma aplicação.

62 http://www.linuxmagazine.com.br

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 adminis-trador 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, pode-se 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 infor-maçõ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 relacio-namentos 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 in-formaçõ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 en-

tre os componentes e das mudanças (lógicas ou físicas) de um determi-nado componente em um período de tempo.

Portanto, o ITADDM é uma fer-ramenta que responde à seguinte pergunta: “Quais são as aplicações e serviços afetados se o componen-te parar ou tiver sua configuração alterada?”. Com relação ao sistema operacional, o ITADDM é bem de-mocrá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 Configura-tion Management Database).

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 com-ponentes de TI.

ConclusãoA família de produtos Tivoli é uma plataforma aberta, que permite que os administradores das ferramentas as adaptem para atender as necessi-dades de suas empresas.

Administradores Linux, habitua-dos a ter este nível de controle nos seus sistemas operacionais, podem certamente se beneficiar desta com-binação de melhores práticas e fle-xibilidade existente nas ferramentas de gerenciamento de infraestrutura do Tivoli. n

Mais informações

[1] OPAL (IBM Tivoli Open Process Automation Library): http://www-01.ibm.com/software/tivoli/features/opal/

[2] Linux na IBM: http://www.ibm.com/br/linux/index.phtml

[3] Soluções para gerenciamento de Linux da IBM: http://www-01.ibm.com/software/tivoli/solutions/linux/products.html/

[4] Tivoli Information Center (contém produtos para Linux e outros sistemas operacionais): http://www.ibm.com/developerworks/wikis/display/tivolidoccentral/Home/

Gostou do artigo?Queremos ouvir sua opinião. Fale conosco em cartas@linuxmagazine.com.br

Este artigo no nosso site: http://lnm.com.br/article/4003

Sobre os autoresMarcos 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 ferra-mentas 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. É cer-tificado em ITIL Foundations, ITM e Netcool/OMNIbus.

Institute

LinuxProfessional

R

Inscrições e mais informações:

www.lpi-brasil.orgtreinamentos@vectory.com.br

Tel (11) 3675-2600

Inclua em seu currículo a prin-cipal certi�cação Linux no mundo – LPI.

Inclua em seu currículo a prin-cipal certi�caçã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

e�ciência nos negócios e reduzir custos. Atualmente há no mercado uma carência por pro�ssionais certi�cados para

atender a essa demanda crescente. Aproveite essa

oportunidade e inclua em seu