Questa pagina spiega come Memorystore for Valkey esegue la manutenzione delle 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 consigli si applicano sia alle istanze ad alta disponibilità sia a quelle 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 sono chiamati manutenzione. La manutenzione è completamente gestita dal servizio ed è progettata per non avere alcun impatto sui tempi di inattività.
La manutenzione di solito rientra nelle seguenti categorie:
- Funzionalità di Memorystore. Per lanciare alcune funzionalità, Memorystore richiede un aggiornamento di manutenzione.
- Patch del sistema operativo. Monitoriamo costantemente le vulnerabilità di sicurezza appena identificate nel sistema operativo. Una volta rilevata, applichiamo una patch al sistema operativo per proteggerti da nuovi rischi.
- Patch del database. La manutenzione può includere un aggiornamento di Valkey per migliorare le caratteristiche di sicurezza, prestazioni e affidabilità dell'istanza oltre a quanto fornito da OSS 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 fare lo scale in 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 for 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 riposo viene eseguita utilizzando le funzionalità di reindirizzamento delle richieste del protocollo del cluster Valkey open source in combinazione con i seguenti meccanismi di Memorystore:
- Failover coordinato senza perdita di dati
- Rimozione dei nodi in modo graduale per consentire ai client di allinearsi agli 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 nelle seguenti finestre in base al fuso orario dell'istanza:
Finestra dei giorni feriali (dal lunedì al venerdì): dalle 22:00 alle 06:00
Finestra del fine settimana: dalle 22:00 di venerdì alle 06:00 di lunedì
Strategia di deployment graduale
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 applicazione (tempo durante il quale l'aggiornamento viene applicato e monitorato prima di considerarlo riuscito ed eseguire l'operazione successiva) sono integrati nell'intero parco di istanze Memorystore a livello di servizio. Inoltre, i tempi di compilazione sono integrati nelle istanze nelle zone di una regione (più domini di errore) per ridurre l'eventuale ambito 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 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 principale e zero o più nodi replica. Memorystore utilizza la seguente procedura per aggiornare qualsiasi nodo Valkey principale o replica esistente in uno shard:
- Memorystore per Valkey aggiunge prima una replica completamente nuova con l'aggiornamento software più recente allo shard. 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.
- Next Memorystore rimuove la replica che utilizza il software precedente.
- La procedura viene ripetuta per ogni nodo dell'istanza.
La strategia Crea prima di eliminare consente di mantenere la capacità di provisioning dell'istanza, rispetto a un tipico deployment incrementale che si aggiorna in situ, ma comporta un'interruzione della disponibilità (e a volte la 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 la replica di 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.
Per sfruttare al meglio l'architettura di scalabilità orizzontale dell'istanza, esegui il provisioning di un numero maggiore di shard per ridurre le dimensioni dello spazio 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 lavorano insieme e utilizzano le seguenti strategie per evitare i tempi di riposo dell'applicazione:
- Le richieste in arrivo dei client vengono bloccate temporaneamente sul nodo principale, fornendo una finestra per garantire 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 principale precedente, ora una replica, sblocca le richieste esistenti e le reindirizza al nodo principale appena eletto utilizzando il protocollo del cluster Valkey OSS. 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. Impara l'indirizzo del nuovo endpoint principale e non richiede più i reindirizzamenti.
In genere, i failover coordinati richiedono decine di millisecondi. Tuttavia, i dati in transito in attesa di essere sottoposti a flush nelle repliche e le dimensioni totali dell'istanza possono aumentare la latenza del failover. Le dimensioni dell'istanza possono influire sulla convergenza tra i nodi principali, il che influisce sulla decisione di eleggere il nuovo principale.
Passaggio 3: rimuovi la replica della chiave Valkey
L'ultimo passaggio del meccanismo Crea prima di eliminare consiste nel rimuovere il nodo replica sul software precedente. La rimozione improvvisa di un nodo avrebbe un impatto sulle applicazioni client perché i client memorizzano nella cache le informazioni sugli 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 replica che esegue il software precedente viene mantenuto per un determinato periodo di svuotamento, in genere nell'ordine di minuti, durante il quale inizia a reindirizzare le richieste di lettura in arrivo al nodo principale del relativo shard. Consente al client di terze parti di aggiornare la topologia del nodo e di conoscere i nuovi endpoint delle repliche. 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 della replica da rimuovere.