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à.

Resilienza all'edge

Il pilastro dell'affidabilità comprende la capacità di un carico di lavoro di svolgere la funzione prevista in modo corretto e coerente quando previsto. Ciò include la capacità di utilizzare e testare il carico di lavoro durante il suo ciclo di vita. In questo senso, quando si progetta un'architettura resiliente all'edge, è necessario innanzitutto considerare quali infrastrutture verranno utilizzate per implementare tale architettura. Esistono tre possibili combinazioni da implementare utilizzando Zone locali AWS e AWS Outposts: Outpost to Outpost, Outpost to Local Zone e Local Zone to Local Zone, come illustrato nel diagramma seguente. Sebbene esistano altre possibilità per architetture resilienti, come la combinazione di servizi AWS edge con un'infrastruttura locale tradizionale, oppure Regioni AWS, questa guida si concentra su queste tre combinazioni che si applicano alla progettazione di servizi cloud ibridi

Considerazioni sull'infrastruttura

At AWS, uno dei principi fondamentali della progettazione dei servizi consiste nell'evitare singoli punti di errore nell'infrastruttura fisica sottostante. Grazie a questo principio, AWS il software e i sistemi utilizzano più zone di disponibilità e sono resilienti al guasto di una singola zona. All'edge, AWS offre infrastrutture basate su Local Zones e Outposts. Pertanto, un fattore critico per garantire la resilienza nella progettazione dell'infrastruttura è definire dove vengono distribuite le risorse di un'applicazione.

Zone locali

Le Local Zone agiscono in modo simile alle Zone di disponibilità al loro interno Regione AWS, in quanto possono essere selezionate come ubicazione di collocamento per AWS risorse zonali come sottoreti e istanze. EC2 Tuttavia, non si trovano in centri industriali e IT Regione AWS, ma in prossimità di centri abitati, industriali e IT, dove oggi non esistono. Regione AWS Nonostante ciò, mantengono ancora connessioni sicure e a elevata larghezza di banda tra i carichi di lavoro locali nella zona locale e i carichi di lavoro in esecuzione nella. Regione AWS Pertanto, è consigliabile utilizzare Local Zones per distribuire i carichi di lavoro più vicino agli utenti per requisiti di bassa latenza.

Outposts

AWS Outposts è un servizio completamente gestito che estende AWS l'infrastruttura e gli strumenti al data center. Servizi AWS APIs La stessa infrastruttura hardware utilizzata in Cloud AWS è installata nel data center. Gli Outposts vengono quindi collegati a quelli più vicini. Regione AWS Puoi utilizzare Outposts per supportare i tuoi carichi di lavoro con bassa latenza o requisiti locali di elaborazione dei dati.

Zone di disponibilità per i genitori

Ogni zona locale o avamposto ha una regione principale (detta anche regione di origine). La regione principale è quella in cui è ancorato il piano di controllo dell'infrastruttura AWS periferica (Outpost o Local Zone). Nel caso delle Local Zones, la regione principale è un componente architettonico fondamentale di una Local Zone e non può essere modificata dai clienti. AWS Outposts si estende Cloud AWS all'ambiente locale, quindi è necessario selezionare una regione e una zona di disponibilità specifiche durante il processo di ordinazione. Questa selezione fissa il piano di controllo della distribuzione di Outposts all' AWS infrastruttura scelta.

Quando si sviluppano architetture ad alta disponibilità nell'edge, la regione principale di queste infrastrutture, come Outposts o Local Zones, deve essere la stessa, in modo che un VPC possa essere esteso tra di loro. Questo VPC esteso è la base per la creazione di queste architetture ad alta disponibilità. Quando si definisce un'architettura altamente resiliente, è per questo che è necessario convalidare la regione principale e la zona di disponibilità della regione in cui il servizio sarà (o è) ancorato. Come illustrato nel diagramma seguente, se si desidera implementare una soluzione ad alta disponibilità tra due Outposts, è necessario scegliere due diverse zone di disponibilità per ancorare gli Outposts. Ciò consente un'architettura Multi-AZ dal punto di vista del piano di controllo. Se desideri implementare una soluzione ad alta disponibilità che includa una o più Local Zones, devi prima convalidare la zona di disponibilità principale in cui è ancorata l'infrastruttura. A tale scopo, utilizzate il seguente comando: AWS CLI

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

