Questa pagina spiega come Memorystore for Redis Cluster esegue la manutenzione delle istanze. Fornisce inoltre informazioni e consigli di configurazione di cui le applicazioni client devono essere a conoscenza per sfruttare la progettazione della manutenzione senza tempi di inattività di Memorystore for Redis Cluster. Questi consigli si applicano sia ai cluster ad alta disponibilità sia a quelli senza repliche. Tuttavia, consigliamo vivamente la configurazione ad alta disponibilità per tutti i casi d'uso di produzione.
Memorystore for Redis Cluster aggiorna regolarmente le istanze per garantire che il servizio sia affidabile, efficiente, 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 in genere rientra nelle seguenti categorie:
- Funzionalità di Memorystore. Per lanciare alcune funzionalità, Memorystore richiede un aggiornamento di manutenzione.
- Patch del sistema operativo. Monitoriamo continuamente 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 Redis per migliorare le caratteristiche di sicurezza, prestazioni e affidabilità dell'istanza oltre a quelle fornite da OSS Redis.
Configurare l'applicazione client
Per configurare l'applicazione client in modo da ottenere le migliori prestazioni e la massima disponibilità possibili durante la manutenzione, segui questi passaggi:
- Utilizza e configura il client del cluster OSS Redis in base alle indicazioni riportate in Best practice per il client Redis per assicurarti che qualsiasi manutenzione pianificata non influisca sull'applicazione client. Le nostre configurazioni client consigliate possono evitare i ripristini della connessione tramite aggiornamenti periodici della topologia in linea e rotazioni della connessione in background.
- Testa l'applicazione client con una serie di operazioni di aggiornamento (ad esempio scalabilità orizzontale o verticale, modifiche al conteggio delle repliche) durante l'esecuzione di un carico di lavoro rappresentativo sui nodi primari e di replica e monitora l'impatto sul client. Questi aggiornamenti testano la logica di aggiornamento della topologia in linea sui client, l'impatto della sincronizzazione completa, l'individuazione di nuovi nodi e la funzionalità di rimozione dei nodi esistenti. Il test consente di verificare che il client del cluster OSS Redis sia configurato correttamente per evitare qualsiasi impatto negativo sulla tua applicazione.
Manutenzione pianificata
Memorystore for Redis Cluster utilizza una strategia del ciclo di vita con deployment graduale e creazione prima dell'eliminazione per evitare qualsiasi impatto sui tempi di inattività a causa della manutenzione. La manutenzione senza tempi di inattività viene eseguita utilizzando le funzionalità di reindirizzamento delle richieste del protocollo del cluster Redis OSS in combinazione con i seguenti meccanismi di Memorystore:
- Failover coordinato senza alcuna perdita di dati.
- Rimozione controllata dei nodi per consentire ai client di recuperare gli aggiornamenti della topologia del cluster senza alcun impatto sulla disponibilità.
- Gli endpoint Private Service Connect del cluster non sono interessati dalla manutenzione. Per saperne di più su questi endpoint, consulta Endpoint del cluster.
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 non pianificato.
Strategia di deployment graduale
I deployment di manutenzione di Memorystore for Redis Cluster vengono eseguiti con un ambito in aumento progressivo e a una velocità che consente il rilevamento degli errori in tempo utile per mitigarne l'impatto e stabilire la fiducia nella stabilità. I tempi di bake (il periodo di tempo durante il quale l'aggiornamento viene applicato e monitorato prima di essere considerato riuscito e di procedere) sono integrati in tutta la flotta di cluster Memorystore su scala di servizio. Inoltre, i tempi di cottura sono integrati nel cluster tra le zone di una regione (più domini di errore) per ridurre l'ambito dell'impatto, se presente.
Per il cluster configurato per l'alta disponibilità, al massimo un dominio di errore/zona viene aggiornato in un determinato momento per garantire che uno shard del cluster, inclusi il nodo primario e le repliche, abbia un'alta disponibilità durante l'aggiornamento. Inoltre, solo alcuni nodi Redis vengono aggiornati in un determinato momento. Gli aggiornamenti utilizzano un meccanismo del ciclo di vita di creazione prima dell'eliminazione per massimizzare la stabilità del cluster. Questa strategia offre i maggiori vantaggi quando aggiorni un cluster con molti shard. L'applicazione degli aggiornamenti a una piccola parte dello spazio delle chiavi utente complessivo in un determinato momento massimizza la disponibilità dei dati.
Strategia del ciclo di vita con creazione prima dell'eliminazione
Un cluster Redis 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 Redis primario o di replica esistente in uno shard:
- Memorystore for Redis Cluster aggiunge innanzitutto una replica completamente nuova con l'ultimo aggiornamento software 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 dello shard da aggiornare è un nodo primario, viene prima convertito in una replica prima della rimozione utilizzando un failover coordinato.
- Successivamente, Memorystore rimuove la replica che utilizza il software precedente.
- La procedura viene ripetuta per ogni nodo del cluster.
La strategia create-before-destroy consente di conservare la capacità di provisioning del cluster, rispetto a un tipico deployment in sequenza che esegue aggiornamenti sul posto, ma comporta un'interruzione della disponibilità (e a volte una perdita di dati) per l'applicazione client. Per gli shard senza repliche, Memorystore for Redis Cluster esegue comunque il provisioning di una nuova replica, coordina il failover e infine sostituisce il nodo primario esistente dello shard.
Passaggio 1: aggiungi la replica Redis
Il primo passaggio del meccanismo create-before-destroy consiste nell'aggiungere un nodo di replica con il software più recente utilizzando il meccanismo di sincronizzazione completa OSS Redis per copiare i dati dal nodo primario al nodo di replica. A questo scopo, viene creato un processo figlio e viene sfruttata la replica senza dischi per eseguire il bootstrap della replica. Memorystore for Redis Cluster supporta la replica senza disco. A meno che tu non attivi la persistenza, Memorystore for Redis Cluster non utilizza i dischi durante la replica.
Puoi sfruttare al meglio l'architettura di scalabilità orizzontale del cluster eseguendo il provisioning di un numero maggiore di shard per ridurre le dimensioni dello spazio delle chiavi all'interno di un nodo. Un set di dati più piccolo per nodo contribuisce a ridurre l'impatto della latenza di fork di un'operazione di sincronizzazione completa. Inoltre, velocizza la copia dei dati tra i nodi.
Passaggio 2: failover primario coordinato
Se il nodo Redis che deve essere aggiornato è un nodo primario, Memorystore esegue prima un failover coordinato al nodo di replica appena aggiunto e poi procede con la rimozione del nodo. Durante il failover coordinato, il client e i nodi Redis collaborano e utilizzano le seguenti strategie per evitare tempi di inattività per l'applicazione:
- Le richieste client in entrata vengono temporaneamente bloccate sul nodo primario, fornendo una finestra per garantire che la replica esistente sia sincronizzata al 100% con il nodo primario.
- La replica completa la procedura di elezione per assumere il ruolo di istanza principale.
- Il nodo primario precedente, ora una replica, sblocca le richieste esistenti e le reindirizza al nodo primario appena eletto utilizzando il protocollo del cluster OSS Redis. Tutte le nuove richieste inviate al nodo di replica precedente continuano a essere reindirizzate al nuovo nodo primario.
- Il client compatibile con Redis Cluster aggiorna la topologia in memoria. Apprende l'indirizzo del nuovo endpoint principale e non richiede più reindirizzamenti.
I failover coordinati in genere richiedono decine di millisecondi. Tuttavia, le dimensioni totali del cluster possono aumentare la latenza di failover. Lo stesso vale per i dati in transito in attesa di essere scaricati nelle repliche. Le dimensioni del cluster possono influire sulla convergenza tra i nodi primari, il che influisce sul processo decisionale per l'elezione del nuovo nodo primario.
Passaggio 3: rimuovi la replica Redis
L'ultimo passaggio del meccanismo di creazione prima dell'eliminazione consiste nel rimuovere il nodo di replica sul software precedente. La rimozione improvvisa di un nodo avrebbe un impatto sulle applicazioni client perché i client memorizzano nella cache le informazioni sull'endpoint e la topologia del cluster. Memorystore for Redis Cluster ha progettato la rimozione di una replica Redis in modo controllato per consentire alle applicazioni client di aggiornare la topologia prima di subire un arresto forzato del nodo. La topologia è personalizzata per consentire ai client di conoscere la nuova replica. La topologia dimentica anche la replica che verrà rimossa prima della rimozione.
Il nodo di 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 entrata al nodo primario del suo shard. Consente al client del cluster OSS Redis di aggiornare la topologia del cluster 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 cluster sul client del cluster in modo che venga a conoscenza della modifica della replica. I nuovi aggiornamenti della topologia del cluster non visualizzano il nodo di replica che verrà rimosso.
Impostazioni di manutenzione
Con Memorystore, puoi personalizzare le pianificazioni della manutenzione in modo da allinearle alle esigenze della tua applicazione e ridurre al minimo le interruzioni. Per farlo, configura un periodo di manutenzione per il cluster.
I periodi di manutenzione vengono impostati per cluster Memorystore e consentono le seguenti opzioni di configurazione:
- Giorno della settimana. Indica il giorno in cui viene eseguita la manutenzione.
- Ora di inizio. L'ora in cui inizia la manutenzione.
La durata del periodo di manutenzione è di 1 ora. Tieni presente che, in alcuni casi, la manutenzione potrebbe protrarsi oltre il periodo selezionato.
Dopo aver configurato una periodo di manutenzione per un cluster, Memorystore for Redis Cluster pianifica la manutenzione automatica in futuro in base alle preferenze che hai impostato per le finestre di manutenzione.
Periodi di manutenzione predefiniti
Se non imposti un periodo di manutenzione, Memorystore aggiornerà il cluster in uno dei seguenti periodi di tempo in base al fuso orario del cluster:
Finestra settimanale (da lunedì a venerdì). Dalle 22:00 alle 06:00
Finestra del fine settimana. Venerdì dalle 22:00 a lunedì alle 06:00
Esempio di manutenzione
In qualità di sviluppatore che gestisce un servizio di carrello degli acquisti presso un rivenditore, hai la responsabilità di supervisionare un ambiente di produzione che include un'istanza di Memorystore for Redis Cluster. Per garantire un rendimento ottimale durante la manutenzione, devi pianificarla quando il cluster registra un traffico minimo, in genere intorno a mezzanotte di domenica.
In questo caso, puoi impostare il periodo di manutenzione del cluster di produzione su:
- Giorno della settimana. Domenica.
- Ora di inizio. 01:00.
Notifiche relative alla manutenzione prevista
Per assicurarti di rimanere informato sugli eventi di manutenzione sul tuo cluster, puoi configurare le notifiche email relative alla manutenzione imminente almeno una settimana prima della data prevista. Queste notifiche avranno come oggetto "Upcoming maintenance for your Cloud Memorystore instance [your-cluster-name]".
Viene inviata una notifica anche all'inizio della manutenzione del cluster. L'oggetto dell'email sarà "Maintenance
is undergoing for your Cloud Memorystore instance [your-cluster-name]".
Al termine della manutenzione, viene inviata una notifica di completamento. Il titolo dell'email è "Completed Maintenance
for your Cloud Memorystore instance [your-cluster-name]".
Se Memorystore riprogramma la manutenzione, riceverai un'email che ti informa dell'annullamento della manutenzione. L'oggetto di questa email sarà "Canceled maintenance for your Cloud Memorystore instance [your-cluster-name]".
Devi attivare la ricezione di queste notifiche di manutenzione. Per registrarti alle notifiche di manutenzione, segui i passaggi descritti di seguito:
Per ricevere notifiche di manutenzione da Memorystore, assicurati di aver completato i passaggi precedenti almeno una settimana prima dell'aggiornamento di manutenzione pianificato per la tua istanza. In caso contrario, il sistema non avrà tempo sufficiente per avvisarti della manutenzione imminente.
Le notifiche verranno inviate all'indirizzo email associato al tuo Account Google. Non è possibile configurare un alias email personalizzato (ad esempio, un alias email del team). Al momento, non supportiamo l'invio di notifiche a un indirizzo email diverso.
Se ti abboni alle notifiche di manutenzione, riceverai avvisi per tutti i cluster Memorystore con manutenzione pianificata all'interno di un progetto specificato. Se hai effettuato l'iscrizione, riceverai una notifica separata per ogni cluster.
Per istruzioni su come trovare la manutenzione pianificata, vedi Trovare la manutenzione pianificata.
Ripianificazione della manutenzione
Nello scenario in cui sono configurati periodi di manutenzione per il cluster, questa sezione fornisce linee guida su come riprogrammare la manutenzione. Ad esempio, se è previsto il lancio di un nuovo servizio durante il periodo di manutenzione corrente, potresti voler posticipare il periodo di manutenzione di alcuni giorni dopo il lancio.
Puoi ripianificare la manutenzione entro 14 giorni dall'orario originariamente pianificato. Nell'ambito della ripianificazione della manutenzione, scegli una delle seguenti opzioni:
- Aggiorna ora: anziché attendere il periodo di manutenzione pianificato, puoi applicare immediatamente gli aggiornamenti al cluster.
- Giorno e ora personalizzati: scegli un orario qualsiasi entro 14 giorni dall'orario di manutenzione originariamente pianificato.
Durante la riprogrammazione della manutenzione, si applicano le seguenti limitazioni:
- Se manca meno di un'ora all'orario di manutenzione programmato, non puoi ripianificare la manutenzione.
- In caso di riprogrammazione riuscita, viene inviata un'email di conferma dell'annullamento della manutenzione precedente e una nuova notifica di manutenzione imminente con la pianificazione aggiornata.
Per istruzioni sulla riprogrammazione della manutenzione, vedi Ripianificare la manutenzione.
Domande frequenti
Questa sezione contiene le domande frequenti sulla manutenzione di Memorystore for Redis Cluster.
Come si fa a sapere quando è pianificata la manutenzione del cluster?
Per sapere quando è pianificata la manutenzione del tuo cluster, ti consigliamo di
iscriverti alle notifiche e configurare un periodo di manutenzione. Puoi anche
controllare manualmente il cluster per vedere se il
parametro maintenanceSchedule viene visualizzato nella risposta.
Quando Memorystore for Redis Cluster ti avvisa della manutenzione imminente?
Se ti abboni alle notifiche di manutenzione e imposti un periodo di manutenzione, Memorystore for Redis Cluster ti invia una notifica via email almeno una settimana prima di un evento di manutenzione.
Per quanto tempo puoi rimandare la manutenzione?
Dopo aver pianificato la manutenzione del cluster, puoi avviare l'aggiornamento immediatamente o posticiparlo fino a due settimane dopo la data e l'ora di manutenzione originariamente pianificate.
Ad esempio, se pianifichi la manutenzione per l'11 ottobre alle 23:15, puoi rinviarla fino al 25 ottobre alle 23:15. Se non intervieni, la manutenzione viene eseguita alla data e all'ora pianificate.
Per saperne di più, consulta Ripianificare la manutenzione.
Quali best practice garantiscono un'esperienza di aggiornamento della manutenzione senza problemi?
Per garantire un'esperienza di aggiornamento della manutenzione senza problemi, ti consigliamo di procedere come segue:
- Segui le istruzioni per configurare l'applicazione client.
- Imposta il periodo di manutenzione in un giorno e un orario in cui il cluster registra un traffico minimo (ad esempio, la domenica a mezzanotte).
- Attiva le notifiche di manutenzione. Di conseguenza, Memorystore for Redis Cluster ti invia una notifica via email almeno sette giorni prima che venga pianificato un aggiornamento di manutenzione per il tuo cluster.
- Se non hai un'ora a basso impatto o senza impatto per l'utilizzo dell'applicazione, utilizza l'impostazione predefinita del servizio per le implementazioni graduali. Questo valore predefinito contiene le best practice per gli aggiornamenti della manutenzione. Per saperne di più, consulta Manutenzione pianificata.
Quando ti consigliamo di applicare immediatamente un aggiornamento di manutenzione?
Puoi applicare immediatamente un aggiornamento di manutenzione a un cluster di test per vedere l'impatto dell'aggiornamento sulla tua applicazione. Puoi osservare l'impatto di questo aggiornamento. Se si verificano problemi con l'aggiornamento, puoi posticipare la manutenzione dei cluster di produzione finché non risolvi i problemi.
Se il giorno e l'ora attuali sono adatti al tuo cluster e prevedi un carico elevato sul tuo cluster in futuro, puoi eseguire l'aggiornamento di manutenzione immediatamente.
Gli aggiornamenti di manutenzione vengono sempre completati all'interno del periodo di manutenzione?
Memorystore for Redis Cluster avvia un aggiornamento di manutenzione all'interno della finestra di manutenzione che specifichi. Memorystore for Redis Cluster di solito completa l'aggiornamento all'interno della finestra, ma non sempre.
Puoi disattivare la manutenzione o programmarla prima su determinati cluster?
Non puoi disattivare la manutenzione o controllare l'ordine di manutenzione dei tuoi cluster. Tuttavia, dopo aver ricevuto la notifica di manutenzione iniziale, puoi riprogrammare la manutenzione per posticiparla fino a due settimane.
Passaggi successivi
- Visualizza le autorizzazioni necessarie per gestire le finestre di manutenzione per il cluster.