Profissionais TI - Pra quem respira informação

Introdução: um resumo sobre virtualização

Um servidor normalmente não usa 100% da sua capacidade de processamento.

O processo de virtualização consiste em aproveitar ao máximo o hardware de um servidor concentrando várias máquinas virtuais em uma máquina física, trazendo vários benefícios, dentre os quais, destacam-se:

• Redução de consumo de energia;
• Redução da geração de calor e na pegada de carbono;
• Gerenciamento simplificado em um único console;
• Facilidade de expansão.

O desafio: converter máquinas físicas em virtuais

Recentemente recebi a tarefa de converter 15 máquinas físicas em virtuais. Eram máquinas com idades entre 9 e 15 anos, muitas das quais com capacidade de processamento esgotada, rodando versões do Windows Server 2003, 2008 e 2012. O backup era lento, em fita LTO e retenção de 2 dias, com latência de 16 horas.

Primeira etapa: licenças de softwares

A primeira etapa foi reunir informações das licenças de software e upgrades necessários para permitir a virtualização, pois tipos e quantidades de licenças podem variar neste caso. Mas o objetivo deste artigo não é debater licenciamento e sim mostrar o processo adotado e os obstáculos encontrados.

Definição do novo hardware

Foi utilizado o software Live Optics para analisar os picos de processamento e armazenamento dos servidores físicos. Após 30 dias de análise foi possível determinar o volume de armazenamento e processamento necessários.

Para um ambiente virtualizado, o hardware proposto foi composto por dois hosts Dell R730xd com SSD de 480Gb para o sistema Hypervisor e 192Gb de RAM cada um, que foram ligados em pool. Estes hosts também possuíam 2 processadores com 10 núcleos cada e 6 placas de rede, sendo 2 de 10Giga para comunicação com os demais servidores, 2 de 10Giga para comunicação com a Storage em multipathing e 2 de 1Giga para gerenciamento.

Também foi adquirido um servidor com 20TB de armazenamento para backup em disco, um Storage iSCSI com uma LUN de 10TB em disco SAS e outra LUN com auto tier composta por 6TB SAS e 4TB SSD.

Por fim completaram o hardware dois switches Dell 10Giga de 24 portas cada. Cabos de 1m CAT6 Furukawa interligaram os equipamentos no rack porque este tipo de cabo pode, em curtas distâncias, atingir 10Giga de velocidade.

Tipos de virtualização

A virtualização pode ser do tipo 1 (bare-metal), quando o software hypervisor é executado na camada de hardware do servidor, ou tipo 2 (hosted) quando existe uma camada de software entre o hardware e o hypervisor.

Para servidores, a melhor escolha é um hypervisor bare-metal.

Definição do Hypervisor

Neste ponto, foram analisados os três softwares que dominam o mercado atual.

O Microsoft Hyper-V foi descartado por que, apesar da grande evolução recente, usa mais recursos do hardware para a camada hypervisor quando comparado aos demais.

O VMWare VSphere não pode ser instalado no servidor de testes Dell R410 por incompatibilidade de hardware, sendo descartado também.

A solução então foi usar o Citrix XenServer na versão 7.2, que tinha vários recursos gratuitos e permitiria uma avaliação tranquila sem necessidade de investimento no em licença no primeiro momento.

Apesar do Citrix não ter reconhecimento no mercado da mesma forma que o VSphere ou o Hyper-V, ele é uma boa solução também, com bom desempenho e interface mais fácil e intuitiva que os dois concorrentes.

Treinamento

Eu já tinha uma boa noção de virtualização. Em 2005 implantei uma rede com  thin clients da Orion (os primeiros PC-Expanion que recebemos no Brasil) compartilhando áreas de trabalho de Windows 2000 e Windows XP e posteriormente utilizei tanto o VMWare quanto o Citrix XenServer 6.5.

Mas a instalação e configuração do hypervisor do zero ainda era um pouco obscura para mim.

