Récupération d’urgence d’Azure Virtual Desktop

  • Article

Pour garantir la sécurité des données de votre organisation, vous devez adopter une stratégie de continuité d'activité et de reprise d’activité (BCDR). Une stratégie BCDR solide permet aux applications et aux charges de travail de fonctionner pendant les interruptions de service planifiées et non planifiées. Ces plans doivent inclure les machines virtuelles hôtes de session gérées par les clients, par opposition au service Azure Virtual Desktop qui est géré par Microsoft. Pour plus d’informations sur les zones de gestion, consultez Concepts relatifs à la reprise d’activité Azure Virtual Desktop.

Le service Azure Virtual Desktop a été conçu pour fournir une haute disponibilité. Azure Virtual Desktop est un service global géré par Microsoft. Plusieurs instances de ses composants indépendants sont réparties dans différentes régions Azure. En cas de panne inattendue avec l’un des composants, soit votre trafic est redirigé vers l’une des instances restantes, soit Microsoft commence un basculement complet vers une infrastructure redondante d’une autre région Azure.

Pour garantir que les utilisateurs pourront se connecter en cas de panne régionale dans les machines virtuelles hôtes de session, vous devez concevoir votre infrastructure en prenant en compte la nécessité d’une haute disponibilité et d’une reprise d’activité. Un plan de reprise d’activité classique inclut la réplication des machines virtuelles vers un autre emplacement. En cas de panne, le site principal bascule vers les machines virtuelles répliquées dans l’emplacement secondaire. Les utilisateurs peuvent continuer à accéder aux applications à partir de l’emplacement secondaire sans interruption. En plus de la réplication de machine virtuelle, vous devez conserver les identités utilisateur accessibles à l’emplacement secondaire. Si vous utilisez des conteneurs de profils, vous devrez également les répliquer. Enfin, assurez-vous que vos applications d’entreprise qui reposent sur les données de l’emplacement principal peuvent basculer avec le reste des données.

Pour résumer, pour maintenir les utilisateurs connectés pendant une panne, vous devez effectuer les opérations suivantes :

  • Répliquez les machines virtuelles dans un emplacement secondaire.
  • Si vous utilisez des conteneurs de profils, configurez la réplication des données dans l’emplacement secondaire.
  • Vérifiez que les identités des utilisateurs que vous configurez dans l’emplacement principal sont disponibles dans l’emplacement secondaire. Pour garantir la disponibilité, vérifiez que vos contrôleurs de domaine Active Directory sont disponibles dans ou à partir de l’emplacement secondaire.
  • Vérifiez que toutes les applications métier et les données de votre emplacement principal sont également basculées vers l’emplacement secondaire.

Plans de reprise d’activité actif-passif et actif-actif

Il existe deux types d’infrastructures de reprise d’activité : actif-passif et actif-actif. Chaque type d’infrastructure fonctionne de manière différente. Voyons donc ces différences.

Les plans de type actif-passif conviennent lorsque vous disposez d’une région comprenant un ensemble de ressources actives et d’une autre qui est désactivée jusqu’à ce que vous en ayez besoin (passive). Si la région active est mise hors connexion par une panne ou un sinistre, l’organisation peut basculer vers la région passive en l’activant et en redirigeant tous les utilisateurs.

Une autre option est le déploiement de type actif-actif, où vous utilisez les deux ensembles d’infrastructure en même temps. Même si certains utilisateurs peuvent être affectés par les pannes, l’impact sera limité aux utilisateurs de la région qui connaît la panne. Les utilisateurs de l’autre région qui sont toujours en ligne ne seront pas affectés, et la reprise d’activité sera limitée aux utilisateurs de la région affectée qui se reconnectent à la région active qui est fonctionnelle. Les déploiements de type actif-actif peuvent prendre de nombreuses formes, notamment :

  • Surprovisionner l’infrastructure dans chaque région pour prendre en charge les utilisateurs affectés en cas de panne de l’une des régions. Un inconvénient potentiel de cette méthode est que la gestion des ressources supplémentaires coûte plus cher.
  • Avoir des hôtes de session supplémentaires dans les deux régions actives, mais les libérer quand ils ne sont pas nécessaires, ce qui réduit les coûts.
  • Provisionner uniquement une nouvelle infrastructure pendant la reprise d’activité et autoriser les utilisateurs affectés à se connecter aux hôtes de session nouvellement provisionnés. Cette méthode nécessite des tests réguliers avec des outils IaC afin de pouvoir déployer la nouvelle infrastructure aussi rapidement que possible lors d’un sinistre.

