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.
# Modes de défaillance plus importants
Pour concevoir des architectures HA afin d'atténuer les défaillances les plus importantes, telles que les pannes de rack, de centre de données, de zone de disponibilité (AZ) ou de région, vous devez déployer plusieurs Outposts dotés d'une capacité d'infrastructure suffisante dans des centres de données distincts dotés d'une alimentation et d'une connectivité WAN indépendantes. Vous ancrez les Outposts dans différentes zones de disponibilité (AZs) au sein d'une Région AWS ou de plusieurs régions. Vous devez également fournir une site-to-site connectivité résiliente et suffisante entre les sites pour prendre en charge la réplication synchrone ou asynchrone des données et la redirection du trafic de charge de travail. En fonction de l'architecture de votre application, vous pouvez utiliser le DNS [Amazon Route 53](https://aws.amazon.com/route53/) et [Amazon Route 53 on Outposts](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/outpost-resolver.html) disponibles dans le monde entier pour diriger le trafic vers l'emplacement souhaité et automatiser la redirection du trafic vers les sites survivants en cas de panne à grande échelle.
# Routage intra-VPC d'Outposts Rack
AWS Outposts Le rack prend en charge les [communications intra-VPC entre plusieurs Outposts](https://aws.amazon.com/blogs/compute/introducing-intra-vpc-communication-across-multiple-outposts-with-direct-vpc-routing/). Les ressources de deux Outposts logiques distincts peuvent communiquer entre elles en acheminant le trafic entre les sous-réseaux du même VPC qui les traversent à l'aide des passerelles locales d'Outpost (LGW). Grâce à la communication intra-VPC entre plusieurs Outposts, vous pouvez remplacer la route locale dans la table de routage associée à votre sous-réseau Outposts en ajoutant une route plus spécifique à l'autre sous-réseau Outposts en utilisant le LGW local comme prochain saut. [Cela peut apporter des avantages à l'architecture d'applications qui nécessitent d'étendre un VPC entre deux Outposts logiques, comme [Amazon ECS sur deux racks d'Outposts ou un cluster Amazon EKS sur l'](https://community.aws/content/2k5wK9P1oSC9I4ZzuSLWynsiJaa/extend-amazon-ecs-across-two-outposts-racks)autre. AWS Outposts](https://aws.amazon.com/blogs/containers/deploy-an-amazon-eks-cluster-across-aws-outposts-with-intra-vpc-communication/)
![\[Schéma montrant les chemins réseau pour un seul VPC avec plusieurs Outposts logiques\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/aws-outposts-high-availability-design/images/page-49-single-vpc-multiple-outposts.png)
Outposts-to-Outposts le routage du trafic à travers la région est bloqué car il s'agit d'un anti-modèle. Un tel trafic entraînerait des frais de sortie dans les deux sens et une latence nettement supérieure à celle du routage du trafic sur le réseau étendu du client.
# Routage inter-VPC des Outposts Rack
Les ressources de deux Outposts distincts déployés dans des environnements différents VPCs peuvent communiquer entre elles sur le réseau du client. Le déploiement de cette architecture vous permet d'acheminer le trafic Outposts-to-Outposts via vos réseaux locaux sur site et WAN en ajoutant des itinéraires vers les avant-posts/sous-réseaux VPC homologues.
![\[Schéma montrant les chemins réseau pour plusieurs VPC avec plusieurs Outposts logiques\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/aws-outposts-high-availability-design/images/page-50-multiple-vpc-multiple-outposts-networking-path.png)
Pratiques recommandées pour se protéger contre les modes de défaillance plus importants :
+ Déployez plusieurs Outposts ancrés dans plusieurs régions AZs .
+ Utilisez une méthode séparée VPCs pour chaque avant-poste dans le cadre d'un déploiement multi-avant-postes.
# Résolution locale Route 53 sur les Outposts
Lorsque le lien de AWS Outposts service est affecté par une déconnexion temporaire, la résolution DNS locale échoue, ce qui empêche les applications et les services de découvrir d'autres services, même s'ils s'exécutent sur le même rack Outposts. Cependant, lorsque le résolveur Route 53 est activé AWS 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é au profit du parent Région AWS. Dans le même temps, pour la résolution DNS des noms d'hôtes locaux, le résolveur Route 53 sur Outposts permet de réduire le temps de latence car les résultats des requêtes sont mis en cache et diffusés localement, tout en étant totalement intégré aux points de terminaison du résolveur Route 53.
Les points de terminaison entrants du résolveur Route 53 transmettent les requêtes DNS qu'ils reçoivent depuis l'extérieur du VPC au résolveur exécuté dans Outposts. En revanche, Route 53 Resolver Outbound permet aux résolveurs Route 53 de transférer les requêtes DNS aux résolveurs DNS que vous gérez sur votre réseau local, comme illustré dans le schéma suivant.
![\[Schéma illustrant le résolveur Route 53 sur les Outposts\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/aws-outposts-high-availability-design/images/page-51-route53-resolver-outposts.png)
## Considérations relatives à Route 53 Resolver on Outposts
Éléments à prendre en compte :
+ Vous devez activer le résolveur Route 53 sur les Outposts, et cela s'applique à l'ensemble du déploiement d'Outposts, même s'il implique plusieurs racks de calcul sous un seul identifiant Outposts.
+ Pour activer cette fonctionnalité, vos Outposts doivent disposer d'une capacité de calcul suffisante pour déployer le résolveur local sous la forme d'au moins 4 EC2 instances de c5.xlarge, m5.large ou m5.xlarge.
+ Si vous utilisez un DNS privé, vous devez partager la zone hébergée privée avec les « Outposts VPCs » requis afin de mettre en cache les enregistrements localement dans le résolveur Route 53 sur les Outposts.
+ Afin de permettre l'intégration au DNS local avec les points de terminaison entrants et sortants, vos Outposts doivent disposer d'une capacité de calcul suffisante pour déployer deux instances par point de terminaison Route53. EC2
# Cluster local EKS sur les Outposts
Lorsque le lien de service Outposts est déconnecté de la région parent, des problèmes peuvent se poser avec des services tels que EKS Extended Cluster, où le plan de contrôle réside dans la région. Parmi les défis figure la perte de communication entre le plan de contrôle EKS et les nœuds de travail et PODs. Bien que les deux nœuds de travail PODs puissent continuer à fonctionner et à gérer les applications résidant sur les Outposts localement, le plan de contrôle Kubernetes peut les considérer comme défaillants et planifier leur remplacement lorsque la connexion au plan de contrôle sera rétablie. Cela peut entraîner des interruptions de service des applications lorsque la connectivité est rétablie.
Pour simplifier les choses, il existe une option permettant d'héberger l'intégralité de votre cluster EKS sur Outposts. Dans cette configuration, le plan de contrôle Kubernetes et vos nœuds de travail s'exécutent localement sur site sur la capacité de calcul de vos Outposts. Ainsi, votre cluster continue de fonctionner même en cas d'interruption temporaire de votre connexion Service Link et après sa restauration.
![\[Cluster local Amazon EKS sur Outposts\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/aws-outposts-high-availability-design/images/page-52-eks-local-cluster-outposts.png)
## Considérations relatives au cluster local EKS sur Outposts
Certaines considérations doivent être prises en compte lors du déploiement d'un cluster local EKS dans Outposts :
+ Lors d'une déconnexion, il n'existe aucune option permettant d'exécuter une modification dans le cluster lui-même nécessitant l'ajout de nouveaux nœuds de travail ou la mise à l'échelle automatique d'un groupe de nœuds, tant que cela dépend EC2 des appels d'API ASG vers la AWS région parent.
+ • Il existe un ensemble de fonctionnalités non prises en charge sur les clusters locaux répertoriées sur le support [eksctl AWS Outposts](https://eksctl.io/usage/outposts/). .