Product Documentation

Récupération d’urgence

Vous pouvez concevoir et configurer des déploiements XenMobile comprenant plusieurs sites pour la récupération d’urgence à l’aide d’une stratégie de basculement active-passive.

La stratégie de récupération d’urgence recommandée dans cet article comprend les éléments suivants :

  • Un seul site actif XenMobile dans le centre de données d’un lieu géographique desservant tous les utilisateurs de l’entreprise dans le monde, appelé site principal.
  • Un deuxième site XenMobile dans le centre de données d’un deuxième emplacement géographique, appelé site de récupération d’urgence. Ce site de récupération d’urgence fournit un basculement actif-passif du site si une défaillance du centre de données à l’échelle du site se produit sur le site principal. Le site principal comprend XenMobile, la base de données SQL et l’infrastructure NetScaler afin de faciliter le basculement et de fournir aux utilisateurs un accès à XenMobile via un événement d’échec de la connectivité au site principal.

Les serveurs XenMobile du site de récupération d’urgence restent hors connexion pendant les opérations normales et sont mis en ligne uniquement lors des scénarios de récupération d’urgence où le basculement complet du site (du site principal au site de récupération d’urgence) est requis. Les serveurs SQL sur le site de récupération d’urgence doivent être actifs et prêts à desservir les connexions avant que les serveurs XenMobile ne puissent être redémarrés sur le site de récupération d’urgence.

Cette stratégie de récupération d’urgence repose sur le basculement manuel du niveau d’accès NetScaler au moyen de modifications DNS pour acheminer les connexions MDM et MAM vers le site de récupération d’urgence en cas de panne.

Remarque :

Pour utiliser cette architecture, vous devez mettre en place un processus de sauvegarde asynchrone des bases de données, ainsi qu’un moyen d’assurer la haute disponibilité de l’infrastructure SQL.

Processus de basculement de récupération d’urgence

  1. Si vous testez votre processus de basculement de récupération d’urgence, arrêtez les serveurs XenMobile du site principal pour simuler une défaillance du site.
  2. Modifiez les enregistrements DNS publics des serveurs XenMobile pour qu’ils pointent vers les adresses IP externes du site de récupération d’urgence.
  3. Modifiez l’enregistrement DNS interne pour que le serveur SQL pointe sur l’adresse IP du serveur SQL du site de récupération d’urgence.
  4. Mettez les bases de données SQL XenMobile en ligne sur le site de récupération d’urgence. Assurez-vous que SQL Server et la base de données sont actifs et prêts à desservir les connexions des serveurs XenMobile locaux sur le site.
  5. Activez les serveurs XenMobile sur le site de récupération d’urgence.

Processus de mise à jour de XenMobile Server

Suivez ces étapes chaque fois que vous mettez à jour XenMobile avec des correctifs et des versions afin de préserver l’uniformité du code des serveurs principal et de récupération d’urgence.

  1. Assurez-vous que les serveurs XenMobile du site principal ont été corrigés ou mis à niveau.
  2. Assurez-vous que l’enregistrement DNS pour SQL Server est associé à la base de données SQL Server active sur le site principal.
  3. Mettez les serveurs XenMobile du site de récupération d’urgence en ligne. Les serveurs se connectent à la base de données du site principal sur le WAN uniquement au cours du processus de mise à niveau.
  4. Appliquez les correctifs et les mises à jour requis sur tous les serveurs XenMobile du site de récupération d’urgence.
  5. Redémarrez les serveurs XenMobile et vérifiez que le correctif ou la mise à niveau a été appliqué(e).

Diagramme d’architecture de référence de récupération d’urgence

Le diagramme suivant illustre l’architecture de haut niveau d’un déploiement de XenMobile pour la récupération d’urgence.

Diagramme d'architecture de référence de récupération d'urgence

GSLB pour la récupération d’urgence

Un élément clé de cette architecture est l’utilisation de GSLB (Global Server Load Balancing) pour diriger le trafic vers le centre de données approprié.

Par défaut, l’assistant NetScaler pour XenMobile configure NetScaler Gateway de manière à ne pas activer l’utilisation de GSLB pour la récupération d’urgence. Par conséquent, vous devez prendre des mesures supplémentaires.

Fonctionnement de GSLB

GSLB est à la base une forme de DNS. Les appareils NetScaler participants agissent en tant que serveurs DNS faisant autorité et associent les enregistrements DNS à l’adresse IP correcte (généralement le VIP censé recevoir le trafic). Le boîtier NetScaler vérifie l’intégrité du système avant de répondre à une requête DNS dirigeant le trafic vers ce système.

Lorsqu’un enregistrement est associé, le rôle de GSLB dans la résolution du trafic est terminé. Le client communique directement avec l’adresse IP virtuelle (VIP) cible. Le comportement du client DNS joue un rôle important dans le contrôle de la méthode et de la date d’expiration d’un enregistrement. Ce comportement se situe en grande partie en dehors des limites du système NetScaler. Ainsi, GSLB est soumis aux mêmes limitations que la résolution de noms DNS. Les clients mettent en cache les réponses. Par conséquent, l’équilibrage de charge dans ce contexte n’est pas effectué en temps réel, contrairement à l’équilibrage de charge traditionnel.

La configuration GSLB sur NetScaler, y compris les sites, les services et les moniteurs, existe afin de fournir la résolution de nom DNS correcte.

La configuration réelle des serveurs de publication (dans ce scénario, la configuration créée par l’assistant NetScaler pour XenMobile) n’est pas affectée par GSLB. GSLB est un service distinct sur NetScaler.

Défis liés à la délégation de domaine lors de l’utilisation de GSLB avec XenMobile

L’assistant NetScaler pour XenMobile permet de configurer NetScaler Gateway pour XenMobile. Cet assistant génère trois serveurs virtuels d’équilibrage de charge et un serveur virtuel NetScaler Gateway.

Deux des serveurs virtuels d’équilibrage de charge gèrent le trafic MDM sur les ports 443 et 8443. NetScaler Gateway reçoit le trafic MAM et le transmet au troisième serveur, le serveur virtuel d’équilibrage de charge MAM, sur le port 8443. Tout le trafic vers le serveur virtuel d’équilibrage de charge MAM est transmis via NetScaler Gateway.

Le serveur virtuel d’équilibrage de charge MAM nécessite le même certificat SSL que les serveurs XenMobile et utilise le même nom de domaine complet que celui utilisé lors de l’inscription d’appareils. Le serveur d’équilibrage de charge MAM utilise également le même port (8443) que l’un des serveurs d’équilibrage de charge MDM. Pour permettre la résolution du trafic, l’assistant NetScaler pour XenMobile crée un enregistrement DNS local sur NetScaler Gateway. L’enregistrement DNS correspond au nom de domaine complet utilisé lors de l’inscription d’appareils.

Cette configuration est efficace lorsque l’URL du serveur XenMobile n’est pas une URL de domaine GSLB. Si une URL de domaine GSLB est utilisée en tant qu’URL de serveur XenMobile, comme l’exige la récupération d’urgence, l’enregistrement DNS local empêche NetScaler Gateway de résoudre le trafic sur les serveurs d’équilibrage de charge MDM.

Utilisation de la méthode CNAME pour la récupération d’urgence GSLB

Pour résoudre les problèmes liés à la configuration par défaut créée par l’assistant NetScaler pour XenMobile, vous pouvez créer un enregistrement CNAME associé au nom de domaine complet du serveur XenMobile dans le domaine parent (company.com) et pointez un enregistrement vers la sous-zone déléguée (gslb.company.com) pour laquelle NetScaler fait autorité. Cela permet la création d’un enregistrement A DNS statique pour l’adresse VIP d’équilibrage de charge MAM requise pour résoudre le trafic.

  1. Sur le DNS externe, créez un CNAME associé au nom de domaine complet du serveur XenMobile qui pointe vers le nom de domaine complet du domaine GSLB sur NetScaler GSLB. Vous avez besoin de deux domaines GSLB : un pour le trafic MDM et un autre pour le trafic MAM (NetScaler Gateway).

    Exemple :

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

  2. Sur l’instance NetScaler Gateway de chaque site, créez un serveur virtuel GSLB avec un nom de domaine complet correspondant à celui indiqué par l’enregistrement CNAME.

    Exemple :

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

    Lorsque vous utilisez l’assistant NetScaler pour XenMobile pour déployer NetScaler Gateway, utilisez l’URL du serveur XenMobile lors de la configuration du serveur d’équilibrage de charge MAM. Cela permet de créer un enregistrement A DNS statique pour l’URL du serveur XenMobile.

  3. Testez avec les clients qui s’inscrivent sur Secure Hub à l’aide de l’URL du serveur XenMobile (xms.company.com).

    Cet exemple utilise les noms de domaine complets suivants :

    • xms.company.com est l’URL utilisée par le trafic MDM et par les appareils lors de l’inscription, configurée dans cet exemple à l’aide de l’assistant NetScaler pour XenMobile.
    • xms.gslb.company.com est le nom de domaine complet du domaine GSLB pour le serveur XenMobile.