Questa pagina spiega come Memorystore for Redis Cluster esegue la manutenzione dei cluster. Fornisce inoltre informazioni e consigli di configurazione di cui le applicazioni client devono essere a conoscenza per sfruttare il design di manutenzione senza tempi di inattività di Memorystore for Redis Cluster. Questi consigli si applicano sia ai cluster a disponibilità elevata 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, 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à.
In genere, la manutenzione 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.
Configurare l'applicazione client
Per configurare l'applicazione client in modo da ottenere le migliori prestazioni e la migliore disponibilità possibili durante la manutenzione, segui questi passaggi:
- Utilizza e configura il client del cluster Redis OSS seguendo le indicazioni riportate in Best practice per i client Redis per assicurarti che la manutenzione pianificata non influisca sull'applicazione client. Le configurazioni client consigliate possono evitare i ripristini della connessione 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 del numero di 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, il rilevamento di nuovi nodi e la funzionalità di rimozione dei nodi esistenti. Il test consente di assicurarsi che il client sia configurato correttamente per evitare qualsiasi impatto negativo sull'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 Redis con i seguenti meccanismi di Memorystore:
- Failover coordinato senza perdita di dati.
- Rimozione graduale 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 non pianificati come guasti 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 in aumento progressivo e a una velocità che consente di rilevare gli 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 tutto il parco risorse di cluster Memorystore su scala di servizio. Inoltre, i tempi di bake sono integrati all'interno del 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à, al massimo un dominio di errore/zona viene aggiornato in un determinato momento per assicurarsi che uno shard del cluster, inclusi sia il nodo primario sia le repliche, abbia un'alta affidabilità durante l'aggiornamento. Inoltre, in un determinato momento vengono aggiornati solo alcuni nodi Redis. 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 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 di 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é aggiornare un nodo esistente, per garantire che la capacità di cui hai 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.
- Memorystore rimuove la replica che utilizza il software precedente.
- La procedura viene ripetuta per ogni nodo del cluster.
La strategia di creazione prima dell'eliminazione consente di mantenere la capacità di cui è stato eseguito il provisioning del cluster, rispetto a un deployment in sequenza tipico che aggiorna 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 primario esistente dello shard.
Passaggio 1: aggiungi la replica Redis
Il primo passaggio del meccanismo di creazione prima dell'eliminazione consiste nell'aggiungere un nodo di replica con l'ultimo software utilizzando il meccanismo Redis OSS di sincronizzazione completa per copiare i dati dal nodo primario al nodo di replica. Questa operazione viene eseguita creando un fork di un processo figlio e sfruttando la replica senza disco 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 consente di 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 primario coordinato
Se il nodo Redis che deve essere aggiornato è un nodo primario, Memorystore esegue innanzitutto 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 assicurarsi che la replica esistente sia sincronizzata al 100% con il nodo primario.
- La replica completa la procedura di elezione per assumere il ruolo di nodo primario.
- Il nodo primario precedente, ora una replica, sblocca le richieste esistenti e le reindirizza al nodo primario appena eletto utilizzando il protocollo del cluster Redis OSS. 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 primario e non richiede più reindirizzamenti.
In genere, i failover coordinati richiedono decine di millisecondi. Tuttavia, le dimensioni totali del cluster possono aumentare la latenza del 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. Una rimozione improvvisa del 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 che sia graduale 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 di aggiornare la topologia del cluster e di conoscere i nuovi endpoint di replica. Se il client tenta di raggiungere un nodo rimosso dopo il periodo di svuotamento, il tentativo non riesce, il che a sua volta 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 visualizzano 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, puoi configurare 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 superare il periodo selezionato.
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 uno dei seguenti periodi di tempo in base al fuso orario del cluster:
Periodo nei giorni feriali (dal lunedì al venerdì). Dalle 22:00 alle 06:00
Periodo nel fine settimana. Dal venerdì alle 22:00 al 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, 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 imminente
Per rimanere informato sugli eventi di manutenzione del cluster, puoi configurare le notifiche via email relative alla manutenzione imminente almeno una settimana prima della pianificazione. Queste notifiche avranno la riga dell'oggetto "Upcoming maintenance for your Cloud Memorystore instance [your-cluster-name]".
Viene inviata una notifica anche all'inizio della manutenzione del cluster. La
riga dell'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 della manutenzione annullata. La riga dell'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 attivare le notifiche di manutenzione:
Per ricevere notifiche di manutenzione da Memorystore, assicurati di aver completato questi passaggi almeno una settimana prima dell'aggiornamento di manutenzione pianificato per il 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 abboni alle notifiche di manutenzione, riceverai avvisi per tutti i cluster Memorystore con manutenzione pianificata all'interno di un progetto specificato. Se hai attivato l'abbonamento, riceverai una notifica separata per ogni cluster.
Per istruzioni su come trovare la manutenzione pianificata, consulta Trovare la manutenzione pianificata.
Ripianificare la manutenzione
Se per il cluster sono configurati periodi di manutenzione, questa sezione fornisce indicazioni 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 riprogrammare la manutenzione entro 14 giorni dall'ora originariamente pianificata. Nell'ambito della riprogrammazione 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'ora qualsiasi entro 14 giorni dall' ora di manutenzione originariamente pianificata.
Durante la riprogrammazione della manutenzione, si applicano le seguenti limitazioni:
- Se manca meno di un'ora all'ora di manutenzione pianificata corrente, non puoi riprogrammare la manutenzione.
- Al termine della 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 riprogrammare la manutenzione, consulta Ripianificare la manutenzione.
Domande frequenti
Questa sezione contiene le domande frequenti sulla manutenzione di Memorystore for Redis Cluster.
Come faccio a sapere quando è pianificata la manutenzione del mio cluster?
Per sapere quando è pianificata la manutenzione del cluster, ti consigliamo di abbonarti alle notifiche e di configurare un periodo di manutenzione. Puoi anche
controllare manualmente il cluster per verificare se il
maintenanceSchedule parametro viene visualizzato nella risposta.
Quando Memorystore for Redis Cluster mi 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 posso posticipare la manutenzione?
Dopo aver pianificato la manutenzione del cluster, puoi avviare immediatamente l'aggiornamento del cluster o posticiparlo fino a due settimane dalla data e 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 esegui alcuna azione, 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:
- Seguire le istruzioni per configurare l'applicazione client.
- Impostare il periodo di manutenzione su un giorno e un'ora in cui il cluster registra un traffico minimo (ad esempio, la domenica a mezzanotte).
- Attivare 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 cluster.
- Se non hai un'ora di impatto basso o nullo per l'utilizzo dell'applicazione, utilizza l'impostazione predefinita del servizio per i rollout graduali. Questa impostazione predefinita contiene le 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 sull'applicazione. Puoi osservare l'impatto di questo aggiornamento. Se si verificano problemi con l'aggiornamento, puoi posticipare la manutenzione dei cluster di produzione fino a quando non li risolvi.
Se il giorno e l'ora correnti sono adatti al tuo cluster e prevedi un carico elevato sul cluster in futuro, puoi eseguire immediatamente l'aggiornamento di manutenzione.
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. In genere, Memorystore for Redis Cluster completa l'aggiornamento all'interno del periodo, ma non sempre.
Posso disattivare la manutenzione o pianificare la manutenzione prima su determinati cluster?
Non puoi disattivare la manutenzione o controllare l'ordine di manutenzione dei 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.