O AMBIENTE LEGADO
Inicialmente, por volta de 2004
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
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
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.
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.
O Xen é
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.