quinta-feira, 7 de maio de 2009

TI Virtualização: um relato sobre as escolhas entre vmware, microsoft e xen

Objetivo: este relato visa apresentar informações que foram levantadas para um projeto de virtualização de infra-estrutura de servidores, onde existia como cenário legado um parque de servidores “montados”, executando o vmware Workstation 6, servindo como infra-estrutura de TI para todos os servidores de uma empresa. A proposta consistia em diminuir os custos com a legalização dos softwares de virtualização, o vmware, e aumentar a capacidade de escalabilidade do parque em si. Para isso, o projeto inicial consistia em migrar algumas máquinas virtuais vmware para um novo servidor Dell PowerEdge 2900, com 16Gb de RAM, 564Gb em 04 discos SAS com RAID 10, e um outro sistema de virtualização. Inicialmente cogitou-se a possibilidade de legalização da infra-estrutura adotando para isso o gratuito Microsoft Virtual PC, porém após pesquisas realizadas na Internet descobriu-se a recém aceitação da comunidade pelo Microsoft Hyper-V, e também se destacando como solução opensource o Xen, para ambiente Linux. Foram realizados testes com os respectivos softwares e pesquisas de comparação entre eles, sendo apresentados esses resultados neste trabalho, como forma de nortear os demais colegas da área que também precisem acessar as mesmas informações, porém em menor tempo do que nós levamos.

O AMBIENTE LEGADO

Inicialmente, por volta de 2004, optamos por virtualizar alguns servidores em função das facilidades de reconfiguração dos ambientes de teste. Era um momento de incerteza, onde não sabíamos se nosso firewall seria baseado na plataforma ISA Server, da Microsoft, ou Iptables + Squid, do Linux, entre outras possibilidades proprietárias menos conhecidas, como o Kerio Winrouter Firewall.

Nesse momento o vmware Workstation se mostrou uma solução interessante, pois podíamos com uma única máquina física levantar as três máquinas virtuais, simultaneamente, para testarmos em nossa rede. Essa experiência nos despertou para novos testes em outros servidores, como os controladores de domínio, os servidores web e os servidores de arquivos.
Em meados de 2006 os resultados dos testes iniciados em 2004 expressaram-se na substituição total da fazenda de servidores. Dos seis servidores físicos, estimados para compras, foram adquiridos apenas dois, e nestes dois executados três servidores virtuais em cada. Uma comparação do custo benefício deste projeto, à luz da época, mostrou-se insignificativo, visto que o custo dos dois servidores aproximou-se do custo dos seis servidores de menor porte, inicialmente estimados para compra. A vantagem visualizada na época, para a virtualização da infra-estrutura de servidores de TI, apresentou-se na forma de contingência, backup e tempo de start para um novo servidor.

Em termos de contingência a virtualização apresentou um cenário completamente flexível, um servidor virtual, que por ventura apresentasse qualquer tipo de problema, como: corrompimento de arquivos, danos ao hardware do servidor físico, infecção por vírus, podiam ser facilmente e rapidamente substituídos por cópias deles próprios. Como exemplo, ou apagávamos a vm danificada e substituíamos por uma cópia “limpa” (na mesma máquina física) ou, em outra máquina física qualquer como uma estação de trabalho do suporte técnico, instalávamos o vmware Workstation e conseguíamos levantar a cópia “limpa” do servidor virtual temporariamente nessa estação. Aqui vale uma ressalva para explicar que nossa operação diária não era classificada como missão-crítica, onde poderíamos, por conveniência ou necessidade, ausentar as operações dos servidores por algumas horas, sem com isso gerar prejuízos para a empresa (de imagem ou financeiro), e dessa forma podíamos confortavelmente, em momentos de panes, nos limitar a copiar a vm em produção para uma segunda estação de trabalho.

Em termos de backup a virtualização apresentou uma nova realidade para a empresa, onde passamos a realizar o backup da vm ao invés do simples backup dos dados. Como exemplo, antes da virtualização, guardávamos o backup dos bancos de dados em unidades de DVD-rom, porém o processo de recuperação desses dados, em caso de panes com o servidor, era extremamente demorado, em função de: primeiro ser necessário reinstalar e reconfigurar o servidor Windows, instalar e configurar o servidor de banco de dados, e finalmente restaurar o backup no novo servidor de banco. Porém ainda havendo sérias desconfianças de que algo ainda poderia estar faltando, em relação as configurações do Windows ou do próprio banco de dados. Em suma, era despendido um tempo de recuperação médio de 12h, contando com um esforço-homem muito grande (a pressão pelo prazo de recuperação, as incertezas de atualizações, entre outras sensações desagradáveis do momento de pane). Com a nova proposta da virtualização o backup passou a ser feito do diretório de residência da máquina virtual, como por exemplo “c:\vm”. Backup este realizado de forma automática, via agendador de tarefas, que através de um simples comando de xcopy copiava todo o conteúdo da pasta para um segundo HD, no mesmo servidor. Este HD, cuja existência era apenas para manter o backup das vms, passava a maior parte do tempo desligado, através do sistema de consumo de energia do computador, a fim de evitar danos por interrupção de força elétrica e ampliação do tempo de vida útil da peça. Porém, para aumentar ainda mais a confiança na recuperação, uma cópia desse HD de Backup era enviado, também automaticamente via agendador de tarefas, para uma estação de trabalho na rede. Com este esquema, aparentemente mirabolante e oneroso, conseguíamos recuperar não apenas os dados, mas o sistema Windows como um todo, com todas as suas configurações, atualizações e peculiaridades de configuração. Em termos de tempo de recuperação, passamos a operar com um tempo médio de recuperação na ordem dos 20 minutos, tempo suficiente para inicializar uma cópia “limpa” da máquina virtual. Com essa solução, projetos envolvendo unidades de fitas dat, servidores de storage e cluster de servidores, ficaram por longos tempos engavetados.

Em termos de tempo de start a virtualização mostrou ser extremamente veloz. Deixamos uma máquina virtual servidora, com o sistema atualizado e pré-configurado, de forma genérica, como um template. Toda vez que se fazia necessário inicializar um novo servidor na rede, como um servidor de terminal, um novo dns, um novo dhcp, ou mesmo uma máquina de teste, bastava copiar a vm-genérica para um novo nome e iniciar a nova vm. Com isso a velocidade nos experimentos, testes e laboratórios passaram a ser muito mais rápidos e confiáveis, pois tínhamos a certeza de um ambiente devidamente controlado.
Essas vantagens, geralmente não encontradas nos fóruns e FAQs da Internet, justificaram quatro anos de infra-estrutura virtualizada na TI. Bons quatro anos pra dizer a verdade. Porém uma expansão estratégica nos negócios da empresa demandariam um novo cenário.


O NOVO CENÁRIO

Com 200 funcionários e quase 500 computadores a instituição passara para uma nova realidade, inexata e imprevisível, em função da compra de novas unidades ao longo do Brasil. Diretoria e gerências não sabiam com precisão os impactos na estrutura de TI que a fusão com as novas unidades iria causar no negócio. A ordem era se preparar. Comprar um novo maquinário que suportasse uma demanda inicial mínima e que com o tempo pudesse ser escalonada com a aquisição de novos módulos.

O calculo realizado para atender esse novo cenário foi uma estimativa no crescimento de conexões simultâneas ao banco de dados, conexões simultâneas no acesso ao servidor web e conexões simultâneas no servidor de terminal remoto. Previmos um crescimento de 15 para 50 conexões simultâneas ao banco de dados, de 5 para 100 conexões simultâneas ao servidor web, e de 15 para 40 conexões simultâneas no servidor de terminal remoto. Entretanto esses números não eram exatos, nem sabíamos se a margem de erro seria muito grande para mais ou para menos, dessa forma resolvemos continuar apostando na virtualização como forma de nos prevenirmos contra esse cenário.

A idéia consistia em ampliar a escalabilidade dos atuais servidores, até então já consumindo o máximo que suas arquiteturas de máquinas “montadas” podiam suportar, como por exemplo o limite de 4Gb de memória RAM, o limite de 04 discos SATA e a inexistências de dispositivos seguros, como os de tecnologia hotswaps. A solução foi partir para uma máquina de grife. Entre as três candidatas orçadas: Dell, HP e IBM, por questões de custo-benefício, a escolha ficou com a Dell. O PowerEdge 2900 foi encomendado com sua configuração: 16Gb RAM, 564Gb (sendo 04 HDs SAS em RAID 10), duas fontes redundantes, 02 processadores quad-cores.
Em posse dessa nova máquina o próximo passo consistia na escolha do sistema operacional e na solução de virtualização a ser adotada. Como premícia, não continuaríamos mais com a solução do vmware Workstation por acreditar que suas limitações e valores de licenciamento não poderiam mais ser aproveitados para o novo cenário que se instalava. Começamos então a pesquisar as soluções possíveis.




AS SOLUÇÕES DE VIRTUALIZAÇÃO

O primeiro estudo levantado foi sobre as soluções da própria vmware. Pesquisando em seu site, que por sua vez não foi nada fácil (péssima usabilidade), pudemos observar uma divisão de produtos, sendo uma linha destinada para servidores e datacenters e outra linha destinada para desktops.Como nosso foco estava na linha para servidores então nos aprofundamos nessa divisão. Clicando no botão “View All”, aparece uma nova subdivisão dos produtos, demoramos um certo tempo até compreendermos o significado dessas sub-divisões, sendo necessário realizar diversas pesquisas em blogs e sites na Internet. Em resumo, o que podemos falar sobre essas subdivisões é o seguinte:

Server & Datacenter Products, são os softwares de virtualização em si. O vSphere é a mais nova produção, particularmente ainda não experimentamos para poder falar maiores detalhes, mas tem como proposta a criação de computação em nuvem (cloud operating system), que seria mais ou menos na criação de estações de trabalhos virtuais.

Infrastructure 3, é a solução comercial para datacenters, provê todos os recursos avançados da virtualização. Muito caro para nosso projeto.

Server é a solução freeware, equivalente ao Workstation. Instala-se sobre um sistema operacional e permite virtualizar outros sistemas operacionais. É divulgado como uma estratégia comercial da vmware para que as empresas degustem e sintam vontade em ter o Intrastructure. Para nós, substitui perfeitamente o Workstation, mas apresenta as mesmas limitações do mesmo.

ESXi, também outra solução freeware. Entretanto essa solução é um sistema operacional em si, diferente do Server. Ele aproveita o que há de melhor da tecnologia de virtualização. Entretanto, é necessário adquirir a parte o sistema de gerenciamento, que sem ele não é possível fazer praticamente nada. Este sistema de gerenciamento está avaliado em torno dos R$55.000,00. Seria a solução procurada por nós, se não fosse o custo da console de administração.

A subdivisão de Virtualization Management Products equivale aos softwares de gerenciamento, backup, recuperação, entre outros. São as ferramentas necessárias para administrar o Infrastructure e o ESXi. Em função de seus custos interrompemos as pesquisas nesse momento e procuramos alternativas.


A segunda solução pesquisa, cuja referência nos foi dado pelo Google ao pesquisarmos por “alternativas ao vmware ESXi” apareceu o Xen. O Xen nos apresentou a um novo mundo da virtualização que ainda não estávamos inseridos. Descobrimos que o Xen introduziu um novo conceito, denominado paravirtualização, que corresponde a ter um novo sistema operacional, modificado em seu kernel, de forma a alcançar taxas extremas de alta performance. Em oposição as tecnologias de virtualização que necessitam de um hospedeiro para ser instalado.

O Xen é um hypervisor (tecnologia de virtualização) que suporta a chamada virtualização completa (equivalente a dizer que permite simular outros sistemas operacionais sem modificá-los), baseado nas novas tecnologias Intel VT e AMD-V. Gratuito e opensource atraiu bastante nossas atenções. Inicialmente visualizamos o Xen como uma solução ao ESXi, ambos sendo um sistema operacional.

