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 ai cluster 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 influire 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 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.
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 il 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 della connessione in background.
- Testa l'applicazione client con una serie di operazioni di aggiornamento (ad esempio fare lo scale in 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 di ciclo di vita di deployment graduale e creazione prima dell'eliminazione per evitare qualsiasi impatto sui tempi di inattività causato dalla 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 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 disponibilità, al massimo un dominio di errore/zona viene aggiornato in un determinato momento per garantire che uno shard del cluster, inclusi sia il nodo primario che 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 create-before-destroy
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 di creazione prima dell'eliminazione 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 di creazione prima dell'eliminazione 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 secondario e viene sfruttata la replica senza dischi per eseguire il bootstrap della 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 da aggiornare è 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 primaria.
- 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 principale.
- 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 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 primario del suo shard. Consente al client del cluster OSS Redis di aggiornare la topologia del cluster e 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 che siano in linea con le 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.
Una volta configurato un periodo di manutenzione per un'istanza del cluster, la manutenzione automatica futura verrà pianificata 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:
Finestra dei giorni feriali (da lunedì a venerdì). Dalle 22:00 alle 06:00
Finestra del fine settimana. Venerdì, dalle 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'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 posticipare il periodo di manutenzione di qualche giorno dopo il lancio.
Puoi riprogrammare la manutenzione tutte le volte che vuoi entro due settimane dall'ora originariamente pianificata. Durante la riprogrammazione, puoi scegliere una delle seguenti opzioni:
- Aggiorna ora. Anziché attendere la periodo di manutenzione pianificata, puoi applicare immediatamente gli aggiornamenti al cluster.
- Giorno e ora personalizzati. In questo modo puoi scegliere un orario specifico entro due settimane 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
Di seguito sono riportate alcune domande frequenti sulle norme di manutenzione per Memorystore for Redis Cluster:
Come faccio a sapere quando è pianificata la manutenzione del mio cluster?
Ti consigliamo di iscriverti alle notifiche e di configurare un periodo di manutenzione per sapere quando è pianificata la manutenzione per la tua istanza. Puoi anche eseguire il controllo manualmente utilizzando Trova manutenzione pianificata per verificare se il campo maintenance_schedule è impostato nella risposta.
Quando ricevo una notifica della manutenzione imminente?
Se hai eseguito la registrazione per ricevere le notifiche di manutenzione e hai impostato un periodo di manutenzione, riceverai un avviso via email almeno una settimana prima di un evento di manutenzione.
Per quanto tempo posso posticipare la manutenzione?
Una volta pianificata la manutenzione per il cluster, puoi avviare immediatamente l'aggiornamento per l'istanza o posticiparlo fino a due settimane dopo l'orario di manutenzione originariamente pianificato. Ad esempio, se la manutenzione è pianificata per l'11 ottobre alle 23:15, puoi posticiparla al 25 ottobre alle 23:15. Se non intervieni, la manutenzione verrà applicata all'ora pianificata.
Per maggiori dettagli, vedi Ripianificazione della manutenzione.
Quali best practice devo seguire per un'esperienza di aggiornamento della manutenzione senza problemi?
Ti consigliamo di eseguire le seguenti operazioni per garantire un'esperienza di aggiornamento della manutenzione senza problemi:
- Segui le istruzioni per configurare l'applicazione client.
- Devi impostare il periodo di manutenzione in modo che la manutenzione non venga applicata nelle ore di picco di utilizzo di Redis.
- Devi attivare le notifiche di manutenzione per ricevere un avviso via email almeno sette giorni prima che venga pianificato un aggiornamento di manutenzione per la tua istanza.
- Se non hai un'ora di basso impatto o nessun impatto per l'utilizzo dell'applicazione, ti consigliamo di utilizzare l'impostazione predefinita del servizio di implementazioni graduali, che include le best practice. Per saperne di più, consulta Manutenzione pianificata.
Quando devo applicare immediatamente la manutenzione?
Uno scenario in cui potresti applicare immediatamente l'aggiornamento di manutenzione è un cluster di test per vedere l'impatto sull'applicazione. In questo modo puoi osservare l'impatto che ha e posticipare la manutenzione dei cluster di produzione in base alle necessità/autorizzazioni.
Puoi anche pianificare immediatamente la manutenzione se l'ora corrente è adatta al tuo cluster e prevedi un carico elevato sul cluster in futuro.
Gli aggiornamenti di manutenzione vengono sempre completati all'interno del periodo di manutenzione?
Un aggiornamento inizia all'interno del periodo di manutenzione specificato. L'aggiornamento viene generalmente completato entro la finestra, ma non è garantito.
Posso disattivare la manutenzione o programmarla prima su determinati cluster?
No, non puoi disattivare la manutenzione o controllare l'ordine di manutenzione per i tuoi cluster. Tuttavia, una volta ricevuta la notifica di manutenzione iniziale, puoi ripianificare la manutenzione per posticiparla fino a due settimane.
Passaggi successivi
- Visualizza le autorizzazioni necessarie per gestire i periodi di manutenzione per il cluster Redis.