Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Importante
Cache di Azure per Redis ha annunciato la sequenza temporale di ritiro per tutti gli SKU. È consigliabile spostare le istanze di Cache Redis di Azure esistenti in Azure Managed Redis non appena è possibile.
Per altre informazioni sul ritiro:
Resilienza della connessione e carico del server
Quando si sviluppano applicazioni client, assicurarsi di esaminare le procedure consigliate pertinenti per la resilienza della connessione e la gestione del carico del server.
Prendere in considerazione più chiavi e valori più piccoli
Cache di Azure per Redis funziona meglio con valori più piccoli. Per distribuire i dati su più chiavi, è consigliabile dividere blocchi di dati più grandi in blocchi più piccoli. Per altre informazioni sulle dimensioni ideali per i valori, vedere questo articolo.
Dimensioni elevate per la richiesta o la risposta
Una richiesta/risposta di grandi dimensioni può causare un timeout. Si supponga, ad esempio, che il valore di timeout configurato nel client sia di 1 secondo. L'applicazione richiede due chiavi, ad esempio "A" e "B", nello stesso momento (con la stessa connessione di rete fisica). La maggior parte dei client supporta il pipelining delle richieste in cui entrambe le richieste 'A' e 'B' vengono inviate una dopo l'altra senza attendere le risposte. Il server invia le risposte nello stesso ordine. Se la risposta 'A' ha dimensioni elevate, può consumare la maggior parte del timeout per le richieste successive.
Nell'esempio seguente le richieste 'A' e 'B' vengono inviate rapidamente al server. Il server avvia rapidamente l'invio di risposte 'A' e 'B'. A causa dei tempi di trasferimento dei dati, la risposta 'B' deve attendere il timeout della risposta 'A' anche se il server ha risposto rapidamente.
|-------- 1 Second Timeout (A)----------|
|-Request A-|
|-------- 1 Second Timeout (B) ----------|
|-Request B-|
|- Read Response A --------|
|- Read Response B-| (**TIMEOUT**)
Non è semplice misurare questa richiesta/risposta. È possibile instrumentare il codice client per tenere traccia di richieste e risposte di grandi dimensioni.
Esistono svariate risoluzioni per le dimensioni delle risposte di grandi dimensioni, tra cui:
- Ottimizzare l'applicazione per un numero elevato di valori di piccole dimensioni, anziché per qualche valore di grandi dimensioni.
- La soluzione migliore consiste nel dividere i dati in valori più bassi correlati.
- Per informazioni dettagliate sul motivo per cui sono consigliati valori più piccoli, vedere il post Qual è l'intervallo di dimensioni del valore ideale per Redis? 100 KB sono troppi?.
- Aumentare le dimensioni della macchina virtuale (VM) per ottenere funzionalità di larghezza di banda superiori
- Una maggiore larghezza di banda nella macchina virtuale client o server può ridurre i tempi di trasferimento dei dati per risposte più grandi.
- Confrontare l'utilizzo di rete corrente in entrambi i computer con i limiti delle dimensioni correnti della macchina virtuale. Una maggiore larghezza di banda solo sul server o solo sul client potrebbe non essere sufficiente.
- Aumentare il numero di oggetti di connessione usati dall'applicazione.
- Usare un approccio round robin per effettuare richieste su oggetti di connessione diversi.
Distribuzione delle chiavi
Se si prevede di usare il clustering Redis, leggere prima di tutto Procedure consigliate per il clustering Redis con chiavi.
Usare il pipelining
Provare a scegliere un client Redis che supporta il Pipelining di Redis. Il pipelining consente di usare in modo efficiente la rete e di ottenere la massima velocità effettiva possibile.
Evitare operazioni costose
Alcune operazioni Redis, come il comando KEYS, sono costose e devono essere evitate. Per alcune considerazioni sui comandi a esecuzione prolungata, vedere Comandi con esecuzione prolungata.
Scegliere un livello appropriato
Usare livelli Standard, Premium, Enterprise o Enterprise Flash per i sistemi di produzione. Non usare il livello Basic nell'ambiente di produzione. Il livello Basic è un sistema a nodo singolo senza replica dei dati e senza contratto di servizio. Usare almeno una cache di livello C1. Le cache di livello C0 sono destinate solo a scenari semplici di sviluppo e test per i motivi seguenti:
- Condividono un core CPU
- Usano poca memoria
- Sono soggette a problemi che influiscono negativamente sulle prestazioni
È consigliabile testare le prestazioni per scegliere il livello corretto e convalidare le impostazioni di connessione. Per altre informazioni, vedere Test delle prestazioni.
Client nella stessa area della cache
Posizionare l'istanza della cache e l'applicazione nella stessa area. La connessione a una cache in un'area diversa può aumentare in modo significativo la latenza e ridurre l'affidabilità.
Anche se è possibile connettersi dall'esterno di Azure, non è consigliabile, soprattutto quando si usa Redis come cache. Se si usa il server Redis come archivio chiave/valore, la latenza potrebbe non essere il problema principale.
Basarsi sul nome host, non sull'indirizzo IP pubblico
L'indirizzo IP pubblico assegnato alla cache può cambiare a causa di un'operazione di scalabilità o di un miglioramento del back-end. È consigliabile basarsi sul nome host anziché su un indirizzo IP pubblico esplicito. Ecco i moduli consigliati per i vari livelli:
| Livello | Form |
|---|---|
| Basico, Standard, Premium | <cachename>.redis.cache.windows.net |
| Enterprise, Enterprise Flash | <DNS name>.<Azure region>.redisenterprise.cache.azure.net. |
Scegliere una versione di Redis appropriata
La versione predefinita di Redis usata durante la creazione di una cache può cambiare nel tempo. La cache di Azure per Redis potrebbe adottare una nuova versione quando viene rilasciata una nuova versione di Redis open source. Se è necessaria una versione specifica di Redis per l'applicazione, è consigliabile scegliere in modo esplicito la versione di Redis quando si crea la cache.
Usare la crittografia TLS
La cache di Azure per Redis richiede comunicazioni crittografate TLS per impostazione predefinita. Le versioni 1.0, 1.1 e 1.2 di TLS sono attualmente supportate. Tuttavia, TLS 1.0 e 1.1 sono in fase di deprecazione a livello di settore, quindi usare TLS 1.2 se possibile.
Se la libreria client o lo strumento non supporta TLS, è possibile abilitare le connessioni non crittografate tramite il portale di Azure o le API di gestione. Nei casi in cui le connessioni crittografate non sono possibili, è consigliabile inserire la cache e l'applicazione client in una rete virtuale. Per altre informazioni sulle porte usate nello scenario della cache della rete virtuale, vedere questa tabella.
Modifica ai certificati TLS di Azure
Microsoft sta aggiornando i servizi di Azure per l'uso di certificati server TLS emessi da un set diverso di autorità di certificazione (CA). Questa modifica viene implementata in fasi dal 13 agosto 2020 al 26 ottobre 2020 (data stimata). Azure sta apportando questa modifica perché i certificati CA correnti non sono uno dei requisiti baseline di CA/Browser Forum. Il problema è stato segnalato il 1° luglio 2020 e si applica a più provider di infrastruttura a chiave pubblica (PKI) diffusi in tutto il mondo. La maggior parte dei certificati TLS usati oggi dai servizi di Azure proviene dalla infrastruttura a chiave pubblica (PKI) Baltimore CyberTrust Root. Il servizio Cache di Azure per Redis continua a essere concatenato alla Baltimore CyberTrust Root. I certificati server TLS, tuttavia, verranno rilasciati dalle nuove autorità di certificazione intermedie (ICA) a partire dal 12 ottobre 2020.
Note
Questa modifica è limitata ai servizi nelle aree di Azure pubbliche. Esclude i cloud sovrani, ad esempio Cina, o governativi.
Quali sono gli effetti di questa modifica?
La maggior parte dei clienti di Cache di Azure per Redis non sono interessati dalla modifica. L'applicazione potrebbe essere interessata se specifica in modo esplicito un elenco di certificati accettabili, una procedura nota come associazione del certificato. Se è associato a un certificato intermedio o foglia anziché a Baltimore CyberTrust Root, è necessario eseguire azioni immediate per modificare la configurazione del certificato.
La cache di Azure per Redis non supporta l'associazione a OCSP.
Nella tabella seguente vengono fornite informazioni sui certificati in fase di aggiornamento. A seconda del certificato usato dall'applicazione, potrebbe essere necessario aggiornarlo per evitare la perdita di connettività all'istanza della cache di Azure per Redis.
| Tipo di CA | Corrente | Post aggiornamento (12 ottobre 2020) | Azione |
|---|---|---|---|
| Radice | Identificazione: d4de20d05e66fc53fe1a50882c78db2852cae474 Scadenza: lunedì 12 maggio 2025, 16:59:00 Nome soggetto: CN = Baltimore CyberTrust Root OU = CyberTrust O = Baltimora C = IE |
Nessuna modifica | nessuno |
| Intermedi | Identificazioni personali: CN = Microsoft IT TLS CA 1 Identificazione personale: 417e225037fbfaa4f95761d5ae729e1aea7e3a42 CN = Microsoft IT TLS CA 2 Identificazione personale: 54d9d20239080c32316ed9ff980a48988f4adf2d CN = Microsoft IT TLS CA 4 Identificazione personale: 8a38755d0996823fe8fa3116a277ce446eac4e99 CN = Microsoft IT TLS CA 5 Identificazione personale: Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7 Scadenza: venerdì 20 maggio 2024 5:52:38 Nome soggetto: OU = Microsoft IT O = Microsoft Corporation L = Redmond S = Washington C = STATI UNITI |
Identificazioni personali: CN = Microsoft RSA TLS CA 01 Identificazione personale: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a CN = Microsoft RSA TLS CA 02 Identificazione personale: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75 Scadenza: martedì, 8 ottobre 2024 12:00:00; Nome soggetto: O = Microsoft Corporation C = STATI UNITI |
Obbligatoria |
Quali azioni devono essere intraprese?
Se l'applicazione usa l'archivio certificati del sistema operativo o associa, tra gli altri, Baltimore Root, non è necessaria alcuna azione.
Se l'applicazione associa un certificato TLS intermedio o foglia, è consigliabile associare le radici seguenti:
| Certificato | Thumbprint |
|---|---|
| Baltimore Root CA | d4de20d05e66fc53fe1a50882c78db2852cae474 |
| Microsoft RSA Root Certificate Authority 2017 | 73a5e64a3bff8316ff0edccc618a906e4eae4d74 |
| Digicert Global Root G2 | df3c24f9bfd666761b268073fe06d1cc8d4f82a4 |
Suggerimento
È previsto che i certificati intermedi e foglia cambino frequentemente. È consigliabile non accettare una dipendenza da tali certificati. Associare invece l'applicazione a un certificato radice perché viene aggiornato meno spesso.
Per continuare ad associare certificati intermedi, aggiungere quanto segue all'elenco di certificati intermedi associati, che include qualche certificato in più per ridurre al minimo le modifiche future:
| Nome comune della CA | Thumbprint |
|---|---|
| Microsoft RSA TLS CA 01 | 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a |
| Microsoft RSA TLS CA 02 | b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75 |
| Microsoft Azure TLS Issuing CA 01 | 2f2877c5d778c31e0f29c7e371df5471bd673173 |
| Microsoft Azure TLS Issuing CA 02 | e7eea674ca718e3befd90858e09f8372ad0ae2aa |
| Microsoft Azure TLS Issuing CA 05 | 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5 |
| Microsoft Azure TLS Issuing CA 06 | 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0 |
Se l'applicazione convalida il certificato nel codice, è necessario modificarlo per riconoscere le proprietà, ad esempio autorità di certificazione, identificazione personale, dei nuovi certificati associati. Questa verifica aggiuntiva deve coprire tutti i certificati associati per una migliore preparazione per il futuro.
Indicazioni specifiche della libreria client
Per altre informazioni, vedere Librerie client.