Sei sulla pagina 1di 14

Migrao de servidores fsicos para virtuais P2V usando ferramentas OpenSource

Diego Lima Santos Curso de Especializao em Redes e Segurana de Sistemas Pontifcia Universidade Catlica do Paran Curitiba, outubro de 2009

Resumo Estudo de caso real abordando a migrao (P2V) de servidores fsicos Linux para mquinas virtuais, realizada no Servio Social Autnomo Paranacidade. Utilizando para tal procedimento ferramentas OpenSource disponveis, virtualizao dos servidores utilizando o monitor de mquinas virtuais Xen. O artigo descrever as, tecnologias utilizadas, procedimentos adotados e resultados obtidos aps a migrao. 1 Introduo

Em meados de 2008 o Servio Social Autnomo Paranacidade adquiriu servidores do modelo IBM server x3650 de alta performance, porm a migrao trivial de todos os antigos servidores para novos no era possvel, pois a quantidade de antigos servidores era superior. Entretanto notvel que a ociosidade dos recursos em servidores de alta performance em mdia de 90%, devemos maximizar a utilizao dos recursos computacionais, pois o custo unitrio de cada servidor relativamente alto. A tcnica de virtualizao neste cenrio indicada para resolver o problema da subutilizao dos novos recursos. Virtualizao no uma idia nova, desde a criao da linguagem de programao Java, a maioria dos usurios de computadores utiliza pelo menos uma mquina virtual, talvez antigamente utilizavam o sistema UCSD Pascal p, uma das primeiras mquinas virtuais para Pascal. A virtualizao na camada de sistema operacional data do final da dcada de 1960, a primeira mquina virtual foi o VM/CMS da IBM, essa tecnologia ainda usada atualmente com o nome de z/VM, utilizado para suportar o uso eficiente do Linux nos servidores IBM zSeries. [1,2] Atualmente o mercado de solues de virtualizao disputado por diversas tecnologias e produtos, podemos ento distinguir entre virtualizao de servidor, memria e rede, porm essas formas frequentemente se confundem. De acordo com a finalidade da aplicao, a virtualizao de servidores e de desktops se separam, porm esses limites de separao so imprecisos. Outro critrio saber se a virtualizao ser efetuada atravs de hardware ou de software. Se a virtualizao for vinculada a uma determinada plataforma ou for independente de plataforma, podemos falar em virtualizao in-the-box e out-of-the box. [1,2]

1.1

Tcnicas de Virtualizao

As mquinas virtuais de sistema podem ser distinguidas de acordo com a localizao da camada de virtualizao. Se a camada de virtualizao estiver diretamente sobre a camada de hardware chamada de Tipo 1 ou Nativo, portanto um sistema operacional convidado roda em um nvel superior a hardware, exemplos: CP/CMS, Xen, VMWare ESX. Caso a camada de virtualizao estiver por cima de um sistema operacional, chamado de Tipo 2 ou Modell Hosted Virtualization, exemplos: VMWare-GSX, Qemu, MS Virtual PC, OpenVz, Vserver fazem parte desta categoria de mquinas virtuais. Existem dois tipos bsicos de virtualizao de mquinas, virtualizao completa e paravirtualizao: Caso toda a plataforma fsica (CPU, mmoria, I/O) for virtualizada, estamos falando de virtualizao completa (full-virtualization). Outro tipo de virtualizao requer alteraes nos hspedes, assim os mesmos sabem perfeitamente que rodam em um ambiente virtual. Essas alteraes so perfeitamente possveis de serem executadas em sistemas de cdigo aberto. Essa tcnica conhecida como paravirtualizao (paravirtualization), permite que mquinas virtuais especficas comuniquem-se diretamente com o hardware, ao invs de todas mquinas hspedes comunicarem-se com o hospedeiro. A para-virtualizao s possvel por meio da cooperao de hspede e hospedeiro na manipulao de operaes sensveis, um benefcio de desempenho considervel. O Xen e o sistema representante mais popular da paravirtualizao.[1,2] A figura 1 ilustra os 3 tipos bsicos de virtualizao: Virtualizao total, Para-virtualizao e Modell Hosted Virtualization.

Figura 1 Tipos de Virtualizao.[3] Nenhuma tcnica de execuo necessariamente a melhor, embora a virtualizao completa custe desempenho, abre a possibilidade de poder executar software de um mundo estranho. A paravirtualizao tem maior performance que mquinas completamente virtualizados e alta performance em I/O, mas requer para isso sistemas operacionais hspedes modificveis, praticamente eliminando o sistema operacional MS Windows. 2 Hypervisor Xen

O Xen foi originalmente desenvolvido pelo Grupo de Pesquisas de Sistemas no Laboratrio de Computao da Universidade de Cambridge, como parte do projeto XenoServers fundado pelo UK-EPSRC. Sua primeira apario foi no SOSP (Symposium on Operating System) em 2003 e a primeira verso (1.0) foi liberada em outubro do mesmo ano. [2] Foi fundada uma empresa denominada XenSource, Inc., com objetivo de gerir e promover

o desenvolvimento do projeto open source. Em outubro de 2007 a XenSource, Inc foi adquirida pela Citrix System por U$500 milhes.[5] Atualmente participam do desenvolvimento alm de membros da comunidade Xen, engenheiros pertencentes a grandes tais como: Citrix, SGI, Sun, IBM, HP, Intel, Dell, Oracle, Novell. O Xen licenciado com a licena GPL2 [6]. Existe a verso paga do Xen, desenvolvido pela Citrix chamada de XenServer. Podemos dizer que hypervisor Xen o corao do Xen, ele situa-se entre os domnios convidados e a plataforma fsica (hardware), alocando e controlando recursos, provendo proteo e isolamento. Ele define as interfaces virtuais que sero utilizadas pelos domnios convidados. Cada mquina virtual que roda no Xen chamada de domain. Quando o servidor Xen inicia, ele primeiro inicia o hypervisor, que responsvel em iniciar o domnio chamado Domain0 (dom0) que o sistema operacional hospedeiro, o dom0 o domnio privilegiado, tem acesso aos recursos de hardware e contm ferramentas para gerenciar os outros domnios, domnios sem privilgios so chamados de domainU (domU), de unprivileged. [7,8] A figura 2 ilustra o funcionamento do hypervisor do Xen, o hypervisor virtualiza a CPU e a memria. Enquanto o domnio privilegiado dom0, pode acessar diretamente o hardware, os domnios domU, sem privilgios, acessam aos dispositivos virtualizados pelo hypervisor. [1]

Figura 2 Hypervisor Xen [1] O Xen suporta dois tipos bsicos de virtualizao: para-virtualizado (PVM) e virtualizado total (HVM), para executar hspedes virtualizados total conjuntamente com paravirtualizados ser necessrio o processador possuir em sua arquitetura tecnologia AMD-V (Codename Pacifica) ou Intel-VT (Codename Vanderpool). Mquinas para-virtualizadas apresentam melhor desempenho do que mquinas em virtualizao total.[1,2] 2.1 Vantagens do Xen

Podemos relacionar como benefcios da virtualizao utilizando o Xen como monitor de mquina virtual (VMM) [2,4,8]: Consolidao de servidores: Colocar vrios servidores dentro de uma nica mquina, reduzindo custos, necessidades de espao fsico e facilitando a administrao;

Aumentar a utilizao dos servidores: Diminuir a ociosidade na utilizao de recursos computacionais em servidores de grande porte; Conteno de Falhas: isolamento de servios dedicados em mquinas virtuais diferentes; Manter nvel de servio (SLA): Recurso de Live migration na realocao de domnios Xen entre plataformas fsicas, para evitar a paralisao e manter acordos de nvel servio; Menor TCO: O Xen open-source alm do seu reconhecido desempenho e baixo custo para data center ou sistemas empresariais; Economia de Energia: Economizar energia facilmente notvel, exemplo: alimentar e refrigerar 100 servidores fsicos um custo bem mais alto se analisar 1 servidor fsico com 100 servidores virtuais; Reduo de domnios de coliso e domnios de broadcast:O trfego entre as mquinas virtuais e realizado dentro do hypervisor; Clonagem: Facilmente adicionar servidores por clonagem de um servidor virtual j existente; Computao em cluster: Permite a implantao de servidores em cluster; Reduo de custo de implantao de novos servidores. Podemos relacionar como desvantagens do Xen: A obrigatoriedade de utilizar um kernel modificado e um micro kernel para estabelecer a mquina real e as mquinas virtuais; A quantidade de passos para configurar e instalar uma mquina virtual. 2.2 Terminologias Xen

A infraestrutura de virtualizao Xen funciona de maneira diferente de outras solues de virtualizao, algumas definies e termos so necessrias quando para o entendimento do sistema Xen de virtualizao [8]: VM: Mquina virtual o ambiente virtual que executa um sistema operacional; VMM: Monitor de mquina virtual, software que possibilita executar mquinas virtuais; Domain: Termo utilizado para referir a uma instncia da mquina virtual; Dom0: Domnio privilegiado no sistema Xen; DomU:Todos os outros domnios no sistema Xen; Host: Sistema hospedeiro de mquina virtuais; Guest: Instncia de mquina virtual que iniciada no host; PVM: Mquina virtual para-virtualizada, domains Xen PVM somente pode ser iniciada utilizando sistemas operacionais modificados; HVM: Mquina virtual totalmente virtualizada, domains Xen pode iniciar sistemas operacionais sem modificao. O Xen oferece a capacidade de virtualizar Microsoft Windows utilizando esse recurso. 2.3 Tipos de Xen hypervisor

O Xen hypervisor est disponibilizado em diferentes opes, para diferentes propsitos [2]: 32 bit SMP: Pacote para arquitetura 32 bit com suporte a mltiplos ncleos ou sistemas com mais de um processador, espao de endereamento de memria limitada a 4GB, suporta somente domnios de 32 bits. 32 bit PAE36 SMP: Pacote para arquitetura 32 bit com suporte a processador de

mltiplos ncleos ou sistemas com mais de um processador, a extenso PAE permite enderear at 64GB de memria, suporta somente domnios de 32 bits. 64 bit SMP: Pacote para arquitetura 64 bit com suporte a processadores de mltiplos ncleos ou sistemas com mais de um processador, elimina todas as restries de endereamento de memria associadas ao endereamento de 32 bits, suporta domnios de 32 bits e 64 bits. O source code do Xen hypervisor est disponibilizado em: www.xen.org/download/ , os pacotes precisam ser compilados, contm o kernel alterado para funcionar no Xen, ferramenta utilizadas no dom0 para controlar o hypervisor e documentao do Xen. Alm da opo de instalar a partir do source code possivel instalar o Xen pr compilado. Atualmente principais distribuies Linux (Debian, OpenSuse, Red Hat, Fedora, CentOs) contm os pacotes necessrios para implantao do Xen Hypervisor por meio de gerenciadores de pacotes (aptitude, apt-get, yum, etc...). 2.4 Armazenamento dos domnios

O Xen possibilita a opo de usar uma variedade de mtodos de armazenamento para os domnios convidados, armazenamento local utilizando: arquivos de imagens, volumes lgicos (LVM) e parties comuns; Armazenamento remoto, como iSCSI, ATA-over-Ethernet (AoE), e Network File System (NFS). [7] Arquivos simples podem ser utilizados como dispositivos de bloco virtual, armazenando domnios Xen, est a maneira mais rpida de comear a usar o Xen. Utilizando o comando dd podemos criar o arquivo de armazenamento a ser utilizado. Embora os arquivos ser uma maneira simples e rpida de armazenar Vms, existem algumas desvantagens da utilizao de arquivos como Virtual Block Devices VBDs [8]: No so adequados para domnios virtuais que utilizam E/S intensivamente, o acesso ao dispositivo virtual extremamente lento quando o trabalho de E/S pesado. O Linux, por padro, suporta no mximo de oito arquivos VBDs utilizado por domnios Xen. Este nmero pode ser aumentado utilizando o parmetro de kernel max_loop. O LVM fornece um nvel de abstrao acima dos dispositivos de bloco real (exemplo, discos). Isto permite uma flexibilidade significativa na gesto de armazenamento, entre outras coisas, tornando mais fcil redimensionar parties em tempo real. O termo LVM geralmente refere-se a execuo especfica de uma gerenciador de volume lgico para o kernel do Linux. O uso de LVM para armazenamento de domnios Xen provavelmente a maneira ideal para configurar e administrar os domnios. Em testes realizados o desempenho utilizando LVM como Dispositivo de Bloco Virtual VBD prximo da utilizao de dispositivos fsicos diretos do tipo /dev/hdX. [4] O interessante recurso Live Migration do Xen, permite migrar uma mquina virtual de um servidor para outro, entretanto necessrio que o tipo de armazenamento do dispositivo de bloco virtual (VBD) seja remoto, sistemas de arquivos de rede ou dispositivos de armazenamento de rede (NAS, ou Network Attached Storage). O NFS pode ser utilizado como sistema de arquivos de rede. Uma soluo de baixo custo e excelente desempenho utilizar iSCSI [1]. 3 Migrao P2V fsico para virtual.

O processo de alcanar a consolidao de servidor virtualizado depende do ponto de partida, caso esteja projetando seu sistema desde o incio, a soluo implementar a virtualizao a partir do desenvolvimento. Caso o sistema j est fisicamente instalado, a

soluo migrar do ambiente fsico para virtual [9]. O termo migrao P2V vem do ingls, Physical to Virtual, o procedimento para converso e migrao de sistema operacional, aplicativos e dados instalados em um servidor fsico, para um mquina virtual convidada de uma plataforma de virtualizao. Existem diversos mtodos para executar a migrao P2V: manual, semi-automtico e automtico [9]: Mtodo P2V automtico: Mtodo de migrao que utiliza ferramentas que migra o servidor fsico pela rede, sem a assistncia do usurio. Exemplos de ferramentas: PlatSpin, AutoVirt, VizionCore, LeoStream. Mtodo P2V semi-automtico: Mtodo de migrao que utiliza ferramentas, que necessita da assistncia do usurio para migrar o servidor fsico. Exemplos de ferramentas: VMWare Converter, MS Virtual Server Migration Toolkit, Virt-P2V. Mtodo P2V manual: Mtodo P2V onde o usurio manualmente cria a mquina virtual no ambiente de virtualizao e copia todos os arquivos do sistema operacional, aplicativos e dados da mquina fsica. Algumas Ferramentas de migrao tambm podem solucionar diversos problemas em potencial trazidos pela incompatibilidade de hardware entre o servidor fsico e a mquina virtual, passando os drivers necessrios ao kernel do sistema operacional e inicializando os drivers corretamente durante a fase de inicializao do sistema. A maioria dessas ferramentas P2V so proprietrias e fazem mais do que preciso para migrao de uma nica mquina [9]. Especificamente para o XenServer a Citrix desenvolveu a ferramenta proprietria XenConvert, a ferramenta permite a migrao P2V semi-automtica, permite migrao P2V de qualquer sistema operacional suportado pelo XenServer (Windows, Linux, etc). A ferramenta livre, porm ainda experimental, Virt-P2V [12] promissora, funciona como um live CD que realiza a migrao P2V via rede, incluindo a instalao da VM na mquina hospedeira, o requisito para migrao a plataforma de virtualizao suportar a API de virtualizao Libvirt entre as plataformas que suportam esto Xen, KVM, Qemu [13]. Existe diversos mtodos de se fazer migrao P2V manualmente, um desse mtodos utiliza ferramentas open source de clonagem tais como Mondo Rescue, Partimage, Clonezilla Livre, com algumas configuraes podemos virtualizar em modo paravirtualizado ou totalmente virtualizado conforme for o caso, esse mtodo suporta a migrao P2V de servidores MS Windows e Linux [9,14]. O mtodo mais interessante para migrar servidores fsicos Linux para virtuais, utiliza das ferramentas e comandos do prprio Linux para efetuar a migrao P2V manual. Devido a grande variedade de comandos e ferramentas disponveis no Linux existem muitos mtodos descritos, tais como: Utilizando o comando netcat - nc conjuntamente com o utilitrio dd [15,16] e efetuar a clonagem via rede. Utilizando o ssh com o comando tar [17]. Utilizando a ferramenta de cpia rsync [18,19,20]. Em todos esses mtodos descritos caso o sistema migrado for Linux, necessrio vrios ajustes para que o sistema operacional possa se acomodar bem em mquina virtual paravirtualizada ou totalmente virtualizada. 4 Projeto de migrao

O Servio Social Autnomo PARANACIDADE adquiriu novos servidores do modelo IBM server x3650, havia a necessidade de colocar em produo os novos servidores visto que estaes de trabalho e servidores legados faziam o papel de servidores em produo. No parque de servidores da organizao a poltica de software preferencial para utilizao de

software livre, todos os servidores utilizam como sistema operacional Debian Linux. Para a migrao dos servidores legados existia duas possibilidades: migrar para mquinas fsicas ou migrar para mquinas virtuais. Migrar para mquinas fsicas o sistema operacional ocupa toda a plataforma fsica e no utiliza com eficincia todos os recursos computacionais do servidor (E/S, memria, CPU), cada servidor fsico legado necessita de um novo servidor para permitir a migrao, fazendo necessrio a aquisio de um maior nmero de servidores, gerando custos exagerados. A outra soluo possvel, migrar para mquinas virtuais atravs de alguma plataforma de virtualizao, possibilitaria melhor utilizao dos recursos dos servidores, reduzindo a subutilizao, compartilhando e alocando os recursos (memria, CPU, disco) de forma customizada, oferecendo tambm segurana e performance. Rapidamente vemos que a migrao utilizando mquinas virtuais a melhor soluo, sendo possvel multiplicar a quantidade de servidores dedicados por plataforma fsica. Dentre as solues de virtualizao disponveis a plataforma escolhida foi o Xen, escolha foi pelo Xen ser de cdigo aberto GPL 2, estar disponvel em praticamente todas as atuais distribuies Linux (Debian, Fedora, CentOs, Red Hat, OpenSuse...etc), reconhecido alto desempenho em mquinas virtuais do tipo paravirtualizadas. 4.1 Planejamento da migrao

O estudo de caso em questo contempla o projeto de migrao realizado no Paranacidade, o caso apresentado ser migrao P2V de 3 servidores fsicos para 3 mquinas virtuais. O servidor de nome uru onde est instalado o hypervisor Xen, este servidor da marca/modelo IBM System x3650. As caractersticas principais de hardware do servidor uru: 2 processadores Intel Xeon E5320 de 4 ncleos cada um, 8 GB de memria principal e 2 discos SAS de 300GB cada, suporte a RAID. O IBM System x3650 possui os recursos da tecnologia de virtualizao IntelVT, necessrios para o Xen virtualizao total (full-virtualization). A situao inicial dos servidores fsicos em produo antes da migrao P2V era utilizao de servidores legados e estaes de trabalhos, servidores migrados esto descritos abaixo: Servidor beijaflor: Genrico, processador Pentium III 1 GHz, disco IDE de 4GB, 256 MB de memria. Debian Etch, servios DNS master do domnio e NTP. Servidor tucano: Genrico, processador Pentium IV 1,8 GHz, disco IDE 40GB, 1 GB de memria. Debian Etch, servio WEB (Apache e Postgresql) de projetos. Servidor colibri: Compaq Proliant ML370 server, processador Pentium III Copermine 1 Ghz, disco SCSI de 40 GB, 512 MB de memria. Debian Etch, servio WEB (Apache e Mysql), portal ambiente XOOPS. Aproximadamente 80.000 horas em produo. A condio dos servidores migrados no era a ideal para servidores em produo, porm apenas o servidor colibri apresentava problemas de hardware, blocos defeituosos no disco rgido ocorrendo erros de leitura e escrita. Migrar os servidores fsicos para mquinas virtuais foi a melhor soluo encontrada, pois utilizar um novo servidor para cada mquina migrada subutilizaria recursos computacionais, com a virtualizao h diversos benefcios, consolidao de servidores, melhor aproveitamento de recursos, economia de energia, reduo de custos operacionais, dentre outros j citados.

4.2

Instalando o Xen

Existe diversas maneiras de instalar o Xen em servidores, o primeiro passo definir qual distribuio Linux instalar para ser a base do hospedeiro, em nosso caso o data-center padronizado com a utilizao do sistema operacional Debian Linux. O servidor uru tem 2 discos de 300GB optou-se por utilizar os discos em RAID nvel 1, aumentando a segurana dos dados, o particionamento foi definido da seguinte forma: / - Sistema de arquivos raiz. - 15GB; Swap rea de troca - 1 GB; LVM Logical Volume Manager - 280 GB, partio LVM onde so criados os discos das mquinas virtuais. A verso instalada do sistema operacional no servidor uru, foi a verso stable disponvel, Debian Lenny arquitetura i386, em servidores Xen aconselhado que no sejam instalados servios extras desnecessrios ( WEB, DHCP, SAMBA, etc ), podendo comprometer o desempenho. No momento da instalao foi selecionado somente o conjunto de pacotes Sistema Bsico. Alguns pacotes so necessrios aps a instalao bsica, atravs do gerenciador de pacotes aptitude, podemos instalar facilmente dependncias e os pacotes. Com o comando # aptitude install rsync ssh posftix ntp, instalamos pacotes teis. ssh: servidor e cliente de ssh; Rsync: aplicativo que sincroniza arquivos e diretrios remotos; postfix: Servidor de e-mail. NTP: Servio de sincronizao de relgio entre servidores, utilizado para manter a hora correta no servidor. Para fins de monitoramento bsico do servidor uru, instalar os pacotes logwatch, fcheck e cron-apt. Estes aplicativos podem enviar e-mail para uma determinada conta habilitando previamente o MTA postfix: # aptitude install logwatch fcheck cron-apt Para instalar o Xen System em servidores Debian Linux existe duas possibilidades relatadas [8, 21]; Compilar e instalar os fonte obtidos do site do projeto Xen http://www.xen.org/downloads. Outra possibilidade instalar atravs do formato de pacotes da distribuio, no caso do Debian formato .deb, instalar usando pacotes da distro apresenta inmeras vantagens, so pacotes homologados e altamente testados pela comunidade e desenvolvedores, podem ser gerenciados facilmente atravs do aptitude, apt-get, etc , no precisam do trabalhoso e demorado processo de compilao dos fontes, porm frequentemente os fontes obtidos do site do projeto Xen so verses mais recentes. Pela facilidade e comodidade no gerenciamento de pacotes utilizar os pacotes da distribuio Linux a melhor soluo em casos normais. No Debian Lenny podemos instalar o Xen System e todas suas dependncias com apenas um comando: # aptitude install xen-linux-system-2.6.26-2-xen-686. Este metapacote instala o Xen hypervisor de 32 bits PAE. Para instalar o Xen hypervisor 64 bits, pode-se instalar o sistema operacional Debian arquitetura amd64 ou obter o pacote xen-hypervisor-amd64 e instalar manualmente: dpkg -x xen-hypervisor-3.2-1-amd64_3.2.1-2_amd64.deb xen64 cp xen64/boot/xen-3.2-1-amd64.gz /boot Utilizando o aptitude no possvel ter um hypervisor 64 e dom0 de 32 bits ou tudo 64 bits ou 32 bits, Desta maneira manual temos o hypervisor 64 bits e a dom0 de 32 bits, esse arranjo utilizado no Xen Live CD [22]. Aps necessrio configurar o gerenciador de boot

grub para utilizar o microkernel Xen de 64 bits e o kernel 32 bits na dom0, conveniente tambm limitar a memria da dom0 (parmetro dom0_mem) tcnica conhecida como memory balloon. Exemplo de entrada no menu grub: title Xen Hypervisor 3.2-1 64 bits / Debian GNU/Linux, kernel 2.6.26-2-xen-686 kernel /xen-3.2-1-amd64.gz dom0_mem=512M module /vmlinuz-2.6.26-2-xen-686 root=/dev/mapper/vg01--dom0--root ro console=tty0 module /initrd.img-2.6.26-2-xen-686 quiet O arquivo de configurao do Xen fica localizado em /etc/xen/xend-config.sxp, existe diversos parmetros para torna a virtualizao possvel, segue abaixo alguns parmetros bsicos configurados[7]: network-script : Determina o script que ser usado para criar o ambiente de rede; vif-script: Especifica a interface virtual, o script localizado em /etc/xen/script; mim-mem: Define o tamanho mnimo de memria reservado para a Dom0, padro 196MB; xend-unix-server: Habilita o gerenciamento do servidor Xen via Unix Domain Socket Server; xend-http-server: Habilita o gerenciamento do servidor Xen via http stream packet; xend-port: Define a porta utilizada para gerenciar o servidor via http, padro porta 8000; xend-relocation-server: Habilita o recurso de live migration; xend-relocation-port: Defina a porta utilizada para o live migration, padro porta 8002. 4.2.1 Gerenciando os domnios Xen

Para gerenciar as mquinas virtuais convidadas do servidor uru, utilizamos a ferramenta linha de comando xm Xen Management User Interface, essa ferramenta instalada e acessada na domain0, xm se comunica diretamente com o daemon do Xen (xend), atravs do comando xm podemos criar, ativar, desligar e alterar domnios virtuais. Os principais subcomandos para gerenciar domnios virtuais atravs do xm so [7]: create: Cria um domnio virtual baseado num arquivo de configurao; destroy: Encerra um domnio imediatamente; list: Lista e prov informaes dos domnios; reboot: Reinicia o domnio; shutdown: desliga o domnio. Para o gerenciamento remoto das mquinas virtuais sem precisar estar na console do servidor uru, utilizamos a biblioteca desenvolvida C pela Red Hat, Libvirt, para instalar a libvirt em servidores Debian, utilizamos o seguinte comando: #aptitude install libvirt-bin, atravs da biblioteca libvirt podemos acessar remotamente o servidor uru, utilizando a ferramenta linha de comando virsh ou utilizando a ferramenta grfica virt-manager, nesse caso via tnel ssh seguro (figura 3). Existe diversas outras ferramentas de gerenciamento de domnios Xen e algumas tambm so grficas, porm foram testadas, exemplos de outras ferramentas so: HyperVM (Baseado WEB), Ganeti, MLN, Enomalism, ConVirt.

Figura 3 Ferramenta virt-manager acessando servidor URU 4.2.2 Segurana no domnio privilegiado - Domain0

Quando administramos uma mquina fsica, umas das tarefas mais importantes proteger o sistema, esta tarefa pode assumir diversas formas, incluindo a aplicao dos patches de segurana mais recentes, fechar todas as portas desnecessrias, auditar qualquer comportamento anormal ou suspeito. Essas atividades so importantes tambm quando se utiliza mquinas virtuais Xen. Alm disso, o Xen introduz novas oportunidades e desafios em segurana, o Xen introduz uma camada abaixo das mquinas virtuais, qualquer comprometimento do prprio Xen ou do domnio privilegiado Domain0 pode causar problemas em todas as mquinas virtuais. fundamental procurar isolar servios em mquinas virtuais diferentes, podemos tambm criar segmentos de redes distintos [7]. Se o domnio privilegiado dom0 estiver comprometido, todos os domnios domUs tambm esto, por esse motivo vital que o sistema operacional dom0 esteja bem protegido contra ataques. Segundo [7] remover softwares e servios desnecessrios a maneira mais simples de proteger um domain0, pois qualquer servio em execuo representa um ponto de entrada para um possvel ataque, importante limitar acesso de usurios na dom0, somente permitir o login do usurio administrador, seguimos estas premissas na instalao e configurao do servidor uru. A estrutura de rede no Xen flexvel, possvel monitorar toda atividade de rede das mquinas virtuais com facilidade. Podemos utilizar um monitor de trfego de rede como o Snort e bloquear todos os pacotes de entrada para o domain0 utilizando um firewall como o iptables netfilter para domain0s baseados em Linux ou ipf para baseados em UNIX [7]. Optamos por utilizar regras de iptables na dom0 do servidor uru. Um script shell executado ao final do processo de boot do servidor. Apenas permitimos o acesso ao servio ssh na dom0 necessrio para o gerenciamento remoto do servidor, um projeto futuro podemos implementar regras para os domnios convidados domUs. Em linhas gerais o script habilita as seguintes regras: #iptables -a input -s 0.0.0.0 -d uru.paranacidade.org.br -p tcp --dport 22 -j accept; #iptables -a input -d uru.paranacidade.org.br -j reject. 4.3 Migrando P2V

Existem diversas ferramentas e procedimentos para migrao P2V, algumas ferramentas so proprietrias e h relatos que funcionam muito bem, porm nosso objetivo sempre que possvel utilizar de ferramentas Open-Source, das ferramentas testadas a

ferramenta Virt-P2V a mais promissora, entretanto a ferramenta ainda experimental e esta em desenvolvimento. De todos os mtodos pesquisados e considerando o cenrio: servidores fsicos Debian Linux, mquina virtual do tipo paravirtualizada e ambiente de virtualizao Xen utilizando como base Debian Linux, o mtodo que consideramos mais adequado descrevemos abaixo. O mtodo P2V manual e utiliza o aplicativo rsync [18,19,20] para efetuar a cpia dos dados do servidor fsico para o disco da mquina virtual, alguns ajustes nos arquivos de configurao precisam ser feitos para mquina fsica acomodar bem na mquina virtual, utilizaremos como exemplo a migrao P2V do servidor fsico beijaflor. Primeiramente criamos os volumes lgicos (LVM) que serviro de discos virtual. O esquema de particionamento pode variar ou ser semelhante ao do servidor fsico, criamos 2 volumes lgicos, 1GB para partio de swap e 5GB para partio root com sistema de arquivos ext3: #lvcreate -L1G -n beijaflor.swap vg01 #lvcreate -L5G -n beijaflor.root vg01 #mkfs.ext3 /dev/vg01/beijaflor.root #mkswap /dev/vg01/beijaflor.swap Cada mquina virtual Xen utiliza um arquivo de configurao, este arquivo deve ficar localizado na dom0 em /etc/xen/auto/, criamos o arquivo beijaflor-vm.cfg: #Arquivo de configurao Xen mquina virtual beijaflor-vm import commands krn_vers = commands.getoutput('uname -r') name = 'beijaflor-vm' builder = 'linux' #builder PVM se a VM for HVM builder ='HVM' #vfb e extra configura console, habilita acesso VNC vfb = [ 'type=vnc,vncdisplay=1' ] extra = 'console=hvc0 clocksource=jiffies guestname=beijaflor-vm' kernel = '/boot/vmlinuz-' + krn_vers #Define o kernel utilizado pela VM ramdisk = '/boot/initrd.img-' + krn_vers memory = '512' # Quantidade de mmoria em megabytes vcpus =1 # Nmero de CPUs # Define os discos virtuais e a partio root root = '/dev/xvda1 ro' disk = [ 'phy:/dev/vg01/beijaflor.root,xvda1,w', \ 'phy:/dev/vg01/beijaflor.swap,xvda2,w'] # Configura o ambiente de rede vif = [ 'bridge=xenbr0' ] A prximo etapa copiar todos os arquivos e diretrios do servidor fsico beijaflor, para que no haja inconsistncia dos dados copiados recomendado parar os servios do servidor migrado, especialmente os servios que utilizem bases de dados como openldap, mysql, pgsql, etc, deixando somente os servios bsicos para a copia remota. No caso do servidor beijaflor paramos os processos ntpd - NTP e bind9 - DNS. Alguns diretrios no precisam ser copiados, em especial os /sys e /proc. Na console da dom0 executamos o seguinte comando: #rsync -vaH -e 'ssh' --numeric-ids --stats --progress --exclude "/mnt/*" --exclude "/proc/*" --exclude "/sys/*" --exclude "/tmp/*" --exclude "/var/tmp/*" --exclude "/var/ run/*.pid" --exclude "/var/run/dbus/system_bus_socket" beijaflor.paranacidade.org.br:/ /mnt/beijaflor.root/

preciso ajustar os pontos de montagens da mquina virtual no arquivo /mnt/beijaflor.root/etc/fstab e incluir a console padro hvc0 nos arquivos /etc/inittab e /etc/securetty. Utilizando esse mtodo no preciso instalar gerenciador de boot (grub, lilo, etc) no disco root da mquina virtual, porm possvel utilizar o script pygrub para tal finalidade. Utilizamos a chamada do kernel Linux da dom0 fora da mquina virtual, porm necessrio copiar os mdulos do kernel da dom0 para dentro da mquina virtual. #cp -a /lib/modules/$(uname -r) /mnt/beijaflor.root/lib/modules/ Verificamos e revisamos todas as configuraes antes de desligar o servidor fsico, feito isso conclumos a migrao P2V inicializando a mquina virtual criada, utilizando o aplicativo xm: #xm create -c /etc/xen/auto/beijaflor-vm.cfg 4.3.1 Domnios virtuais - DomUs

A tabela abaixo mostra os domUs criados no servidor uru utilizando o procedimento P2V descrito. Na criao das mquinas virtuais somente os recursos mnimos necessrios foram alocados. DomUs Colibri-vm Tucano-vm 4.4 S.O. Debian Etch Debian Lenny Servios DNS, Ntp Web Web, Pgsql Disco LVM 8GB LVM - 10G LVM - 15G RAM 512MB 2048MB 1024MB Processador 1 2 2

Beijaflor-vm Debian Lenny

Problemas encontrados

Diagnosticamos alguns problemas em migrao P2V, aps a migrao as mquinas virtuais domUs congelavam, se a mquina hospedeira fosse reiniciada a quente, o kernel gerava a log de erro com a seguinte expresso: 'clocksource/0: Time went backwards', esse problema foi resolvido adicionado no arquivo de configurao da mquina virtual a flag extra= clocksource=jiffies [23]. Outro problema constatado aps a migrao P2V, foi a inacessibilidade ao servio SSH das mquinas virtuais, pesquisando sobre o problema, constatamos que o pacote udev no estava instalado nas mquinas virtuais [24]. O procedimento que utilizamos no pode ser realizado em sistemas operacionais muito antigos, visto que no existe kernel Linux modificado Xen para Linux antigos (ex: Debian Potato, Red Hat 6.2, etc) impossibilitando de utilizar a paravirtualizao, somente sendo possvel a migrao para mquinas full-virtualizadas. 5 Concluso

As migraes P2V realizada no data-center do Servio Social Autnomo Paranacidade foram bem sucedidas, os j citados benefcios da virtualizao de servidores utilizando o Xen foram alcanados, consideramos que a consolidao de servidores de vital importncia para organizao, pois maximiza a utilizao dos recursos computacionais existentes e conseqentemente diminui custos. Softwares de virtualizao 100% livre integrados a sistemas operacionais livres, como o caso do Xen em relao s distribuies Linux, tornam o futuro pertencentes a

