Créer des solutions pour la haute disponibilité à l’aide de zones de disponibilité

Azure

L’infrastructure globale de Microsoft Azure est conçue et construite à chaque niveau pour fournir les plus hauts niveaux de redondance et de résilience aux clients. L’infrastructure Azure est composée de zones géographiques, de régions et de zones de disponibilité, qui limitent le rayon d’impact d’une défaillance et, par conséquent, l’incidence potentielle de celle-ci sur les applications et les données des clients. La construction de zones de disponibilité Azure a été développée pour fournir une solution logicielle et de mise en réseau permettant de se protéger contre des défaillances de centre de données, et d’offrir une haute disponibilité accrue à nos clients.

Les Zones de disponibilité sont des emplacements physiques uniques au sein d’une région Azure. Chaque zone est composée d’un ou de plusieurs centres de données équipés d’une alimentation, d’un système de refroidissement et d’un réseau indépendants. La séparation physique des zones de disponibilité au sein d’une région limite l’impact sur les applications et les données de défaillances de zone, telles que des inondations à grande échelle, des ouragans et raz de marée majeurs, et d’autres événements susceptibles de perturber l’accès au site, le passage en toute sécurité, la durée de bon fonctionnement des utilitaires étendus et la disponibilité des ressources. Les zones de disponibilité et leurs centres de centres associés sont conçus de telle sorte que, si une zone est compromise, les services, la capacité et la disponibilité sont assurés par les autres zones de disponibilité de la région.

Les zones de disponibilité permettent répartir une solution sur plusieurs zones au sein d’une région, de sorte qu’une application puisse continuer à fonctionner en cas de défaillance d’une zone. Avec les zones de disponibilité, Azure propose le meilleur contrat de niveau de service (SLA) garantissant une durée de bon fonctionnement des machines virtuelles de 99,99 %. Des services redondants interzone répliquent vos services et vos données dans des zones de disponibilité pour les protéger contre des points de défaillance uniques. Si vous concevez des solutions hautement disponibles sur Azure qui sont stratégiques par nature, en plus d’utiliser des zones de disponibilité, la distribution globale dans plusieurs régions Azure est vivement recommandée.

Diagramme montrant les zones de disponibilité Azure 1 à 3.

Pour plus d’informations sur les zones de disponibilité, y compris le support de service par région et la tarification, consultez Que sont les zones de disponibilité dans Azure ?.

Architectures de référence des zones de disponibilité

Les architectures suivantes permettent des scénarios de haute disponibilité :

Garantie de fiabilité dans Azure

La conception de solutions qui continuent de fonctionner en dépit d’une défaillance est la clé de l’amélioration de la fiabilité d’une solution. Dans des solutions basées sur le cloud, créer pour survivre aux défaillances est une responsabilité partagée. Elle se traduit à trois niveaux : une base résiliente, des services résilients et des applications résilientes. La base est l’investissement de Microsoft dans la plateforme, y compris dans les zones de disponibilité. Sur cette base s’appuient les services Azure que les clients peuvent activer pour bénéficier d’un haute disponibilité, tels que le stockage redondant interzone (ZRS) qui réplique les données entre des zones. Le client construit des applications sur les services activés reposant sur cette base. Les applications doivent être architecturées pour prendre en charge la résilience.

Vos applications

Architecture de votre application ou charge de travail

Services résilients

Fonctionnalités Azure que vous activez en fonction des besoins

Base résiliente

Fonctionnalités Azure intégrées dans la plateforme

Lorsque vous architecturez pour la résilience, vous devez prendre en considération les trois niveaux (base, services et applications) pour atteindre le plus haut niveau possible de fiabilité. Étant donné qu’une solution peut être constituée de nombreux composants, chacun de ceux-ci doit être conçu pour la fiabilité.

Architecture zonale ou redondante interzone

Une zone de disponibilité dans une région Azure est une combinaison d’un domaine d’erreur et d’un domaine de mise à jour. Par exemple, si vous créez trois ou plusieurs machines virtuelles dans trois zones d’une région Azure, vos machines virtuelles sont efficacement réparties sur trois domaines d’erreur et trois domaines de mise à jour. La plateforme Azure reconnaît cette distribution entre domaines de mise à jour pour veiller à ce que les machines virtuelles dans les différentes zones ne soient pas mises à jour en même temps.

Les services Azure qui prennent en charge les zones de disponibilité se répartissent en deux catégories : zonaux et redondants interzone. Les charges de travail client peuvent être catégorisées pour utiliser un des scénarios d’architecture afin de répondre aux exigences de performances et de durabilité des applications.

Une architecture zonale permet de déployer une ressource dans une Zone de disponibilité spécifique auto-sélectionnée pour répondre à des exigences plus rigoureuses en matière de latence et de performances. La résilience est auto-architecturée en répliquant des applications et des données dans une ou plusieurs zones à l’intérieur de la région. Vous pouvez choisir des zones de disponibilité spécifiques pour une réplication synchrone offrant une haute disponibilité, ou une réplication asynchrone offrant un avantage sur le plan de la sauvegarde ou du coût. Vous pouvez épingler des ressources (machines virtuelles, disques managés ou adresses IP standard) à une zone spécifique, ce qui permet d’obtenir une résilience accrue en faisant en sorte qu’une ou plusieurs instances de ressources soient réparties entre les zones.

Avec une architecture redondante interzone, la plateforme Azure réplique automatiquement la ressource et les données entre les zones. Microsoft gère la livraison de la haute disponibilité, car Azure réplique et distribue automatiquement les instances au sein de la région.

La défaillance d’une zone affecte différemment les services zonaux et redondants interzone. En cas de défaillance d’une zone, les services zonaux dans celles-ci deviennent indisponibles jusqu’à ce que la zone ait récupéré. En architecturant vos solutions de manière à utiliser des machines virtuelles répliquées dans plusieurs zones, vous pouvez protéger les applications et données d’une zone qui devient indisponible, par exemple, en raison d’une panne de courant. Si une zone est compromise, les applications et données répliquées sont instantanément disponibles dans une autre zone.

L’architecture zonale s’applique à une ressource spécifique, généralement une ressource IaaS telle qu’une machine virtuelle ou un disque managé, comme illustré.

Diagramme montrant une architecture zonale.

Par exemple, équilibreur de charge zonal, machine virtuelle, disques managés et groupes de machines virtuelles identiques.

Dans l’illustration, chaque machine virtuelle et équilibreur de charge sont déployés dans une zone spécifique.

Avec des services redondants interzone, la distribution de la charge de travail est une fonctionnalité du service gérée par Azure. Azure réplique automatiquement la ressource entre plusieurs zones sans nécessiter d’intervention. Par exemple, ZRS réplique les données dans trois zones, de sorte que la défaillance d’une zone n’a pas d’incidence sur la haute disponibilité des données.

L’illustration suivante présente un équilibreur de charge redondant interzone.

Diagramme montrant un équilibreur de charge redondant interzone.

Par exemple, équilibreur de charge redondant interzone, Azure Application Gateway, Azure Service Bus, réseau privé virtuel (VPN), stockage redondant interzone, Azure ExpressRoute, Event Hubs Azure et Azure Cosmos DB.

Certaines ressources, telles que l’équilibreur de charge et les sous-réseaux, prennent en charge les déploiements tant zonaux que redondants interzone. Une considération importante concernant la haute disponibilité est la distribution efficace du trafic entre les ressources dans les différentes zones de disponibilité. Pour plus d’informations sur la façon dont les zones de disponibilité s’appliquent aux ressources de l’équilibreur de charge tant zonales que redondantes interzone, consultez Équilibreur de charge standard et zones de disponibilité.

Pour obtenir la liste des services Azure qui prennent en charge les zones de disponibilité, consultez la documentation sur les zones de disponibilité.

Contrat de niveau de service proposé par les zones de disponibilité

Avec les zones de disponibilité, Azure propose des contrats de niveau de service garantissant une durée de bon fonctionnement optimale des machines virtuelles de 99,99 %. La version complète du contrat SLA Azure explique la disponibilité garantie d’Azure dans son ensemble.

Le diagramme suivant illustre les niveaux de haute disponibilité qu’offrent respectivement une simple machine virtuelle, des groupes à haute disponibilité et des zones de disponibilité.

Diagramme montrant les niveaux de haute disponibilité qu’offre une machine virtuelle unique, des groupes à haute disponibilité et des zones de disponibilité.

En prenant l’exemple d’une charge de travail de machine virtuelle, une simple machine virtuelle a un contrat SLA de 99,9 %. Cela signifie que la machine virtuelle est disponible 99,9 % du temps. Dans un centre de donnée, l’utilisation de groupes à haute disponibilité peut porter le niveau de SLA à 99,95 % en protégeant un ensemble de machines virtuelles, en garantissant qu’elles ne sont pas toutes sur le même matériel. Dans une région, les charges de travail des machines virtuelles peuvent être distribuées entre des zones de disponibilité pour porter le SLA à 99,99 %. Pour plus d’informations, consultez Options de disponibilité pour les machines virtuelles dans Azure.

Chaque organisation a des exigences uniques, et vous devez concevoir vos applications pour répondre au mieux à vos besoins métier complexes. La définition d’un SLA cible vous permettra de déterminer si l’architecture répond à vos besoins métier. Parmi les éléments à prendre en considération :

Quelles sont les exigences en matière de disponibilité ?
Quel temps d’arrêt maximal est acceptable ?
Combien les temps d’arrêt vont-ils coûter à votre entreprise ?
Combien devriez-vous investir pour rendre l’application hautement disponible ?
Quelles sont les exigences en matière de sauvegarde des données ?
Quelles sont les exigences en matière de réplication des données ?
Quelles sont les exigences de surveillance ?
Votre application a-t-elle des exigences spécifiques en matière de latence ?

Pour obtenir des conseils supplémentaires, consultez les Principes du pilier de fiabilité.

Le coût et la complexité de la conception peuvent varier en fonction des besoins de disponibilité d’une application. Lors de la création d’une charge de travail de machine virtuelle, un coût est associé à chaque machine virtuelle. Par exemple, le coût de deux machines virtuelles par zone dans trois zones actives équivaut au coût de six machines virtuelles. Pour obtenir la tarification des charges de travail de machines virtuelles, consultez la Calculatrice de prix Azure.