Questa pagina spiega in che modo l'architettura di Memorystore for Redis Cluster supporta e fornisce l'alta affidabilità (HA). Questa pagina spiega anche le configurazioni consigliate che contribuiscono a migliorare le prestazioni e la stabilità dell'istanza.
Per saperne di più sulle considerazioni specifiche per le regioni, consulta Area geografica e regioni.
Alta affidabilità
Memorystore for Redis Cluster è basato su un'architettura ad alta affidabilità in cui i client accedono direttamente alle VM di Memorystore for Redis Cluster gestite. I client lo fanno connettendosi ai singoli indirizzi di rete degli shard, come descritto in Connettersi a un'istanza di Memorystore for Redis Cluster.
La connessione diretta agli shard offre i seguenti vantaggi:
La connessione diretta evita qualsiasi singolo punto di errore perché ogni shard è progettato per non funzionare in modo indipendente. Ad esempio, se il traffico di più client sovraccarica uno slot (blocco dello spazio delle chiavi), l'errore dello shard limita l'impatto sullo shard responsabile della gestione dello slot.
La connessione diretta evita gli hop intermedi, il che riduce al minimo il tempo di round trip (latenza del client) tra il client e la VM Redis.
Configurazioni consigliate
Ti consigliamo di creare istanze multizona ad alta affidabilità anziché istanze a zona singola, perché offrono una maggiore affidabilità. Tuttavia, se scegli di eseguire il provisioning di un'istanza senza repliche, ti consigliamo di scegliere un'istanza a zona singola. Per saperne di più, consulta Quando utilizzare un cluster a zona singola.
Per abilitare l'alta affidabilità per l'istanza, devi eseguire il provisioning di almeno un nodo di replica per ogni shard. Puoi farlo quando crei l'istanza oppure puoi scalare il numero di repliche ad almeno una replica per shard. Le repliche forniscono il failover automatico durante la manutenzione pianificata e gli errori imprevisti degli shard.
Devi configurare il client in base alle indicazioni riportate in Best practice per i client Redis. L'utilizzo delle best practice consigliate consente al client OSS Redis di gestire automaticamente e senza problemi il ruolo (failover automatici) e le modifiche dell'assegnazione degli slot (sostituzione dei nodi, fare lo scale out/in dei consumer) per il cluster senza tempi di inattività.
Repliche
Un'istanza di Memorystore for Redis Cluster ad alta affidabilità è una risorsa di regione. Ciò significa che le VM principali e di replica degli shard sono distribuite su più zone per proteggersi da un'interruzione a livello di zona. Memorystore for Redis Cluster supporta istanze con 0-5 repliche per nodo.
Puoi utilizzare le repliche per aumentare la velocità effettiva di lettura scalando le letture.
Per farlo, devi utilizzare il comando READONLY per stabilire una connessione che consenta al client di leggere dalle repliche. Per maggiori dettagli sulla lettura
dalle repliche, consulta Scalare con Redis Cluster.
Forma del cluster con 0 repliche per nodo
Forma del cluster con 1 replica per nodo
Forma del cluster con più repliche per nodo
Failover automatico
I failover automatici all'interno di uno shard possono verificarsi a causa della manutenzione o di un errore imprevisto del nodo principale. Durante un failover, una replica viene promossa a principale. Puoi configurare le repliche in modo esplicito. Il servizio può anche eseguire temporaneamente il provisioning di repliche aggiuntive durante la manutenzione interna per evitare tempi di inattività.
I failover automatici impediscono la perdita di dati durante gli aggiornamenti di manutenzione. Per i dettagli sul comportamento del failover automatico durante la manutenzione, consulta Comportamento del failover automatico durante la manutenzione.
Durata del failover e della riparazione dei nodi
I failover automatici possono richiedere un tempo dell'ordine di decine di secondi per eventi non pianificati, come un arresto anomalo del processo del nodo principale o un guasto hardware. Durante questo periodo, il sistema rileva l'errore e seleziona una replica come nuovo nodo principale.
La riparazione dei nodi può richiedere un tempo dell'ordine di minuti per consentire al servizio di sostituire il nodo non funzionante. Questo vale per tutti i nodi principali e di replica. Per le istanze ad alta affidabilità (senza repliche di cui è stato eseguito il provisioning), la riparazione di un nodo principale non funzionante richiede anche un tempo dell'ordine di minuti.
Comportamento del client durante un failover non pianificato
È probabile che le connessioni client vengano reimpostate a seconda della natura dell'errore. Dopo il ripristino automatico, è necessario riprovare le connessioni con un backoff esponenziale per evitare di sovraccaricare i nodi principali e di replica.
I client che utilizzano le repliche per la velocità effettiva di lettura devono essere preparati a un degrado temporaneo della capacità fino a quando il nodo non funzionante non viene sostituito automaticamente.
Scritture perse
Durante un failover dovuto a un errore imprevisto, le scritture riconosciute potrebbero andare perse a causa della natura asincrona del protocollo di replica di Redis.
Le applicazioni client possono sfruttare il comando Redis WAIT per migliorare la sicurezza dei dati reali. Si tratta di un approccio di tipo best-effort che comporta compromessi, come spiegato nella documentazione del comando Redis WAIT.
Impatto sullo spazio delle chiavi di un'interruzione a zona singola
Questa sezione descrive l'impatto di un'interruzione a zona singola su un'istanza di Memorystore for Redis Cluster.
Istanze multizona
Istanze ad alta affidabilità: se si verifica un'interruzione in una zona, l'intero spazio delle chiavi è disponibile per le letture e le scritture, ma poiché alcune repliche di lettura non sono disponibili, la capacità di lettura viene ridotta. Ti consigliamo vivamente di eseguire l'overprovisioning della capacità del cluster in modo che l'istanza abbia una capacità di lettura sufficiente, nel raro caso di un'interruzione a zona singola. Una volta terminata l'interruzione, le repliche nella zona interessata vengono ripristinate e la capacità di lettura del cluster torna al valore configurato. Per saperne di più, consulta Pattern per app scalabili e affidabili.
Istanze non ad alta affidabilità (senza repliche): se si verifica un'interruzione in una zona, la parte dello spazio delle chiavi di cui è stato eseguito il provisioning nella zona interessata viene sottoposta a un flush dei dati e non è disponibile per le scritture o le letture per la durata dell'interruzione. Una volta terminata l'interruzione, i nodi principali nella zona interessata vengono ripristinati e la capacità del cluster torna al valore configurato.
Istanze a zona singola
- Istanze ad alta affidabilità e non ad alta affidabilità: se si verifica un'interruzione nella zona in cui è stato eseguito il provisioning dell'istanza, il cluster non è disponibile e i dati vengono sottoposti a un flush. Se si verifica un'interruzione in un'altra zona, il cluster continua a gestire le richieste di lettura e scrittura. Una volta terminata l'interruzione, la capacità configurata del cluster viene ripristinata.
Best practice
Questa sezione descrive le best practice per l'alta affidabilità e le repliche.
Aggiungere una replica
L'aggiunta di una replica richiede uno snapshot RDB. Gli snapshot RDB utilizzano un fork di processo e un meccanismo di "copy-on-write" per creare uno snapshot dei dati dei nodi. A seconda del pattern di scrittura nei nodi, la memoria utilizzata dei nodi aumenta man mano che le pagine toccate dalle scritture vengono copiate. Il footprint della memoria può essere fino al doppio delle dimensioni dei dati nel nodo.
Per assicurarti che i nodi abbiano memoria sufficiente per completare lo snapshot, mantieni o
imposta maxmemory all'80% della
capacità del nodo in modo che il 20% sia riservato all'overhead. Questo overhead di memoria, oltre al monitoraggio degli snapshot, ti aiuta a gestire il workload per avere snapshot riusciti. Inoltre, quando aggiungi repliche, riduci il più possibile il traffico di scrittura. Per saperne di più, consulta Monitorare un cluster con un carico di scrittura elevato.