Você está na página 1de 20

ADMINISTRAÇÃO E CONTROLE DE MUDANÇAS DE

SERVIÇOS DE INFRAESTRUTURA DE TI EM DATA


CENTERS COM FERRAMENTAS OPEN SOURCE 1
Rodrigo de Lima Silva <rodrigodlima@gmail.com>
<rodrigodlima@gmail.com>
Alexandre Timm Vieira <xanditv@gmail.com
< xanditv@gmail.com>
> - Orientador

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

29 de novembro de 2010

RESUMO
Este trabalho apresenta as ferramentas
ferramentas e métodos necessários para manter, controlar e administrar os serviços
serviços de
infraestrutura de TI em uma empresa que possui diversos serviços críticos em um data center. Após análise e identificação dos
problemas no cenário atual, são apresentadas as soluções necessárias e implementação das ferramentas para garantir o controle e
administração com qualidade dos serviços de TI. Após a implementação das ferramentas são apresentados os resultados obtidos
Palavras-chave: Controle de Mudanças; Open Source; Administração de Serviços de TI.

 A BSTRACT 
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.

1 INTRODUÇÃO
Com a necessidade cada vez maior de agilizar e manter um ambiente de infraestrutura de TI
controlado, várias ferramentas, métodos e processos foram criados com o intuito de possibilitar a excelência
na manutenção e entrega dos serviços de TI da organização.
A pouco tempo atrás dizia-se que a área de TI da organização precisaria estar alinhada ao negócio,
porém hoje em dia a TI já faz parte do negócio, ou seja, são duas áreas que devem estar “integradas”.
Pensando nisso, é necessário que a área de TI esteja preparada para suportar e garantir, em tempo hábil, a
entrega de serviços de TI necessárias para o negócio da empresa.
Durante o desenvolvimento do trabalho, serão apontados os problemas de manter um ambiente de TI
sem controle e será demonstrado as ferramentas que serão utilizadas para resolver estes problemas
identificados.
Com a necessidade imediata de instalação, configuração e manutenção de servidores torna-se cada
vez mais necessário amadurecer os processos de Gerenciamento de Configuração e Gerenciamento de
Mudanças. Como base nesse cenário, dois processos do modelo COBIT (Control Objectives for Information

1
Artigo elaborado como Trabalho de Conclusão de Curso de Tecnologia em Redes de Computadores da
Universidade Luterana do Brasil, Campus Canoas.

1
and Related Technology), que é um framework de Governança de TI, serão utilizados como apoio para
realizar este controle.
Na seção 2 será descrito a fundamentação teórica das tecnologias e métodos utilizados para realizar a
administração, controle e agilidade do ambiente de Infraestrutura de TI em datacenters. O cenário atual e a
análise dos problemas serão descritos na seção 3. Na seção 4 será apresentado o projeto, onde serão
implementadas as soluções para resolver os problemas enfrentados no cenário atual e ao final, na seção 5,
será descrito a conclusão do artigo.

2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo destina-se à apresentação das principais ferramentas e metodologias necessárias para o
agilizar e administrar um ambiente de TI em um cenário com centenas de servidores e milhares de serviços.
Inicia-se com a definição e explicação de cada software, detalhando seu funcionamento e qual a necessidade
de utilização, realizando comparações com outros softwares disponíveis e citando qual a vantagem de
utilização do software escolhido.
2.1 Ferramentas de mercado para Gerenciamento de Configuração
Existem atualmente no mercado diversos softwares, tanto open source como comerciais, para
facilitar a administração e controle de todo ambiente de servidores. Dentre os softwares comerciais podemos
citar o Red Hat Network Satellite, um produto da empresa líder 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 também pertence a empresa Red Hat, porém é a versão open source do produto
comercial Satellite. Tanto o Spacewal como o Puppet são softwares open source e não é necessário
licenciamento. Estas 4 ferramentas podem ser utilizadas para implantar de forma dinâmica um ambiente
controlado e ágil de servidores em um data center, mas cada uma possui suas vantagens e desvantagens,
então a decisão tem que ser tomada levando em conta vários fatores, tais como custo de licenciamento,
suporte, funcionalidades e principalmente saber qual a ferramenta é a melhor para atender o tipo de negócio
e ambiente de TI da empresa.
2.1.1 Puppet
O Puppet é um framework open source de gerenciamento de sistemas e configurações baseados na
linguagem de programação 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 flexível.
Com o Puppet é possível automatizar todo o processo de configuração de um servidor e reproduzir
esta configuração para quantos servidores foram necessários ao mesmo tempo, diminuindo
consideravelmente o tempo de entrega e configuração dos serviços e também é possível ter a gestão diária da
rede e a manter sob controle, concentrando todos os esforços das equipes de TI nos problemas reais e novos
projetos.
O Puppet funciona de maneira modular, ou seja, é possível adicionar ou remover vários recursos sem
a necessidade de reinstalação do software. Os módulos podem automatizar tarefas tais como a criação 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 geração de
relatórios. O Dashboard facilita o gerenciamento e configuração de tarefas, fornece a visualização rápida das
informações importantes e gera relatórios sobre o sistema.
Dando continuidade aos recursos, citar o Facter, que é uma biblioteca da linguagem de programação
Ruby e é destinada a reunir informações dos sistemas para a tomada de decisão do Puppet, além de reunir
informações sobre o sistema operacional, tais como versão do kernel, número de interfaces de rede entre
outras. Este é um dos recursos mais interessantes e uma das vantagens em relação aos outros softwares de

2
mercado, pois como ele consegue identificar a versão do sistema operacional, ele executa os comandos de
acordo com a distribuição Linux. Por exemplo, ao criar um recurso no Puppet para instalação do software
Postfix, ele executa a instalação de acordo com o gerenciador de pacote da distribuição, se for uma
distribuição baseada em RPM, o pacote é instalado com o yum, se for distribuição baseada em Debian, o
pacote é instalado com o apt.
2.1.2 Spacewalk
Spacewalk é uma solução para gerenciamento de sistemas Linux que permite realizar inventário de
informações sobre hardware e software, instalar e realizar atualização de sistemas, customizar pacotes,
provisionar, gerenciar e distribuir arquivos de configuração e monitorar sistemas.
Como característica, podemos destacar a fácil instalação e administração. O Spacewalk é baseado no
Red Hat Network Satellite, diferenciando-se por ser open source e permitir a integração com outras
distribuições Linux (seção 2.5) além da Red Hat, tais como CentOS, Fedora e SuSe.
Através de uma interface Web de administração, é possível realizar todas as operações de
configurações e ter uma idéia de quantidade de servidores registrados e quantos destes servidores estão
devidamente atualizados com os últimos patches de segurança. A idéia principal é trabalhar com o conceito
de chaves.
O administrador de sistemas, ao registrar um servidor no Spacewalk, deve escolher uma chave de
ativação, essa chave é definida pelo administrador no Spacewalk. Definindo a chave de ativação o servidor é
registrado em um canal (grupo) de atualizações.
Outro recurso importante é que pode-se definir através de chaves e canais quais softwares serão
instalados utilizando determinada chave, pode-se também criar alguns arquivos de configurações
personalizados e com isso criar um padrão de instalação de servidores.
2.2 Ferramentas de mercado para Gerenciamento de Mudanças
Para manter o controle de mudanças e configurações é importante utilizar ferramentas que possam
realizar este controle, mantendo um histórico de mudanças e controle de versões de softwares. Abaixo alguns
conceitos e definições das ferramentas utilizadas atualmente.
2.2.1 Subversion
O Subversion é uma ferramenta open source para controle de versões de softwares. Ele é utilizado
normalmente para se ter um histórico de mudanças no código fonte. Na grande maioria dos casos o
Subversion é utilizado para auxiliar os desenvolvedores de sistemas, pois ele permite que vários
desenvolvedores alterem o mesmo arquivo fonte e depois que realizarem a mudança podem submeter para o
repositório central. A cada modificação que é submetida ao repositório, a versão do arquivo é incrementada.
Logo, se algum problema ocorrer no software após a mudança, basta fazer o rollback da versão anterior onde
o erro não ocorria.
Como este controle de versão é muito útil, ele é utilizado por muitos administradores de sistemas
para controlar as versões dos arquivos de configurações dos servidores, para que seja possível ter um
histórico de mudança e também para fazer um rollback da configuração anterior.
Existem alguns clientes Subversion para realizar estas operações, o mais conhecido atualmente no
mercado é o TortoiseSVN, que funciona em sistemas operacionais Microsoft Windows e através 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 Mudanças,
que são dois processos do modelo COBIT.

3
Como características podemos citar uma interface web para realização do gerenciamento de
mudanças, fácil integração com outras ferramentas da Computer Associates, possui arquitetura multi
plataforma, administração centralizada entre outras.

2.3 Modelos de boas práticas de TI


Atualmente é muito importante para qualquer empresa utilizar boas práticas para manter um
ambiente de TI organizado e para manter o tempo de indisponibilidade do serviço de TI o mais baixo
  possível. O modelo de boas práticas mais utilizadas no mercado atualmente são o ITIL ( Information
 Information
Technology Infrastructure Library) e o COBIT (Control
( Control Objectives for Information and related Technology).
Technology).
“O COBIT é um framework de governança de TI e ferramentas de suporte que permite a gestores avaliar as
exigências de controle, questões técnicas e riscos financeiros” (ICASA, 2010).
O CobiT define as atividades de TI em um modelo de processos genéricos com quatro domínios.
Esses domínios são Planejar e Organizar, Adquirir e Implementar, Entregar e Suportar e Monitorar e Avaliar.
Esses domínios mapeiam as tradicionais áreas de responsabilidade de TI de planejamento, construção,
processamento e monitoramento (IT GOVERNANCE INSTITUTE, 2007). Dentro destes 4 domínios
existem 34 processos, onde as organizações normalmente acabam não utilizando todos estes processos.
Destes 34 processos, podemos destacar dois que são bastante utilizados na área de infraestrutura de TI, que
são o DS9 – Gerenciar a Configuração e AI6 – Gerenciar as Mudanças.
Para ser eficaz, o Gerenciamento de Configuração deve estabelecer um repositório central de todos
os itens de configuração, identificação e manutenção dos itens de configuração e revisão da integridade dos
dados de configuração (IT GOVERNANCE INSTITUTE, 2007).
Todas as mudanças, incluindo manutenções e correções de emergência, relacionadas com a
infraestrutura e as aplicações no ambiente de produção são formalmente gerenciadas de maneira controlada.
As mudanças (incluindo procedimentos, processos, parâmetros de sistemas e de serviço) devem ser
registradas, avaliadas e autorizadas antes da implementação e revisadas em seguida, tendo como base os
resultados efetivos e planejados. Isso assegura a mitigação de riscos de impactos negativos na estabilidade ou
na integridade do ambiente de produção (IT GOVERNANCE INSTITUTE, 2007).
2.4 Distribuições Linux
O Linux pode ser definido como Kernel, ou seja, o núcleo do sistema operacional. “O Linux se
originou em 1991 como um projeto pessoal de Linus Torvalds, um universitário finlandês” (NEMETH,
SNYDER e HEIN, 2004, p.4). Os softwares, comandos e daemons juntamente com o Kernel (núcleo)
formam o sistema operacional. As diferentes formas de montagem do sistema operacional Linux é que
formam as distribuições.
“As distribuições variam em termos de foco, suporte e popularidade” (NEMETH, SNYDER e HEIN,
2004 p.5). Como o Linux está licenciada sobre a licença GPL ( General Public Licence), as pessoas estão
livres para modificar e distribuir, por isso existem tantas distribuições atualmente no mercado.
2.4.1 RPM
As principais e mais perceptíveis diferenças entre elas está na forma como são feitas as atualizações
e instalação de softwares. Algumas distribuições utilizam o RPM (  Red Hat Package Manager) como
gerenciador de pacotes e outras utilizam o DPKG (  Debian Package). Devido a estas diferenças, não é
possível instalar um software baseado em DPKG em uma distribuição baseada em RPM e vice-versa.
Existem também alguns front-ends para estes gerenciadores de pacotes para facilitar ainda mais a instalação
de pacotes. Ao instalar algum pacote com o RPM ou DPKG, é realizado uma checagem de dependências,
onde se valida se o software que está sendo instalado depende de algum outro pacote, caso o pacote tenha
dependência, o RPM ou o DPKG não conclui a instalação e emite um erro informando quais as dependências
que estão faltando. O YUM ( Yellow dog Updater, Modified ) e o APT ( Advanced Packaging Tool) são front-
ends para estes dois gerenciadores de pacotes e resolvem o problema de pend ẽncias. O YUM é utilizado em

4
distribuições baseadas em Red Hat, tais como Fedora, CentOS, SuSe e o APT é utilizado em distribuições
baseadas de Debian. Tanto o YUM como o APT, antes de instalar um pacote, verificam suas dependências e
realizar o download dos pacotes necessários para instalação e com isso facilita todo o processo de instalação
de softwares.
Geralmente, quando se trabalha com administração de servidores, é interessante automatizar todo o
processo de instalação de pacotes e muitas vezes esta tarefa se torna complicada, uma vez que existem
softwares que não estão empacotados no formato RPM ou DPKG, eles simplesmente são softwares
compactados que disponibilizam somente o código fonte e é necessário realizar o processo de compilação e
instalação manual, através do processo make e ./configure.
2.4.2 Rpmbuild
Uma maneira que é utilizada para automatizar e simplificar este processo é através de
empacotamento do código fonte em pacote RPM. O utilitário rpmbuild é utilizado para isso. O rpmbuild
realiza o processo de compilação do software e disponibiliza os binários e demais arquivos em um arquivo
RPM. Desta forma, os administradores podem disponibilizar de maneira automática vários softwares que não
estão nos repositórios principais das distribuições e também permite que se faça pacotes personalizados, de
acordo com a necessidade.
Todo pacote RPM possui um arquivo de configuração, chamado de “spec file”, que é a entrada para
o utilitário rpmbuild (IBM, 2010). Dentro do arquivo spec é que ficam as informações sobre como o pacote
deve ser instalado, qual o caminho dos arquivos e binários e principalemnte onde ficam as informações sobre
o autor do software, descrição e principalmente o changelog, ou seja, o log de todas as modificações já
realizadas no pacote. É com base neste arquivo que o comando rpm busca as informações quando solicitadas,
conforme Figura 1.

Figura 1 – Verificando as informações do pacote RPM

2.4.3 DeltaRPM
DeltaRPM é uma ferramenta que gera pacotes RPM's e que contém a diferença entre o pacote
instalado e a nova versão do pacote. Com isso, é possível recriar um novo RPM a partir das diferenças, o que
acaba diminuindo consideravelmente o seu tamanho. (DELTARPM, 2010).

3 PROJETO /MODELAGEM
Este capítulo destina-se à apresentação do cenário atual, análise dos problemas e soluções propostas
para resolver os problemas identificados.

5
3.1 Cenário atual
A empresa onde será implantado as mudanças sugeridas no trabalho atua no mercado financeiro,
tendo uma estrutura de tecnologia da informação centralizada em um data center principal e secundário em
Porto Alegre e atualmente possui 1.400 (mil e quatrocentos) unidades de atendimento espalhadas por vários
estados brasileiros, entre eles São 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, distribuição
(seção 2.5) CentOS, onde rodam diversos serviços locais e alguns serviços são executados no data center
principal. Todos os servidores das Unidades de Atendimento possuem a mesma configuração e são
padronizados, mudando apenas endereçamento de rede IP e hostname, Além dos 1.400 (mil e quatrocentos)
servidores espalhados pelo país, há ainda algumas centenas de servidores no data center principal e
praticamente a mesma quantidade de servidores replicados para o data center secundário que servem de
contingência caso aconteça alguma falha no data center primário.
3.1.1 Links para comunicação com a rede WAN
A comunicação entre o data center e os servidores das unidades de atendimento se dão através de links
MPLS (Multiprotocol Label Switching) e link satelital. O link MPLS é o link primário e o link satelital
funciona como contingência, caso o link MPLS fique indisponível. Existem algumas unidades de
atendimento que só possuem link satelital, por estarem em alguma região ao qual a Operadora de
Telecomunicações não consegue chegar com suas fibras ópticas. Toda a estrutura localizada nas unidades de
atendimento, para fins de localização, é chamada de rede WAN. Já a rede LAN fica localizada em Porto
Alegre, no mesmo prédio onde está localizado o data center. Neste prédio é onde fica localizado o centro
administrativo, que é responsável por prestar todo o suporte tecnológico e administrativo para as unidades de
atendimento. Neste local também que fica a área de Infraestrutura de TI da empresa, responsável por manter
e administrar toda a área de TI.
3.1.2 Infraestrutura de servidores localizados na rede WAN
Os serviços de infraestrutura que rodam atualmente nos servidores das Unidades de Atendimento são
basicamente os seguintes:
• E-mails
• Internet
• Compartilhamento
Compartilhamento de arquivos
• DNS
• Banco de dados
• Demais aplicações de negócio
Como as mudanças nas versões das aplicações é muito constante, é necessário enviar toda mudança
para todos os servidores ao mesmo tempo, e isto leva muito tempo caso não tenha algum processo
automatizado para realizar estas tarefas.
No cenário 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 repositório de softwares, que fica em um
servidor web Apache, e verifica se há alguma atualização de pacote RPM (Seção 2.5) a ser realizado,e se
tiver, realiza o download e instalação do pacote. O agendamento para rodar o script de atualização é
realizado através da cron, que é uma espécie de agendador de tarefas dos sistemas Microsoft Windows.
Existe um servidor no data center que é onde são realizados as mudanças nos pacotes RPM que são
enviados para os servidores das unidades de atendimento. É neste servidor que são realizadas as mudanças e
atualizações nos aplicativos que são enviados para os servidores. Atualmente, não há um controle de
mudanças eficaz nestes aplicativos, os pacotes são apenas modificados e incrementado a release, ou seja, se
um pacote estava na versão 1.1.1, após alteração e modificação do pacote a versão é incrementada, ficando
1.1.2. O controle das mudanças é feito através do changelog do pacote, conforme explicado na seção 2.5.

6
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 distribuições (seção 2.5), ou seja, um ambiente de TI bastante heterogêneo, com maneiras de
administração diferentes, dependendo do servidor. Existem servidores de aplicação TomCat, Jboss e Oracle
rodando em diferentes distribuições e sem nenhum tipo de gerenciamento ou controle. Os serviços
administrados nos ambientes de produção e que utilizam o sistema operacional Linux como base são dos
mais variados tipos, tais como bancos de dados, servidores web, servidores de compartilhamento de
arquivos, ente outros. Mas a grande maioria são servidores de aplicação Java, tais como TomCat, Jboss e
Oracle.
3.2 Análise e restrições identificadas
Este capítulo destina-se a apresentar os problemas identificados no cenário atual, tanto na estrutura de
rede WAN como na LAN e propor as soluções necessárias para resolver os problemas identificados.
3.2.1 Problemas identificados na infraestrutura de serviços da rede WAN
Analisando o cenário 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 não permite exceções. Por não permitir exceções, acaba dificultando algumas
configurações que são necessárias em servidores diferentes. Por exemplo, quando é necessário enviar alguma
aplicação para alguns servidores para se realizar um piloto ou homologação, não é possível colocar esta
aplicação no repositório de updates, pois todos os servidores baixarão e instalarão esta aplicação.
Uma forma de contornar a situação é enviar via script esta aplicação para uma lista de servidores que
devem entrar no piloto. Porém, este modelo não possui um controle eficaz de quais servidores realmente
estão em piloto e os que não estão. Outro problema identificado é que como a aplicação é enviada via link de
comunicação MPLS, caso algum servidor esteja desligado ou a comunicação esteja indisponível, o envio
do(s) arquivo(s) falhará. Devido a este problema, é necessário rodar outro script para realizar a conexão nos
servidores para saber se o servidor recebeu ou não o(s) arquivos(s) corretamente.
Seguindo a identificação dos problemas, percebe-se que seguidamente os técnicos de campo
precisam se deslocar até as unidades de atendimento para realizar a reinstalação do sistema operacional
devido a problemas de hardware, tais como erros físicos no hard disk ou queima da placa mãe por exemplo.
Os técnicos possuem uma mídia de instalação desatualizada em um cd-rom e com isso a cada nova instalação
é necessário realizar a atualização dos pacotes que estão no repositório de atualizações, essa atualização
possue em média 1Gb de arquivos. Essa atualização demora em torno de 1 dia até ser concluída e acaba
sendo um transtorno para os colaboradores e associados da unidade de atendimento, pois os serviços ficam
comprometidos durante quase dois dias úteis.
Como a quantidade de servidores na WAN é muito elevada, é inviável manter o controle sem uma
ferramenta que permita realizar essa tarefa. Com o passar do tempo, vários servidores ficam com
configurações diferentes e outros desatualizados, isto acaba gerando grande quantidade de chamados na
Central de Atendimento.
3.2.2 Problemas identificados na infraestrutura de serviços no data Center
Analisando o cenário dos servidores localizados no data center, corfome descrito na seção 3.1,
percebe-se que não foi definido um padrão de distribuição Linux (seção 2.5) para utilizar nos servidores,
sendo assim o ambiente de TI acabou ficando muito heterogêneo, com diversas distribuições e maneiras de
administração diferentes. Existem vários servidores de aplicação TomCat, Jboss e Oracle rodando em
diferentes distribuições e sem nenhum tipo de gerenciamento e controle centralizado. Não há também um
processo rápido para disponibilizar um servidor de aplicação para a produção, ou seja, quando surge alguma
demanda para um novo servidor, o processo de instalação e configuração do sistema operacional e demais
aplicações gira em torno de 2 dias úteis, e isso acaba sendo um gargalo na entrega de novos projetos
necessários para o negócio.

7
Além disso, como não existem ferramentas para o controle, servidores com a mesma aplicação estão
com configurações diferentes, o que acaba gerando problemas diferentes. Além disso, é praticamente
inviável enviar alguma configuração personalizada para todos os servidores. Por exemplo, caso seja
necessário alguma alteração na infraestrutura de servidores DNS, é necessário alterar o arquivo
/etc/resolv.conf de todos os servidores, alterando o endereço IP de acordo com os novos servidores DNS.
Como não há um processo automatizado, é enviado um e-mail para todas as equipes informando que o
endereço IP dos servidores DNS foram trocados e é necessário realizar as modificações em todos os
servidores da equipe responsável manualmente.
Outro problema identificado no cenário anteriormente descrito é que não possui um local definindo
onde informa qual equipe é responsável por determinado servidor, ou seja, quando ocorre um problema em
um determinado servidor, ficava complicado de definir ou saber se aquele serviço é da equipe de
infraestrutura, desenvolvimento ou aplicação.
3.3 Soluções propostas
Este capítulo destina-se a apresentar as soluções propostas para resolução dos problemas com base
nos problemas identificados no capítulo anterior.
3.3.1 Infraestrutura de serviços da rede WAN
Foi proposto a utilização do software Spacewalk descrito na seção 2.2.2 para gerenciamento dos
servidores localizados na rede WAN. Através desta ferramenta, será possível identificar facilmente todos os
servidores que estão com softwares desatualizados.
Como citado na identificação dos problemas, há um grande problema quando é necessário realizar
homologação de softwares em determinados servidores. Com a utilização do Spacewalk será possível criar
canais de softwares onde ficarão os softwares que serão homologados. Após será possível registrar os
servidores desejados neste canal de homologação, com isto haverá um controle de quais servidores estão em
homologação e quais servidores estão ou não atualizados.
Com a utilização do spacewalk será possível diminuir o tempo de indisponibilidade e atualização dos
servidores da rede WAN, facilitando o download de atualizações, já que será possível trabalhar com o
conceito de DeltaRPM, citado na seção 2.5.3, ou seja, quando há uma atualização em algum software, o
Spacewalk faz o download apenas da diferença entre o pacote instalado e o pacote que sofreu a atualização,
ou seja, o download do pacote será muito menor e levará menos tempo para ser concluído.
Para o controle de mudanças, seguindo o modelo COBIT, será utilizado a ferramenta Subversion.
Através dela, qualquer atualização de software deverá ser comitada antes no repositório, mantendo um
histório eficaz de mudanças. Através deste controle será possível identificar qual arquivo ou quais arquivos
que sofreram modificações e em qual data.
3.3.2 Infraestrutura de serviços do data Center
A ferramenta Puppet e Spacewalk serão utilizadas para o controle de servidores e serviços
localizados no data center. Como o ambiente é heterogêneo, não teria como utilizar somente o Spacewalk,
pois ele trabalha com o conceito de pacotes RPM e teria problemas em execução 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
informação ele irá executar o comando de acordo com a distribuição, não precisando ser feito um script para
cada distribuição.
Seguindo nesssa linha, com o deploy de arquivos utilizando o Puppet, será possível resolver
problemas do tipo identificado anteriormente, com relação a mudança 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 serviços.

8
4 IMPLEMENTAÇÃO / R
 / RESULTADOS
Este capítulo destina-se a apresentar os detalhes relevantes para implementar os softwares necessários
para as soluções propostas no capítulo anterior para que os problemas identificados no cenário atual sejam
sanados. Será demonstrado também os resultados obtidos após a implementação para atingir os objetivos
propostos, que são:
• Deploy automatizado de configurações.
• Controle e histórico de mudanças.
• Diminuição do tempo de entrega de serviços.
• Monitoramento
Monitoramento dos serviços.
4.1 Puppet
Este capítulo abordará os requisitos, conceitos e configurações relevantes para a instalação e
implementação da ferramenta Puppet e apresentará os resultados obtidos após a implementação.
4.1.1 Requisitos
Um dos requisitos para instalação 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 versão estável do
Puppet é a 2.6.2, esta versão está disponível no site do fabricante. É esta a versão utilizada no decorrer do
artigo. A distribuição Linux que será usada para instalação será a CentOS versão 5.3. Como não há os
pacotes do puppet no repositório principal da distribuição, será compilado e instalado àpartir do código fonte.
A instalação é simples, mas existem alguns pré-requisitos para a instalação. É necessário realizar a
instalação do interpretador Ruby e suas bibliotecas. Na distribuição CentOS, é possível realizar a instação
àpartir do repositório oficial através do comando yum.
O Puppet não 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 número de clientes e
configurações. 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 sessões são encriptadas e são autenticadas com
certificados assinados. Cada nodo gera um certificado assinado e então esse certificado é validado e
autorizado pelo Puppet Master (TURNBULL, 2007).
Depois disso cada cliente contata o servidor, por padrão a cada trinta minutos através de um agente,
para confirmar que sua configuração está atualizada. Se uma nova configuração estiver disponível ou a
configuração foi alterada, ela é recompilada e então aplicada no cliente. Uma observação importante é que se
o cliente não tiver o certificado assinado ele não conseguirá contactar o servidor master, gerando um erro
conforme Figura 2.
Figura 2 – Log informando erro de certificado

9
Se for necessário enviar uma atualização com alguma configuração, pode ser realizada forçadamente
através do servidor, forçando a configuração no cliente. Se alguma configuração existente no cliente estiver
diferente, ela é corrigida de acordo com a original a partir do servidor. Os resultados de qualquer alteração
são registrados e transmitidos para o servidor.
4.1.3 Configurações
Primeiramente foram criados alguns diretórios para fins de organização, ou seja, não é necessário
seguir esse modelo, todos os arquivos de definições podem ser colocados abaixo de /etc/puppet/manifests
diretamente. A estrutura de diretórios ficou conforme Figura 3.

Figura 3 – Estrutura de diretórios localizados em /etc/puppet


Dentro do diretório classes, conforme Figura 4, ficam as definições de classes necessárias, de acordo
com a necessidade. No cenário proposto, o arquivo baseapps.pp possui alguns pacotes básicos que devem
estar instalados em alguns servidores. O conteúdo do arquivo é listado na Figura 4.

Figura 4 - Conteúdo 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 estão instalados, caso não estejam, esses pacotes serão instalados.
Conforme Figura 5, no diretório nodes ficam as definições dos nodos, também conhecido como
clientes. O conteúdo do arquivo nodes.pp pode ser verificado na Figura 6.

10
Figura 5 – Definição 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 conteúdo conforme Figura 6.

Figura 6 – Definições de templates

Conforme ilustrado na Figura 7, percebe-se a utilidade de utilizar a funcionalidade Facter, citada no


início do capítulo. Ou seja, de acordo com o sistema operacional, é possível definir uma classe com
configurações personalizadas. Todos os nodos que forem cadastrados e que utilizem a classe basenode
automaticamente incluirão as classes baseapps, ntp e resolv. Com essa configuração foi possível criar um
padrão para cada distribuição. A Figura 7 demonstra as definições das classes fedora, debian e centos.

11
Figura 7 – Definições 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 distribuições Linux para informar quais os servidores DNS
serão 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 serviço ntp muda dependendo da distribuição.

Figura 8 – Exemplo de utilização de templates

Para verificação e análise dos logs dos clientes que estão 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 implementação e configuração do Puppet foi possível resolver os problemas identificados na
seção 3.2.2, pois foram criados algumas definições de distribuições Linux, pacotes que devem ser instalados
por padrão nas distribuições e templates de arquivos de configurações.
Nos testes realizados na implementação foi definido um template para o arquivo /etc/resolv.conf para
padronizar a consulta DNS dos servidores. Caso seja necessário qualquer alteração de endereçamento IP dos
servidores DNS, basta alterar o template no Puppet e essa configuração será replicada para todos os
servidores de forma automática.
Também 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 atualização de horário do
sistema operacional. Dependendo da distribuição Linux, a forma de iniciar e parar o serviço ntp muda um
pouco. Por exemplo, em distribuições Debian, o daemon do NTP é ntp, já na distribuição CentOS é ntpd.
Com a utilização da funcionalidade Facter do Puppet, foi possível tratar esta peculiaridade, pois o Puppet
consegue identificar qual o Sistema Operacional e iniciar o serviço corretamente.
4.2 Spacewalk
Este capítulo abordará os requisitos, conceitos e configurações relevantes para a instalação e
implementação da ferramenta Spacewalk.
4.2.1 Requisitos
É recomendável que o Spacewalk seja instalado em uma das três distribuições mais utilizadas
atualmente no mercado corporativo, que são: Red Hat, Fedora e CentOS.
É recomendável também um hardwware robusto, pois o Spacewalk trabalha com banco de dados,
podendo ser Oracle ou Postgresql. O espaço em disco para armazenar os pacotes de instalação depende de
quais canais de distribuições serão utilizadas, mas recomenda-se pelo menos 6GB por cada canal de
software. Com relação a memória, o mínimo é 2GB e o recomendado é 4GB ou mais.

4.2.2 Funcionamento
O Spacewalk trabalha com o conceito de canais e chaves. Os canais são os repositórios de softwares.
Por exemplo, existe um canal chamado CentOS5.3 e outro chamado de Fedora13, dentro do canal CentOS5.3
existem diversos softwares específicos para esta distribuição e o mesmo ocorre com o canal Fedora13.
Quando um cliente faz o registro, ele utiliza uma chave, esta chave contém a informação de qual canal
de software aquele servidor será registrado e a partir daí o cliente baixa as atualizações disponíveis daquele
canal. Uma observação importante é que não é necessário realizar a instalação de nenhum agente nos
clientes.
4.2.3 Configurações
Foi criada uma chave de ativação 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 ativação é gerada automaticamente pelo Spacewalk.
Para que o servidor cliente faça o registro no Spacewalk, basta ele executar o comando abaixo,
informando a chave de ativação conforme ilustrado na Figura 10:
[root@servidor rhn]# rhnreg_ks --activationkey 1-3bfa903c75500420694ce96579583827 --serverUrl
https://app1web1p.example.com/XMLRPC

14
Figura 10 – Chaves de ativação no Spacewalk
Após a ativação do cliente, já é possível visualizar as informações no Spacewalk referente ao
sistema, tais como updates, erratas, etc, conforme ilustrada na Figura 11.

Figura 11 – Informações de servidores registrados no Spacewalk


Foi criado também um canal de configuração chamado “homologacao”. Este canal tem o objetivo de
disponibilizar os pacotes que serão usados para testes. Esta configuração permite que se tenha controle de
todos os servidores que estão em homologação. Dentro deste canal é possível colocar todos os pacotes
desejados para homologação e os servidores que estiverem cadastrados neste canal farão o download e
instalação do pacote automaticamente. Conforme pode ser visto na Figura 12, dentro do canal de
configuração “homologação”, são listados todos os sistemas que estão registrados, facilitando o controle.

15
Figura 12 – Lista de servidores registrados no canal de homologação

Na aba Packages pode ser visualizado os pacotes que fazem parte deste canal, conforme Figura 13.

Figura 13 – Lista de pacotes no canal de homologação


Conforme ilustrado na Figura 13, o pacote oracle-xe-univ está incluso no canal de homologação, 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 utilização de pacotes Deltarpm, conforme
explicado na seção 2.5.3. O objetivo de trabalhar com pacotes Detarpm é diminuir o tamanho do pacote
RPM e com isso diminuir também o tempo de download de atualizações.
Conforme Figura 14, foi criado um pacote hello-2.6.4.noarch.rpm que contém 3 arquivos: Samba3-
HOWTO.pdf, hello e hello.1.gz. Este arquivo possui o tamanho de 3.2Mb. Após foi criado um novo pacote,
onde foi adicionado um novo arquivo chamado BIND.pdf. Após foi criado o pacote deltarpm, com a
diferença entre a versão 2.6.4 e 2.6.5 do pacote. Conforme ilustrado na Figura 15, o pacote hello-
2.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 diferença entre a versão 2.6.4 e
2.6.5, ou seja, apenas o tamanho do arquivo BIND.pdf.

16
Figura 14 – Diferença de tamanho dos pacotes utilizando Deltarpm
4.2.5 Resultados
Conforme ilustrado nas figuras acima, nos testes realizados com a configuração e implementação do
Spacewalk, foi possível resolver os problemas identificados na seção 3.2.1. Foi criado uma chave de ativação
para os servidores localizados na rede WAN e um canal de homologação com o intuito de disponibilizar
neste canal os softwares que deveriam ser homologados. Com essa configuração, foi possível identificar
quais os servidores que estavam registrados no canal de homologação e também quais os servidores que
estavam devidamente registrados no Spacewalk e devidamente atualizados.
Com a utilização dos pacotes Deltarpm durante os testes, foi perceptível os resultados obtidos com
relação ao tamanho dos pacotes. Os resultados mostraram que com a utilização dos pacotes Deltarpm pode-
se diminuir o tamanho do pacote em torno de 70%. Com essa utilzação, foi possível resolver o problema
citado na seção 3.2.1, onde era necessário grande quantidade de tempo e de link de comunicação a cada nova
instalação de servidores.
4.3 Subversion
Este capítulo abordará os requisitos, conceitos e configurações relevantes para a instalação e
implementação da ferramenta Subversion.

4.3.1 Requisitos
Não há requisitos para a instalação 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. Não é necessário também de um hardware robusto.
4.3.2 Funcionamento
O Subversion é um sistema centralizado de compartilhamento de informações (SUSSMAN,
FITZPATRICK e PILATO, 2004). Este sistema centralizado é chamado também de repositório. O
respositório armazena as informações no formato de árvore, tipicamente na hierarquia de arquivos e
diretórios. O funcionamento é simples, o cliente baixa os arquivos armazenados no repositório para sua
máquina local e realiza as modificações que achar necessário. Após realizar as modificações, o cliente pode
enviar as modificações para o repositório principal, com isso os demais clientes podem consultar as
alterações que foram realizadas em um determinado arquivo. Ou seja, nenhuma modificação é feita no
repositório central, somente nos clientes.

17
4.3.3 Configurações
O Subversion será utilizado para controle de mudanças e configurações, de acordo com o modelo
COBIT, para realizar as mudanças nos pacotes que serão distribuídos para homologação dos servidores
localizados na rede WAN. Esse controle é necessário, pois assim será possível enviar correções e
atualizações de softwares que estão em homologação facilmente.
Foi criado uma estrutura de diretórios necessários para a compilação e montagem dos pacotes
RPM's. Não é recomendável realizar a compilação de pacotes utilizando o usuário root, então foi criado o
usuário “compiler”. Dentro do diretório home deste usuário foi criado o diretório chamado projetos. Dentro
desta pasta foram criados os diretórios BUILD, RPMS, SPECS e SRPMS. Esta é a estrutura de diretórios
padrão para distribuições que utilizam o gerenciador de pacotes RPM. Será esta a estrutura de diretórios que
será versionada pelo Subversion.
Foi criado então um projeto chamado “Hello” para demonstrar o funcionamento da solução.
Conforme explicado anteriormente foi criado o seguinte diretório /home/compiler/projetos/projeto-hello.
Dentro deste diretório foram criado s os diretórios BUILD,RPMS,SPECS e SRPMS. Foi realizado então a
montagem do pacote RPM utilizando o utilitário rpmbuild, citado na seção 2.5.2. Após a montagem do
pacoter ter sido realizada corretamente, foi importado o diretório projetos para o repositório Subversion com
o comando svn import conforme Figura 15.

Figura 15– Importando o projeto para o repositório


Conforme Figura 16, após a importação do projeto, é possível listar os projetos que estão disponíveis
no repositório.

Figura 16 – Listagem dos projetos do repositório


Após realizar a importação do projeto para o respositório, é recomendável remover o diretório local
criado e realizar o checkout do código através 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 alteração em algum arquivo deverá ser comitado ao repositório Subversion através do
comando “snv ci”. Através deste processo todos os arquivos serão versionados e será possível ter o controle
de todas as mudanças e também será possível verificar o log de mudanças com o comando “svn log”,
conforme Figura 18.

Figura 18 – Comitando alterações no repositório e verificando log de alterações

4.3.4 Resultados
Após a implementação do Subversion, citada acima, foi possível controlar todas as mudanças nos
pacotes RPMS que são modificados e enviados para a produção, garantindo assim o Controle de
Configurações e Mudanças, conforme modelo COBIT.
Com a implementação do Subversion, qualquer alteração em algum arquivo necessariamente necessita
ser enviado/gravado no repositório central. Com isso, qualquer alteração realizada fica devidamente
registrada nos logs para uma possível auditoria para identificação de erros.

5 CONCLUSÃO
Este trabalho demonstrou as ferramentas e métodos necessários para administrar e controlar um
ambiente de serviços de infraestrutura de TI em um data center.
Foi realizado uma análise dos problemas atuais e proposto a implementação de ferramentas para
solucionar os problemas identificados. Durante a implementação e configurações das ferramentas propostas,

19
foi possível concluir o quanto é importante manter sob controle a administração de serviços e mudanças em
um ambiente de TI, de acordo com alguns processos do modelo COBIT.
Com a utilização do Spacewalk e do conceito de Deltarpm, pode-se perceber os benefícios que estas
ferramentas podem trazer para o ambiente de TI, tais como diminuição de até 70% de download de pacotes
de atualizações, controle de servidores que possuem softwares em homologação, padronização de
configurações e uma visão geral de todos os servidores que possuem atualizações pendentes. Utilizando o
Puppet em um ambiente de servidores totalmente heterogêneo, ou seja, com diversas distribuições Linux
diferentes, foi possível controlar e padronizar as configurações dos servidores, facilitando também o deploy
automático de configurações para todos os servidores caso fosse necessário qualquer alteração em algum
arquivo de configuração ou serviço. Com a implementação e configuração do Subversion, foi possível
registrar todas as alterações realizadas em arquivos de configuração ou demais mudanças em pacotes de
softwares, tudo de acordo com o processo do modelo COBIT.
Algumas limitações foram identificadas durante o artigo. O Puppet é uma ferramenta muito poderosa
por ser baseada em linguagem de programação, mas ainda precisa de uma interface gráfica para realizar as
configurações de maneira mais simples e funcional. O Puppet possui uma interface gráfica, chamada de
Dashboard, mas que não permite realizar configurações, apenas consultar detalhes dos sistemas registrados e
erros encontrados.
É importante citar algumas sugestões para trabalhos futuros, ente elas a integração de todas as
ferramentas citadas no trabalho, deixando o Spacewalk apenas como ferramenta de inventário de servidores,
o Puppet como ferramenta de deploy de configurações e o Subversion para controlar todas as mudanças,
tanto no Puppet como no Spacewalk.

REFERÊNCIAS
DELTARPM. Disponível em: <http://freshmeat.net/projects/deltarpm/
<http://freshmeat.net/projects/deltarpm/ > Acesso em: 03 nov. 2010.

IBM. Disponível em: <http://www.ibm.com/developerworks/linux/library/l-rpm1/index.html


<http://www.ibm.com/developerworks/linux/library/l-rpm1/index.html > Acesso em:
02 nov. 2010.

ICASA. Disponível em: <http://www.isaca.org/Knowledge-Center/cobit/Pages/Overview.aspx


<http://www.isaca.org/Knowledge-Center/cobit/Pages/Overview.aspx .> Acesso em:
30 out. 2010.

INFORMATION Technology Infrastructure Library. Disponível em:


<http://pt.wikipedia.org/wiki/Information_Technology_Infrastructure_Library >. Acesso em: 30 out. 2010.

IT GOVERNANCE INSTITUTE. It Governance Roundtable: it Governance Trends. Disponível 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.
São Paulo: Pearson Makron Books, 2004. 669 p.

SUSSMAN, Ben; FITZPATRICK, Brian; PILATO, Michael. Version Control with Subversion. Califórnia,
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