Porém, ao testarmos o Xen, após muitas dificuldades de instalação, operacionalização e de usabilidade em si, descobrimos os produtos da Microsoft que estão voltados para o segmento de virtualização, sendo eles: o VirtualPC e o Hyper-V, sendo o Hyper-V o substituto do VirtualPC 2007.

Pesquisamos também sobre a história da Microsoft no ramo de virtualização, para compreender o grau de maturidade da sua solução em relação aos vastos anos de experiência da vmware. O que conseguimos compreender foi que por volta de 1997 uma empresa denominada Connectix, desenvolveu os softwares Virtual PC e Virtual Server, sendo um para estações de trabalho e o segundo para servidores, respectivamente, a fim de emular o Windows em máquinas Macintosh. Em 2001 esta mesma empresa lança as versões para Windows, despertando o interesse da Microsoft para o ramo da virtualização, que em 2002 adquire a Connectix, suspendendo o desenvolvimento para Macintosh e desenvolvendo os produtos para o ambientes Windows. Em 2004 a Microsoft anuncia o Virtual PC 2004, como proposta de solução em virtualização, mas em função de diversas limitações e da própria existência da concorrência do vmware, não foi aceita pela comunidade em geral. Em 2005 a Microsoft lança o Virtual Server 2005, como forma de concorrer com a vmware. Em 2007 a Microsoft lança uma nova versão do Virtual PC, o Virtual PC 2007, e divulga que suas soluções em virtualizações seriam gratuitas. Em 2008 a Microsoft anuncia o Hyper-V, o equivalente ao Virtual Server 2008, inicialmente como uma solução independente (standalone) a ser instalada nos sistemas operacionais comuns da época, porém em 2009 passa a ser incorporado no próprio sistema Windows Server 2008.

Descobrimos que o Hyper-V vem conquistando a opinião dos blogueiros e colunistas na Internet. Então resolvemos testar, visto que o Xen não estava se adequando a nossa política de usabilidade, que consiste em o administrador de redes preparar o servidor, treinar a equipe de suporte técnico e permitir que essa mesma equipe realize a manutenção no servidor em caso de sua ausência. O fato foi que treinar a equipe de suporte em Linux e Xen não apresentou viabilidade, visto que a equipe não dominava previamente o Linux, não tínhamos tempo hábil para esse treinamento e que a rotatividade da equipe de suporte era elevada.

Na primeira pesquisa que realizamos descobrimos que o Hyper-V era ofertado gratuitamente nas distribuições do Windows Server 2008. Também descobrimos nesse momento que a Microsoft comercializa cada uma das versões do Server 2008 (Standard, Entreprise, DataCenter, Web, entre outros) com ou sem o Hyper-V, além de comercializá-lo a parte também para instalação no Windows Server 2003 ou XP. Como a empresa possui um contrato Academic Alliance com a Microsoft, onde temos a possibilidade de usar uma vasta gama de produtos a um custo razoável, e dentro dessa listagem havia o Windows Server 2008 Standard e Entreprise, então resolvemos testar.

A última questão foi resolver quais das duas distribuições deveriam ser instaladas, a Standard ou a Entreprise. Em pesquisas realizadas no próprio site da Microsoft descobrimos que a versão Standard, com suporte nativo ao Hyper-V, disponibiliza uma única licença de máquina virtual, sendo cobrado em torno de $60,00 a licença para máquinas adicionais, enquanto a versão Enterprise já disponibilizava quatro licenças de máquinas virtuais, também sendo necessário pagar os $60,00 para outras máquinas virtuais. Dessa forma optamos pelo Windows Server 2008 Entrerprise, pois queríamos no mínimo virtualizar quatro servidores.

Dessa forma chegamos na nossa solução de virtualização, onde dispensamos o vmware por questões de custo, dispensamos o Xen por questões de usabilidade e adotamos o Hyper-V por questões de custo-benefício e por acreditar que a solução esteja madura o suficiente para adotarmos em nossa produção.

Em um próximo post pretendo contribuir com as experiências decorridas dessa nova solução, como seus problemas, peculiaridades e benefícios implícitos que não são cobertos pelos FAQs.