Risultato del comando precedente:

{     "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"
         }
     ]
 }

In questo esempio, la zona locale di Miami (us-east-1d-mia-1a1) è ancorata alla zona di us-east-1d-az2 disponibilità. Pertanto, se è necessario creare un'architettura resiliente all'edge, è necessario assicurarsi che l'infrastruttura secondaria (Outposts o Local Zones) sia ancorata a una zona di disponibilità diversa da. us-east-1d-az2 Ad esempio, us-east-1d-az1 sarebbe valido.

Il diagramma seguente fornisce esempi di infrastrutture edge ad alta disponibilità.

Considerazioni sulla rete

Questa sezione illustra le considerazioni iniziali sulla rete periferica, principalmente per le connessioni per accedere all'infrastruttura perimetrale. Esamina le architetture valide che forniscono una rete resiliente per il collegamento di servizio.

Rete resiliente per Local Zones

Le Local Zones sono collegate alla regione principale con collegamenti multipli, ridondanti, sicuri e ad alta velocità che consentono di utilizzare qualsiasi servizio regionale, come Amazon S3 e Amazon RDS, senza interruzioni. Sei responsabile della fornitura della connettività dall'ambiente locale o dagli utenti alla zona locale. Indipendentemente dall'architettura di connettività scelta (ad esempio, VPN o AWS Direct Connect), la latenza che deve essere raggiunta tramite i collegamenti di rete deve essere equivalente per evitare qualsiasi impatto sulle prestazioni delle applicazioni in caso di guasto in un collegamento principale. Se utilizzate AWS Direct Connect, le architetture di resilienza applicabili sono le stesse di quelle per l'accesso a an Regione AWS, come documentato nelle raccomandazioni sulla resilienza.AWS Direct Connect Tuttavia, esistono scenari che si applicano principalmente alle Local Zones internazionali. Nel paese in cui è abilitata la Local Zone, avere un solo AWS Direct Connect PoP rende impossibile la creazione delle architetture consigliate per AWS Direct Connect la resilienza. Se hai accesso a una sola AWS Direct Connect posizione o hai bisogno di resilienza oltre una singola connessione, puoi creare un'appliance VPN su Amazon EC2 e AWS Direct Connect, come illustrato e discusso nel post del AWS blog Enabling high availability connectivity from on-premise to. Zone locali AWS

Rete di resilienza per Outposts

A differenza delle Local Zones, gli Outposts dispongono di una connettività ridondante per accedere ai carichi di lavoro distribuiti in Outposts dalla rete locale. Questa ridondanza viene ottenuta tramite due dispositivi di rete Outposts (). ONDs Ogni OND richiede almeno due connessioni in fibra a 1 Gbps, 10 Gbps, 40 Gbps o 100 Gbps alla rete locale. Queste connessioni devono essere configurate come un gruppo di aggregazione di link (LAG) per consentire l'aggiunta scalabile di più collegamenti.

Per ulteriori informazioni su questa connettività, consulta Connettività di rete locale per Outposts Racks nella AWS Outposts documentazione.

Per un'esperienza e una resilienza ottimali, si AWS consiglia di utilizzare una connettività ridondante di almeno 500 Mbps (1 Gbps è preferibile) per la connessione Service Link a. Regione AWSÈ possibile utilizzare AWS Direct Connect o una connessione Internet per il collegamento al servizio. Questo minimo consente di avviare EC2 istanze, collegare volumi EBS e accedere, ad esempio Amazon EKS Servizi AWS, Amazon EMR e metriche. CloudWatch

Il diagramma seguente illustra questa architettura per una connessione privata ad alta disponibilità.

Il diagramma seguente illustra questa architettura per una connessione pubblica ad alta disponibilità.

Scalabilità delle installazioni rack Outposts con i rack ACE

Il rack Aggregation, Core, Edge (ACE) funge da punto di aggregazione critico per le implementazioni AWS Outposts multi-rack ed è consigliato principalmente per installazioni che superano i tre rack o per pianificare espansioni future. Ogni rack ACE è dotato di quattro router che supportano connessioni a 10 Gbps, 40 Gbps e 100 Gbps (100 Gbps sono ottimali). Ogni rack può connettersi a un massimo di quattro dispositivi upstream del cliente per la massima ridondanza. I rack ACE consumano fino a 10 kVA di potenza e pesano fino a 705 libbre. I vantaggi principali includono la riduzione dei requisiti di rete fisica, un minor numero di uplink di cablaggio in fibra e una riduzione delle interfacce virtuali VLAN. AWS monitora questi rack tramite dati di telemetria tramite tunnel VPN e collabora a stretto contatto con i clienti durante l'installazione per garantire la corretta disponibilità dell'alimentazione, la configurazione di rete e il posizionamento ottimale. L'architettura rack ACE offre un valore crescente man mano che le implementazioni scalano e semplifica efficacemente la connettività, riducendo al contempo la complessità e i requisiti delle porte fisiche nelle installazioni più grandi.  Per ulteriori informazioni, consulta il post del AWS blog Scaling AWS Outposts rack deployments with ACE Rack.

Distribuzione delle istanze tra Outposts e Local Zones

Outposts e Local Zones hanno un numero finito di server di elaborazione. Se l'applicazione distribuisce più istanze correlate, queste istanze potrebbero essere distribuite sullo stesso server o su server nello stesso rack, a meno che non siano configurate diversamente. Oltre alle opzioni predefinite, puoi distribuire le istanze tra i server per mitigare il rischio di eseguire istanze correlate sulla stessa infrastruttura. È inoltre possibile distribuire le istanze su più rack utilizzando i gruppi di posizionamento delle partizioni. Questo è chiamato modello di distribuzione Spread Rack. Utilizza la distribuzione automatica per distribuire le istanze tra le partizioni del gruppo o distribuisci le istanze su partizioni di destinazione selezionate. Distribuendo le istanze sulle partizioni di destinazione, puoi distribuire risorse selezionate sullo stesso rack distribuendo altre risorse tra i rack. Outposts offre anche un'altra opzione chiamata spread host che consente di distribuire il carico di lavoro a livello di host. Il diagramma seguente mostra le opzioni di distribuzione spread rack e spread host.

Ingresso Amazon RDS Multi-AZ AWS Outposts

Quando utilizzi distribuzioni di istanze Multi-AZ su Outposts, Amazon RDS crea due istanze di database su due Outposts. Ogni Outpost funziona sulla propria infrastruttura fisica e si connette a diverse zone di disponibilità in una regione per un'elevata disponibilità. Quando due Outposts sono collegati tramite una connessione locale gestita dal cliente, Amazon RDS gestisce la replica sincrona tra l'istanza del database primario e quella di standby. In caso di guasto del software o dell'infrastruttura, Amazon RDS promuove automaticamente l'istanza di standby al ruolo principale e aggiorna il record DNS in modo che punti alla nuova istanza primaria. Per eseguire le implementazioni Multi-AZ, Amazon RDS crea un'istanza database primaria su un outpost e replica in modo sincrono i dati in un'istanza database in standby su un altro outpost. Le implementazioni Multi-AZ su Outposts funzionano come le implementazioni Multi-AZ in, con le seguenti differenze: Regioni AWS

Le implementazioni Multi-AZ sono disponibili per tutte le versioni supportate di MySQL e PostgreSQL su Amazon RDS on Outposts. I backup locali non sono supportati per le implementazioni Multi-AZ.

Il diagramma seguente mostra l'architettura per le configurazioni Amazon RDS on Outposts Multi-AZ.

Meccanismi di failover

Bilanciamento del carico e scalabilità automatica

Elastic Load Balancing (ELB) distribuisce automaticamente il traffico delle applicazioni in entrata su tutte le EC2 istanze in esecuzione. ELB aiuta a gestire le richieste in entrata indirizzando il traffico in modo ottimale in modo che nessuna singola istanza venga sovraccaricata. Per utilizzare ELB con il tuo gruppo Amazon EC2 Auto Scaling, collega il load balancer al tuo gruppo Auto Scaling. In questo modo il gruppo viene registrato con il sistema di bilanciamento del carico, che funge da unico punto di contatto per tutto il traffico web in entrata verso il gruppo. Quando si utilizza ELB con il gruppo Auto Scaling, non è necessario registrare EC2 singole istanze con il sistema di bilanciamento del carico. Le istanze avviate dal gruppo con dimensionamento automatico vengono registrate automaticamente con il sistema di bilanciamento del carico. Analogamente, le istanze terminate dal gruppo Auto Scaling vengono automaticamente cancellate dal sistema di bilanciamento del carico. Dopo aver collegato un load balancer al gruppo Auto Scaling, puoi configurare il gruppo in modo che utilizzi le metriche ELB (come il numero di richieste di Application Load Balancer per target) per scalare il numero di istanze nel gruppo in base alle fluttuazioni della domanda. Facoltativamente, puoi aggiungere controlli di integrità ELB al tuo gruppo Auto Scaling in modo che Amazon Auto Scaling possa identificare e sostituire EC2 le istanze non integre sulla base di questi controlli di integrità. Puoi anche creare un CloudWatch allarme Amazon che ti avvisi se il numero di host sani del gruppo target è inferiore a quello consentito.

Il diagramma seguente illustra come un Application Load Balancer gestisce i carichi di lavoro su Amazon in. EC2 AWS Outposts

Il diagramma seguente illustra un'architettura simile per Amazon EC2 in Local Zones.

Amazon Route 53 per il failover DNS

Se disponi di più risorse che svolgono la stessa funzione, ad esempio più server HTTP o di posta, puoi configurare Amazon Route 53 per verificare lo stato delle tue risorse e rispondere alle query DNS utilizzando solo le risorse integre. Ad esempio, supponiamo che il tuo sito Web sia ospitato su due server. example.com Un server si trova in una zona locale e l'altro server si trova in un avamposto. È possibile configurare Route 53 per verificare lo stato di tali server e rispondere alle query DNS example.com utilizzando solo i server attualmente integri. Se utilizzi record di alias per indirizzare il traffico verso AWS risorse selezionate, come i sistemi di bilanciamento del carico ELB, puoi configurare Route 53 per valutare lo stato della risorsa e indirizzare il traffico solo verso risorse integre. Quando configuri un record di alias per valutare lo stato di una risorsa, non è necessario creare un controllo dello stato di quella risorsa.

Il diagramma seguente illustra i meccanismi di failover della Route 53.

Amazon Route 53 Resolver su AWS Outposts

Amazon Route 53 Resolverè disponibile negli scaffali Outposts. Fornisce servizi e applicazioni locali con risoluzione DNS locale direttamente da Outposts. Gli endpoint Local Route 53 Resolver abilitano anche la risoluzione DNS tra Outposts e il server DNS locale. Route 53 Resolver on Outposts aiuta a migliorare la disponibilità e le prestazioni delle applicazioni locali.

Uno dei casi d'uso tipici di Outposts consiste nell'implementazione di applicazioni che richiedono un accesso a bassa latenza ai sistemi locali, come apparecchiature di fabbrica, applicazioni di trading ad alta frequenza e sistemi di diagnosi medica.

Se scegli di utilizzare i Resolver Route 53 locali su Outposts, le applicazioni e i servizi continueranno a beneficiare della risoluzione DNS locale per scoprire altri servizi, anche in caso di perdita della connettività con un genitore. Regione AWS I Resolver locali aiutano anche a ridurre la latenza per le risoluzioni DNS perché i risultati delle query vengono memorizzati nella cache e serviti localmente dagli Outposts, il che elimina inutili round trip verso il principale. Regione AWS Tutte le risoluzioni DNS per le applicazioni in Outposts VPCs che utilizzano DNS privato vengono servite localmente.

Oltre ad abilitare i Resolver locali, questo lancio abilita anche gli endpoint Resolver locali. Gli endpoint in uscita Route 53 Resolver consentono ai Resolver Route 53 di inoltrare le query DNS ai resolver DNS che gestisci, ad esempio sulla tua rete locale. Al contrario, gli endpoint in entrata di Route 53 Resolver inoltrano le query DNS che ricevono dall'esterno del VPC al Resolver in esecuzione su Outposts. Consente di inviare query DNS per i servizi distribuiti su un VPC Outposts privato dall'esterno di tale VPC. Per ulteriori informazioni sugli endpoint in entrata e in uscita, consulta Risolvere le query DNS tra e la rete nella documentazione di Route 53. VPCs