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

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 vous suffit de 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 hôte 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

Réplication des données de profil d’utilisateur et d’application

Si vous utilisez des conteneurs de profils, l’étape suivante consiste à répliquer les données vers l’emplacement secondaire.

Vous avez le choix entre cinq options pour stocker les profils FSLogix :

  • Espaces de stockage directs (S2D)
  • Lecteurs réseau (machine virtuelle avec lecteurs supplémentaires)
  • Azure Files
  • Azure NetApp Files
  • Services de stockage tiers disponibles sur la Place de marché Azure

Pour plus d’informations, consultez Options de stockage des conteneurs de profils FSLogix dans Azure Virtual Desktop.

Si vous configurez la reprise d’activité pour des profils utilisateur, vous devez utiliser le service de stockage pour répliquer les données dans une autre région ou utiliser FSLogix Cloud Cache pour gérer la réplication sans utiliser le service de stockage sous-jacent pour répliquer les données.

Dans les sections suivantes, nous allons voir les cinq options qui sont disponibles pour les plans de reprise d’activité de profil utilisateur.

Réplication Azure native

Pour configurer la reprise d’activité, vous pouvez configurer la réplication Azure native. Par exemple, vous pouvez configurer la réplication Azure native avec la réplication de compte de stockage Azure Files standard, la réplication Azure NetApp Files ou Azure File Sync pour les serveurs de fichiers.

Notes

La réplication NetApp est automatique une fois que vous avez effectué la configuration initiale. Avec les plans Azure Site Recovery, vous pouvez ajouter des pré-scripts et post-scripts pour basculer des ressources autres que des machines virtuelles et répliquer des ressources de stockage Azure.

Espaces de stockage direct

Vous pouvez également utiliser des espaces de stockage direct. Étant donné que les espaces de stockage direct gèrent la réplication entre régions en interne, vous n’avez pas besoin de configurer manuellement le chemin secondaire.

Lecteurs réseau (machine virtuelle avec lecteurs supplémentaires)

Vous pouvez également utiliser des machines virtuelles avec des lecteurs supplémentaires pour la reprise d’activité. Si vous répliquez les machines virtuelles de stockage réseau à l’aide d’Azure Site Recovery comme machines virtuelles d’hôte de session, la reprise d’activité conservera le même chemin, ce qui signifie que vous n’avez pas besoin de reconfigurer FSLogix.

Azure Files

Azure Files prend en charge la réplication asynchrone entre les régions que vous pouvez spécifier lors de la création du compte de stockage. Si la nature asynchrone d’Azure Files couvre déjà vos objectifs de reprise d’activité, vous n’avez pas besoin de procéder à une configuration supplémentaire.

Si vous avez besoin d’une réplication synchrone pour réduire la perte de données, nous vous recommandons d’utiliser FSLogix Cloud Cache à la place.

Notes

Cette section ne couvre pas le mécanisme d’authentification par basculement pour Azure Files.

Azure NetApp Files

Vous pouvez également utiliser Azure NetApp Files pour répliquer vos ressources Azure. Pour en savoir plus sur Azure NetApp Files, consultez Créer un peering de réplication pour Azure NetApp Files.

Configuration de FSLogix

L’agent FSLogix peut prendre en charge plusieurs emplacements de profil à l’aide de l’option VHDLocations standard. Cette méthode n’a rien à voir avec le cache cloud. Par conséquent, si vous préférez utiliser le cache, passez directement à FSLogix Cloud Cache. Cette option ne réplique pas non plus les données, mais vous permet plutôt d’accéder à plusieurs fournisseurs de stockage que l’agent FSLogix peut examiner pour trouver ou créer votre profil utilisateur. Cette option nécessite la réplication du stockage afin que le profil puisse être disponible dans la région secondaire.

Pour configurer les entrées du Registre :

  1. Ouvrez l’Éditeur du Registre.

  2. Accédez à Computer>HKEY_LOCAL_MACHINE>SOFTWARE>FSLogix>Profiles.

    A screenshot of the Profiles window in the Registry Editor. VHDLocation is selected.

  3. Cliquez avec le bouton droit sur VHDLocations, puis sélectionnez Modifier les chaînes multiples.

    A screenshot of the Edit Multi-String window. The value data lists the Centrual US and East US locations.

  4. Dans le champ Données de valeur, entrez les emplacements que vous souhaitez utiliser.

  5. Quand vous avez terminé, sélectionnez OK.

Si le premier emplacement n’est pas disponible, l’agent FSLogix bascule automatiquement vers le deuxième, et ainsi de suite.

Nous vous recommandons de configurer le paramètre de Registre VHDLocation de l’agent FSLogix avec les deux emplacements de stockage dans les deux emplacements Azure que vous avez déployés. Pour configurer le paramètre de Registre VHDLocation, vous devez configurer deux stratégies de groupe différentes. La première stratégie de groupe consiste à utiliser les hôtes de session situés dans la région principale avec les emplacements de stockage correspondants, le principal d’abord, puis le secondaire. La deuxième stratégie de groupe consiste à utiliser les hôtes de session de l’emplacement secondaire avec les options de stockage inversées, afin que l’emplacement de stockage secondaire soit listé en premier uniquement pour les machines virtuelles du site secondaire ou de basculement.

Par exemple, supposons que vos machines virtuelles d’hôte de session principales se trouvent dans la région USA Centre, et que le conteneur de profil se trouve également dans la région USA Centre pour des raisons de performances. Dans ce cas, vous allez configurer l’agent FSLogix avec un chemin permettant d’accéder au stockage de la région USA Centre qui est listée en premier. Ensuite, vous allez configurer le service de stockage que vous avez utilisé dans l’exemple précédent pour répliquer vers la région USA Ouest. Si le chemin vers la région USA Centre échoue, l’agent tentera de charger le profil dans la région USA Ouest à la place.

VHDLocations

VHDLocations contribue à la continuité d’activité. Toutefois, ce paramètre n’a pas été conçu pour faire partie d’une solution complète de haute disponibilité ou de reprise d’activité. Le paramètre VHDLocations permet aux utilisateurs d’utiliser un profil répliqué ou nouveau en cas de sinistre, ce qui permet aux utilisateurs de rester productifs même en cas de panne.

Nous allons voir comment fonctionne VHDLocations, ainsi que certains éléments à prendre en compte si vous souhaitez intégrer VHDLocations à votre stratégie de reprise d’urgence :

  • Si le stockage principal n’est pas disponible pour une raison quelconque et qu’un utilisateur se connecte, l’agent FSLogix ne pourra pas accéder au profil utilisateur existant à partir de ce partage principal. L’utilisateur pourra toujours se connecter, mais FSLogix utilisera le profil qu’il trouve dans l’emplacement de stockage secondaire (si vous l’avez déjà répliqué avec la réplication de stockage) ou créera un profil sur le partage secondaire. Étant donné que l’utilisateur utilise désormais un profil répliqué ou un nouveau profil, il n’utilise pas son profil d’origine. Lorsqu’il utilise ce profil secondaire, toutes les mises à jour qu’il effectue s’appliquent uniquement au profil secondaire. Il ne pourra pas accéder à son profil d’origine tant que le stockage principal ne sera pas à nouveau disponible et qu’il ne se sera pas reconnecté.

  • Une fois le stockage principal à nouveau disponible, l’utilisateur ne pourra pas fusionner les modifications qu’il a apportées dans le profil secondaire ou le nouveau profil avec le profil d’origine. Lorsqu’un utilisateur se connecte une fois que le partage principal est à nouveau disponible, il peut utiliser son profil d’origine tel qu’il était avant le sinistre. Toutes les modifications qu’il a apportées dans le profil secondaire ou le nouveau profil pendant l’incident seront perdues.

FSLogix Cloud Cache

FSLogix prend en charge la réplication des conteneurs utilisateur et des conteneurs Office à partir de l’agent qui s’exécute sur l’hôte de session. Même si vous devrez déployer plusieurs fournisseurs de stockage dans différentes régions pour stocker les profils répliqués, vous n’aurez pas besoin de configurer les fonctionnalités de réplication du service de stockage avec plusieurs entrées comme vous l’avez fait avec les paramètres VHDLocations de la section précédente. Toutefois, avant de commencer à configurer FSLogix Cloud Cache, vous devez savoir que cette méthode nécessite un traitement et un espace de stockage supplémentaires sur l’hôte de session. Avant de commencer, vous devez lire Cache Cloud pour créer la résilience et la disponibilité.

Vous pouvez configurer FSLogix Cloud Cache directement dans le Registre en vous basant sur l’exemple VHDLocations de la section précédente. Toutefois, nous vous recommandons plutôt de configurer Cloud Cache à l’aide d’une stratégie de groupe. Pour créer ou modifier un objet de stratégie de groupe, accédez à Configuration ordinateur>Modèles d’administration>FSLogix>Conteneurs de profils (et Conteneurs Office 365 si nécessaire) > Cloud Cache - Emplacements Cloud Cache. Une fois que vous aurez créé ou modifié votre objet de stratégie, vous devrez l’activer, puis lister tous les emplacements du fournisseur de stockage vers lesquels FSLogix doit le répliquer, comme illustré dans l’image suivante.

A screenshot of the FSLogix Cloud Cache Group Policy Cloud Cache Locations is selected.

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é.