Géodistribution active-active avec une base de données multimaître

Géodistribution active-active avec une base de données multimaître

Ce contenu a été écrit avant un changement dans la convention de dénomination de Redis – Redis Enterprise est désormais le surnom de tous nos produits.

Aujourd’hui, les applications Redis peuvent tirer parti de quelques types de réplication –

  • Réplication basée sur LAN : Adaptée aux caractéristiques LAN – Réseaux à faible latence et à large bande passante avec seulement quelques retransmissions.
  • Réplication basée sur WAN : adaptée aux caractéristiques WAN – Réseaux à latence élevée et faible bande passante avec un taux de « bruit » élevé.

Dans la prochaine version de Redis Enterprise 5.0, nous proposons une nouvelle technologie de réplication multi-maître flexible conçue pour le WAN. La nouvelle fonctionnalité permet des déploiements Redis géodistribués actifs-actifs en utilisant la magie des CRDT (types de données répliquées sans conflit). Les CRDT simplifient le développement de systèmes actifs-actifs et résolvent automatiquement les écritures conflictuelles. Combiné avec les types de données Redis, les CRDT pfournir un mécanisme qui peut facilement vous aider à développer systèmes géodistribués actifs-actifs capables de gérer intelligemment les écritures conflictuelles.

Si vous souhaitez en savoir plus sur les CRDT Redis et visiter «Courbure du théorème CAP dans les déploiements géo-distribués avec CRDT

Nous nous concentrerons sur l’expérimentation des CRDT dans cette procédure pas à pas, mais si vous souhaitez approfondir les CRDT, commencez par Cet article par Eric Brewer : 12 ans après le théorème CAP original, Eric Brewer explique comment les CRDT modifient l’équilibre CAP dans cet excellent article. JPour vous familiariser avec les CRDT et les essayer, vous pouvez vous inscrire au programme de prévisualisation de Redis Enterprise 5.0. Retrouver les consignes ici.

Premiers pas avec la géodistribution active-active basée sur le CRDT dans Redis Enterprise

Nous allons configurer un déploiement géo-distribué réduit à l’échelle et démontrer comment l’accès actif-actif fonctionne sous Redis Enterprise. Voici les quatre étapes :

  • Étape 1 : Exécuter quatre conteneurs Docker
  • Étape 2 : Configurer deux clusters
  • Etape 3 : Créer une nouvelle base de données (CRDB)
  • Étape 4 : Connectez-vous à votre base de données et lâchez-vous !

Étape 1 : Exécutez quatre conteneurs

Exécutez 2 conteneurs. Nous utiliserons chacun pour simuler un cluster Redis Enterprise.

Remarque : Avant d’exécuter les conteneurs, accédez aux paramètres du menu fixe et réglez votre RAM par conteneur sur 6 Go. Sous certains systèmes d’exploitation, vous ne pourrez peut-être pas démarrer les conteneurs Redis Enterprise Pack à moins que la RAM par conteneur ne soit ajustée.

docker run -d --cap-add sys_resource -h rp1 --name rp1 -p 8443:8443 -p 8080:8080 -p 12000:12000 redis/redis
docker run -d --cap-add sys_resource -h rp2 --name rp2 -p 8444:8443 -p 8081:8080 -p 12001:12000 redis/redis

Il est important de noter les options -p : chaque conteneur mappe son port d’interface utilisateur Web (8443), son port d’API REST (8080) et son port d’accès à la base de données (12000) à un port hôte unique pour garantir que tous les conteneurs sont accessibles depuis l’hôte. OS qui exécute les conteneurs. Cela vous aidera à vous connecter à chaque cluster à partir de l’hôte ainsi qu’à partir des conteneurs eux-mêmes.

Étape 2 : Configurer deux clusters

Permet de configurer les deux clusters.

Pour le cluster 1, dirigez votre navigateur vers https://localhost:8443 sur la machine hôte pour voir le Redise Console d’administration du pack. Cliquez simplement sur le bouton Configuration de la page pour commencer.

Remarque : Selon votre navigateur, une erreur de certificat peut s’afficher. Choisissez simplement continuer sur le site Web pour accéder à l’écran de configuration.

Slide01

Sur la page de configuration du nœud, sélectionnez vos paramètres par défaut et fournissez un cluster Nom de domaine complet: cluster1.local. Ensuite, cliquez simplement sur le bouton Suivant.

Slide02

Si vous n’avez pas de clé de licence, cliquez sur le bouton Suivant pour essayer la version d’essai du produit.

Sur l’écran suivant, configurez un compte d’administrateur de cluster en utilisant un e-mail pour la connexion et un mot de passe.

Slide03

Vous avez terminé sur cluster1.local.

Répétez les mêmes opérations pour le cluster 2. D’abord, dirigez le navigateur vers https://localhost:8444. Les étapes sont identiques sauf dans cette passe, spécifiez FQDN comme cluster2.local.

Une fois cela fait, nous avons deux clusters Redise Pack avec les FQDN cluster1.local et cluster2.local.

Étape 3 : Créer la base de données Redis

Nous allons créer la base de données à l’aide de l’API REST. Ce qui suit créera une base de données Redis de type CRDB (base de données répliquée sans conflit). Les CRDB ont quelques particularités :

  • Les CRDB sont des bases de données qui s’étendent sur plusieurs clusters.
  • Chacun des clusters participants crée une base de données locale appelée « CRDB Instances ». Les instances CRDB communiquent entre elles à travers les clusters à l’aide de la réplication active-active (ou réplication multimaître).
  • Les applications peuvent se connecter aux instances CRDB comme s’il s’agissait de bases de données Redis locales classiques.

L’appel d’API REST ci-dessous crée une instance CRDB sur cluster1.local et une instance CRDB sur cluster2.local. Sur chaque cluster, les instances CRDB ont un point de terminaison du port 12000 et les deux bases de données sont nommées “sample-crdb”.

Avant d’émettre l’appel ci-dessous, placez le et que vous avez spécifié lors de la configuration ci-dessus.

Sous l’onglet bases de données, choisissez la base de données Redis avec le type de déploiement défini sur Géo-distribué.

new geo distrbuted 1

Sur la page de création de base de données, cliquez sur le afficher l’option avancée lien et entrer base de données1 pour le nom de la base de données et 12000 pour le numéro de port du point de terminaison. Assurez-vous d’ajouter les deux http://cluster1.local:8080 et http://cluster2.local:8080 à la liste des clusters participants.

image2 1

Une fois la base de données activée, vous disposerez d’instances CRDB sur chaque cluster participant auquel vous pourrez vous connecter.

Étape 4 : Connectez-vous à votre Redis CRDB Instances

Une fois la base de données Redis (CRDB) créée, vous êtes prêt à vous connecter à votre base de données. Vous pouvez utiliser l’une des méthodes suivantes pour tester la connectivité à votre base de données

N’oubliez pas que nous avons deux instances CRDB qui sont disponibles pour les connexions et les lectures et écritures simultanées. Les instances CRDB utilisent la réplication bidirectionnelle pour la CRDB globale.

Connexion à l’aide de redis-cli

redis-cli est un simple outil de ligne de commande pour interagir avec la base de données redis. Dans ce cas, nous utiliserons redis-cli sous chaque conteneur en utilisant “exécutable docker”. Utilisation “exécutable docker” pour basculer votre contexte dans le Redise Emballez le conteneur du nœud dans cluster1.local sous le conteneur nommé rp1

docker exec -it rp1 bash

Exécutez redis-cli, situé dans “/opt/redis/bin” répertoire, pour se connecter au port 12000 et stocker et récupérer un clé1 dans la base de données.

/opt/redis/bin/redis-cli -p 12000
127.0.0.1:12000> set key1 123
OK
127.0.0.1:12000> get key1
"123"

Voyons l’écriture à clé1 répliqué sur le cluster 2. Sur une autre fenêtre de terminal, utilisez “docker exec” pour basculer votre contexte dans le Redise Emballez le conteneur du nœud dans le cluster 2.

docker exec -it rp2 bash
/opt/redis/bin/redis-cli -p 12000
127.0.0.1:12000> get key1
"123"

Expérimenter avec les CRDB et les écritures conflictuelles

Vous avez maintenant un déploiement CRDB fonctionnel. Voyons comment les CRDB simplifient le développement lorsque vous avez des écritures distribuées simultanées sur les données.

Voici un test simple. Voyons comment INCR sur k1 sur 2 instances CRDB sur cluster1 et cluster2 se synchronise pour garantir une valeur finale précise. t1 à t5 représente l’ordre des événements. les opérations sous cluster1.local sont effectuées sur le conteneur rp1 et les opérations sous cluster2.local sont effectuées sur le conteneur rp2.

Slide10 1

Simulation de pannes réseau : La synchronisation entre les clusters est rapide. Pour certains des tests avancés, vous trouverez également des simulations de pannes de réseau entre le cluster1 et le cluster2 afin que vous puissiez observer le fonctionnement des CRDT dans chaque type de données.

Il est facile de simuler le partitionnement du réseau dans Docker. Pour créer une partition réseau, recherchez l’adresse IP sur cluster1. je reçois 10.0.0.2

docker exec -it rp1 ifconfig | grep 0.0.0.0 | cut -d":" -f 2 | cut -d" " -f 1

10.0.0.2

Pour rompre la mise en réseau entre les 2 clusters cluster1.local et cluster2.local, exécutez ce qui suit sur cluster2.local (conteneur rp2).

docker exec --privileged rp2 iptables -A INPUT --source 10.0.0.2 -j DROP
docker exec --privileged rp2 iptables -A OUTPUT --dst 10.0.0.2 -j DROP

À ce stade, cluster1 et cluster2 ne peuvent pas communiquer avec la réplication active-active. À un moment donné, vous voudrez restaurer le réseau. Une fois que vous aurez restauré la communication réseau entre les clusters, les CRDB recommenceront automatiquement à se synchroniser. Voici comment procéder ;

docker exec --privileged rp2 iptables -F

En voici une autre à essayer. Cette fois, nous allons simuler une panne de réseau entre les opérations pour observer les problèmes. Dans ce cas, nous verrons comment un Redis SET fonctionne avec les CRDT. nous allons créer l’ensemble et le laisser se synchroniser entre les clusters. Nous allons casser le réseau et ajouter en privé un nouveau membre distinct au SET dans chaque cluster. Une fois la communication rétablie, vous verrez comment les CRDT résolvent l’écriture conflictuelle et unissent les deux ensembles.

Slide11

Nous venons de gratter la surface des CRDT dans Redis. Vous pouvez vous inscrire à l’aperçu privé pour obtenir plus de détails et de documentation sur les fonctionnalités. Suivez simplement les instructions ici.

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *