Desmistificando a virtualização do Exchange 2010 SP1

Artigo original publicado em 11 de outubro de 2011, terça-feira.

Passaram-se alguns meses desde que anunciamos algumas mudanças básicas nas instruções do suporte de virtualização do Exchange 2010 (consulte Anunciando suporte aprimorado de virtualização do hardware para Exchange 2010). Durante esse tempo, recebi algumas perguntas excelentes sobre os cenários de implantação específicos e como as alterações nas nossas instruções de suporte podem afetar essas implementações. Dado o volume de perguntas, parecia uma excelente oportunidade para postar algumas informações adicionais e esclarecimento.

Em primeiro lugar, um pouco de história. Quando fizemos as alterações nas nossas instruções de suporte, a primeira coisa que queríamos era garantir que os nossos clientes não iriam entrar em um estado em que a disponibilidade do serviço do Exchange pudesse ser reduzida como resultado do uso de uma implementação virtualizada. Em outras palavras, queríamos ter certeza de que o alto nível de disponibilidade pudesse ser obtido com uma implementação física do produto Exchange 2010 não seria de maneira nenhuma reduzido pela implementação de uma plataforma de virtualização. Claro, queríamos também garantir que o produto permanecesse funcional e que verificaríamos se a funcionalidade adicional fornecida pela pilha de virtualização não proporcionaria perda de nenhum dado do Exchange durante a operação normal.

Considerando esses pontos, aqui está uma visão geral rápido do que mudamos e o que isso realmente significa.

Com o Exchange 2010 SP1 (ou posterior) implantado:

• Todas as funções do servivor do Exchange 2010, incluindo Unificação de Mensagens, são suportadas em uma máquina virtual.
• As máquinas virtuais de Unificação de Mensagens têm os seguintes requisitos especiais:
  • Quatro processadores virtuais são necessários para a máquina virtual. A memória deve ser dimensionada usando a orientação padrão das práticas recomendadas.
  • Quatro núcleos do processador físico estão disponíveis para uso o tempo todo para cada máquina virtual da função Unificação de Mensagens. Esse requisito significa que nenhuma subscrição excessiva do processador pode estar em uso. Esse requisito afeta a capacidade da máquina virtual da função Unificação de Mensagens utilizar recursos do processador físico.
• As máquinas virtuais do servivor do Exchange (incluindo as máquinas virtuais da caixa de correio do Exchange que fazem parte de um DAG), podem ser combinadas com cluster de failover baseado no host e tecnologia de migração, sempre que as máquinas virtuais forem configuradas de formr a não salvar e restaurar o estado no disco quando movivo ou colocado offline. Toda atividade de failover deve resultar em uma inicialização a frio quando a máquina virtual for ativada no nó de destino. Toda migração planejada deve resultar em desligamento e inicialização a frio, ou em uma migração online que utilizar uma tecnologia como a migração ao vivo Hyper-V. A migração do hipervisor de máquinas virtuais é suportada pelo fornecedor do hipervisor; por isso, você deve garantir que seu fornecedor de hipervisor tenha sido testado e suporte a migração das máquinas virtuais do Exchange. A Microsoft oferecer suporte à migração ao vivo Hyper-V dessas máquinas virtuais.

Vamos repassar algumas definições para ter certeza de que estamos todos pensando sobre os termos nas instruções de suporte da mesma maneira.

• Inicialização a frio Isso ser refere à ação de ativar um sistema a partir de um estado desativado para um início limpo do sistema operacional. Nenhum estado do sistema operacional tem sido persistente nesse caso.
• Estado salvo Quando uma máquina virtual é desativada, geralmente os hipervisores têm a capacidade de salvar o estado da máquina virtual nesse momento para que quando a máquina seja ativada novamente, ela retorno para aquele estado em vez de ir para uma partida de “inicialização a frio”. O “estado salvo” seria o resultado de uma operação “Salvar” no Hyper-V.
• Migração planejada Quando um administrador do sistema inicia a transferência de uma máquina virtual de um host do hipervisor para outro, chamamos isso de migração planejada. Essa pode ser uma migração única ou um administrador do sistema pode configurar alguma automação que seja responsável pela transferência da máquina virtual em uma base programada ou como resultado de algum outro evento que ocorre no sistema diferente de falha do hardware ou do software. O ponto principal aqui é que a máquina virtual do Exchange está operando normalmente e precisa ser realocada por algum motivo – isso pode ser feito através de uma tecnologia como a migração ao vivo ou vMotion. Se a máquina virtual do Exchange ou o host do hipervisor onde a VM está localizada apresentar algum tipo de condição de falha, o resultado disso seria não ser “planejado”.

Virtualizando servivores de Unificação de Mensagens

