Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Modalità di errore più ampie
Per progettare architetture HA per mitigare modalità di guasto più ampie come guasti in rack, data center, Availability Zone (AZ) o Region, è necessario implementare più Outposts con una capacità di infrastruttura sufficiente in data center separati con alimentazione e connettività WAN indipendenti. Gli Outposts vengono ancorati a diverse zone di disponibilità AZs () all'interno di Regione AWS una o più regioni. È inoltre necessario fornire una site-to-site connettività resiliente e sufficiente tra le sedi per supportare la replica sincrona o asincrona dei dati e il reindirizzamento del traffico dei carichi di lavoro. A seconda dell'architettura dell'applicazione, puoi utilizzare [Amazon Route 53 DNS e Amazon Route 53](https://aws.amazon.com/route53/) [on Outposts](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/outpost-resolver.html) disponibili a livello globale per indirizzare il traffico verso la posizione desiderata e automatizzare il reindirizzamento del traffico verso le località sopravvissute in caso di guasti su larga scala.
# Routing intra-VPC Outposts Rack
AWS Outposts rack supporta la [comunicazione intra-VPC tra più Outposts](https://aws.amazon.com/blogs/compute/introducing-intra-vpc-communication-across-multiple-outposts-with-direct-vpc-routing/). Le risorse su due Outpost logici separati possono comunicare tra loro instradando il traffico tra le sottoreti all'interno dello stesso VPC che le attraversa utilizzando i gateway locali di Outpost (LGW). Con la comunicazione intra-VPC tra più Outposts, puoi sovrascrivere la Local Route nella tabella di routing associata alla sottorete Outposts aggiungendo una route più specifica all'altra sottorete Outposts utilizzando l'LGW locale come hop successivo. [Può offrire vantaggi all'architettura di applicazioni che richiedono l'estensione di un VPC tra due Outpost logici come [Amazon ECS su due rack Outposts o un cluster Amazon EKS su due cluster](https://community.aws/content/2k5wK9P1oSC9I4ZzuSLWynsiJaa/extend-amazon-ecs-across-two-outposts-racks) Amazon EKS. AWS Outposts](https://aws.amazon.com/blogs/containers/deploy-an-amazon-eks-cluster-across-aws-outposts-with-intra-vpc-communication/)
![\[Diagramma che mostra i percorsi di rete per un singolo VPC con più Outposts logici\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/aws-outposts-high-availability-design/images/page-49-single-vpc-multiple-outposts.png)
Outposts-to-Outposts il routing del traffico attraverso la Regione è bloccato in quanto si tratta di un anti-pattern. Tale traffico comporterebbe costi di uscita in entrambe le direzioni e una latenza significativamente più elevata rispetto al routing del traffico attraverso la WAN del cliente.
# Routing tra VPC tra Outposts Rack
Le risorse su due Outposts separati distribuiti in modi diversi VPCs possono comunicare tra loro attraverso la rete dei clienti. L'implementazione di questa architettura consente di instradare il traffico Outposts-to-Outposts dalle reti locali locali e WAN aggiungendo percorsi verso gli outpost/sottoreti VPC della controparte.
![\[Diagramma che mostra i percorsi di rete per più VPC con più Outposts logici\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/aws-outposts-high-availability-design/images/page-50-multiple-vpc-multiple-outposts-networking-path.png)
Pratiche consigliate per la protezione da modalità di errore più ampie:
+ Implementa più Outposts ancorati a AZs più regioni.
+ Utilizzali separatamente VPCs per ogni Outpost in una distribuzione Multi-Outpost.
# Route 53 Local Resolver su Outposts
Quando il collegamento al AWS Outposts servizio viene influenzato da una disconnessione temporanea, la risoluzione DNS locale fallisce, rendendo difficile per le applicazioni e i servizi scoprire altri servizi, anche quando sono in esecuzione sullo stesso rack Outposts. Tuttavia, con Route 53 Resolver attivo AWS Outposts, le applicazioni e i servizi continueranno a beneficiare della risoluzione DNS locale per scoprire altri servizi, anche in caso di perdita della connettività del genitore. Regione AWS Allo stesso tempo, per la risoluzione DNS per i nomi host locali, il Route 53 Resolver on Outposts aiuta a ridurre la latenza poiché i risultati delle query vengono memorizzati nella cache e serviti localmente, pur essendo completamente integrato con gli endpoint Route 53 Resolver.
Gli endpoint in entrata del resolver Route 53 inoltrano le query DNS ricevute dall'esterno del VPC al Resolver in esecuzione in Outposts. Al contrario, Route 53 Resolver Outbound consente ai Resolver Route 53 di inoltrare le query DNS ai resolver DNS gestiti sulla rete locale, come illustrato nel diagramma seguente.
![\[Diagramma che mostra il resolver Route 53 su Outposts\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/aws-outposts-high-availability-design/images/page-51-route53-resolver-outposts.png)
## Considerazioni su Route 53 Resolver on Outposts
Considera i seguenti aspetti:
+ È necessario abilitare il Route 53 Resolver su Outposts e si applica all'intera distribuzione Outposts, anche se ciò comporta più rack di elaborazione con un unico ID Outposts.
+ Per abilitare questa funzionalità, i tuoi Outposts devono avere una capacità di calcolo sufficiente per implementare il resolver locale sotto forma di almeno 4 EC2 istanze di qualsiasi c5.xlarge, m5.large o m5.xlarge.
+ Se utilizzi un DNS privato, devi condividere la Private Hosted Zone con gli VPCs Outposts richiesti per memorizzare nella cache i record localmente nel Route 53 Resolver on Outposts.
+ Per consentire l'integrazione con il DNS locale con gli endpoint in entrata e in uscita, gli Outposts devono disporre di una capacità di elaborazione sufficiente per distribuire due istanze per endpoint Route53. EC2
# Cluster locale EKS su Outposts
In caso di disconnessione del collegamento di servizio Outposts dalla regione principale, potrebbero verificarsi problemi con servizi come EKS Extended Cluster, in cui il piano di controllo si trova nella regione. Tra le sfide c'è la perdita di comunicazione tra il piano di controllo EKS e i nodi di lavoro e. PODs Sebbene entrambi i nodi di lavoro PODs possano continuare a funzionare e fornire assistenza alle applicazioni che risiedono su Outposts localmente, il piano di controllo di Kubernetes potrebbe considerarle non funzionanti e programmarne la sostituzione quando la connessione al piano di controllo verrà ripristinata. Ciò può causare interruzioni delle applicazioni quando viene ripristinata la connettività.
Per semplificare questa operazione, è disponibile un'opzione per ospitare l'intero cluster EKS su Outposts. In questa configurazione, sia il piano di controllo Kubernetes che i nodi di lavoro vengono eseguiti localmente in sede sulla capacità di calcolo di Outposts. In questo modo, il cluster continua a funzionare anche in caso di interruzione temporanea della connessione al service link e dopo il ripristino.
![\[Cluster locale Amazon EKS su Outposts\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/aws-outposts-high-availability-design/images/page-52-eks-local-cluster-outposts.png)
## Considerazioni su EKS Local Cluster on Outposts
Ci sono alcune considerazioni da fare quando un cluster locale EKS viene distribuito in Outposts:
+ Durante una disconnessione non sono disponibili opzioni per eseguire alcuna modifica nel cluster stesso che richieda l'aggiunta di nuovi nodi di lavoro o la scalabilità automatica di un gruppo di nodi, purché EC2 dipenda dalle chiamate API ASG verso la AWS regione principale.
+ [• Esiste una serie di funzionalità non supportate sui cluster locali elencate nel supporto eksctl. AWS Outposts](https://eksctl.io/usage/outposts/) .