Les zones de disponibilité sont des regroupements de centres de données séparés physiquement dans une région donnée. La réplication de vos déploiements sur plusieurs zones garantit que les interruptions locales limitées à une zone n’ont pas d’impact négatif sur la disponibilité de votre application. Cette architecture montre comment vous pouvez améliorer la résilience d’un déploiement ASE en déployant dans plusieurs zones de disponibilité. Ces zones ne sont pas liées à la proximité. Elles peuvent être mappées à différents emplacements physiques pour différents abonnements. Cette architecture suppose un déploiement sur un seul abonnement.
Une implémentation de référence de cette architecture est disponible sur GitHub.
Architecture
Le contenu des sous-réseaux ASE utilisé dans cette implémentation de référence est le même que celui de l’architecture de déploiement ASE standard décrit ici. Cette implémentation de référence réplique le déploiement dans deux sous-réseaux ASE. Chaque sous-réseau possède ses propres applications Web, API et instances de fonction s’exécutant sur ses plans App Service. Le cache ReDim requis par les applications est également répliqué pour de meilleures performances. Notez que l’étendue de cette architecture de référence est limitée à une seule région.
Workflow
La section suivante montre la nature de la disponibilité des services utilisés dans cette architecture :
Les environnements App Services peuvent être déployés dans plusieurs zones de disponibilité, uniquement en mode interne ou ILB. Cette implémentation de référence déploie deux sous-réseaux ASE, chacun dans une zone de disponibilité différente. Au minimum, deux zones de disponibilité sont recommandées pour la résilience de bout en bout de votre application. Toutes les ressources ASE ILB du runtime sont situées dans la zone spécifiée : l’adresse IP de l’équilibreur de charge interne de l’ASE, les ressources de calcul, ainsi que le stockage de fichiers sous-jacent requis par l’ASE pour exécuter toutes les applications déployées sur cet ASE. Pour obtenir des instructions et des suggestions détaillées, consultez Prise en charge d’App Service Environment pour les zones de disponibilité.
Le réseau virtuel Azure ou Vnet s’étend sur toutes les zones de disponibilité limitées à une seule région. Les sous-réseaux du réseau virtuel s’étendent également sur plusieurs zones de disponibilité. Cette architecture de référence crée un sous-réseau pour chaque déploiement ASE créé pour une zone de disponibilité. Pour plus d’informations, consultez la configuration réseau requise pour les environnements App Service Environment.
Application Gatewayv2 est redondant interzone. À l’instar du réseau virtuel, il s’étend sur plusieurs zones de disponibilité par région. Cela signifie qu’une seule passerelle d’application est suffisante pour un système à haut niveau de disponibilité, comme indiqué dans cette architecture de référence. La référence SKU v1 ne prend pas cela en charge. Pour plus de détails, consultez Application Gateway v2 avec mise à l’échelle automatique et redondance interzone.
Le Pare-feu Azure offre une prise en charge intégrée de la haute disponibilité. Elle peut s’étendre sur plusieurs zones sans aucune configuration supplémentaire. Cela permet l’utilisation d’un pare-feu unique pour les applications déployées dans plusieurs zones, comme c’est le cas dans cette architecture de référence. Bien que cela ne soit pas utilisé dans cette architecture, vous pouvez également configurer une zone de disponibilité spécifique lors du déploiement du pare-feu, le cas échéant. Pour plus d’informations, consultez Pare-feu et zones de disponibilité Azure.
Azure Active Directory est un service global hautement disponible et hautement redondant, couvrant des zones de disponibilité et des régions. Pour plus d’informations, consultez Améliorer la disponibilité d’Azure Active Directory.
Azure Pipelines prend en charge le traitement parallèle des activités CI/CD. À utiliser dans la phase de déploiement, pour déployer simultanément les applications générées sur plusieurs sous-réseaux ASE, par le biais de plusieurs machines virtuelles jumpbox ou sous-réseaux Bastion. Cette architecture utilise deux machines virtuelles jumpbox pour faciliter le déploiement simultané. Notez que le nombre de travaux parallèles est lié au niveau tarifaire. Le niveau gratuit de base d’un CI/CD hébergé par Microsoft permet de paralléliser jusqu’à 10 tâches, chacune s’exécutant jusqu’à 6 heures.
Azure Cache pour Redis n’est pas un service prenant en charge les zones. Cette architecture crée deux sous-réseaux pour contenir Azure Cache pour Redis, chacun étant épinglé à la zone de disponibilité d’un sous-réseau ASE. Cela est recommandé, car plus le cache est proche de l’application, meilleure est la performance de l’application. Notez qu’il s’agit d’une fonctionnalité d’évaluation, disponible uniquement pour le niveau Premium.
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.
Disponibilité
Environnements App Service
Les environnements App Service avec ILB peuvent être déployés dans une zone de disponibilité spécifique. Les zones de disponibilité sont séparées géographiquement par des centres de données autonomes au sein de la même région. En cas de panne d’un centre de données et si votre architecture le prend en charge, les applications déployées dans d’autres centres de données peuvent garantir la disponibilité.
Utilisez cette fonctionnalité en procédant comme suit :
- Déployez au moins deux de ces environnements dans deux zones distinctes, avec des applications dupliquées dans chaque ASE et
- équilibrez la charge du trafic en amont vers les ASE, à l’aide d’un Application Gateway redondant interzone, comme illustré dans cette architecture de référence.
Prenez en compte ces autres points :
- Un ASE ILB déployé sur une zone garantit la durée de bon fonctionnement des applications et des ressources déjà déployées qu’ils utilisent. Toutefois, la mise à l’échelle du plan App Service, la création d’applications et leur déploiement peuvent toujours subir des pannes dans d’autres zones.
- Un modèle Resource Manager doit être utilisé pour le déploiement initial de l’ASE ILB dans une zone de disponibilité. Par la suite, il est accessible via le portail ou la ligne de commande. La propriété des zones doit être définie sur 1, 2 ou 3 en indiquant les zones logiques.
- Le réseau virtuel par défaut est redondant interzone, par conséquent, tous les sous-réseaux ASE déployés dans une zone peuvent résider dans le même réseau virtuel.
- Les ASE externes ne peuvent pas être épinglés à une zone de disponibilité.
Pour plus d’informations, consultez Prise en charge d’App Service Environment pour les zones de disponibilité.
Résilience
Les applications dans les sous-réseaux ASE forment le pool principal pour l’Application Gateway. Lorsqu’une requête à l’application est effectuée à partir de l’Internet public, la passerelle peut choisir l’une des deux instances de l’application. Application Gateway analyse par défaut l’intégrité des ressources du pool principal, comme décrit dans Vue d’ensemble de l’analyse d’intégrité Application Gateway. Dans la configuration de référence, une sonde d’intégrité par défaut ne peut surveiller que le serveur frontal web. Étant donné que ce serveur Web frontal utilise à son tour d’autres composants, il peut sembler sain, mais néanmoins échouer si les dépendances échouent en raison d’une défaillance partielle du centre de données de cette zone. Pour éviter de tels échecs, utilisez une sonde personnalisée pour contrôler l’intégrité de l’application. Cette architecture de référence implémente des contrôles d’intégrité dans le serveur frontal web principal, le votingApp. Cette sonde d’intégrité vérifie si l’API Web, ainsi que le cache Redis, sont intègres. Consultez l’extrait de code qui implémente cette sonde dans le fichier Startup.cs :
var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionStrings:VotingDataAPIBaseUri"))
{
Path = "/health"
};
services.AddHealthChecks()
.AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
.AddRedis(Configuration.GetValue<string>("ConnectionStrings:RedisConnectionString"));
L’extrait de code suivant montre comment le script deploy_ha.sh configure les pools principaux et la sonde d’intégrité pour la passerelle App Gateway :
# Generates parameters file for appgw arm script
cat <<EOF > appgwApps.parameters.json
[
{
"name": "votapp",
"hostName": "${APPGW_APP1_URL}",
"backendAddresses": [
{
"fqdn": "${INTERNAL_APP1_URL1}"
},
{
"fqdn": "${INTERNAL_APP1_URL2}"
}
],
"certificate": {
"data": "${CERT_DATA_1}",
"password": "${PFX_PASSWORD}"
},
"probePath": "/health"
},
...
Si l’un des composants échoue au test de la sonde d’intégrité, à savoir le serveur frontal web, l’API ou le cache, l’Application Gateway achemine la requête vers l’autre application à partir du pool principal. Cela permet de s’assurer que la requête est toujours routée vers l’application dans un sous-réseau ASE entièrement disponible.
La sonde d’intégrité est également implémentée dans l’implémentation de référence standard. La passerelle renvoie simplement une erreur en cas d’échec de la sonde d’intégrité. Toutefois, dans le cas d’une implémentation hautement disponible, elle améliore la résilience de l’application et la qualité de l’expérience utilisateur.
Optimisation des coûts
L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.
Les considérations relatives au coût de l’architecture de haute disponibilité sont principalement similaires à celles du déploiement standard.
Les différences suivantes peuvent avoir une incidence sur le coût :
- Déploiements multiples d’environnements App Service.
- Déploiements multiples d’instances de niveau Premium Azure Cache pour Redis. Cette architecture de référence utilise le niveau Premium, étant donné que :
- Seul le Cache Redis de niveau Premium peut être utilisé à partir du réseau virtuel et
- l’épinglage zonal du Cache Redis, une fonctionnalité d’évaluation publique, est uniquement disponible dans le niveau Premium.
Le compromis entre la haute disponibilité, le système résilient et le système sécurisé a un coût accru. Évaluez les besoins de l’entreprise en ce qui concerne la tarification, à l’aide de la calculatrice de prix.
Points à prendre en considération pour le déploiement
Cette implémentation de référence étend le niveau de production du pipeline CI/CD utilisé dans le déploiement standard, à l’aide d’une machine virtuelle jumpbox par zone de disponibilité. Cela a deux objectifs :
- Épingler les machines virtuelles à la même zone de disponibilité que celle utilisée par les ressources ASE, garantissant ainsi la durée de bon fonctionnement dans le déploiement en cas de défaillance limitée à une ou deux zones.
- Ainsi que paralléliser le déploiement, en utilisant les machines virtuelles en tant que pool des agents Azure Pipelines.
Le fichier azure-pipelines.yml de cette implémentation de référence illustre ce déploiement parallèle, en créant des étapes de déploiement distinctes pour chaque ASE zonale.
Déployer ce scénario
Pour déployer l’implémentation de référence pour cette architecture, consultez le fichier readme de GitHubet suivez le script pour les déploiements à haute disponibilité.
Étapes suivantes
Vous pouvez développer les informations présentées dans cette architecture de référence et faire évoluer horizontalement vos applications dans la même région ou dans plusieurs régions, en fonction de la capacité de charge maximale attendue. La réplication de vos applications sur plusieurs régions peut aider à atténuer les risques de défaillances des centres de données géographiques plus larges, par exemple en raison de tremblements de tremblements ou d’autres catastrophes naturelles. Pour en savoir plus sur la mise à l’échelle horizontale, consultez Mise à l’échelle géolocalisée avec les environnements App Service. Pour une solution de routage globale et hautement disponible, envisagez d’utiliser Azure Front Door.