REL10-BP01 Implementazione del carico di lavoro in più sedi - Pilastro dell'affidabilità

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

REL10-BP01 Implementazione del carico di lavoro in più sedi

Distribuisci i dati e le risorse del carico di lavoro su più zone di disponibilità o, se necessario, su diverse Regioni AWS. Questi luoghi possono essere diversi a seconda delle necessità.

Uno dei principi fondamentali per la progettazione dei servizi AWS è la prevenzione di singoli punti di errore nell'infrastruttura fisica sottostante. Questo ci spinge a creare software e sistemi che utilizzano più zone di disponibilità e sono resistenti ai guasti di una singola zona. Allo stesso modo, i sistemi sono costruiti per resistere ai guasti di un singolo nodo di calcolo, singolo volume di archiviazione o singola istanza di un database. Quando si costruisce un sistema che si basa su componenti ridondanti, è importante assicurarsi che i componenti funzionino in modo indipendente e, nel caso di, in modo autonomo. Regioni AWS I vantaggi ottenuti dai calcoli di disponibilità teorica con componenti ridondanti sono validi solo se questo continua a essere vero.

Zone di disponibilità () AZs

Regioni AWS sono composte da più zone di disponibilità progettate per essere indipendenti l'una dall'altra. Ogni zona di disponibilità è separata da una distanza fisica significativa da altre zone per evitare scenari di guasto correlati, dovuti a rischi ambientali come incendi, inondazioni e tornado. Ogni zona di disponibilità ha anche un'infrastruttura fisica indipendente: connessioni dedicate di alimentazione di rete, fonti di alimentazione di backup autonome, servizi meccanici indipendenti e connettività di rete indipendente all'interno e all'esterno della zona di disponibilità. Questa struttura limita gli errori di uno qualsiasi di questi sistemi alla sola AZ interessata. Nonostante siano geograficamente separate, le zone di disponibilità sono situate nella stessa area regionale, il che consente una rete a elevato throughput e bassa latenza. L'intera area Regione AWS (in tutte le zone di disponibilità, costituita da più data center fisicamente indipendenti) può essere considerata come un unico obiettivo di implementazione logico per il carico di lavoro, inclusa la possibilità di replicare i dati in modo sincrono (ad esempio, tra database). Ciò ti consente di utilizzare le zone di disponibilità in una configurazione attiva/attiva o attiva/standby.

Le zone di disponibilità sono indipendenti e pertanto la disponibilità del carico di lavoro aumenta quando il carico di lavoro è progettato per utilizzare più zone di disponibilità. Alcuni AWS servizi (incluso il piano dati delle EC2 istanze Amazon) vengono distribuiti come servizi strettamente zonali in cui hanno condiviso il destino con la zona di disponibilità in cui si trovano. EC2Le istanze Amazon nell'altra versione non AZs saranno tuttavia interessate e continueranno a funzionare. Allo stesso modo, se un errore in una zona di disponibilità causa l'errore di un database Amazon Aurora, un'istanza Aurora di lettura-replica in una zona di disponibilità non interessata può essere automaticamente promossa a primaria. I servizi regionali AWS , come Amazon DynamoDB, utilizzano internamente più zone di disponibilità in una configurazione attiva/attiva per raggiungere gli obiettivi di progettazione della disponibilità per quel servizio, senza che sia necessario configurare il posizionamento delle zone di disponibilità.

Diagramma che mostra un'architettura multi-livello implementata su tre zone di disponibilità. Nota: Amazon S3 e Amazon DynamoDB sono sempre ad AZ multiple automaticamente. ELBInoltre viene distribuito in tutte e tre le zone.

Figura 9: architettura multi-livello distribuita su tre zone di disponibilità. Nota: Amazon S3 e Amazon DynamoDB sono sempre ad AZ multiple automaticamente. ELBInoltre è distribuito in tutte e tre le zone.

Sebbene i piani di AWS controllo offrano in genere la possibilità di gestire le risorse all'interno dell'intera regione (più zone di disponibilità), alcuni piani di controllo (inclusi Amazon EC2 e AmazonEBS) hanno la capacità di filtrare i risultati in base a un'unica zona di disponibilità. Con questo approccio, la richiesta viene elaborata solo nella zona di disponibilità specificata, riducendo l'esposizione all'interruzione in altre zone di disponibilità. Questo AWS CLI esempio illustra come ottenere informazioni sulle EC2 istanze Amazon solo dalla zona di disponibilità us-east-2c:

AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c

AWS Zone locali

AWS Le Local Zone agiscono in modo simile alle Zone di disponibilità all'interno delle rispettive aree, Regione AWS in quanto possono essere selezionate come ubicazioni di collocamento per AWS risorse zonali come sottoreti e istanze. EC2 Ciò che le rende speciali è il fatto che non si trovano nelle aree associate Regione AWS, ma in prossimità di centri IT, industriali e popolati, dove oggi non esistono. Regione AWS Tuttavia, mantengono una connessione sicura e a larghezza di banda elevata tra i carichi di lavoro locali nella zona locale e quelli in esecuzione nella Regione AWS. È consigliabile utilizzare le zone locali AWS per implementare i carichi di lavoro più vicini agli utenti per requisiti a bassa latenza.

Amazon Global Edge Network

Amazon Global Edge Network è composto da posizioni edge in città di tutto il mondo. Amazon CloudFront utilizza questa rete per fornire contenuti agli utenti finali con una latenza inferiore. AWS Global Accelerator ti consente di creare endpoint di carico di lavoro in queste edge location per consentire l'onboarding sulla rete AWS globale vicino ai tuoi utenti. Amazon API Gateway consente API endpoint ottimizzati per l'edge utilizzando una CloudFront distribuzione per facilitare l'accesso dei clienti attraverso l'edge location più vicina.

Regioni AWS

Regioni AWS sono progettati per essere autonomi, pertanto, per utilizzare un approccio multiregionale, è necessario distribuire copie dedicate dei servizi in ciascuna regione.

Un approccio multiregionale è comune per le strategie di ripristino di emergenza volte al raggiungimento degli obiettivi di ripristino in caso di eventi isolati su larga scala. Consulta Pianificazione per il disaster recovery (DR) per ulteriori informazioni su queste strategie. Qui, tuttavia, ci concentriamo invece sulla disponibilità, che cerca di fornire un obiettivo medio di operatività nel tempo. Per gli obiettivi di alta disponibilità, un'architettura multi-regione sarà generalmente progettata per essere attiva/attiva, dove ogni copia del servizio (nelle rispettive regioni) è attiva (serve le richieste).

Raccomandazione

Gli obiettivi di disponibilità per la maggior parte dei carichi di lavoro possono essere soddisfatti utilizzando una strategia multi-AZ all'interno di una singola Regione AWS. Considera le architetture multi-regione solo quando i carichi di lavoro hanno requisiti di disponibilità estremi o altri obiettivi aziendali che richiedono un'architettura multi-regione.

AWS ti offre le funzionalità per gestire servizi in più regioni. Ad esempio, AWS fornisce la replica continua e asincrona dei dati utilizzando Amazon Simple Storage Service (Amazon S3) Replication, Amazon Read Replicas (inclusa Aurora Read Replicas) e RDS Amazon DynamoDB Global Tables. Con la replica continua, le versioni dei dati sono disponibili per un uso quasi immediato in ogni regione attiva.

In questo modo AWS CloudFormation, puoi definire la tua infrastruttura e distribuirla in modo uniforme su e indietro. Account AWS Regioni AWS Inoltre, AWS CloudFormation StackSets estende questa funzionalità consentendoti di creare, aggiornare o eliminare AWS CloudFormation pile su più account e regioni con un'unica operazione. Per le distribuzioni di EC2 istanze Amazon, viene utilizzata una (AMIAmazon Machine Image) per fornire informazioni come la configurazione hardware e il software installato. Puoi implementare una pipeline Amazon EC2 Image Builder che crea ciò di cui AMIs hai bisogno e copiarlo nelle tue regioni attive. Ciò garantisce che questi Golden AMIs abbiano tutto ciò di cui hai bisogno per distribuire e scalare il tuo carico di lavoro in ogni nuova regione.

Per indirizzare il traffico, sia Amazon Route 53 che AWS Global Accelerator consentono la definizione di policy che determinano quali utenti accedono a quale endpoint regionale attivo. Con Global Accelerator imposti un valore di traffico per controllare la percentuale di traffico diretta a ciascun endpoint dell'applicazione. Route 53 supporta questo approccio percentuale e anche molte altre policy disponibili, tra cui quelle basate sulla geoprossimità e sulla latenza. Global Accelerator sfrutta automaticamente l'ampia rete di server AWS perimetrali per integrare il traffico verso la dorsale della AWS rete il prima possibile, con conseguente riduzione delle latenze di richiesta.

Tutte queste capacità operano in modo da preservare l'autonomia di ogni regione. Esistono pochissime eccezioni a questo approccio, inclusi i nostri servizi che forniscono una distribuzione edge globale (come Amazon CloudFront e Amazon Route 53), insieme al piano di controllo per il servizio AWS Identity and Access Management (IAM). La maggior parte dei servizi opera interamente all'interno di una singola regione.

Data center on-premises

Per i carichi di lavoro eseguiti in un data center locale, progetta un'esperienza ibrida quando possibile. AWS Direct Connect fornisce una connessione di rete dedicata dalla tua sede per AWS consentirti di funzionare in entrambi.

Un'altra opzione è quella di eseguire AWS l'infrastruttura e i servizi in locale utilizzando AWS Outposts. AWS Outposts è un servizio completamente gestito che estende AWS l'infrastrutturaAPIs, AWS i servizi e gli strumenti al data center. La stessa infrastruttura hardware utilizzata in Cloud AWS è installata nel data center. AWS Outposts vengono quindi collegati al più vicino Regione AWS. È quindi possibile utilizzarli AWS Outposts per supportare carichi di lavoro con bassa latenza o requisiti di elaborazione locale dei dati.

Livello di rischio associato se questa best practice non fosse adottata: elevato

Guida all'implementazione

  • Utilizza più zone di disponibilità e. Regioni AWS Distribuisci i dati e le risorse del carico di lavoro su più zone di disponibilità o, se necessario, su diverse Regioni AWS. Questi luoghi possono essere diversi a seconda delle necessità.

  • Se il carico di lavoro deve essere implementato in più regioni, scegli una strategia multi-regione. La maggior parte delle esigenze di affidabilità può essere soddisfatta in un'unica soluzione Regione AWS utilizzando una strategia a più zone di disponibilità. Quando necessario, utilizza una strategia multi-regione per soddisfare le tue esigenze aziendali.

  • Valuta AWS Outposts il tuo carico di lavoro. Se il carico di lavoro richiede bassa latenza nel data center on-premises o applica i requisiti di elaborazione dei dati locali, Quindi esegui AWS l'infrastruttura e i servizi in locale utilizzando AWS Outposts

  • Determina se AWS Local Zones ti aiuta a fornire servizi ai tuoi utenti. Se hai requisiti di bassa latenza, verifica se AWS Local Zones si trova vicino ai tuoi utenti. Se sì, utilizzale per implementare carichi di lavoro più vicini a tali utenti.

Risorse

Documenti correlati:

Video correlati: