Condividi tramite

Sviluppo

  • Articolo

Resilienza della connessione e carico del server

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.
  • 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:

Livello Modulo
Basic, 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

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 ai certificati 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.

Nota

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

Tipo ca Corrente Post Rolling (12 ottobre 2020) Azione
Radice Identificazione personale: d4de20d05e66fc53fe1a50882c78db2852cae474

Scadenza: lunedì 12 maggio 2025, 4:59:00

Nome soggetto:
CN = Baltimore CyberTrust Root
OU = CyberTrust
O = Baltimora
C = IE		 Non cambiando None
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: 8a38755d0996823fe8fa3116a27ce446eac4e99

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: 703d7a8f0ebf55aa59f98eaf4a206004eb2516a

CN = Microsoft RSA TLS CA 02
Identificazione personale: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75

Scadenza: martedì, 8 ottobre 2024 12:00:00 am;

Nome soggetto:
O = Microsoft Corporation
C = STATI UNITI
 Richiesto

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:

Certificate Identificazione personale
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 dipendenze. Aggiungere invece l'applicazione a un certificato radice perché esegue il rollback meno frequente.

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:

Nome comune della CA Identificazione personale
Microsoft RSA TLS CA 01 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02 b0c2d2d13cdd56cdaa6ab6e2c0440be4a429c75
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 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