Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résilience à la périphérie

Le pilier de fiabilité englobe la capacité d'une charge de travail à exécuter correctement et de manière cohérente la fonction prévue lorsqu'elle est censée le faire. Cela inclut la capacité d'exploiter et de tester la charge de travail tout au long de son cycle de vie. En ce sens, lorsque vous concevez une architecture résiliente à la périphérie, vous devez d'abord déterminer quelles infrastructures vous utiliserez pour déployer cette architecture. Il existe trois combinaisons possibles à implémenter en utilisant Zones locales AWS et AWS Outposts : avant-poste vers avant-poste, avant-poste vers zone locale et zone locale vers zone locale, comme illustré dans le schéma suivant. Bien qu'il existe d'autres possibilités pour les architectures résilientes, telles que la combinaison de services de AWS périphérie avec une infrastructure sur site traditionnelle Régions AWS, ce guide se concentre sur ces trois combinaisons qui s'appliquent à la conception de services de cloud hybride

Considérations relatives à l’infrastructure

À AWS, l'un des principes fondamentaux de la conception des services est d'éviter les points de défaillance uniques dans l'infrastructure physique sous-jacente. En raison de ce principe, les AWS logiciels et les systèmes utilisent plusieurs zones de disponibilité et résistent à la défaillance d'une seule zone. À la périphérie, AWS propose des infrastructures basées sur les Zones Locales et les Outposts. Par conséquent, un facteur essentiel pour garantir la résilience lors de la conception de l'infrastructure consiste à définir où les ressources d'une application sont déployées.

Zones locales

Les zones locales agissent de la même manière que les zones de disponibilité qui les composent Région AWS, car elles peuvent être sélectionnées comme emplacement pour les AWS ressources zonales telles que les sous-réseaux et EC2 les instances. Cependant, ils ne sont pas situés dans un Région AWS, mais à proximité de grands centres industriels et informatiques où il n'en Région AWS existe pas aujourd'hui. Malgré cela, ils conservent des connexions sécurisées à bande passante élevée entre les charges de travail locales de la zone locale et les charges de travail exécutées dans le. Région AWS Par conséquent, vous devez utiliser les Zones Locales pour déployer les charges de travail au plus près de vos utilisateurs afin de garantir une faible latence.

Outposts

AWS Outposts est un service entièrement géré qui étend AWS l'infrastructure et Services AWS APIs les outils à votre centre de données. La même infrastructure matérielle que celle utilisée dans le AWS Cloud est installée dans votre centre de données. Les Outposts sont ensuite connectés aux plus proches. Région AWS Vous pouvez utiliser les Outposts pour prendre en charge vos charges de travail nécessitant une faible latence ou nécessitant un traitement local des données.

Zones de disponibilité pour les parents

