Sviluppo

resilienza e carico del server di Connessione

Quando si sviluppano applicazioni client, assicurarsi di considerare 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 del valore ideale, vedere questo articolo.

Dimensioni di richiesta o risposta di grandi dimensioni

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 la 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' è grande, può consumare la maggior parte del timeout per le richieste successive.

Nell'esempio seguente, la richiesta '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.

Le risoluzioni per le dimensioni delle risposte di grandi dimensioni sono varie, ma includono:

• Ottimizzare l'applicazione per un numero elevato di valori di piccole dimensioni, anziché per alcuni valori di grandi dimensioni.
  • La soluzione migliore consiste nel dividere i dati in valori più bassi correlati.
  • Vedere il post Qual è l'intervallo di dimensioni del valore ideale per Redis? Sono 100 KB troppo grandi? per informazioni dettagliate sul motivo per cui sono consigliati valori più piccoli.
• 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 le procedure consigliate per il clustering di Redis con le chiavi.

Usare pipelining

Provare a scegliere un client Redis che supporta la pipelining di Redis. 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 a 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 contratto di servizio. Usare almeno una cache di livello C1. Le cache C0 sono progettate solo per scenari di sviluppo/test semplici perché:

• condividono un core CPU
• usare poca memoria
• sono soggetti a problemi rumorosi vicini

È 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

Individuare 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.

Fare affidamento su nome host non su 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:

Scegliere una versione di Redis appropriata

La versione predefinita di Redis usata durante la creazione di una cache può cambiare nel tempo. 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.

Linee guida specifiche per i livelli Enterprise

Poiché i livelli Enterprise ed Enterprise Flash sono basati su Redis Enterprise anziché su Redis open source, esistono alcune differenze nelle procedure consigliate per lo sviluppo. Per altre informazioni, vedere Procedure consigliate per i livelli Enterprise ed Enterprise Flash.

Usare la crittografia TLS

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 un percorso di deprecazione a livello di settore, quindi usare TLS 1.2 se possibile.

Se la libreria client o lo strumento non supporta TLS, l'abilitazione di connessioni non crittografate è possibile tramite le API di gestione o portale di Azure. 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 di rete virtuale, vedere questa tabella.

Modifica del certificato TLS di Azure

Microsoft sta aggiornando i servizi di Azure per l'uso di certificati server TLS da un set diverso di autorità di certificazione (CA). Questa modifica viene implementata in fasi dal 13 agosto 2020 al 26 ottobre 2020 (stimata). Azure sta apportando questa modifica perché i certificati CA correnti non sono uno dei requisiti di base della CA/del browser. 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 dai servizi di Azure proviene oggi dall'infrastruttura PKI radice Baltimore CyberTrust. 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.

Quali sono gli effetti di questa modifica?

La maggior parte dei cache di Azure per Redis i clienti non sono interessati dalla modifica. L'applicazione potrebbe essere interessata se specifica in modo esplicito un elenco di certificati accettabili, una procedura nota come aggiunta del certificato. Se è aggiunto a un certificato intermedio o foglia anziché a Baltimore CyberTrust Root, è necessario eseguire azioni immediate per modificare la configurazione del certificato.

cache di Azure per Redis non supporta Associazione OCSP.

Nella tabella seguente vengono fornite informazioni sui certificati di cui viene eseguito il rollback. A seconda del certificato usato dall'applicazione, potrebbe essere necessario aggiornarlo per evitare la perdita di connettività all'istanza di cache di Azure per Redis.

Quali azioni devono essere intraprese?

Se l'applicazione usa l'archivio certificati del sistema operativo o aggiunge la radice baltimora tra le altre, non è necessaria alcuna azione.

Se l'applicazione aggiunge un certificato TLS intermedio o foglia, è consigliabile aggiungere le radici seguenti:

Per continuare a aggiungere certificati intermedi, aggiungere quanto segue all'elenco di certificati intermedi aggiunti, che include alcuni altri per ridurre al minimo le modifiche future:

Se l'applicazione convalida il certificato nel codice, è necessario modificarlo per riconoscere le proprietà --- ad esempio Issuers, Thumbprint --- dei nuovi certificati aggiunti. Questa verifica aggiuntiva deve coprire tutti i certificati aggiunti per essere più a prova di futuro.

Indicazioni specifiche della libreria client

Per altre informazioni, vedere Librerie client.

Passaggi successivi

• Test delle prestazioni
• Failover e applicazione di patch per Cache di Azure per Redis