Resultados do teste

 

Tópico modificado em: 2011-03-02

Este tópico descreve os resultados dos testes da Microsoft da solução de failover proposta nesta seção.

Latência de Link de Site Central

Usamos um simulador de latência de rede para apresentar a latência no link WAN simulado entre Norte e Sul. A topologia recomendada tem suporte para uma latência máxima de 20 ms entre os locais geográficos. Melhorias na arquitetura do Lync Server 2010 permitem que a latência seja aumentada além do valor máximo de 15 ms permitido na topologia de resiliência de site metropolitado do Microsoft Office Communications Server 2007 R2.

• 15 ms   Começamos introduzindo uma latência de ida e volta de 15 ms nos dois caminhos de rede entre os dois sites e o caminho de dados usado para replicação de dados entre os dois sites. A topologia continuava operando sem problema nessas condições e com menos carga.

• 20 ms   Em seguida, começamos a aumentar a latência. Na latência de ida e volta de 20 ms para tráfego de rede e dados, a topologia continuou a operar sem problemas. 20 ms é a latência máxima de ida e volta aceita para essa topologia no Lync Server 2010.

  Importante:
  A Microsoft não dará suporte a soluções cuja latência de rede e dados excede 20 ms.

• 30 ms Na latência de ida e volta de 30 ms, começamos a perceber degradação de desempenho. Especificamente, as filas de mensagens para arquivamento e monitoramento de bancos de dados começaram a crescer. Como resultado desses aumentos de latência, a experiência do usuário também foi deteriorada. O tempo de entrada e o tempo de criação da conferência também foram aumentados, e a experiência de A/V se degradou significativamente. Por esses motivos, a Microsoft não oferece suporte a uma solução onde a latência de ida e volta excedeu 20 ms.

Failover

Como mencionado anteriormente, todos os clusters do Windows Server 2008 R2 na topologia usou um quorum de Maioria dos Nós e Compartilhamentos de Arquivos. Como resultado, para simular o failover de site, tivemos que isolar todos os servidores e clusters, perdendo a conectividade com o site Sul e o site de testemunha. Usamos um desligamento "sujo" de todos os servidores no local Norte.

Os resultados e as observações após falha do site do Norte são:

• O nó de cluster passivo do SQL Server tornou-se ativo em minutos. A quantidade exata de tempo pode variar e depende dos detalhes do ambiente. Usuários internos, conectados ao site do Norte, foram desconectados e conectados novamente de forma automática. Durante o failover, a presença não foi atualizada e novas ações, como novas sessões de mensagens Instantâneas ou conferências, falharam com erros apropriados. Nenhum outro erro ocorreu depois que o failover foi concluído.

• Enquanto há um caminho de rede válido entre pontos, as chamadas ponto a ponto em andamento continuaram sem interrupção.

• As chamadas UC-PSTN foram desconectadas se o gateway que dá suporte à chamada se tornou indisponível. Nesse caso, os usuários poderão restabelecer a chamada manualmente.

• Os usuários do Lync 2010 conectados ao site do Norte foram desconectados e reconectados automaticamente ao site do Sul dentro de minutos. Em seguida, os usuários puderam continuar como antes.

• Para reconectar, os usuários do cliente Chat em Grupo precisaram sair e entrar novamente. O serviço de Canal de Chat de Grupo e o serviço de Pesquisa no site do Sul, que normalmente foram interrompidos ou desabilitados no site, precisaram ser iniciados manualmente.

• Conferências hospedadas no site do Norte falharam automaticamente no site do Sul. Foi solicitado que todos os usuários retornassem à conferência após a conclusão do failover. Os clientes puderam reingressar na reunião. A gravação da reunião continuou durante o failover. O arquivamento foi interrompido até que o Servidor de Arquivamento em espera automática foi colocado online.

• O trabalho de capacidade de gerenciamento continuou enquanto o site do Norte está desativado. Por exemplo, os usuários puderam ser movidos do Aparelho de Filial Persistente para o pool de Front-End.

• Depois que o site do Norte ficou offline, os clusters do SQL Server e os clusters de compartilhamento de arquivo no site do Sul ficaram online em alguns minutos.

• A duração de failover do site conforme observado em nossos testes foi apenas de alguns minutos.

Failback

Para fins de teste, definimos o failback como restauração de toda a funcionalidade para o site do Norte, de forma que os usuários possam reconectar a servidores nesse site. Após a restauração do site do Norte, todos os recursos de cluster foram movidos de volta para seus nós no site do Norte.

Recomendamos executar o failback de forma controlada, preferencialmente durante de descanso, pois algumas interrupções de usuário podem acontecer durante os procedimentos de failback. Resultados e observações após o failback do site do Norte são:

• Antes que os recursos de cluster possam ser movidos de volta para seus nós no site do Norte, o armazenamento teve que ser totalmente ressincronizado. Se o armazenamento não tiver sido ressincronizado, os clusters não ficarão online. A ressincronização do armazenamento aconteceu automaticamente.

• Para garantir o impacto mínimo do usuário, os clusters foram definidos para não fazer failback automaticamente. Nossa recomendação é adiar o failback até a próxima janela de manutenção depois de garantir que o armazenamento foi totalmente ressincronizado.

• Os Servidores Front-Ends ficarão online quando puderem conectar aos Serviços de Domínio do Active Directory. Se o Banco de Dados de Back-End ainda não estiver disponível quando os Servidores Front-End ficarem online, os usuários terão a funcionalidade limitada.

  Depois que os Servidores Front-End no site do Norte estiverem online, novas conexões serão roteadas para eles. Os usuários que estão online e que normalmente se conectam por meio de Servidores Front-End no site do Norte, serão desconectados e reconectarão no servidor de site do Norte usual.

  Se você desejar impedir que os Servidores Front-End no site do Norte fiquem online automaticamente - por exemplo, se você desejar maior controle sobre todo o processo ou se a latência entre os dois locais não tem sido restaurada para níveis aceitáveis - recomendamos desligar os Servidores Front-End.

• Duração de failback do site conforme observado em nossos testes foi em um minuto.