Windows 365 Cross-region Disaster Recovery (CRDR) !

Comme beaucoup de services Azure en GA, Windows 365 possède lui aussi une SLA. Celle-ci est annoncée à 99.9 %. Pour un utilisateur travaillant dans son Cloud PC, il est essentiel que ce dernier soit hautement disponible pour accomplir ses tâches. Mais si un panne intervient dans un centre de données Microsoft, existe-t-il une option de reprise d’activité après sinistre pour son Cloud PC Windows 365 ? La réponse est … oui !

Avant de s’intéresser à ce nouveau service disponible via une licence add-on, faisons rapidement le tour de ce que propose Microsoft en termes de services pour Windows 365.

Quels sont les engagements Microsoft en termes de SLA ?

Voici un lien officiel Microsoft contenant les SLAs par services. Vous pouvez y télécharger le document Word dans la langue de votre choix :

Dans ce document figure une section dédiée à la SLA du service Windows 365. On y retrouve les engagements Microsoft et les indemnités financières en cas d’indisponibilité :

Quelles sont les mesures de maintien de service dans une licence Windows 365 ?

Sur la page consacrée au Cloud PC de Microsoft, on y retrouve les informations de disponibilités suivantes :

  • 99,9 % des sessions utilisateur Windows 365 Cloud PC hautement disponibles, telles que définies dans le contrat SLA Windows 365.
  • Stockage sur disque avec résilience des objets de données de onze 9.
  • Récupération d’urgence automatisée « dans la zone » pour le calcul.
  • Un objectif de point de récupération de ~0.
Microsoft Learn

Cela nous indique que Microsoft a différents mécanismes possibles dans la même zone pour prévenir des défaillances matérielles :

  • Défaillance CPU/Mémoire
  • Défaillance du réseau
  • Défaillance des disques
  • Défaillance électrique

Il ne semble pas y avoir de surcoût pour profiter de ce premier niveau de protection, et le niveau de RPO est proche de zéro :

La récupération d’urgence Windows 365 automatisée est basée sur une copie à jour du disque du système d’exploitation, avec un RPO de ~0. Par conséquent, le processus de récupération démarre automatiquement, car il n’est pas nécessaire d’accepter la perte de données associée à une récupération dans le passé.

Microsoft Learn

Quid de la SLA dans la gestion des Cloud PC (Intune + Portail) ?

Toujours dans ce même article, Microsoft nous annonce d’autres chiffres sur la gestion Intune des Cloud PC, mais également dans l’accès aux utilisateurs :

Le service de gestion des PC cloud possède une architecture régionalement redondante, conçue pour être hautement disponible, avec une durée de bon fonctionnement cible de 99,99 %. En cas de panne du service de gestion, le service a les objectifs suivants :

  • RTO de < 6 heures.
  • RPO de <30 minutes pour les modifications apportées au service de gestion.
Microsoft Learn

Qu’est que le Cross-region Restore ?

Le service appelé Cross-region Restore est connu de longue date pour la restauration des machines virtuelles Azure au travers du service Recovery Service Vault, quand celui-ci a la fonctionnalité CRR d’activée :

La restauration inter-région peut être utilisée pour restaurer des machines virtuelles Azure dans la région secondaire, qui est une région jumelée à Azure.

Vous pouvez restaurer toutes les machines virtuelles Azure pour le point de récupération sélectionné si la sauvegarde est effectuée dans la région secondaire.

Pendant la sauvegarde, les captures instantanées ne sont pas répliquées dans la région secondaire. Seules les données stockées dans le coffre sont répliquées. Ainsi, les restaurations de la région secondaire sont des restaurations de niveau coffre uniquement. L’heure de restauration de la région secondaire sera presque identique à celle du niveau coffre pour la région principale.

Microsoft Learn

Qu’est que le Cross-region Disaster Recovery (CRDR) pour Windows 365 ?

En ce 1er juillet 2024, Microsoft a annoncé la disponibilité générale de son service Cross-region Disaster Recovery pour Windows 365. Déjà disponible pour un grand nombre de services Azure, cette offre payante permet de disposer d’une sauvegarde de secours sur une seconde région Azure distante :

La récupération d’urgence inter-région de Windows 365 est un service facultatif pour Windows 365 Entreprise qui protège les PC et les données cloud contre les pannes régionales.

Lorsqu’il est activé, il crée des copies temporaires distantes géographiquement des PC cloud accessibles dans la région de sauvegarde sélectionnée. Ces copies permettent d’augmenter la disponibilité et de préserver la productivité.

Microsoft Learn

CRR vs DR vs CRDR ?

Le Cross Region Restore (CRR) et le Disaster Recovery (DR) sont toutes deux des stratégies utilisées pour assurer la continuité des activités et la protection des données, mais elles servent à des fins différentes et sont utilisées dans des scénarios différents :

  • Cross Region Restore (CRR) permet de restaurer des données sauvegardées dans une région secondaire.
  • Disaster Recovery (DR) implique un ensemble de politiques et de procédures pour permettre la récupération synchrone ou la continuation des infrastructures technologiques vitales et des systèmes suite à un désastre.

Le Cross-region Disaster Recovery (CRDR) s’inscrit finalement dans un mélange de ces 2 concepts :

  • Restauration des données sauvegardées dans une région secondaire.
  • Procédure pour permettre la continuation des infrastructures dans une région secondaire.

Quid des RPOs et RTOs ?

Comme le Cross-region Disaster Recovery de Windows 365 fonctionne avec des sauvegardes périodiques et non une synchronisation constante des données, le RPO s’en retrouve impacté :

En cas de panne, le service a les objectifs cibles suivants pour la récupération d’urgence inter-région :

  • RTO de < 4 heures pour les tenants avec moins de 50 000 PC cloud dans une région.
  • RPO de <4 heures.
Microsoft Learn

Note : le délai RPO du CRR dépendra également de la fréquence de sauvegarde configurée dans les paramètres de l’utilisateur des Cloud PCs :

Maintenant que ces concepts ont été annoncés, et afin d’y avoir plus clair, je vous propose un petit exercice sur le Cross-region Disaster Recovery (CRDR) pour Windows 365 :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur Windows 365, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une licence Microsoft 365
  • Une licence Windows 365 Entreprise
  • Une licence add-on Windows 365 Cross Region Disaster Recovery

Commencez par configurer le service Cross Region Disaster Recovery via le portail Intune.

Etape I – Configuration du CRDR

Rendez-vous sur la page du portail Intune, puis naviguez dans le menu suivant afin d’y retrouver la liste de vos postes Windows 365 :

Rendez-vous dans le menu suivant pour configurer le CRDR :

Cliquez sur la règle de paramètres utilisateurs de votre choix :

Cliquez sur Éditer :

Activez par cette option la fonctionnalité CRDR :

Choisissez le lien réseau correspondant à votre infrastructure, mais également la Géographie et la région Azure où seront créés les Cloud PCs quand le CRDR sera déclenché, puis cliquez sur Suivant :

Cliquez ici pour mettre à jour votre règle utilisateur :

La notification Intune suivante apparaît alors :

Vérifiez que le paramétrage CRDR est bien changé sur votre règle utilisateur :

Toujours sur le portail Intune, rendez-vous dans le rapport suivant afin de voir l’impact sur vos Cloud PCs déjà en place :

Cliquez sur la section suivante afin de comprendre pourquoi une alerte est présente :

Cliquez sur un des Cloud PCs pour comprendre le motif de l’alerte :

Un problème de licence est bien à l’origine de notre alerte :

Comme la majorité des licences, cet add-on a lui-aussi besoin d’être acheté en nombre et assigné aux utilisateurs concernés.

Ouvrez un nouvel onglet vers le portail Entra, puis cliquez sur la licence add-on Windows 365 Cross Region Disaster Recovery :

Assignez cet add-on a un de vos utilisateurs disposant déjà d’une licence Windows 365 :

Attendez quelques minutes, puis retournez sur le rapport afin de constater la disparition de l’alerte sur l’utilisateur en question :

La configuration du CRDR semble terminée, il ne nous reste qu’à tester le service sur notre utilisateur de test pour comprendre en détail la procédure de ce service.

Etape II – Activation du Cross-region Disaster Recovery :

Ouvrez une session sur votre Windows 365, puis rendez-vous sur la page Internet suivante afin de localiser approximativement votre Cloud PC.

Dans mon cas, le résultat nous montre une IP rattachée à la région de Zurich en Suisse. Cette information est cohérente puis que ce Cloud PC est créé dans la région Azure Suisse Nord :

Retournez sur la console Intune, puis activez le service CRDR pour ce Cloud PC via la fonction Bulk :

Renseignez tous les champs, puis cliquez sur Suivant :

Choisissez le Cloud PC dont l’utilisateur possède la licence Windows 365 Cross Region Disaster Recovery, puis cliquez sur Suivant :

Lancez l’activation du CRDR en cliquant sur Créer :

La notification Intune suivante apparaît :

Attendez quelques minutes, puis retourner sur la page du Cloud PC afin d’y constater l’erreur du lancement du CRDR :

Je pense que cela s’explique par l’absence de points de restauration dans la seconde région Azure, et/ou du fait de la configuration très récente.

J’ai donc décidé d’attendre 24-48 heures avant de recommencer la même opération d’activation du CRDR :

La notification Intune suivante apparaît :

Attendez quelques minutes, puis retourner sur la page du Cloud PC afin d’y constater le lancement du CRDR :

Quelques minutes plus tard, la session Windows ouverte sur le Cloud PC concerné se ferme d’elle-même, pour cause d’arrêt de la machine virtuelle :

Retentez d’ouvrir une session Windows 365 via le client Microsoft Remote Desktop :

Le message d’erreur suivant indique que la machine virtuelle du Cloud PC n’est plus accessible :

Actualiser la page du Cloud PC afin d’y constater un changement du statut CRDR :

Quelques minutes plus tard, le statut CRDR est passé en complété :

Retournez sur le rapport Intune appelé Statut de reprise après sinistre des PC Cloud dans toute la région afin d’y constater 2 nouvelles informations :

  • Le démarrage du service CRDR
  • L’expiration de l’instance CRDR dans 7 jours

Sur le client Microsoft Remote Desktop, lancez un rafraîchissement sur le Cloud PC :

Constatez l’apparition d’un second espace de travail contenant un poste appelé Temporary Cloud PC :

Ouvrez une session de bureau à distance sur ce Temporary Cloud PC :

Rendez-vous sur la page Internet suivante afin de localiser approximativement votre Cloud PC temporaire.

Dans mon cas, ce nouveau résultat nous montre une IP rattachée à la France. Cette information est cohérente, puisque le CRDR est configuré sur la région Azure France Central :

La notification Windows suivante nous informe également le caractère temporaire de ce second Cloud PC :

Il ne nous reste plus qu’à désactiver le Cross-region Disaster Recovery afin de voir le retour dans la région Azure d’origine.

Etape III – Désactivation du Cross-region Disaster Recovery :

Comme pour l’activation du CRDR, la désactivation de ce dernier se déclenche via la fonction Bulk :

Cliquez-ici pour ajouter le Cloud PC temporaire concerné par le CRDR :

Choisissez le Cloud PC temporaire créé sur France Central :

Cliquez sur Suivant :

Lancez la désactivation du CRDR en cliquant sur Créer :

La notification Intune suivante apparaît :

Attendez quelques minutes, puis retourner sur la page du Cloud PC afin d’y constater le lancement du failback du CRDR :

Suite à cette opération, une notification Windows nous informe que le Cloud PC temporaire devrait être décommissionné sous peu :

Une seconde notification Windows se fait plus pressante sur le besoin de déconnexion du Cloud PC temporaire :

Quelques minutes plus tard, le statut du failback du CRDR est passé en complété :

Retournez sur le rapport Intune appelé Statut de reprise après sinistre des PC Cloud dans toute la région afin d’y constater 2 nouvelles informations :

  • L’arrêt du service CRDR
  • La suppression de l’expiration du Cloud PC temporaire

Quelques minutes plus tard, la session Windows ouverte sur le Cloud PC temporaire est automatiquement fermée à cause de l’arrêt de la machine virtuelle :

Sur le client Microsoft Remote Desktop, lancez un rafraîchissement sur le Cloud PC temporaire :

Constatez dans le second espace de travail la disparition du poste appelé Temporary Cloud PC :

Ouvrez une session de bureau à distance sur le Cloud PC de base :

Ouvrez à nouveau page Internet suivante.

Dans mon cas, le résultat nous remontre une IP rattachée à la région de Zurich en Suisse. Cette information est cohérente puis que ce Cloud PC de base avait été créé dans la région Azure Suisse Nord :

Conclusion

Contrairement à de nombreuses solutions traditionnelles de récupération après sinistre, Windows 365 Cross-region Disaster Recovery a été conçu pour être configuré et utilisé avec une expérience minimale, voire aucune, en matière de récupération après sinistre. La configuration peut être terminée en quelques minutes.

Windows 365 Cross-region Disaster Recovery est fourni en tant que licence complémentaire aux SKU Windows 365 Entreprise. Aux États-Unis, le prix de l’add-on Windows 365 Cross-region Disaster Recovery est de 5 $ par utilisateur et par mois.

Mise en place d’un Azure Disaster Recovery sur un environnement Azure Virtual Desktop

Dans le cloud, il faut anticiper les pannes. Au lieu d’essayer d’empêcher toutes les défaillances, l’objectif est de réduire les répercussions d’une défaillance potentielle au niveau de chaque composant. Dans ce cas, les stratégies de sauvegarde et de récupération deviennent importantes.

Azure propose une solution de récupération d’urgence de bout en bout, simple, sécurisée, évolutive et rentable, qui peut être intégrée à des solutions locales de protection des données. Il est donc possible d’assurer une continuité de service par la réplication des ressources sur une seconde région.

Voilà pour la définition officielle côté Microsoft.

Je trouve cette image d’architecture assez parlante : le but d’un Disaster Recovery est bien de répliquer un site de production existante vers un second site, et d’assurer une synchronisation des données pour avoir une reprise d’activité des plus performantes.

Voici un exemple d’architecture Azure, redondée en totalité sur une seconde région Azure.

Contexte : Azure Virtual Desktop

Pour les architectures basées sur Azure Virtual Desktop, le fonctionnement est identique : je vais répliquer les services suivants dans une seconde région Azure :

  • Active Directory : ici Azure Active Directory Domain Services
  • Machine virtuelle : composant principal de AVD
  • Disque managé : utilisé pour OS
  • Compte de stockage : utilisé pour les profils utilisateurs via la solution FSLogix

Il est également possible de répliquer les ressources propres à Azure Virtual Desktop dans une seconde région, telles que :

  • Host Pool
  • Workspace
  • Applications groups

Je ne vais pas faire cette réplication globale dans ce billet, car je souhaite vous montrer ici le processus d’auto-enrôlement des machines virtuelles, issues du Test Failover, directement dans l’environnement Azure Virtual Desktop existant.

Je vais détailler de manière assez rapide la mise en place du premier environnement de production AVD, hébergé sur Suisse Nord. Cela reste un déploiement classique, car il ne nécessite pas de spécificités particulières pour la mise en place du Disaster Recovery, installé dans un second temps.

Etape I : Création d’un domaine Active Directory

La première étape consiste à la création du domaine. Cette solution est obligatoire pour la mise en place de tout environnement Azure Virtual Desktop.

Comme indiqué plus haut, j’ai choisi d’utiliser le service Azure Active Directory Domain Services. Pour rappel, il s’agit d’un domaine managé par Microsoft et c’est une ressource unique par Tenant :

What are the Differences Between Azure Active Directory and Azure Active  Directory Domain Services?

Alternative : Il est malgré tout possible de choisir un serveur Active Directory sur une machine virtuelle.

Voici une vidéo très explicative de Travis Roberts, qui montre les différences entre Active Directory, Azure Active Directory et Azure Active Directory Domain Services

Pour pouvoir répliquer mon service AADDS dans une seconde région Azure, j’ai choisi le SKU “Enterprise” car le SKU “Standard” ne permet pas d’utiliser la fonction Réplica Set. Pas de panique, ce SKU reste modifiable, même après la création du service AADDS et comme expliqué ici :

Merci à AnubhavinIT pour cette démonstration d’installation d’AADDS.

Etape II : Création d’une image pour les machines virtuelles

Encore une fois, je ne vais pas m’étendre en détail sur ce processus de création d’une image pour votre environnement Azure Virtual Desktop. A vrai dire, il ne diffère en rien de la préparation d’une image en dehors du cloud. L’idée générale ici est de créer un ensemble d’applicatifs et de configurations pour automatiser le processus de création de machines virtuelles dans votre environnement AVD.

La dernière vidéo complétement déjantée de Dean Cefola le montre très bien ????.

Etape III : Création d’un environnement Azure Virtual Desktop

Une fois l’image “prête à l’emploi”, nous allons pouvoir créer notre environnement Azure Virtual Desktop. Cette création va mettre en place les ressources Azure suivantes :

  • Host pool
  • x machine(s) virtuelle(s)
  • Workspace
  • Applications groups
Pour être toujours complet dans le processus de création AVD, je vous conseille cette vidéo de Mike Rodrick sur cette étape.

Etape IV : Mise en place du compte de stockage FSLogix

Le service Azure Virtual Desktop recommande les conteneurs de profils FSLogix en tant que solution de profil utilisateur. FSLogix est conçu pour l’itinérance des profils dans des environnements informatiques à distance, comme Azure Virtual Desktop. Il stocke un profil utilisateur complet dans un seul conteneur.

Source : Microsoft
FSLogix on Twitter: "New Microsoft learn module: Separate user profiles  from virtual machines with FSLogix profiles within Windows Virtual Desktop.  Learn more here: https://t.co/LlzMPK43Oa… https://t.co/mRbliUqBIo"
L’idée générale de séparer le profil utilisateur de la VM permet faciliter la mise à jour des images, de laisser l’utilisateur se connecter sur une autre VM en y retrouvant toutes ses applications et ses datas.
Pour comprendre en détail son fonctionnement et son utilité dans notre architecture AVD, quoi de mieux que de demander encore une fois à Dean.

Point important : L’installation de FSLogix nécessite quelques étapes, notamment au niveau de l’application des droits utilisateurs sur le file share (NTFS + RBAC).

Une bonne vidéo vaut toujours que de longues explications, merci Travis Roberts.

Etape V : Mise en place du Disaster Recovery via Azure Site Recovery

Notre environnement de production de Azure Virtual Desktop est maintenant prêt, nous allons pouvoir commencer la mise en place de la solution de Disaster Recovery.

Pour vous assurer que les utilisateurs peuvent toujours se connecter pendant une panne de région, vous devez répliquer leurs machines virtuelles à 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.

Source : Microsoft

Dans mon cas, je vais utiliser le service Azure Site Recovery pour assurer la réplication des machines virtuelles. En effet ce service assure une réplication constante des données dans Azure.

Attention : pour faire un DR complet, il faudra aussi prendre en considération la réplication du compte de stockage utilisé pour les profils gérés par FSLogix.

Activer la réplication d’une machine virtuelle peut se faire directement depuis l’interface de la VM.

Je vais pouvoir choisir ma région de réplication et personnaliser certains paramètres de configuration. Il n’est pas obligatoire de localiser la réplication sur la région paire de la première. Des coûts de bande passante entre région seront évidemment facturés par Microsoft.

J’ai déjà créé au préalable un premier groupe de ressources et un premier réseau virtuel dans ma seconde région, j’ai donc pu les sélectionner sans souci.

On peut donc démarrer la réplication juste après :

Ce processus d’initialisation prend un peu de temps, mais peut-être suivi par les notifications Azure.
Une fois la première réplication entièrement terminée, nous retrouvons sur la machine virtuelle son état de DR et toutes les informations associées.
Voici les ressources Azure créées dans la seconde région Azure. Finalement, nous n’avons qu’un compte de stockage et qu’un réseau virtuel.

Avant de démarrer la bascule des VMs dans AVD vers la seconde région Azure, je souhaite vous montrer l’état d’environnement de Azure Virtual Desktop :

Le Remote Desktop est bien accessible aux utilisateurs via l’application AVD Remote Desktop ou l’accès WEB.

Pour vérifier le bon fonctionnement du Disaster Recovery, qui je le rappelle doit TOUJOURS être déclenché manuellement, nous allons utiliser la fonction “Test Failover” de ce dernier :

  • Je commence par éteindre les machines virtuelles AVD déjà présentes sur Suisse Nord.
  • Je déclenche le Test Failover sur la ou les VMs AVD.
Un DR, exercice ou non, doit TOUJOURS être déclenché manuellement.

Pourquoi cela ?

Cela tient à une propriété d’enrôlement automatique des machines virtuelles à AVD.

Du fait que les nouvelles machines virtuelles vont avoir le même nom de machine que les précédentes, je souhaite vous montrer ici l’interruption de service, puis la reprise d’activité avec les nouvelles machines dans la seconde région Azure :

L’arrêt des machines virtuelles entraîne un service indisponible dans Azure Virtual Desktop.

Une fois le failover déclenché sur les deux machines virtuelles de mon environnement AVD, on retrouve toutes les nouvelles ressources Azure, automatiquement créées dans la seconde région Ouest Europe :

Copie d’écran des ressource présentes dans le groupe de ressources ASR.
Copie d’écran de ma liste de VMs : on retrouve bien donc deux VMs allumées (Ouest Europe) et deux VMs éteintes (Suisse Nord).

Résultat constaté : quelques minutes plus tard, je retrouve donc un environnement Azure Virtual Desktop opérationnel, sans aucune action supplémentaire de ma part :

Attention une VM qui passe peut en cacher une autre !
On peut noter que la région indique toujours la Région Azure Suisse nord car l’enrôlement de la nouvelle machine virtuelle s’appuie toujours sur les propriétés de la machine originelle.

Côté utilisateur : les utilisateurs peuvent donc se reconnecter à Azure Virtual Desktop :

Aperçu utilisateur via l’application Remote Desktop dédiée à Azure Virtual Desktop.

Note : Une fois le test de Failover réussi, pensez à nettoyer les ressources créées pour l’occasion et rallumer les machines virtuelles de production :

Une fonctionnalité de nettoyage des ressources issues du test du DR est directement disponible ici.

Résultat attendu :

Une fois le nettoyage démarré et les VMs de production rallumées : les machines virtuelles de production reprendront leur place dans l’host pool de Azure Virtual Desktop :

Le statut des VMs dans le host pool AVD retourne en « Unvailable » lorsque je le nettoie les ressources issue du test du Failover.
Le statut des VMs de retourne en « Available » lorsque je redémarre les machines de productions dans Suisse Ouest.

Conclusion

J’espère avoir été assez claire dans ce billet pour vous permettre de faire votre propre test dans votre environnement Azure Virtual Desktop.

Attention rappel, je n’ai pas parlé de la réplication de compte de stockage pour FSLogix, lui aussi à prendre en compte dans une solution de disaster recovery complète.

N’hésitez pas à faire part de vos réactions ou questions dans les commentaires ????