Perguntas e respostas do ExchangeBalanceamento de carga, transporte de borda e mais

Henrik Walther

P Temos vários servidores com o Microsoft® Office SharePoint® Server em execução implantados em nosso ambiente de produção corporativo. Cada um desses servidores precisa retransmitir mensagens de saída por meio dos servidores HT (Transporte de Hub) em nossa recém-implantada infra-estrutura do Exchange Server 2007. Como um servidor do SharePoint só nos permite especificar o FQDN (nome de domínio totalmente qualificado) de um único servidor SMTP (Exchange) na página Administração Central | Operações | Definições do Email de Saída, como mostrado na Figura 1, estava me perguntando como podemos eliminar esse único ponto de falha?

Figura 1 Definições do email de saída na página Administração Central do SharePoint (Clique na imagem para ampliá-la)

R Esta é uma ótima pergunta porque muitas organizações se concentram na alta disponibilidade e, assim, não aceitarão nenhum ponto de falha sequer em todos os ambientes de produção corporativos. Isso se torna ainda mais evidente quando o assunto é sistema de mensagens e serviços de colaboração.

Por padrão, os servidores HT do Exchange 2007 são resistentes. Ou seja, se houver mais de um servidor HT implantado em um site do Active Directory® e um servidor HT nesse site do Active Directory estiver indisponível, o servidor HT de origem que está tentando entregar a mensagem passará para o próximo servidor HT disponível no site do Active Directory. Isso é feito usando mecanismos DNS round robin (caso o primeiro servidor HT na lista não responda, tentemos o próximo).

Dessa forma, quando se chega à comunicação inteiramente entre HTs e entre o servidor de caixa de correio e o HT (ou seja, intra-org), não precisamos nos preocupar com a alta disponibilidade (ou balanceamento de carga, no caso), porque essa é uma funcionalidade nativa do Exchange 2007. No entanto, tenha em mente que, se você instalar a função de servidor HT em um computador que também tem a função de servidor de caixa de correio instalada, a função de servidor de caixa de correio irá sempre preferir o servidor HT local aos demais servidores HT no site do Active Directory (mesmo quando o servidor HT instalado localmente estiver indisponível) quando o serviço de Envio de Mensagens do Microsoft Exchange envia mensagens.

As informações anteriores não são, de fato, úteis em relação aos servidores do SharePoint, embora seja importante que você saiba disso antes de continuarmos. Como um servidor HT é resistente por padrão, não há suporte para a comunicação intra-org do balanceamento de carga entre servidores HT no Exchange 2007 que usam balanceadores de carga de hardware ou a funcionalidade WNLB (Balanceamento de Carga de Rede do Windows®).

Na verdade, não havia nenhum suporte para o tráfego SMTP de entrada do balanceamento de carga nos servidores HT baseados na versão do Exchange 2007 RTM. Mas o Exchange 2007 SP1 mudou isso. Com o SP1, ainda não é possível balancear a carga da comunicação intra-org usando os balanceadores de carga de hardware ou a funcionalidade WNLB (e por que você faria isso, a propósito?), mas você pode balancear a carga do tráfego SMTP de entrada em origens que não sejam do Exchange (como, por exemplo, servidores do SharePoint) e clientes do Exchange como os clientes IMAP ou POP que enviam mensagens de saída para a organização do Exchange 2007 usando o conector de recebimento do cliente padrão no servidor HT.

Logo, para configurar um servidor do SharePoint a fim de retransmitir mensagens por meio de uma organização do Exchange 2007 SP1, basta criar um registro DNS no DNS do Active Directory e apontá-lo para um balanceador de carga de hardware, que pode distribuir o tráfego em vários servidores HT ou usar a funcionalidade WNLB para cumprir esse objetivo. Para usar este segundo método, configure o cluster WNLB usando um endereço IP virtual e FQDN (como, por exemplo, mail.contoso.com) e adicione a porta 25 (tráfego SMTP de entrada dos servidores que não sejam do Exchange) e 587 (SMTP de entrada dos clientes do Exchange como, por exemplo, IMAP e POP) na guia Regras de Porta. A Figura 2 mostra como ficará a guia Regras de Porta com essa configuração. Você também desejará ter a certeza de atribuir o endereço IP do cluster NLB virtual a ambas as regras, em vez de selecionar todos os endereços IP.

Figura 2 Regras de porta definidas (Clique na imagem para ampliá-la)

Quando o cluster NLB for configurado, você precisará criar um novo conector de recebimento que deve ser configurado para escutar a porta 25 e só permitirá os servidores que precisam dela para retransmitir mensagens usando esse conector. Além disso, verifique se esse conector usa o endereço IP do cluster NLB virtual criado anteriormente.

P A nossa infra-estrutura do sistema de mensagens se baseia no Exchange Server 2007. Para tornar os nossos servidores de caixa de correio do Exchange 2007 redundantes tanto no nível de hardware quanto de armazenamento, eles são todos servidores de Caixa de Correio agrupados com base na tecnologia CCR (replicação contínua em cluster). Os nós ativo e passivo de cada cluster CCR estão localizados no mesmo data center físico. Agora que atualizamos os nossos servidores do Exchange 2007 para o SP1, queremos aproveitar a disponibilidade do serviço e dos dados, replicando bancos de dados de caixa de correio para servidores de Caixa de Correio com a nova tecnologia SCR (Replicação Contínua em Espera) incluída no Exchange 2007 SP1.

Reconhecemos que as fontes SCR podem ser servidores de Caixa de Correio autônomos do Exchange 2007 SP1 ou CMS (servidor de caixas de correio clusterizadas) baseados no CCR ou na tecnologia SCC (cluster de cópia única). Mas e os servidores de destino SCR?

R Os servidores de destino SCR (também conhecidos como pontos de extremidade SCR) devem ser um servidor de Caixa de Correio autônomo sem LCR (replicação contínua local) habilitada para qualquer grupo de armazenamento ou um nó passivo em um cluster de failover do Windows (anteriormente conhecido como Microsoft Cluster Server) com a função de servidor de Caixa de Correio instalada. Isso significa ser possível formar o cluster de failover e, em seguida, instalar a função de servidor de caixa de correio em um nó passivo no cluster, mas você não pode usar um servidor de Caixa de Correio clusterizado como o destino SCR.

P A nossa organização usa o Exchange 2007 como a plataforma do sistema de mensagens. Chegamos até mesmo a optar por substituir a nossa antiga solução em anti-spam/antivírus na rede de perímetro por uma solução baseada nos servidores de transporte de borda do Exchange 2007 com o Forefront™ Security for Exchange instalado para que pudéssemos usufruir as várias camadas de proteção e segurança da mensagem. O nosso plano é implantar pelo menos mais dois servidores de Transporte de Borda no futuro próximo.

Isso suscita a minha dúvida. Como faríamos o balanceamento de carga nas conexões SMTP de entrada com a nossa solução em higienização de mensagens baseada no Transporte de Borda do Exchange 2007 e, assim, distribuiríamos a carga tornando-a totalmente redundante?

R Caso os servidores de Transporte de Borda na rede de perímetro sejam os servidores SMTP com a Internet, é possível usar uma abordagem semelhante à usada no grupo de TI (Tecnologia da Informação) da Microsoft. O TI da Microsoft implantou seis servidores de Transporte de Borda (três em Redmond e três no Vale do Silício) que manipulam mais de 16 milhões de mensagens de entrada diariamente (e mais de 13 milhões são filtradas como spam).

O TI da Microsoft conta com um total de três registros MX (Mail Exchange) para o domínio Microsoft.com. São eles: maila.microsoft.com, mailb.microsoft.com e mailc.microsoft.com (consulte a Figura 3). Cada registro MX foi configurado com uma preferência igual a 10 para que seja escolhido aleatoriamente usando-se uma técnica round robin DNS. Além disso, dois endereços IP (hosts de correio) são associados a cada registro MX.

Figura 3 Registros MX e hosts de correio da Internet de Microsoft.com (Clique na imagem para ampliá-la)

Por que dois endereços IP por registro MX? Como alguns MTAs (agentes de transferência de mensagem) sempre escolherão o mesmo registro MX, não importa quantos registros MX você configurou para um domínio. Com relação ao Exchange Server, isso não tem sido problema há anos (não desde o Exchange 2000), mas infelizmente ainda há MTAs por aí que apresentam essa falha no design. Por isso, não importa qual MTA tenta entregar uma mensagem para um endereço Microsoft.com, pois todas as conexões SMTP estão distribuídas usando uma combinação entre round robin DNS e balanceamento de carga.

P O nosso domínio do Active Directory se baseia nos DCs (controladores de domínio) do Windows Server® 2003. Atualmente estamos na fase de planejamento da transição dos nossos DCs do Windows Server 2003 para o Windows Server 2008 e do nosso ambiente do sistema de mensagens do Exchange 2003 para o Exchange Server 2007. Podemos fazer a transição do nosso domínio do Active Directory para o Windows Server 2008 atualizando todos os servidores com o Windows Server 2003 em execução para o Windows Server 2008 antes da transição do ambiente do sistema de mensagens do Exchange Server 2003 para o Exchange 2007?

R Sim, como há total suporte para o Exchange Server 2003 SP2 em um domínio do Active Directory consistindo inteiramente em DCs do Windows Server 2008, é possível pôr o plano em prática. Apenas tenha em mente que, caso pretenda usar RODCs (controladores de domínio somente leitura) do Windows Server 2008, você não deve configurar o RUS (Serviço de Atualização de Destinatário) do Exchange para usar um RODC.

Henrik Walther é Microsoft Certified Architect: Messaging (aprendiz) e MVP em Exchange com mais de 14 anos de experiência na atividade de TI. Ele trabalha como arquiteto de tecnologia na Interprise Consulting, além de ser redator técnico da Biblioso Corp.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. É proibida a reprodução total ou parcial sem autorização.