Athos Ribeiro de Albuquerque Motta

Migração de servidores de aplicação JAVA no Fundo Nacional deDesenvolvimento da Educação -

De Oracle iAS para JBoss

Monografia de Pós-Graduação “Lato Sensu”apresentada ao Departamento de Ciência daComputação para obtenção do título de Especialistaem “Administração em Redes Linux”

OrientadorProf. Joaquim Quinteiro Uchoa

LavrasMinas Gerais - Brasil

2011

Athos Ribeiro de Albuquerque Motta

Migração de servidores de aplicação JAVA no Fundo Nacional deDesenvolvimento da Educação -

De Oracle iAS para JBoss

Monografia de Pós-Graduação “Lato Sensu”apresentada ao Departamento de Ciência daComputação para obtenção do título de Especialistaem “Administração em Redes Linux”

Aprovada em 30 de Abril de 2011

Prof. Arlindo Follador Neto

Prof. Sanderson Lincohn Gonzaga de Oliveira

Prof. Joaquim Quinteiro Uchoa(Orientador)

LavrasMinas Gerais - Brasil

2011

Dedico esta monografia a meus pais, pelo carinho, apoio e incentivo em todos osmomentos...

Agradecimentos

Agradeço a Deus pela vida, a minha noiva pelo carinho e companhia,a minha família pelo apoio, e a todos os que me incentivaram duranteo curso.

Sumário

1 Introdução 1

2 Conceitos Básicos 3

2.1 Oracle Application Server . . . . . . . . . . . . . . . . . . . . . 5

2.2 Servidor de Aplicações JBoss . . . . . . . . . . . . . . . . . . . . 6

2.3 Virtualização com KVM . . . . . . . . . . . . . . . . . . . . . . 9

2.4 KVM - Kernel-Based Virtual Machine . . . . . . . . . . . . . . . 11

2.5 Libvirt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Recursos de administração . . . . . . . . . . . . . . . . . . . . . 14

2.6.1 Virsh . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.6.2 Virtual Machine Manager . . . . . . . . . . . . . . . . . 16

3 Estudo de Caso 19

3.1 Ambiente de estudo . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Conclusão 25

i

ii

Lista de Figuras

2.1 Arquitetura J2EE - Adaptada de (BARRY, 2011) . . . . . . . . . 4

2.2 Estrutura de diretórios - JBoss . . . . . . . . . . . . . . . . . . . 7

