• Database›
  • Amazon ElastiCache›
  • Pagina di assistenza agli aggiornamenti del servizio e alla manutenzione gestita da Amazon ElastiCache

Pagina di assistenza agli aggiornamenti del servizio e alla manutenzione gestita da Amazon ElastiCache

Panoramica

Aggiorniamo frequentemente il nostro parco Amazon ElastiCache con patch e aggiornamenti applicati alle istanze in modo ottimizzato. Lo facciamo in uno dei seguenti due modi:

(a) manutenzione gestita continua e (b) aggiornamenti del servizio. Queste operazioni di manutenzione e di aggiornamento del servizio sono necessarie per l'applicazione di aggiornamenti intesi a rafforzare sicurezza, affidabilità e prestazioni.

La manutenzione gestita continua avviene saltuariamente e direttamente nelle tue finestre di manutenzione senza che sia necessaria alcuna azione da parte tua.
Gli aggiornamenti del servizio ti offrono la libertà di poterli applicare autonomamente. Viene loro assegnato un orario ed è possibile spostarli all'interno della finestra di manutenzione così da permetterci di eseguirli una volta superata la loro data di scadenza.

Ti offriamo l'opzione di gestire personalmente gli aggiornamenti in qualsiasi momento, prima della finestra di manutenzione pianificata. Quando sei tu a gestire l'aggiornamento, l'istanza riceve l'aggiornamento del sistema operativo quando il nodo viene rilanciato e la finestra di manutenzione programmata viene annullata.

Argomenti della pagina

Aggiornamenti del servizio
23
Aggiornamenti della manutenzione continua gestita
11

Aggiornamenti del servizio

Gli aggiornamenti del servizio sono una funzionalità di Amazon ElastiCache che consente di applicare alcuni aggiornamenti del servizio a tua discrezione. Questi aggiornamenti possono essere di due tipi: patch di sicurezza o aggiornamenti del software secondari. Questi aggiornamenti contribuiscono a rafforzare la sicurezza, l'affidabilità e le prestazioni dei tuoi cluster.

Il vantaggio di questi aggiornamenti del servizio consiste nel poter scegliere il momento in cui applicarli (ad esempio, puoi ritardare un aggiornamento del servizio quando c'è un importante evento aziendale che richiede la disponibilità 24x7 dei cluster ElastiCache).

Per i dettagli di ogni aggiornamento del servizio, fai riferimento al valore dell'attributo "Descrizione aggiornamento".

Quando gli aggiornamenti del servizio applicabili ai cluster in uso saranno disponibili, lo comunicheremo utilizzando diversi canali tra cui la console Amazon ElastiCache, l'e-mail, Amazon Simple Notification Service (SNS), AWS Personal Health Dashboard ed Eventi Amazon CloudWatch.

Gli aggiornamenti disponibili tramite la nostra manutenzione gestita continua sono diversi da quelli offerti tramite gli aggiornamenti del servizio. Gli aggiornamenti applicati tramite la manutenzione gestita continua sono programmati direttamente nelle tue finestre di manutenzione senza che sia necessaria alcuna azione da parte tua. Agli aggiornamenti del servizio è assegnato un orario e puoi decidere quando applicarli entro la "Data limite consigliata per l'applicazione". Se entro questa data questi aggiornamenti non sono stati applicati, ElastiCache potrebbe programmarli nella tua finestra di manutenzione.

Se il cluster ElastiCache partecipa a un programma di conformità HIPAA, PCI o FedRAMP, per rispettare la conformità è necessario applicare gli aggiornamenti del servizio entro la “Data limite consigliata per l'applicazione”. Per maggiori informazioni, consultare la sezione Aggiornamenti di sicurezza self-service per la conformità.

Per altri cluster, ti consigliamo di applicare gli aggiornamenti del servizio seguendo i ritmi della tua azienda. Se non sei in grado di applicare un aggiornamento del servizio entro la "Data limite consigliata per l'applicazione", potrai comunque farlo fino alla "Data di scadenza dell'aggiornamento". Tuttavia, la “Data di scadenza dell'aggiornamento” può variare in qualsiasi momento, a seconda della disponibilità di nuovi aggiornamenti.

Quando tu o Amazon ElastiCache applicate un aggiornamento del servizio a uno o più cluster, l'aggiornamento viene applicato a non più di un nodo alla volta all'interno di ogni partizione finché tutti i cluster selezionati non sono aggiornati. I nodi che vengono aggiornati subiranno un downtime di pochi secondi, mentre il resto del cluster continuerà a servire il traffico.

  • Non sarà apportata nessuna modifica alla configurazione del cluster.
  • Noterai un ritardo nei parametri di CloudWatch, che verranno recuperati il prima possibile.

Gli aggiornamenti del servizio sono applicati nello stesso modo degli "Aggiornamenti continui di manutenzione gestita", attraverso la sostituzione dei nodi. Si prega di fare riferimento alle seguenti domande nella sezione Aggiornamenti continui di manutenzione gestita in questa pagina per i dettagli su come l'aggiornamento viene applicato e su come preparare la tua applicazione per minimizzare l'impatto.

  • Quali effetti ha la sostituzione di un nodo sulle applicazioni?
  • Quali best practice sono consigliate per procedere a un'agevole sostituzione dei nodi e ridurre al minimo la perdita di dati?
  • Quali best practice per la configurazione del client dovrei seguire per minimizzare l'interruzione delle operazioni dell'applicazione durante la manutenzione?

Sì, il nodo è sostituito da un nuovo nodo vuoto. I contenuti della cache non saranno più presenti e inizieranno da capo.

Puoi determinare se è possibile disattivare un aggiornamento del servizio verificando il valore dell'attributo "Aggiornamento automatico dopo la data di scadenza". Se il valore dell'attributo "Aggiornamento automatico dopo la data di scadenza" di un aggiornamento del servizio è "no", puoi disattivare l'aggiornamento. Tuttavia se il valore dell'attributo "Aggiornamento automatico dopo la data di scadenza" di un aggiornamento del servizio è "sì" e la "Applicazione per data" consigliata è passata, ElastiCache pianificherà in automatico l'aggiornamento del servizio di tutti i cluster rimanenti per la finestra di manutenzione successiva. Questo aggiornamento automatico del servizio verrà pianificato prima della "Data di scadenza dell'aggiornamento" e riceverai una notifica una settimana prima dell'aggiornamento con l'ora pianificata. Consigliamo vivamente di applicare gli aggiornamenti di sicurezza anche se è possibile disattivarli.  Se scegli di applicare l'aggiornamento del servizio ai cluster rimanenti prima della finestra di manutenzione, ElastiCache non riapplicherà l'aggiornamento del servizio durante la finestra di manutenzione.

L'obiettivo degli aggiornamenti del servizio è offrirti la libertà di applicarli quando vuoi. I cluster che non partecipano ai programmi di conformità supportati da ElastiCache possono scegliere di non applicare gli aggiornamenti o applicarli con una frequenza ridotta durante l'anno. Questo è vero solamente quando il valore dell'attributo "Auto-aggiornamento dopo la data di scadenza" di un aggiornamento del servizio è "no". Per maggiori informazioni, vai a Posso evitare gli aggiornamenti del servizio?

No, gli aggiornamenti del servizio e gli aggiornamenti della manutenzione gestita continua applicati direttamente da Amazon ElastiCache durante le finestre di manutenzione dei tuoi cluster sono reciprocamente esclusivi.

Una lista completa degli attributi e delle rispettive descrizioni è disponibile in Applicazione degli aggiornamenti self-service.

Per capire quando è bene applicare gli aggiornamenti del servizio disponibili, puoi fare riferimento all'attributo dell'aggiornamento del servizio "Gravità", che ha i valori seguenti (in ordine di priorità):

1. critico: è consigliato applicarlo immediatamente (entro 14 giorni o prima)
2. importante: è consigliato applicarlo non appena consentito dal tuo flusso aziendale (entro 30 giorni o prima)
3. medio: è consigliato applicarlo entro 60 giorni o prima
4. basso: è consigliato applicarlo entro 90 giorni o prima

Per maggiori informazioni, consulta la nostra documentazione pubblica, Applicazione degli aggiornamenti.

La disponibilità dipende dall'importanza degli aggiornamenti del servizio.

Questo attributo mostra se il tuo cluster è stato aggiornato entro la "Data limite consigliata per l'applicazione". Se un aggiornamento del servizio è applicato dopo la “Data limite consigliata per l'applicazione”, l'attributo “Service Update SLA Met” è impostato su “no”.

Questa informazione è importante per i cluster di Amazon ElastiCache che partecipano ai programmi di conformità HIPAA, PCI e FedRAMP. Per maggiori informazioni, consultare la sezione Aggiornamenti di sicurezza self-service per la conformità.

Sì. Salvo se indicato altrimenti nell'attributo "Descrizione", gli aggiornamenti del servizio sono sempre cumulativi: se dimentichi di applicarli entro la "Data di scadenza dell'aggiornamento", questi saranno inclusi nell'aggiornamento del servizio successivo. Gli aggiornamenti del servizio del tipo "sicurezza" rientrano in questa categoria cumulativa.

No, gli aggiornamenti del servizio sono applicati a livello del cluster. Se annulli un aggiornamento in corso, alcuni nodi di uno stesso cluster potrebbero essere aggiornati mentre altri no. In questo caso, il cluster continuerà ad apparire nella lista di cluster a cui applicare l'aggiornamento del servizio. Il cluster continuerà a funzionare normalmente.

Questo può succedere in due casi:

(a) Se dimentichi di applicare l'aggiornamento del servizio facoltativo e lo stato attuale dell'aggiornamento è "scaduto". Ecco perché i cluster che partecipano a programmi di conformità devono sempre applicare tutti gli aggiornamenti del servizio.
(b) Se il tuo nodo (o i tuoi nodi) sono sostituiti per qualsiasi altra ragione, ad esempio un evento di manutenzione pianificato o un failover del nodo, Amazon ElastiCache eseguirà il provisioning di un nuovo nodo (o nodi) con gli ultimi aggiornamenti del servizio già inclusi.

In entrambi i casi, il cluster continuerà a funzionare normalmente.

I nuovi nodi contengono tutti gli aggiornamenti del servizio applicabili, quindi puoi sostituire manualmente i nodi esistenti che non sono stati aggiornati per ricevere gli ultimi aggiornamenti.

Sì. Un aggiornamento del servizio può essere applicabile solo a Redis OSS, solo a Memcached oppure sia a Redis OSS che a Memcached. Per capire le specifiche di ogni aggiornamento, è possibile cercare gli attributi “Motore” e “Versione motore” dell'aggiornamento del servizio.

Sì, è possibile rinviare l'aggiornamento del servizio cambiando la finestra di manutenzione. L'aggiornamento programmato sarà applicato al cluster solo se la data programmata corrisponde alla finestra di manutenzione del cluster. Una volta cambiata la finestra di manutenzione e passata la data prevista, l'aggiornamento del servizio sarà riprogrammato alla nuova finestra specificata nelle settimane successive. Riceverai una nuova notifica una settimana prima che la nuova data sia stata raggiunta.

La sicurezza in AWS è una responsabilità condivisa. Si consiglia vivamente di applicare l'aggiornamento al più presto.

Il tuo cluster può far parte di diversi aggiornamenti di servizio. La maggior parte degli aggiornamenti non richiede di applicarli separatamente. L'applicazione di un aggiornamento al tuo cluster segnerà gli altri aggiornamenti come completati, ove applicabile. Potrebbe essere necessario applicare più aggiornamenti allo stesso cluster separatamente se lo stato non passa automaticamente a "completato".

ElastiCache pianificherà l'aggiornamento del servizio sui cluster rimanenti dopo "Applicazione consigliata entro la data" se il valore dell’attributo "Auto-aggiornamento dopo la data passata" è "sì". L'aggiornamento sarà programmato nella finestra di manutenzione del cluster e riceverai una nuova notifica una settimana prima con la data prevista prima che gli aggiornamenti vengano applicati.

L'aggiornamento programmato del servizio sarà applicato ai cluster nello stesso modo degli "Aggiornamenti continui di manutenzione gestita". Si prega di fare riferimento alla seguente sezione per dettagli su come viene applicato l'aggiornamento, come cambiare l'aggiornamento programmato e come preparare la tua applicazione per un aggiornamento programmato per minimizzare l'impatto.

Per mantenere la stabilità del cluster, ElastiCache applica gli aggiornamenti a un solo nodo alla volta all'interno di ogni shard. Se l'aggiornamento del servizio non può essere applicato all'intero cluster in una singola finestra di manutenzione, sarà programmato per continuare in quelle successive. Riceverai nuove notifiche sulla prossima data prevista e potrai prepararti di conseguenza.

Il cliente non può ripristinare l'aggiornamento del servizio una volta iniziato. Se riscontri un problema dopo aver applicato un aggiornamento del servizio, contatta il team del supporto AWS.

Aggiornamenti della manutenzione continua gestita

Questi aggiornamenti sono obbligatori e sono applicati direttamente alle tue finestre di manutenzione senza che sia necessaria alcuna azione da parte tua. Questi aggiornamenti sono separati da quelli offerti dagli aggiornamenti del servizio.

La sostituzione di un nodo viene normalmente completata in pochi secondi. Può, tuttavia, richiedere tempi leggermente più lunghi in alcune configurazioni di istanze o pattern di traffico. Ad esempio, la memoria nei nodi principali di Redis OSS potrebbe non essere sufficiente e il traffico in scrittura potrebbe essere elevato. Quando una replica vuota viene sincronizzata dal nodo principale, questo potrebbe rimanere senza memoria nel tentativo di applicare le richieste di scrittura in entrata e nello stesso momento sincronizzare la replica. In questo caso, il nodo master disconnetterà la replica e riavvierà il processo di sincronizzazione. Per completare il processo, potrebbero essere necessari diversi tentativi. Se i livelli di traffico rimangono elevati, è anche possibile che la replica non riesca a sincronizzarsi.

I nodi Memcached non necessitano di sincronizzazione, perciò la loro sostituzione avviene più rapidamente, a prescindere dalla dimensione.

Per i nodi Redis OSS, il processo di sostituzione è stato progettato per cercare di mantenere i dati esistenti e richiede una replica riuscita. Per i cluster a nodo singolo, ElastiCache avvia una replica dinamicamente, replica i dati, e quindi vi esegue un failover. Per i gruppi di replica composti da più nodi, ElastiCache sostituisce le repliche esistenti e sincronizza i dati a partire dalle repliche principali a quelle nuove. Se l'opzione Multi-AZ con failover automatico è attivata, la sostituzione della replica principale attiverà il failover su una replica di lettura. Per le configurazioni del cluster impostate per utilizzare i relativi client e per quelle non cluster con failover automatico abilitato, le sostituzioni dei nodi pianificate verranno completate mentre il cluster gestisce le richieste di scrittura in entrata. Se l'opzione Multi-AZ è disabilitata, ElastiCache sostituisce la replica principale e in seguito sincronizza i dati da una replica di lettura. Il nodo principale non è disponibile in questo periodo di tempo, il che causa un'interruzione più prolungata nelle operazioni di scrittura.

Per i nodi Memcached, il processo di sostituzione avvia un nuovo nodo vuoto e termina il nodo in uso. Il nuovo nodo non sarà disponibile per un breve periodo di tempo durante la transizione. Superato questo momento, le prestazioni dell'applicazione subiranno rallentamenti mentre i dati della cache vengono caricati nel nuovo nodo.

Per i nodi Redis OSS, il processo di sostituzione è stato progettato per cercare di mantenere i dati esistenti e richiede una replica riuscita. Cerchiamo di sostituire solo una quantità ottimale di nodi dallo stesso cluster in un dato momento, per mantenerne la stabilità. È tuttavia possibile allocare una replica principale e una di lettura in diverse zone di disponibilità. In questo caso, quando un nodo viene sostituito, i dati vengono sincronizzati da un nodo peer in un'altra zona di disponibilità. Consigliamo, inoltre, di aggiornare la versione del motore Redis OSS a 5.0.6 o superiore, poiché queste versioni del motore hanno una stabilità migliore e permettono ai cluster di servire continuamente le richieste di scrittura in entrata durante le attività di patching se hanno il failover automatico abilitato. Infine, se la configurazione include solo un cluster principale e una singola replica per partizione, consigliamo di aggiungere ulteriori repliche prima del patching. Questo eviterà la riduzione della disponibilità e dei rischi durante il processo di patching. Per i cluster a nodo singolo, consigliamo di programmare una quantità di memoria libera sufficiente per Redis OSS secondo quanto descritto qui. Per i gruppi di replica composti da più nodi, consigliamo anche di programmare la sostituzione durante un periodo di traffico di scrittura in entrata limitato.

Per i nodi Memcached, consigliamo di programmare la finestra di manutenzione durante periodi di traffico di scrittura in entrata limitato, testare il failover dell'applicazione e utilizzare il client “più intelligente” fornito da ElastiCache. La perdita di dati non può essere evitata, perché i dati sono conservati solo in memoria.

Per Redis OSS, la configurazione della modalità cluster offre la miglior disponibilità durante le operazioni gestite o non gestite, e raccomandiamo sempre di utilizzare un client supportato dalla modalità cluster che si connetta all'endpoint di scoperta del cluster. Quando la modalità cluster è disattivata, raccomandiamo di utilizzare sempre l'endpoint principale per tutte le operazioni di scrittura. Gli endpoint di nodi singoli dei nodi di replica possono essere utilizzati per tutte le operazioni di lettura. Se nel cluster è attivato il failover automatico, il nodo principale può cambiare, quindi, l'applicazione dovrebbe confermare il ruolo del nodo e aggiornare tutti gli endpoint di lettura per assicurare che non stiano appesantendo il master. Quando il failover automatico è disabilitato, il ruolo del nodo non cambierà, tuttavia il tempo di inattività di operazioni gestite o non gestite è maggiore rispetto ai cluster con il failover automatico attivato. Evita di indirizzare richieste di lettura solo alle repliche di lettura. Se configuri il tuo client per inviare le richieste di lettura solo a quelle stesse repliche, assicurati di disporre di almeno due repliche di lettura per evitare interruzioni durante le relative operazioni nella finestra di manutenzione.

Consigliamo di lasciare che sia ElastiCache a gestire la sostituzione dei nodi autonomamente durante la finestra di manutenzione. È possibile utilizzare la finestra di manutenzione settimanale per programmare le sostituzioni quando viene creato un cluster ElastiCache. Per spostare in un secondo momento la finestra di manutenzione, è possibile usare l'API ModifyCacheCluster o fare clic su Modify nella console di gestione di ElastiCache.

Se si sceglie di gestire la sostituzione da soli, è possibile eseguire varie azioni a seconda del caso d'uso e della configurazione del cluster:

• Modificare la finestra di manutenzione.
• Riavviare l'istanza utilizzando il processo Backup e ripristino.
• Se la configurazione del cluster è in modalità Cluster disabilitata

o Sostituire una replica di lettura (modalità Cluster disabilitata): una procedura per sostituire manualmente una replica di lettura in un gruppo di replica.
o Sostituire il nodo principale (modalità Cluster disabilitata): una procedura per sostituire manualmente il nodo principale in un gruppo di replica.
o Sostituire un nodo autonomo (modalità Cluster disabilitata): due procedure diverse per sostituire un nodo autonomo.

• Se la configurazione del cluster è in modalità Cluster abilitata

o Sostituire un nodo nel cluster con uno o più partizioni: è possibile utilizzare il backup e ripristino oppure la scalabilità orizzontale seguita da scalabilità verticale per sostituire i nodi.

Per ulteriori istruzioni su tutte le presenti opzioni, consultare la pagina Azioni da intraprendere quando un nodo è pianificato per la sostituzione.

Con Memcached, è sufficiente eliminare e ricreare i cluster. In seguito alla sostituzione, l'evento programmato connesso alle istanze viene annullato.

Per ricevere le notifiche, puoi impostare le notifiche Amazon SNS per gli eventi rilevanti, come ad esempio un evento di sostituzione programmato. È possibile consultare la sezione Events nella console di gestione di ElastiCache oppure verificare la presenza di eventi futuri ElastiCache:NodeReplacementScheduled tramite l'API describe-events.

Per configurare le notifiche SNS, utilizza le informazioni qui disponibili.

Sì, puoi spostare la finestra di manutenzione del cluster. Per spostare in un secondo momento la finestra di manutenzione, è possibile usare l'API (ModifyCacheCluster oppure ModifyReplicationGroup) o fare clic su Modify nella console di gestione di ElastiCache.

Dopo aver spostato la finestra di manutenzione, il servizio ElastiCache pianificherà la manutenzione del nodo durante la nuova finestra specificata. Di seguito sono riportati alcuni esempi di come avviene lo spostamento.

Ad esempio,

Supponiamo che attualmente sia giovedì 9/11, alle 15 e la prossima finestra di manutenzione sia venerdì 10/11, alle 17. Questi sono 3 scenari e i relativi risultati:

• Sposti la finestra di manutenzione a venerdì alle 16 (dopo la data e l'ora corrente e prima della prossima finestra di manutenzione pianificata). Il nodo sarà sostituito venerdì 10/11, alle 16
• Sposti la finestra di manutenzione a sabato alle 16 (dopo la data e l'ora corrente e dopo la prossima finestra di manutenzione pianificata). Il nodo sarà sostituito sabato 11/11, alle 16.
• Sposti la finestra di manutenzione a mercoledì alle 16 (anticipandola nella settimana rispetto alla data e ora corrente). Il nodo sarà sostituito il mercoledì successivo 15/11, alle 16.

Queste sostituzioni vengono effettuate per applicare aggiornamenti obbligatori del sistema operativo dell'host. Gli aggiornamenti contribuiscono a rafforzare sicurezza, affidabilità e prestazioni.

È possibile che vengano sostituiti diversi nodi dello stesso cluster a seconda della configurazione, senza inficiarne la stabilità. Per i cluster partizionati, in genere non vengono sostituiti contemporaneamente diversi nodi nella stessa partizione. Inoltre, cerchiamo di non sostituire la maggior parte dei nodi master in un cluster su tutti gli shard.
Per quanto riguarda i cluster non in shard, cercheremo di scaglionare la sostituzione dei nodi durante l'intera finestra di manutenzione, in modo da mantenere elevata la stabilità del cluster.

Sì, se le finestre di manutenzione di cluster diversi sono configurate nello stesso periodo, è possibile che i nodi vengano sostituiti simultaneamente.