Desmitificando o Objeto de Matriz CAS - Parte 2

Artigo original publicado na quinta-feira, 29 de março de 2012

Bem-vindo de volta! Em Desmitificando o Objeto de Matriz CAS - Parte 1 nós cobrimos aqueles três itens para começar a desmitificar o objeto de matriz CAS no Exchange Server 2010.

1. Um objeto de matriz CAS não balanceia a carga do seu tráfego
2. Um objeto de matriz CAS não possui serviço OWA, ECP, EWS, Descoberta Automática, IMAP, SMTP ou POP
3. Um objeto de matriz CAS não precisa fazer parte do seu certificado SSL

Aqui na Parte 2 iremos cobrir os seguintes três itens e de uma vez por todas tirar toda a névoa do objeto de matriz CAS para ajudar você a corrigir as implantações existentes e/ou planejar implantações futuras de forma mais estratégica.

4. Um objeto de matriz CAS não deve ser resolvido através do DNS por clientes externos
5. Um objeto de matriz CAS não deve ser configurado ou alterado após criar bancos de dados de caixa de correio do Exchange Server 2010 e mover caixas de correio para os bancos de dados
6. Um objeto de matriz CAS deve ser configurado mesmo se você possui apenas um CAS ou um servidor multi-função único.

4. Um objeto de matriz CAS não deve ser resolvido através de DNS por clientes externos

Como mencionado na Parte 1 (pelo menos duas vezes, eu parei de contar) seu FQDN do objeto de matriz CAS não deve ser o mesmo FQDN usado para outros serviços como o OWA, ECP, EWS, EAS, Descoberta Automática ou o hostname externo do Outlook Anywhere.

A principal razão para isso é que os clientes do Outlook Anywhere tentarão primeiro resolver o FQDN do objeto de matriz CAS, portanto, sabe que não deve sequer tentar uma conexão RPC (por TCP) ou ir direito para o HTTPS. Você permite conexões RPC (por TCP) diretamente pela Internet para sua Intranet? Eu espero que não e se você fizer obterá um grande sinal vermelho em seu relatório do Programa de Avaliação de Integridade e Risco do Exchange. Se o cliente não tentar conectar através de RPC (por TCP) porque pode resolver com sucesso o FQDN do objeto de matriz CAS pode haver um atraso significativo antes do cliente voltar a tentar uma conexão HTTPS para a URL de proxy do Outlook Anywhere. Este atraso pode resultar em uma geração de chamadas para o suporte ao cliente maior se os usuários finais percebem que este atraso reduz o desempenho e/ou o serviço.

Para evitar essa situação, apenas certifique-se de que seu FQDN do objeto de matriz CAS é único para o DNS interno, talvez como outlook.corp.contoso.com enquanto a outra URL de serviço não RPC (por TCP) utilize algo como mail.contoso.com interna e externamente através de DNS dividido.

Se você não teve a oportunidade de utilizar o DNS dividido, é porque você possui um conjunto de servidores DNS internos E externos lidando com solicitações para a mesma zona de pesquisa avançada, por exemplo contoso.com. As duas infraestruturas DNS são completamente isoladas uma da outra. Não há transferências de zona, nem elas estão utilizando umas as outras como encaminhadores de DNS. Esta configuração permite os usuários internos utilizarem a infraestrutura DNS para resolver o host mail.contoso.com para um endereço IP interno (por exemplo, 192.168.1.10) que é transmitido para seu VIP do balanceador de carga enquanto os usuários externos o resolvem para os endereços IP públicos que podem apontar para sua infraestrutura TMG/UAG do Forefront para Internet em sua rede de perímetro. É muito comum o endereço IP do objeto de matriz CAS e o endereço IP interno das URLS de serviço não RPC (por TCP) (OWA, ECP, EWS, etc…) serem o mesmo VIP do balanceador de carga, mas eles podem utilizar diferentes verificações ativas para uma detecção de estado do serviço adequada.

O seu DNS atende uma resposta curinga?

Eu não tive um cliente com um servidor DNS externo que utilizou um registro curinga em resposta a qualquer consulta recebida para um hostname não existente. Isto significava que você poderia enviar uma solicitação DNS para SomeFunkyNameThatDoesNotExist.contoso.com e o servidor DNS sempre retornaria o endereço IP do seu site empresarial. (Registros curingas são completamente válidos por um ponto de vista de padrões de Internet. Consulte a seção 4.3.3 em RFC 1034 para detalhes - Editor).

Por causa disso, seus clientes do Outlook Anywhere podem sempre resolver o FQDN do objeto de matriz CAS e deveria tentar primeiro uma conexão RPC (por TCP) antes de trocar para o HTTPS. Se você se encontrar em uma situação similar com um servidor DNS externo usando respostas curingas para uma determinada zona de pesquisa avançada, eu recomendaria tentar evitar usar esta zona de pesquisa avançada para a URL do proxy do Outlook Anywhere.

Um desvio rápido se desejamos lembrar você de não esquecer de configurar os monitores de saúde de serviço adequados para sua solução de balanceamento de carga. Para os melhores resultados de monitoramento do serviço, consulte seu fornecedor de solução do balanceamento de carga. Veja Implantação do Balanceador de Carga do Exchange Server 2010 para obter uma lista de fornecedores do balanceador de carga que passaram pelo teste de solução do Exchange 2010 e links para suas páginas relativas (para Exchange 2010). Observe, *não* é uma lista definitiva de fornecedores de balanceamento de carga suportados em qualquer maneira. É simplesmente uma lista de fornecedores que escolheram se relacionar com a Microsoft diretamente para teste de solução e suporte.

Um exemplo rápido pode ser que seus FQDNs baseados em serviço HTTPS possui testes ativos realizados nas respostas TCP/443 e que a solução de balanceamento de carga para de enviar tráfego de novo cliente para qualquer servidor de Acesso do Cliente que interrompe a resposta do TCP/443. O FQDN de serviço RPC (por TCP) do objeto de matriz CAs pode ter testes ativos realizados no Mapeador de Ponto de Extremidade RPC no TCP/135 assim como as duas portas TCP estáticas escolhidas para o Serviço de Acesso do Cliente RPC e serviço do Catálogo de Endereços. Se qualquer destas três portas param de responder em um determinado servidor de Acesso do Cliente, a solução de balanceamento de carga não irá enviar tráfego do novo cliente para aquele CAS para RPC (por TCP) até que todas as portas comecem a responder novamente. Se você não configurar portas TCP estáticas, o Exchange escolherá uma porta TCP dinâmica para cada serviço na inicialização tornando o teste ativo mais difícil, se não impossível, para algumas soluções do balanceamento de carga.

5. Um objeto de matriz CAS não deve ser configurada após criar bancos de dados do Exchange Server 2010

Vários vezes estamos com pressa para instalar os servidores de Caixa de correio, criar os bancos de dados da caixa de correio e começar o teste de validação da solução com o Jetstress. Posso sugerir que você desacelere um momento para evitar problemas depois? Enquanto os servidores da caixa de correio são consideradas por muitos como a função do servidor mais importante, não é bom se sua porta frontal é fechada porque você não pode chegar a ela através dos servidores do Acesso do Cliente.

Se você começa a criar bancos de dados da caixa de correio antes de um objeto de matriz CAS estar no local, você verá um servidor de Acesso do Cliente aleatório no mesmo site do Active Directory declarado no atributo RpcClientAccessServer de cada banco de dados.

Ao invés de parecer, deve (usar o FQDN dos objetos de matriz CAS)

Figura 1: Se um objeto de matriz CAS é criado, a propriedade RpcClientAccessServer do banco de dados da caixa de correio é preenchida com o FQDN do objeto de matriz CAS

Irá se assemelhar ao seguinte:

Figura 2: Se o objeto de matriz CAS não é criado, a propriedade RpcClientAccessServer do banco de dados de caixa de correio é preenchido com o FQDN do servidor de Acesso do Cliente

Os perfis do cliente se assemelharão ao seguinte…

Figura 3: Se um objeto de matriz CAS não é criado, os clientes do Outlook são configurados com o FQDN do servidor de Acesso do Cliente

Os clientes irão ser conectados como o seguinte…

Figura 4: Clientes conectando ao FQDN do servidor de Acesso do Cliente

A primeira vista isso pode parecer muito inofensivo e funcionar bem, mas você está se configurando para ter problemas posteriormente. Se você começar a mover caixas de correio para o Exchange Server 2010 com esta configuração, o Outlook usará o nome CAS no campo “Servidor” do perfil do usuário. Funcionará, a não ser que o servidor de Acesso do Cliente se tornar indisponível ou ser descomissionado posteriormente e ser substituído com um servidor nomeado diferentemente. Iríamos preferir estar usando um pool com carga balanceada dos servidores de Acesso do Cliente sobre o tempo que ocorre? ? Sim, você iria preferir!

Você pode pensar sozinho “Ok espertinho, se este dia acontecer eu irei criar um objeto de matriz CAS e corrigir o RpcClientAccessServer nos bancos de dados e a vida será boa”. Estou aqui para dizer a você eu irei trabalhar apenas em caixas de correio que você mover para o Exchange 2010 após isso. Qualquer usuário com um perfil do Outlook pré-existente configurado para apontar para um nome CAS e não o objeto de matriz CAS, irá continuar a conectar ao nome do CAS e não irá se atualizar sozinho para utilizar o FQDN do objeto de matriz CAS.

O perfil não se atualizará sozinho porque o cliente não receberá uma resposta ecWrongServer do CAS. Não receberá esta resposta porque qualquer CAS é um ponto de conexão válido para qualquer banco de dados da caixa de correio através de RPC (por TCP) para que os clientes possam sobreviver a eventos de falha/interrupção do centro de dados sem precisar ser reconfigurado e tudo que os administradores precisam fazer é girar o registro DNS do objeto de matriz CAS para um pool sobrevivente do CAS. Atualmente a única forma de corrigir perfis de caixa de correio seria um reparo de perfil manual no Outlook, através da publicação de um arquivo PRF do Office através de GPO (não indo trabalhar para máquinas unidas não pelo domínio) ou pelo descomissionamento do servidor CAS nomeado nos perfis do usuário para que o ponto de extremidade não esteja mais disponível. Esta última opção deve (teste teste teste!!) iniciar um reparo de perfil completo pela Descoberta Automática no Outlook 2007 ou no Outlook 2010. O Outlook 2003 é reparável apenas com um reparo de perfil ou um arquivo PRF. A Descoberta Automática não irá, como escrito neste artigo, atualizar um perfil para um novo nome de servidor como parte do processo de Descoberta Automática normal que atualiza a configuração do Outlook Anywhere e descobre URLs EWS para outros recursos como o Gerenciamento OOF, Disponibilidade e gerenciamento de Regras da Caixa de entrada.

Isto também significa que se você mover uma caixa de correio de um banco de dados em um AD Site-A que usa um objeto de matriz CAS nomeado Boston-CASArray para um banco de dados no AD Site-B que usa um objeto de matriz CAS nomeado Redmond-CASArray que o perfil não irá atualizar o campo nome do servidor permanecerá igual ao FQDN Boston-CASArray. Você pode desejar manter isto em mente se tiver um preenchimento do usuário que migra para sites diferentes devido a mudanças do trabalho ou realizar uma mudança de caixa de correio interna em massa para outro site a algum momento durante o ciclo de vida da solução. Se você não estiver criando bancos de dados do Exchange 2010 antes de criar um objeto de matriz CAS, é fundamental que você volte e corrija o atributo RpcClientAccessServer dos bancos de dados para usar o objeto de matriz CAS movendo caixas de correio para os bancos de dados.

6. Um objeto de matriz CAS deve ser configurado mesmo se tiver apenas um servidor CAS ou um servidor multi-função.

Reflita por um momento sobre o que foi discutido no item anterior. Um cliente não irá se atualizar para usar um objeto de matriz CAS se você adicionar um posteriormente. Bem, e se você tivesse apenas um CAS? Você pode pensar que não importa. Eu acho que poderia discutir que não importa no momento, mas e por que não no futuro pode melhorar as coisas e economizar alguns ciclos e frustrações? E se daqui a um ano você se encontrar na necessidade de substituir esse CAS? Se você tem perfil de cliente que estão apontando para um nome de CAS e você não tem uma forma limpa de transição com algum tipo de interrupção ou trabalho manual. Você terá que reparar seus perfis com um dos meios já mencionados após adicionar um novo CAS ou terá que descomissionar o CAS existente e introduzir um novo CAS com o mesmo hostname que exigirá algum tempo de inatividade. Para mim, nenhuma destas opções é aceitável.

E se posteriormente seus requisitos comerciais mudam e ditam que você deve ter acesso de cliente altamente disponível? É possível atingir esta meta apenas adicionando um segundo CAS e uma solução de balanceamento de carga. Você ficará preso no mesmo barco novamente tendo que reparar os perfis de todos através de um dos meios discutidos. Novamente, não são opções aceitáveis para mim.

O que eu posso sugerir é criar um objeto de matriz CAs do início. Como você faz isso se não tem um balanceador de carga e possui apenas um CAS? Simples! Configure o objeto de matriz CAS normalmente. Dê um nome, um site AD, um FQDN e simplesmente aponte o registro “A” DNS para o IP como o único CAS existente ou o servidor multi-função do momento. Você apenas se preparou e se precisar substituir o CAS único ou o servidor multi-função, tudo que precisa é compilar o novo servidor e mudar o endereço IP do registro DNS e tudo funciona sem interrupções. Se você desejar adicionar uma alta disponibilidade posteriormente, você terá que ter uma solução de balanceamento de carga funcionando e mudar o endereço IP do registro DNS do objeto de matriz CAS para o ponto no VIP da solução de balanceamento de carga. Fácil!

Espero que este artigo tenha sido útil para resolver algumas ideias incorretas sobre o objeto de matriz CAS e continue a ajudar todos em uma migração do Exchange Server 2010 com integridade.

Brian Day
Engenheiro de Campo Premier, Mensagem

Esta é uma publicação localizada. Encontre o artigo original em Demystifying the CAS Array Object - Part 2