Chaque zone locale ou avant-poste possède une région parent (également appelée région d'origine). La région parent est l'endroit où le plan de contrôle de l'infrastructure AWS périphérique (avant-poste ou zone locale) est ancré. Dans le cas des zones locales, la région parent est un composant architectural fondamental d'une zone locale et ne peut pas être modifiée par les clients. AWS Outposts l'étend AWS Cloud à votre environnement sur site. Vous devez donc sélectionner une région et une zone de disponibilité spécifiques lors du processus de commande. Cette sélection ancre le plan de contrôle de votre déploiement d'Outposts à l' AWS infrastructure choisie.

Lorsque vous développez des architectures de haute disponibilité en périphérie, la région parent de ces infrastructures, telle que les Outposts ou les Zones Locales, doit être identique, afin qu'un VPC puisse être étendu entre elles. Ce VPC étendu est à la base de la création de ces architectures à haute disponibilité. Lorsque vous définissez une architecture hautement résiliente, vous devez donc valider la région parent et la zone de disponibilité de la région dans laquelle le service sera (ou est) ancré. Comme illustré dans le schéma suivant, si vous souhaitez déployer une solution de haute disponibilité entre deux Outposts, vous devez choisir deux zones de disponibilité différentes pour ancrer les Outposts. Cela permet une architecture multi-AZ du point de vue du plan de contrôle. Si vous souhaitez déployer une solution à haute disponibilité incluant une ou plusieurs zones locales, vous devez d'abord valider la zone de disponibilité parent dans laquelle l'infrastructure est ancrée. Pour cela, utilisez la AWS CLI commande suivante :

aws ec2 describe-availability-zones --zone-ids use1-mia1-az1

Résultat de la commande précédente :

{     "AvailabilityZones": [         
          {
             "State": "available",
             "OptInStatus": "opted-in",
             "Messages": [],
             "RegionName": "us-east-1",
             "ZoneName": "us-east-1-mia-1a",
             "ZoneId": "use1-mia1-az1",
             "GroupName": "us-east-1-mia-1",
             "NetworkBorderGroup": "us-east-1-mia-1",
             "ZoneType": "local-zone",
             "ParentZoneName": "us-east-1d",
             "ParentZoneId": "use1-az2"
         }
     ]
 }

Dans cet exemple, la zone locale de Miami (us-east-1d-mia-1a1) est ancrée dans la zone de us-east-1d-az2 disponibilité. Par conséquent, si vous devez créer une architecture résiliente à la périphérie, vous devez vous assurer que l'infrastructure secondaire (Outposts ou Zones Locales) est ancrée dans une zone de disponibilité autre que. us-east-1d-az2 Par exemple, us-east-1d-az1 serait valide.

Le schéma suivant fournit des exemples d'infrastructures périphériques à haute disponibilité.

Considérations relatives au réseau

Cette section décrit les considérations initiales relatives à la mise en réseau en périphérie, principalement pour les connexions permettant d'accéder à l'infrastructure périphérique. Il passe en revue les architectures valides qui fournissent un réseau résilient pour le lien de service.

Réseau de résilience pour les Zones Locales

Les Zones Locales sont connectées à la région mère par de multiples liaisons haut débit sécurisées et redondantes qui vous permettent d'utiliser n'importe quel service régional, tel qu'Amazon S3 et Amazon RDS, de manière fluide. Vous êtes responsable de fournir la connectivité entre votre environnement local ou vos utilisateurs et la zone locale. Quelle que soit l'architecture de connectivité que vous choisissez (par exemple, VPN ou AWS Direct Connect), la latence qui doit être atteinte via les liens réseau doit être équivalente pour éviter tout impact sur les performances de l'application en cas de défaillance d'une liaison principale. Si vous l'utilisez AWS Direct Connect, les architectures de résilience applicables sont les mêmes que celles permettant d'accéder à un Région AWS, comme indiqué dans les recommandations de AWS Direct Connect résilience. Cependant, certains scénarios s'appliquent principalement aux Zones Locales internationales. Dans le pays où la zone locale est activée, le fait de n'avoir qu'un AWS Direct Connect seul PoP rend impossible la création des architectures recommandées pour AWS Direct Connect la résilience. Si vous n'avez accès qu'à un seul AWS Direct Connect emplacement ou si vous avez besoin d'une résilience allant au-delà d'une simple connexion, vous pouvez créer une appliance VPN sur Amazon EC2 et AWS Direct Connect, comme illustré et expliqué dans le billet de AWS blog Activer la connectivité hautement disponible sur site vers Zones locales AWS.

Réseau de résilience pour les Outposts

Contrairement aux Zones Locales, les Outposts disposent d'une connectivité redondante pour accéder aux charges de travail déployées dans les Outposts depuis votre réseau local. Cette redondance est obtenue grâce à deux périphériques réseau Outposts (). ONDs Chaque OND nécessite au moins deux connexions par fibre optique à 1 Gbit/s, 10 Gbit/s, 40 Gbit/s ou 100 Gbit/s vers votre réseau local. Ces connexions doivent être configurées en tant que groupe d'agrégation de liens (LAG) pour permettre l'ajout évolutif de liens supplémentaires.

Pour plus d'informations sur cette connectivité, consultez la section Connectivité réseau locale pour les Outposts Racks dans la documentation. AWS Outposts

Pour une expérience et une résilience optimales, il est AWS recommandé d'utiliser une connectivité redondante d'au moins 500 Mbit/s (1 Gbit/s est préférable) pour la connexion par liaison de service au. Région AWS Vous pouvez utiliser AWS Direct Connect une connexion Internet pour le lien de service. Ce minimum vous permet de lancer des EC2 instances, d'attacher des volumes EBS et d'y accéder Services AWS, comme Amazon EKS, Amazon EMR et des métriques. CloudWatch

Le schéma suivant illustre cette architecture pour une connexion privée à haute disponibilité.

Le schéma suivant illustre cette architecture pour une connexion publique à haute disponibilité.

Expansion des déploiements en rack d'Outposts avec des racks ACE

Le rack Aggregation, Core, Edge (ACE) constitue un point d'agrégation essentiel pour les déploiements AWS Outposts multirack et est principalement recommandé pour les installations comportant plus de trois racks ou pour la planification d'une future extension. Chaque rack ACE comprend quatre routeurs qui prennent en charge les connexions 10 Gbit/s, 40 Gbit/s et 100 Gbit/s (100 Gbit/s est optimal). Chaque rack peut se connecter à un maximum de quatre appareils clients en amont pour une redondance maximale. Les racks ACE consomment jusqu'à 10 kVA d'énergie et pèsent jusqu'à 705 livres. Les principaux avantages incluent la réduction des exigences en matière de réseau physique, la réduction des liaisons montantes de câblage en fibre optique et la diminution des interfaces virtuelles VLAN. AWS surveille ces racks par le biais de données de télémétrie via des tunnels VPN et travaille en étroite collaboration avec les clients lors de l'installation pour garantir une disponibilité électrique, une configuration réseau et un placement optimal. L'architecture en rack ACE apporte une valeur croissante à mesure que les déploiements évoluent et simplifie efficacement la connectivité tout en réduisant la complexité et les exigences en matière de ports physiques dans les grandes installations.  Pour plus d'informations, consultez le billet de AWS blog Scaling AWS Outposts rack deployments with ACE Rack.

Répartition des instances entre les Outposts et les Zones Locales

Les Outposts et les Zones Locales disposent d'un nombre limité de serveurs informatiques. Si votre application déploie plusieurs instances associées, ces instances peuvent être déployées sur le même serveur ou sur des serveurs du même rack, sauf si elles sont configurées différemment. Outre les options par défaut, vous pouvez répartir les instances sur les serveurs afin de limiter le risque lié à l'exécution d'instances associées sur la même infrastructure. Vous pouvez également répartir les instances sur plusieurs racks en utilisant des groupes de placement de partitions. C'est ce qu'on appelle le modèle de distribution par rayonnage. Utilisez la distribution automatique pour répartir les instances sur les partitions du groupe ou déployez des instances sur des partitions cibles sélectionnées. En déployant des instances sur des partitions cibles, vous pouvez déployer des ressources sélectionnées sur le même rack tout en répartissant les autres ressources entre les racks. Outposts propose également une autre option appelée spread host qui vous permet de répartir votre charge de travail au niveau de l'hôte. Le schéma suivant montre les options de distribution du rack de diffusion et de l'hôte de diffusion.

Amazon RDS Multi-AZ dans AWS Outposts

Lorsque vous utilisez des déploiements d'instances multi-AZ sur des Outposts, Amazon RDS crée deux instances de base de données sur deux Outposts. Chaque avant-poste fonctionne sur sa propre infrastructure physique et se connecte aux différentes zones de disponibilité d'une région pour une haute disponibilité. Lorsque deux Outposts sont connectés via une connexion locale gérée par le client, Amazon RDS gère la réplication synchrone entre les instances de base de données principale et de secours. En cas de défaillance du logiciel ou de l'infrastructure, Amazon RDS place automatiquement l'instance de secours au rôle principal et met à jour l'enregistrement DNS pour qu'il pointe vers la nouvelle instance principale. Pour les déploiements Multi-AZ, Amazon RDS crée une instance de base de données principale sur un Outpost et réplique de manière synchrone les données vers une instance de base de données en veille sur un Outpost différent. Les déploiements multi-AZ sur les Outposts fonctionnent comme les déploiements multi-AZ dans Régions AWS les Outposts, avec les différences suivantes :

Les déploiements multi-AZ sont disponibles pour toutes les versions prises en charge de MySQL et PostgreSQL sur Amazon RDS on Outposts. Les sauvegardes locales ne sont pas prises en charge pour les déploiements multi-AZ.

Le schéma suivant montre l'architecture des configurations multi-AZ d'Amazon RDS on Outposts.

Mécanismes de basculement

Équilibrage de charge et dimensionnement automatique

Elastic Load Balancing (ELB) répartit automatiquement le trafic entrant de votre application sur toutes les EC2 instances que vous exécutez. ELB aide à gérer les demandes entrantes en acheminant le trafic de manière optimale afin qu'aucune instance ne soit débordée. Pour utiliser ELB avec votre groupe Amazon EC2 Auto Scaling, associez l'équilibreur de charge à votre groupe Auto Scaling. Cela enregistre le groupe auprès de l'équilibreur de charge, qui agit comme un point de contact unique pour tout le trafic Web entrant dans votre groupe. Lorsque vous utilisez ELB avec votre groupe Auto Scaling, il n'est pas nécessaire d'enregistrer des EC2 instances individuelles auprès de l'équilibreur de charge. Les instances qui sont lancées par votre groupe Auto Scaling sont automatiquement enregistrées auprès de l'équilibreur de charge. De même, les instances mises hors service par votre groupe Auto Scaling sont automatiquement désenregistrées de l'équilibreur de charge. Après avoir attaché un équilibreur de charge à votre groupe Auto Scaling, vous pouvez configurer votre groupe pour utiliser les métriques ELB (telles que le nombre de demandes d'Application Load Balancer par cible) afin d'adapter le nombre d'instances du groupe en fonction des fluctuations de la demande. Vous pouvez éventuellement ajouter des tests de santé ELB à votre groupe Auto Scaling afin qu'Amazon EC2 Auto Scaling puisse identifier et remplacer les instances défectueuses sur la base de ces tests de santé. Vous pouvez également créer une CloudWatch alarme Amazon qui vous avertit si le nombre d'hôtes sains du groupe cible est inférieur au nombre autorisé.

Le schéma suivant illustre comment un Application Load Balancer gère les charges de travail sur Amazon dans. EC2 AWS Outposts

Le schéma suivant illustre une architecture similaire pour Amazon EC2 dans les Zones Locales.

Amazon Route 53 pour le basculement du DNS

Lorsque plusieurs ressources exécutent la même fonction, par exemple plusieurs serveurs HTTP ou de messagerie, vous pouvez configurer Amazon Route 53 pour vérifier l'état de vos ressources et répondre aux requêtes DNS en utilisant uniquement les ressources saines. Supposons, par exemple, que votre site Web soit hébergé sur deux serveurs. example.com Un serveur se trouve dans une zone locale et l'autre dans un avant-poste. Vous pouvez configurer Route 53 pour vérifier l'état de ces serveurs et pour répondre aux requêtes DNS en example.com utilisant uniquement les serveurs actuellement sains. Si vous utilisez des enregistrements d'alias pour acheminer le trafic vers AWS des ressources sélectionnées, telles que les équilibreurs de charge ELB, vous pouvez configurer Route 53 pour évaluer l'état de la ressource et acheminer le trafic uniquement vers les ressources saines. Lorsque vous configurez un enregistrement d'alias pour évaluer l'état d'une ressource, il n'est pas nécessaire de créer un bilan de santé pour cette ressource.

Le schéma suivant illustre les mécanismes de basculement de Route 53.

Amazon Route 53 Resolver sur AWS Outposts

Amazon Route 53 Resolverest disponible sur les supports Outposts. Il fournit à vos services et applications sur site une résolution DNS locale directement depuis Outposts. Les points de terminaison Local Route 53 Resolver permettent également la résolution DNS entre les Outposts et votre serveur DNS local. Route 53 Resolver on Outposts permet d'améliorer la disponibilité et les performances de vos applications sur site.

L'un des cas d'utilisation typiques des Outposts consiste à déployer des applications qui nécessitent un accès à faible latence aux systèmes sur site, tels que les équipements d'usine, les applications de trading à haute fréquence et les systèmes de diagnostic médical.

Lorsque vous choisissez d'utiliser les résolveurs Route 53 locaux sur les Outposts, les applications et les services continueront de bénéficier de la résolution DNS locale pour découvrir d'autres services, même en cas de perte de connectivité avec un Région AWS parent. Les résolveurs locaux aident également à réduire le temps de latence pour les résolutions DNS, car les résultats des requêtes sont mis en cache et diffusés localement depuis les Outposts, ce qui élimine les allers-retours inutiles vers le parent. Région AWS Toutes les résolutions DNS pour les applications des Outposts VPCs qui utilisent un DNS privé sont servies localement.

Outre l'activation des résolveurs locaux, ce lancement active également les points de terminaison des résolveurs locaux. Les points de terminaison sortants Route 53 Resolver permettent aux résolveurs Route 53 de transférer les requêtes DNS aux résolveurs DNS que vous gérez, par exemple sur votre réseau local. En revanche, les points de terminaison entrants Route 53 Resolver transmettent les requêtes DNS qu'ils reçoivent de l'extérieur du VPC au résolveur qui s'exécute sur Outposts. Il vous permet d'envoyer des requêtes DNS pour des services déployés sur un VPC Outposts privé depuis l'extérieur de ce VPC. Pour plus d'informations sur les points de terminaison entrants et sortants, consultez la section Résolution des requêtes DNS entre VPCs et votre réseau dans la documentation Route 53.