Uma das alterações feitas foi a adição de suporte para a função Unificação de Mensagens no Hyper-V e outros hipervisores suportados. Como mencionei no início desse artigo, queríamos garantir que todas as alterações feitas na nossa instrução de suporte resultasse no produto permanecendo totalmente funcional e proporcionar o melhor serviço possível aos nossos usuários. Como tal, precisamos que o Exchange Server 2010 SP1 seja implementado para suporte à UM. O motivo para isso é bem simples. A função UM depende de um componente de mídia fornecido pela equipe da Microsoft Lync. Nossos parceiros na Lync fizeram algum trabalho antes da liberação do Exchange 2010 SP1 para permitir processamento de áudio de alta qualidade em tempo real em uma implantação virtual e na liberação SP1 do Exchange 2010 integramos essas alterações na função UM. Depois disso, fizemos alguns testes adicionais para garantir que a experiência do usuário fosse o mais ideal possível e modificamos a nossa instrução de suporte.

Como você notará, temos exigências específicas sobre a configuração da CPU para máquinas virtuais (e máquinas do host do hipervisor) nas quais a UM está sendo executada. Essa é uma segurança adicional contra a má experiência do usuário (que aparecem como baixa qualidade de voz).

Cluster de failover baseado no host & Migração

Grande parte da confusão em torno da instrução de suporte alterada decorre da combinação de detalhes sobre a tecnologia do cluster de failover baseado no host & migração com o 2010 DAGs). A orientação aqui é realmente muito simples.

• Primeiro, vamos falar sobre se oferecemos suporte à tecnologia de migração de terceiros (como o VMotion da VMware). A Microsoft não pode criar instruções de “suporte” para integração dos produtos hipervisor de terceiros usando essas tecnologias com o Exchange 2010, pois essas tecnologias não fazem parte do programa de Validação de Virtualização de Servivores (SVVP) que abrange outros aspectos do nosso suporte para hipervisores de terceiros. Criamos uma instrução genérica aqui sobre o suporte, mas, além disso, você precisa garantir que seu fornecedor hipervisor suporta a combinação da sua tecnologia de migração/cluster com o Exchange 2010. Para simplificar o máximo possível: se o seu fornecedor hipervisor oferecer suporte à tecnologia de migração com o Exchange 2010, ofereceremos suporte do Exchange 2010 com sua tecnologia de migração.

• Em segundo lugar, vamos falar sobre como definimos o cluster de failover baseado no host. Isso se refere a todo tipo de tecnologia que oferece capacidade automática para reagir em falhas no nível do host e inicias as VMs afetadas em servivores alternativos. O uso dessa tecnologia é realmente suportado dentro da instrução de suporte fornecida, supondo que esteja em um cenário de falha, a VM será ativada a partir de uma inicialização a frio no host alternativo. Queremos garantir que a VM nunca será ativada a partir do estado salvo que é persistente no disco, pois ela estará “parada” em relação ao resto dos membros do DAG.

• Em terceiro lugar, quando se trata de tecnologia de migração na instrução de suporte, falaremos sobre todo tipo de tecnologia quer permite uma transferência planejada de uma VM de uma máquina do host para outra. Além disso, esta pode ser uma transferência automatizada que ocorre como parte do recurso de balanceamento de carga (mas não está relacionado a uma falha no sistema). As migrações são realmente suportadas enquanto as VMS nunca são ativadas a partir do estado saldo que é persistente no disco. Isso significa que a tecnologia que mova uma VM através do transporte do estado e a memória da VM na rede sem tempo de inatividade percebido são suportado para uso com o Exchange 2010. Observe que um fornecedor hipervisor de terceiros deve fornecer suporte para a tecnologia de migração, enquanto a Microsoft fornecerá suporte para o Exchange quando usado nesta configuração. No caso do Microsoft Hyper-V, isso significa que a migração ao viso é compatível, mas a migração rápida não.

Com o Hyper-V, é importante estar ciente de que o comportamento padrão ao selecionar a operação “Mover” em uma VM é realmente executar uma migração rápida. Para ficar em um estado suportado com os membros do Exchange 2010 SP1 DAG, é essencial ajustar esse comportamento conforme mostrado nas configurações da VM abaixo (as configurações exibidas aqui representam como você deve fazer a implantação com o Hyper-V):

Figura 1: A máquina virtual correta do Hyper-V para membros do Grupo de Disponibilidade de Banco de Dados

Vamos revisar. No Hyper-V, a migração ao vivo é suportada para membros do DAG, mas a migração rápida, não. Visualmente, isso significa que isso é suportado:

Figura 2: Migração ao vivo do membro do Grupo de Disponibilidade de Banco de Dados no Hyper-V é suportado (consulte a captura de tela maior)

E isso não é suportado:

Figura 3: A migração rápido dos membros do Grupo de Disponibilidade de Banco de Dados não é suportada

Esperamos que isso ajude a esclarecer nossa instrução de suporte e orientação para as alterações do SP1. Aguardamos ansiosamente qualquer comentário que você queira nos fazer!

Jeff Mealiffe

Esta é uma postagem de blog localizada. Consulte o artigo original em Demystifying Exchange 2010 SP1 Virtualization