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à.
Resilienza in Amazon ElastiCache
L'infrastruttura AWS globale è costruita attorno a AWS regioni e zone di disponibilità. AWS Le regioni forniscono più zone di disponibilità fisicamente separate e isolate, collegate con reti a bassa latenza, ad alto throughput e altamente ridondanti. Con le zone di disponibilità, è possibile progettare e gestire applicazioni e database che eseguono il failover automatico tra zone di disponibilità senza interruzioni. Le zone di disponibilità sono più disponibili, tolleranti ai guasti e scalabili rispetto alle infrastrutture tradizionali a data center singolo o multiplo.
Oltre all'infrastruttura AWS globale, Amazon ElastiCache offre diverse funzionalità per aiutarti a supportare le tue esigenze di resilienza e backup dei dati.
Limitazione dell'impatto degli errori
Quando pianifichi l' ElastiCache implementazione di Amazon, devi pianificare in modo che gli errori abbiano un impatto minimo sull'applicazione e sui dati. Questa sezione, organizzata in più argomenti, illustra cosa fare per proteggere l'applicazione e i dati in caso di errori.
Argomenti
Limitazione degli errori con Memcached in esecuzione
Per minimizzare l'impatto degli errori con un motore Memcached in esecuzione, è possibile avvalersi delle seguenti soluzioni. Esistono due tipi di errori gestibili nei piani di mitigazione, gli errori dei nodi e quelli delle zone di disponibilità.
Limitazione degli errori dei nodi
Le cache serverless mitigano automaticamente gli errori dei nodi con un'architettura multi-AZ replicata in modo che gli errori dei nodi siano trasparenti per l'applicazione. Per minimizzare l'impatto dell'errore di un nodo in un cluster progettato autonomamente, occorre innanzitutto distribuire i dati memorizzati nella cache tra più nodi. Poiché i cluster progettati autonomamente non supportano la replica, un errore di nodo comporta in ogni caso una perdita di dati del cluster.
Quando crei un cluster Memcached, puoi crearlo con da 1 a 60 nodi o più su richiesta speciale. Ripartire i dati tra più nodi consente di arginare la perdita di dati se un nodo genera un errore. Se, ad esempio, i dati vengono distribuiti tra dieci nodi, ciascuno di questi includerà circa il 10% dei dati memorizzati nella cache. Pertanto, in caso di errore, la perdita da arginare con la creazione e il provisioning di un nodo sostitutivo sarà del 10%. Se gli stessi dati fossero memorizzati in 3 nodi più grandi, un errore di nodo comporterebbe la perdita di circa il 33% dei dati memorizzati nella cache.
Per informazioni su come definire il numero di nodi in un cluster Memcached, consulta Creazione di un cluster Memcached (console).
Limitazione degli errori delle zone di disponibilità
Le cache serverless mitigano automaticamente gli errori delle zone di disponibilità con un'architettura multi-AZ replicata in modo che gli errori delle zone di disponibilità siano trasparenti per l'applicazione.
Per limitare l'impatto dell'errore di una zona di disponibilità in un cluster progettato autonomamente, posiziona i nodi nel maggior numero possibile di zone. Nell'improbabile eventualità di un errore AZ, perderai i dati memorizzati nella cache di quella AZ, non i dati memorizzati nella cache dell'altra. AZs
Perché impostare tanti nodi?
Se la mia regione ha solo tre zone di disponibilità, perché mi occorrono più di tre nodi, dal momento che, se una zona genera un errore, perdo comunque un terzo dei dati?
Ottima domanda. Esistono due tipi di errori di cui limitare gli effetti, gli errori dei nodi e quelli delle zone di disponibilità. Effettivamente, se i dati sono distribuiti su più zone di disponibilità, una delle quali genera un errore, si perdono solo i dati memorizzati in quest'ultima, indipendentemente dal numero di nodi in essere. Tuttavia, se è un nodo a generare l'errore, la presenza di più nodi riduce proporzionalmente la perdita di dati.
Non esiste una "formula magica" che consenta di determinare il numero di nodi da configurare in un cluster. È necessario valutare l'eventuale impatto della perdita di dati rispetto alla probabilità di errore e ai costi, per poi trarre le proprie conclusioni.
Per informazioni su come definire il numero di nodi in un cluster Memcached, consulta Creazione di un cluster Memcached (console).
Per ulteriori informazioni sulle regioni e sulle zone di disponibilità, consulta Regioni e zone di disponibilità.
Mitigazione degli errori durante l'esecuzione di Valkey o Redis OSS
Quando si utilizza un OSS motore Valkey o Redis, sono disponibili le seguenti opzioni per ridurre al minimo l'impatto di un errore di un nodo o di una zona di disponibilità.
Limitazione degli errori dei nodi
Le cache serverless mitigano automaticamente gli errori dei nodi con un'architettura multi-AZ in modo che gli errori dei nodi siano trasparenti per l'applicazione. I cluster progettati autonomamente devono essere configurati in modo appropriato per mitigare l'errore di un singolo nodo.
Per mitigare l'impatto dei guasti dei OSS nodi Valkey o Redis sui cluster progettati autonomamente, sono disponibili le seguenti opzioni:
Attenuazione degli errori: Valkey o Redis Replication Groups OSS
Un gruppo di OSS replica Valkey o Redis è composto da un singolo nodo primario dal quale l'applicazione può sia leggere che scrivere, e da 1 a 5 nodi di replica di sola lettura. Quanto scritto sul nodo primario si propaga in modo asincrono ai nodi della replica di lettura.
Quando una replica di lettura genera un errore
ElastiCache rileva la replica di lettura non riuscita.
ElastiCache disconnette il nodo guasto.
ElastiCache avvia e fornisce un nodo sostitutivo nella stessa AZ.
Il nuovo nodo si sincronizza con il nodo primario.
Nel frattempo, l'applicazione può continuare a leggere e scrivere avvalendosi degli altri nodi.
Valkey o Redis Multi-AZ OSS
È possibile abilitare Multi-AZ sui gruppi di replica Valkey o Redis. OSS Indipendentemente dal fatto che la funzione Multi-AZ sia abilitata o meno, un nodo primario non riuscito sarà comunque rilevato e sostituito automaticamente, sebbene con modalità diverse in base all'abilitazione.
Quando la funzione Multi-AZ è abilitata
ElastiCache rileva il guasto del nodo principale.
ElastiCache promuove il nodo di replica di lettura con il minor ritardo di replica sul nodo primario.
Le altre repliche si sincronizzano con il nuovo nodo primario.
ElastiCache avvia una replica di lettura nella zona di disponibilità del sistema primario fallito.
Il nuovo nodo si sincronizza con il nuovo nodo primario.
Il failover su un nodo di replica è un processo generalmente più veloce della creazione con il provisioning di un nuovo nodo primario. Ciò significa che l'applicazione può riprendere a scrivere sul nodo primario più velocemente con la funzione Multi-AZ abilitata.
Per ulteriori informazioni, consulta Riduzione al minimo dei tempi di inattività ElastiCache utilizzando Multi-AZ con Valkey e Redis OSS.
Quando la funzione Multi-AZ è disabilitata
ElastiCache rileva il guasto primario.
ElastiCache mette offline il principale.
ElastiCache crea e fornisce un nuovo nodo primario per sostituire il nodo primario guasto.
ElastiCache sincronizza il nuovo primario con una delle repliche esistenti.
A sincronizzazione conclusa, il nuovo nodo funge da nodo primario del cluster.
Durante le fasi 1-4 di questo processo, l'applicazione non può scrivere sul nodo primario, ma può continuare a leggere dai nodi di replica.
Per una maggiore protezione, si consiglia di avviare i nodi del gruppo di replica in diverse zone di disponibilità (). AZs Così facendo, l'eventuale malfunzionamento di una zona di disponibilità andrà a condizionare solo i nodi in essa, senza compromettere quelli nelle altre.
Per ulteriori informazioni, consulta Alta disponibilità utilizzando gruppi di replica.
Limitazione degli errori delle zone di disponibilità
Le cache serverless mitigano automaticamente gli errori delle zone di disponibilità con un'architettura multi-AZ replicata in modo che gli errori delle zone di disponibilità siano trasparenti per l'applicazione.
Per limitare l'impatto dell'errore di una zona di disponibilità in un cluster progettato autonomamente, posiziona i nodi di ogni partizione nel maggior numero possibile di zone.
Se tutti i nodi di una partizione, indipendentemente dal numero, fossero posizionati nella stessa zona di disponibilità, un errore di quest'ultima si rivelerebbe catastrofico, poiché comporterebbe la perdita di tutti i dati della partizione. Tuttavia, se si posizionano i nodi in più aree di AZs disponibilità, in caso di errore in una zona di disponibilità si perderanno solo i nodi di tale zona.
Perdere un nodo significa subire un calo nelle prestazioni, poiché le operazioni di lettura si ritrovano a dover essere condivise da meno nodi. Tale calo non conoscerà soluzione di continuità fino alla sostituzione dei nodi.
Per informazioni su come specificare le zone di disponibilità per i OSS nodi Valkey o Redis, consulta. Creazione di un cluster Valkey (modalità cluster disabilitata) (console)
Per ulteriori informazioni sulle regioni e sulle zone di disponibilità, consulta Scelta delle regioni e delle zone di disponibilità per ElastiCache.
Raccomandazioni
Consigliamo di creare le cache serverless su cluster progettati autonomamente, in quanto si ottiene automaticamente una migliore tolleranza agli errori senza configurazioni aggiuntive. Quando si crea un cluster progettato autonomamente, tuttavia, è necessario pianificare due tipi di errori: errori di singoli nodi ed errori di zone di disponibilità. Il piano di mitigazione degli errori ideale consente di affrontare entrambe le tipologie di guasto.
Minimizzazione dell'impatto degli errori dei nodi
Per ridurre al minimo l'impatto di un errore di nodo quando si utilizza Valkey o RedisOSS, si consiglia di utilizzare nell'implementazione più nodi in ogni shard e di distribuire i nodi su più zone di disponibilità. Questa operazione viene eseguita automaticamente per le cache serverless.
Per i cluster progettati autonomamente su Valkey o RedisOSS, consigliamo di abilitare Multi-AZ sul gruppo di replica in modo da eseguire automaticamente il failover su una replica in caso di guasto del ElastiCache nodo primario.
Quando si esegue Memcached e si ripartiscono i dati tra i nodi, più nodi si configurano, minore sarà la perdita di dati in caso di errore.
Minimizzare l'impatto degli errori delle zone di disponibilità
Per ridurre al minimo l'impatto dell'errore di una zona di disponibilità, consigliamo di ubicare i nodi nel maggior numero possibile di zone di disponibilità. La distribuzione uniforme dei nodi tra i nodi AZs ridurrà al minimo l'impatto nell'improbabile caso di un errore AZ. Questa operazione viene eseguita automaticamente per le cache serverless.
Altre precauzioni
Se utilizzi Valkey o RedisOSS, oltre a quanto sopra, ti consigliamo di pianificare backup regolari del cluster. I backup (gli snapshot) generano un file .rdb utile per ripristinare la cache in caso di errore o danneggiamento. Per ulteriori informazioni, consulta Snapshot e ripristino.
