Configurare la replica geografica attiva per le istanze di Managed Redis di Azure (anteprima)
Questo articolo illustra come configurare una cache con replica geografica attiva usando il portale di Azure.
La replica geografica attiva raggruppa fino a cinque istanze di Managed Redis di Azure (anteprima) in un'unica cache che si estende su più aree di Azure. Tutte le istanze fungono da cache locali primarie. Un'applicazione decide l'istanza o le istanze da usare per le richieste di lettura e scrittura.
Nota
Il trasferimento dei dati tra aree di Azure viene addebitato a velocità di larghezza di banda standard.
Funzionamento della replica geografica attiva
La replica geografica attiva usa tipi di dati replicati senza conflitti (CRDT) per distribuire facilmente i dati tra le istanze di Redis che possono essere distribuite tra continenti. Queste istanze sono connesse in una configurazione attiva-attiva, in cui le scritture in un'istanza vengono riflesse automaticamente nelle altre istanze dello stesso gruppo di replica geografica. Questa replica bidirezionale dei dati differisce dagli approcci di replica attiva-passiva unidirezionale, in cui i dati vengono replicati dal database primario a una replica geografica, ma non dall'altra direzione. Si tratta di uno strumento potente comunemente usato in diversi modi:
Fornire la latenza locale distribuendo la memorizzazione nella cache più vicina agli utenti. Usando una rete di istanze Redis con replica geografica attiva, è possibile posizionare le cache geograficamente più vicine agli utenti in ogni area, riducendo la latenza e migliorando le prestazioni dell'app.
Sincronizzazione delle applicazioni globali. Poiché le cache con replica geografica vengono visualizzate come una singola istanza di Redis, è possibile distribuire i dati a livello globale senza dover segmentare i dati in base alle aree. Ad esempio, è possibile usare un singolo set ordinato redis per fornire una classifica di gioco per tutti gli utenti di tutto il mondo, invece di fornire una classifica separata per ogni area geografica.
Riduzione del tempo di inattività e del rischio di interruzioni a livello di area. Poiché ogni istanza di Redis nel gruppo di replica geografica viene costantemente aggiornata con i dati più recenti delle altre istanze del gruppo, i dati vengono mantenuti correttamente durante un'interruzione a livello di area. Le applicazioni possono passare temporaneamente all'uso di una delle altre istanze del gruppo e, quando l'area torna online, l'istanza di Redis viene ricaricata automaticamente con i dati delle altre cache con replica geografica.
Per una suddivisione più dettagliata del funzionamento della replica geografica attiva, vedere Distribuzione geografica attiva-attiva (basata su CRDTS)
Ambito della disponibilità
Livello | Ottimizzato per la memoria, bilanciato, ottimizzato per il calcolo | Ottimizzato per Flash |
---|---|---|
Disponibile | Sì (tranne B0 e B1) | Sì |
Importante
Gli SKU B0 e B1 bilanciati non supportano la replica geografica attiva.
Prerequisiti per la replica geografica attiva
Esistono alcune restrizioni quando si usa la replica geografica attiva:
La replica geografica attiva è supportata solo quando Azure Managed Redis si trova in una configurazione a disponibilità elevata, vale a dire che usa la replica.
Sono supportati solo i moduli RediSearch e RedisJSON
Nel livello Ottimizzato per Flash, è possibile usare solo i criteri di rimozione Nessuna rimozione. Tutti i criteri di rimozione sono supportati negli altri livelli.
La persistenza dei dati non è supportata perché la replica geografica attiva offre un'esperienza superiore.
Tutte le cache all'interno di un gruppo di replica geografica devono avere la stessa configurazione. Ad esempio, tutte le cache devono avere stessi SKU, capacità, criteri di rimozione, criteri di clustering, moduli e impostazione TLS.
Se viene ridimensionata un'istanza di un gruppo di replica geografica, è necessario ridimensionare le altre istanze di tale gruppo alla stessa dimensione prima che possa verificarsi qualsiasi altra scalabilità. Per altre informazioni, vedere Ridimensionamento delle istanze in un gruppo di replica geografica.
Non è possibile usare i comandi Redis
FLUSHALL
eFLUSHDB
quando si usa la replica geografica attiva. L’inibizione dei comandi impedisce l'eliminazione accidentale dei dati. Invece, usare l'operazione flush.
Creare o aggiungere un gruppo di replica geografica attivo
Quando si crea una nuova risorsa Managed Redis di Azure, selezionare la scheda Avanzate. Completare la prima parte del modulo, inclusi i criteri di clustering. Per altre informazioni sulla scelta dei criteri di clustering, vedere Clustering in Managed Redis di Azure.
Selezionare Configura per configurare la Replica geografica attiva.
Creare un nuovo gruppo di replica per una prima istanza della cache. In alternativa, selezionarne uno esistente dall'elenco.
Per terminare, selezionare Configura.
Attendere che la prima cache venga creata correttamente. Al termine, viene visualizzato Configurato per Replica geografica attiva. Ripetere i passaggi precedenti per ogni istanza della cache nel gruppo di replica geografica.
Aggiungere un'istanza esistente a un gruppo di replica geografica attiva
Per aggiungere un'istanza della cache esistente a un gruppo di replica geografica attiva, è possibile usare l'API REST per eseguire un'azione di collegamento forzato.
Tutti i dati nell'istanza della cache collegata vengono eliminati. L'istanza non è disponibile temporaneamente anche per alcuni minuti durante l'aggiunta al gruppo di replica geografica. Il portale e il supporto dell'interfaccia della riga di comando non sono ancora disponibili per questa funzionalità.
Rimozione da un gruppo di replica geografica attivo
Per rimuovere un'istanza della cache da un gruppo di replica geografica attiva, è sufficiente eliminare l'istanza. Le istanze rimanenti vengono quindi riconfigurate automaticamente.
Forzare lo scollegamento se si verifica un'interruzione dell'area
La replica geografica attiva è una funzionalità efficace per aumentare notevolmente la disponibilità quando si usa Managed Redis di Azure. È tuttavia consigliabile eseguire le operazioni necessarie per preparare le cache in caso di interruzione a livello di area.
Si considerino, ad esempio, i suggerimenti seguenti:
Identificare in anticipo l'altra cache nel gruppo di replica geografica a cui passare in caso di arresto di un'area.
Assicurarsi che i firewall siano impostati in modo che tutte le applicazioni e i client possano accedere alla cache di backup identificata.
Ogni cache nel gruppo di replica geografica ha una propria chiave di accesso. Determinare il modo in cui l'applicazione passa a chiavi di accesso diverse quando la destinazione è una cache di backup.
Se una cache nel gruppo di replica geografica diventa inattiva, viene avviata una compilazione di metadati in tutte le cache del gruppo di replica geografica. I metadati non possono essere eliminati finché non è possibile sincronizzare nuovamente le scritture in tutte le cache. È possibile impedire la compilazione dei metadati forzando lo scollegamento della cache inattiva. Prendere in considerazione il monitoraggio della memoria disponibile nella cache e lo scollegamento in caso di utilizzo elevato di memoria, in particolare per carichi di lavoro con intensa attività di scrittura.
È inoltre possibile usare un modello di interruttore. Usare il modello per reindirizzare automaticamente il traffico da una cache che riscontra un'interruzione dell'area verso una cache di backup nello stesso gruppo di replica geografica. Usare servizi di Azure come Gestione traffico di Azure o Azure Load Balancer per abilitare il reindirizzamento.
Se una delle cache nel gruppo di replica non è disponibile a causa di interruzioni dell'area, è possibile forzare la rimozione della cache non disponibile dal gruppo di replica.
È consigliabile rimuovere la cache non disponibile perché le cache rimanenti nel gruppo di replica iniziano a archiviare i metadati non condivisi nella cache non disponibile. In questo caso, le cache disponibili nel gruppo di replica potrebbero esaurire la memoria.
Passare al portale di Azure e selezionare una delle cache nel gruppo di replica ancora disponibile.
Selezionare Replica geografica attiva nel menu Risorse a sinistra per visualizzare le impostazioni presenti nel riquadro di lavoro.
Selezionare la cache di cui è necessario forzare lo scollegamento selezionando la casella.
Selezionare Forza scollegamento, quindi OK per confermare.
Dopo aver ripristinato la disponibilità dell'area interessata, è necessario eliminare la cache interessata e ricrearla per aggiungerla di nuovo al gruppo di replica.
Configurare la replica geografica attiva usando l'interfaccia della riga di comando di Azure o PowerShell
Interfaccia della riga di comando di Azure
Usare l'interfaccia della riga di comando di Azure per creare una nuova cache e un nuovo gruppo di replica geografica o per aggiungere una nuova cache a un gruppo di replica geografica esistente. Per altre informazioni, vedere creare az redisenterprise.
Creare una nuova istanza di Managed Redis di Azure in un nuovo gruppo di replica geografica usando l'interfaccia della riga di comando di Azure
Questo esempio crea una nuova istanza B10 bilanciata di Managed Redis di Azure denominata Cache1 nell'area Stati Uniti orientali. La cache viene quindi aggiunta a un nuovo gruppo di replica geografica attivo denominato replicationGroup:
az redisenterprise create --location "East US" --cluster-name "Cache1" --sku "Balanced_B10" --resource-group "myResourceGroup" --group-nickname "replicationGroup" --linked-databases id="/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default"
Per configurare correttamente la replica geografica attiva, l'ID dell'istanza della cache da creare deve essere aggiunto con il parametro --linked-databases
. L'ID è nel formato:
/subscriptions/<your-subscription-ID>/resourceGroups/<your-resource-group-name>/providers/Microsoft.Cache/redisEnterprise/<your-cache-name>/databases/default
Creare una nuova istanza di Managed Redis di Azure in un gruppo di replica geografica esistente usando l'interfaccia della riga di comando di Azure
In questo esempio viene creata una nuova istanza della cache B10 bilanciata denominata Cache2 nell'area Stati Uniti occidentali. Lo script aggiunge quindi la cache al gruppo di replica geografica attiva replicationGroup
creato in una procedura precedente. In questo modo, viene collegata in una configurazione attiva-attiva con la Cache1.
az redisenterprise create --location "West US" --cluster-name "Cache2" --sku "Balanced_B10" --resource-group "myResourceGroup" --group-nickname "replicationGroup" --linked-databases id="/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default" --linked-databases id="/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache2/databases/default"
Come in precedenza, è necessario elencare sia la Cache1che la Cache2 usando il parametro --linked-databases
.
Azure PowerShell
Usare Azure PowerShell per creare una nuova cache e un nuovo gruppo di replica geografica o per aggiungere una nuova cache a un gruppo di replica geografica esistente. Per altre informazioni, vedere New-AzRedisEnterpriseCache.
Creare una nuova istanza di Managed Redis di Azure in un nuovo gruppo di replica geografica usando PowerShell
Questo esempio crea una nuova istanza della cache B10 bilanciata di Managed Redis di Azure denominata Cache1 nell'area Stati Uniti orientali. La cache viene quindi aggiunta a un nuovo gruppo di replica geografica attivo denominato replicationGroup:
New-AzRedisEnterpriseCache -Name "Cache1" -ResourceGroupName "myResourceGroup" -Location "East US" -Sku "Balanced_B10" -GroupNickname "replicationGroup" -LinkedDatabase '{id:"/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default"}'
Per configurare correttamente la replica geografica attiva, l'ID dell'istanza della cache da creare deve essere aggiunto con il parametro -LinkedDatabase
. L'ID è nel formato:
/subscriptions/<your-subscription-ID>/resourceGroups/<your-resource-group-name>/providers/Microsoft.Cache/redisEnterprise/<your-cache-name>/databases/default
Creare una nuova istanza di Managed Redis di Azure in un gruppo di replica geografica esistente usando PowerShell
In questo esempio viene creata una nuova istanza della cache B10 bilanciata denominata Cache2 nell'area Stati Uniti occidentali. Lo script aggiunge quindi la cache al gruppo di replica geografica attiva, replicationGroup creato nella procedura precedente. Il risultato è dato da due cache, Cache1 e Cache2, collegate in una configurazione attiva-attiva.
New-AzRedisEnterpriseCache -Name "Cache2" -ResourceGroupName "myResourceGroup" -Location "West US" -Sku "Balanced_B10" -GroupNickname "replicationGroup" -LinkedDatabase '{id:"/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default"}', '{id:"/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache2/databases/default"}'
Come in precedenza, è necessario elencare sia la Cache1che la Cache2 usando il parametro -LinkedDatabase
.
Ridimensionamento di istanze in un gruppo di replica geografica
È possibile ridimensionare le istanze configurate per l'uso della replica geografica attiva. Tuttavia, un gruppo di replica geografica con una combinazione di dimensioni della cache diverse può causare problemi. Per evitare che si verifichino questi problemi, tutte le cache in un gruppo di replica geografica devono avere le stesse dimensioni e lo stesso livello di prestazioni.
Poiché il ridimensionamento richiede la modifica delle dimensioni o del livello ed è difficile ridimensionare contemporaneamente tutte le istanze nel gruppo di replica geografica, Azure Managed Redis ha un meccanismo di blocco. Se si ridimensiona un'istanza in un gruppo di replica geografica, la macchina virtuale sottostante viene ridimensionata, ma la memoria disponibile è limitata alle dimensioni originali fino a quando non vengono ridimensionate anche le altre istanze. Qualsiasi altra operazione di ridimensionamento per le istanze rimanenti viene bloccata finché non corrisponderà alla stessa configurazione della prima cache da ridimensionare.
Esempio di ridimensionamento
Ad esempio, potrebbero essere presenti tre istanze nel gruppo di replica geografica, tutte le istanze M10 ottimizzate per la memoria:
Nome istanza | Redis00 | Redis01 | Redis02 |
---|---|---|---|
Type | Istanza M10 ottimizzata per la memoria | Istanza M10 ottimizzata per la memoria | Istanza M10 ottimizzata per la memoria |
Si supponga di voler ridimensionare ogni istanza di questo gruppo di replica geografica in un'istanza X20 ottimizzata per il calcolo. Innanzitutto, ridimensionare una delle cache fino a X20:
Nome istanza | Redis00 | Redis01 | Redis02 |
---|---|---|---|
Type | Istanza X20 ottimizzata per il calcolo | Istanza M10 ottimizzata per la memoria | Istanza M10 ottimizzata per la memoria |
A questo punto, le istanze Redis01
e Redis02
possono ridimensionare solo un'istanza X20 ottimizzata per il calcolo. Tutte le altre operazioni di ridimensionamento sono bloccate.
Nota
L'istanza Redis00
non è bloccata a questo punto dal ridimensionamento. Ma viene bloccato una volta Redis01
o Redis02
viene ridimensionato in modo da essere una X20 ottimizzata per il calcolo.
Dopo che ogni istanza viene ridimensionata allo stesso livello e alle stesse dimensioni, tutti i blocchi di ridimensionamento vengono rimossi:
Nome istanza | Redis00 | Redis01 | Redis02 |
---|---|---|---|
Type | Istanza X20 ottimizzata per il calcolo | Istanza X20 ottimizzata per il calcolo | Istanza X20 ottimizzata per il calcolo |
Operazione di scaricamento
A causa della potenziale perdita di dati accidentale, non è possibile usare i comandi Redis FLUSHALL
e FLUSHDB
con qualsiasi istanza della cache che risiede in un gruppo di replica geografica. Usare invece il pulsante Scarica cache nella parte superiore del riquadro di lavoro Replica geografica attiva.
Metrica di replica geografica
La metrica Replica geografica integra in Azure Managed Redis consente di monitorare l'integrità dei cluster con replica geografica. Questa metrica viene usata per monitorare lo stato di sincronizzazione tra le repliche geografiche.
Per monitorare la metrica Replica geografica integra nella portale di Azure:
Aprire il portale di Azure e selezionare l'istanza di Redis gestita di Azure.
Nel menu Risorsa selezionare Metriche nella sezione Monitoraggio .
Selezionare Aggiungi metrica e selezionare la metrica Replica geografica integra.
Se necessario, applicare filtri per repliche geografiche specifiche.
È possibile configurare un avviso per notificare se la metrica Replica geografica integra genera un valore non integro (0) continuamente per oltre 60 minuti.
Selezionare Nuova regola di avviso.
Definire la condizione da attivare se il valore della metrica è 0 per almeno 60 minuti, il tempo consigliato.
Aggiungere gruppi di azioni per le notifiche, ad esempio posta elettronica, SMS e altri.
Salvare l'avviso.
Per altre informazioni su come configurare gli avvisi per la cache Redis Enterprise, vedere la sezione relativa agli avvisi in Monitorare Cache Redis.
Importante
Questa metrica può essere temporaneamente visualizzata come non integra a causa di operazioni di routine come eventi di manutenzione o ridimensionamento, avviate da Azure o dal cliente. Per evitare falsi allarmi, è consigliabile configurare una finestra di osservazione di 60 minuti, in cui la metrica continua a rimanere non integra come il tempo appropriato per la generazione di un avviso, in quanto potrebbe indicare un problema che richiede l'intervento.
Problemi comuni lato client che possono causare problemi di sincronizzazione tra repliche geografiche
Uso di hashtag personalizzati: l'uso di hashtag personalizzati in Redis può causare una distribuzione non uniforme dei dati tra partizioni, che potrebbe causare problemi di prestazioni e problemi di sincronizzazione nelle repliche geografiche, quindi evitare di usare hashtag personalizzati a meno che il database non debba eseguire più operazioni chiave.
Dimensioni elevate delle chiavi: le chiavi di grandi dimensioni possono creare problemi di sincronizzazione tra le repliche geografiche. Per garantire prestazioni uniformi e replica affidabile, è consigliabile mantenere le dimensioni delle chiavi inferiore a 500 MB quando si usa la replica geografica. Se le dimensioni delle singole chiavi si avvicinano a 2 GB, la cache riscontra problemi di integrità della replica geografica.
Scaricare le cache con l'interfaccia della riga di comando di Azure o PowerShell
È possibile usare l'interfaccia della riga di comando di Azure e PowerShell anche per attivare un'operazione di scaricamento. Per altre informazioni sull'uso dell'interfaccia della riga di comando di Azure, vedere az redisenterprise database flush. Per altre informazioni sull'uso di PowerShell, vedere Invoke-AzRedisEnterpriseCacheDatabaseFlush.
Importante
Prestare attenzione quando si usa la funzionalità Scarica cache. Selezionando il pulsante, vengono rimossi tutti i dati dalla cache corrente e da TUTTE le cache collegate nel gruppo di replica geografica.
Gestire l'accesso alla funzionalità usando il controllo degli accessi in base al ruolo di Azure È necessario concedere l'accesso allo scarico di tutte le cache solo agli utenti autorizzati.