Evacuazione controllata dal piano di controllo

Il primo modello utilizza le operazioni sul piano dati per impedire l'esecuzione di operazioni in una zona di disponibilità interessata per mitigare l'impatto di un evento. Tuttavia, è possibile che tu stia utilizzando un'architettura che non utilizza sistemi di bilanciamento del carico o in cui la configurazione di un controllo dello stato per host non è possibile. Oppure, potresti voler impedire che nuove capacità vengano distribuite nella zona di disponibilità interessata tramite Auto Scaling o la normale pianificazione del lavoro.

Per risolvere entrambe le situazioni, sono necessarie le azioni del piano di controllo per aggiornare la configurazione della risorsa. Il modello funzionerà per qualsiasi servizio la cui configurazione di rete può essere aggiornata, ad esempio EC2 Auto Scaling, Amazon ECS, Lambda e altri. Richiede la scrittura di codice per ogni servizio, ma la logica aziendale segue uno schema standard. Il codice deve essere eseguito localmente da un operatore che risponde all'evento per ridurre al minimo le dipendenze richieste. Il flusso di base della logica dello script è illustrato nella figura seguente.

Aggiornamento del piano di controllo per evacuare una zona di disponibilità

1. Lo script elenca tutte le risorse del tipo specificato, come il gruppo Auto Scaling, il servizio ECS o la funzione Lambda, e recupera le relative sottoreti dalle informazioni sulle risorse. Le risorse supportate dipendono da ciò che lo script è stato configurato per supportare.

2. Determina quali sottoreti devono essere rimosse confrontando il nome della zona di disponibilità di ciascuna sottorete con l'ID della zona di disponibilità mappato fornito come parametro di input.

3. La configurazione di rete della risorsa viene aggiornata per rimuovere le sottoreti identificate.

4. I dettagli dell'aggiornamento vengono registrati in una tabella DynamoDB. L'ID della zona di disponibilità è memorizzato comechiave di partizionee l'ARN o il nome della risorsa viene memorizzato comechiave di ordinamento. Le sottoreti rimosse vengono archiviate come un array di stringhe. Infine, il tipo di risorsa viene anche memorizzato e utilizzato come chiave hash per unIndice secondario globale(GSI).

Poiché la fase quattro registra gli aggiornamenti effettuati, questo approccio si presta anche a essere facilmente reversibile quando si è pronti per il ripristino, come illustrato nella figura seguente.

Aggiornamento del piano di controllo per il ripristino dopo l'evacuazione della zona di disponibilità

Fasi di ripristino:

1. Interroga il GSI per rimuovere le sottoreti per ogni risorsa del tipo specificato nella zona di disponibilità specificata (o tutte le zone di disponibilità se non ne è specificata una).

2. Descrivi ogni risorsa trovata nella query DynamoDB per ottenere la sua configurazione di rete corrente.

3. Combina le sottoreti della configurazione di rete corrente con quelle recuperate dalla query DynamoDB.

4. Aggiorna la configurazione di rete della risorsa con il nuovo set di sottoreti.

5. Rimuove il record dalla tabella DynamoDB dopo il completamento dell'aggiornamento.

Questo modello generalizzato impedisce sia il routing del lavoro verso la zona di disponibilità interessata sia l'installazione di nuove capacità in tale zona. Di seguito sono riportati alcuni esempi di come questa operazione viene eseguita per diversi servizi.

• Lambda— Aggiorna la funzioneConfigurazione VPCper rimuovere le sottoreti nella zona di disponibilità specificata.

• Gruppo Auto Scaling—Rimuovi le sottoreti dalla configurazione ASGche sostituirà tale capacità nelle restanti zone di disponibilità.

• Amazon ECS—Aggiorna la configurazione VPC del servizio ECSper rimuovere le sottoreti.

• Amazon EKS— Applicacontaminazioniai nodi della zona di disponibilità interessata per eliminare i pod esistenti e impedire che vengano programmati altri pod lì.

Ogni servizio reagirà in modo diverso all'aggiornamento della configurazione. Ad esempio, Amazon ECS seguiràconfigurazione di distribuzione del servizio dopo un aggiornamentoe avvia una distribuzione continua o una distribuzione blu/verde di nuove attività.

Questi aggiornamenti potrebbero spostare il lavoro nelle zone di disponibilità intatte troppo rapidamente per alcuni carichi di lavoro. Pur essendo configurato per essere staticamente stabile al guasto (con una capacità sufficiente preconfigurata nelle zone di disponibilità rimanenti per gestire il lavoro della zona di disponibilità interessata), potresti anche voler eliminare gradualmente la capacità dalla zona di disponibilità interessata.

Se prevedi di aggiornare la configurazione di rete del tuo gruppo Auto Scaling, questo è un gruppo target per un sistema di bilanciamento del carico con bilanciamento del carico tra zonedisabili, segui questa guida.

Auto Scaling reagisce a questa modifica utilizzando ilLogica di ribilanciamento della zona di disponibilità. Avvierà le istanze nelle altre zone di disponibilità per soddisfare la capacità desiderata e terminerà le istanze nella zona di disponibilità rimossa. Tuttavia, il load balancer continuerà a suddividere il traffico in modo uniforme in ogni zona di disponibilità, inclusa quella rimossa dall'ASG, mentre le istanze vengono terminate. Ciò potrebbe comportare un esaurimento della capacità residua in quella zona di disponibilità fino a quando tutte le istanze non saranno terminate correttamente. Questo è lo stesso problema descritto inIndipendenza dalla zona di disponibilitàrelativo allo squilibrio della zona di disponibilità quando il bilanciamento del carico tra zone è disabilitato. Per evitare che ciò accada, puoi:

• Esegui sempre prima l'evacuazione della zona di disponibilità, in modo che il traffico venga suddiviso solo tra le zone di disponibilità rimanenti

• Specifica unnumero minimo di obiettivi sani con failover DNSper corrispondere al numero obiettivo minimo richiesto per quella zona di disponibilità.

Ciò contribuirà a garantire che il traffico non venga inviato alla zona di disponibilità che hai rimosso dopo l'inizio della chiusura delle istanze.