Fila do Exchange & R: as migrações e atualizações
Ao migrar de um grupo para outro, as atualizações nem sempre são automáticas e nem sempre desejadas.
Henrik Walther
Exchange 2010 e Hyper-V.
**P.**Estamos planejando implantar o Exchange Server 2010. Política da empresa afirma que todos os novos servidores devem ser máquinas virtuais (VMs) rodando em Hyper-V. Para aumentar a disponibilidade de aplicativos e serviços, todos os servidores de raiz do Hyper-V participarem nos Clusters de Failover do Hyper-V.
Vimos recentemente este blog post sobre o blog da equipe do Microsoft Exchange anunciando suporte de virtualização de hardware avançado para Exchange 2010. Especialmente encontramos a seguinte instrução interessante:
"Combinando soluções de alta disponibilidade do Exchange 2010 (grupos de disponibilidade de banco de dados [DAGs]) com clusters baseados em hipervisor, alta disponibilidade, ou soluções de migração que irão mover ou automaticamente failover servidores de caixa de correio que são membros de um DAG entre servidores em cluster raiz, é agora suportado."
Isso é uma boa notícia para nós, porque significa que agora pode implantar servidores de caixas de correio do Exchange 2010 participando de um DAG como VMs em um Cluster de Failover do Hyper-V. Existe alguma coisa que devemos estar conscientes de fazê-lo?
**R.**Você certamente tempo de implantação do Exchange 2010 bem. Você está absolutamente correto que a Microsoft agora suporta combinando DAGs com tecnologia de clustering e migração de failover baseada em host. Isso se aplica não apenas a Hyper-V, mas qualquer fornecedor de virtualização de hardware participando do Programa de validação de virtualização do Windows Server (SVVP).
No entanto, existem alguns pontos importantes para manter em mente, se você está pensando em membros de DAG migração ao vivo. Você precisa Exchange 2010 SP1 ou posterior para isso ser suportados. É também altamente recomendado usar discos não passagem e volumes de cluster compartilhado. Quando o grupo de produtos Exchange e equipe do Hyper-V testaram cada método, observaram o tempo off-line associado à movimentação dos recursos de armazenamento foi cortado pela metade, usando volumes de cluster compartilhado.
Se o servidor off-line ultrapassar cinco segundos, o nó de DAG será excluído do cluster. Portanto, é importante certificar-se de que o Cluster de Failover do Hyper-V pode migrar recursos em menos de cinco segundos. Se ele não é possível ajuste o tempo limite de pulsação de cluster para um valor mais alto. Você não deve definir superior a 10 segundos, porém.
Também certifique-se de que aplicou os patches mais recentes relacionadas com o Hyper-V para os servidores de host do Hyper-V. Sobre a rede de migração ao vivo, certifique-se de quadros jumbo estão ativado e os switches envolvidos suportam quadros jumbo. Também é recomendável que você altere o buffer de recebimento em cada host do Hyper-V para 8192. Também, você deve implantar maior largura de banda possível para a rede de migração ao vivo (5 GB ou maior é preferível).
É importante configurar cada VM, que eles salvar e restaurar o estado em disco quando movido ou colocado off-line. Qualquer failover deve causar uma inicialização a frio quando o nó de destino está executando uma VM. Um processo de migração planejada também deve incluir uma inicialização desligamento e frio. A ação off-line controlado por cluster é definida como "Salvar estado" por padrão. Em vez disso, ele deve ser definido para "Desligar" (ver Figura 1) para que o servidor de frio é inicializado quando live-migrado de um nó de Hyper-V para outro.
.jpg)
Figura 1 ação off-line controlado por Cluster definida para "Shut down.”
O recém-lançado "As práticas recomendadas para virtualizar o Exchange Server 2010 com Windows Server 2008 R2 Hyper-V" white paper inclui um monte de boas informações sobre o Exchange 2010 virtualização com Hyper-V. E, em último, mas não menos importante, o documentação do Exchange 2010 no TechNet foi atualizado para refletir essa nova postura de apoio.
Registrando FQDNs
**P.**Nós já implantados Exchange 2010 e tem um total de 12 funções de servidor de acesso de cliente (CAS). Utilizamos um modelo de datacenter de distribuição do usuário ativo/passivo. Isto significa que temos um data center principal e um datacenter de failover. Existem seis funções CAS em cada data center. Nós usamos uma solução de balanceador de carga com base em hardware para carregar tráfego de acesso de cliente de equilíbrio em cada data center. Nós temos aproximadamente 50.000 usuários, com conexão a maioria das suas caixas de correio usando os clientes Outlook 2007/2010 internos.
Vimos recentemente este post no blog no Blog da equipe do Exchange, que recomenda a todos os clientes habilitem a autenticação Kerberos para clientes internos do Outlook e explica o porquê. Por causa da presente recomendação, estamos planejando para habilitar a autenticação Kerberos para os clientes Outlook internos em nossa organização.
Embora nós ler o post do blog em detalhe e check-out a documentação do Exchange 2010 relevante no TechNet, nós ainda estamos um pouco em dúvida quanto à qual totalmente qualificado nomes de domínio (FQDN) temos de registrar como nomes de entidade de serviço (SPNs). O que acontece com o FQDN de descoberta automática? Nós precisamos de registrar esse FQDN também?
**R.**Eu posso entender por que você está um pouco confuso sobre o FQDN de descoberta automática. A maioria dos clientes têm uma descoberta automática FQDN geralmente chamado descoberta automática..com (companyname). Esse FQDN é para clientes externos (principalmente dispositivos Exchange ActiveSync e Outlook em qualquer lugar) para criação automática de perfil.
Vários recursos do Outlook 2007/2010 contam com o serviço de descoberta automática (Assistente fora do escritório [OOF], catálogo de Endereços Offline [OAB] e de Unificação de mensagens [UM]). Os clientes do Outlook 2007/2010 internos não usam esse FQDN de descoberta automática, porém. Eles parecem até o ponto de conexão de serviço no Active Directory usando o serviço de descoberta automática interna uniforme recurso identificador (URI), que, por padrão, aponta para o FQDN de CAS (ver Figura 2).
Quando você usa uma solução de balanceador de carga para distribuir o tráfego do cliente entre CASs em uma matriz de CAS, você geralmente definir o serviço de descoberta automática interna URI para apontar para o endereço IP virtual (VIP) associado com o respectivo serviço virtual no balanceador de carga. Alguns clientes usam um FQDN dedicado para isso. Outros apenas usam o mesmo FQDN utilizado para Outlook Web App (OWA), painel de controle do Exchange (ECP), OAB e Exchange Web Services (EWS).
.jpg)
Figura 2: FQDN para o serviço de descoberta automática interna URI.
Atualizações de ponto de extremidade
**P.**Nós temos uma solução resiliente do site do Exchange 2010 com um primário e failover datacenter. Recentemente fizemos uma alternância de datacenter planejada para verificar se as etapas no nosso plano de recuperação de desastres de datacenter. Durante a transição, percebemos que algo. Embora clientes Outlook internos poderiam conectar-se muito bem após ter alterado o registro DNS para a matriz de CAS no data center primário para que ele apontou para a matriz de CAS no data center de failover, o ponto de extremidade de conexão nunca foi atualizado nos clientes.
Quando a matriz de CAS não está disponível no data center primário e o registro DNS para essa matriz de CAS é atualizado para apontar para a matriz de CAS no data center de failover, não é esperado comportamento que o ponto de extremidade de conexão é atualizado no cliente Outlook também?
**R.**O que você vê é realmente o comportamento esperado. O ponto de extremidade de conexão não vai / não deve ser atualizado quando você altera o registro DNS para a matriz de CAS no data center primário para apontar para o endereço IP associado com a matriz de CAS no data center de failover. Como você viu-se, os clientes do Outlook conectará apenas bom, enquanto o nome de matriz de CAS resolve acessível endereço IP.
Este comportamento faz coisas menos doloroso ao fazer a transição para a datacenter. Você só precisa tomar cuidado de replicação do DNS — não é necessário se preocupar se um cliente Outlook teve seu perfil atualizado.
Atualizações de perfil
**P.**Temos vários sites do Active Directory, todos com servidores Exchange 2010 SP1. Cada site tem três funções de CAS. Para distribuir o tráfego de cliente entre as três funções de CAS em cada site, criamos CAS arrays e DAGs para fornecer flexibilidade de caixa de correio.
Às vezes, um usuário move permanentemente de um local físico para outro. Neste evento, podemos mover caixa de correio do usuário para um banco de dados de caixa de correio no novo site. Porque nós mover caixa de correio de usuário de um banco de dados de caixa de correio com um valor de servidor Acesso para cliente RPC diferente do valor do banco de dados de destino, que seria de esperar perfil do Outlook do usuário será atualizado para refletir o valor de RPC CAS do banco de dados de caixa de correio de destino (consulte Figura 3).
.jpg)
Figura 3: valor de servidor Acesso para cliente RPC para um banco de dados de caixa de correio.
Não temos quaisquer clientes Outlook 2003, apenas 2007 e 2010. Até agora, nós só fui capazes de ter o perfil do Outlook atualizado executando uma reparação de perfil.
**R.**Eu entendo como você esperaria o perfil do Outlook para atualizar automaticamente durante um movimento de cross-site de caixa de correio de um banco de dados de caixa de correio com um valor de CAS de RPC para um banco de dados de caixa de correio de destino com outro valor de CAS de RPC. Na verdade, porém, o que você está enfrentando é o comportamento esperado.
A razão para este comportamento tem a ver com o fato de que a fonte de CAS (matriz) determina qual caixa de correio deve acessar com base nas propriedades do Active Directory. Se o Active Directory é atualizado, ele nunca falar com o banco de dados de caixa de correio errado e nunca receber resposta anecWrongServer, que é necessário para acionar uma atualização de perfil do Outlook. O grupo de produtos Exchange está plenamente consciente desse comportamento longe do ideal. Não há nenhuma palavra ainda sobre quando — ou mesmo se — isso será corrigido.
Confiar mas verificar
**P.**Nós estamos tentando configurar a Federação entre nosso grupo Exchange 2010 e outra. Eu me lembro que você precisa usar um certificado confiável de uma autoridade de certificação de terceiros (CA) para definir relações de confiança de federação entre organizações do Exchange 2010. Eu queria verificar se isso é verdade.
**R.**Você provavelmente Leia isto antes de 2010 Exchange SP1 foram lançadas. Com o Exchange 2010 RTM, você precisou de um certificado de uma CA de terceiros para obter uma relação de confiança de Federação trabalhando entre duas organizações do Exchange 2010.
No entanto, isto mudou com o lançamento do SP1 do Exchange 2010. Com o Exchange 2010 SP1, você pode usar um certificado auto-assinado ou um certificado emitido por uma PKI interna. Na verdade, o Assistente de "Nova confiança de Federação" automaticamente cria e instala um certificado auto-assinado especificamente para fins de confiança de Federação (ver Figura 4).
.jpg)
Figura 4 O novo certificado auto-assinado criado pelo Assistente de "nova Federação Trust".
.jpg)
Henrik Waltheré um Microsoft Certified Master: Exchange 2007 e Exchange MVP com mais de 15 anos de experiência em negócios de TI. Ele trabalha como arquiteto de tecnologia para Timengo Consulting (um Microsoft Gold Certified Partner na Dinamarca) e como redator técnico da Biblioso Corp. (uma empresa norte-americana especializada em gestão de serviços de documentação e localização).