Azure Site Recovery pour des serveurs sur site

En cas de sinistre informatique, il n’y a aucun moyen de savoir ce qui peut frapper ou comment votre l’infrastructure peut en être affectée. Toutefois, en adoptant une approche réfléchie de la planification en cas de catastrophe, vous créer une tranquillité d’esprit si votre entreprise devait être confrontée à un sinistre.

Azure Site Recovery : permet d’assurer la continuité de l’activité en maintenant l’exécution des charges de travail et applications métier lors des interruptions. Site Recovery réplique les charges de travail s’exécutant sur des machines virtuelles et physiques depuis un site principal vers un emplacement secondaire.

En cas d’interruption au niveau de votre site principal, vous basculez vers un emplacement secondaire, depuis lequel vous pouvez accéder aux applications. Quand l’emplacement principal est de nouveau fonctionnel, vous pouvez effectuer une restauration automatique vers celui-ci.
Microsoft Learn

Voici une vidéo qui parle des mécanismes d’Azure Site Recovery :

Afin de se faire une meilleure idée sur Azure Site Recovery, je vous propose de réaliser un petit exercice combinant Azure Site Recovery et Hyper-V :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur Azure Site Recovery, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Important : Pour cela, je vous propose de simuler deux serveurs sous Windows Server 2019 grâce à un environnement virtualisé de type Hyper-V hébergé lui sur Azure

Dans Azure, il est en effet possible d’imbriquer de la virtualisation. Cela demande malgré tout quelques exigences, comme le SKU de la machine virtuelle Hyper-V, mais aussi sa génération.

Etape I – Préparation de la machine virtuelle hôte (Hyper-V) :

Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :

Cliquez-ici pour créer votre machine virtuelle hôte (Hyper-V) :

Renseignez tous les champs de base de votre machine virtuelle Hyper-V :

Choisissez une taille de machine virtuelle présent dans la famille Dsv3 :

Définissez un compte administrateur local, puis cliquez sur Suivant :

Rajoutez un second disque pour stocker la machine virtuelle invitée (Windows 11),créée plus tard dans notre machine virtuelle hôte (Hyper-V) :

Conservez les options par défaut, puis cliquez sur OK :

Cliquez ensuite sur Suivant :

Retirez l’adresse IP publique (pour des questions de sécurité), puis cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la première VM, puis attendez environ 3 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre machine virtuelle Hyper-V :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Attendez environ 5 minutes qu’Azure Bastion soit déployé pour continuer cet exercice :

La notification suivante vous indique alors le succès de la création d’Azure Bastion :

La configuration Azure est maintenant terminée, la suite va se passer sur la machine virtuelle Hyper-V.

Etape II – Configuration Hyper-V :

Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la VM :

Une fois connecté sur votre machine virtuelle hôte (Hyper-V), ouvrez Windows PowerShell :

Exécutez la commande suivante pour installer les deux rôles suivants :

Rôle DHCP
Rôle Hyper-V

Install-WindowsFeature -Name DHCP,Hyper-V  –IncludeManagementTools

Attendez environ une minute que l’installation des rôles se termine :

Lancez la commande suivante pour lancer un redémarrage de votre VM hôte (Hyper-V) :

Shutdown -R

Attendez environ 30 secondes que le redémarrage se termine pour se reconnecter à celle-ci, toujours via Azure Bastion :

Une fois la session Bastion rouverte, ouvrez PowerShell en mode ISE :

Lancez le script suivant afin de créer un switch virtuel dans Hyper-V, et de type interne :

$switchName = "InternalNAT"
New-VMSwitch -Name $switchName -SwitchType Internal
New-NetNat –Name $switchName –InternalIPInterfaceAddressPrefix “192.168.0.0/24”
$ifIndex = (Get-NetAdapter | ? {$_.name -like "*$switchName)"}).ifIndex
New-NetIPAddress -IPAddress 192.168.0.1 -InterfaceIndex $ifIndex -PrefixLength 24

Lancez le script suivant afin de configurer un périmètre DHCP avec une règle de routage, et le serveur DNS d’Azure :

Add-DhcpServerV4Scope -Name "DHCP-$switchName" -StartRange 192.168.0.50 -EndRange 192.168.0.100 -SubnetMask 255.255.255.0
Set-DhcpServerV4OptionValue -Router 192.168.0.1 -DnsServer 168.63.129.16
Restart-service dhcpserver

Ouvrez le Gestionnaire de disques depuis le menu démarrer afin de configurer le disque de données ajouté sur votre VM hôte (Hyper-V) :

Dès l’ouverture du Gestionnaire de disques, cliquez sur OK pour démarrer l’initialisation du disque de données :

Sur celui-ci, créez un nouveau volume :

Cliquez sur Suivant :

L’environnement Hyper-V est maintenant en place. Nous allons pouvoir créer ensemble deux machine virtuelles :

Windows Server 2019 pour jouer le rôle d’Appliance Azure Site Recovery
Windows Server 2019 pour jouer le rôle d’un serveur on-premise

Etape III – Création des machines virtuelles (Appliance / SRV) :

Pour cela, il est nécessaire de récupérer une image au format ISO de Windows Server 2019 afin de créer la machine virtuelle Appliance, puis d’y installer l’OS.

Toujours sur la machine virtuelle hôte (Hyper-V), ouvrez le navigateur internet Microsoft Edge.

Rendez-vous sur la page suivante pour télécharger l’ISO de Windows Server 2019, puis effectuez les actions suivantes :

Attendez quelques minutes pour que le téléchargement de l’ISO se termine :

Depuis votre VM hôte (Hyper-V), rouvrez votre console Hyper-V Manager, puis cliquez-ici pour créer votre première machine virtuelle Appliance :

Cliquez sur Suivant :

Modifier les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM hôte (Hyper-V), puis cliquez sur Suivant :

Pensez à bien choisir Génération 2 :

Modifier la taille de la mémoire vive allouée à la VM Appliance, puis cliquez sur Suivant :

Utilisez le switch créé précédemment, puis cliquez sur Suivant :

Cliquez sur Suivant :

Utilisez le fichier ISO de Windows Server 2019 téléchargé précédemment, puis cliquez sur Suivant :

Cliquez sur Terminer pour finaliser la création de votre machine virtuelle archive :

Modifiez le nombre de processeurs virtuels, puis cliquez sur OK :

Cliquez-ici pour lancer le démarrage de la VM archive :

Appuyez sur n’importe quelle touche du clavier pour démarrer sur l’image ISO de Windows Server 2019 :

Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :

Lancez l’installation de Windows Server 2019 :

Choisissez une version suivante de Windows Server 2019, puis cliquez sur Suivant :

Acceptez les termes et conditions de Microsoft, puis cliquez sur Suivant :

Sélectionnez l’installation personnalisée de Windows Server 2019 :

Validez l’installation sur le seul disque disponible, puis cliquez sur Suivant :

Attendez maintenant que l’installation de Windows Server 2019 commence :

En attentant que l’installation de Windows Server 2019 se finisse sur la machine virtuelle Appliance, créez une seconde machine virtuelle appelée et SRV de génération 1 :

De la même manière que pour la VM appliance, lancez l’installation de Windows Server 2019 sur la VM SRV :

Une fois les deux installations terminées, définissez un mot de passe pour le compte administrateur local :

Sur les 2 VMs, renseignez le mot de passe administrateur pour ouvrir une sessions Windows :

Désactivez la sécurité Internet Explorer, puis cliquez sur OK :

Depuis Internet Explorer, recherchez puis installez Edge :

Nous deux machines virtuelles sont correctement installées. La suite consiste à mettre en place l’appliance d’Azure Site Recovery.

Etape IV – Configuration Azure Site Recovery :

Retournez sur le portail Azure afin de créer le Coffre de restauration (Azure Recovery Vault) :

Renseignez les informations de base de votre Coffre de restauration, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de Coffre de restauration, puis attendez environ 1 minute :

Une fois le déploiement terminé, cliquez-ici pour commencer la configuration de Coffre de restauration :

Préparer l’infrastructure on-premise en cliquant ici :

Cliquez sur le lien suivant afin d’ouvrir la documentation Microsoft :

Copiez le lien ci-dessous (ou ici) afin de télécharger l’appliance dédiée à Azure Site Recovery :

Collez ce lien dans la machine virtuelle Appliance, puis attendez la fin du téléchargement :

Une fois l’archive ZIP téléchargé, ouvrez le dossier contenant celle-ci :

Avant de décompresser l’archive ZIP, débloquez celle-ci grâce à la case suivante, puis cliquez sur OK :

Lancez l’extraction dans le dossier de votre choix :

Attendez environ 3 minutes que l’archive ZIP se décompresse en totalité :

Sur la machine virtuelle Appliance, ouvrez une session PowerShell, puis positionnez-vous le dossier où l’archive ZIP a été extraite :

Lancez la commande PowerShell suivante :

.\DRInstaller.ps1

Confirmez la réponse avec Y :

Attendez environ 2 minutes que le traitement PowerShell se termine :

Vérifiez qu’aucune erreur n’a été remontée dans la fenêtre PowerShell :

Toujours sur la VM Appliance, retrouvez le dossier Software créé à la racine du disque Q afin de modifier ses propriétés :

Dans l’onglet Partage, cliquez sur le bouton Partager :

Confirmez les utilisateurs voulus, puis cliquez sur Partager :

Copiez le chemin du partage puis fermez la fenêtre de configuration du partage :

Lancez les 2 actions suivantes respectivement sur les deux VMs :

Sur la machine virtuelle Appliance, ouvrez Microsoft Azure Appliance Configuration Manager (présent sur le bureau )
Sur la machine virtuelle SRV, utilisez l’explorateur Windows pour vous rendre sur le chemin du partage activé précédemment

Sur la VM Appliance, vérifiez le bon fonctionnement réseau ainsi que les préconisations minimales, puis cliquez sur Continuer :

Attendez le contrôle de version, puis cliquez sur Continuer :

Cliquez sur Sauvegarder :

Cliquez sur Continuer :

Coller la clef précédemment présentée sur votre Coffre de restauration Azure, puis cliquez sur Login :

La fenêtre suivante s’ouvre afin que vous puissiez copier le code d’identification dans Azure :

Renseignez ce code dans la fenêtre d’authentification Azure, puis cliquez sur Suivant :

Renseignez vos identifiants Azure :

Réussissez le challenge MFA si nécessaire :

Cliquez sur Continuer afin d’autoriser la configuration avec Azure :

Vérifiez la confirmation Azure :

Attendez que l’enregistrement sur Azure se termine :

Cliquez sur Continuer :

Cochez la case suivante puis cliquez sur Continuer :

Ajoutez les informations relatives (identifiants / IP) à la machine virtuelle SRV :

Une fois ces informations renseignées, cliquez sur Continuer :

Comme indiqué, attendez jusqu’à 30 minutes que le traitement se termine :

En attendant, lancez l’installation de l’agent sur la machine virtuelle SRV disponible sur le partage réseau activé précédemment :

Cliquez sur Suivant :

Attendez environ 2 minutes que l’installation se termine :

Une fois l’installation terminée, cliquez ici pour configurer l’agent :

Copiez les détails de la machine virtuelle SRV dans le bloc-notes :

Créez sur le partage réseau un fichier texte contenant les détails de la machine virtuelle SRV, collez le contenu de ce fichier texte sur la machine virtuelle Appliance, puis téléchargez le fichier de configuration :

Sauvegardez le fichier de configuration téléchargé précédemment sur le partage réseau, puis insérez le dans la configuration de la machine virtuelle SRV :

Lancez le traitement de configuration, puis attendez environ 1 minute :

Cliquez sur terminer une fois tous les voyants au vert :

De retour sur Azure, vérifiez la bonne configuration de l’infrastructure de reprise dans le Coffre de restauration :

La configuration d’Azure Site Recovery est maintenant terminée. La prochaine étape consiste en la mise en place de la réplication vers Azure.

Etape V – Activation de la réplication :

Activez la réplication de votre VM SRV via le menu suivant :

Choisissez votre VM SRV dans la liste des machines à répliquer, puis cliquez sur Suivant :

Cliquez sur Suivant :

Renseignez tous les champs ci-dessous, puis cliquez sur Suivant :

Activez la réplication Azure :

Une première notification Azure apparaît pour vous signaler la mise en place des ressources :

Puis une seconde notification Azure apparaît pour vous indiquer le démarrage de la réplication de votre VM SRV :

Un clic sur cette notification nous affiche toutes les étapes et travaux réalisés au sein du Coffre de restauration :

Environ 10 minutes, une nouvelle notification nous indique le succès de la configuration de réplication :

Cliquez ici pour suivre l’avancement de la réplication des données vers Azure :

La machine virtuelle SRV est maintenant répliquée dans Azure. Nous allons maintenant pouvoir tester la réplication ASR via la fonction de bascule (failover).

Etape VI – Test de la réplication :

Environ 45 minutes après, la machine virtuelle SRV est enfin répliquée dans Azure et son statut change en Protégée :

Consultez les informations dont le RPO :

Consultez le schéma complet de réplication ASR :

Vérifiez et modifiez ci-dessous les informations VM et réseau :

Vérifiez et modifiez ci-dessous les informations des disques :

De retour sur la machine virtuelle SRV, créez un fichier image, puis enregistrez-le sur le bureau :

Attendez environ 10 minutes, puis lancez l’opération de bascule vers Azure :

Cochez la case suivante, plus cliquez-ici :

Confirmez votre action en cliquant ici :

Une nouvelle notification Azure apparaît pour vous indiquer la création de la machine virtuelle SRV dans Azure :

Consultez le nouveau groupe de ressources Azure créé pour la réplication :

Attendez la seconde notification Azure vous indiquant le succès du traitement de bascule :

Rafraichissez la page du groupe de ressources créé par ASR afin de constate la présence de la nouvelle machine virtuelle SRV :

Vérifiez la configuration CPU / Mémoire :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

La notification suivante vous indique alors le succès de la création d’Azure Bastion :

Lancez le script PowerShell suivant afin d’activer le service de bureau à distance :

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -name "fDenyTSConnections" -value 0

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Environ 30 secondes plus tard, le traitement est exécuté avec succès :

Ouvrez une session de bureau à distance via Azure Bastion en utilisant les mêmes identifiants administrateurs :

Réouvrez le fichier image créé précédemment avant la bascule :

Conclusion :

Malgré une mise en place un peu longue et des exigences de puissance CPU / Mémoire concernant la machine virtuelle appliance, la mise en place d’Azure Site Recovery a bien fonctionné. Que demandez de plus 😎🥳

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 ????

Mettre en place un Disaster Recovery sur Suisse Ouest

Carte représentant les régions Microsoft Azure à travers le monde
(Crédits : Microsoft).

Un des plus grands atouts de Microsoft Azure est bien le nombre de régions disponibles à travers le monde. A l’heure j’écris ce billet, nous pouvons déjà compter sur plus de 65 régions disponibles. Par région, j’entends que chacune d’entre elle dispose d’un ou plusieurs centres de données, appelés également zone de disponibilité.

Quoi de neuf en 2021 ?

