Você está na página 1de 20

ADMINISTRAO E CONTROLE DE MUDANAS DE SERVIOS DE INFRAESTRUTURA DE TI EM DATA CENTERS COM FERRAMENTAS OPEN SOURCE1

Rodrigo de Lima Silva <rodrigodlima@gmail.com> Alexandre Timm Vieira <xanditv@gmail.com> - Orientador


Universidade Luterana do Brasil Curso Superior de Tecnologia em Redes de Computadores Campus Canoas Av. Farroupilha, 8001 Bairro So Jos CEP 92425-900 Canoas - RS

29 de novembro de 2010

RESUMO
Este trabalho apresenta as ferramentas e mtodos necessrios para manter, controlar e administrar os servios de infraestrutura de TI em uma empresa que possui diversos servios crticos em um data center. Aps anlise e identificao dos problemas no cenrio atual, so apresentadas as solues necessrias e implementao das ferramentas para garantir o controle e administrao com qualidade dos servios de TI. Aps a implementao das ferramentas so apresentados os resultados obtidos Palavras-chave: Controle de Mudanas; Open Source; Administrao de Servios de TI.

ABSTRACT
Title: Administration and management change control of infrastructure IT services in data centers with open source tools
This article describes necessary methods and tools, used in order to maintaining, controlling and managing a set of IT infrastructure services of a given company that has several critical services in a data center. After having analyzed and identified the problems regarded to the current scenario, the proposed solutions, and implemented tools to ensure quality control and management of IT service will be presented. After describing the tools implementation all the results obtainde will be presented. Key-words: Change Control; Open Source; IT Service Management.

INTRODUO

Com a necessidade cada vez maior de agilizar e manter um ambiente de infraestrutura de TI controlado, vrias ferramentas, mtodos e processos foram criados com o intuito de possibilitar a excelncia na manuteno e entrega dos servios de TI da organizao. A pouco tempo atrs dizia-se que a rea de TI da organizao precisaria estar alinhada ao negcio, porm hoje em dia a TI j faz parte do negcio, ou seja, so duas reas que devem estar integradas. Pensando nisso, necessrio que a rea de TI esteja preparada para suportar e garantir, em tempo hbil, a entrega de servios de TI necessrias para o negcio da empresa. Durante o desenvolvimento do trabalho, sero apontados os problemas de manter um ambiente de TI sem controle e ser demonstrado as ferramentas que sero utilizadas para resolver estes problemas identificados. Com a necessidade imediata de instalao, configurao e manuteno de servidores torna-se cada vez mais necessrio amadurecer os processos de Gerenciamento de Configurao e Gerenciamento de Mudanas. Como base nesse cenrio, dois processos do modelo COBIT (Control Objectives for Information

Artigo elaborado como Trabalho de Concluso de Curso de Tecnologia em Redes de Computadores da Universidade Luterana do Brasil, Campus Canoas.

and Related Technology), que um framework de Governana de TI, sero utilizados como apoio para realizar este controle. Na seo 2 ser descrito a fundamentao terica das tecnologias e mtodos utilizados para realizar a administrao, controle e agilidade do ambiente de Infraestrutura de TI em datacenters. O cenrio atual e a anlise dos problemas sero descritos na seo 3. Na seo 4 ser apresentado o projeto, onde sero implementadas as solues para resolver os problemas enfrentados no cenrio atual e ao final, na seo 5, ser descrito a concluso do artigo.

FUNDAMENTAO TERICA

Este captulo destina-se apresentao das principais ferramentas e metodologias necessrias para o agilizar e administrar um ambiente de TI em um cenrio com centenas de servidores e milhares de servios. Inicia-se com a definio e explicao de cada software, detalhando seu funcionamento e qual a necessidade de utilizao, realizando comparaes com outros softwares disponveis e citando qual a vantagem de utilizao do software escolhido.

2.1

Ferramentas de mercado para Gerenciamento de Configurao

Existem atualmente no mercado diversos softwares, tanto open source como comerciais, para facilitar a administrao e controle de todo ambiente de servidores. Dentre os softwares comerciais podemos citar o Red Hat Network Satellite, um produto da empresa lder no mercado de Sistemas Operacionais Linux, CA Automation Suite for Data Centers da empresa Computer Associates e o Puppet da empresa Puppet Labs e o Spacewalk, que tambm pertence a empresa Red Hat, porm a verso open source do produto comercial Satellite. Tanto o Spacewal como o Puppet so softwares open source e no necessrio licenciamento. Estas 4 ferramentas podem ser utilizadas para implantar de forma dinmica um ambiente controlado e gil de servidores em um data center, mas cada uma possui suas vantagens e desvantagens, ento a deciso tem que ser tomada levando em conta vrios fatores, tais como custo de licenciamento, suporte, funcionalidades e principalmente saber qual a ferramenta a melhor para atender o tipo de negcio e ambiente de TI da empresa. 2.1.1 Puppet O Puppet um framework open source de gerenciamento de sistemas e configuraes baseados na linguagem de programao Ruby e trabalha no modelo cliente-servidor (TURNBULL, 2007). A sua proposta entregar para os administradores de sistemas um sistema de gerenciamento simples, consistente, transparente e flexvel. Com o Puppet possvel automatizar todo o processo de configurao de um servidor e reproduzir esta configurao para quantos servidores foram necessrios ao mesmo tempo, diminuindo consideravelmente o tempo de entrega e configurao dos servios e tambm possvel ter a gesto diria da rede e a manter sob controle, concentrando todos os esforos das equipes de TI nos problemas reais e novos projetos. O Puppet funciona de maneira modular, ou seja, possvel adicionar ou remover vrios recursos sem a necessidade de reinstalao do software. Os mdulos podem automatizar tarefas tais como a criao de um banco de dados, um servidor Web ou um servidor de e-mails por exemplo. Outro recurso importante o Dashboard, que uma interface web e uma ferramenta para gerao de relatrios. O Dashboard facilita o gerenciamento e configurao de tarefas, fornece a visualizao rpida das informaes importantes e gera relatrios sobre o sistema. Dando continuidade aos recursos, citar o Facter, que uma biblioteca da linguagem de programao Ruby e destinada a reunir informaes dos sistemas para a tomada de deciso do Puppet, alm de reunir informaes sobre o sistema operacional, tais como verso do kernel, nmero de interfaces de rede entre outras. Este um dos recursos mais interessantes e uma das vantagens em relao aos outros softwares de

mercado, pois como ele consegue identificar a verso do sistema operacional, ele executa os comandos de acordo com a distribuio Linux. Por exemplo, ao criar um recurso no Puppet para instalao do software Postfix, ele executa a instalao de acordo com o gerenciador de pacote da distribuio, se for uma distribuio baseada em RPM, o pacote instalado com o yum, se for distribuio baseada em Debian, o pacote instalado com o apt. 2.1.2 Spacewalk Spacewalk uma soluo para gerenciamento de sistemas Linux que permite realizar inventrio de informaes sobre hardware e software, instalar e realizar atualizao de sistemas, customizar pacotes, provisionar, gerenciar e distribuir arquivos de configurao e monitorar sistemas. Como caracterstica, podemos destacar a fcil instalao e administrao. O Spacewalk baseado no Red Hat Network Satellite, diferenciando-se por ser open source e permitir a integrao com outras distribuies Linux (seo 2.5) alm da Red Hat, tais como CentOS, Fedora e SuSe. Atravs de uma interface Web de administrao, possvel realizar todas as operaes de configuraes e ter uma idia de quantidade de servidores registrados e quantos destes servidores esto devidamente atualizados com os ltimos patches de segurana. A idia principal trabalhar com o conceito de chaves. O administrador de sistemas, ao registrar um servidor no Spacewalk, deve escolher uma chave de ativao, essa chave definida pelo administrador no Spacewalk. Definindo a chave de ativao o servidor registrado em um canal (grupo) de atualizaes. Outro recurso importante que pode-se definir atravs de chaves e canais quais softwares sero instalados utilizando determinada chave, pode-se tambm criar alguns arquivos de configuraes personalizados e com isso criar um padro de instalao de servidores.

2.2

Ferramentas de mercado para Gerenciamento de Mudanas

Para manter o controle de mudanas e configuraes importante utilizar ferramentas que possam realizar este controle, mantendo um histrico de mudanas e controle de verses de softwares. Abaixo alguns conceitos e definies das ferramentas utilizadas atualmente. 2.2.1 Subversion O Subversion uma ferramenta open source para controle de verses de softwares. Ele utilizado normalmente para se ter um histrico de mudanas no cdigo fonte. Na grande maioria dos casos o Subversion utilizado para auxiliar os desenvolvedores de sistemas, pois ele permite que vrios desenvolvedores alterem o mesmo arquivo fonte e depois que realizarem a mudana podem submeter para o repositrio central. A cada modificao que submetida ao repositrio, a verso do arquivo incrementada. Logo, se algum problema ocorrer no software aps a mudana, basta fazer o rollback da verso anterior onde o erro no ocorria. Como este controle de verso muito til, ele utilizado por muitos administradores de sistemas para controlar as verses dos arquivos de configuraes dos servidores, para que seja possvel ter um histrico de mudana e tambm para fazer um rollback da configurao anterior. Existem alguns clientes Subversion para realizar estas operaes, o mais conhecido atualmente no mercado o TortoiseSVN, que funciona em sistemas operacionais Microsoft Windows e atravs de interface de comando no Linux, utilizando o comando svn. 2.2.2 CA Software Change Manager O CA Software Change Manager um produto da empresa Computer Associates, no qual oferece diversos recursos interessantes para realizar o Gerenciamento de Controle e Gerenciamento de Mudanas, que so dois processos do modelo COBIT.

Como caractersticas podemos citar uma interface web para realizao do gerenciamento de mudanas, fcil integrao com outras ferramentas da Computer Associates, possui arquitetura multi plataforma, administrao centralizada entre outras.

2.3

Modelos de boas prticas de TI

Atualmente muito importante para qualquer empresa utilizar boas prticas para manter um ambiente de TI organizado e para manter o tempo de indisponibilidade do servio de TI o mais baixo possvel. O modelo de boas prticas mais utilizadas no mercado atualmente so o ITIL (Information Technology Infrastructure Library) e o COBIT (Control Objectives for Information and related Technology). O COBIT um framework de governana de TI e ferramentas de suporte que permite a gestores avaliar as exigncias de controle, questes tcnicas e riscos financeiros (ICASA, 2010). O CobiT define as atividades de TI em um modelo de processos genricos com quatro domnios. Esses domnios so Planejar e Organizar, Adquirir e Implementar, Entregar e Suportar e Monitorar e Avaliar. Esses domnios mapeiam as tradicionais reas de responsabilidade de TI de planejamento, construo, processamento e monitoramento (IT GOVERNANCE INSTITUTE, 2007). Dentro destes 4 domnios existem 34 processos, onde as organizaes normalmente acabam no utilizando todos estes processos. Destes 34 processos, podemos destacar dois que so bastante utilizados na rea de infraestrutura de TI, que so o DS9 Gerenciar a Configurao e AI6 Gerenciar as Mudanas. Para ser eficaz, o Gerenciamento de Configurao deve estabelecer um repositrio central de todos os itens de configurao, identificao e manuteno dos itens de configurao e reviso da integridade dos dados de configurao (IT GOVERNANCE INSTITUTE, 2007). Todas as mudanas, incluindo manutenes e correes de emergncia, relacionadas com a infraestrutura e as aplicaes no ambiente de produo so formalmente gerenciadas de maneira controlada. As mudanas (incluindo procedimentos, processos, parmetros de sistemas e de servio) devem ser registradas, avaliadas e autorizadas antes da implementao e revisadas em seguida, tendo como base os resultados efetivos e planejados. Isso assegura a mitigao de riscos de impactos negativos na estabilidade ou na integridade do ambiente de produo (IT GOVERNANCE INSTITUTE, 2007).