A solução foi investir em cursos on line para obter mais conhecimento nesta área e um excelente curso de Citrix Hypervisor 7.6 na Udemy possibilitou configurar os servidores hosts deste projeto.

Início do processo de migração

Com o servidor de teste configurado, o primeiro passo foi criar novas máquinas virtuais em Linux CentOs 7 para serviços do Web Server e Web Container, substituindo um servidor com Windows Server 2003.

O servidor de e-mail Exchange Server 2007 não tinha mais suporte da Microsoft e também não haviam softwares atuais de antispam com suporte a esta versão, resultando em risco grave de segurança. Este servidor foi desligado e o serviço migrado para nuvem devido ao alto custo do Exchange 2019.

Mas alguns servidores não podiam simplesmente receber upgrades por vários motivos: precisavam ser convertidos “AS-IS” para o ambiente virtual.

Programas P2V (Physical to Virtual)

Para converter uma máquina física em virtual existem vários programas. Neste projeto, usei alguns deles:

• MVMC – Microsoft Virtual Machine Converter 3.0, permitiu converter uma única máquina 2012R2 com sucesso, mas era incompatível com Windows Server 2003.
• SCVMM – System Center Virtual Machine Manager, também da Microsoft, instalado sobre o Windows Server 2008R2 com Hyper-V habilitado, permitiu converter com sucesso algumas máquinas com Windows Server 2003. Ele ainda permite backups com a máquina online ou off-line, tendo uma taxa de sucesso muito alta.
• Disk2Vhd – Também da Microsoft, na versão 2.1 utilizada, possibilita converter uma máquina inteira ou apenas determinados discos, tendo sido muito útil quando havia discos separados para o Sistema Operacional e as aplicações, principalmente banco de dados.
• XenConvert – Da própria Citrix, foi descontinuado após a versão 7.x do XenServer e foi preciso “garimpar” bastante a internet até conseguir realizar um download das versões 2.1 a 2.3 da ferramenta. E ela permite converter a própria máquina física onde foi instalado, sendo muito útil em alguns casos.
• VConverter – Da VMWare, também foi útil em dois casos de conversão com Windows Server 2008R2 e 2003 64 bits.
• NTBackup – Funcionou em apenas uma máquina Windows Server 2003. Esta ferramenta, nativa do Windows 2K3, criou um backup que foi posteriormente restaurado para uma nova VM criada com o mesmo sistema operacional da máquina física.

Formato do arquivo P2V

A maioria dos programas P2V consegue criar um arquivo com a extensão .vhd que posteriormente é importada para o Citrix XenServer. A exceção é o VConverter que cria em outro formato, mas isso é facilmente corrigido com o XenConverter que converte o formado para .vhd ou com comandos do Windows Powershell.

Desafio do P2V – Windows Server 2003

O maior desafio do P2V foi com o sistema operacional Windows Server 2003 porque esta versão não tem suporte nativo para virtualização.

Muitas conversões apresentavam erro de tela azul ao iniciar a VM (Virtual Machine) ou travavam solicitando ativação do software ou simplesmente não iniciavam.

O pesadelo do HP Proliant 

Um velho servidor HP ProLiant DL380 G5 fabricado em 2007 com Windows Server 2003 Standard de 32 bitis foi o primeiro eleito ao processo de virtualização. Mas 8 tentativas desastrosas forçaram a busca por vários meios de conversão P2V.

Esse velho guerreiro motivou a acentuar a busca por mais conhecimento, aprimorando todos os métodos de P2V adotados até o momento.

Importar vários discos na máquina

Para as máquinas físicas dotadas de vários discos, o XenConverter gerava um único arquivo .vhd com unidades logicas para a nova VM.

Mas outros software geravam vários arquivos .vhd e o método de importar um de cada vez para o Citrix em várias VMs diferentes e depois usar as funções de Detach e Attach Disk para desvincular o disco (storage) de uma VM e vincular na VM principal se mostrou o mais eficaz.

