Le migliori pratiche per il controllo del routing in ARC

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

Per eseguire attività di failover ARC con il piano dati del cluster di ripristinoAPI, è possibile allegare una ARC IAM policy all'utente. Per ulteriori informazioni, consulta Esempi di policy basate sull'identità in Amazon Application Recovery Controller () ARC.

Per DNS i record che potrebbe essere necessario modificare nell'ambito del meccanismo di failover, in particolare per i record sottoposti a controlli di integrità, è opportuno utilizzare TTL valori inferiori. L'impostazione TTL di un valore di 60 o 120 secondi è una scelta comune in questo scenario.

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

Per ulteriori informazioni, consulta Scelta TTL dei valori per i DNS record nelle Best practice per Amazon Route 53 DNS.

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 dell'applicazione è un DNS aggiornamento. 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 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'keepaliveopzione 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.

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

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

Utilizzando il piano ARC datiAPI, è possibile visualizzare i controlli e gli stati del routing insieme all'ListRoutingControlsoperazione e aggiornare gli stati di controllo del routing per reindirizzare il traffico in modo da consentire il failover dell'operazione. UpdateRoutingControlState È possibile utilizzare AWS CLI (come in questi esempi) o il codice che si scrive utilizzando uno dei. AWS SDKs ARCoffre un'affidabilità estrema grazie API al piano dati integrato per evitare il failover del traffico. Si consiglia di utilizzare API invece di modificare gli stati di controllo del routing in. AWS Management Console

Connect a uno degli endpoint del cluster regionale ARC per utilizzare il piano API 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 ignorarla per effettuare l'aggiornamento e gestire il traffico. Per ulteriori informazioni, consulta Sostituire le regole di sicurezza per reindirizzare il traffico.

Testa regolarmente il failover con il controllo del ARC routing, per eseguire il failover dallo stack di applicazioni primario a uno stack di applicazioni secondario. È importante assicurarsi che le ARC strutture aggiunte siano allineate con le risorse corrette dello stack e che tutto funzioni come previsto. È consigliabile verificarlo dopo la configurazione ARC dell'ambiente e continuare a farlo periodicamente, in modo da preparare l'ambiente di failover, prima che si verifichi una situazione di errore in cui è necessario che il sistema secondario sia attivo e funzionante rapidamente per evitare tempi di inattività per gli utenti.