2.4

Distribuies Linux

O Linux pode ser definido como Kernel, ou seja, o ncleo do sistema operacional. O Linux se originou em 1991 como um projeto pessoal de Linus Torvalds, um universitrio finlands (NEMETH, SNYDER e HEIN, 2004, p.4). Os softwares, comandos e daemons juntamente com o Kernel (ncleo) formam o sistema operacional. As diferentes formas de montagem do sistema operacional Linux que formam as distribuies. As distribuies variam em termos de foco, suporte e popularidade (NEMETH, SNYDER e HEIN, 2004 p.5). Como o Linux est licenciada sobre a licena GPL (General Public Licence), as pessoas esto livres para modificar e distribuir, por isso existem tantas distribuies atualmente no mercado. 2.4.1 RPM As principais e mais perceptveis diferenas entre elas est na forma como so feitas as atualizaes e instalao de softwares. Algumas distribuies utilizam o RPM (Red Hat Package Manager) como gerenciador de pacotes e outras utilizam o DPKG (Debian Package). Devido a estas diferenas, no possvel instalar um software baseado em DPKG em uma distribuio baseada em RPM e vice-versa. Existem tambm alguns front-ends para estes gerenciadores de pacotes para facilitar ainda mais a instalao de pacotes. Ao instalar algum pacote com o RPM ou DPKG, realizado uma checagem de dependncias, onde se valida se o software que est sendo instalado depende de algum outro pacote, caso o pacote tenha dependncia, o RPM ou o DPKG no conclui a instalao e emite um erro informando quais as dependncias que esto faltando. O YUM (Yellow dog Updater, Modified) e o APT (Advanced Packaging Tool) so frontends para estes dois gerenciadores de pacotes e resolvem o problema de pendncias. O YUM utilizado em

distribuies baseadas em Red Hat, tais como Fedora, CentOS, SuSe e o APT utilizado em distribuies baseadas de Debian. Tanto o YUM como o APT, antes de instalar um pacote, verificam suas dependncias e realizar o download dos pacotes necessrios para instalao e com isso facilita todo o processo de instalao de softwares. Geralmente, quando se trabalha com administrao de servidores, interessante automatizar todo o processo de instalao de pacotes e muitas vezes esta tarefa se torna complicada, uma vez que existem softwares que no esto empacotados no formato RPM ou DPKG, eles simplesmente so softwares compactados que disponibilizam somente o cdigo fonte e necessrio realizar o processo de compilao e instalao manual, atravs do processo make e ./configure. 2.4.2 Rpmbuild Uma maneira que utilizada para automatizar e simplificar este processo atravs de empacotamento do cdigo fonte em pacote RPM. O utilitrio rpmbuild utilizado para isso. O rpmbuild realiza o processo de compilao do software e disponibiliza os binrios e demais arquivos em um arquivo RPM. Desta forma, os administradores podem disponibilizar de maneira automtica vrios softwares que no esto nos repositrios principais das distribuies e tambm permite que se faa pacotes personalizados, de acordo com a necessidade. Todo pacote RPM possui um arquivo de configurao, chamado de spec file, que a entrada para o utilitrio rpmbuild (IBM, 2010). Dentro do arquivo spec que ficam as informaes sobre como o pacote deve ser instalado, qual o caminho dos arquivos e binrios e principalemnte onde ficam as informaes sobre o autor do software, descrio e principalmente o changelog, ou seja, o log de todas as modificaes j realizadas no pacote. com base neste arquivo que o comando rpm busca as informaes quando solicitadas, conforme Figura 1.

Figura 1 Verificando as informaes do pacote RPM 2.4.3 DeltaRPM

DeltaRPM uma ferramenta que gera pacotes RPM's e que contm a diferena entre o pacote instalado e a nova verso do pacote. Com isso, possvel recriar um novo RPM a partir das diferenas, o que acaba diminuindo consideravelmente o seu tamanho. (DELTARPM, 2010).

PROJETO/MODELAGEM

Este captulo destina-se apresentao do cenrio atual, anlise dos problemas e solues propostas para resolver os problemas identificados.

3.1

Cenrio atual

A empresa onde ser implantado as mudanas sugeridas no trabalho atua no mercado financeiro, tendo uma estrutura de tecnologia da informao centralizada em um data center principal e secundrio em Porto Alegre e atualmente possui 1.400 (mil e quatrocentos) unidades de atendimento espalhadas por vrios estados brasileiros, entre eles So Paulo, Mato Grosso do Sul, Santa Catarina, Paran, conforme ilustrado na Figura 1. Em cada unidade de atendimento h um servidor com sistema operacional Linux, distribuio (seo 2.5) CentOS, onde rodam diversos servios locais e alguns servios so executados no data center principal. Todos os servidores das Unidades de Atendimento possuem a mesma configurao e so padronizados, mudando apenas endereamento de rede IP e hostname, Alm dos 1.400 (mil e quatrocentos) servidores espalhados pelo pas, h ainda algumas centenas de servidores no data center principal e praticamente a mesma quantidade de servidores replicados para o data center secundrio que servem de contingncia caso acontea alguma falha no data center primrio. 3.1.1 Links para comunicao com a rede WAN A comunicao entre o data center e os servidores das unidades de atendimento se do atravs de links MPLS (Multiprotocol Label Switching) e link satelital. O link MPLS o link primrio e o link satelital funciona como contingncia, caso o link MPLS fique indisponvel. Existem algumas unidades de atendimento que s possuem link satelital, por estarem em alguma regio ao qual a Operadora de Telecomunicaes no consegue chegar com suas fibras pticas. Toda a estrutura localizada nas unidades de atendimento, para fins de localizao, chamada de rede WAN. J a rede LAN fica localizada em Porto Alegre, no mesmo prdio onde est localizado o data center. Neste prdio onde fica localizado o centro administrativo, que responsvel por prestar todo o suporte tecnolgico e administrativo para as unidades de atendimento. Neste local tambm que fica a rea de Infraestrutura de TI da empresa, responsvel por manter e administrar toda a rea de TI. 3.1.2 Infraestrutura de servidores localizados na rede WAN Os servios de infraestrutura que rodam atualmente nos servidores das Unidades de Atendimento so basicamente os seguintes: E-mails Internet Compartilhamento de arquivos DNS Banco de dados Demais aplicaes de negcio Como as mudanas nas verses das aplicaes muito constante, necessrio enviar toda mudana para todos os servidores ao mesmo tempo, e isto leva muito tempo caso no tenha algum processo automatizado para realizar estas tarefas. No cenrio atual, existe um script em shell para realizar esta tarefa automaticamente. Esse script que roda em todos os servidores consulta todos os dias s 22 horas o repositrio de softwares, que fica em um servidor web Apache, e verifica se h alguma atualizao de pacote RPM (Seo 2.5) a ser realizado,e se tiver, realiza o download e instalao do pacote. O agendamento para rodar o script de atualizao realizado atravs da cron, que uma espcie de agendador de tarefas dos sistemas Microsoft Windows. Existe um servidor no data center que onde so realizados as mudanas nos pacotes RPM que so enviados para os servidores das unidades de atendimento. neste servidor que so realizadas as mudanas e atualizaes nos aplicativos que so enviados para os servidores. Atualmente, no h um controle de mudanas eficaz nestes aplicativos, os pacotes so apenas modificados e incrementado a release, ou seja, se um pacote estava na verso 1.1.1, aps alterao e modificao do pacote a verso incrementada, ficando 1.1.2. O controle das mudanas feito atravs do changelog do pacote, conforme explicado na seo 2.5.

3.1.3

Infraestrutura de servidores localizados no data center

J no Data center a estrutura um pouco diferente. Existem centanas de servidores Linux, com as mais variadas distribuies (seo 2.5), ou seja, um ambiente de TI bastante heterogneo, com maneiras de administrao diferentes, dependendo do servidor. Existem servidores de aplicao TomCat, Jboss e Oracle rodando em diferentes distribuies e sem nenhum tipo de gerenciamento ou controle. Os servios administrados nos ambientes de produo e que utilizam o sistema operacional Linux como base so dos mais variados tipos, tais como bancos de dados, servidores web, servidores de compartilhamento de arquivos, ente outros. Mas a grande maioria so servidores de aplicao Java, tais como TomCat, Jboss e Oracle.

3.2

Anlise e restries identificadas

Este captulo destina-se a apresentar os problemas identificados no cenrio atual, tanto na estrutura de rede WAN como na LAN e propor as solues necessrias para resolver os problemas identificados. 3.2.1 Problemas identificados na infraestrutura de servios da rede WAN Analisando o cenrio atual, principalmente na estrutura de rede WAN, onde existem milhares se servidores espalhados por diversos estados do Brasil, percebe-se que ele apresenta alguns problemas por possuir uma estrutura que no permite excees. Por no permitir excees, acaba dificultando algumas configuraes que so necessrias em servidores diferentes. Por exemplo, quando necessrio enviar alguma aplicao para alguns servidores para se realizar um piloto ou homologao, no possvel colocar esta aplicao no repositrio de updates, pois todos os servidores baixaro e instalaro esta aplicao. Uma forma de contornar a situao enviar via script esta aplicao para uma lista de servidores que devem entrar no piloto. Porm, este modelo no possui um controle eficaz de quais servidores realmente esto em piloto e os que no esto. Outro problema identificado que como a aplicao enviada via link de comunicao MPLS, caso algum servidor esteja desligado ou a comunicao esteja indisponvel, o envio do(s) arquivo(s) falhar. Devido a este problema, necessrio rodar outro script para realizar a conexo nos servidores para saber se o servidor recebeu ou no o(s) arquivos(s) corretamente. Seguindo a identificao dos problemas, percebe-se que seguidamente os tcnicos de campo precisam se deslocar at as unidades de atendimento para realizar a reinstalao do sistema operacional devido a problemas de hardware, tais como erros fsicos no hard disk ou queima da placa me por exemplo. Os tcnicos possuem uma mdia de instalao desatualizada em um cd-rom e com isso a cada nova instalao necessrio realizar a atualizao dos pacotes que esto no repositrio de atualizaes, essa atualizao possue em mdia 1Gb de arquivos. Essa atualizao demora em torno de 1 dia at ser concluda e acaba sendo um transtorno para os colaboradores e associados da unidade de atendimento, pois os servios ficam comprometidos durante quase dois dias teis. Como a quantidade de servidores na WAN muito elevada, invivel manter o controle sem uma ferramenta que permita realizar essa tarefa. Com o passar do tempo, vrios servidores ficam com configuraes diferentes e outros desatualizados, isto acaba gerando grande quantidade de chamados na Central de Atendimento. 3.2.2 Problemas identificados na infraestrutura de servios no data Center Analisando o cenrio dos servidores localizados no data center, corfome descrito na seo 3.1, percebe-se que no foi definido um padro de distribuio Linux (seo 2.5) para utilizar nos servidores, sendo assim o ambiente de TI acabou ficando muito heterogneo, com diversas distribuies e maneiras de administrao diferentes. Existem vrios servidores de aplicao TomCat, Jboss e Oracle rodando em diferentes distribuies e sem nenhum tipo de gerenciamento e controle centralizado. No h tambm um processo rpido para disponibilizar um servidor de aplicao para a produo, ou seja, quando surge alguma demanda para um novo servidor, o processo de instalao e configurao do sistema operacional e demais aplicaes gira em torno de 2 dias teis, e isso acaba sendo um gargalo na entrega de novos projetos necessrios para o negcio.

Alm disso, como no existem ferramentas para o controle, servidores com a mesma aplicao esto com configuraes diferentes, o que acaba gerando problemas diferentes. Alm disso, praticamente invivel enviar alguma configurao personalizada para todos os servidores. Por exemplo, caso seja necessrio alguma alterao na infraestrutura de servidores DNS, necessrio alterar o arquivo /etc/resolv.conf de todos os servidores, alterando o endereo IP de acordo com os novos servidores DNS. Como no h um processo automatizado, enviado um e-mail para todas as equipes informando que o endereo IP dos servidores DNS foram trocados e necessrio realizar as modificaes em todos os servidores da equipe responsvel manualmente. Outro problema identificado no cenrio anteriormente descrito que no possui um local definindo onde informa qual equipe responsvel por determinado servidor, ou seja, quando ocorre um problema em um determinado servidor, ficava complicado de definir ou saber se aquele servio da equipe de infraestrutura, desenvolvimento ou aplicao.

3.3

Solues propostas

Este captulo destina-se a apresentar as solues propostas para resoluo dos problemas com base nos problemas identificados no captulo anterior. 3.3.1 Infraestrutura de servios da rede WAN Foi proposto a utilizao do software Spacewalk descrito na seo 2.2.2 para gerenciamento dos servidores localizados na rede WAN. Atravs desta ferramenta, ser possvel identificar facilmente todos os servidores que esto com softwares desatualizados. Como citado na identificao dos problemas, h um grande problema quando necessrio realizar homologao de softwares em determinados servidores. Com a utilizao do Spacewalk ser possvel criar canais de softwares onde ficaro os softwares que sero homologados. Aps ser possvel registrar os servidores desejados neste canal de homologao, com isto haver um controle de quais servidores esto em homologao e quais servidores esto ou no atualizados. Com a utilizao do spacewalk ser possvel diminuir o tempo de indisponibilidade e atualizao dos servidores da rede WAN, facilitando o download de atualizaes, j que ser possvel trabalhar com o conceito de DeltaRPM, citado na seo 2.5.3, ou seja, quando h uma atualizao em algum software, o Spacewalk faz o download apenas da diferena entre o pacote instalado e o pacote que sofreu a atualizao, ou seja, o download do pacote ser muito menor e levar menos tempo para ser concludo. Para o controle de mudanas, seguindo o modelo COBIT, ser utilizado a ferramenta Subversion. Atravs dela, qualquer atualizao de software dever ser comitada antes no repositrio, mantendo um histrio eficaz de mudanas. Atravs deste controle ser possvel identificar qual arquivo ou quais arquivos que sofreram modificaes e em qual data. 3.3.2 Infraestrutura de servios do data Center A ferramenta Puppet e Spacewalk sero utilizadas para o controle de servidores e servios localizados no data center. Como o ambiente heterogneo, no teria como utilizar somente o Spacewalk, pois ele trabalha com o conceito de pacotes RPM e teria problemas em execuo e controle de servidores baseados em Debian ou BSD por exemplo. O Puppet consegue identificar qual o sistema operacional est rodando no servidor, com base nessa informao ele ir executar o comando de acordo com a distribuio, no precisando ser feito um script para cada distribuio. Seguindo nesssa linha, com o deploy de arquivos utilizando o Puppet, ser possvel resolver problemas do tipo identificado anteriormente, com relao a mudana de DNS. (explicar melhor sobre isso) Por fim, ser implementado o Nagios para sanar a falta de um monitoramento eficaz de todos os servidores e servios.

IMPLEMENTAO / RESULTADOS

Este captulo destina-se a apresentar os detalhes relevantes para implementar os softwares necessrios para as solues propostas no captulo anterior para que os problemas identificados no cenrio atual sejam sanados. Ser demonstrado tambm os resultados obtidos aps a implementao para atingir os objetivos propostos, que so: Deploy automatizado de configuraes. Controle e histrico de mudanas. Diminuio do tempo de entrega de servios. Monitoramento dos servios.

4.1

Puppet

Este captulo abordar os requisitos, conceitos e configuraes relevantes para a instalao e implementao da ferramenta Puppet e apresentar os resultados obtidos aps a implementao. 4.1.1 Requisitos Um dos requisitos para instalao do Puppet referente ao sistema operacional, pois ele roda apenas em sistemas baseados Unix ou Linux. No momento em que este artigo est sendo escrito, a verso estvel do Puppet a 2.6.2, esta verso est disponvel no site do fabricante. esta a verso utilizada no decorrer do artigo. A distribuio Linux que ser usada para instalao ser a CentOS verso 5.3. Como no h os pacotes do puppet no repositrio principal da distribuio, ser compilado e instalado partir do cdigo fonte. A instalao simples, mas existem alguns pr-requisitos para a instalao. necessrio realizar a instalao do interpretador Ruby e suas bibliotecas. Na distribuio CentOS, possvel realizar a instao partir do repositrio oficial atravs do comando yum. O Puppet no requer hardware de ponta, mas recomenda-se que seja um servidor com pelo menos 2Gb de RAM e processador Intel acima de 2Ghz, dependendo claro do nmero de clientes e configuraes. Este modelo de hardware suporta tranquilamente de 50 a 100 clientes conectados. 4.1.2 Funcionamento Para disponibilizar a conectividade cliente-servidor, o Puppet usa o protoco XML-RPC rodando sobre o protocolo HTTPS na porta 8140. Desta maneira, as sesses so encriptadas e so autenticadas com certificados assinados. Cada nodo gera um certificado assinado e ento esse certificado validado e autorizado pelo Puppet Master (TURNBULL, 2007). Depois disso cada cliente contata o servidor, por padro a cada trinta minutos atravs de um agente, para confirmar que sua configurao est atualizada. Se uma nova configurao estiver disponvel ou a configurao foi alterada, ela recompilada e ento aplicada no cliente. Uma observao importante que se o cliente no tiver o certificado assinado ele no conseguir contactar o servidor master, gerando um erro conforme Figura 2. Figura 2 Log informando erro de certificado

Se for necessrio enviar uma atualizao com alguma configurao, pode ser realizada foradamente atravs do servidor, forando a configurao no cliente. Se alguma configurao existente no cliente estiver diferente, ela corrigida de acordo com a original a partir do servidor. Os resultados de qualquer alterao so registrados e transmitidos para o servidor. 4.1.3 Configuraes Primeiramente foram criados alguns diretrios para fins de organizao, ou seja, no necessrio seguir esse modelo, todos os arquivos de definies podem ser colocados abaixo de /etc/puppet/manifests diretamente. A estrutura de diretrios ficou conforme Figura 3.

Figura 3 Estrutura de diretrios localizados em /etc/puppet Dentro do diretrio classes, conforme Figura 4, ficam as definies de classes necessrias, de acordo com a necessidade. No cenrio proposto, o arquivo baseapps.pp possui alguns pacotes bsicos que devem estar instalados em alguns servidores. O contedo do arquivo listado na Figura 4.

Figura 4 - Contedo do arquivo baseapps.pp Conforme mostrado na Figura 4, quando o cliente consultar o puppetmaster, ele ir verificar se os pacotes joe, perl e ruby esto instalados, caso no estejam, esses pacotes sero instalados. Conforme Figura 5, no diretrio nodes ficam as definies dos nodos, tambm conhecido como clientes. O contedo do arquivo nodes.pp pode ser verificado na Figura 6.

10

Figura 5 Definio dos clientes Conforme Figura 5, foram cadastrados dois clientes, onde informa que o nodo web.example.com faz parte da classe webserver e nodo vostro.example.com pertence a classe basenode. Tanto a classe webserver como a classe basenode foram definidas no arquivo template.pp que possui o contedo conforme Figura 6.

Figura 6 Definies de templates Conforme ilustrado na Figura 7, percebe-se a utilidade de utilizar a funcionalidade Facter, citada no incio do captulo. Ou seja, de acordo com o sistema operacional, possvel definir uma classe com configuraes personalizadas. Todos os nodos que forem cadastrados e que utilizem a classe basenode automaticamente incluiro as classes baseapps, ntp e resolv. Com essa configurao foi possvel criar um padro para cada distribuio. A Figura 7 demonstra as definies das classes fedora, debian e centos.

11

Figura 7 Definies das classes de Sistemas Operacionais A classe resolv citada anteriormente uma classe do tipo template, ou seja, utilizado um modelo de arquivo para satisfazer as necessidades, conforme Figura 8. Neste caso, o modelo para o arquivo /etc/resolv.conf, que o arquivo utilizado pelas distribuies Linux para informar quais os servidores DNS sero utilizados para consultas. Quando o cliente utilizar a classe resolv, ele receber o arquivo resolv.conf padronizado pelo Puppet. J a classe ntp necessita utilizar a funcionalidade facter, pois depende do sistema operacional utilizado, j que o nome do daemon para iniciar e parar o servio ntp muda dependendo da distribuio.

Figura 8 Exemplo de utilizao de templates Para verificao e anlise dos logs dos clientes que esto registrados no Puppet, foi instalado o Puppet Dashboard, que uma interface web utilizada justamente para este fim.

12

Figura 9 Tela de log do Puppet Dashboard

13

4.1.4

Resultados

Com a implementao e configurao do Puppet foi possvel resolver os problemas identificados na seo 3.2.2, pois foram criados algumas definies de distribuies Linux, pacotes que devem ser instalados por padro nas distribuies e templates de arquivos de configuraes. Nos testes realizados na implementao foi definido um template para o arquivo /etc/resolv.conf para padronizar a consulta DNS dos servidores. Caso seja necessrio qualquer alterao de endereamento IP dos servidores DNS, basta alterar o template no Puppet e essa configurao ser replicada para todos os servidores de forma automtica. Tambm foi definido um template para o arquivo /etc/ntp.conf onde definiu-se quais seriam os servidores NTP (Network Time Protocol) que deveriam ser consultados para atualizao de horrio do sistema operacional. Dependendo da distribuio Linux, a forma de iniciar e parar o servio ntp muda um pouco. Por exemplo, em distribuies Debian, o daemon do NTP ntp, j na distribuio CentOS ntpd. Com a utilizao da funcionalidade Facter do Puppet, foi possvel tratar esta peculiaridade, pois o Puppet consegue identificar qual o Sistema Operacional e iniciar o servio corretamente.

4.2

Spacewalk

Este captulo abordar os requisitos, conceitos e configuraes relevantes para a instalao e implementao da ferramenta Spacewalk. 4.2.1 Requisitos recomendvel que o Spacewalk seja instalado em uma das trs distribuies mais utilizadas atualmente no mercado corporativo, que so: Red Hat, Fedora e CentOS. recomendvel tambm um hardwware robusto, pois o Spacewalk trabalha com banco de dados, podendo ser Oracle ou Postgresql. O espao em disco para armazenar os pacotes de instalao depende de quais canais de distribuies sero utilizadas, mas recomenda-se pelo menos 6GB por cada canal de software. Com relao a memria, o mnimo 2GB e o recomendado 4GB ou mais. 4.2.2 Funcionamento

O Spacewalk trabalha com o conceito de canais e chaves. Os canais so os repositrios de softwares. Por exemplo, existe um canal chamado CentOS5.3 e outro chamado de Fedora13, dentro do canal CentOS5.3 existem diversos softwares especficos para esta distribuio e o mesmo ocorre com o canal Fedora13. Quando um cliente faz o registro, ele utiliza uma chave, esta chave contm a informao de qual canal de software aquele servidor ser registrado e a partir da o cliente baixa as atualizaes disponveis daquele canal. Uma observao importante que no necessrio realizar a instalao de nenhum agente nos clientes. 4.2.3 Configuraes Foi criada uma chave de ativao no Spacewalk para os servidores da rede WAN, conforme ilustrado na Figura 9. Quando um servidor da rede WAN for registrado utilizando esta chave, ele automaticamente ser cadastrado no grupo. A chave de ativao gerada automaticamente pelo Spacewalk. Para que o servidor cliente faa o registro no Spacewalk, basta ele executar o comando abaixo, informando a chave de ativao conforme ilustrado na Figura 10: [root@servidor rhn]# rhnreg_ks --activationkey 1-3bfa903c75500420694ce96579583827 --serverUrl https://app1web1p.example.com/XMLRPC

14

Figura 10 Chaves de ativao no Spacewalk Aps a ativao do cliente, j possvel visualizar as informaes no Spacewalk referente ao sistema, tais como updates, erratas, etc, conforme ilustrada na Figura 11.

Figura 11 Informaes de servidores registrados no Spacewalk Foi criado tambm um canal de configurao chamado homologacao. Este canal tem o objetivo de disponibilizar os pacotes que sero usados para testes. Esta configurao permite que se tenha controle de todos os servidores que esto em homologao. Dentro deste canal possvel colocar todos os pacotes desejados para homologao e os servidores que estiverem cadastrados neste canal faro o download e instalao do pacote automaticamente. Conforme pode ser visto na Figura 12, dentro do canal de configurao homologao, so listados todos os sistemas que esto registrados, facilitando o controle.

15

Figura 12 Lista de servidores registrados no canal de homologao Na aba Packages pode ser visualizado os pacotes que fazem parte deste canal, conforme Figura 13.

Figura 13 Lista de pacotes no canal de homologao Conforme ilustrado na Figura 13, o pacote oracle-xe-univ est incluso no canal de homologao, o que significa que este pacote ser instalado em todos os servidores que estiverem registrados neste canal. 4.2.4 Componente extra Foi configurado e implementado no ambiente de testes a utilizao de pacotes Deltarpm, conforme explicado na seo 2.5.3. O objetivo de trabalhar com pacotes Detarpm diminuir o tamanho do pacote RPM e com isso diminuir tambm o tempo de download de atualizaes. Conforme Figura 14, foi criado um pacote hello-2.6.4.noarch.rpm que contm 3 arquivos: Samba3HOWTO.pdf, hello e hello.1.gz. Este arquivo possui o tamanho de 3.2Mb. Aps foi criado um novo pacote, onde foi adicionado um novo arquivo chamado BIND.pdf. Aps foi criado o pacote deltarpm, com a diferena entre a verso 2.6.4 e 2.6.5 do pacote. Conforme ilustrado na Figura 15, o pacote hello2.6.6.noarch.rpm foi criado contendo 4 arquivos: Samba3-HOWTO.pdf, hello, hello.1.gz e BIND.pdf. O pacote hello-2.6.6.noarch.rpm ficou com o tamanho de 408Kb, apenas com a diferena entre a verso 2.6.4 e 2.6.5, ou seja, apenas o tamanho do arquivo BIND.pdf.

16

Figura 14 Diferena de tamanho dos pacotes utilizando Deltarpm 4.2.5 Resultados

Conforme ilustrado nas figuras acima, nos testes realizados com a configurao e implementao do Spacewalk, foi possvel resolver os problemas identificados na seo 3.2.1. Foi criado uma chave de ativao para os servidores localizados na rede WAN e um canal de homologao com o intuito de disponibilizar neste canal os softwares que deveriam ser homologados. Com essa configurao, foi possvel identificar quais os servidores que estavam registrados no canal de homologao e tambm quais os servidores que estavam devidamente registrados no Spacewalk e devidamente atualizados. Com a utilizao dos pacotes Deltarpm durante os testes, foi perceptvel os resultados obtidos com relao ao tamanho dos pacotes. Os resultados mostraram que com a utilizao dos pacotes Deltarpm podese diminuir o tamanho do pacote em torno de 70%. Com essa utilzao, foi possvel resolver o problema citado na seo 3.2.1, onde era necessrio grande quantidade de tempo e de link de comunicao a cada nova instalao de servidores.

4.3

Subversion

Este captulo abordar os requisitos, conceitos e configuraes relevantes para a instalao e implementao da ferramenta Subversion. 4.3.1 Requisitos No h requisitos para a instalao do Subversion. Existe instalador para os mais variados sistemas operacionais, incluindo AIX, CentOS, Debian, Fedora, FreeBSD, HP-UX, Mac OS X, Solaris e Microsoft Windows. No necessrio tambm de um hardware robusto. 4.3.2 Funcionamento O Subversion um sistema centralizado de compartilhamento de informaes (SUSSMAN, FITZPATRICK e PILATO, 2004). Este sistema centralizado chamado tambm de repositrio. O respositrio armazena as informaes no formato de rvore, tipicamente na hierarquia de arquivos e diretrios. O funcionamento simples, o cliente baixa os arquivos armazenados no repositrio para sua mquina local e realiza as modificaes que achar necessrio. Aps realizar as modificaes, o cliente pode enviar as modificaes para o repositrio principal, com isso os demais clientes podem consultar as alteraes que foram realizadas em um determinado arquivo. Ou seja, nenhuma modificao feita no repositrio central, somente nos clientes.

17

4.3.3

Configuraes O Subversion ser utilizado para controle de mudanas e configuraes, de acordo com o modelo COBIT, para realizar as mudanas nos pacotes que sero distribudos para homologao dos servidores localizados na rede WAN. Esse controle necessrio, pois assim ser possvel enviar correes e atualizaes de softwares que esto em homologao facilmente. Foi criado uma estrutura de diretrios necessrios para a compilao e montagem dos pacotes RPM's. No recomendvel realizar a compilao de pacotes utilizando o usurio root, ento foi criado o usurio compiler. Dentro do diretrio home deste usurio foi criado o diretrio chamado projetos. Dentro desta pasta foram criados os diretrios BUILD, RPMS, SPECS e SRPMS. Esta a estrutura de diretrios padro para distribuies que utilizam o gerenciador de pacotes RPM. Ser esta a estrutura de diretrios que ser versionada pelo Subversion. Foi criado ento um projeto chamado Hello para demonstrar o funcionamento da soluo. Conforme explicado anteriormente foi criado o seguinte diretrio /home/compiler/projetos/projeto-hello. Dentro deste diretrio foram criado s os diretrios BUILD,RPMS,SPECS e SRPMS. Foi realizado ento a montagem do pacote RPM utilizando o utilitrio rpmbuild, citado na seo 2.5.2. Aps a montagem do pacoter ter sido realizada corretamente, foi importado o diretrio projetos para o repositrio Subversion com o comando svn import conforme Figura 15.

Figura 15 Importando o projeto para o repositrio Conforme Figura 16, aps a importao do projeto, possvel listar os projetos que esto disponveis no repositrio.

Figura 16 Listagem dos projetos do repositrio Aps realizar a importao do projeto para o respositrio, recomendvel remover o diretrio local criado e realizar o checkout do cdigo atravs do Subversion, somente assim se ter o controle de versionamento, conforme ilustrado na Figura 17.

18

Figura 17 Realizando o checkout do projeto Hello Qualquer alterao em algum arquivo dever ser comitado ao repositrio Subversion atravs do comando snv ci. Atravs deste processo todos os arquivos sero versionados e ser possvel ter o controle de todas as mudanas e tambm ser possvel verificar o log de mudanas com o comando svn log, conforme Figura 18.

Figura 18 Comitando alteraes no repositrio e verificando log de alteraes 4.3.4 Resultados

Aps a implementao do Subversion, citada acima, foi possvel controlar todas as mudanas nos pacotes RPMS que so modificados e enviados para a produo, garantindo assim o Controle de Configuraes e Mudanas, conforme modelo COBIT. Com a implementao do Subversion, qualquer alterao em algum arquivo necessariamente necessita ser enviado/gravado no repositrio central. Com isso, qualquer alterao realizada fica devidamente registrada nos logs para uma possvel auditoria para identificao de erros.

CONCLUSO

Este trabalho demonstrou as ferramentas e mtodos necessrios para administrar e controlar um ambiente de servios de infraestrutura de TI em um data center. Foi realizado uma anlise dos problemas atuais e proposto a implementao de ferramentas para solucionar os problemas identificados. Durante a implementao e configuraes das ferramentas propostas,

19

foi possvel concluir o quanto importante manter sob controle a administrao de servios e mudanas em um ambiente de TI, de acordo com alguns processos do modelo COBIT. Com a utilizao do Spacewalk e do conceito de Deltarpm, pode-se perceber os benefcios que estas ferramentas podem trazer para o ambiente de TI, tais como diminuio de at 70% de download de pacotes de atualizaes, controle de servidores que possuem softwares em homologao, padronizao de configuraes e uma viso geral de todos os servidores que possuem atualizaes pendentes. Utilizando o Puppet em um ambiente de servidores totalmente heterogneo, ou seja, com diversas distribuies Linux diferentes, foi possvel controlar e padronizar as configuraes dos servidores, facilitando tambm o deploy automtico de configuraes para todos os servidores caso fosse necessrio qualquer alterao em algum arquivo de configurao ou servio. Com a implementao e configurao do Subversion, foi possvel registrar todas as alteraes realizadas em arquivos de configurao ou demais mudanas em pacotes de softwares, tudo de acordo com o processo do modelo COBIT. Algumas limitaes foram identificadas durante o artigo. O Puppet uma ferramenta muito poderosa por ser baseada em linguagem de programao, mas ainda precisa de uma interface grfica para realizar as configuraes de maneira mais simples e funcional. O Puppet possui uma interface grfica, chamada de Dashboard, mas que no permite realizar configuraes, apenas consultar detalhes dos sistemas registrados e erros encontrados. importante citar algumas sugestes para trabalhos futuros, ente elas a integrao de todas as ferramentas citadas no trabalho, deixando o Spacewalk apenas como ferramenta de inventrio de servidores, o Puppet como ferramenta de deploy de configuraes e o Subversion para controlar todas as mudanas, tanto no Puppet como no Spacewalk.

REFERNCIAS
DELTARPM. Disponvel em: <http://freshmeat.net/projects/deltarpm/> Acesso em: 03 nov. 2010. IBM. Disponvel em: <http://www.ibm.com/developerworks/linux/library/l-rpm1/index.html> Acesso em: 02 nov. 2010. ICASA. Disponvel em: <http://www.isaca.org/Knowledge-Center/cobit/Pages/Overview.aspx.> Acesso em: 30 out. 2010. INFORMATION Technology Infrastructure Library. Disponvel em: <http://pt.wikipedia.org/wiki/Information_Technology_Infrastructure_Library>. Acesso em: 30 out. 2010. IT GOVERNANCE INSTITUTE. It Governance Roundtable: it Governance Trends. Disponvel em: <http://www.itgi.org/AMTemplateebff.pdf?Section=ITGI_Research_Publications&Template=/ContentMana gement/ContentDisplay.cfm&ContentID=40353> Acesso em: 30 out. 2010. NEMETH, Evi; SNYDER, Garth; HEIN, Trent. Manual Completo do Linux, Guia do Administrador. So Paulo: Pearson Makron Books, 2004. 669 p. SUSSMAN, Ben; FITZPATRICK, Brian; PILATO, Michael. Version Control with Subversion. Califrnia, EUA: O'Reilly, 2004. 383 p. TURNBULL, James. Pulling Strings with Puppet. New York, EUA: Apress, 2007. 169 p.

20

Você também pode gostar