Le migliori pratiche per la configurazione dell'autoshift zonale

Tieni presente le seguenti best practice e considerazioni quando abiliti l'autoshift zonale in Amazon Route 53 Application Recovery Controller.

L'autoshift zonale include due tipi di turni di traffico: turni automatici e turni zonali Practice Run.

• Lo spostamento automatico AWS consente di ridurre i tempi di ripristino allontanando il traffico delle risorse applicative da una zona di disponibilità durante gli eventi, per conto dell'utente.

• Con le prove, Route 53 ARC avvia un cambio di zona per tuo conto. Lo spostamento zonale sposta il traffico da una zona di disponibilità a una risorsa e viceversa, con cadenza settimanale. Le sessioni pratiche aiutano ad accertarsi di aver aumentato la capacità necessaria per le zone di disponibilità in una regione affinché l'applicazione possa tollerare la perdita di una zona di disponibilità.

Esistono diverse best practice e considerazioni da tenere a mente per quanto riguarda gli spostamenti automatici e le esecuzioni pratiche. Consulta i seguenti argomenti prima di abilitare lo spostamento automatico zonale o configurare le sessioni pratiche per una risorsa.

Argomenti

• Limita il tempo in cui i client rimangono connessi ai tuoi endpoint

• Prescalate la vostra capacità di risorse e testate il traffico mutevole

• Sii consapevole dei tipi e delle restrizioni delle risorse

• Specificate gli allarmi per le prove

• Valuta i risultati delle prove

Limita il tempo in cui i clienti rimangono connessi ai tuoi endpoint

Quando Amazon Route 53 Application Recovery Controller allontana il traffico da un problema, ad esempio utilizzando lo spostamento zonale o lo spostamento automatico di zona, il meccanismo utilizzato da Route 53 ARC per spostare il traffico dell'applicazione è un aggiornamento DNS. Un aggiornamento DNS fa sì che tutte le nuove connessioni vengano indirizzate lontano dalla posizione compromessa. Tuttavia, i client con connessioni aperte preesistenti potrebbero continuare a effettuare richieste nei confronti della posizione compromessa fino alla riconnessione dei client. Per garantire un ripristino rapido, ti consigliamo di limitare il periodo di tempo in cui i client rimangono connessi ai tuoi endpoint.

Se si utilizza un Application Load Balancer, è possibile utilizzare l'keepaliveopzione per configurare la durata delle connessioni. Ti consigliamo di abbassare il keepalive valore per adattarlo all'obiettivo del tempo di ripristino per l'applicazione, ad esempio 300 secondi. Quando scegli un keepalive orario, considera che questo valore rappresenta un compromesso tra la riconnessione più frequente in generale, il che può influire sulla latenza, e lo spostamento più rapido di tutti i client da una zona o regione compromessa.

Per ulteriori informazioni sull'impostazione dell'keepaliveopzione per Application Load Balancer, vedete la durata del client HTTP keepalive nella Application Load Balancer User Guide.

Prescalate la vostra capacità di risorse e testate il traffico in continua evoluzione

Quando si AWS sposta il traffico da una zona di disponibilità a favore di uno spostamento di zona o di uno spostamento automatico, è importante che le zone di disponibilità rimanenti siano in grado di soddisfare le maggiori percentuali di richiesta della risorsa. Questo modello è noto come stabilità statica. Per ulteriori informazioni, consulta il white paper sulla stabilità statica con le zone di disponibilità nella libreria di Amazon Builder.

Ad esempio, se l'applicazione richiede 30 istanze per servire i propri clienti, è necessario effettuare il provisioning di 15 istanze in tre zone di disponibilità, per un totale di 45 istanze. In questo modo, quando si AWS sposta il traffico da una zona di disponibilità, con uno spostamento automatico o durante un'esecuzione pratica, è comunque AWS possibile servire i client dell'applicazione con il totale rimanente di 30 istanze, su due zone di disponibilità.

La funzionalità di spostamento automatico zonale di Route 53 ARC consente di ripristinare rapidamente AWS gli eventi in una zona di disponibilità quando si dispone di un'applicazione con risorse predimensionate per funzionare normalmente con la perdita di una zona di disponibilità. Prima di abilitare lo spostamento automatico zonale per una risorsa, scalate la capacità delle risorse in tutte le zone di disponibilità configurate in un'unica. Regione AWS Quindi, avvia i turni zonali per la risorsa, per verificare che l'applicazione funzioni ancora normalmente quando il traffico viene spostato da una zona di disponibilità.

Dopo aver eseguito il test con i turni zonali, abilita lo spostamento automatico zonale e configurato le esecuzioni pratiche per le risorse dell'applicazione. Le esercitazioni regolari con zonal autoshift vi aiutano ad assicurarvi, su base continuativa, che la vostra capacità sia ancora scalata in modo appropriato. Con una capacità sufficiente in tutte le zone di disponibilità, l'applicazione può continuare a servire i clienti, senza interruzioni, durante un trasferimento automatico.

Per ulteriori informazioni sull'avvio di uno spostamento di zona per una risorsa, vedere. Spostamento di zona in Amazon Route 53 Application Recovery Controller

Sii consapevole dei tipi e delle restrizioni delle risorse

Lo spostamento automatico zonale supporta lo spostamento del traffico da una zona di disponibilità per tutte le risorse supportate dallo spostamento zonale. In generale, sono supportati Network Load Balancer e Application Load Balancer con bilanciamento del carico tra zone disattivato. In alcuni scenari di risorse specifici, lo spostamento automatico zonale non sposta il traffico da una zona di disponibilità a favore di uno spostamento automatico.

Ad esempio, se i gruppi target del sistema di bilanciamento del carico nelle zone di disponibilità non dispongono di istanze o se tutte le istanze non sono integre, il sistema di bilanciamento del carico si trova in uno stato di fail-open. Se AWS avvia uno spostamento automatico per un sistema di bilanciamento del carico in questo scenario, lo spostamento automatico non modifica le zone di disponibilità utilizzate dal sistema di bilanciamento del carico perché il sistema di bilanciamento del carico è già in uno stato di fail-open. Questo è il comportamento previsto. Lo spostamento automatico non può causare il malfunzionamento di una zona di disponibilità e spostare il traffico verso le altre zone di disponibilità se tutte le zone di disponibilità non sono aperte (non integre). Regione AWS

Un secondo scenario è se AWS avvia uno spostamento automatico per un Application Load Balancer che è un endpoint per un acceleratore. AWS Global Accelerator Come per lo spostamento di zona, lo spostamento automatico non è supportato per gli Application Load Balancer che sono endpoint degli acceleratori in Global Accelerator.

Per visualizzare i dettagli sulle risorse supportate, inclusi tutti i requisiti e le eccezioni di cui essere a conoscenza, consulta. Risorse supportate per lo spostamento zonale e lo spostamento automatico di zona

Specificare gli allarmi per le sessioni di pratica

È necessario configurare almeno un allarme, quello relativo ai risultati, per le esercitazioni con spostamento automatico zonale. Facoltativamente, puoi anche configurare un secondo allarme, l'allarme di blocco.

Quando consideri gli CloudWatch allarmi che configuri per le sessioni di pratica per la tua risorsa, tieni presente quanto segue:

• Per quanto riguarda l'allarme relativo ai risultati, che è obbligatorio, ti consigliamo di configurarlo in modo che entri in uno ALARM stato in cui le metriche relative alla risorsa o all'applicazione indicano che lo spostamento del traffico dalla zona di disponibilità influisce negativamente sulle prestazioni. CloudWatch Ad esempio, è possibile determinare una soglia per i tassi di richiesta per la risorsa e quindi configurare un allarme in modo che entri in uno ALARM stato in cui la soglia viene superata. L'utente è responsabile della configurazione di un allarme appropriato che provochi AWS la fine dell'esercitazione e restituisca un FAILED risultato.

• Ti consigliamo di seguire il AWS Well Architected Framework, che ti consiglia di implementare gli indicatori chiave di prestazione (KPI) come allarmi. CloudWatch In tal caso, è possibile utilizzare questi allarmi per creare un allarme composito da utilizzare come trigger di sicurezza, per impedire l'avvio di sessioni di prova che potrebbero causare il mancato rispetto di un KPI nell'applicazione. Quando l'allarme non è più attivo, Route 53 ARC avvia le esercitazioni la prossima volta che viene pianificata un'esecuzione pratica per la risorsa. ALARM

• Per quanto riguarda l'allarme di blocco dell'esercitazione, se scegli di configurarlo, puoi scegliere di tenere traccia di una metrica specifica che usi per indicare che non desideri che venga avviata un'esercitazione.

• Per fare pratica, devi specificare l'Amazon Resource Name (ARN) per ogni allarme, che devi prima configurare in Amazon. CloudWatch Gli CloudWatch allarmi che specifichi possono essere allarmi compositi, per consentirti di includere diverse metriche e controlli per l'applicazione e la risorsa in grado di attivare lo stato dell'allarme. ALARM Per ulteriori informazioni, consulta Combinare gli allarmi nella Amazon CloudWatch User Guide.

• Assicurati che gli CloudWatch allarmi che specifichi per le esercitazioni si trovino nella stessa regione della risorsa per cui stai configurando un'esercitazione.

Valuta i risultati delle esercitazioni

Route 53 ARC riporta un risultato per ogni sessione pratica. Dopo un'esercitazione, valuta il risultato e determina se è necessario agire. Ad esempio, potrebbe essere necessario scalare la capacità o modificare la configurazione per un allarme.

Di seguito sono riportati i possibili risultati delle esercitazioni:

• RIUSCITA: L'allarme relativo ai risultati non è ALARM stato attivato durante l'esercitazione e l'esercitazione ha completato l'intero periodo di prova di 30 minuti.

• FALLITO: l'allarme di risultato è entrato in uno ALARM stato durante l'esecuzione dell'esercitazione.

• INTERROTTA: L'esercitazione si è conclusa per un motivo diverso dall'allarme di esito che entrava in uno ALARM stato. Un'esercitazione può essere interrotta per diversi motivi, tra cui i seguenti:

  • L'esercitazione è stata interrotta perché è stato AWS avviato un cambio automatico nella regione Regione AWS o si è verificata una condizione di allarme nella regione.

  • L'esecuzione pratica è stata terminata perché la configurazione dell'esecuzione pratica è stata eliminata per la risorsa.

  • L'esecuzione dell'esercitazione è stata interrotta perché è stato avviato uno spostamento di zona avviato dal cliente per la risorsa nella zona di disponibilità da cui il trasferimento zonale dell'esecuzione dell'esercitazione stava allontanando il traffico.

  • L'esecuzione dell'esercitazione è stata interrotta perché non è più possibile accedere all' CloudWatch allarme specificato per la configurazione dell'esercitazione.

  • L'esercitazione è stata terminata perché l'allarme di blocco specificato per l'esercitazione è entrato in uno ALARM stato.

  • L'esercitazione è stata interrotta per un motivo sconosciuto.

• IN SOSPESO: L'esercitazione è attiva (in corso). Non ci sono ancora risultati da restituire.