2.3 Camadas de abstração em virtualização - Adaptado de (JONES,2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Componentes do KVM - Adaptado de (JONES, 2007) . . . . . . . 12

2.5 Virtual Machine Manager - Tela principal . . . . . . . . . . . . . 17

2.6 Virtual Machine Manager - Informações de máquina virtual . . . 18

iii

iv

Lista de Tabelas

2.1 Estrutura de diretórios superior do JBoss . . . . . . . . . . . . . . 8

2.2 Hipervisores suportados pela Libvirt . . . . . . . . . . . . . . . . 14

2.3 Exemplos de parâmetros do comando virsh. . . . . . . . . . . . . 15

3.1 Especificações dos equipamentos - ambiente anterior . . . . . . . 20

3.2 Especificações dos equipamentos - novo ambiente . . . . . . . . . 21

v

vi

Resumo

O objetivo deste trabalho é apresentar as técnicas e recursos utiliza-dos na migração do ambiente de servidores de aplicações JAVA - J2EEdo Fundo Nacional de Desenvolvimento da Educação (FNDE), autar-quia do Ministério da Educação. A motivação para efetuar a referidamigração foi a atualização para a versão 1.6 do JAVA JDK para desen-volvimento e execução de aplicações, a questão de custos em relação àsolução final, a padronização dos ambientes de aplicação com o exis-tente no MEC, além de atender às politicas governamentais de apoioao software livre. O foco principal foi a substituição do servidor deaplicações Oracle iAS 10G para o servidor JBoss EAP 4.3, juntamentecom a mudança de equipamentos, implantação de um novo modelo detrabalho dos servidores, fazendo uso de virtualização para aproveitarmelhor os novos equipamentos, baseada em Red Hat Linux. Tam-bém foram implantados sistemas para monitoramento das aplicaçõese servidores.

Palavras-Chave: Software Livre; Java; Jboss; Virtualização; KVM;Linux.

vii

Capítulo 1

Introdução

O objetivo deste trabalho é apresentar as técnicas e recursos utilizados na migra-ção do ambiente de servidores de aplicações JAVA - J2EE do Fundo Nacionalde Desenvolvimento da Educação (FNDE), autarquia do Ministério da Educação.Após análise de vantagens em relação à estrutura de servidores de aplicação emoperação, buscando verificar o que seria mais vantajoso e interessante ao órgãopara promover a continuidade de uso da solução existente, foi definido um novopadrão de servidores de aplicação. A motivação para efetuar a referida migraçãofoi a atualização para a versão 1.6 do JAVA JDK para desenvolvimento e execu-ção de aplicações, a questão de custos em relação à solução final, a padronizaçãodos ambientes de aplicação com o existente no MEC, além de atender às politi-cas governamentais de apoio ao software livre. Juntamente com essa mudança desoftware para continuar provendo o serviço de aplicações web, foi também efetu-ada uma substituição de equipamentos por novos servidores com maior capacidadede processamento e com tempo de garantia renovado, permitindo uma maior con-fiabilidade para os serviços prestados.

Como a diferença de recursos entre os novos equipamentos e os antigos seriagrande e de modo a evitar um desperdício desses recursos, decidiu-se utilizar avirtualização de servidores como forma de aumentar a disponibilidade do serviço.Um outro motivo para uso de virtualização era facilitar a manutenção dos servi-dores e aproveitar de maneira mais satisfatória os recursos disponibilizados poresses equipamentos, tanto para o ambiente de produção como para os ambientesde desenvolvimento e homologação de software do FNDE.

Como o sistema operacional utilizado nos equipamentos seria a versão 5.4 doRed Hat Enterprise Linux, foi dada preferência para que se utilizassem os recursos

1

de virtualização já disponíveis no mesmo, aproveitando as ferramentas ligadasà biblioteca libvirt; Havia a possibilidade de utilização de virtualização atravésde dois hipervisores1: o Xen2 e KVM (Kernel Virtual Machine)3, ambos sendosoftware de código aberto. Porém, devido a informações recebidas de técnicosda empresa que estaria fornecendo o conjunto de software a ser implantado, oKVM seria o produto com suporte principal oferecido pela Red Hat já a partir dasnovas versões de seu sistema operacional (da versão 6.0 em diante), pelo fato dejá estar incluso de forma direta no kernel do Linux e pela grande evolução de suaqualidade desde que foi lançado. Devido a isso, decidiu-se pelo uso dessa soluçãono ambiente operacional do FNDE.

O foco principal deste trabalho é apresentar a substituição do servidor de apli-cações Oracle iAS 10G para o servidor JBoss EAP 4.3 juntamente com a mudançade equipamentos e implantação de um novo modelo de trabalho dos servidores,fazendo uso de virtualização baseada em Red Hat Linux para aproveitar melhor osnovos equipamentos. Também foram implantados sistemas para monitoramentodas aplicações e servidores.

O texto foi baseado nas normas da UFLA para produção de TCC (PRPG/U-FLA, 2007) e encontra-se organizado como se segue. O Capítulo 2 apresentaconceitos básicos sobre ferramentas e recursos utilizados na implantação em es-tudo, conceitos sobre virtualização com KVM e sobre a utilização da bibliotecalibvirt para gerenciamento das máquinas virtuais. O Capítulo 3 apresenta informa-ções sobre o objeto de estudo e como foi realizada a implantação desse estudo noFundo Nacional de Desenvolvimento da Educação - FNDE. O Capítulo 4 apresentacomentários e observações finais.

1Hipervisor: Camada de software que abstrai o hardware do sistema operacional permitindoque vários sistemas operacionais virtualizados sejam executados no mesmo equipamento, sendoexecutado sobre um sistema operacional hospedeiro.

2Xen Hypervisor - http://www.xen.org3Linux KVM - http://www.linux-kvm.org

2

Capítulo 2

Conceitos Básicos

Este capítulo busca apresentar conceitos básicos relativos aos recursos utilizadosna execução do projeto alvo do presente estudo de caso. São apresentadas defini-ções e um breve histórico desses recursos.

Servidores de aplicação são produtos baseados em componentes inseridos nacamada central de um ambiente de servidores, provendo serviços de middlewarepara segurança e manutenção de estado, assim como acesso a dados e persistência.

A função de um servidor de aplicação é padronizar a arquitetura de desen-volvimento de aplicações. Esta tarefa é realizada através da definição de váriosmodelos de componentes, que são padrões que podem ser utilizados pelos desen-volvedores para criar componentes, os quais podem ser disponibilizados em umservidor de aplicação utilizando um modelo de desenvolvimento. A partir do mo-mento em que os componentes são executados no servidor, este provê um conjuntode serviços que são colocados à disposição dos componentes.

Os servidores de aplicação Java baseiam-se na plataforma Java 2, EnterpriseEdition, que utiliza um modelo distribuído de múltiplas camadas, normalmentesendo formado por:

• uma camada cliente, a qual pode ser composta por uma ou mais aplicações(clientes) ou browsers (no caso de aplicações web);

• uma camada central, formada pela plataforma J2EE, através de um servidorweb e um servidor Enterprise Java Beans - EJB, também chamados contêi-neres;

3

• uma camada de informações (Enterprise Information System - EIS), formadapelos servidores de arquivos e servidores de bancos de dados.

A Figura 2.1 apresenta um exemplo da organização em uma estrutura deste modelodistribuído.

Figura 2.1: Arquitetura J2EE - Adaptada de (BARRY, 2011)

Segundo (ARMSTRONG et al., 2005),

“Aplicações J2EE de múltiplas camadas são geralmente consideradascomo aplicações de três camadas porque elas são distríbuidas entretrês localizações: máquinas clientes, o equipamento servidor J2EE,

4

e os bancos de dados ou máquinas legadas no back end. Aplicaçõesde três camadas que são executadas dessa forma estendem o modelopadrão de camadas cliente e servidor ao inserir um servidor de apli-cação de execução múltipla entre a aplicação cliente e o servidor dearmazenamento”.

A camada cliente pode ser formada por um cliente web ou por uma aplicaçãocliente. O cliente web é formado por 2 partes:

• páginas web contendo linguagens de marcação1 (MARKUP. . . , 2011), dina-micamente geradas por componentes sendo executados na camada web;

• um navegador web, responsável por renderizar as páginas recebidas do ser-vidor.

Aplicação cliente, mostrada como a camada do topo da Figura 2.1, refere-seao tipo de cliente disponibilizado através de um navegador web por meio de umalinguagem de marcação. Os componentes da camada do meio, ou camada web sãoexecutados no servidor J2EE. Esses componentes são formados por servlets ou pá-ginas criadas utilizando tecnologia JSP, disponibilizando conteúdo dinâmico. Porúltimo, a camada EIS, ou sistema de infraestrutura enterprise, gerencia os compo-nentes relacionados ao acesso à base de dados e outros sistemas de informação.

2.1 Oracle Application Server

O Oracle Application Server Enterprise Edition (referido daqui em diante comoOracle iAS) é “uma plataforma de aplicações que oferece uma solução compre-ensiva para desenvolvimento, integração e disponibilização de (...) aplicações,portais e sítios web”2.

Entre as características citadas pelo fornecedor, estão a alta disponibilidade,performance e escalabilidade. O referido sistema vinha sendo utilizado no am-biente operacional do FNDE aproximadamente desde o ano de 2006, em funçãode licitação e projeto de implantação ocorridos anteriormente.

1Por exemplo: HTML, XML, etc2Oracle application Server Enterprise Edition - http://www.oracle.com/us/products/

middleware/application-server/enterprise-edition/index.html

5

2.2 Servidor de Aplicações JBoss

O servidor de aplicação Jboss teve origem em 1999, com o nome de EJBoss (En-terprise Java Beans Open Source Software), através de Marc Fleury, disponibili-zando uma implementação da porção EJB das especificações da J2EE. O nomefoi alterado logo em seguida para evitar problemas de licenciamento com a SunMicrosystems e seu EJB, passando então a se chamar JBoss.

À medida em que o projeto se popularizava, desenvolvedores passaram a ven-der documentação, serviços de consultoria e treinamento. Em 2001, a equipe dedesenvolvimento foi incorporada como JBoss Group, LLC, passando a oferecerserviço de suporte em 2002. Ao mesmo tempo, foi lançada a versão JBoss AS 3,passando a ser competitiva frente a produtos proprietários como Websphere e We-bLogic. Em 2004, o JBoss Group, LLC. passou a ser uma corporação com o nomeJBoss, Inc. Ao atingir a versão JBoss AS 4, o foco em ambientes corporativos(enterprise) aumentou, através de serviços de suporte técnico; Além disso, outrassoluções passaram a ser diponibilizadas como componentes que podem ser utiliza-dos tanto junto ao JBoss AS como independentemente. Entre esses componentes,podem ser citados o JBoss Cache, Hibernate, jBPM e JBoss Rules. Em abril de2006, a empresa foi adquirida pela Red Hat, Inc (JAMAE; JOHNSON, 2009).

Como algumas características do JBoss, pode-se citar a implantação fácil decluster de servidores, com ajustes mínimos em arquivos de configuração e a im-plantação de novas tecnologias antes dos outros produtos do mercado. Segundo(JAMAE; JOHNSON, 2009), o suporte a Java SE 5.0 e EJB3 no JBoss foi disponi-bilizado desde 2005, enquanto que os servidores de aplicação de grande influênciano mercado passaram a disponibilizar esse suporte apenas dois ou três anos depois.

Além disso, devido ao seu tempo de existência no mercado, o JBoss é con-siderado um produto maduro e confiável. Por ser um produto desenvolvido nomodelo de código aberto (open source), sua adoção torna-se mais fácil por partedos desenvolvedores. O desenvolvedor precisa apenas efetuar o download de umarquivo, descompactá-lo, e começar a sua utilização, sem problemas com licen-ças. Além disso, é possível verificar o código fonte e efetuar modificações senecessário, além de contribuir com o processo de melhorias do JBoss. Da mesmaforma que com outro software open source, há a formação de uma comunidade deusuários que podem enviar comentários, sugestões, alterações no código atravésde patches enviados e que são analisados para uma possível inclusão em novasversões. Mais ainda, há a possibilidade de se obter suporte gratuito justamenteatravés da comunidade de usuários do sistema.

6

O servidor de aplicação JBoss é construido em uma arquitetura modular, pos-sibilitando que apenas serviços necessários sejam executados no servidor, evitandoassim desperdício de recursos e diminuindo a possibilidade de problemas de se-gurança devido a processos sendo executados sem necessidade. A instalação doJBoss, como dito anteriormente, pode ser resumida em um simples procedimentode se efetuar o download de um arquivo e descompactar o arquivo em um lugarapropriado no equipamento onde o mesmo será executado. Além disso, os arqui-vos necessários à execução do JBoss ficam todos contidos na estrutura de diretóriosprovida pelo arquivo descompactado, facilitando a movimentação do serviço emcaso de migração de servidores, bem como em caso de necessidade de desinstala-ção, onde é necessário apenas efetuar a exclusão da referida estrutura de diretórios.A Figura 2.2 ilustra a estrutura de diretórios principais do servidor JBoss (JBOSS,INC., 2006). A Tabela 2.1 apresenta uma descrição dos diretórios superiores daestrutura do JBoss.

Figura 2.2: Estrutura de diretórios - JBoss

7

Diretório Descriçãobin Contém pacotes JAR e scripts de inicializaçãoclient Contém os pacotes JAR necessários para execução de clientes

fora do JBossserver Contém os conjuntos de configuração do servidor JBosslib Contém pacotes JAR de inicialização usados pelo JBoss

Tabela 2.1: Estrutura de diretórios superior do JBoss

8

2.3 Virtualização com KVM

Devido ao aumento constante de recursos e poder de processamento dos computa-dores, muitas vezes todo o potencial dos equipamentos não é aproveitado. Comoforma de resolver essa situação, tem-se dado bastante destaque à utilização detécnicas de virtualização de computadores. A virtualização de sistemas consisteem executar determinado software, normalmente sistemas operacionais, de formaisolada, independente e simultaneamente em um único sistema, com sua própriainstância de sistema operacional virtualizado. Um dos modos de implementaçãocomuns de virtualização é através da utilização de um hipervisor, que fornece umhardware virtual à máquina virtual sendo executada (CURRAN, 2010). A Fi-gura 2.3 apresenta o modelo de camadas de abstração em virtualização.

Figura 2.3: Camadas de abstração em virtualização - Adaptado de (JONES, 2007)

O hipervisor serve como uma camada de abstração entre o hardware e o sis-tema operacional. Acima do hipervisor estão os sistemas operacionais “convida-dos”, ou máquinas virtuais. O hipervisor se encarrega de passar a essas máquinasvirtuais a impressão de estarem sendo executadas diretamente sobre o hardware.

Dentre os modos de virtualização existentes atualmente, pode-se citar:

• Virtualização por software: Também conhecida como emulação ou vir-tualização completa, é utilizada para executar sistemas operacionais sem

9

modificações, apenas simulando toda a arquitetura de CPU do equipamentovia software. É a mais lenta forma de se virtualizar, porém é a que podeser executada em mais sistemas, por não depender de hardware específico,levando-se em consideração que o sistema de virtualização ofereça a possi-bilidade de virtualização dessa forma.

• Tradução binária: Neste modelo, ao invés de ser efetuada uma emulaçãodo processador, a máquina virtual é executada diretamente na CPU. Caso amáquina virtual necessite ter acesso a instruções privilegidas do sistema, ohipervisor intercepta a chamada e efetua uma reescrita do código em me-mória, de forma que o sistema operacional da máquina virtual opere nor-malmente sem perceber a mudança. Este modelo, utilizado pelo hipervisorVMWare3 (RED HAT, INC., 2009) e também pelo emulador QEMU (BEL-LARD, 2005), apesar de ter uma alta complexidade para sua implementação,provê ganhos significativos de desempenho em comparação com a emulaçãocompleta da CPU.

• Paravirtualização: Consiste de uma técnica de virtualização em que o sis-tema operacional virtualizado é executado juntamente com o sistema hospe-deiro, compartilhando dispositivos e bibliotecas comuns a ambos. Um sis-tema paravirtualizado possui acesso completo aos dispositivos de sistema,sendo que através de configurações de segurança (como SELinux4 e con-trole de arquivos) é possível impor limites a esse acesso. Uma vantagem daparavirtualização é sua velocidade maior em comparação a outros modos devirtualização, com o custo de ser necessário efetuar modificações no sistemaoperacional hospedeiro (no caso do Linux, uma imagem modificada do ker-nel). O sistema “convidado” fica ciente de que está sendo executado em umhipervisor e coopera com o mesmo em seus processos de escalonamento eI/O; O hipervisor Xen utiliza essa técnica.

• Virtualização Assistida por hardware: É uma técnica assistida por hardware,provendo um ambiente virtualizado com total abstração da camada física dosistema, criando uma máquina virtual onde o sistema operacional convidadopode ser executado, sem a necessidade de modificações no mesmo. O sis-tema operacional convidado é executado normalmente, sem a noção de queestá em um ambiente virtualizado. É necessário que haja suporte a essemodo de virtualização por parte do processador utilizado, através da pre-sença da tecnologia AMD-V (AMD Virtualization) em processadores AMD,

3VMWare - http://www.vmware.com4SELinux: http://selinuxproject.org/page/Main_Page

10

ou VT-x para processadores Intel; Ambos fabricantes vem constantementeacrescentando aos seus processadores cada vez mais recursos de virtualiza-ção de forma a diminuir possíveis sobrecargas à memória do sistema devidoà necessidade de tradução de endereços de acesso à memória. Graças a essesavanços, os sistemas virtualizados conseguem atingir desempenho similar asistemas rodando diretamente sobre o hardware. Entre esses recursos estãoo VT-D da Intel e o IOMMU da AMD, responsáveis por oferecer acessodireto a dispositivos PCI para as máquinas virtuais. É esse o tipo de virtua-lização utilizado pelo KVM.

2.4 KVM - Kernel-Based Virtual Machine

Os equipamentos atuais têm se tornado cada vez mais complexos em relação aoperações de escalonamento básicas, por ser necessário levar em conta múltiplascamadas de processamento em um núcleo, múltiplos núcleos em um processador,e múltiplos processadores em um único sistema. Da mesma forma, as controla-doras de memória integradas precisam que o gerenciamento de memória leve emconsideração as características de acesso à memória não-uniforme (NUMA)5 dosistema. Enquanto para hipervisores normais é necessário investir esforços paraintegrar essas capacidades, o kernel do Linux apresenta os recursos de escalona-dor e sistema de gerenciamento de memória de forma madura, sendo assim umaboa opção para virtualização de sistemas, que podem então desfrutar dos trabalhosde otimização atuais e futuros do mesmo em seu favor. Cada máquina virtual passaa ser um processo comum escalonado pelo escalonador do kernel Linux.

Nesse contexto é que surgiu o KVM, implementado como um módulo queao ser carregado converte o kernel Linux em um hipervisor. Seu desenvolvimentotem ocorrido de maneira bastante rápida, em parte devido à sua entrada no mer-cado após tecnologias como a virtualização assistida por hardware já haverem sidocriadas. Dessa forma, recursos já disponibilizados por hardware não precisam serimplementados. O hipervisor KVM passou a fazer parte do kernel Linux a partir desua versão 2.6.20, e requer que o sistema possua suporte às tecnologias Intel VT-Xou AMD-V. Com sua adoção, recursos como gerenciador de memória, escalona-dor de processos e pilha de rede, entre outros, não precisaram ser redesenvolvidos,

5NUMA - Non-Uniform Memory Access: Refere-se à uma arquitetura de memória em que otempo de acesso à memória depende da sua localização em relação ao processador; Dessa forma, oprocessador pode acessar de forma mais rápida sua própria memória local em comparação a memórianão-local, compartilhada ou não com outros processadores.

11

já que o kernel Linux já os tem implantados com uma maturidade e estabilidadereconhecidas.

Ao ter como requisito a disponibilidade por parte do equipamento de recursosnativos de virtualização, o KVM, através de seus desenvolvedores, pode ter umfoco voltado a esses equipamentos, ao invés de se preocupar com suporte a equi-pamentos legados ou modificações no sistema operacional, como no caso do Xen.Além disso, ao utilizar como base o próprio kernel Linux, pode se aproveitar dosrecursos de gerenciamento de memória, escalonamento de processos, entre outros,já inclusos nele e também da maturidade apresentada pelo mesmo, ao invés de terque implementar esses recursos desde o início.

As máquinas virtuais são executadas em modo de usuário, sendo gerenciadaspelo sistema operacional hospedeiro como um simples processo. A emulação dedispositivos a serem utilizados pelas máquinas virtuais é de responsabilidade deuma versão modificada do emulador QEMU6, que fornece um conjunto de dis-positivos como controladoras de disco IDE e SCSI, placas de interface de rede,barramentos USB e PCI, entre outros.

Figura 2.4: Componentes do KVM - Adaptado de (JONES, 2007)

6QEMU - http://qemu.org

12

A Figura 2.4 fornece uma visão do modelo de funcionamento do KVM. Acimado hardware está a camada do hipervisor, formada pelo uso do kernel Linux jun-tamente com o módulo do KVM carregado. Acima dele, estão os processos sendoexecutados pelo sistema operacional, como as aplicações normais do sistema, ejuntamente com eles, a máquina virtual junto com suas próprias aplicações, sendoreconhecida também como mais um processo pelo hipervisor (JONES, 2007).

2.5 Libvirt

A biblioteca Libvirt7 foi desenvolvida para ser um conjunto de software desti-nado a prover uma maneira simplificada de gerenciamento de máquinas virtuaisjuntamente com outras funcionalidades de virtualização, como gerenciamento deinterfaces de rede e armazenamento, ou seja, controlar todos os aspectos de ad-ministração de máquinas virtuais. Além disso, um de seus objetivos é prover ummeio centralizado de gerência de diversas ferramentas de virtualização, seja hi-pervisores, sejam outras ferramentas de virtualização. O intuito é ser um “blocode construção” para ferramentas de gerenciamento de alto nível e para aplicaçõesfocadas em virtualização de uma única máquina virtual, ou nó. Diversos nós po-dem ser acessados simultaneamente, porém as APIs limitam-se a operações emum único nó (LIBVIRT, 2011).

Entre as características da Libvirt, estão a capacidade de gerenciamento re-moto dos sistemas virtualizados com utilização de certificados x5098 e criptogra-fia TLS9, podendo ser autenticado com Kerberos10 e SASL11; Ela permite uso depolíticas de controle de acesso utilizando PolicyKit12 e autodescoberta de sistemasatravés de DNS multicast com Avahi13. O desenvolvimento da biblioteca está vol-tado a oferecer uma API comum que implemente ofereça funcionalidades comuns

7Libvirt: http://libvirt.org8x509: Padrão de infraestrutura de chaves publicas para ponto único de acesso (Single sign-

on(SSO) e infraestrutura de gerenciamento de privilégios(PMI): http://tools.ietf.org/html/rfc2510

9TLS - Segurança em camada de transporte(Transport Layer Security: http://www.ietf.org/html.charters/tls-charter.html

10Kerberos - Protocolo de autenticação de rede: http://web.mit.edu/Kerberos/11SASL - Camada simples de autenticação e segurança(Simple Security and Authentication

Layer): http://asg.web.cmu.edu/sasl/12PolicyKit - Conjunto de ferramentas para controle de privilégios para serviços do sistema.

http://www.freedesktop.org/wiki/Software/PolicyKit13http://avahi.org/

13

Tabela 2.2: Hipervisores suportados pela LibvirtHipervisor DescriçãoXen Hipervisor para arquiteturas Intel 32bit, Intel 64bit e

PowerPc 970QEMU Emulador disponível para várias arquiteturasKernel-basedVirtual Machine(KVM)

Plataforma de emulação Linux

OpenVZ Virtualização em nível de sistema operacional base-ada no Kernel Linux

VirtualBox Hipervisor para virtualização de arquitetura x86User Mode Linux Emulador de plataforma Linux para várias arquite-

turasArmazenamento Drivers de áreas de armazenamento (disco local,

disco em rede, volumes iSCSI)

implementadas pelo conjunto de hipervisores suportados. A Tabela 2.2 mostrauma lista de hipervisores suportados pela libvirt.

2.6 Recursos de administração

2.6.1 Virsh

A terminologia utilizada pela Libvirt refere-se ao host físico como sendo um “nó”e ao sistema operacional virtualizado como sendo um “domínio”. A configuraçãode um domínio é toda definida através de um arquivo XML, contendo as opções ne-cessárias para definição do domínio, informando recursos utilizados pelo domínio,configuração de periféricos, tipos de dispositivos do domínio. Essa configuraçãopode ser muito simples, ao mesmo tempo em que permite um grande detalhamentode características disponibilizadas para o dominio em questão.

Uma das ferramentas disponibilizadas pela Libvirt chama-se Virsh. Trata-sede um comando que permite a utilização de funcionalidades da Libvirt através deum modelo interativo de shell. Os recursos oferecidos por essa ferramentas podemser utilizados diretamente pela linha de comando, e também pelo shell interativoinvocado pela execução isolada do comando virsh.

Através desse comando, é possível efetuar operações como:

14

Tabela 2.3: Exemplos de parâmetros do comando virsh.Parâmetro Funçãoautostart Habilita e desabilita a inicialização automática de

um domínio ao se iniciar o serviço (daemon da lib-virt.

console Efetua conexão à console virtual da máquina virtual(domínio).

create Cria um domínio a partir de um arquivo XML.destroy Finaliza imediatamente a execução de um domínio,

liberando qualquer recurso que o mesmo esteja uti-lizando.

detach-disk Desconecta um dispositivo de disco do domínio.domifstat Obtém informações referentes à interface de rede de

um domínio em execução.dominfo Obtém informações básicas sobre determinado do-

mínio.dumpxml Retorna informações sobre o domínio em formato

XML na saída padrão (stdout).edit Possibilita a edição do arquivo XML de configura-

ção de um domínio.list Retorna uma lista de domínio configurados e/ou dis-

poníveis.migrate Efetua a migração de um domínio para outro host.reboot Efetua a reinicialização de um domínio.start Coloca um domínio desligado em funcionamento.

• listar as máquinas virtuais, ou domínios, existentes;

• repassar comandos para iniciar, reiniciar e desligar os domínios;

• alterar configurações do domínio, seja informando novos dispositivos comoredimensionando recursos;

• efetuar migrações de domínios entre hosts.

A Tabela 2.3 mostra algumas das opções disponíveis à ferramenta, que podemser utilizadas tanto como parâmetros em linha de comando (por exemplo, “virshlist”), ou diretamente ao se utilizar o shell virsh.

15

2.6.2 Virtual Machine Manager

Um dos recursos disponíveis no RedHat e em outras distribuições atuais para fazero gerenciamento de máquinas virtuais é o Virtual Machine Manager14, ou Virt-manager. O Virtual Machine Manager é uma ferramenta em interface gráfica quedisponibiliza ao administrador recursos como um sumário dos domínios sendoexecutados, juntamente com gráficos exibindo sua utilização de memória e pro-cessamento. Ainda oferece ferramentas de auxílio (wizards) para criação, configu-ração e alterações em domínios, ajudando na tarefa de administrar os recursos dehardware virtual para os mesmos, além de fornecer acesso a um console gráficoatravés de um cliente VNC embutido. Juntamente com o Virt-manager, são dispo-nibilizadas algumas ferramentas para auxiliar o trabalho do administrador. Essasferramentas, executadas em modo de linha de comando, são:

• Virt-install: Oferece meios de fazer a instalação de sistemas operacionaisnos domínios;

• Virt-clone: Para efetuar cópias de domínios inativos;

• Virt-image: Para efetuar instalações de sistemas operacionais a partir deuma imagem pré-definida.

• Virt-viewer: Fornece um console gráfico do sistema operacional convidado.

A Figura 2.5 apresenta a tela inicial do Virtual Machine Manager, já commáquinas virtuais criadas e em execução. Cabe salientar que os nomes dos ser-vidores foram alterados na figura de modo a preservar informações referentes aoambiente existente. Nesta tela é possível verificar informações como a quanti-dade de memória alocada para cada máquina virtual, bem como o servidor (host)onde as máquinas estão sendo executadas. Outra informação disponível refere-seà quantidade de processadores e/ou núcleos disponíveis no host e à quantidade deprocessadores virtuais alocados para cada máquina virtual.

A Figura 2.6 exibe informações sobre o uso de recursos que uma determi-nada máquina virtual está consumindo em tempo real (uso de processador, uso dememória, tráfego de dados em disco e de rede).

14Virtual Machine Manager - http://virt-manager.et.redhat.com/index.html

16

Figura 2.5: Virtual Machine Manager - Tela principal

17

Figura 2.6: Virtual Machine Manager - Informações de máquina virtual

18

Capítulo 3

Estudo de Caso

3.1 Ambiente de estudo

O ambiente de aplicações JAVA do FNDE era composto por um servidor dedicadopara o desenvolvimento das aplicações, um servidor para se efetuar a homologa-ção dos sistemas desenvolvidos antes de entrarem em produção, e o ambiente deprodução em si, formado por quatro servidores físicos que comunicavam entre siatravés de um sistema de arquivos em cluster, o OCFS21. As especificações dosequipamentos são listadas na tabela 3.1.

O acesso aos sistemas em produção é controlado por um equipamento balan-ceador de carga, sendo que o utilizado é o appliance netscaler, de fabricação daCitrix. Esse balanceador é responsável por toda a parte de gerenciamento de con-textos das aplicações e redirecionamento do usuário a determinado servidor dentrode um conjunto. Esse equipamento mantem-se em uso no ambiente, sofrendo al-terações apenas nos servidores para os quais passou a direcionar o tráfego da rede.

O ambiente posterior passou a ser formado também por seis máquinas físicas,sendo quatro para o ambiente de produção, uma para desenvolvimento e mais umapara aplicação. A diferença primária está nas especificações de hardware dessesequipamentos, como listadas na tabela 3.2.

A mudança de ambiente em relação à alteração de sistema operacional ocorreude forma tranquila, uma vez que ambos, tanto SUSE como Red Hat utilizam comobase o padrão de pacotes RPM. Dessa forma, houve um melhor aproveitamento

1OCFS2 - Oracle Cluster File System 2: http://oss.oracle.com/projects/ocfs2/

19

Tabela 3.1: Especificações dos equipamentos - ambiente anteriorDesenvolvimento: Um servidor, composto por:

• um processador Intel Xeon de núcleo duplo com tec-nologia Hyperthreading, resultando em quatro nú-cleos visíveis para o sistema;

• 6GB de memória;

• sistema operacional SUSE Linux Enterprise Server10 SP2.

Homologação: Um servidor, composto por:

• um processador Intel Xeon de núcleo duplo com tec-nologia Hyperthreading, resultando em quatro nú-cleos visíveis para o sistema;

• 8GB de memória;

• sistema operacional SUSE Linux Enterprise Server10 SP2.

Produção: Quatro servidores, compostos por:

• quatro processadores Intel Xeon de núcleo duplocom tecnologia Hyperthreading, resultando em de-zesseis núcleos visíveis para o sistema;

• 12GB de memória;

• sistema operacional SUSE Linux Enterprise Server10 SP2.

20

Tabela 3.2: Especificações dos equipamentos - novo ambienteDesenvolvimento: Um servidor, composto por:

• dois processadores Intel Xeon de núcleo quádruplo,resultando em oito núcleos visíveis para o sistema;

• 32GB de memória;

• sistema operacional Red Hat Enterprise Linux 5.4.

Homologação: Um servidor, composto por:

• dois processadores Intel Xeon de núcleo quádruplo,resultando em oito núcleos visíveis para o sistema;

• 32GB de memória;

• sistema operacional Red Hat Enterprise Linux 5.4.

Produção: quatro servidores, compostos por:

• quatro processadores Intel Xeon de núcleo quádru-plo, resultando em dezesseis núcleos visíveis para osistema;

• 128GB de memória;

• sistema operacional Red Hat Enterprise Linux 5.4.

21

do tempo, já que os responsáveis pela administração dos servidores já possuíambastante familiaridade com a estrutura e o funcionamento do sistema operacional.Para aproveitar recursos de gerenciamento e evitar tráfego desnecessário na rede,foi configurado um servidor como repositório de pacotes para distribuição nosservidores.

A implantação teve início com o levantamento por parte dos técnicos da em-presa contratada das configurações do ambiente de aplicações existente no FNDE,através de diversas reuniões e acompanhamento dos administradores do ambiente.Foram obtidas informações sobre as bibliotecas utilizadas, os sistemas que esta-vam sendo disponibilizados, o modo de funcionamento destes sistemas, as fontesde dados para conexão ao banco de dados, e como as aplicações eram disponibili-zadas ao servidor de aplicação durante suas devidas atualizações e implantações.

O primeiro passo foi o levantamento de quais aplicações seriam portadas doambiente antigo para o Jboss. Após esse levantamento, foi verificado que aproxi-madamente trinta sistemas deveriam ser migrados ao todo. Porém, foi verificadoque alguns sistemas precisariam continuar funcionando em um ambiente servidopelo Oracle Application Server, devido à esses sistemas serem desenvolvidos emlinguagem PL/SQL, dependente do ambiente Oracle. Assim não seria possívelefetuar a migração de imediato desses sistemas. Dessa forma, ficou a cargo dosdesenvolvedores e arquitetos JAVA a tarefa de efetuar posteriormente o trabalho dedesenvolvimento de solução independente de ambiente caso possível e necessárioa médio ou longo prazo.

Um dos desafios enfrentados foi a mudança das bibliotecas de sistema que porvezes encontravam-se diretamente atreladas às aplicações em seus empacotamen-tos, os quais eram disponibilizados através dos pacotes .ear específicos de cadaaplicação. Durante o processo de migração, essas bibliotecas foram redefinidasde modo a serem utilizadas em modo compartilhado pelas aplicações, mantendoassim um ambiente mais controlado e com risco menor de falhas.

De modo a não causar transtornos aos usuários dos sistemas, foram prepara-dos ambientes separados nas novas máquinas enquanto os servidores antigos con-tinuavam em produção. Dessa forma, o processo de migração tanto de bibliotecaspara garantir compatibilidade com o JBoss quanto das aplicações pode ser feito deforma gradual e segura. À medida que as aplicações iam sendo migradas, os res-ponsáveis pela homologação dos sistemas efetuavam os testes no novo ambiente evalidavam os mesmos para implantação em produção.

Enquanto isso, o desenvolvimento de novas versões das aplicações foi con-gelado no ambiente antigo, e os desenvolvedores passaram a efetuar alterações já

22

visando o novo ambiente. Ao mesmo tempo, os servidores destinados a prover onovo ambiente de produção iam sendo instalados e configurados para hospedar oserviço do JBoss juntamente com as aplicações portadas.

Foram criados em cada servidor físico de produção quatro máquinas virtuais,além de duas máquinas virtuais no servidor físico de desenvolvimento e duas noservidor de homologação, utilizando-se a virtualização do KVM juntamente como uso da biblioteca libvirt para gerenciamento das máquinas virtuais.

Inicialmente, cogitou-se utilizar uma área de armazenamento comum em umstorage para esse ambiente. Devido a problemas de performance detectados apóstestes utilizando GFS2, decidiu-se manter as máquinas independentes entre si, po-rém mantendo as mesmas versões das aplicações em instalações iguais. Isto foifeito através da utilização da ferramenta Rsync3 de uma das máquinas virtuaispara todas as outras, garantindo a igualdade de versões, e com o balanceamentode carga garantido pelo equipamento também já citado anteriormente. Apenaspara informação, o motivo dos problemas de desempenho foi devido a um gargaloexistente no referido equipamento de armazenamento.

Através da utilização das máquinas nessa disposição, passou-se a ter um am-biente com maior capacidade de conexões por parte dos usuários dos sistemas.Além disso um problema que às vezes acontecia com o sistema anterior foi elimi-nado. Os servidores rodando o Oracle iAS em determinados momentos não obtiamêxito na sincronização. Os servidores não conseguiam atualizar os sistemas atra-vés dos pacotes .ear e também não conseguiam voltar ao funcionamento normalapós esses procedimentos de atualização, deixando as aplicações indisponíveis emalguns momentos. Isso exigia a parada dos processos responsáveis pelos sistemasem todas as máquinas do ambiente. Em alguns casos, era necessário efetuar areinicialização dos servidores e até mesmo a restauração de cópias de segurança.

Outro ponto alterado foi a maneira como a implantação e atualização de siste-mas era efetuada. No ambiente anterior, as aplicações eram disponibilizadas a umdos servidores de aplicação, e através do sistema de arquivos de cluster OCFS2,os dados eram replicados para as outras máquinas responsáveis pelo mesmo tra-balho. Tentou-se utilizar GFS para que as máquinas enxergassem um ponto deacesso único através de um storage. Porém, como o desempenho não ficou comoo esperado, decidiu-se utilizar os antigos scripts adaptados para o novo ambiente,replicando as mudanças para todos os servidores através do uso da ferramentaRsync. Assim, mesmo com o aumento do número de servidores, que passaram

2GFS - Red Hat Global File System: http://www.redhat.com/gfs/3Rsync: http://rsync.samba.org/

23

de quatro para dezesseis no ambiente de produção, o tempo de atualização dasaplicações foi otimizado.

O script de atualização das aplicações tem seu funcionamento baseado na uti-lização de um menu em shell script que apresenta ao responsável pela atualizaçãodo sistema a opção de escolha do sistema a ser atualizado. O script obtém um ar-quivo contendo os códigos da aplicação disponibilizado em um servidor de arqui-vos compartilhado, copia para o servidor de aplicação, efetua as devidas alteraçõesde arquivos de configuração de aplicações que necessitam manter-se constantes en-tre atualizações, e então através do uso de Rsync, efetua apenas as alterações maisatuais no sistema, melhorando o tempo de atualização.

Assim que as aplicações migradas nos ambientes de homologação e desenvol-vimento foram definidas como prontas para implantação no ambiente de produção,foi efetuado um plano de migração através de padrões de requisição de mudanças.As aplicações foram separadas em uma lista e organizadas para migração por eta-pas, após análise de impactos e revisões por parte dos desenvolvedores e gerentesresponsáveis pelo funcionamento das mesmas. A migração foi dividida em trêsgrupos para migração, levando em consideração níveis de complexidade e de pri-oridades de funcionamento dessas aplicações. Foram identificados alguns errosde execução das aplicações, os quais foram corrigidos para efetuar a implanta-ção final. Ao final da implantação, devido a alguns problemas de funcionamentode duas aplicações, houve a necessidade de se efetuar o retorno de sua execuçãopara o ambiente anterior até que os problemas fossem solucionados, e após novostestes, houve a migração final com sucesso.

De forma a possibilitar o monitoramento dos servidores e serviços disponibi-lizados pelos mesmos, foi efetuada configuração por meio de adição desses novosservidores a ferramentas de monitoramento como Nagios e Cacti de modo a garan-tir ações por parte dos técnicos em caso de problemas. Como houve a distribuiçãodo serviço entre vários servidores, o padrão de disponibilidade dos serviços pres-tados passou a manter-se em um nível maior que o anterior.

24

Capítulo 4

Conclusão

A motivação principal do objeto desse estudo foi de se efetuar a migração dosservidores de aplicação JAVA e ao mesmo tempo atualizar os equipamentos quedisponibilizavam os serviços anteriormente. Os equipamentos em utilização aindaapresentavam bom desempenho e cumpriam suas funções, porém devido ao fatode término de seus prazos de garantia e também à necessidade de se manter ofuncionamento tanto dos equipamentos como dos serviços prestados por eles éque houve essa migração.

Uma das grandes deficiências do ambiente Java / Oracle iAS no FNDE era aquestão da versão do ambiente de desenvolvimento e execução de aplicações Javaque vinha sendo utilizada, mais especificamente com a versão 1.4 do Java Deve-lopment Kit - JDK, defasada e apresentando menos recursos em relação às versõesmais atuais. A dificuldade de atualização estava principalmente na necessidade deinstalação de versão mais atual do sistema, sendo necessário firmar novo contratojunto à Oracle (na figura de seus representante comerciais), causando um elevadocusto devido ao alto preço de licenças de uso de software desta empresa.

Como o objetivo principal da migração era efetuar a transferência das apli-cações do ambiente com Oracle iAS para o novo ambiente executando JBoss, épossível dizer que a mesma foi efetuada com sucesso. Após as alterações ne-cessárias devido às diferenças de funcionamento dos dois produtos, os sistemasforam migrados e passaram a trabalhar como esperado no novo ambiente. Todo oprocesso foi feito seguindo recomendações de práticas de gerência de informaçãocomo por exemplo documentos de requisição de mudança. Dessa forma, apenascom a verificação de funcionamento dos sistemas é que o trabalho foi dado comoconcluido. Passado um ano após a migração ter sido efetivada, a solução implan-

25

tada baseada no servidor de aplicações JBoss tem se mostrado estável, confiável ede ótimo nível de qualidade. Exceto por problemas isolados em certos momentosprovenientes de alterações em aplicações, o serviço tem sido mantido sem neces-sidade de grandes alterações ou incidentes críticos. Além disso, a qualidade dosprodutos utilizados tem sido verificada em função de seu funcionamento duranteesse tempo de uso.

Uma das questões que puderam ser observadas é a confirmação de que softwarelivre nem sempre é sinônimo de software gratuito. O contrato de suporte estabe-lecido junto à empresa, e por sua vez junto à Red Hat, foi de 1 ano, sendo queapós expirado esse prazo, houve a necessidade de se renovar a subscrição dos ser-viços de suporte. Durante a transição de período de vencimento de suporte e suarenovação, houve a interrupção da possibilidade de se obter novos pacotes e atua-lizações através dos canais oficiais da Red Hat. Além disso, pode-se observar quehá um custo de certa forma elevado em alguns pontos, como em relação ao suportede sistema operacional, mas ainda assim vantajoso em relação à solução utilizadaanteriormente.

26

Referências Bibliográficas

ARMSTRONG, E.; BALL, J.; BODOFF, S.; CARSON, D. B.; EVANS, I.;GREEN, D.; HAASE, K.; JENDROCK, E. The J2EE 1.4 Tutorial. 2005.1542 p. Disponível em: <http://download.oracle.com/javaee/1.4/tutorial/doc-/J2EETutorial.pdf>.

BARRY, D. Application server definition. 2011. Acessado em 20/02/2011.Disponível em: <http://www.service-architecture.com/application-servers-/articles/application server definition.html>.

BELLARD, F. Qemu, a fast and portable dynamic translator. Proceedings ofthe USENIX Annual Technical Conference, Usenix Association, p. 6, 2005.Disponível em: <http://www.usenix.org/event/usenix05/tech/freenix/full papers-/bellard/bellard.pdf>.

CURRAN, C. Red Hat Enterprise Linux Virtualization Guide. 5. ed.[S.l.], 2010. 402 p. Disponível em: <http://docs.redhat.com/docs/en-US-/Red%5FHat%5FEnterprise%5FLinux/5/html/Virtualization>.

JAMAE, J.; JOHNSON, P. JBoss in Action. Greenwich, CT: Manning PublicationsCo., 2009. 464 p.

JBOSS, INC. The JBoss 4 Installation Guide. [S.l.], 2006. 26 p. P.14,15.Disponível em: <http://docs.jboss.org/jbossas/guides/installguide/r1/en/pdf-/jboss4-install.pdf>.

JONES, M. T. Discover the linux kernel virtual machine. IBM DeveloperWorks,IBM Corp., 2007. Acessado em 20/02/2011. Disponível em: <http://www.ibm-.com/developerworks/linux/library/l-linux-kvm/>.

LIBVIRT. Libvirt Goals. 2011. Online. Disponível em: <http://libvirt.org/goals-.html>.

27

MARKUP Language. Britannica Online Encyclopedia, Britannica OnlineEncyclopedia, 2011. Acessado em 14/03/2011. Disponível em: <http://www-.britannica.com/EBchecked/topic% -/1323641/markup-language>.

PRPG/UFLA. Normas para Elaboração de Trabalhos de Conclusão de Cursosde Pós-Graduação Lato Sensu. 2. ed. Lavras, 2007. 29 p. Disponível em:<http://www.prpg.ufla.br/Legis/legis1.htm>.

RED HAT, INC. KVM – KERNEL BASED VIRTUAL MACHINE. [S.l.], 2009.11 p. Disponível em: <http://www.redhat.com/f/pdf/rhev/DOC-KVM.pdf>.

28