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.
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 :
Alternative : Il est malgré tout possible de choisir un serveur Active Directory sur une machine virtuelle.
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 :
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.
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
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
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).
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.
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.
On peut donc démarrer la réplication juste après :
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 :
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.
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 :
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 :
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 :
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 :
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 :
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 :
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 ????
