Microsoft Exchange 2010: Estabelecendo um data center virtual do Exchange 2010
Algumas práticas recomendadas devem ser seguidas ao planejar e implantar uma infraestrutura virtual do Exchange.
Brien M. Posey
A virtualização de servidores tornou-se a norma, mas o planejamento de virtualização ainda é algo de uma forma de arte. Isso é especialmente verdadeiro quando você está planejando virtualizar o Exchange Server. Você deve implantar o Exchange com desempenho e tolerância a falhas em mente. Adicionando o desafio é o facto de que abrangem a maioria das implantações do Exchange Server em vários servidores.
Você deve anotar todas as recomendações aqui apresentadas são baseadas no Hyper-V como a plataforma de virtualização. Isto não quer dizer que você não pode usar outras plataformas de virtualização. O oficial Microsoft apoiar a política afirma que você pode executar o Exchange em "qualquer hipervisor de terceiros que tem sido validado de acordo com o programa de validação de virtualização do Windows Server." Atualmente, Citrix Systems Inc., a VMware Inc. e um número de outros fornecedores de virtualização participa deste programa.
A partição pai
Ao planejar e implantar uma infra-estrutura virtual do Exchange Server, é importante alocar recursos suficientes para a partição do pai (que executa o sistema operacional de gerenciamento). Na falta de reservar recursos adequados pode afetar todos os seus servidores virtuais em execução em um servidor host.
A Microsoft recomenda reservar pelo menos 1 GB de memória para a partição do pai e o gerenciamento de sistema operacional. Se você estiver executando o Hyper-V em cima de uma instalação completa do Windows Server 2008 ou Windows Server 2008 R2, você deve considerar a reserva de 2 GB de memória para a gestão de sistema operacional para garantir OS nunca fique baixa em recursos.
A Microsoft também recomenda dedicando uma controladora de interface de rede (NIC) para fins de gerenciamento. Se você planeja usar a migração ao vivo, você deve dedicar um NIC para o processo de migração ao vivo. É importante notar que Microsoft não suporta a migração ao vivo para a função de servidor caixa de correio, se o servidor de caixa de correio é um membro de um grupo de disponibilidade de banco de dados (DAG).
Configuração de disco virtual
Exchange Server e Hyper-V são bastante flexíveis ao provisionamento de armazenamento. Mesmo assim, existem algumas práticas recomendadas Microsoft no que diz respeito a configuração de armazenamento virtualizado em servidores Exchange.
Hyper-V cria provisionamento thin virtuais VHDs (discos rígidos) por padrão. Isto significa que independentemente de quão grande você cria seu VHD, Hyper-V inicialmente irá criar um arquivo VHD que é menos de um gigabyte em tamanho. Este arquivo VHD expande dinamicamente como dados são adicionados.
Apesar de provisionamento thin pode ajudar a reduzir o consumo de espaço em disco, provisionamento thin discos rígidos virtuais não executam, bem como discos de comprimento fixo. Assim sendo, a Microsoft recomenda que usar somente discos de comprimento fixo para servidores Exchange virtualizados.
A configuração de disco real, que você deve usar irá variar dependendo da função de servidor, mas há algumas diretrizes gerais que são verdadeiras para todas as funções de servidor. Para começar, a Microsoft recomenda que dedicar um disco físico (LUN) para o gerenciamento de sistema operacional. Isso garante a gestão que os não estará competindo para recursos de disco com as máquinas virtuais (VMs).
A Microsoft recomenda também fornecer um LUN dedicado para o sistema operacional em cada um dos servidores virtuais. O VHD que contém o sistema operacional convidado deve ser grande o suficiente para armazenar o Windows Server e o arquivo de página. O tamanho de arquivo de paginação é geralmente o mesmo que a quantidade de RAM alocada para a VM.
Como tal, a Microsoft recomenda-se que dar o convidado OS 15 GB, além de equivalente de espaço para a quantidade de memória alocada para a VM. Portanto, um servidor virtual do Exchange com 4 GB de RAM teoricamente seria necessário cerca de 19 GB de espaço em disco para o volume que contém o sistema operacional.
Antes de começar realmente alocar recursos de disco, há um par de coisas a considerar. Você perceberá que eu não mencionei o espaço consumido por binários do Exchange Server. O requisito de 15 GB leva isso em consideração. Windows Server 2008 requer um mínimo de 10 GB de espaço em disco. A instalação padrão do Exchange Server multirole inicialmente consome aproximadamente cerca de 2.5 GB de espaço em disco (que pode mudar as coisas se mover em torno).
Ele ainda é uma boa idéia para aumentar um pouco os volumes de sistema operacional convidado, por duas razões. Em primeiro lugar, a recomendação de 15 GB só cumpre os requisitos de disco mínimo do Windows Server 2008. O requisitos de sistema para o Windows Server 2008 especificamente recomendar 40 GB ou mais. Máquinas com mais de 16 GB de memória RAM serão exigem espaço adicional em disco para paginação, hibernação e arquivos de despejo.
Planeje com antecedência
Servidores virtuais são muito flexíveis em termos de alocação de hardware. Você pode adicionar memória para um servidor virtual por capricho. Assim sendo, é uma boa idéia para iniciar com um VHD maior do que você realmente precisa para que você pode facilmente acomodar a expansão de memória futura. Essas recomendações se aplicam para o VHD que contém a máquina convidada OS e os binários do Exchange. A Microsoft também recomenda a criação de um ou mais VHDs adicionais para armazenamento de dados.
Por exemplo, se você estivesse criando um servidor de transporte de hub, você iria querer criar um VHD secundário para acomodar as filas de mensagens. Para um servidor de caixa de correio virtual, você deve criar dois VHDs extras — um para os bancos de dados de caixa de correio e um para os arquivos de log de transações.
Microsoft não parece enfatizar o hardware de armazenamento real, exceto com relação aos servidores de caixa de correio. Para esses casos, a Microsoft recomenda usar SCSI virtual. O método preferido envolve o uso de passagem SCSI, mas discos fixos também são aceitáveis.
Exchange também oferece suporte a armazenamento iSCSI para servidores de caixa de correio. Se você escolher o armazenamento iSCSI, a Microsoft recomenda que você configurar o iniciador iSCSI dentro do gerenciamento de sistema operacional, em vez de em máquinas convidadas. A Microsoft suporta usando o iniciador iSCSI dentro de uma máquina convidada, mas fazendo assim elimina o suporte a quadros jumbo. Ele também resulta em desempenho menor do que você gostaria de obter se você executou o iniciador iSCSI na partição pai.
Quando você configura o iniciador iSCSI na partição pai, você pode apresentar os destinos iSCSI anexado ao convidado OSes. Aqueles devem ser configuradas para tratar os destinos iSCSI como discos de passagem SCSI.
Tolerância a falhas
Hyper-V e Exchange 2010 oferecem culpa própria mecanismos de tolerância. Hyper-V oferece suporte a clusters de failover baseado em host. Exchange 2010 fornece DAGs. Essas soluções tolerantes a dois falhas trabalham de maneiras completamente diferentes, portanto, é importante escolher a solução tolerante a falhas que funcionará melhor para sua organização.
Se você não estiver familiarizado com DAGs, estas são um mecanismo de Exchange 2010 em que você pode combinar para até 16 servidores de caixa de correio em um único grupo. Você pode replicar bancos de dados de caixa de correio individual para qualquer um dos membros de DAG, proporcionando proteção em caso de falha.
Em contraste, o Hyper-V com base em host funcionam os clusters vinculando vários servidores Hyper-V para um cluster compartilhado volume. No caso de uma falha do servidor host, as VMs que residem no host com falha podem failover para um host alternativo.
Então, qual solução tolerante a falha deve você usar? A primeira coisa a considerar é o nível de proteção que cada uma oferece. DAGs oferecem proteção troca dados nativa, que fornece controle de failover automático no banco de dados. Como tal, DAGs podem proteger contra falhas de servidor, rede e banco de dados.
Hyper-V Host-Based Clustering de Failover opera no nível do host de virtualização. Não é uma solução compatível com Exchange, para que ele não pode protegê-lo contra uma falha no banco de dados. Ele só pode proteger contra uma falha de rede ou servidor. Sua dependência de um volume de cluster compartilhado significa que sob certas circunstâncias, o armazenamento compartilhado poderia tornar-se um ponto único de falha.
Enquanto esses fatores podem favorecer o uso de DAGs, existem outras considerações. Uma é que DAGs só podem acomodar servidores de caixa de correio — eles oferecem nenhuma proteção para quaisquer outras funções de servidor do Exchange.Isto não quer dizer que você não pode alcançar um grau de tolerância a falhas para outras funções de servidor Exchange-nível. Exchange usará automaticamente quaisquer servidores de transporte de hub disponíveis redundantes. Você pode balancear um servidor de transporte de borda e servidor de acesso de cliente (CAS) usando um DNS rodada instalação robin, mas lá não é realmente uma boa troca-nível falha tolerante a solução para essas funções.
Tendo em conta a vulnerabilidade dos servidores não-caixa de correio do Exchange, sua melhor opção poderia ser dupla. Criar um DAG para servidores de caixa de correio e use Host-Based Clustering de Failover para proteger outras funções de servidor do Exchange. No entanto, atingir esse tipo de proteção não é tão simples.
Você vai encontrar algumas restrições quando você começar a virtualização membros do DAG. Por um lado, você não pode hospedar um membro DAG virtualizado em um servidor de Hyper-V é um membro de um Cluster de Failover baseado em Host. Exchange não vai parar de fazer isso, mas não é uma configuração com suporte. Na verdade, a Microsoft desencoraja a mistura DAGs e Clusters de Failover baseado em Host.
A outra coisa é que você realmente não pode fugir com colocando vários membros do DAG para um servidor único host. Ao fazê-lo completamente pudesse prejudicar a protecção que fornece o DAG. Se o servidor falhar, todos os servidores de caixa de correio no host também falhará. Nessa configuração, o servidor host torna-se um ponto único de falha que potencialmente poderia forçar todo o DAG off-line.
Não há diretrizes Microsoft firmes sobre a disposição dos servidores virtualizados do Exchange para fornecer a melhor tolerância a falhas, mas existem várias alternativas. Tente criar um Cluster de Failover baseado em Host e usá-lo para hospedar o servidor de transporte de borda e CAS. Se você precisar fornecer balanceamento de carga para essas funções de servidor, considere criar Clusters de Failover de Host-Based adicionais e hospedagem de um servidor de transporte de borda e CAS em cada cluster. Você pode usar uma combinação de DNS round robin e redundantes registros MX para balancear a carga entre os servidores virtuais disponíveis.
Você não deve ter notado nenhuma menção de Unificação de mensagens. Direita agora, a Microsoft não suporta virtualizado servidores de Unificação. No entanto, Exchange 2010 SP2 irá adicionar esse suporte.
Você também pode considerar a criação não-clusterizados servidores Hyper-V. Cada um desses servidores sem cluster deve hospedar um servidor de caixa de correio e um servidor de transporte de Hub. Fazer cada servidor de caixa de correio de um membro do DAG e criar pelo menos dois servidores de transporte de Hub virtualizados para cada site do Active Directory.
Com essa configuração, os DAGs irão proteger contra o servidor de caixa de correio ou falha de banco de dados de caixa de correio individual. Os servidores de transporte de Hub redundante fornecem redundância de nível de transporte.
A única coisa que falta a partir dessa arquitetura é um servidor de pasta pública. Há algum tempo Microsoft tem dito que as pastas públicas estão indo embora. Se você puder, isso seria um grande momento para começar a progressiva-los. Se você continuar usando pastas públicas, você precisa compreender por que razão um DAG não pode proteger bancos de dados de pasta pública. A única maneira de fornecer tolerância a falhas para servidores de pasta pública é replicar pastas públicas para vários servidores de caixa de correio.
Como você pode ver, há um monte de planejamento que vai para construir uma infra-estrutura virtualizada Exchange, com suas principais considerações sendo hardware alocação e tolerância a falhas. Manter esses fatores em mente ajudará a orientá-lo para desenvolver uma infra-estrutura sólida e confiável.
.jpg)
**Brien M. Posey**é um Microsoft Most Valuable Professional e escritor técnico freelance com milhares de artigos e dezenas de livros para o seu crédito. Você pode visitar o seu site em brienposey.com.
Conteúdo relacionado