Come amministrare Cache Redis di Azure

  • Articolo

Questo articolo descrive come eseguire attività di amministrazione, ad esempio il riavvio e il canale di aggiornamento e Pianificare gli aggiornamenti per le istanze di cache di Azure per Redis.

Riavvio

A sinistra, reboot consente di riavviare uno o più nodi della cache. Questa funzionalità di riavvio consente di testare la resilienza dell'applicazione in caso di errore di un nodo della cache.

Importante

Il riavvio non è ancora disponibile per il livello Enterprise. Il riavvio è disponibile per tutti gli altri livelli.

Screenshot che evidenzia l'opzione di menu Riavvia

Selezionare i nodi da riavviare e selezionare Riavvia.

Screenshot che mostra i nodi che è possibile riavviare

Se si dispone di una cache Premium con clustering abilitato, è possibile selezionare le partizioni della cache da riavviare.

screenshot delle opzioni di partizione

Per riavviare uno o più nodi della cache, selezionare i nodi e selezionare Riavvia. Se è abilitata una cache Premium con clustering, selezionare le partizioni da riavviare e quindi selezionare Riavvia. Dopo alcuni minuti, i nodi selezionati si riavviano e vengono ripristinati online pochi minuti dopo.

L'effetto sulle applicazioni client varia a seconda dei nodi riavviati.

  • Primario: quando il nodo primario viene riavviato, cache di Azure per Redis esegue il failover nel nodo di replica e lo promuove a primario. Durante il failover potrebbe verificarsi un breve intervallo in cui le connessioni alla cache potrebbero avere esito negativo.
  • Replica: quando il nodo di replica viene riavviato, in genere non si verifica alcun effetto sui client della cache.
  • Sia primario che replica: quando entrambi i nodi della cache vengono riavviati, cache di Azure per Redis tenta di riavviare normalmente entrambi i nodi, in attesa del completamento di uno prima del riavvio dell'altro. In genere, la perdita di dati non si verifica. Tuttavia, la perdita di dati può comunque verificarsi a eventi o errori di manutenzione imprevisti. Il riavvio della cache molte volte in una riga aumenta la probabilità di perdita di dati.
  • Nodi di una cache Premium con clustering abilitato: quando si riavviano uno o più nodi di una cache Premium con clustering abilitato, il comportamento per i nodi selezionati è analogo a quello che si ottiene quando si riavviano il nodo o i nodi corrispondenti di una cache non cluster.

Domande frequenti sulla funzionalità di riavvio

Quale nodo si deve riavviare per testare l'applicazione?

Per testare la resilienza dell'applicazione in caso di errore del nodo primario della cache, riavviare il nodo primario . Per testare la resilienza dell'applicazione in caso di errore del nodo di replica, riavviare il nodo Replica .

È possibile riavviare la cache per annullare le connessioni al client?

Sì, se si riavvia la cache, tutte le connessioni client vengono cancellate. Il riavvio può essere utile nel caso in cui ogni connessione client venga usata a causa di un errore di logica o di un bug nell'applicazione client. Ogni piano tariffario presenta diversi limiti di connessione al client per le diverse dimensioni e, una volta raggiunti questi limiti, non vengono accettate altre connessioni al client. Il riavvio della cache consente di annullare tutte le connessioni al client.

Importante

Se si riavvia la cache per cancellare le connessioni client, StackExchange.Redis si riconnette automaticamente solo dopo che il nodo di Redis è tornato in linea. Se il problema sottostante non viene risolto, le connessioni client possono continuare a interrompersi.

Con il riavvio i dati nella cache andranno persi?

Se si riavviano entrambi i nodi primario e di replica , tutti i dati nella cache (o in tale partizione quando si usa una cache Premium con clustering abilitato) come probabilmente essere sicuri. Tuttavia, i dati possono essere persi in alcuni casi. Il riavvio di entrambi i nodi deve essere preso con cautela.

Se si riavvia solo uno dei nodi, i dati non vengono in genere persi, ma potrebbero essere ancora. Ad esempio, se il nodo primario viene riavviato e una scrittura della cache è in corso, i dati della scrittura della cache andranno persi. Un altro scenario per la perdita di dati sarebbe se si riavvia un nodo e l'altro nodo si arresta a causa di un errore contemporaneamente. Per altre informazioni sulle possibili cause di una perdita di dati, vedere What happened to my data in Redis?(Cosa è accaduto ai dati in Redis)

È possibile riavviare la cache usando PowerShell, l'interfaccia della riga di comando o altri strumenti di gestione?

Sì, per istruzioni relative a PowerShell vedere Riavviare una Cache Redis.

È possibile riavviare la cache Aziendale?

No. Il riavvio non è ancora disponibile per il livello Enterprise. Il riavvio è disponibile per i livelli Basic, Standard e Premium. Le impostazioni visualizzate nel menu Risorsa in Amministrazione istration dipendono dal livello della cache. Non viene visualizzato il riavvio quando si usa una cache dal livello Enterprise.

Scaricare i dati

Quando si usano i livelli Basic, Standard o Premium di cache di Azure per Redis, i dati vengono scaricati dal menu delle risorse. L'operazione Scarica dati consente di eliminare o scaricare tutti i dati nella cache. Questa operazione di scaricamento può essere usata prima di ridimensionare le operazioni per ridurre potenzialmente il tempo necessario per completare l'operazione di ridimensionamento nella cache. È anche possibile configurare per eseguire periodicamente l'operazione di scaricamento nelle cache di sviluppo/test per mantenere sotto controllo l'utilizzo della memoria.

L'operazione di scaricamento , quando eseguita in una cache in cluster, cancella i dati da tutte le partizioni contemporaneamente.

Importante

In precedenza, l'operazione di scaricamento era disponibile solo per le cache del livello Enterprise con replica geografica. Ora è disponibile nei livelli Basic, Standard e Premium.

Screenshot che mostra i dati scaricati selezionati nel menu delle risorse di un'istanza della cache.

Aggiornare il canale e pianificare gli aggiornamenti

A sinistra, Pianifica aggiornamenti consente di scegliere un canale di aggiornamento e una finestra di manutenzione per l'istanza della cache.

Qualsiasi istanza della cache che usa il canale di aggiornamento Stabile riceve aggiornamenti alcune settimane dopo rispetto alle istanze della cache usando il canale di aggiornamento di anteprima. È consigliabile scegliere il canale di aggiornamento anteprima per i carichi di lavoro non di produzione e meno critici. Scegliere il canale di aggiornamento stabile per i carichi di lavoro di produzione più critici. Per impostazione predefinita, tutte le cache vengono memorizzate nel canale di aggiornamento Stabile .

Importante

Se si modifica il canale di aggiornamento nell'istanza della cache, la cache viene sottoposta a un evento di applicazione di patch per applicare gli aggiornamenti corretti. È consigliabile modificare il canale di aggiornamento durante la finestra di manutenzione.

Una finestra di manutenzione consente di controllare i giorni e gli orari di una settimana durante i quali è possibile aggiornare le macchine virtuali che ospitano la cache. cache di Azure per Redis fa il massimo sforzo per avviare e completare l'aggiornamento del software server Redis entro l'intervallo di tempo specificato definito.

Importante

La finestra di manutenzione e canale di aggiornamento si applica agli aggiornamenti e agli aggiornamenti del server Redis al sistema operativo delle macchine virtuali che ospitano la cache. La finestra di manutenzione e canale di aggiornamento non si applica agli aggiornamenti del sistema operativo host agli host che ospitano le macchine virtuali della cache o altri componenti di rete di Azure. In rari casi, in cui le cache sono ospitate in modelli meno recenti, la finestra di manutenzione non si applicherà nemmeno agli aggiornamenti del sistema operativo guest. È possibile stabilire se la cache si trova in un modello precedente se il nome DNS della cache viene risolto in un suffisso , cloudapp.netchinacloudapp.cnusgovcloudapi.net o .cloudapi.de

Attualmente non è disponibile alcuna opzione per configurare un canale di aggiornamento o gli aggiornamenti pianificati per una cache di livello Enterprise.

Screenshot che mostra gli aggiornamenti della pianificazione

Per specificare una finestra di manutenzione, controllare i giorni desiderati e specificare l'ora di inizio della finestra di manutenzione per ogni giorno. Quindi selezionare OK. L'ora dell'intervallo di manutenzione è in formato UTC e può essere configurata solo su base oraria.

L'intervallo di manutenzione minimo predefinito per gli aggiornamenti è di cinque ore. Questo valore non è configurabile dal portale di Azure, ma è possibile configurarlo in PowerShell usando il MaintenanceWindow parametro del cmdlet New-AzRedisCacheScheduleEntry. Per altre informazioni, vedere È possibile gestire gli aggiornamenti pianificati usando PowerShell, l'interfaccia della riga di comando o altri strumenti di gestione?

Domande frequenti sulla pianificazione degli aggiornamenti

Quando vengono eseguiti gli aggiornamenti se non si usa la funzionalità di pianificazione degli aggiornamenti?

Se non si specifica un intervallo di manutenzione, è possibile eseguire aggiornamenti in qualsiasi momento.

Quale tipo di aggiornamenti vengono eseguiti durante l'intervallo di manutenzione pianificato?

Durante l'intervallo di manutenzione pianificato vengono eseguiti solo gli aggiornamenti del server Redis. La finestra di manutenzione non si applica agli aggiornamenti o agli aggiornamenti di Azure per il sistema operativo host.

È possibile gestire gli aggiornamenti pianificati usando PowerShell, l'interfaccia della riga di comando o altri strumenti di gestione?

Sì, è possibile gestire gli aggiornamenti pianificati con i cmdlet di PowerShell seguenti:

È possibile eseguire un aggiornamento coperto e gestito dalla funzionalità Aggiornamenti pianificata all'esterno della finestra Aggiornamenti pianificata?

Sì. In generale, gli aggiornamenti non vengono applicati all'esterno della finestra di Aggiornamenti pianificata configurata. Gli aggiornamenti della sicurezza critici rari possono essere applicati al di fuori della pianificazione dell'applicazione di patch come parte dei criteri di sicurezza.

Contenuto correlato

Altre informazioni sulle funzionalità di Cache di Azure per Redis.