Identifier le scénario correct de récupération d’urgence
Pour aider à limiter l’impact d’une défaillance du centre de données ou encore d’une panne régionale, votre organisation doit préparer la protection appropriée pour la récupération d’urgence. La définition de la stratégie de protection appropriée dépend principalement de différents scénarios d’échec susceptibles d’affecter les fonctionnalités d’Azure Virtual Desktop.
Objectifs et métriques
Le processus de récupération d’urgence nécessite une coordination entre chacune des procédures entreprises pour rétablir le fonctionnement complet d’une organisation. Ce qui rassemble collectivement ces procédures, c’est la présence d’objectifs de niveau de service communs et clairement définis. Les services de récupération d’urgence doivent inclure les métriques suivantes :
- Objectif de point de récupération (RPO): quantité minimale autorisée de données que vous devez remettre aux clients pour le service en fonction des ressources sauvegardées considérées comme étant récupérées. À l’inverse, ce montant peut être considéré comme la perte de données maximale acceptable, exprimée sous la forme d’un pourcentage soustrait de 100.
- Objectif de temps de récupération (RTO) : fenêtre maximale autorisée pour un processus de restauration, qui peut également être considérée comme une mesure du temps d’arrêt que l’organisation est prête à se permettre.
- Période de rétention: période maximale autorisée de conservation d’un jeu de sauvegarde avant qu’il ne doive être actualisé et remplacé.
Le RPO et le RTO peuvent être considérés comme étant équilibrés les uns par rapport aux autres, de sorte qu’un client puisse décider d’autoriser des temps de récupération plus longs afin d’obtenir des points de récupération plus élevés. Si le temps de récupération est un problème pour un client en raison de la bande passante disponible ou du risque de temps d’arrêt, le client peut ne pas parvenir à un RPO élevé.
Le reste de l’unité explore trois scénarios d’échec différents et explique comment préparer la continuité d’activité et la récupération d’urgence (BCDR) pour Azure Virtual Desktop :
- Scenario 1: Altération locale des données, métadonnées ou ressources
- Scenario 2 : Un seul centre de données de défaillance de zone de disponibilité au sein d’une région Azure
- Scenario 3 : Panne dans la région Azure
Remarque
Pour en savoir plus sur la protection des composants individuels d’Azure Virtual Desktop, consultez la section « En savoir plus » dans l’unité Résumé de ce module.
Scenario 1: Altération locale des données, métadonnées ou ressources
Supposons que votre environnement Azure Virtual Desktop soit affecté par une défaillance de l’hôte de session ou une altération du profil FSLogix. Dans de telles situations, la méthode de récupération la plus courante consiste à restaurer les profils à partir d’une sauvegarde ou à reconstruire l’hôte de session. Cette unité examine la façon dont chacune de ces méthodes s’applique à chaque composant d’environnement Azure Virtual Desktop.
Service Azure Virtual Desktop
Le service Azure Virtual Desktop reste entièrement fonctionnel et n’est pas affecté par ces types d’échecs. Microsoft est responsable de la sauvegarde et de l’exécution de tous les éléments dans le Contrat de niveau de service (SLA) fourni.
AD DS et Microsoft Entra Domain Services
Active Directory contrôleurs de domaine sont des composants essentiels d’Azure Virtual Desktop et doivent toujours être accessibles. Pour vous assurer que l’échec n’affecte pas leurs fonctionnalités, assurez-vous d’avoir créé plusieurs contrôleurs de domaine. Si vous avez des contrôleurs de domaine dans des machines virtuelles Azure, vérifiez que vous les avez configurés pour qu’ils se trouvent dans le même groupe à haute disponibilité. Si vos contrôleurs de domaine s’exécutent en tant qu’ordinateurs locaux, vous devez concevoir la connectivité entre votre réseau local et le réseau virtuel Azure avec redondance. Utilisez Azure ExpressRoute pour gérer les connexions et les chemins redondants. Sauvegardez l’état du système Active Directory et restaurez-le si nécessaire. Si vous utilisez microsoft Entra Domain Services, Microsoft est responsable de la maintenance des contrôleurs de domaine redondants et de leur protection contre les défaillances non planifiées.
Pools d’hôtes
Les pools d’hôtes peuvent devenir indisponibles au cours normal de l’opération. Les pools d’hôtes fournissent des applications et des bureaux virtuels Azure aux utilisateurs. Ces derniers sont configurés à partir de l’image de bureau. Par conséquent, si une défaillance se produit et qu’une image de bureau est disponible, vous pouvez les recréer. Vous pouvez également utiliser un pool d’hôtes distinct pour les applications qui sont consommées via Azure Virtual Desktop. Vous devez également envisager une approche de récupération d’urgence similaire pour ce pool d’hôtes.
Réseaux virtuels
Les réseaux virtuels sont des services gérés et ne sont pas affectés par ce type de défaillance. Le réseau virtuel Azure fournit un bloc d’adresses IP privé dans lequel vous pouvez déployer toutes vos ressources pour une connectivité privée, puis sécuriser ces ressources dans une limite. Par conséquent, un réseau virtuel ne tombe jamais en panne ou ne subit jamais de panne en cas de défaillance locale de la ressource dans un centre de données unique.
Profils FSLogix et attachement d’application MSIX
Selon votre choix de technologie de stockage FSLogix, vous pouvez configurer Sauvegarde Azure pour Azure Files partages et Azure NetApp Files captures instantanées. Vous pouvez également utiliser le service de sauvegarde pour protéger les fichiers et dossiers sur les machines virtuelles du serveur.
Des images
Vous pouvez souvent apporter des modifications aux images de bureau pendant la maintenance normale de l’environnement Azure Virtual Desktop. Vous devez conserver des sauvegardes d’images afin de pouvoir les récupérer rapidement en cas d’altération.
Scenario 2 : Un seul centre de données de défaillance de zone de disponibilité au sein d’une région Azure
Une région Azure est un ensemble de centres de données déployés dans un périmètre défini par une latence et connectés via un réseau régional dédié à faible latence. En cas de panne d’un centre de données ou d’une zone dans une région Azure, votre BCDR pour Azure Virtual Desktop doit inclure les recommandations répertoriées dans les sections suivantes.
Service Azure Virtual Desktop
Le service Azure Virtual Desktop reste entièrement fonctionnel et n’est pas affecté par ce type de défaillance. Microsoft est responsable de la restauration et de l’exécution de tous les éléments dans le contrat SLA fourni.
AD DS et Microsoft Entra Domain Services
Pour éviter une défaillance de centre de données unique, déployez au moins deux contrôleurs de domaine dans une zone de disponibilité. Si vous utilisez microsoft Entra Domain Services, Microsoft gère les deux contrôleurs de domaine de votre locataire dans une zone de disponibilité distincte, si elle est prise en charge par la région.
Pools d’hôtes
Pour la résilience des machines virtuelles du pool d’hôtes, vous pouvez déployer un pool d’hôtes Azure Virtual Desktop à l’aide de Zones de disponibilité pour les machines virtuelles. Vous pouvez distribuer des machines virtuelles dans le pool d’hôtes entre différents centres de données qui se trouvent toujours dans la même région.
Réseau virtuel
Les réseaux virtuels sont un service géré et ne sont pas affectés par ce type d’échec. Vous devez vous assurer que les ressources fiables sont toujours configurées avec une connectivité réseau appropriée. Par exemple, l’utilisation d’un équilibreur de charge de base peut être affectée par ce type de défaillance, parce qu’il ne prend pas en charge la disponibilité de la zone.
Profils FSLogix et attachement d’application MSIX
Utilisez Azure Files avec le stockage redondant interzone Premium pour tirer parti de la prise en charge des Zones de disponibilité. Dans ce scénario, les profils FSLogix et les disques durs virtuels d’attachement d’application MSIX restent disponibles en cas de panne du centre de données.
Des images
Ce type de défaillance n’affecte pas les images, car elles deviennent disponibles dans une autre zone.
Scenario 3 : Panne dans la région Azure
L’échec de régions Azure complètes est très peu probable et rare. Mais vous devez également être préparé en cas d’échec. Envisagez d’implémenter les recommandations suivantes pour implémenter BCDR pour Azure Virtual Desktop.
Service Azure Virtual Desktop
Le service Azure Virtual Desktop reste entièrement fonctionnel et n’est pas affecté par ce type de défaillance. Microsoft est responsable de la restauration et de l’exécution de tous les éléments dans le contrat SLA fourni.
AD DS et Microsoft Entra Domain Services
Pour vous préparer à ce type de défaillance, vous pouvez développer un domaine managé afin d’avoir plusieurs réplicas par locataire Microsoft Entra. Les jeux de réplicas peuvent être ajoutés à n’importe quel réseau virtuel appairé dans n’importe quelle région Azure qui prend en charge les services de domaine Microsoft Entra.
Si vous utilisez des contrôleurs de domaine locaux, vous devez configurer la connectivité au réseau virtuel dans la nouvelle région à l’aide d’un VPN, d’ExpressRoute ou d’un réseau étendu virtuel (WAN virtuel). Si vous utilisez Microsoft Entra Domain Services, vous pouvez créer un jeu de réplicas supplémentaire dans une autre région. Le réseau virtuel dans la région supplémentaire qui héberge le nouveau jeu de réplicas doit être en mesure de communiquer avec le réseau qui héberge l’ensemble principal des services de domaine Microsoft Entra. Nous vous recommandons d’utiliser le peering entre les réseaux virtuels pour la réplication intrasite entre les jeux de réplicas.
Pools d’hôtes
Vous pouvez déployer un pool d’hôtes Azure Virtual Desktop dans des configurations actif-actif et actif-passif :
Avec active-active: Avec une configuration active-active, un pool d’hôtes unique peut avoir des machines virtuelles provenant de plusieurs régions. Vous devez combiner des fonctionnalités de cache cloud pour répliquer activement le profil FSLogix d’un utilisateur dans le stockage dans plusieurs régions. Pour l’attachement d’application MSIX, utilisez une autre copie sur un partage de fichiers supplémentaire dans l’autre région. Les machines virtuelles de chaque région doivent contenir le registre de cache cloud pour spécifier les emplacements. En outre, vous devez configurer les stratégies de groupe pour accorder la priorité à l’emplacement de stockage local. Ce déploiement d’Azure Virtual Desktop offre la plus grande efficacité du point de vue de l’utilisateur. Cela est dû au fait qu’en cas d’échec, les utilisateurs de la région restante peuvent continuer à utiliser le service sans avoir à se reconnecter. Toutefois, cette configuration est plus coûteuse et plus complexe à déployer et n’est pas optimisée pour les performances.
Active-passive: Pour une configuration active-passive, vous pouvez utiliser Azure Site Recovery pour répliquer vos machines virtuelles dans la région secondaire avec vos contrôleurs de domaine. Si vous utilisez Azure Site Recovery, vous n’avez pas besoin d’inscrire les machines virtuelles manuellement. Au lieu de cela, l’agent Azure Virtual Desktop dans la machine virtuelle secondaire utilise automatiquement le jeton de sécurité le plus récent pour se connecter à l’instance de service la plus proche de celui-ci. Cela garantit que votre hôte de session rejoint automatiquement le pool d’hôtes et que l’utilisateur doit se reconnecter uniquement pour accéder à ses machines virtuelles. Pour cette configuration, vous pouvez également créer un pool d’hôtes secondaire (appelé secours actif) dans la région de basculement avec toutes les ressources désactivées. Vous pouvez ensuite utiliser un plan de récupération dans Azure Site Recovery pour activer les pools d’hôtes et créer un processus orchestré. Vous devez également créer un groupe d’applications dans la région de basculement et leur attribuer des utilisateurs.
Réseaux virtuels
Les défaillances de région ont un impact sur les réseaux virtuels et les services déployés au sein des réseaux virtuels. Vous devez planifier un réseau virtuel dans votre région secondaire. Vous pouvez créer un réseau virtuel manuellement, puis le configurer avec le peering avec le réseau principal. Vous pouvez également utiliser Azure Site Recovery pour configurer le réseau virtuel dans la région de basculement et conserver les paramètres de votre réseau principal.
Dans un bureau virtuel Azure connecté à votre réseau local, vous devez configurer le réseau virtuel dans la région secondaire avec une connectivité au réseau local.
Profils FSLogix et attachement d’application MSIX
Vous pouvez utiliser Azure NetApp Files comme option de stockage pour les profils FSXlogix et l’attachement d’application MSIX, car ils prennent en charge la réplication inter-région. Azure Files avec les performances Standard prennent également en charge la réplication inter-région. Vous pouvez configurer l’agent FSLogix pour prendre en charge plusieurs emplacements de profil, ce qui permet de garantir la disponibilité en cas d’échec. Si l’emplacement principal échoue, l’agent FSLogix est répliqué dans le cadre de la machine virtuelle Azure Site Recovery. L’agent tente automatiquement d’utiliser le chemin de profil qui pointe vers la région secondaire.
Pour le scénario actif/actif et si le RTO ou le RTA est inférieur à une journée, nous vous recommandons d’utiliser des profils FSLogix pour utiliser cloud cache. Cloud Cache est une fonctionnalité de FSLogix qui doit être spécifiquement activée et configurée. Il vous permet d’utiliser plusieurs emplacements distants, qui sont tous mis à jour en permanence pendant la session utilisateur.
Des images
Vous devez répliquer les images dans la région secondaire après chaque modification de l’image de bureau principale. Vous pouvez utiliser azure Compute Gallery pour partager des images personnalisées entre différentes régions. En cas de défaillance de la région primaire, vous pouvez utiliser des images de bureau clonées comme sources pour la création des pools d’hôtes.
Dépendances d’application
Les applications qui dépendent des ressources disponibles dans la région primaire nécessitent les mêmes ressources dans l’emplacement secondaire. Par exemple, si certaines de vos applications sont connectées avec le backend SQL déployé dans une région, veillez à répliquer SQL à l’emplacement secondaire. Pour SQL Server sur des machines virtuelles Azure, vous pouvez utiliser Azure Site Recovery. Pour SQL en tant que PaaS (Platform-as-a-service), vous pouvez utiliser des groupes de géo-réplication ou de basculement automatique actifs. Vous devez inclure ces ressources dans le plan BCDR global. En outre, vous devez inclure un plan Azure Site Recovery qui peut modéliser les dépendances d’application dans le plan de protection.