Problemas com o Windows Server 2003

Após 6 meses migrando máquinas, principalmente nas versões 2003 do Windows, foi desenvolvido um método com acerto de 94% nestas conversões.

Tanto a máquina física quanto a máquina virtual devem ser preparadas antes e depois da conversão para obter sucesso neste processo. Alguns itens importantes a serem observados:

• Desabilitar o Internet Explorer Security System: Este passo consiste em acessar o painel de controle, selecionar a opção de desinstalar programas e clicar no botão Recursos do Windows. Em seguida, desmarcar a opção “Internet Explorer Security System” e clicar em Avançar. Isso é necessário para conseguir ativar a nova máquina virtual pois esta funcionalidade do Windows impede o acesso à ativação do software pela Internet, tornando o Windows inoperante.
• Instalar e atualizar o Internet Explorer 8: Sem este recurso também não é possível ativar o Windows na nova VM criada.
• Atualizar Data e Hora da máquina: Se a data e hora local não estiver correta o Windows também não será ativado. Neste caso, após importar a nova VM a partir do arquivo .vhd gerado pelo software P2V, ligar a mesma teclando F8 e no menu de loon do Windows, escolher a opção “Modo de segurança com Prompt de Comando”. Ao acessar o Windows, ajustar data e hora local e reiniciar a VM.
• Usuário Administrador: Na máquina física, criar, se não existir, um usuário Administrador. Isso pode ser feito pressionando a tecla Windows+R no teclado para executar o comando msc. Na tela que irá surgir, clicar com o botão direito do mouse em Usuários e selecionar “Add New User” e preencher os campos solicitados com a identidade do novo usuário Administrador. Gravar as informações e, na opção Grupos de Usuário abaixo da opção anterior, clicar duas vezes no grupo Administrators e adicionar o novo usuário criado. O usuário usado na conversão P2V necessita de acesso total ao conteúdo do disco da máquina física, por isso deve ser um usuário administrador.
• Mac-Address da placa de rede: Após criar a VM, usar na máquina física o comando ipconfig /all no prompt de comando do Windows e anotar o Mac-Address da placa de rede. Em seguida, atribuir esse mesmo MAC na VM criada.
• Desligar a máquina física antes de ligar a VM: Para não haver conflitos de nomes na rede e tentar evitar o processo de ativação do Windows.
• Processador e memória: Criar a nova VM com mesma quantidade de memória e processador da máquina física para evitar problemas de ativação do Windows. Após os testes a quantidade de memória e processadores pode ser alterada conforme a necessidade.
• Parar os processos da máquina: Parar processos com o comando msc durante o processo de P2V online, principalmente processos SAP e de bancos de dados (Oracle, SqlServer, MySql, Postgree, etc), além de antivírus e backups.
• Preferir conversões Offline quando possível. O SCVMM inicia neste modo uma versão do Windows PE (Preinstallation Environment) com os processos da máquina física interrompidos durante o processo.
• Após importar o arquivo .vhd, faça uma cópia da nova VM, apague nesta cópia a placa de rede no menu Networking do Citrix e teste a inicialização da mesma. Se der certo, apague a cópia e configure o Mac Address da placa de rede da VM criada inicialmente.
• Execute um scanner com o antivírus na máquina física antes de iniciar o processo de P2V.

E o pesadelo continua

A essa altura do projeto, com mais de 7 máquinas convertidas, o velho HP Proliant insistia em não funcionar. Todas as ferramentas e métodos que converteram com sucesso os demais servidores W2K3 foram inúteis nesse servidor. E já somavam 18 tentativas de P2V nele e não poderia desistir porque havia uma aplicação legada nele que não era possível substituir ou reinstalar.

Active Directory

Para o servidor AD a opção foi criar uma nova VM Windows Server 2012, promove-la a AD Master e descredenciar a máquina física em seguida por que não é aconselhável um processo P2V para Servidor do AD.

