Cette architecture de référence vous aide à déployer une charge de travail stratégique qui utilise des services partagés centralisés, nécessite une connectivité locale et s’intègre à d’autres charges de travail d’une entreprise. Cette aide est destinée à un propriétaire de charge de travail qui fait partie d’une équipe d’application dans l’organisation.
Vous pouvez vous retrouver dans cette situation quand votre organisation souhaite déployer la charge de travail dans une zone d’atterrissage d’application Azure qui hérite du groupe d’administration Corp. La charge de travail doit s’intégrer aux ressources partagées préprovisionnées dans la zone d’atterrissage de plateforme Azure qui sont gérées par des équipes centralisées.
Important
Qu’est-ce qu’une zone d’atterrissage Azure ? Une zone d’atterrissage d’application est un abonnement Azure dans lequel la charge de travail s’exécute. Elle est connectée aux ressources partagées de l’organisation. Cette connexion lui donne accès à l’infrastructure de base nécessaire pour exécuter la charge de travail, comme le réseau, la gestion de l’accès aux identités, les stratégies et le monitoring. Les zones d’atterrissage de plateforme sont une collection d’abonnements divers remplissant chacun une fonction spécifique. Par exemple, l’abonnement Connectivité fournit une résolution DNS centralisée, une connectivité locale et des appliances virtuelles réseau (NVA) qui peuvent être utilisées par les équipes d’application.
En tant que propriétaire de la charge de travail, vous bénéficiez du transfert de la gestion des ressources partagées vers des équipes centrales et pouvez vous concentrer sur les efforts de développement de la charge de travail. L’organisation bénéficie de l’application d’une gouvernance cohérente et de l’amortissement des coûts sur plusieurs charges de travail.
Nous vous recommandons vivement de bien étudier le concept des zones d’atterrissage Azure.
Dans cette approche, l’optimisation de la fiabilité est une responsabilité que vous partagez avec l’équipe de plateforme. Les composants gérés de manière centralisée doivent être extrêmement fiables pour qu’une charge de travail stratégique fonctionne comme prévu. Vous devez avoir une relation de confiance avec l’équipe de plateforme afin que les problèmes d’indisponibilité dans les services centralisés, qui affectent la charge de travail, soient atténués au niveau de la plateforme. Toutefois, votre équipe est responsable de la définition des exigences avec l’équipe de plateforme pour atteindre vos objectifs.
Cette architecture s’appuie sur l’architecture de référence stratégique avec des contrôles réseau. Nous vous recommandons de vous familiariser avec l’architecture de référence avant de passer à la suite de cet article.
Notes
L’aide repose sur un exemple d’implémentation de production qui présente le développement d’applications stratégiques sur Azure. Cette implémentation peut être utilisée comme base pour un développement de solution supplémentaire dans votre première étape vers la production.
Stratégies de conception
Appliquez ces stratégies en plus de la base de référence stratégique :
Chemin critique
Le niveau de fiabilité des composants de l’architecture peut varier. Le chemin critique inclut les composants qui doivent rester fonctionnels afin que la charge de travail ne subisse pas de temps d’arrêt ni de dégradation des performances. L’utilisation d’un chemin léger permet de réduire les points de défaillance.
Cycle de vie des composants
Tenez compte du cycle de vie des composants critiques, car il impacte votre objectif qui est d’obtenir un temps d’arrêt proche de zéro. Les composants sont soit des ressources éphémères ou de courte durée qui peuvent être créées et détruites selon les besoins, soit des ressources non éphémères ou de longue durée qui partagent la durée de vie avec le système ou la région.
Dépendances externes
Minimisez les dépendances externes vis-à-vis de composants et de processus, car elles peuvent introduire des points de défaillance. L’architecture a des ressources qui appartiennent à différentes équipes extérieures à la vôtre. Ces composants (s’ils sont critiques) sont inclus dans l’étendue de cette architecture.
La topologie de l’abonnement
Les zones d’atterrissage Azure n’impliquent pas une seule topologie d’abonnement. Planifiez votre empreinte d’abonnement avec votre équipe de plateforme pour répondre aux exigences de fiabilité de la charge de travail dans tous les environnements.
Observabilité autonome dans le chemin critique
Mettez en place des ressources de monitoring dédiées pour permettre à l’équipe d’interroger rapidement sa collection de données (en particulier le chemin critique) et de travailler sur des corrections.
Architecture
Téléchargez un fichier Visio de cette architecture.
Les composants de cette architecture sont identiques à ceux de l’architecture de référence stratégique avec des contrôles réseau. Les descriptions sont courtes par souci de concision. Si vous avez besoin de plus d’informations, consultez les articles liés. Pour obtenir de la documentation sur les services Azure, consultez Ressources associées.
Ressources globales
Ces ressources résident dans le ou les abonnements de zone d’atterrissage d’application. Les ressources globales ne sont pas éphémères et partagent la durée de vie du système. Les services Azure et leur configuration sont identiques à ceux des ressources globales de référence.
Ressources réseau régionales
Ces ressources résident dans les abonnements de zone d’atterrissage de plateforme et le ou les abonnements de zone d’atterrissage d’application. L’architecture de référence déploie toutes les ressources qui vous appartiennent. Toutefois, dans cette architecture, les ressources réseau fournies par le biais de l’abonnement Connectivité sont provisionnées dans le cadre de la zone d’atterrissage de plateforme.
Dans cet article, consultez la section Réseau virtuel hub régional.
Ressources d’empreinte régionales
Ces ressources résident dans le ou les abonnements de zone d’atterrissage d’application. Ces ressources ne partagent rien avec d’autres ressources, à l’exception des ressources globales.
La plupart des services Azure et leur configuration sont identiques à ceux de l’architecture d’empreinte de référence, à l’exception des ressources réseau qui sont préprovisionnées par l’équipe de plateforme.
Dans cet article, consultez la section Réseau virtuel spoke régional.
Ressources externes
La charge de travail interagit avec les ressources locales. Certaines d’entre elles se trouvent sur le chemin critique de la charge de travail, par exemple une base de données locale. Ces ressources et les communications avec celles-ci sont prises en compte dans le Contrat de niveau de service (SLA) composite global de la charge de travail. Toutes les communications passent par l’abonnement Connectivité. La charge de travail peut atteindre d’autres ressources externes, mais celles-ci ne sont pas considérées comme critiques.
Ressources de pipeline de déploiement
Les pipelines de build et de mise en production pour une application stratégique doivent être entièrement automatisés pour garantir un moyen cohérent de déployer une empreinte validée. Ces ressources sont identiques à celles du pipeline de déploiement de référence.
Ressources de monitoring régionales
Ces ressources résident dans le ou les abonnements de zone d’atterrissage d’application. Les données de surveillance des ressources globales et des ressources régionales sont stockées indépendamment. Les services Azure et leur configuration sont identiques à ceux des ressources de monitoring de référence.
Dans cet article, consultez la section Considérations relatives au monitoring.
Ressources de gestion
Pour accéder au cluster de calcul privé et à d’autres ressources, cette architecture utilise des agents de build privés et des instances de machines virtuelles jumpbox. Azure Bastion fournit un accès sécurisé aux jumpbox. Les ressources à l’intérieur des empreintes sont identiques à celles des ressources de gestion de référence.
Mise en réseau - Éléments à prendre en compte
Dans cette conception, la charge de travail est déployée dans la zone d’atterrissage d’application et nécessite une connectivité aux ressources fédérées dans la zone d’atterrissage de plateforme. L’objectif peut être d’accéder aux ressources locales, de contrôler le trafic de sortie, etc.
Topologie du réseau
L’équipe de plateforme décide de la topologie réseau pour l’ensemble de l’organisation. Nous partons du principe que cette architecture utilise la topologie hub-and-spoke. Azure Virtual WAN peut également être utilisé.
Réseau virtuel hub régional
L’abonnement Connectivité contient un réseau virtuel hub avec des ressources partagées par l’ensemble de l’organisation. Ces ressources sont détenues et gérées par l’équipe de plateforme.
D’un point de vue stratégique, ce réseau n’est pas éphémère et ces ressources se trouvent sur le chemin critique.
| Ressource Azure | Objectif |
|---|---|
| Azure ExpressRoute | Fournit une connectivité privée du niveau local à l’infrastructure Azure. |
| Pare-feu Azure | Agit en tant qu’appliance virtuelle réseau qui inspecte et restreint le trafic de sortie. |
| DNS Azure | Fournit la résolution de noms entre différents locaux. |
| Passerelle VPN | Connecte les branches distantes de l’organisation à l’infrastructure Azure par le biais de l’Internet public. Peut également servir de solution de connectivité de secours pour accroître la résilience. |
Les ressources sont provisionnées dans chaque région et appairées au réseau virtuel spoke (décrit ci-après). Veillez à bien comprendre et à accepter les mises à jour de l’appliance virtuelle réseau, les règles de pare-feu, les règles d’acheminement, le basculement ExpressRoute vers la passerelle VPN, l’infrastructure DNS, etc.
Notes
L’un des principaux avantages de l’utilisation du hub fédéré est que la charge de travail peut s’intégrer à d’autres charges de travail, dans Azure ou entre différents locaux, en traversant les hubs réseau gérés par l’organisation. Ce changement réduit également vos coûts opérationnels dans la mesure où une partie de la responsabilité est transférée à l’équipe de plateforme.
Réseau virtuel spoke régional
La zone d’atterrissage d’application comporte au moins deux réseaux virtuels Azure préprovisionnés, par région, qui sont référencés par les empreintes régionales. Ces réseaux ne sont pas éphémères. L’un sert le trafic de production et l’autre cible le déploiement vNext. Cette approche vous permet de suivre des pratiques de déploiement fiables et sécurisées.
Réseau virtuel d’opérations
Le trafic opérationnel est isolé dans un réseau virtuel distinct. Ce réseau virtuel n’est pas éphémère et ce réseau vous appartient. Cette architecture conserve la même conception que l’architecture de référence avec des contrôles réseau.
Il n’y a aucun peering entre le réseau d’opérations et le réseau spoke. Toutes les communications s’effectuent par le biais de liaisons privées.
Responsabilités partagées
Il importe de bien comprendre chaque élément de conception de l’architecture et l’équipe qui en a la charge. Voici quelques considérations majeures.
Planification des adresses IP
Après avoir estimé la taille nécessaire pour exécuter votre charge de travail, collaborez avec l’équipe de plateforme afin qu’elle puisse provisionner le réseau de manière appropriée.
Équipe de plateforme
Fournit des adresses distinctes pour les réseaux virtuels qui participent aux peerings. Le chevauchement d’adresses, par exemple de réseaux locaux et de charge de travail, peut provoquer des perturbations entraînant une panne.
Alloue des espaces d’adressage IP suffisamment grands pour contenir les ressources d’exécution et de déploiement, gérer les basculements et prendre en charge la scalabilité.
Le réseau virtuel préprovisionné et les peerings doivent pouvoir prendre en charge la croissance attendue de la charge de travail. Vous devez évaluer régulièrement cette croissance avec l’équipe de plateforme. Pour plus d’informations, consultez Connectivité à Azure.
Sous-réseaux du réseau spoke régional
Vous êtes responsable de l’allocation de sous-réseaux dans le réseau virtuel régional. Les sous-réseaux et les ressources qu’ils contiennent sont éphémères. L’espace d’adressage doit être suffisamment grand pour prendre en charge la croissance potentielle.
Sous-réseau de points de terminaison privés Quand le trafic atteint le réseau virtuel, la communication avec les services PaaS au sein du réseau est limitée par l’utilisation de points de terminaison privés, tout comme dans l’architecture de référence avec des contrôles réseau. Ces points de terminaison sont placés dans un sous-réseau dédié. Les adresses IP privées des points de terminaison privés sont attribuées à partir de ce sous-réseau.
Sous-réseau de cluster Les exigences de scalabilité de la charge de travail influencent la quantité d’espace d’adressage à allouer aux sous-réseaux. À mesure que les nœuds et pods AKS font l’objet d’un scale-out, les adresses IP sont affectées à partir de ce sous-réseau.
Segmentation du réseau
Maintenez une segmentation appropriée afin que la fiabilité de votre charge de travail ne soit pas compromise par un accès non autorisé.
Cette architecture utilise des groupes de sécurité réseau (NSG) pour restreindre le trafic entre les sous-réseaux et l’abonnement Connectivité. Les groupes de sécurité réseau utilisent ServiceTags pour les services pris en charge.
Équipe de plateforme
Applique l’utilisation de groupes de sécurité réseau par le biais de stratégies Azure Network Manager.
Tient compte de la conception de la charge de travail. Il n’y a pas de trafic direct entre les empreintes. Il n’y a pas non plus de flux interrégionaux. Si ces chemins sont nécessaires, le trafic doit passer par l’abonnement Connectivité.
Empêche le trafic hub inutile provenant d’autres charges de travail dans la charge de travail stratégique.
Trafic de sortie issu d’empreintes régionales
Tout le trafic sortant de chaque réseau spoke régional est acheminé par le biais du Pare-feu Azure centralisé dans le réseau hub régional. Il agit comme le tronçon suivant qui inspecte puis autorise ou refuse le trafic.
Équipe de plateforme
Crée des UDR pour cette route personnalisée.
Affecte des stratégies Azure qui empêchent l’équipe d’application de créer des sous-réseaux qui n’ont pas la nouvelle table de routage.
Accorde des autorisations appropriées de contrôle d’accès en fonction du rôle (RBAC) à l’équipe d’application afin qu’elle puisse étendre les routes en fonction des exigences de la charge de travail.
Redondance multirégion
Vos charges de travail stratégiques doivent être déployées dans plusieurs régions pour résister aux pannes régionales. Collaborez avec l’équipe de plateforme pour vérifier que l’infrastructure est fiable.
Équipe de plateforme
Déploie des ressources réseau centralisées par région. La méthodologie de conception stratégique nécessite une isolation régionale.
Collabore avec l’équipe d’application pour découvrir les dépendances régionales cachées afin qu’une ressource de plateforme dégradée dans une région n’impacte pas les charges de travail d’une autre région.
Résolution DNS
L’abonnement Connectivité fournit des zones DNS privées. Toutefois, cette approche centralisée peut ne pas tenir compte des besoins DNS qui peuvent être spécifiques à votre cas d’usage. Provisionnez vos propres zones DNS et créez une liaison vers l’empreinte régionale. Si l’équipe d’application n’est pas propriétaire du DNS, la gestion des liaisons privées devient difficile pour les ressources globales comme Azure Cosmos DB.
Équipe de plateforme
Délègue les zones Azure DNS Private à l’équipe d’application pour couvrir ses cas d’usage.
Pour le réseau hub régional, définit la valeur des serveurs DNS sur Par défaut (fourni par Azure) pour prendre en charge les zones DNS privées gérées par l’équipe d’application.
Considérations relatives à la conception d’environnements
Il est courant de placer les charges de travail dans des environnements distincts pour la production, la préproduction et le développement. Voici quelques points clés à prendre en compte.
Comment l’isolation est-elle maintenue ?
L’environnement de production doit être isolé des autres environnements. Les environnements inférieurs doivent également maintenir un certain niveau d’isolation. Évitez de partager des ressources appartenant à l’application entre les environnements.
Un environnement de production est exigé pour les ressources aux niveaux global, régional et empreinte appartenant à l’équipe d’application. Des environnements de préproduction, tels que la mise en lots et l’intégration, sont nécessaires pour garantir que l’application est testée dans un environnement qui simule autant que possible la production. L’environnement de développement doit être une version réduite de l’environnement de production.
Quel est le cycle de vie attendu ?
Les environnements de préproduction peuvent être détruits une fois les tests de validation terminés. Il est recommandé que les environnements de développement partagent la durée de vie d’une fonctionnalité et soient détruits une fois le développement terminé. Ces actions sont effectuées par l’automatisation CI/CD (intégration continue et livraison continue).
Quels sont les compromis ?
Considérez les compromis entre l’isolation des environnements, la complexité de la gestion et l’optimisation des coûts.
Conseil
Tous les environnements doivent être dépendants des instances de production des ressources externes, y compris les ressources de plateforme. C’est notamment le cas d’un hub régional de production dans l’abonnement Connectivité. Vous pouvez ainsi minimiser le delta entre les environnements de préproduction et de production.
Topologie d’abonnement pour l’infrastructure de charge de travail
Les abonnements vous sont remis par l’équipe de plateforme. En fonction du nombre d’environnements, vous demanderez plusieurs abonnements pour une seule charge de travail. Selon leur type, certains environnements peuvent nécessiter des abonnements dédiés tandis que d’autres peuvent être regroupés dans un seul abonnement.
Quoi qu’il en soit, collaborez avec l’équipe de plateforme pour concevoir une topologie qui répond à l’objectif de fiabilité globale de la charge de travail. Il est avantageux de partager les ressources fournies par la plateforme entre les environnements du même abonnement de manière à refléter l’environnement de production.
Notes
L’utilisation de plusieurs abonnements pour contenir les environnements peut permettre d’atteindre le niveau d’isolation requis. Les abonnements de zone d’atterrissage sont hérités du même groupe d’administration. La cohérence avec la production est donc assurée pour les tests et la validation.
Abonnement de production
Les ressources sur l’abonnement qui vous est donné peuvent faire l’objet de limites. Si vous colocalisez toutes ces ressources dans un abonnement, vous risquez d’atteindre ces limites. En fonction de vos unités d’échelle et de l’échelle attendue, envisagez un modèle plus distribué. Par exemple,
Un abonnement qui contient à la fois des agents de build Azure DevOps et des ressources globales.
Un abonnement par région. Il contient les ressources régionales, les ressources d’empreinte et les jumpbox pour la ou les empreintes régionales.
Voici un exemple de topologie d’abonnement utilisée dans cette architecture.
Abonnement de préproduction
Au moins un abonnement est requis. Il peut exécuter de nombreux environnements indépendants, mais nous vous recommandons d’utiliser plusieurs environnements dans des abonnements dédiés. Cet abonnement peut également être soumis à des limites de ressources, comme l’abonnement de production décrit ci-dessus.
Abonnement de développement
Au moins un abonnement est requis. Cet abonnement peut être soumis à des limites de ressources s’il exécute tous les environnements indépendants. Vous pouvez donc demander plusieurs abonnements. Il est recommandé d’avoir des environnements individuels dans leurs abonnements dédiés.
Essayez de refléter la topologie de production autant que possible.
Points à prendre en considération pour le déploiement
Les déploiements ayant échoué ou les versions erronées sont des causes courantes de pannes d’application. Testez minutieusement votre application (et les nouvelles fonctionnalités) dans le cadre du cycle de vie d’application. Lors du déploiement de la charge de travail dans une zone d’atterrissage, vous devez intégrer votre conception aux ressources et à la gouvernance fournies par la plateforme.
Consultez Charges de travail stratégiques Well-Architected : déploiement et test.
Infrastructure de déploiement
La fiabilité de l’infrastructure de déploiement, comme les agents de build et leur réseau, a souvent autant d’importance que les ressources d’exécution de la charge de travail.
Cette architecture utilise des agents de build privés pour empêcher tout accès non autorisé pouvant impacter la disponibilité de l’application.
Il est fortement recommandé de maintenir l’isolation entre les ressources de déploiement. Une infrastructure de déploiement doit être liée à vos abonnements de charge de travail pour cet environnement. Si vous utilisez plusieurs environnements dans des abonnements de préproduction, créez une séparation supplémentaire en limitant l’accès à ces environnements individuels. Des ressources de déploiement par région peuvent être envisagées pour rendre l’infrastructure de déploiement plus fiable.
Déploiement sans temps d’arrêt
Les mises à jour de l’application peuvent provoquer des pannes. La mise en œuvre de déploiements cohérents permet d’améliorer la fiabilité. Les approches suivantes sont recommandées :
- Disposer de pipelines de déploiement entièrement automatisés.
- Déployer les mises à jour dans des environnements de préproduction sur une empreinte propre.
Pour plus d’informations, consultez les consignes de déploiement et de test pour les charges de travail stratégiques.
Dans l’architecture de référence, ces stratégies sont implémentées en annulant le provisionnement, puis en supprimant l’empreinte à chaque mise à jour. Dans cette conception, un déprovisionnement complet n’est pas possible car certaines ressources appartiennent à l’équipe de plateforme. Le modèle de déploiement a donc été modifié.
Modèle de déploiement
L’architecture de référence utilise le modèle Blue-Green pour déployer les mises à jour d’application. Les nouvelles empreintes avec des modifications sont déployées en même temps que les empreintes existantes. Une fois le trafic déplacé vers la nouvelle empreinte, l’empreinte existante est détruite.
Dans ce cas, le réseau virtuel appairé donné n’est pas éphémère. L’empreinte n’est pas autorisée à créer le réseau virtuel ou le peering sur le hub régional. Vous devrez réutiliser ces ressources dans chaque déploiement.
Le modèle Canary peut déboucher sur un déploiement sécurisé avec la possibilité de restaurer. Tout d’abord, une nouvelle empreinte est déployée avec des modifications de code. Le pipeline de déploiement référence le réseau virtuel préprovisionné et alloue des sous-réseaux, déploie des ressources et ajoute des points de terminaison privés. Il déplace ensuite le trafic vers ces sous-réseaux dans ce réseau virtuel préprovisionné.
Quand l’empreinte existante n’est plus nécessaire, toutes les ressources d’empreinte sont supprimées par le pipeline, à l’exception des ressources appartenant à la plateforme. Le réseau virtuel, les paramètres de diagnostic, le peering, l’espace d’adressage IP, la configuration DNS et le contrôle d’accès en fonction du rôle (RBAC) sont conservés. À ce stade, l’empreinte est dans un état propre et prête pour le nouveau déploiement suivant.
Stratégies Azure DINE (deploy-if-not-exists)
Les zones d’atterrissage d’application Azure peuvent être associées à des stratégies Azure DINE. Ces vérifications garantissent que les ressources déployées respectent les normes de l’entreprise dans les zones d’atterrissage d’application, même quand elles appartiennent à l’équipe d’application. Il peut y avoir un décalage entre votre déploiement et la configuration finale des ressources.
Comprenez l’impact de toutes les stratégies DINE qui seront appliquées à vos ressources. Si des modifications sont apportées à la configuration des ressources, incorporez l’intention des stratégies dans vos déploiements déclaratifs au début du cycle de développement de la charge de travail. Sinon, une dérive entraînant un delta entre l’état souhaité et l’état déployé peut se produire.
Gestion de l’accès à l’abonnement de déploiement
Traitez les limites d’abonnement comme vos limites de sécurité pour limiter le rayon d’explosion. Les menaces peuvent impacter la fiabilité de la charge de travail.
Équipe de plateforme
- Autorise les équipes d’application à effectuer des opérations avec des autorisations étendues à l’abonnement de zone d’atterrissage d’application.
Si vous exécutez plusieurs déploiements au sein d’un même abonnement, une violation impactera les deux déploiements. Il est recommandé d’exécuter les déploiements dans des abonnements dédiés. Créez des principaux de service par environnement afin de maintenir une séparation logique.
Le principal de service doit fournir une certaine autonomie par rapport aux ressources de charge de travail. En outre, des restrictions doivent être mises en place pour empêcher une manipulation excessive des ressources de plateforme au sein de l’abonnement.
Surveillance - Éléments à prendre en compte
La plateforme de zone d’atterrissage Azure fournit des ressources d’observabilité partagées dans le cadre des abonnements de gestion. L’équipe d’opérations centralisées encourage les équipes d’application à utiliser le modèle fédéré. Toutefois, pour les charges de travail stratégiques, un magasin d’observabilité centralisé unique n’est pas recommandé car il peut constituer un point de défaillance unique. Les charges de travail stratégiques génèrent également des données de télémétrie qui peuvent ne pas être applicables ou exploitables pour les équipes d’opérations centralisées.
Il est donc fortement recommandé d’adopter une approche de monitoring autonome. Les opérateurs de charge de travail sont en définitive responsables du monitoring et doivent avoir accès à toutes les données représentant l’intégrité globale.
L’architecture de référence suit cette approche qui est reprise ici. Azure Log Analytics et Azure Application Insights sont déployés aux niveaux régional et global pour monitorer les ressources dans ces étendues. L’agrégation des journaux d’activité, la création de tableaux de bord et la génération d’alertes sont la responsabilité de votre équipe. Bénéficiez des capacités de Diagnostics Azure qui envoient des métriques et des journaux à différents puits pour répondre aux exigences de la plateforme en matière de collecte de journaux et de métriques.
Modèle d'intégrité
La méthodologie de conception stratégique nécessite un modèle d’intégrité système. Quand vous définissez un score d’intégrité global, incluez les flux de zone d’atterrissage de plateforme dans l’étendue dont dépend l’application. Créez des requêtes de journal, d’intégrité et d’alerte pour effectuer un monitoring entre espaces de travail.
Équipe de plateforme
Octroie des récepteurs de journaux de requête et de lecture RBAC (contrôle d’accès en fonction du rôle) pour les ressources de plateforme pertinentes utilisées dans le chemin critique de l’application stratégique.
Soutient l’objectif organisationnel de fiabilité de la charge de travail stratégique en donnant à l’équipe d’application suffisamment d’autorisations pour mener à bien ses opérations.
Dans cette architecture, le modèle d’intégrité inclut les journaux et les métriques des ressources provisionnées dans l’abonnement Connectivité. Si vous étendez cette conception pour atteindre une ressource locale telle qu’une base de données, le modèle d’intégrité doit inclure la connectivité réseau à cette ressource, notamment des limites de sécurité telles que des appliances virtuelles réseau dans Azure et au niveau local. Ces informations sont importantes pour déterminer rapidement la cause racine et remédier à l’impact sur la fiabilité. Par exemple, la défaillance s’est-elle produite lors de la tentative d’acheminement vers la base de données ou y a-t-il eu un problème avec la base de données ?
Consultez Charges de travail stratégiques Well-Architected : modélisation de l’intégrité.
Intégration aux règles et stratégies fournies par la plateforme
L’abonnement de zone d’atterrissage d’application hérite des stratégies Azure, des règles Azure Network Manager et d’autres contrôles de son groupe d’administration. L’équipe de plateforme fournit ces garde-fous.
Pour les déploiements, ne dépendez pas exclusivement des règles fournies par la plateforme, car :
- Elles ne sont pas conçues pour répondre aux besoins des charges de travail individuelles.
- Les stratégies et les règles peuvent être mises à jour ou supprimées par quelqu’un d’extérieur à votre équipe, ce qui peut avoir un impact sur la fiabilité.
Nous vous recommandons vivement de créer et d’affecter des stratégies Azure dans vos déploiements. Cet effort peut entraîner une certaine duplication qui reste toutefois acceptable compte tenu de l’impact potentiel sur la fiabilité du système. Si des modifications sont apportées aux stratégies de plateforme, les stratégies de charge de travail sont toujours appliquées localement.
Équipe de plateforme
- Implique l’équipe d’application dans le processus de gestion des changements des stratégies à mesure que celles-ci évoluent.
- Tient compte des stratégies utilisées par l’équipe d’application. Évalue si elles doivent être ajoutées au groupe d’administration.
Déployer cette architecture
Les aspects de cette architecture relatifs au réseau sont implémentés dans l’implémentation Mission-Critical Connected.
Notes
L’implémentation Connected est destinée à illustrer une charge de travail stratégique qui repose sur des ressources organisationnelles, s’intègre à d’autres charges de travail et utilise des services partagés. L’implémentation part du principe qu’un abonnement Connectivité existe déjà.
Étapes suivantes
Passez en revue la zone de conception du réseau et de la connectivité dans Azure Well-Architected Framework.
Ressources associées
Outre les services Azure utilisés dans l’architecture de référence, ces services sont importants pour cette architecture.