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-BP04 Affidati al piano dati e non al piano di controllo durante il ripristino
I piani di controllo forniscono le risorse amministrative APIs utilizzate per creare, leggere e descrivere, aggiornare, eliminare ed elencare (CRUDL) le risorse, mentre i piani dati gestiscono il traffico di day-to-day servizio. Durante l'implementazione di risposte di ripristino o mitigazione a eventi che possono influire sulla resilienza, concentrati sull'utilizzo di un numero minimo di operazioni del piano di controllo (control-plane) per ripristinare, ridimensionare, ristabilire, riparare il servizio o eseguirne il failover. Le operazioni del piano dati dovrebbero avere la precedenza su qualsiasi attività durante questi eventi che causano deterioramento.
Ad esempio, le seguenti sono tutte azioni del piano di controllo (control-plane): avvio di una nuova istanza di calcolo, creazione di storage a blocchi e descrizione dei servizi di coda. Quando avvii istanze di calcolo, il piano di controllo (control-plane) deve eseguire diverse attività, come trovare un host fisico con capacità, allocare interfacce di rete, preparare volumi di storage a blocchi locali, generare credenziali e aggiungere regole di sicurezza. I piani di controllo (control-plane) tendono ad avere un'orchestrazione complicata.
Risultato desiderato: quando lo stato di risorsa viene compromesso, il sistema è in grado di ripristinarsi automaticamente o manualmente spostando il traffico da risorse danneggiate a risorse integre.
Anti-pattern comuni:
-
Dipendenza dalla modifica DNS dei record per reindirizzare il traffico.
-
Dipendenza dalle operazioni di dimensionamento del piano di controllo (control-plane) per sostituire i componenti danneggiati a causa di un provisioning delle risorse insufficiente.
-
Affidarsi ad azioni estese, multiservizio e API multicontrollo sul piano per porre rimedio a qualsiasi categoria di deterioramento.
Vantaggi dell'adozione di questa best practice una maggiore percentuale di successo in termini di riparazione automatica può ridurre il tempo medio di ripristino e migliorare la disponibilità del carico di lavoro.
Livello di rischio associato se questa best practice non fosse adottata: medio. Per determinati tipi di degrado del servizio, i piani di controllo (control-plane) sono interessati. La dipendenza dall'uso estensivo del piano di controllo per la riparazione può aumentare il tempo di ripristino () e il tempo medio di ripristino (RTO). MTTR
Guida all'implementazione
Per limitare le azioni del piano dati, esegui una valutazione del servizio determinare le azioni necessarie per ripristinarlo.
Sfrutta Amazon Application Recovery Controller per spostare il DNS traffico. Queste funzionalità monitorano continuamente la capacità dell'applicazione di ripristinarsi in caso di guasti e consentono di controllare il ripristino delle applicazioni su più Regioni AWS zone di disponibilità e in locale.
Le policy di instradamento di Route 53 utilizzano il piano di controllo (control-plane), quindi non fare affidamento su di esso per il ripristino. I piani dati Route 53 rispondono alle DNS domande ed eseguono e valutano i controlli di integrità. Sono distribuiti a livello globale e progettati per un accordo sul livello di servizio con disponibilità del 100% (SLA).
La gestione APIs e le console di Route 53 in cui è possibile creare, aggiornare ed eliminare le risorse Route 53 funzionano su piani di controllo progettati per dare priorità alla forte coerenza e alla durabilità necessarie durante la gestione. DNS A tal fine, i piani di controllo (control-plane) sono situati in un'unica regione: Stati Uniti orientali (Virginia settentrionale). Sebbene entrambi i sistemi siano progettati per essere molto affidabili, i piani di controllo non sono inclusi nel. SLA Possono verificarsi eventi rari in cui la progettazione resiliente del piano dati consente di mantenere la disponibilità mentre i piani di controllo (control-plane) non lo fanno. Per i meccanismi di ripristino di emergenza e failover, utilizzare le funzioni del piano dati per garantire la migliore affidabilità possibile.
Progetta la tua infrastruttura di elaborazione in modo che sia staticamente stabile per evitare di utilizzare il piano di controllo durante un incidente. Ad esempio, se utilizzi EC2 istanze Amazon, evita di effettuare il provisioning di nuove istanze manualmente o di chiedere agli Auto Scaling Groups di aggiungere istanze in risposta. Per ottenere i massimi livelli di resilienza, è necessario fornire una capacità sufficiente nel cluster utilizzato per il failover. Se questa soglia di capacità deve essere limitata, imposta dei limiti sull'intero end-to-end sistema per limitare in modo sicuro il traffico totale che raggiunge il set limitato di risorse.
Per servizi come Amazon DynamoDB, API Amazon Gateway, load balancer e serverless, l'utilizzo di AWS Lambda tali servizi sfrutta il piano dati. Tuttavia, la creazione di nuove funzioni, load balancer, API gateway o tabelle DynamoDB è un'azione del piano di controllo e deve essere completata prima del degrado come preparazione a un evento e alla ripetizione delle azioni di failover. Per AmazonRDS, le azioni del piano dati consentono l'accesso ai dati.
Per ulteriori informazioni sui piani dati, sui piani di controllo e su come AWS crea servizi per soddisfare gli obiettivi di alta disponibilità, consulta Stabilità statica tramite zone di disponibilità
Capire quali operazioni sono sul piano dati e quali sul piano di controllo (control-plane).
Passaggi dell'implementazione
Per ogni carico di lavoro che deve essere ripristinato dopo un evento di deterioramento, valuta il runbook di failover, il design ad alta disponibilità, il progetto di riparazione automatica o il piano di ripristino delle risorse HA. Identifica ogni azione che potrebbe essere considerata un'azione del piano di controllo (control-plane).
Prendi in considerazione la possibilità di modificare l'azione di controllo in un'azione del piano dati:
-
Auto Scaling (piano di controllo) su risorse EC2 Amazon prescalate (piano dati)
-
Scalabilità delle EC2 istanze Amazon (piano di controllo) alla AWS Lambda scalabilità (piano dati)
-
Valuta qualsiasi progetto utilizzando Kubernetes e considerando la natura delle azioni del piano di controllo (control-plane). L'aggiunta di pod è un'azione del piano dati in Kubernetes. Le azioni devono limitarsi all'aggiunta di pod e non all'aggiunta di nodi. L'utilizzo di nodi con provisioning eccessivo
è il metodo preferibile per limitare le azioni del piano di controllo (control-plane).
Prendi in considerazione approcci alternativi che consentano alle azioni del piano dati di incidere sulla stessa correzione.
-
Route 53 Record change (piano di controllo) o Amazon Application Recovery Controller (piano dati)
-
Controlli dell'integrità di Route 53 per aggiornamenti più automatizzati
Se il servizio è mission critical, prendi in considerazione alcuni servizi in una regione secondaria per consentire più azioni del piano di controllo (control-plane) e del piano dati in una regione non interessata dal problema.
-
Amazon EC2 Auto Scaling o Amazon EKS in una regione principale rispetto ad Amazon Auto EC2 Scaling o EKS Amazon in una regione secondaria e instradamento del traffico verso una regione secondaria (azione del piano di controllo)
-
Crea una replica di lettura nella regione secondaria o tenta la stessa azione nella regione principale (azione del piano di controllo (control-plane))
Risorse
Best practice correlate:
Documenti correlati:
Video correlati:
Esempi correlati:
Strumenti correlati: