Questa pagina spiega come Memorystore for Redis Cluster esegue la manutenzione sui cluster. Fornisce inoltre informazioni e suggerimenti di configurazione di cui le tue applicazioni client devono essere a conoscenza per sfruttare il design di manutenzione senza tempi di inattività di Memorystore for Redis Cluster. Questi suggerimenti si applicano sia ai cluster ad alta affidabilità sia ai cluster senza repliche. Tuttavia, consigliamo vivamente la configurazione ad alta affidabilità per tutti i casi d'uso di produzione.
Memorystore for Redis Cluster aggiorna regolarmente i cluster 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 avere un impatto pari a zero 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 costantemente le vulnerabilità di sicurezza appena identificate nel sistema operativo. Una volta rilevate, applichiamo 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à dei cluster oltre a quelle fornite da Redis.
Memorystore for Redis Cluster non aggiorna automaticamente i cluster per ogni release di manutenzione. Per determinare il momento migliore per pianificare la manutenzione completa, Google Cloud valuta periodicamente gli aggiornamenti disponibili. Se hai bisogno di una versione di manutenzione specifica prima, puoi utilizzare la manutenzione self-service dopo che è disponibile un aggiornamento. Per ulteriori informazioni sulle versioni di manutenzione, inclusi i numeri e i dettagli delle versioni di manutenzione, consulta i changelog di manutenzione di Memorystore for Redis Cluster.
Configura 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 Redis OSS in base alle indicazioni riportate in Best practice per i client Redis 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 scale out, modifiche al conteggio delle repliche) durante l'esecuzione di un workload 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, il rilevamento di nuovi nodi e la funzionalità di rimozione dei nodi esistenti. I test aiutano a verificare che il client 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 ottenuta utilizzando le funzionalità di reindirizzamento delle richieste del protocollo Redis con i seguenti meccanismi di Memorystore:
- Failover coordinato senza perdita di dati.
- Rimozione controllata dei nodi per consentire ai client di aggiornarsi alla 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 programmata. Per informazioni sull'impatto di eventi non pianificati come errori hardware, consulta 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 progressivamente crescente e a una velocità che consente di rilevare gli errori in tempo utile per mitigare 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 considerarlo riuscito e procedere) sono integrati nel parco risorse di cluster Memorystore su scala di servizio. Inoltre, i tempi di bake 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 affidabilità, viene aggiornato al massimo un dominio/zona di errore alla volta per garantire che uno shard del cluster, incluse sia le repliche principali che quelle secondarie, abbia un'alta affidabilità durante l'aggiornamento. Inoltre, vengono aggiornati solo alcuni nodi Redis alla volta. Gli aggiornamenti utilizzano un meccanismo del ciclo di vita con creazione prima dell'eliminazione per massimizzare la stabilità del cluster. Questa strategia offre i maggiori vantaggi quando si aggiorna un cluster 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 del ciclo di vita con creazione prima dell'eliminazione
Un cluster Redis ha più shard. Ogni shard ha un nodo principale e zero o più nodi di replica. Memorystore utilizza la seguente procedura per aggiornare qualsiasi nodo Redis principale o di replica esistente in uno shard:
- Memorystore for Redis Cluster aggiunge prima una replica completamente nuova con l'ultimo aggiornamento software allo shard. Memorystore crea un nodo completamente nuovo, anziché aggiornare un nodo esistente, per garantire che la capacità di 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 di creazione prima della distruzione aiuta a mantenere la capacità di provisioning del cluster, rispetto a un tipico deployment in sequenza che esegue l'aggiornamento in loco, ma comporta un'interruzione della disponibilità (e talvolta 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 principale esistente dello shard.
Passaggio 1: aggiungi una replica Redis
Il primo passaggio del meccanismo di creazione prima della distruzione consiste nell'aggiungere un nodo di replica con il software più recente utilizzando il meccanismo OSS Redis di sincronizzazione completa per copiare i dati dal nodo principale al nodo di replica. Questo viene fatto tramite il fork di un processo figlio e l'utilizzo della replica senza disco per eseguire il bootstrap della replica. Memorystore for Redis Cluster supporta la replica senza disco. A meno che 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 aiuta 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, quindi 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 principale, offrendo una finestra per garantire che la replica esistente sia sincronizzata al 100% con il nodo principale.
- La replica completa il processo 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 selezionato utilizzando il protocollo del cluster Redis OSS. Tutte le nuove richieste inviate al nodo di replica precedente continuano a essere reindirizzate al nuovo nodo principale.
- Il client compatibile con il cluster Redis aggiorna la topologia in memoria. Apprende l'indirizzo del nuovo endpoint principale e non richiede più reindirizzamenti.
I failover coordinati dovrebbero richiedere in genere 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 trasferiti alle repliche. Le dimensioni del cluster possono influire sulla convergenza tra i nodi principali, il che influisce sul processo decisionale relativo all'elezione del nuovo nodo principale.
Passaggio 3: rimuovi la replica Redis
L'ultimo passaggio del meccanismo di creazione prima della distruzione consiste nel rimuovere il nodo di replica sul software precedente. Una rimozione improvvisa dei nodi avrebbe un impatto sulle applicazioni client, perché i client memorizzano nella cache le informazioni sugli endpoint e la topologia del cluster. Memorystore for Redis Cluster è stato progettato per rimuovere una replica Redis in modo controllato, per consentire alle applicazioni client di aggiornare la propria topologia prima di 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 che venga rimossa.
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 principale del relativo shard. In questo modo, il client del cluster può aggiornare la topologia del cluster e scoprire 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 attiva un aggiornamento della topologia del cluster sul client del cluster in modo che apprenda la modifica della replica. I nuovi aggiornamenti della topologia del cluster non vedono il nodo di replica che verrà rimosso.
Impostazioni di manutenzione
Con Memorystore, puoi personalizzare le pianificazioni di manutenzione in base 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 di inizio della manutenzione.
La durata del periodo di manutenzione è di 1 ora. Tieni presente che, in alcuni casi, la manutenzione potrebbe superare la finestra selezionata.
Dopo aver configurato un periodo di manutenzione per un cluster, Memorystore for Redis Cluster pianifica la manutenzione automatica in futuro in base alle preferenze impostate per i periodi di manutenzione.
Periodi di manutenzione predefiniti
Se non imposti un periodo di manutenzione, Memorystore aggiornerà il cluster in una delle seguenti finestre temporali in base al fuso orario del cluster:
Finestra nei giorni feriali (da lunedì a venerdì). Dalle 22:00 alle 06:00
Finestra del fine settimana. Da venerdì alle 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 cluster. Per garantire prestazioni ottimali durante la manutenzione, vuoi pianificarla quando il cluster registra un traffico minimo, che in genere si verifica intorno alla mezzanotte della 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 imminente
Per assicurarti di rimanere al corrente degli eventi di manutenzione sul tuo cluster, puoi configurare notifiche via email relative alla manutenzione imminente almeno una settimana prima della data pianificata. Queste notifiche avranno come oggetto "Upcoming maintenance for your Cloud Memorystore instance [your-cluster-name]".
Viene inviata una notifica anche quando inizia la 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 ripianifica la manutenzione, riceverai un'email
di notifica della manutenzione annullata. La riga dell'oggetto di questa email
sarebbe "Canceled maintenance for your Cloud Memorystore instance [your-cluster-name]".
Per ricevere queste notifiche di manutenzione, devi attivare l'opzione. Per registrarti alle notifiche di manutenzione, segui questi passaggi:
Per ricevere notifiche di manutenzione da Memorystore, assicurati di aver completato questi passaggi almeno una settimana prima dell'aggiornamento di manutenzione pianificato per il tuo cluster. In caso contrario, Memorystore for Redis Cluster non avrà tempo sufficiente per informarti della manutenzione imminente.
Memorystore for Redis Cluster invia notifiche all'indirizzo email associato al tuo Account Google. Non puoi 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 iscrivi 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, consulta Trova la manutenzione pianificata.
Ripianificazione della manutenzione
Se per il tuo cluster sono configurati periodi di manutenzione, questa sezione fornisce linee guida su come ripianificare la manutenzione. Ad esempio, se il lancio di un nuovo servizio è pianificato durante il periodo di manutenzione corrente, potresti voler posticipare il periodo di manutenzione di qualche giorno dopo il lancio.
Puoi ripianificare la manutenzione entro 14 giorni dall'orario originariamente pianificato. Nell'ambito della nuova pianificazione 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 ripianificazione della manutenzione, si applicano le seguenti limitazioni:
- Se manca meno di un'ora all'orario di manutenzione pianificato, non puoi ripianificare la manutenzione.
- Una volta completata la riprogrammazione, viene inviata un'email di conferma dell'annullamento della manutenzione precedente e una nuova notifica di manutenzione imminente con la pianificazione aggiornata.
Per istruzioni su come ripianificare la manutenzione, consulta Ripianifica la manutenzione.
Domande frequenti
Questa sezione contiene le domande frequenti (FAQ) sulla manutenzione di Memorystore for Redis Cluster.
Come fai a sapere quando è pianificata la manutenzione del tuo 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 invia una notifica sulla manutenzione imminente?
Se ti iscrivi 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 posso posticipare la manutenzione?
Dopo aver pianificato la manutenzione del cluster, puoi avviare l'aggiornamento del cluster immediatamente o posticiparlo fino a due settimane dalla data e dall'ora di manutenzione originariamente pianificate.
Ad esempio, se pianifichi la manutenzione per l'11 ottobre alle 23:15, puoi posticiparla 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 Ripianifica la manutenzione.
Quali best practice consentono di eseguire un aggiornamento di manutenzione senza problemi?
Per garantire un'esperienza di aggiornamento di manutenzione senza problemi, ti consigliamo di procedere come segue:
- Segui le istruzioni per configurare l'applicazione client.
- Imposta il periodo di manutenzione su un giorno e un'ora 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 della pianificazione di 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 il valore predefinito del servizio per le implementazioni graduali. Questa impostazione predefinita contiene best practice per gli aggiornamenti di manutenzione. Per saperne di più, consulta Manutenzione pianificata.
Quando 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 rimandare la manutenzione dei cluster di produzione fino alla risoluzione dei problemi.
Se il giorno e l'ora correnti sono adatti al tuo cluster e prevedi un carico elevato sul 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 del periodo di manutenzione specificato. Memorystore for Redis Cluster di solito completa l'aggiornamento all'interno della finestra, ma non sempre.
Puoi disattivare la manutenzione o pianificarla prima su determinati cluster?
Non puoi disattivare la manutenzione o controllarne l'ordine per i 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 i periodi di manutenzione del cluster.