Pour plus d’informations sur les types de plans de reprise d’activité que vous pouvez utiliser, consultez Concepts relatifs à la reprise d’activité Azure Virtual Desktop.

Identifier la méthode qui convient le mieux à votre organisation est la première chose à faire avant de commencer. Une fois votre plan en place, vous pouvez commencer à créer votre plan de reprise d’activité.

Réplication de machines virtuelles

Tout d’abord, vous devez répliquer vos machines virtuelles vers l’emplacement secondaire. Vos options pour ce faire dépendent de la façon dont vos machines virtuelles sont configurées :

  • Vous pouvez configurer la réplication pour toutes vos machines virtuelles situées dans les pools d’hôtes personnels et groupés avec Azure Site Recovery. Pour plus d’informations sur le fonctionnement de ce processus, consultez Répliquer des machines virtuelles Azure dans une autre région Azure. Toutefois, si vous avez groupé des pools d’hôtes que vous avez créés à partir d’une même image et que vous n’avez pas de données utilisateur personnelles stockées localement, vous pouvez choisir de ne pas les répliquer. Au lieu de cela, vous avez la possibilité de créer les machines virtuelles à l’avance et de les mettre hors tension. Vous pouvez également choisir de provisionner uniquement de nouvelles machines virtuelles dans la région secondaire pendant un incident. Si vous choisissez ces méthodes, il ne vous restera qu’à configurer un pool d’hôtes et les groupes d’applications et espaces de travail qui lui sont associés.
  • Vous pouvez créer un pool hôte dans la région de basculement tout en laissant toutes les ressources de votre emplacement de basculement désactivées. Pour cette méthode, vous devez configurer de nouveaux groupes d’applications et espaces de travail dans la région de basculement. Vous pouvez ensuite utiliser un plan Azure Site Recovery pour activer les pools d’hôtes.
  • Vous pouvez créer un pool hôte rempli de machines virtuelles créées à la fois dans les régions principale et de basculement, tout en gardant les machines virtuelles dans la région de basculement désactivées. Dans ce cas, il vous suffit de configurer un pool d’hôtes et les groupes d’applications et espaces de travail associés. Vous pouvez utiliser un plan Azure Site Recovery pour activer les pools d’hôtes avec cette méthode.

Nous vous recommandons d’utiliser Azure Site Recovery pour gérer la réplication des machines virtuelles vers d’autres emplacements Azure, comme décrit dans Architecture de récupération d’urgence Azure vers Azure. Nous vous recommandons d’utiliser Azure Site Recovery pour les pools d’hôtes personnels, car, tout comme leur nom l’indique, les pools d’hôtes personnels ont tendance à contenir des données d’ordre personnel. Azure Site Recovery prend en charge les références SKU basées sur les serveurs et basées sur les clients.

Si vous utilisez Azure Site Recovery, vous n’avez pas besoin d’inscrire ces machines virtuelles manuellement. L’agent Azure Virtual Desktop de la machine virtuelle secondaire utilise automatiquement le dernier jeton de sécurité pour se connecter à l’instance de service la plus proche. La machine virtuelle (hôte de session) dans l’emplacement secondaire devient automatiquement une partie du pool d’hôtes. L’utilisateur final doit se reconnecter en cours de route, mais en dehors de cela, aucune autre opération manuelle n’est nécessaire.

S’il existe des connexions utilisateur existantes pendant la panne, avant que l’administrateur puisse démarrer le basculement vers la région secondaire, vous devez mettre fin aux connexions utilisateur dans la région actuelle.

Pour déconnecter les utilisateurs dans Azure Virtual Desktop (classique), exécutez cette cmdlet :

Invoke-RdsUserSessionLogoff

Pour déconnecter les utilisateurs dans Azure Virtual Desktop, exécutez cette applet de commande :

Remove-AzWvdUserSession

Une fois que vous avez déconnecté tous les utilisateurs de la région primaire, vous pouvez basculer les machines virtuelles dans la région primaire et permettre aux utilisateurs de se connecter aux machines virtuelles de la région secondaire.

Réseau virtuel

Ensuite, envisagez la connectivité réseau pendant la panne. Vous devez vous assurer que vous avez configuré un réseau virtuel (VNET) dans votre région secondaire. Si vos utilisateurs doivent accéder à des ressources locales, vous devez configurer ce réseau virtuel pour y accéder. Vous pouvez établir des connexions locales avec un VPN, ExpressRoute ou un Virtual WAN.

Nous vous recommandons d’utiliser Azure Site Recovery pour configurer le réseau virtuel dans la région de basculement, car il conserve les paramètres de votre réseau principal et n’a pas besoin de peering.

Identités utilisateur

Ensuite, assurez-vous que le contrôleur de domaine est disponible à l’emplacement secondaire.

Il existe trois façons de maintenir la disponibilité du contrôleur de domaine :

  • Avoir un ou plusieurs contrôleurs de domaine Active Directory dans l’emplacement secondaire
  • Utiliser un contrôleur de domaine Active Directory local
  • Répliquer un contrôleur de domaine Active Directory à l’aide d’Azure Site Recovery

Profils utilisateur

Nous vous recommandons d’utiliser FSLogix pour gérer les profils utilisateur. Pour plus d’informations, consultez l’article Option de continuité des activités et récupération d’urgence pour FSLogix.

Sauvegarde de vos données

Vous avez également la possibilité de sauvegarder vos données. Vous pouvez choisir l’une des méthodes suivantes pour sauvegarder vos données Azure Virtual Desktop :

  • Pour les données de calcul, nous vous recommandons de sauvegarder uniquement les pools d’hôtes personnels avec la Sauvegarde Azure.
  • Pour les données de stockage, la solution de sauvegarde recommandée varie en fonction du stockage principal que vous avez utilisé pour stocker les profils utilisateur :

Dépendances d’application

Enfin, assurez-vous que toutes les applications d’entreprise qui reposent sur les données situées dans la région primaire peuvent basculer vers l’emplacement secondaire. Veillez également à configurer les paramètres que les applications doivent utiliser dans le nouvel emplacement. Par exemple, si une des applications dépend du serveur principal SQL, veillez à répliquer SQL dans l’emplacement secondaire. Vous devez configurer l’application pour qu’elle utilise l’emplacement secondaire dans le cadre du processus de basculement ou de sa configuration par défaut. Vous pouvez modéliser des dépendances d’application sur des plans Azure Site Recovery. Pour plus d’informations, consultez À propos des plans de récupération.

Tests de récupération d'urgence

Une fois que vous avez fini de configurer la récupération d’urgence, vous pouvez tester votre plan pour vous assurer qu’il fonctionne.

Voici quelques suggestions pour tester votre plan :

  • Si les machines virtuelles de test ont accès à Internet, elles prennent le relais des hôtes de session existants pour les nouvelles connexions, mais toutes les connexions existantes à l’hôte de session d’origine restent actives. Assurez-vous que l’administrateur exécutant le test déconnecte tous les utilisateurs actifs avant de tester le plan.
  • Vous ne devriez effectuer des tests de récupération d’urgence complets qu’au cours d’une fenêtre de maintenance pour ne pas perturber vos utilisateurs.
  • Vérifiez que votre test couvre toutes les applications et données vitales pour l’entreprise.
  • Nous vous recommandons de basculer uniquement jusqu’à 100 machines virtuelles à la fois. Si vous avez plus de machines virtuelles, nous vous recommandons de les faire basculer par lots séparés de 10 minutes.

Étapes suivantes

Si vous avez des questions sur la sécurisation de vos données en plus de la planification en prévision des pannes, consultez notre guide de sécurité.