De manière générale, la grande majorité des services proposés par les principaux hébergeurs Cloud s’accompagnent d’un niveau de service (SLA). Ce Service-level agreement est un point d’accord concernant la disponibilité d’un service entre les utilisateurs et l’hébergeur Cloud. Une architecture entière dispose elle aussi de sa propre SLA. La SLA de ce produit final combine alors toutes les SLAs de ses sous-produits dont elle dépend.
Dans cet article, nous allons parcourir ensemble quelques mécanismes de résilience disponibles sur Azure. Nous testerons aussi ces méthodes dans le cadre de déploiement d’environnement AVD via le portail Azure.
Qu’est-ce que la SLA selon Microsoft ?
Les Contrats de Niveau de Service (« Service-level agreements », SLA) décrivent les engagements de Microsoft en termes de temps de disponibilité et de connectivité. Les SLA pour les différents services Azure sont énumérés ci-dessous.
SLA selon Microsoft
Azure élabore différentes SLAs pour chaque service qu’ils proposent. Certains services encore en préversion, destinés à du développement ou même gratuits peuvent être dépourvus de SLA. Tout naturellement, une SLA plus élevée apporte une meilleure disponibilité au service attendu.
Prenons en exemple la SLA des machines virtuelles créées sur Azure. Cette SLA dépend par exemple des performances des disques rattachés à la machine virtuelle :
Le choix de disques plus performant est une chose facile à comprendre et à mettre en place. Elle est donc la une première démarche à effectuer pour renforcer la résilience.
Quelle SLA dans le cadre d’un Azure Virtual Desktop ?
Azure Virtual Desktop s’appuie lui aussi sur des machines virtuelles Azure. Microsoft propose le un tableau comparant les cinq types de disques disponibles pour vous aider à choisir celui que vous allez utiliser selon votre scénario d’utilisation :
| Disque Ultra | SSD Premium v2 | SSD Premium | SSD Standard | HDD Standard | |
|---|---|---|---|---|---|
| Type de disque | SSD | SSD | SSD | SSD | HDD |
| Scénario | Charges de travail gourmandes en E/S, telles que le système SAP HANA, les bases de données de niveau supérieur (par exemple, SQL et Oracle), et autres charges de travail très lourdes en transactions. | Charges de travail de production et sensibles aux performances qui nécessitent systématiquement une latence faible, des IOPS et un débit élevé | Charges de travail de production et sensibles aux performances | Serveurs web, applications d’entreprise peu utilisées et Dev/Test | Sauvegarde, non critique, accès peu fréquent |
Microsoft vous recommande donc de créer vos machines virtuelles AVD avec des disques Premium SSD, et cela pour trois raisons :
- SLA de haut niveau, 99.9 %, indispensable pour environnement de production.
- Performances élevées, bande passante et IOPS satisfaisantes.
- Rapport qualité / prix en intégrant les coûts transactionnels dans son prix mensuel fixe.
Dans le cadre d’un pool de machines virtuelles AVD avec des disques Premium SSD, la SLA est alors à 99.9 % pour chacune d’elle.
Un autre paramètre rentre en ligne de compte pour renforcer la SLA de machines virtuelles : Nombre de machines virtuelles jouant un rôle identique :
Qu’est-ce qu’un Groupe à haute disponibilité ?
Un Groupe à haute disponibilité est un regroupement logique d’au moins deux machines virtuelles, de manière à fournir une application hautement disponible et à répondre aux exigences du niveau de 99,95 % inscrit dans les contrats de niveau de service Azure. Le groupe à haute disponibilité proprement dit ne vous coûte rien ; vous payez uniquement pour chaque instance de machine virtuelle que vous créez.
Microsoft Learn
Deux notions importantes sont alors configurables grâce à cette fonctionnalité d’Azure :
- Domaine de mise à jour : regroupe des machines virtuelles pouvant être mises à jour et donc potentiellement redémarrées en même temps. Le redémarrage des domaines de mise à jour effectue un redémarrage que sur un seul un seul domaine à la fois. (Max 20 domaines de mise à jour par Groupe à haute disponibilité)
- Domaine d’erreur : regroupe des machines virtuelles partageant une source d’alimentation et réseau en commune. Cela a pour effet de limiter l’effet des défaillances des équipements physiques, des pannes du serveur et des coupures d’électricité. (Max 3 domaines d’erreur par Groupe à haute disponibilité)
Autrement dit, Azure vous permet de positionner gratuitement vos machines virtuelles dans un Groupe à haute disponibilité, de telle sorte que si l’une d’entre-elles rencontre des difficultés ou une mise à jour Azure, une continuité de service de votre application est assurée via la disponibilité garantie des autres machines virtuelles.
Dans le cas d’un environnement Azure Virtual Desktop, certains services critiques peuvent alors être répartis sur plusieurs Groupes de disponibilité. Par exemple :
- Groupe de disponibilité 1 : Les machines virtuelles dédiées au pool d’hôtes AVD
- Groupe de disponibilité 2 : Les machines virtuelles dédiées au domaine AD
Qu’est-ce que les Zones de disponibilité ?
Un schéma est souvent plus clair que de longues explications. Voici un empilement hiérarchique du Cloud Microsoft. Chaque service Azure est défini par toutes ces strates ici présentes.
Les géographies d’Azure n’ont pas d’impact direct sur les architectures déployées dans le Cloud. Il faut juste garder en tête qu’une géographie Azure regroupe plusieurs régions Azure.
Le niveau le plus important à retenir est bien la Région Azure. Le Cloud de Microsoft est réparti sur environ une soixantaine de régions Azure. La plupart de ces régions Azure forment une paire de 2 régions. Cette liaison forte apporte des services spécifiques, comme le but d’accroitre les capacités de de reprise après sinistre.
Enfin, de plus en plus de régions Azure disposent de plusieurs Zones de disponibilité :
Les Zones de disponibilité Azure sont des emplacements physiquement séparés au sein de région Azure, qui sont tolérants aux défaillances de centre de données en raison de l’infrastructure redondante et de l’isolation logique des services Azure.
Microsoft Learn
L’intérêt de disposer de lieux géographiques séparés de plusieurs kilomètres, voir dizaines de kilomètres, est d’apporter une meilleure résilience que celle générée via les Groupes à haute disponibilité, toujours présent dans un seul site physique, pour faire face à des sinistres de grande envergure.
Afin de garantir un haut niveau de performance, Microsoft signale que l’impact sur la latence d’une architecture Azure répartie sur plusieurs Zones de disponibilité est minime voire nul, et cela grâce à une latence inférieure à deux millisecondes entre ces zones.
Microsoft met également à disposition un outil graphique intéressant sur les composantes de l’infrastructure Azure afin d’en savoir un peu plus :
Comme pour presque tous les articles dédiés Azure Virtual Desktop, voici différents tests pour en évaluer l’impact dans le déploiement de vos ressources.
Etape 0 : Rappel des prérequis
Des prérequis sont nécessaires pour réaliser ces démonstrations AVD :
- Un tenant Microsoft
- Une souscription Azure valide
- Un réseau virtuel existant sur Azure
La mise en place d’une notion de disponibilité doit se faire lors de la création des machines virtuelles. Il n’est plus possible d’agir dessus une fois les machines virtuelles déployées. Cela est donc paramétrable uniquement :
- Lors de la création du pool d’hôtes AVD
- Lors de l’ajout de nouvelles machines virtuelles à un environnement AVD existant.
Test A : AVD + Groupe à haute disponibilité
Commencez par déployer un pool d’hôtes AVD grâce à la barre de recherche du portail Azure :
Remplissez le premier onglet sans spécificité particulière :
Continuez sur les éléments de base de vos machines virtuelles AVD :
L’option ci-dessous nous invite à préciser la notion de disponibilité voulue. Choisissez ici Groupe à haute disponibilité :
Cliquez comme ceci pour en créer un nouveau Groupe à haute disponibilité :
Spécifiez le nom et les nombres de domaines de mise à jour et d’erreurs voulus :
Terminez de remplir les informations de cet onglet sans spécificité particulière :
Créez également un workspace AVD :
Lancez la création de votre environnement Azure Virtual Desktop :
Attendez que votre déploiement AVD se termine :
Contrôlez plusieurs machines virtuelles et constatez le Groupe à haute disponibilité dont elles dépendent :
Consultez l’ensemble des informations de votre Groupe à haute disponibilité en recherchant directement cette ressource Azure depuis votre groupe de ressources :
Ses paramétrages de base ne sont malheureusement plus modifiables :
L’ajout de nouvelle machines virtuelles à votre pool d’hôtes AVD avec ce même Groupe à haute disponibilité est toujours accessible.
Finalement, le déploiement d’un environnement Azure Virtual Desktop via le portail Azure prend bien en charge la répartition des machines virtuelles du pool d’hôtes dans un Groupe à haute disponibilité.
Continuons maintenant avec un second test dédié aux Zones de disponibilité.
Test B : AVD + Zones de disponibilité
Là encore, nous allons commencer par déployer un second pool d’hôtes AVD. Repartez depuis la barre de recherche du portail Azure pour accéder au service AVD :
Remplissez là encore le premier onglet sans spécificité particulière :
Continuez sur les éléments de base de vos machines virtuelles AVD :
Choisissez dans le même menu déroulant Zones de disponibilité, puis sélectionnez les 3 Zones disponibles dans la région Suisse Nord :
Terminez de remplir les informations de cet onglet sans spécificité particulière :
Créez là encore un workspace AVD :
Lancez la création de votre environnement Azure Virtual Desktop :
Attendez que votre second déploiement AVD se termine :
Contrôlez plusieurs machines virtuelles et constatez la Zone de disponibilité dont elles dépendent :
A l’inverse du Groupe à haute disponibilité, il n’existe pas de ressource Azure symbolisant la Zones de disponibilité. Là encore, plus aucun paramétrage n’est modifiable après création.
Ici aussi, le déploiement d’un environnement Azure Virtual Desktop via le portail Azure prend lui aussi en charge la répartition des machines virtuelles du pool d’hôtes dans plusieurs Zones de disponibilité.
Remarque importante
Une différence subtile existe les Groupes à haute disponibilité et les Zones de disponibilité. Le premier est bien un groupe dont sont associées plusieurs machines virtuelles, tandis que le second est une affectation d’une machine virtuelle à un datacenter (zone) spécifique.
Au final, pour que ces deux services Azure fassent sens dans votre architecture :
- Je n’ai besoin que d’un seul groupe à haute disponibilité pour plusieurs VMs
- J’ai besoin de plusieurs zones de disponibilité pour plusieurs VMs
Pourquoi cette précision ?
Car il arrive souvent qu’un doute s’installe sur lesquelles et combien de ces ressources (Groupe à haute disponibilité / Zones de disponibilité) sont nécessaires.
Conclusion
Azure Virtual Desktop continue de progresser en automatisation et en simplicité de déploiement. Le fait que de plus en plus de régions Azure disposent de Zones de disponibilité est une très bonne nouvelle pour la résilience des services Cloud. Enfin Dean de l’Azure Academy nous en reparle en détail dans cette vidéo ????????
Un commentaire sur “Augmentez la résilience de votre AVD”