virtualizao [2]. Constatamos que o desempenho das mquinas virtuais superior aos antigos servidores fsicos, at o momento as mquinas virtuais em produo no apresentaram sinais de falta de recurso (memria, processador), caso ocorra podemos alocar os recursos necessrios utilizando as interfaces de gerenciamento (CLI ou GUI). Como projetos futuros podemos: implementar regras de firewall na dom0 para cada domU, est sendo estudada a aquisio de um Storage Area Network - SAN, possibilitando assim utilizar do recurso Live Migration, implantar Controle de Acesso Obrigatrio ( MAC Mandatory Access Control) das permisses de acesso de cada mquina virtual, utilizando a biblioteca Svirt [25], ainda experimental. Bibliografia [1] GARLOFF, KURT. Para-virtualizao com o Xen 3. Linux MAGAZINE. v..24, p. 3843, outubro de 2006. [2] SIQUEIRA, LUCIANO; BRENDEL, JENS-CHRISTOPH. Virtualizao. So Paulo, Linux Pocket PRO. ed. 04. 2007. [3] HARA, FBIO. O que virtualizao ?. Acessado em outrubro de 2009. Disponvel em: http://superdownloads.uol.com.br/materias/que-virtualizacao-parte-1.html [4] IBRAHIM, HORCIO. Virtualizao de Servidores com Xen. Braslia: SERPRO, 2008. [5] Xen Citrix Acquisition. Acessado em outubro de http://www.xensource.com/about/Pages/CitrixAcquisition.aspx [6] Xen Hypervisor. Acessado em http://www.xen.org/products/xenhyp.html outubro de 2009. 2009. Disponvel Disponvel em: em:

[7]MATTEWS, JEANNA; DOW, ELIS; DESHANE, TODD, HU WENJIN; ET AL. Running Xen: A Hands-On Guide to the Art of Virtualization. Editora Prentice Hall. Abril de 2008. [8]WILLIANS, DAVID. Virtualization with Xen. Editora Syngress. 2008. [9] LI, TING. Migrando para um ambiente Linux Virtual com Clonezilla. Acessado em outubro de 2009. Disponvel em: http://www.ibm.com/developerworks/br/library/l-clonezilla/ [10]Wikipdia. Acessado em outubro http://en.wikipedia.org/wiki/Physical-to-Virtual de 2009. 2009. Disponvel Disponvel em: em:

[11]Xen Convert. Acessado em outubro de http://www.citrix.com/English/ss/downloads/details.asp? downloadId=1857892&productId=683148#top

[12]Virt-P2V. Acessado em outubro de 2009. Disponvel em: http://et.redhat.com/~rjones/virtp2v/ [13]LibVirt Virtualization API. em:http://libvirt.org/index.html Acesado em outubro de 2009. Disponvel

[14]Mondo Rescue Home Page. Acessado em outubro de 2009. Disponvel em: http://www.mondorescue.org/ [15] Wonders of dd and netcat :: Cloning Operating Systems. Acessado em outubro de 2009. Disponvel em :http://www.rajeevnet.com/hacks_hints/os_clone/os_cloning.html [16]Linux P2V. Acessado em outubro em:http://conshell.net/wiki/index.php/Linux_P2V de 2009. Disponvel

[17]LARCHERI, PAOLO. Xen P2V: how to import a Linux Physical Machine as a Xen DomU. Acesado em outubro de 2009. Disponvel em:http://tuttodebian.blogspot.com/2008/05/xen-p2v-how-to-import-linux-physical.html [18]Xen-br wiki. Migrando um servidor fsico Linux para Virtual (p2v). Acesado em outubro de 2009. Disponvel em:http://wiki.xen-br.org/index.php?title=P2v-howto [19]XenSource. Xen Manual P2V Process. Acessado em outubro de 2009. Disponvel em: http://wiki.xensource.com/xenwiki/XenManualPtoVProcess [20]ORMIERES, RICARDO. Migrao P2V de RHEL4 com RedHat/Xen. Acessado em outubro de 2009. Disponvel em: http://blog.seatecnologia.com.br/2009/06/10/migrauao-p2vde-rhel4-com-redhat-xen [21] VON HAGEN, WILLIAM. Professional Xen Virtualization. Editora Wiley, 2008. [22] MARTINS, THIAGO. LiveCd Xen. Acessado em outubro de 2009. Disponvel em: http:// wiki.xensource.com/xenwiki/LiveCD [23] Debian Wiki. Xen HowTo. Acessado em outubro de 2009. Disponvel em:http://wiki.debian.org/Xen#A.27clocksource.2BAC8-0.3ATimewentbackwards.27 [24]Virtualization in Debian Etch. Acessado em outubro de 2009. Disponvel em: http://www.punknix.com/virtualization_uml [25]SELinux Project, Svirt. Acessado http://selinuxproject.org/page/SVirt em outubro de 2009. Disponvel em:

Potrebbero piacerti anche