ADMINISTRAÇÃO E CONTROLE DE MUDANÇAS DE SERVIÇOS DE INFRAESTRUTURA DE TI EM DATA CENTERS COM FERRAMENTAS OPEN SOURCE 1

Transcrição

1 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> 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 São José CEP Canoas - RS 29 de novembro de 2010 RESUMO Este trabalho apresenta as ferramentas e métodos necessários para manter, controlar e administrar 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. 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. 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

2 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 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 s 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

3 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 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 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 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

4 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 Technology Infrastructure Library) e o COBIT (Control Objectives for Information and related 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 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 frontends para estes dois gerenciadores de pacotes e resolvem o problema de pendẽncias. O YUM é utilizado em 4

5 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 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 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

6 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 (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 (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 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 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: s Internet 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 O controle das mudanças é feito através do changelog do pacote, conforme explicado na seção

7 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 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 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

8 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 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 Infraestrutura de serviços da rede WAN Foi proposto a utilização do software Spacewalk descrito na seção 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 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

9 4 IMPLEMENTAÇÃO / 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 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 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 Funcionamento Para disponibilizar a conectividade cliente-servidor, o Puppet usa o protoco XML-RPC rodando sobre o protocolo HTTPS na porta 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

10 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 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

11 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

12 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

13 Figura 9 Tela de log do Puppet Dashboard 13

14 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 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 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 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-3bfa903c ce serverurl 14

15 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

16 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 Componente extra Foi configurado e implementado no ambiente de testes a utilização de pacotes Deltarpm, conforme explicado na seção 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 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 e do pacote. Conforme ilustrado na Figura 15, o pacote hello noarch.rpm foi criado contendo 4 arquivos: Samba3-HOWTO.pdf, hello, hello.1.gz e BIND.pdf. O pacote hello noarch.rpm ficou com o tamanho de 408Kb, apenas com a diferença entre a versão e 2.6.5, ou seja, apenas o tamanho do arquivo BIND.pdf. 16

17 4.2.5 Resultados Figura 14 Diferença de tamanho dos pacotes utilizando Deltarpm 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 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 podese 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 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 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

18 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 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

19 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 Resultados Figura 18 Comitando alterações no repositório e verificando log de alterações 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

20 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: < Acesso em: 03 nov IBM. Disponível em: < Acesso em: 02 nov ICASA. Disponível em: < Acesso em: 30 out INFORMATION Technology Infrastructure Library. Disponível em: < Acesso em: 30 out IT GOVERNANCE INSTITUTE. It Governance Roundtable: it Governance Trends. Disponível em: < gement/contentdisplay.cfm&contentid=40353> Acesso em: 30 out NEMETH, Evi; SNYDER, Garth; HEIN, Trent. Manual Completo do Linux, Guia do Administrador. São Paulo: Pearson Makron Books, p. SUSSMAN, Ben; FITZPATRICK, Brian; PILATO, Michael. Version Control with Subversion. Califórnia, EUA: O'Reilly, p. TURNBULL, James. Pulling Strings with Puppet. New York, EUA: Apress, p. 20