Le migliori pratiche per il controllo del routing in ARC

In uno scenario di disaster recovery (DR), riduci al minimo le dipendenze del sistema utilizzando un approccio semplice per accedere AWS ed eseguire le attività di ripristino. Crea credenziali IAM a lunga durata appositamente per le attività di DR e conservale in modo sicuro in una cassaforte fisica locale o in un deposito virtuale, per accedervi quando necessario. Con IAM, puoi gestire centralmente le credenziali di sicurezza, come le chiavi di accesso e le autorizzazioni per l'accesso alle risorse. AWS Per le attività non DR, ti consigliamo di continuare a utilizzare l'accesso federato, utilizzando AWS servizi come Single. AWS Sign-On

Per eseguire attività di failover in ARC con l'API data plane del cluster di ripristino, puoi allegare una policy ARC IAM al tuo utente. Per ulteriori informazioni, consulta Identity-based esempi di policy in Amazon Application Recovery Controller (ARC).

Per i record DNS che potresti dover modificare nell'ambito del meccanismo di failover, in particolare i record che sono sottoposti a controllo di integrità, è opportuno utilizzare valori TTL inferiori. Per questo scenario, è comune impostare un TTL di 60 o 120 secondi.

L'impostazione DNS TTL (time to live) indica ai resolver DNS per quanto tempo memorizzare nella cache un record prima di richiederne uno nuovo. Quando si sceglie un TTL, si fa un compromesso tra latenza e affidabilità e reattività ai cambiamenti. Con un TTL più breve su un record, i resolver DNS notano gli aggiornamenti del record più rapidamente perché il TTL specifica che devono eseguire query più frequentemente.

Per ulteriori informazioni, consulta Scelta dei valori TTL per i record DNS in Best practice for Amazon Route 53 DNS. https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-dns.html

Quando utilizzi i controlli di routing per passare da uno Regione AWS all'altro, il meccanismo utilizzato da Amazon Application Recovery Controller (ARC) per spostare il traffico delle applicazioni è un aggiornamento DNS. Questo aggiornamento fa sì che tutte le nuove connessioni vengano indirizzate lontano dalla posizione compromessa.

Tuttavia, i client con connessioni aperte preesistenti potrebbero continuare a fare richieste sulla sede compromessa fino alla riconnessione dei client. Per garantire un ripristino rapido, ti consigliamo di limitare il periodo di tempo in cui i clienti rimangono connessi ai tuoi endpoint.

Se utilizzi un Application Load Balancer, puoi utilizzare l'keepaliveopzione per configurare la durata delle connessioni. Per ulteriori informazioni, consulta la durata del client HTTP keepalive nella Guida per l'utente di Application Load Balancer.

Per impostazione predefinita, Application Load Balancer imposta il valore di durata keepalive del client HTTP su 3600 secondi o 1 ora. Ti consigliamo di abbassare il valore in modo che sia in linea con l'obiettivo di tempo di ripristino per l'applicazione, ad esempio 300 secondi. Quando scegliete la durata keepalive di un client HTTP, tenete presente che questo valore rappresenta un compromesso tra la riconnessione più frequente in generale, che può influire sulla latenza, e l'allontanamento più rapido di tutti i client da una AZ o da una regione compromessa.

Ti consigliamo di conservare una copia locale degli endpoint del cluster ARC Regional, nei segnalibri o salvata nel codice di automazione che utilizzi per riprovare gli endpoint. Durante un evento di errore, potresti non essere in grado di accedere ad alcune operazioni API, incluse le operazioni API ARC che non sono ospitate sul cluster di dati estremamente affidabile. È possibile elencare gli endpoint per i cluster ARC utilizzando l'operazione DescribeCluster API.

I controlli di routing forniscono cinque endpoint regionali per garantire un'elevata disponibilità, anche in caso di guasti. Per ottenere la loro piena resilienza, è importante disporre di una logica di ripetizione in grado di utilizzare tutti e cinque gli endpoint, se necessario. Per informazioni sull'utilizzo di esempi di codice con l' AWS SDK, inclusi esempi per provare gli endpoint del cluster, consulta. Esempi di codice per l'utilizzo di Application Recovery Controller AWS SDKs

Utilizzando l'API ARC data plane, visualizzate i controlli e gli stati del routing con l'ListRoutingControlsoperazione e aggiornate gli stati di controllo del routing per reindirizzare il traffico destinato al failover con l'operazione. UpdateRoutingControlState È possibile utilizzare AWS CLI (come in questi esempi) o il codice scritto utilizzando uno degli SDK. AWS ARC offre un'estrema affidabilità con l'API nel piano dati per il failover del traffico. Si consiglia di utilizzare l'API anziché modificare gli stati di controllo del Console di gestione AWS routing in.

Connettiti a uno degli endpoint del tuo cluster regionale per consentire ad ARC di utilizzare l'API del piano dati. Se l'endpoint non è disponibile, prova a connetterti a un altro endpoint del cluster.

Se una regola di sicurezza blocca un aggiornamento dello stato di controllo del routing, puoi bypassarlo per effettuare l'aggiornamento e il failover del traffico. Per ulteriori informazioni, consulta Ignorare le regole di sicurezza per reindirizzare il traffico.

Testa regolarmente il failover con ARC Routing Control, per passare dallo stack di applicazioni primario a uno stack di applicazioni secondario. È importante assicurarsi che le strutture ARC aggiunte siano allineate con le risorse corrette nello stack e che tutto funzioni come previsto. È consigliabile verificarlo dopo aver configurato ARC per il proprio ambiente e continuare a eseguire i test periodicamente, in modo che l'ambiente di failover sia pronto, prima di incorrere in una situazione di errore in cui è necessario che il sistema secondario sia attivo e funzionante rapidamente per evitare tempi di inattività per gli utenti.