REL11-BP03 Automatizza la guarigione su tutti i livelli - AWS Well-Architected Framework
Guida all'implementazione Risorse

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

REL11-BP03 Automatizza la guarigione su tutti i livelli

Al rilevamento di un guasto, utilizza funzionalità automatizzate per eseguire azioni da correggere. I guasti possono essere riparati automaticamente tramite meccanismi di servizio interni oppure riavviando o rimuovendo le risorse tramite azioni correttive.

Per applicazioni gestite dal cliente e per il ripristino tra regioni, è possibile attingere a modelli di ripristino e processi di riparazione automatizzati dalle best practice esistenti.

La possibilità di riavviare o rimuovere una risorsa è uno strumento importante per risolvere i guasti. Una best practice consiste nel rendere i servizi stateless, ove possibile. In questo modo si evita la perdita di dati o di disponibilità durante il riavvio della risorsa. Nel cloud è possibile, e in genere si dovrebbe, sostituire l'intera risorsa (ad esempio, un'istanza di calcolo o una funzione serverless) come parte del riavvio. Il riavvio stesso è un modo semplice e affidabile per eseguire il ripristino in caso di guasto. Molti tipi diversi di guasto si verificano nei carichi di lavoro. Possono verificarsi guasti a livello di hardware, software, comunicazione e operazioni.

Il riavvio o i nuovi tentativi come pratiche risolutive si applicano anche alle richieste di rete. Adotta lo stesso approccio di ripristino sia a un timeout di rete sia a un guasto di dipendenza in cui la dipendenza restituisce un guasto. Entrambi gli eventi hanno un effetto simile sul sistema, quindi piuttosto che tentare di trasformare entrambi gli eventi in un caso speciale, adotta una strategia analoga di nuovi tentativi limitati con un un jitter e un backoff esponenziali. La capacità di riavvio è un meccanismo di ripristino presente nelle architetture di cluster ROC (Recovery-oriented computing) e ad alta disponibilità.

Risultato desiderato: vengono eseguite azioni automatiche di risoluzione a seguito del rilevamento di un errore.

Anti-pattern comuni:

  • Provisioning di risorse senza dimensionamento automatico.

  • Implementazione individuale di applicazioni in istanze/container.

  • Implementazione di applicazioni che non possono essere distribuite in più posizioni senza utilizzare il ripristino automatico.

  • Riparazione manuale delle applicazioni che il dimensionamento e il ripristino automatici non sono stati in grado di riparare.

  • Nessuna automazione dei database di failover.

  • Mancanza di metodi automatizzati per reinstradare il traffico verso nuovi endpoint.

  • Nessuna replica dell'archiviazione.

Vantaggi dell'adozione di questa best practice: la riparazione automatica può ridurre il tempo medio di ripristino e migliorare la disponibilità.

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

Guida all'implementazione

I progetti per Amazon EKS o altri servizi Kubernetes devono includere set di repliche o stateful set minimi e massimi e il dimensionamento minimo di cluster e gruppi di nodi. Questi meccanismi forniscono una quantità minima di risorse di elaborazione continuamente disponibili mentre riparano automaticamente eventuali guasti utilizzando il piano di controllo (control-plane) Kubernetes.

I modelli di progettazione a cui si accede tramite un bilanciatore del carico che utilizza cluster di calcolo dovrebbero sfruttare i gruppi Auto Scaling. Elastic Load Balancing (ELB) distribuisce automaticamente il traffico delle applicazioni in entrata su più destinazioni e appliance virtuali in una o più zone di disponibilità (). AZs

I progetti basati su cluster computing che non utilizzano il bilanciamento del carico devono avere dimensioni progettate per la perdita di almeno un nodo. Ciò consentirà al servizio di rimanere in esecuzione con una capacità potenzialmente ridotta durante il ripristino di un nuovo nodo. Servizi di esempio sono Mongo, DynamoDB Accelerator, Amazon Redshift, Amazon, Cassandra, EMR MSK KafkaEC2, -, Couchbase e Amazon Service. ELK OpenSearch Molti di questi servizi possono essere progettati con funzionalità di riparazione automatica aggiuntive. Alcune tecnologie di cluster devono generare un avviso in caso di perdita di un nodo attivando un flusso di lavoro automatico o manuale per creare un nuovo nodo. Questo flusso di lavoro può essere automatizzato per risolvere rapidamente i problemi. AWS Systems Manager

Amazon EventBridge può essere usato per monitorare e filtrare eventi come CloudWatch allarmi o cambiamenti di stato in altri AWS servizi. In base alle informazioni sugli eventi, può quindi richiamare AWS Lambda Systems Manager Automation o altri obiettivi per eseguire una logica di correzione personalizzata sul carico di lavoro. Amazon EC2 Auto Scaling può essere configurato per verificare lo stato delle EC2 istanze. Se l'istanza si trova in uno stato diverso da quello in esecuzione o se lo stato del sistema è compromesso, Amazon EC2 Auto Scaling considera l'istanza non integra e avvia un'istanza sostitutiva. Per le sostituzioni su larga scala (ad esempio la perdita di un'intera zona di disponibilità), è preferibile adottare la stabilità statica per ottenere un'elevata disponibilità.

Passaggi dell'implementazione

  • Utilizza i gruppi Auto Scaling per implementare livelli in un carico di lavoro. Auto Scaling è in grado di eseguire il risanamento automatico sulle applicazioni stateless e aggiungere o rimuovere capacità.

  • Per le istanze di calcolo menzionate in precedenza, utilizza il bilanciamento del carico e scegli il tipo di bilanciatore del carico adeguato.

  • Prendi in considerazione la possibilità di guarire per AmazonRDS. Utilizzando le istanze di standby, puoi configurare il failover automatico sulle stesse. Per Amazon Read RDS Replica, è necessario un flusso di lavoro automatizzato per rendere primaria una replica di lettura.

  • Implementa il ripristino automatico su EC2 istanze in cui sono distribuite applicazioni che non possono essere distribuite in più posizioni e può tollerare il riavvio in caso di guasto. Il ripristino automatico può essere utilizzato per sostituire l'hardware guasto e riavviare l'istanza quando l'applicazione non è in grado di essere distribuita in più posizioni. I metadati dell'istanza e gli indirizzi IP associati vengono conservati, nonché EBSi volumi e i punti di montaggio su Amazon Elastic File System o File Systems for Lustre e Windows. Utilizzando AWS OpsWorks, puoi configurare la riparazione automatica delle EC2 istanze a livello di livello.

  • Implementa il ripristino automatico utilizzando AWS Step Functions e AWS Lambda quando non è possibile utilizzare il dimensionamento automatico o il ripristino automatico oppure quando il ripristino automatico non riesce. Quando non è possibile utilizzare il ridimensionamento automatico e non è possibile utilizzare il ripristino automatico oppure il ripristino automatico fallisce, è possibile automatizzare la riparazione utilizzando e. AWS Step Functions AWS Lambda

  • Amazon EventBridge può essere usato per monitorare e filtrare eventi come CloudWatchallarmi o cambiamenti di stato in altri AWS servizi. In base alle informazioni sugli eventi, può quindi richiamare AWS Lambda (o altre destinazioni) per eseguire una logica di riparazione personalizzata sul tuo carico di lavoro.

Risorse

Best practice correlate:

Documenti correlati:

Video correlati:

Esempi correlati:

Strumenti correlati: