Cache di Azure per Redis e affidabilità
Cache di Azure per Redis offre un archivio dati in memoria basato sul software Redis (Remote Dictionary Server). È costituito da una cache di dati sicura e da un broker di messaggistica che offre velocità effettiva elevata e accesso ai dati a bassa latenza per le applicazioni.
I concetti chiave e le procedure consigliate che supportano l'affidabilità includono:
Le sezioni seguenti includono considerazioni sulla progettazione, un elenco di controllo per la configurazione e opzioni di configurazione consigliate specifiche di Cache di Azure per Redis.
Considerazioni relative alla progettazione
I Contratti di servizio (SLA) di Cache di Azure per Redis coprono solo le cache di livello Standard e Premium, non la cache di livello Basic.
Redis è una cache in memoria per coppie chiave-valore e, per impostazione predefinita, integra funzionalità di disponibilità elevata, ad eccezione del livello Basic. Il servizio Cache di Azure per Redis è disponibile in tre livelli:
Basic: non consigliato per carichi di lavoro di produzione. Il livello Basic è ideale per:
- Nodo singolo
- Più dimensioni
- Sviluppo
- Test
- Carichi di lavoro non critici
Standard: una cache replicata in una configurazione a due nodi primario/secondario gestita da Microsoft, con un contratto di servizio che garantisce disponibilità elevata.
Premium: combina tutte le funzionalità incluse nel livello Standard con le seguenti funzionalità aggiuntive:
- Hardware e prestazioni più veloci rispetto al livello Basic o Standard.
- Dimensione della cache maggiore, fino a
120GB. - Persistenza dei dati, grazie alla presenza dei file RDB (Redis Database File) e AOF (Append Only File).
- Supporto della rete virtuale.
- Clustering
- Replica geografica: i dati vengono replicati dalla cache primaria in una cache secondaria, contenuta in un'altra area, per il ripristino di emergenza. Per eseguire il failover nella cache secondaria, entrambe le cache devono essere scollegate manualmente e la cache secondaria deve essere disponibile per operazioni di scrittura. L'applicazione che scrive in Redis, inoltre, deve essere aggiornata con la stringa di connessione della cache secondaria.
- Zone di disponibilità: la cache e le repliche vengono implementate in più zone di disponibilità.
Nota
Per impostazione predefinita, in ogni distribuzione è presente una replica per partizione. Nelle distribuzioni in cui è presente più di una replica, la persistenza, il clustering e la replica geografica sono tutti disabilitati. I nodi verranno distribuiti in modo uniforme tra tutte le zone. Il numero di repliche deve essere
>=al numero di zone. - Importazione ed esportazione.
Microsoft garantisce ai clienti almeno il 99.9% del tempo di connettività tra gli endpoint della cache e il gateway Internet di Microsoft.
Elenco di controllo
La cache di Azure per Redis è stata configurata tenendo in considerazione la resilienza?
- Pianificare gli aggiornamenti.
- Monitorare la cache e impostare gli avvisi.
- Distribuire la cache in una rete virtuale.
- Valutare una strategia di partizionamento all'interno della cache Redis.
- Configurare la persistenza dei dati per salvare una copia della cache in Archiviazione di Azure oppure usare la replica geografica, a seconda dei requisiti aziendali.
- Implementare i criteri di ripetizione dei tentativi nel contesto di Cache di Azure per Redis.
- Usare un'implementazione statica o singleton del multiplexer di connessione a Redis e seguire la Guida alle procedure consigliate.
- Vedere Come amministrare Cache Redis di Azure.
Raccomandazioni per la configurazione
Esplorare la tabella di raccomandazioni seguente per ottimizzare la configurazione di Cache di Azure per Redis per l'affidabilità del servizio:
| Recommendation | Descrizione |
|---|---|
| Pianificare gli aggiornamenti. | Pianificare i giorni e le ore in cui dovranno essere applicati alla cache gli aggiornamenti del server Redis, che non includono gli aggiornamenti di Azure o gli aggiornamenti al sistema operativo della macchina virtuale. |
| Monitorare la cache e impostare gli avvisi. | Impostare avvisi in caso di eccezioni, utilizzo elevato della CPU, utilizzo elevato della memoria, carico del server e chiavi rimosse, per acquisire informazioni utili a stabilire il momento migliore per ridimensionare la cache. Se la cache deve essere ridimensionata, è importante capire quando effettuare questa operazione, poiché sarà necessario aumentare l'utilizzo della CPU per eseguire la migrazione dei dati. |
| Distribuire la cache in una rete virtuale. | In questo modo il cliente acquisisce un controllo maggiore sul traffico che è possibile connettere alla cache. Assicurarsi che la subnet disponga di uno spazio indirizzi sufficiente per distribuire i nodi e le partizioni della cache (cluster). |
| Valutare una strategia di partizionamento all'interno della cache Redis. | Il partizionamento di un archivio dati Redis prevede la suddivisione dei dati tra istanze del server Redis. Ogni istanza costituisce una singola partizione. Cache di Azure per Redis consente di astrarre i servizi di Redis dietro un'interfaccia e non li espone direttamente. Il modo più semplice per implementare il partizionamento consiste nel creare più istanze della Cache Redis di Azure e distribuire i dati nelle cache. È possibile associare ogni elemento di dati a un identificatore (chiave di partizione) che specifica la cache in cui è memorizzato l'elemento. La logica dell'applicazione client potrà usare l'identificatore per indirizzare le richieste alla partizione appropriata. Questo schema è molto semplice. Tuttavia, se lo schema di partizionamento viene modificato, ad esempio se vengono create istanze extra di Cache di Azure per Redis, è possibile sia necessario riconfigurare le applicazioni client. |
| Configurare la persistenza dei dati per salvare una copia della cache in Archiviazione di Azure oppure usare la replica geografica, a seconda dei requisiti aziendali. | Persistenza dei dati: se vengono riavviati sia il server master che il server di replica, i dati verranno caricati automaticamente dall'account di archiviazione. Replica geografica: la cache secondaria deve essere scollegata dalla cache primaria. La cache secondaria diventerà ora la cache primaria e potrà ricevere operazioni di scrittura. |
| Implementare i criteri di ripetizione dei tentativi nel contesto di Cache di Azure per Redis. | La maggior parte dei servizi di Azure e degli SDK client include un meccanismo di ripetizione dei tentativi. Questi meccanismi differiscono perché ogni servizio ha caratteristiche e requisiti diversi. Ogni meccanismo di ripetizione dei tentativi viene ottimizzato per un servizio specifico. |
| Vedere Come amministrare Cache Redis di Azure. | Viene illustrato come il riavvio della cache può determinare la perdita di dati e come testare la resilienza dell'applicazione. |
Artefatti di origine
Per identificare le istanze di Redis che non si trovano nel livello Premium, usare la query seguente:
Resources
| where type == 'microsoft.cache/redis'
| where properties.sku.name != 'Premium'