Questa pagina spiega in che modo Memorystore for Valkey esegue la manutenzione sulle istanze. Fornisce inoltre informazioni e consigli di configurazione che le tue applicazioni client devono conoscere per sfruttare al meglio il design di manutenzione senza tempi di riposo di Memorystore per Valkey. Questi suggerimenti si applicano sia alle istanze a disponibilità elevata sia alle istanze senza repliche. Tuttavia, consigliamo vivamente la configurazione ad alta disponibilità per tutti i casi d'uso di produzione.
Memorystore for Valkey aggiorna regolarmente le istanze per garantire che il servizio sia affidabile, performante, sicuro e aggiornato. Questi aggiornamenti prendono il nome di manutenzione. La manutenzione è completamente gestita dal servizio ed è progettata per non avere alcun impatto sui tempi di inattività.
La manutenzione in genere rientra nelle seguenti categorie:
- Funzionalità di Memorystore. Per lanciare alcune funzionalità, Memorystore richiede un aggiornamento di manutenzione.
- Patch per il sistema operativo. Monitoriamo continuamente le nuove vulnerabilità di sicurezza identificate nel sistema operativo. Una volta rilevata, applichiamo una patch al sistema operativo per proteggerti da nuovi rischi.
- Patch di database. La manutenzione può includere un aggiornamento di Valkey per migliorare le caratteristiche di sicurezza, prestazioni e affidabilità dell'istanza oltre a quanto offerto da Valkey.
Configura l'applicazione client
Per configurare l'applicazione client in modo da ottenere le migliori prestazioni e disponibilità possibili durante la manutenzione, segui questi passaggi:
- Utilizza e configura il client di terze parti in base alle indicazioni riportate in Best practice per i client per assicurarti che la manutenzione pianificata non influisca sull'applicazione client. Le nostre configurazioni client consigliate possono evitare i reset delle connessioni tramite aggiornamenti periodici della topologia in linea e rotazioni delle connessioni in background.
- Testa l'applicazione client con una serie di operazioni di aggiornamento (ad esempio ridimensionamento in aumento o in diminuzione, modifiche al numero di repliche) durante l'esecuzione di un carico di lavoro rappresentativo sui nodi principali e sulle repliche e monitora l'impatto sul client. Questi aggiornamenti testano la logica di aggiornamento della topologia in linea sui client, l'impatto della sincronizzazione completa, il rilevamento di nuovi nodi e la funzionalità di rimozione dei nodi esistenti. I test consentono di assicurarsi che il client di terze parti sia configurato correttamente per evitare ripercussioni negative sulla tua applicazione.
Manutenzione pianificata
Memorystore per Valkey sfrutta una strategia di ciclo di vita di creazione prima di eliminazione e di implementazione graduale per evitare che la manutenzione pianificata di Memorystore influisca sul tempo di inattività delle istanze Valkey. La manutenzione senza tempi di inattività si ottiene utilizzando le funzionalità di reindirizzamento delle richieste del protocollo cluster OSS Valkey in combinazione con i seguenti meccanismi Memorystore:
- Failover coordinato senza perdita di dati
- Rimozione curata dei nodi per consentire ai client di recuperare gli aggiornamenti della topologia dei nodi senza alcun impatto sulla disponibilità
- Gli endpoint PSC dell'istanza non sono interessati dalla manutenzione. Per ulteriori informazioni sugli endpoint PSC, vedi Endpoint delle istanze.
Il comportamento del servizio descritto nelle sezioni seguenti si applica solo alla manutenzione pianificata. Per informazioni sull'impatto di eventi imprevisti come guasti hardware, vedi Comportamento del client durante un failover imprevisto.
Periodi di manutenzione predefiniti
Per impostazione predefinita, Memorystore aggiorna l'istanza nel modo in base al fuso orario dell'istanza:
Finestra dei giorni feriali (da lunedì a venerdì): dalle 22.00 alle 6.00
Finestra del fine settimana: dalle 22:00 di venerdì alle 06:00 di lunedì
Strategia di deployment graduali
I deployment di Memorystore for Valkey vengono eseguiti con un ambito progressivamente crescente e a una velocità che consente il rilevamento degli errori in tempo sufficiente per mitigare l'impatto e stabilire l'affidabilità della stabilità. I tempi di attesa (il tempo durante il quale l'aggiornamento viene applicato e monitorato prima che venga considerato un esito positivo e in futuro) sono integrati nel parco istanze Memorystore nella scala del servizio. Inoltre, i tempi di recupero sono integrati all'interno delle istanze nelle varie zone di una regione (più domini di errore) per ridurre l'eventuale impatto dell'impatto.
Per l'istanza configurata per l'alta disponibilità, in un determinato momento viene aggiornato al massimo un dominio di errore/una zona per garantire che uno shard dell'istanza, incluse le repliche e la principale, abbia un'alta disponibilità durante l'aggiornamento. Inoltre, in un determinato momento vengono aggiornati solo alcuni nodi Valkey. Gli aggiornamenti utilizzano un meccanismo di ciclo di vita di creazione prima della distruzione per massimizzare la stabilità delle istanze. Questa strategia offre i maggiori vantaggi quando viene aggiornata un'istanza con molti shard. L'applicazione degli aggiornamenti solo a una piccola parte dello spazio delle chiavi utente complessivo in un determinato momento massimizza la disponibilità dei dati.
Strategia di ciclo di vita Crea prima di eliminare
Un'istanza Valkey ha più shard. Ogni shard ha un nodo primario e zero o più nodi di replica. Memorystore utilizza la seguente procedura per aggiornare qualsiasi nodo Valkey principale o replica esistente in uno shard:
- Memorystore for Valkey aggiunge innanzitutto una replica completamente nuova allo shard con l'aggiornamento software più recente. Memorystore crea un nodo completamente nuovo, anziché aggiornarne uno esistente, per garantire che la capacità di cui è stato eseguito il provisioning venga mantenuta in caso di errore di bootstrap imprevisto.
- Se un nodo all'interno del frammento da aggiornare è un nodo principale, viene prima convertito in una replica prima della rimozione utilizzando un failover coordinato.
- Successivamente, Memorystore rimuove la replica che utilizza il software precedente.
- Il processo viene ripetuto per ciascun nodo dell'istanza.
La strategia di creazione prima dell'eliminazione consente di mantenere la capacità dell'istanza sottoposta a provisioning, rispetto a un tipico deployment in sequenza che si aggiorna in loco, ma determina un'interruzione della disponibilità (e talvolta una perdita di dati) per l'applicazione client. Per gli shard senza repliche, Memorystore per Valkey esegue comunque prima il provisioning di una nuova replica, coordina il failover e infine sostituisce il nodo principale esistente dello shard.
Passaggio 1: aggiungi una replica Valkey
Il primo passaggio del meccanismo Crea prima di eliminare consiste nell'aggiungere un nodo replica con il software più recente utilizzando il meccanismo Valkey OSS di sincronizzazione completa per copiare i dati dal nodo principale al nodo replica. Ciò viene fatto eseguendo il fork di un processo secondario e sfruttando la replica senza disco per avviare la replica.
Puoi sfruttare al meglio l'architettura con scalabilità orizzontale dell'istanza eseguendo il provisioning di un numero maggiore di shard per ridurre le dimensioni dello spazio delle chiavi all'interno di un nodo. Avere un set di dati più piccolo per nodo contribuisce a ridurre l'impatto della latenza del fork di un'operazione di sincronizzazione completa. Inoltre, velocizza la copia dei dati tra i nodi.
Passaggio 2: failover principale coordinato
Se il nodo Valkey da aggiornare è un nodo principale, Memorystore esegue prima un failover coordinato al nodo replica appena aggiunto e poi procede con la rimozione del nodo. Durante il failover coordinato, il client e i nodi Valkey collaborano e utilizzano le strategie seguenti per evitare tempi di inattività per l'applicazione:
- Le richieste in arrivo dei client vengono bloccate temporaneamente sul nodo principale, fornendo una finestra per assicurarsi che la replica esistente sia sincronizzata al 100% con quella principale.
- La replica completa la procedura di elezione per assumere il ruolo principale.
- Il nodo primario precedente, ora una replica, sblocca le richieste esistenti e le reindirizza alla nuova istanza principale eletta utilizzando il protocollo del cluster OSS Valkey. Le nuove richieste inviate al nodo replica precedente continuano a essere reindirizzate al nuovo nodo principale.
- Il client compatibile con Valkey aggiorna la topologia in memoria. Apprende l'indirizzo del nuovo endpoint principale e non richiede più reindirizzamenti.
In genere, i failover coordinati richiedono decine di millisecondi. Tuttavia, il flush dei dati in corso nelle repliche e la dimensione totale dell'istanza possono aumentare la latenza di failover. Le dimensioni dell'istanza possono influenzare la convergenza tra i nodi primari, il che influisce sul processo decisionale relativo alla scelta della nuova istanza principale.
Passaggio 3: rimuovi la replica di Valkey
L'ultimo passaggio del meccanismo di creazione prima dell'eliminazione è la rimozione del nodo di replica sul software precedente. Una rimozione brusca del nodo avrebbe un impatto per le applicazioni client, in quanto i client memorizzano nella cache le informazioni dell'endpoint e la topologia dell'istanza. Memorystore per Valkey ha progettato la rimozione di una replica Valkey in modo che sia graduale, in modo da consentire alle applicazioni client di aggiornare la loro topologia prima di un arresto anomalo del nodo. La topologia è personalizzata per consentire ai client di conoscere la nuova replica, ma anche di dimenticare in anticipo quella da rimuovere.
Il nodo di replica che esegue il software precedente viene mantenuto per un determinato periodo di svuotamento, generalmente dell'ordine di minuti, durante il quale inizia a reindirizzare le richieste di lettura in entrata al nodo primario dello shard. Consente al client di terze parti di aggiornare la topologia dei nodi e di saperne di più sui nuovi endpoint di replica. Se il client tenta di raggiungere un nodo rimosso dopo il periodo di svuotamento, il tentativo non va a buon fine, il che a sua volta attiva un aggiornamento della topologia del nodo sul client in connessione in modo che venga a conoscenza della modifica della replica. I nuovi aggiornamenti della topologia del nodo non vedono il nodo replica da rimuovere.