REL11-BP04 Fare affidamento al piano dati invece che al piano di controllo durante il ripristino

I piani di controllo forniscono le API amministrative utilizzate per creare, leggere e descrivere, aggiornare, eliminare ed elencare (CRUDL) risorse, mentre i piani di dati gestiscono il traffico quotidiano del 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 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: 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 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 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:

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 deterioramento del servizio, vengono compromessi i piani di controllo. Le dipendenze dall'uso intenso del piano di controllo per la riparazione possono aumentare il tempo di ripristino (RTO) e il tempo medio di ripristino (MTTR).

Guida all'implementazione

Per limitare le azioni del piano dati, esegui una valutazione servizio per servizio per determinare le azioni necessarie per ripristinarlo.

Sfrutta Amazon Application Recovery Controller (ARC) per spostare il traffico DNS. Queste funzionalità monitorano continuamente la capacità dell'applicazione di ristabilirsi dai guasti e consentono di controllarne il ripristino su più Regioni AWS, zone di disponibilità e on-premise.

Le policy di instradamento di Route 53 utilizzano il piano di controllo, quindi non fare affidamento su di esso per il ripristino. I piani dati di Route 53 rispondono alle query DNS ed eseguono e valutano i controlli di integrità. Sono distribuiti a livello globale e progettati per un accordo sul livello di servizio (SLA) con disponibilità al 100%.

Le API e la console di gestione di Route 53, dove si creano, aggiornano ed eliminano le risorse di Route 53, funzionano su piani di controllo progettati per privilegiare la forte coerenza e la durata necessarie per la gestione del DNS. A tal fine, i piani di controllo sono situati in un'unica regione: Stati Uniti orientali (Virginia settentrionale). Sebbene entrambi i sistemi siano costruiti per essere molto affidabili, i piani di controllo non sono inclusi nello SLA. Possono verificarsi eventi rari in cui la progettazione resiliente del piano dati consente di mantenere la disponibilità mentre i piani di controllo non lo fanno. Per i meccanismi di ripristino di emergenza e failover, utilizzare le funzioni del piano dati per garantire la migliore affidabilità possibile.

Per Amazon EC2, utilizzare progetti di stabilità statica per limitare le azioni del piano di controllo. Le azioni del piano di controllo includono l'aumento delle risorse, in maniera individuale o utilizzando gruppi Auto Scaling (ASG). Per ottenere i massimi livelli di resilienza, è necessario fornire una capacità sufficiente nel cluster utilizzato per il failover. Se è necessario limitare questa soglia di capacità, imposta acceleratori sull'intero sistema end-to-end per limitare in modo sicuro il traffico totale che raggiunge il set limitato di risorse.

L'utilizzo di servizi come Amazon DynamoDB, Amazon API Gateway, sistemi di bilanciamento del carico e AWS Lambda serverless avviene sfruttando il piano dati. Tuttavia, la creazione di nuove funzioni, sistemi di bilanciamento del carico, gateway API o tabelle DynamoDB è un'azione del piano di controllo e deve essere completata prima del deterioramento come preparazione a un evento e test delle azioni di failover. Per Amazon RDS, le azioni del piano dati consentono l'accesso ai dati.

Per ulteriori informazioni sui piani dati, sui piani di controllo e su come AWS costruisce i servizi per soddisfare gli obiettivi di alta disponibilità, consulta Stabilità statica utilizzando le zone di disponibilità.

Capire quali operazioni sono sul piano dati e quali sul piano di controllo.

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.

Prendi in considerazione la possibilità di modificare l'azione di controllo in un'azione del piano dati:

Prendi in considerazione approcci alternativi che consentano alle azioni del piano dati di incidere sulla stessa correzione.

Se il servizio è mission critical, prendi in considerazione alcuni servizi in una regione secondaria per consentire più azioni del piano di controllo e del piano dati in una regione non interessata dal problema.

Risorse

Best practice correlate:

Documenti correlati:

Video correlati:

Esempi correlati:

Strumenti correlati: