Recuperação de desastres

Você pode desenvolver e configurar implantações do XenMobile que incluem vários locais de recuperação de desastres usando uma estratégia de failover ativo-passivo.

A estratégia de recuperação de desastres recomendada discutida neste artigo consiste em:

  • Um único site ativo do XenMobile no datacenter de uma localização geográfica atendendo a todos os usuários da empresa globalmente, conhecido como o site principal.
  • Um segundo site XenMobile no datacenter de um segundo local geográfico, conhecido como site de recuperação de desastre. Este site de recuperação de desastre fornece failover de site ativo-passivo em caso de falha de um datacenter em todo o site principal. O site principal inclui o XenMobile, o banco de dados SQL, a infraestrutura do NetScaler para facilitar o failover e fornecer aos usuários acesso ao XenMobile por meio do evento de falha de conectividade no site principal.

Os servidores XenMobile no site de recuperação de desastre permanecem off-line durante as operações normais e são colocados on-line apenas em cenários de recuperação de desastre, onde é necessário um failover completo do site principal para o site de recuperação de desastre. Os SQL Servers no site de recuperação de desastre devem estar ativos e prontos para atender às conexões antes de iniciar os servidores XenMobile no site de recuperação de desastre.

Essa estratégia de recuperação de desastre depende do failover manual da camada de acesso do NetScaler por meio de alterações de DNS para rotear conexões do MDM e do MAM para o site de recuperação de desastre no caso de uma indisponibilidade.

Nota:

Para usar essa arquitetura, você deve ter um processo para backups assíncronos dos bancos de dados e alguma maneira de garantir alta disponibilidade para a infraestrutura SQL.

Processo de Failover de Recuperação de Desastres

  1. Se você estiver testando seu processo de failover de recuperação de desastre, encerre os servidores XenMobile no site principal para simular a falha do site.
  2. Altere os registros DNS públicos dos servidores XenMobile para apontar para os endereços IP externos do site de recuperação de desastre.
  3. Altere o registro DNS interno do SQL Server para apontar para o endereço IP do SQL Server do site de recuperação de desastre.
  4. Coloque os bancos de dados XenMobile SQL on-line no site de recuperação de desastre. Certifique-se de que o SQL Server e o banco de dados estejam ativos e prontos para atender às conexões dos servidores XenMobile locais ao site.
  5. Ative os servidores XenMobile no site de recuperação de desastre.

Processo de atualização do servidor XenMobile

Siga estas etapas sempre que você atualizar o XenMobile com patches e novas versões, para manter o código dos servidores principal e de recuperação de desastres uniformes.

  1. Certifique-se de que os servidores XenMobile no site principal foram corrigidos ou atualizados.
  2. Verifique se o registro DNS do SQL Server está resolvendo o banco de dados ativo do SQL Server no site principal.
  3. Coloque os servidores XenMobile do site de recuperação de desastre online. Os servidores se conectam ao banco de dados do site principal pela WAN somente durante o processo de atualização.
  4. Aplique patches e atualizações necessárias a todos os servidores XenMobile do site de recuperação de desastre.
  5. Reinicie os servidores XenMobile e confirme se o patch ou atualização foi bem-sucedido.

Diagrama da Arquitetura de Referência de Recuperação de Desastres

O diagrama a seguir mostra a arquitetura de alto nível para uma implantação de recuperação de desastre do XenMobile.

Diagrama da arquitetura de referência de recuperação de desastre

GSLB para recuperação de desastres

Um elemento-chave dessa arquitetura é o uso do Global Server Load Balancing (GSLB) para direcionar o tráfego para o data center correto.

Por padrão, o Assistente NetScaler para XenMobile configura o NetScaler Gateway de uma maneira que não permite o uso do GSLB para recuperação de desastres. Portanto, você deve executar etapas adicionais.

Como funciona o GSLB

O GSLB é, no seu núcleo, uma forma de DNS. Os dispositivos NetScaler participantes atuam como servidores DNS autoritativos e resolvem os registros DNS para o endereço IP correto (geralmente o VIP que deve receber tráfego). O dispositivo NetScaler verifica a integridade do sistema antes de responder a uma consulta DNS direcionando o tráfego para esse sistema.

Quando um registro é resolvido, a função do GSLB na resolução do tráfego é concluída. O cliente se comunica diretamente com o endereço de IP virtual (VIP) de destino. O comportamento do cliente DNS desempenha um papel importante no controle de como e quando um registro expira. Isso está em grande parte fora dos limites do sistema NetScaler. Como tal, o GSLB está sujeito às mesmas limitações que a resolução de nomes DNS. Respostas de clientes em cache; entretanto, o balanceamento de carga dessa maneira não é tão em tempo real quanto o balanceamento de carga tradicional.

A configuração do GSLB no NetScaler, incluindo sites, serviços e monitores, existe para fornecer a resolução de nomes DNS correta.

A configuração real dos servidores de publicação (nesse cenário, a configuração criada pelo assistente do NetScaler para XenMobile) não é afetada pelo GSLB. O GSLB é um serviço separado no NetScaler.

Desafios com a delegação de domínio ao usar o GSLB com o XenMobile

O assistente NetScaler para XenMobile configura o NetScaler Gateway para XenMobile. Esse assistente gera três servidores virtuais de balanceamento de carga e um servidor virtual NetScaler Gateway.

Dois dos servidores virtuais de balanceamento de carga lidam com o tráfego do MDM, nas portas 443 e 8443. O NetScaler Gateway recebe o tráfego do MAM e o encaminha para o terceiro servidor, o servidor virtual de balanceamento de carga do MAM, na porta 8443. Todo o tráfego para o servidor virtual de balanceamento de carga do MAM passa pelo NetScaler Gateway.

O servidor virtual de balanceamento de carga do MAM requer o mesmo certificado SSL dos servidores XenMobile e usa o mesmo FQDN usado para registrar dispositivos. O servidor de balanceamento de carga do MAM também usa a mesma porta (8443) que um dos servidores de balanceamento de carga do MDM. Para permitir que o tráfego seja resolvido, o Assistente NetScaler para XenMobile cria um registro DNS local no NetScaler Gateway. O registro DNS corresponde ao FQDN usado para registrar dispositivos.

Essa configuração é efetiva quando o URL do servidor XenMobile não é uma URL de domínio do GSLB. Se uma URL de domínio do GSLB for usada como a URL do XenMobile Server, conforme exigido para recuperação de desastre, o registro DNS local impedirá que o NetScaler Gateway resolva o tráfego para os servidores de balanceamento de carga do MDM.

Usando o Método CNAME para Recuperação de Desastres GSLB

Para resolver os desafios apresentados pela configuração padrão criada pelo Assistente NetScaler para XenMobile, você pode criar um registro CNAME para o FQDN do XenMobile Server no domínio pai (company.com) e apontar um registro na subzona delegada (gslb.company.com) para a qual o NetScaler é autoritativo. Isso permite a criação do registro DNS A estático para o endereço VIP de balanceamento de carga do MAM, necessário para resolver o tráfego.

  1. No DNS externo, crie um CNAME para o FQDN do XenMobile Server que aponta para o FQDN do domínio GSLB no NetScaler GSLB. Você precisa de dois domínios GSLB: um para o tráfego do MDM e outro para o tráfego do MAM (NetScaler Gateway).

    Exemplo:

    CNAME = xms.company.com IN CNAME xms.gslb.comany.com

  2. Na instância do NetScaler Gateway de cada site, crie um servidor virtual GSLB com um FQDN, para o qual o registro CNAME está apontando.

    Exemplo:

    bind gslb vserver xms-gslb -domainName xms.gslb.company.com

    Ao usar o Assistente NetScaler para XenMobile para implantar o NetScaler Gateway, use a URL do XenMobile Server ao configurar o servidor de balanceamento de carga do MAM. Isso cria um registro DNS A estático para a URL do XenMobile Server.

  3. Teste com clientes registrados no Secure Hub usando a URL do XenMobile Server (xms.company.com).

    Este exemplo usa os seguintes FQDNs:

    • xms.company.com é a URL usada pelo tráfego do MDM e é usada pelo registro de dispositivos, que é configurado neste exemplo usando o Assistente NetScaler para XenMobile.
    • xms.gslb.company.com é o FQDN do domínio GSLB para o XenMobile Server.