Configurer la géoréplication active pour les instances d’Azure Managed Redis (préversion)

Article
11/19/2024

Dans cet article, vous allez voir comment configurer un cache avec géoréplication active à l’aide du portail Azure.

La géoréplication active regroupe jusqu’à cinq instances d’Azure Managed Redis (préversion) dans un même cache qui s’étend sur plusieurs régions Azure. Toutes les instances agissent comme des caches principaux locaux. Une application détermine la ou les instances à utiliser pour les demandes de lecture et d’écriture.

Notes

Le transfert de données entre régions Azure est facturé aux tarifs de bande passante standard.

Fonctionnement de la géoréplication active

La géoréplication active utilise des types de données répliqués sans conflit (CRDT) pour distribuer en toute transparence des données entre des instances Redis qui peuvent être distribuées sur plusieurs continents. Ces instances sont connectées dans une configuration actif-actif, où les écritures dans une instance sont automatiquement reflétées dans les autres instances du même groupe de géoréplication. Cette réplication bidirectionnelle des données diffère des approches de réplication actif-passif unidirectionnelle, où les données sont répliquées du réplica principal vers un géoréplica, mais pas dans l’autre sens. Il s’agit d’un outil puissant couramment utilisé de plusieurs façons :

Fournir une latence locale en distribuant la mise en cache plus proche des utilisateurs. En utilisant un réseau d’instances Redis géorépliquées actives, vous pouvez placer des caches géographiquement plus proches des utilisateurs de chaque région, ce qui réduit la latence et améliore les performances des applications.
Synchronisation des applications globales. Étant donné que les caches géorépliqués apparaissent comme une instance Redis unique, vous pouvez distribuer mondialement les données sans avoir à les segmenter par régions. Par exemple, vous pouvez utiliser un seul ensemble trié Redis pour fournir le classement d’un jeu pour tous les utilisateurs dans le monde entier, plutôt que de fournir un classement distinct pour chaque région géographique.
Réduction des temps d’arrêt et des risques liés aux pannes régionales. Étant donné que chaque instance Redis du groupe de géoréplication est constamment mise à jour avec les données les plus récentes des autres instances du groupe, les données sont bien conservées en cas de panne régionale. Les applications peuvent basculer temporairement pour utiliser l’une des autres instances du groupe, et lorsque la région revient en ligne, l’instance Redis est automatiquement rechargée avec les données des autres caches géorépliqués.

Pour obtenir une description plus détaillée du fonctionnement de la géoréplication active, consultez Géodistribution active-active (basée sur CRDT).

Étendue de la disponibilité

Niveau	À mémoire optimisée, Équilibré, Optimisé pour le calcul	Optimisé pour le stockage flash
Disponible	Oui (sauf B0 et B1)	Oui

Important

Les références SKU Équilibré B0 et B1 ne prennent pas en charge la géoréplication active.

Conditions préalables à la géoréplication active

Il existe quelques restrictions lors de l’utilisation de la géoréplication active :

La géoréplication active est prise en charge uniquement lorsque Azure Managed Redis est dans une configuration à haute disponibilité (c’est-à-dire, qui utilise la réplication).
Seuls les modules RediSearch et RedisJSON sont pris en charge
Sur le niveau Flash optimisé, seule la stratégie d’éviction Sans éviction peut être utilisée. Toutes les stratégies d’éviction sont prises en charge sur les autres niveaux.
La persistance des données n’est pas prise en charge, car la géoréplication active offre une expérience supérieure.
Tous les caches d’un groupe de géoréplication doivent avoir la même configuration. Par exemple, tous les caches doivent avoir les mêmes référence SKU, capacité, stratégie d’éviction, stratégie de clustering, modules et paramètre TLS.
Si une instance de groupe de géoréplication est mise à l’échelle, les autres instances de ce groupe doivent être mises à l’échelle sur la même taille avant que toute mise à l’échelle supplémentaire puisse se produire. Pour plus d’informations, consultez Mise à l’échelle des instances dans un groupe de géoréplication.
Vous ne pouvez pas utiliser les commandes Redis FLUSHALL et FLUSHDB lors de l’utilisation de la géoréplication active. L’interdiction des commandes empêche la suppression involontaire des données. Utilisez plutôt l’opération de vidage.

Créer ou rejoindre un groupe de géoréplication active

Lors de la création d’une ressource Azure Managed Redis, sélectionnez l’onglet Avancé. Renseignez la première partie du formulaire, y compris la stratégie de clustering. Pour plus d’informations sur le choix d’une stratégie de clustering, consultez Clustering dans Azure Managed Redis.
Sélectionnez Configurer pour configurer la Géo-réplication active.
Créez un nouveau groupe de réplication pour une première instance de cache. Ou bien, sélectionnez un modèle existant dans la liste.
Sélectionnez Configurer pour terminer.
Patientez pendant la création du premier cache. Une fois terminé, vous voyez Configuré défini pour la Géoréplication active. Répétez les étapes ci-dessus pour chaque instance de cache du groupe de géoréplication.

Ajouter une instance existante à un groupe de géoréplication actif

Pour ajouter une instance de cache existante à un groupe de géoréplication actif, vous pouvez utiliser l’API REST pour effectuer une action de liaison forcée.

Toutes les données de l’instance de cache en cours de liaison seront ignorées. L’instance sera également temporairement indisponible pendant plusieurs minutes lors de la jonction du groupe de géoréplication. La prise en charge du portail et de l’interface CLI n’est pas encore disponible pour cette fonctionnalité.

Supprimer une instance d’un groupe de géoréplication active

Pour supprimer une instance de cache d’un groupe de géoréplication active, supprimez simplement l’instance. Les instances restantes sont ensuite automatiquement reconfigurées.

Dissociation forcée en cas de panne d’une région

La géoréplication active est une fonctionnalité puissante qui améliore considérablement la disponibilité lors de l’utilisation d’Azure Managed Redis. Toutefois, mieux vaut prendre des mesures pour préparer vos caches en cas de panne régionale.

Par exemple, tenez compte des conseils suivants :

Identifiez à l’avance vers quel autre cache du groupe de géoréplication basculer si une région connaît une panne.
Vérifiez que les pare-feu sont définis de sorte que l’ensemble des applications et des clients puissent accéder au cache de sauvegarde identifié.
Chaque cache du groupe de géoréplication a sa propre clé d’accès. Déterminez comment l’application passe à des clés d’accès différentes lors du ciblage d’un cache de sauvegarde.
Si un cache du groupe de géoréplication tombe en panne, une accumulation de métadonnées commence à arriver dans tous les caches du groupe de géoréplication. Les métadonnées ne peuvent pas être ignorées tant que les écritures ne peuvent pas être resynchronisées dans tous les caches. Vous pouvez empêcher l’accumulation de métadonnées en forçant la dissociation du cache qui est en panne. Pensez à surveiller la mémoire disponible dans le cache et à le dissocier en cas de sollicitation de la mémoire, en particulier pour les charges de travail lourdes en écriture.

Il est également possible d’utiliser un modèle de disjoncteur. Utilisez le modèle pour rediriger automatiquement le trafic loin d’un cache qui connaît une panne régionale et en direction d’un cache de sauvegarde dans le même groupe de géoréplication. Utilisez des services Azure comme Azure Traffic Manager ou Azure Load Balancer pour activer la redirection.

Si l’un des caches dans votre groupe de réplication n’est pas disponible en raison d’une panne de région, vous pouvez forcer la suppression du cache non disponible du groupe de réplication.

Vous devez supprimer le cache non disponible, car les caches restants dans le groupe de réplication commencent à stocker les métadonnées qui n’ont pas été partagées dans le cache non disponible. Dans ce cas, les caches disponibles dans votre groupe de réplication peuvent manquer de mémoire.

Accédez au Portail Azure et sélectionnez l’un des caches dans le groupe de réplication qui est toujours disponible.
Sélectionnez la géo-réplication active dans le menu Ressource à gauche pour afficher les paramètres dans le volet de travail.
Sélectionnez le cache dont vous avez besoin pour forcer la dissociation en activant la case à cocher.
Sélectionnez Force unlink (Forcer la dissociation), puis OK pour confirmer.
Une fois la disponibilité de la région affectée restaurée, vous devez supprimer le cache affecté et le recréer pour le rajouter à votre groupe de réplication.

Configurer la géoréplication active à l’aide d’Azure CLI ou de PowerShell

Azure CLI

Utilisez Azure CLI pour créer un cache et un groupe de géoréplication, ou pour ajouter un nouveau cache à un groupe de géoréplication existant. Pour plus d’informations, consultez az redisenterprise create.

Créer une instance Azure Managed Redis dans un nouveau groupe de géoréplication à l’aide d’Azure CLI

Cet exemple crée une instance Azure Managed Redis Équilibré B10 nommée Cache1 dans la région USA Est. Ensuite, le cache est ajouté à un nouveau groupe de géoréplication active nommé 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"

Pour configurer correctement la géoréplication active, l’ID de l’instance de cache en cours de création doit être ajouté avec le paramètre --linked-databases. L’ID est au format suivant :

/subscriptions/<your-subscription-ID>/resourceGroups/<your-resource-group-name>/providers/Microsoft.Cache/redisEnterprise/<your-cache-name>/databases/default

Créer une instance Azure Managed Redis dans un groupe de géoréplication existant à l’aide d’Azure CLI

Cet exemple crée une instance de cache Équilibré B10 nommée Cache2 dans la région USA Ouest. Ensuite, le script ajoute le cache au groupe de géoréplication active replicationGroup créé dans une procédure précédente. De cette façon, il est lié dans une configuration active-active avec 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"

Comme précédemment, vous devez lister Cache1 et Cache2 à l’aide du paramètre --linked-databases.

Azure PowerShell