Mas para o AD secundário (Windows Server 2003) foi realizado processo de P2V em horário fora do expediente, durante um final de semana, com a ferramenta SCVMM em modo off-line com sucesso.

O cuidado neste caso é desligar a máquina física ao final do processo de P2V e ligar a nova VM. A máquina física não deve mais ser ligada para evitar reversão de USN (número de sequência de atualização do AD).

Programas de backup

Este foi o calcanhar de Aquiles do projeto. Foram testadas diversas soluções de backup, mas infelizmente a maioria não oferece suporte direto ao Citrix XenServer.

• Arcserver UDP – Esta ferramenta de backup, muito utilizada com o SAP e Oracle pela estabilidade, foi uma grande decepção no tratamento ao Xenserver. Para criar os backups ele precisa instalar um agente nas VMs Windows e criar uma VM Linux nova com o agente Linux. E para recuperar o backup ele exige que se crie uma nova VM com mesmo sistema operacional da máquina original, mesmo espaço em disco e capacidade de processamento e memória, execute um agente através de uma imagem ISO nesta nova VM e restaure o backup. Isso torna o processo oneroso e praticamente inviável, fora o alto risco de não ter acesso à estas informações em casos de desastre. Além disso ele exige espaço nas máquinas físicas para criar o Shadow Copy, gerando erro quando isso não é possível.
• SOS Backup, da Virtus, foi excepcional na compatibilidade com o Citrix, bastando executar no Host Master do XenServer um script simples e mapear um Storage Windows SMB e todas as VMs do pool já apareceram no Schedule de backup. Infelizmente ele não conseguiu executar o backup incremental do File Server com 800Gb de tamanho.
• Bacula backup: O valor com todos os plug-ins foi relativamente alto em comparação aos demais, o que dificultou prosseguir com o mesmo para a fase de testes.
• Script de backup: É possível criar scripts de backup no host para criar snapshots das VMs, exportar este arquivo e apagar o snapshot em seguida. Esse script pode ser agendado de acordo com a necessidade. O ponto fraco deste processo é o trabalho para criar o script e para incluir novas VMs nele quando necessário.
• Veeam: Mesmas dificuldades do ArcServe com VMs Citrix.
• Commvault: Foi solicitado o contato mais de uma vez, mas não houve retorno.

Servidores SAP e Oracle

Os servidores SAP e Oracle eram os mais críticos. Mas, seguindo os passos anteriores, foi possível usar o SVCMM da Microsoft com os serviços off-line e obter 100% de sucesso na virtualização.

Mas o procedimento chegou a durar 46 horas no servidor de desenvolvimento, com 1,6TB de dados, entre conversão da máquina, cópia dos arquivos .vhd e importação / configuração no XenServer. E o serviço ficou indisponível neste período.

Conclusão

O processo de virtualização teve alguns problemas durante a fase de aprendizagem, mas, após quase 8 meses, foi obtida a taxa de 100% de sucesso.

O Citrix XenServer se mostrou estável em todo o processo, tendo atendido plenamente a necessidade da empresa, embora não possua, infelizmente, suporte da maioria dos fornecedores de backup.

Em tempo

Ah, o velho HP Proliant sofreu a 26ª tentativa de P2V. Nesta tentativa a ideia foi ligar a máquina no próprio Hyper-V após a conversão. E, após quase 5 horas de boot, ele funcionou, permitindo desinstalar drivers de arrays Scsi.

Na segunda inicialização o tempo diminuiu para o boot e lá pela quinta tentativa de boot ele ficou mais rápido, iniciando em 2 minutos.

Neste ponto foi instalado o XenTools (Drivers do XenServer) e realizada a importação do arquivo .vhd para o XenServer.

E para nossa enorme surpresa, a VM funcionou perfeitamente.

Espero que eu tenha conseguido mostrar o que aprendi virtualizando servidores com Citrix XenServer e Windows Server 2003. Caso tenha dúvidas ou complementos ao texto, deixe seu comentário!