Virtualizar Domain Controllers–Devo ou não?

Esta pergunta já ouvi inúmeras vezes. Em treinamento, palestras, emails e clientes sempre ouço a pergunta “Porque eu não posso virtualizar o Domain Controller?”

Esta semana em um grande cliente que atendo como consultor da Dell, alguns sites não permitiam logon, o Office Communicator não funcionava e outros problemas. Portanto, acho que este tema é bem apropriado com o crescimento dos ambientes virtualizados.

UPDATE: O Windows Server 2012 introduziu recursos próprios para virtualizar Domain Controllers sem as restrições com o NTP, porem a questão de logar no servidor Hyper-V pode continuar ativa.

Vamos começar com o fato concreto: Ninguem disse que não podem ser virtualizados, e sim que existem fatores a considerar. E é sobre isso que irei escrever.

Posso virtualizar todos os meus Domain Controllers?

Pode, mas terá sérios problemas de segurança e comprometer a réplica se o seu Domain Controller for Windows 2003.

Existem alguns pontos a se considerar ao pensar em virtualizar todos os servidores que podem ser consultados em http://support.microsoft.com/kb/888794/en-us quando vc ainda utilizar DCs com Windows 2000 ou Windows 2003.

Não é a toa que se recomenda ter os FSMOs em servidor fisico, mas falaremos disso daqui a pouco.

Porque virtualizar todos os Domain Controller compromete a segurança?

Neste caso temos duas opções, a primeira deixar o Hyper-V utilizando segurança SAM (local) ou ingressar ele no dominio da VM e as duas podem lhe trazer problemas.

A primeira opção é um sistema de segurança antigo, não baseado em Kerberos e fácil de se quebrar.

A segunda é o risco de ao ter uma queda das VMs ou um desligamento para manutenção ou energia o servidor do Hyper-V não aceitar logon e mostrar a mensagem “No Domain Controllers for Authentication”.

Porque não é recomendado virtualizar FSMOs?

Porque os FSMOs desempenham papeis importantes na estrutura, normalmente é o Global Catalog e tambem o NTP Server.

Caso seja virtualizado as FSMOs o servidor poderá ficar com problemas de sincronização de horários, replicação atrasada, etc.

Se ele estiver em uma VM e esta for desligada por um certo tempo o risco de estar com problemas de USN é maior ainda.

E o pior momento é se o host Hyper-V perder o relógio e atrasar o horário, gerando inconsistencias sérias no AD.

Esta discussão é antiga, desde o inicio do Hyper-V e pode ser acompanhada em http://blogs.technet.com/b/robse/archive/2008/06/16/dc-virtualized-and-external-ntp-servers.aspx

Qual o problema com o NTP Server?

O NTP Server tem a função de ser o sincronizador de horário nos dominios. A principio é feito pelo PDC Emulator.

Maquina fisicas mantem relógio por consultar o RTC (Real Time Clock) na BIOS que é baseado em cristal e após isso o SO passa a usar algoritmos logicos para manter o relógio.

O problema em VMs é que este algoritmo pode ficar comprometido por conta da carga, já que ele não é fisico e sofre interferencia conforme o weight definido para as operações, ou seja, irá atrasar ou adiantar.

Para evitar isso o Hyper-V faz a sincronização usando as Integrations Features, e ai ocorrem as desincronizações e os usuários não conseguem logar, aplicaçoes dão erro, etc.

Ai temos um problema, no documento “Running Domain Controllers in Hyper-V” (http://www.microsoft.com/download/en/details.aspx?id=20164) diz para desligar esta feature dos DCs virtuais.

Por outro lado o blog do PM de virtualização (http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/11/19/time-synchronization-in-hyper-v.aspx) diz para não fazer isso.

O problema é muito bem abordado pelo Ben Armstrong e é real. Uma maquina fisica mantem o relógio quando desligada (RTC), mas a virtual não, portanto se todos os DCs forem virtuais e esta opção estiver desabilitada em um desligamento eles irão retornar com o horário em que foram desligados, e quem irá atualizá-los?

Minha Recomendação Final

Siga as práticas do documento “Running Domain Controllers in Hyper-V”, mas sempre tenha um servidor fisico QUE NÃO SEJA O HOST DO HYPER-V.

Configure todas as máquinas, incluindo os hosts do Hyper-V para sincronizar com esta fisica usando Net Time /SetSNTP:<servidor> e assim não terá problema com o relógio, já que o próprio host irá sincronizar com o fisico e consequentemente as VMs com ele.

 

É isso ai, espero ter ajudado e qualquer acrescimo podem me enviar pelos comentários ou email.

Best Practices para Exchange 2010 no Hyper-V

Este documento disponibilizado no domingo pela Microsoft é útil não só em casos de Exchange mas como em qualquer outro projeto de virtualização com Hyper-V.

O documento foca nas melhores práticas de implementação do Exchange 2010 no Hyper-V mas adicionalmente explica as tecnologias envolvidas e o porque da recomendação.

Por exemplo, explica cada tipo de disco que o Hyper-V suporta (DAS, iSCSI, eSATA, etc) e considera qual o melhor a ser utilizado e recomendações como termos mais de uma placa de rede no caso de iSCSI, performance de discos virtuais fixos versus dinamicos, etc.

Mas como o documento é focado em Exchange, achei algumas recomendações muito interessantes, principalmente o resumo que ele apresenta com os itens:

  • Snapshots, differencing/delta disks
  • Virtual processor/physical processor core ratios greater than 2:1
  • Applications running on the root virtual machine (excluding antivirus, backup, management software, and so on).

Do meio do documento para frente ele passa a descrever um cenário de exemplo e mostrar os cáculos envolvidos pela carga do cliente e como seria o sizing, incluindo DAG e recomendações sobre como usar da melhor forma.

Resumindo, leitura imperdível!!!!!!

Faça o download em http://www.microsoft.com/downloads/en/details.aspx?FamilyID=8647c69d-6c2c-40ca-977e-18c2379b07ad

Atualizado 26/10/2010: Hyper-V com Windows 2008 R2 Service Pack 1 Beta

Atualizado: Liberado o Release Candidate em 26/10/2010: http://www.microsoft.com/windowsserver2008/en/us/sp1.aspx

Windows 2008-SP1

Hoje consegui instalar o Service Pack Beta 1 do Windows Server 2008 R2 e achei bem interessante as mudanças no Hyper-V (Dynamic Memory), como já estava anunciado (http://technet.microsoft.com/en-us/evalcenter/ff183870.aspx).

Hyper-V SP1

Como pode ser visto na imagem acima, você pode escolher memória estática (fixa) ou dinâmica.

O interessante são as possibilidades de indicar quanto a memória irá ser incrementada baseada na prioridade da máquina em relação a outras máquinas virtuais (VM) no mesmo servidor. No slider Memory Priority você indicará como as máquinas ao ser inicializada poderão alocar memória do Hyper-V.

NOTA: É importante frisar que para a memória ser dinâmica EM EXECUÇÃO é necessário que as VMs com Windows 2008 R2 e Windows 7 estejam também com o SP1 Beta. Em outras VMs as maquinas alocarão memória conforme forem sendo iniciadas.