L’année 2021 va continuer sur cette forte progression puisqu’il a été annoncé lors de l’Ignite 2021, que chaque région Azure aura droit à des zones de disponibilités en son sein. Aucun calendrier précis n’a été communiqué pour l’heure.

En revanche, chaque région Azure disponible se retrouve liée à une région paire au sein de la même zone géographique. Ces deux régions sont donc spécéfiquement reliées pour obtenir une faible latence mais aussi des services supplémentaires, comme de la continuité d’activité en cas de grand sinistre.

*Les régions paires ne sont jamais mises à jour en même temps. La région paire va servir de stockage de secours pour les ressources configurées en GRS (Geo-redundant storage).*

Pour tout comprendre sur les principes de régions et de disponibilités, je ne peux que vous conseiller l’excellente vidéo de Travis Roberts :

Et la Suisse dans tout ça ?

Microsoft Azure est implanté sur le territoire Suisse depuis 2019. Cela rend possible la mise en place d’un nouveau tenant 365 dans le pays helvétique, mais aussi le placement de ressources Azure. Il s’agit ici d’une évolution importante pour les entreprises et les organisations ayant des besoins en matière de résidence, de sécurité et de conformité des données.

*Azure est présent sur Suisse dans deux régions distinctes: la Suisse occidentale située à Genève et la Suisse du Nord située à Zurich.*

Deux régions Azure sont donc disponibles sur Suisse, mais cela ne veut pas dire que les deux sont accessibles pour tous. En effet, la région Suisse Nord reste à ce jour la région principale pour cette zone géographique. Il est malgré tout possible de faire une demande auprès de Microsoft pour installer des environnements de production sur Suisse Ouest, mais cette demande devra être motivée par son caractère stratégique et/ou critique.

Et si l’on souhaite mettre un disaster recovery sur la région paire ?

Pour rappel, un disaster recovery est une solution de réplication vers un lieu géographique éloigné pour assurer une continuité de service. L’intérêt de ce type de service est de limiter certains coûts liés à l’infrastructure secondaire. En effet, Azure propose un service appelé Azure Site Recovery, qui va se charger de répliquer les données en continu. Les ressources ne sont créées qu’en cas de failover (bascule). On ne paye donc que pour le stockage répliqué sur la seconde région. Ce schéma ci-dessous montre bien l’effort d’architecture pour assurer une continuité pour les 3 couches de service en cas de grand sinistre :

Azure Site Recovery | Microsoft Azure — Exemple de réplication d’architecture entre deux régions Azure. Traffic manager sera en mesure de détecter tout seul que la première région ne répond plus aux requêtes et pourra donc rediriger tous les flux vers la seconde région.

Pour installer notre Azure Site Recovery en Suisse Ouest, nous aurons donc besoin au préalable de faire une demande auprès des services de Support Microsoft. Un processus de demande d’accès aux régions Azure est disponible ici. A noter qu’en cas d’achat des ressources Azure par un Cloud Service Provider (CSP), cette demande devra être faite directement auprès de leurs services afin d’être correctement traitée. Une fois la demande validée par Microsoft, vous pourrez donc avoir « Suisse Ouest » dans la liste des régions disponible lors de la création de votre Azure Site Recovery.

Microsoft Azure Regions in Switzerland now available - Thomas Maurer

Vous voilà prêt à mettre tout ça en place !

Quelques conseils :

La création du groupe de ressource devra aussi faire sur la région paire (Suisse Ouest). Vous pourrez rencontrer un blocage lors de la configuration de la réplication avec Azure Site Recovery si ce dernier se trouve également dans un groupe de ressource créé sur Suisse Nord. Après réflexion, cela semble logique car le sinistre risquerait d’empêcher d’accéder à votre ressource, située dans une autre région non impactée, mais dont son groupe de ressource l’est potentiellement.
Comme toujours, avant toute mise en place de ressource Azure, vérifier la disponibilité de tous les services nécessaires dans ladite région, afin de vous retrouver bloqué en milieu de déploiement.

????