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à.
Le migliori pratiche per i cambiamenti zonali in ARC
Consigliamo le seguenti best practice per l'utilizzo dei turni zonali per il ripristino Multi-AZ in. ARC I turni zonali in genere rimuovono capacità da un'applicazione live, quindi è importante fare attenzione quando li si utilizza in produzione.
Argomenti
- Pianificazione e pre-scalabilità della capacità
Assicurati di aver pianificato e predimensionato o di poter scalare automaticamente una capacità sufficiente per far fronte al carico aggiuntivo imposto alle zone di disponibilità quando inizi un turno di zona. In un'architettura orientata al ripristino, in genere si consiglia di predimensionare la capacità di elaborazione in modo da includere un margine di crescita sufficiente per soddisfare i picchi di traffico quando una delle tre repliche (in genere) è offline.
Quando si avvia uno spostamento di zona per una singola risorsa di bilanciamento del carico, ad esempio, la capacità di una zona di disponibilità viene temporaneamente rimossa dal sistema di bilanciamento del carico. A seconda dei turni zonali avviati e della configurazione dei sistemi di bilanciamento del carico, devi assicurarti di aver pianificato attentamente la gestione dell'aumento del carico nelle restanti zone di disponibilità.
- Limita il tempo in cui i client rimangono connessi ai tuoi endpoint
-
Quando Amazon Application Recovery Controller (ARC) allontana il traffico da un problema, ad esempio utilizzando lo spostamento zonale o lo spostamento automatico di zona, il meccanismo ARC utilizzato per spostare il traffico dell'applicazione è un aggiornamento. DNS Un DNS aggiornamento fa sì che tutte le nuove connessioni vengano allontanate dalla posizione compromessa.
Tuttavia, i client con connessioni aperte preesistenti potrebbero continuare a fare richieste verso la 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'
keepalive
opzione per configurare la durata delle connessioni. Per ulteriori informazioni, consulta la durata HTTP del client keepalive nella Guida per l'utente di Application Load Balancer.Per impostazione predefinita, Application Load Balancer impostano il valore di durata del HTTP client keepalive su 3600 secondi o 1 ora. Ti consigliamo di abbassare il valore in modo che sia in linea con l'obiettivo del tempo di ripristino per l'applicazione, ad esempio 300 secondi. Quando scegli la durata di keepalive di un HTTP client, 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.
- Prova in anticipo i turni zonali iniziali
Prova regolarmente a spostare il traffico lontano dalle zone di disponibilità per la tua applicazione avviando i turni zonali. Pianifica ed esegui turni zonali iniziali, preferibilmente in ambienti di test e produzione, come parte dei regolari test di failover per il ripristino delle applicazioni in caso di emergenza. I test regolari sono fondamentali per garantire che siate pronti e abbiate la sicurezza necessaria per mitigare i problemi quando si verifica un evento operativo.
- Assicurati che tutte le zone di disponibilità siano integre e che assorbano traffico
I turni zonali funzionano contrassegnando una risorsa, ovvero una replica dell'applicazione, come non integra in una zona di disponibilità. Ciò significa che è fondamentale garantire che gli obiettivi dei sistemi di bilanciamento del carico delle applicazioni siano generalmente integri e che assorbano attivamente il traffico nelle zone di disponibilità di una regione. Ti consigliamo di disporre di dashboard per tenere traccia di ciò, incluse, ad esempio, le metriche Elastic Load Balancing per obiettivi bytesProcessed non integri e per zona di disponibilità.
Prendi in considerazione la possibilità di monitorare lo stato delle tue risorse da una seconda regione adiacente. I vantaggi di questo approccio sono che può essere più rappresentativo dell'esperienza degli utenti finali e riduce anche il rischio che sia l'applicazione che il monitoraggio vengano colpiti contemporaneamente dallo stesso disastro («destino condiviso»).
- Utilizzate le API operazioni sul piano dei dati per il disaster recovery
Per avviare un cambiamento di zona quando è necessario ripristinare un'applicazione rapidamente, con poche dipendenze, si consiglia di utilizzare le azioni di spostamento zonale AWS Command Line Interface o API con credenziali prememorizzate, se possibile. Puoi anche avviare turni zonali in, per facilità d'uso. AWS Management Console Ma quando un ripristino rapido e affidabile è fondamentale, le operazioni sul piano dati sono una scelta migliore. Per ulteriori informazioni, consulta la Zonal Shift API Reference Guide.
- Sposta il traffico con uno spostamento zonale solo temporaneamente
Uno spostamento zonale allontana temporaneamente il traffico da una zona di disponibilità, per mitigare un danno. È necessario ripristinare la risorsa per l'applicazione in servizio non appena si interviene per correggere un problema. Ciò garantisce che l'intera applicazione venga ripristinata allo stato originale, completamente ridondante e resiliente.