Utilisez Azure PowerShell pour créer un cache et un groupe de géoréplication, ou pour ajouter un nouveau cache à un groupe de géoréplication existant. Pour plus d’informations, consultez New-AzRedisEnterpriseCache.

Créer une instance Azure Managed Redis dans un nouveau groupe de géoréplication à l’aide de PowerShell

Cet exemple crée une instance de cache Azure Managed Redis Équilibré B10 nommée Cache1 dans la région USA Est. Ensuite, le cache est ajouté à un nouveau groupe de géoréplication active nommé 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"}'

Pour configurer correctement la géoréplication active, l’ID de l’instance de cache en cours de création doit être ajouté avec le paramètre -LinkedDatabase. L’ID est au format suivant :

/subscriptions/<your-subscription-ID>/resourceGroups/<your-resource-group-name>/providers/Microsoft.Cache/redisEnterprise/<your-cache-name>/databases/default

Créer une instance Azure Managed Redis dans un groupe de géoréplication existant à l’aide de PowerShell

Cet exemple crée une instance de cache Équilibré B10 nommée Cache2 dans la région USA Ouest. Ensuite, le script ajoute le cache au groupe de géoréplication active « replicationGroup » créé dans la procédure précédente. Le résultat est que les deux caches, Cache1 et Cache2, sont liés dans une configuration actif-actif.

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"}'

Comme précédemment, vous devez lister Cache1 et Cache2 à l’aide du paramètre -LinkedDatabase.

Mise à l’échelle des instances dans un groupe de géoréplication

Il est possible de mettre à l’échelle des instances qui sont configurées pour utiliser la géoréplication active. Toutefois, un groupe de géoréplication composé de différentes tailles de cache peut poser des problèmes. Pour éviter que ces problèmes ne se produisent, tous les caches d’un groupe de géoréplication doivent avoir la même taille et le même niveau de performance.

Étant donné que la mise à l’échelle nécessite la modification de la taille ou du niveau et qu’il est difficile de mettre à l’échelle simultanément toutes les instances du groupe de géoréplication, Azure Managed Redis dispose d’un mécanisme de verrouillage. Si vous mettez à l’échelle une instance dans un groupe de géoréplication, la machine virtuelle sous-jacente sera mise à l’échelle, mais la mémoire disponible sera plafonnée à la taille d’origine jusqu’à ce que les autres instances soient également mises à l’échelle. Et toutes les autres opérations de mise à l’échelle des instances restantes sont verrouillées jusqu’à ce qu’elles correspondent à la même configuration que le premier cache à mettre à l’échelle.

Exemple de mise à l’échelle

Par exemple, vous pouvez avoir trois instances dans votre groupe de géoréplication, toutes des instances À mémoire optimisée M10 :

Nom d'instance	Redis00	Redis01	Redis02
Type	À mémoire optimisée M10	À mémoire optimisée M10	À mémoire optimisée M10

Supposez que vous souhaitez effectuer un scale-up de chaque instance de ce groupe de géoréplication vers une instance Optimisé pour le calcul X20. Vous devez d’abord effectuer un scale-up de l’un des caches vers le niveau X20 :

Nom d'instance	Redis00	Redis01	Redis02
Type	Optimisé pour le calcul X20	À mémoire optimisée M10	À mémoire optimisée M10

À l’heure actuelle, les instances Redis02 et Redis01 peuvent effectuer un scale-up uniquement d’une instance Optimisé pour le calcul X20. Toutes les autres opérations de mise à l’échelle sont verrouillées.

Remarque

À ce stade, l’instance Redis00 peut toujours être mise à l’échelle vers un niveau supérieur. Mais elle sera verrouillée une fois que Redis01 ou Redis02 aura été mis à l’échelle vers le niveau Optimisé pour le calcul X20.

Une fois que chaque instance a été mise à l’échelle au même niveau et à la même taille, tous les verrous de mise à l’échelle sont supprimés :

Nom d'instance	Redis00	Redis01	Redis02
Type	Optimisé pour le calcul X20	Optimisé pour le calcul X20	Optimisé pour le calcul X20

Opération de vidage

En raison du risque de perte de données par inadvertance, vous ne pouvez pas utiliser les commandes Redis FLUSHALL et FLUSHDB avec une instance de cache résidant dans un groupe de géoréplication. Utilisez plutôt le bouton Vider le ou les caches situé en haut du volet de travail La géoréplication active.

Capture d’écran montrant la géoréplication active sélectionnée dans le menu Ressource et la fonctionnalité Vider le cache est encadrée en rouge.

Vider les caches à l’aide d’Azure CLI ou de PowerShell

Azure CLI et PowerShell peuvent également être utilisés pour déclencher une opération de vidage. Pour plus d’informations sur l’utilisation d’Azure CLI, consultez az redisenterprise database flush. Pour plus d’informations sur l’utilisation de PowerShell, consultez Invoke-AzRedisEnterpriseCacheDatabaseFlush.