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

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

Redis Enterprise Cluster (RLEC) a connu un grand succès depuis sa sortie initiale. Ça sert déploiements Redis de production de nombreux clientsleur permettant d’utiliser la base de données la plus rapide au monde avec une charge opérationnelle minimale.

Nous avons récemment publié notre version 4.2.1 de RLEC, qui comprend des améliorations et des fonctionnalités très utiles demandées par les clients, telles que :

  • Réplication interrégionale / cloud
  • Prise en charge multi-IP et IPv6
  • AOF amélioré
  • Prise en charge des profils cloud et de réseau local
  • prise en charge de la journalisation rsyslog
  • Prise en charge de l’emplacement de stockage OpenStack Object Store (“Swift”)

et beaucoup plus…

Vous trouverez ci-dessous un aperçu de certaines mises à jour clés, et vous pouvez lire tous les détails dans le notes de version.

Réplication interrégionale / cloud

RLEC inclut une fonctionnalité très utile appelée “Réplica de” afin que vous puissiez définir une base de données comme étant une réplique (destination) d’une autre base de données (source). Une fois définies et chargées avec votre jeu de données initial, toutes les commandes d’écriture sont synchronisées de la source à la destination. Cela vous permet de maintenir une base de données (destination) qui est une réplique exacte d’une autre base de données.

Cette configuration peut être très utile, par exemple, si vous souhaitez répartir la charge de lecture de votre application sur plusieurs bases de données. De plus, il peut être utilisé pour une synchronisation unique d’une base de données soit au sein de RLEC, soit à partir d’un OSS Redis.

Vos bases de données source et de destination peuvent même avoir des architectures de déploiement différentes. Par exemple, la base de données source peut être une base de données en cluster (partagée), tandis que la base de données de destination peut être une simple base de données à un seul fragment.

Désormais, la fonctionnalité “Réplica de” a été améliorée pour permettre réplication entre régions / cloud sur WAN en autorisant la compression du trafic. Vous pouvez désormais déployer deux clusters RLEC dans différentes régions ou clouds et activer la réplication entre les bases de données de ces clusters. Lors de la définition de la réplication, vous pouvez décider si vous souhaitez utiliser la compression des données et contrôler le niveau de compression.

En outre, la fonctionnalité a également été améliorée pour permettre de définir plusieurs bases de données source pour une seule base de données de destination.

Voici un exemple d’architecture qui montre comment plusieurs réplicas dans le même cluster peuvent aider à faire évoluer la charge de lecture, et un réplica dans un autre cluster sur une autre plate-forme cloud peut gérer les lectures à distance ou servir à des fins de reprise après sinistre.

Réplique interrégionale/cloud de

Prise en charge multi-IP et IPv6

Nous avons également ajouté la prise en charge de plusieurs adresses IP par nœud. Vous pouvez désormais définir plusieurs adresses IP par nœud et déterminer celles qui sont utilisées pour le trafic interne du cluster et celles qui sont utilisées pour le trafic du client afin de communiquer avec les points de terminaison de la base de données. Ce faisant, vous pouvez séparer physiquement le trafic de gestion de cluster interne du trafic de la base de données client, ce qui vous permet d’obtenir de meilleures performances de vos bases de données.

Une autre fonctionnalité intéressante qui peut grandement améliorer la sécurité est notre prise en charge des types d’adresses IPv6. Les multiples adresses IP ci-dessus peuvent être soit des adresses de type IPv4 traditionnelles, soit des adresses de type IPv6 plus récentes et plus sécurisées.

Voici un exemple d’architecture qui montre comment plusieurs clients peuvent se connecter au même nœud en utilisant différentes adresses IP ou se connecter à un nœud différent en utilisant IPv6. C’est un excellent moyen de séparer logiquement différentes connexions client à une base de données ou de répartir le trafic.

Prise en charge multi-IP et IPv6

AOF amélioré

AOF (Append Only File) est un mécanisme de persistance très utile pour Redis. Lorsque vous l’utilisez, chaque commande d’écriture sur Redis est accumulée dans le fichier de persistance, vous pouvez donc “rejouer” toutes ces commandes si jamais vous avez besoin de restaurer les données à partir de la persistance. Comme vous pouvez l’imaginer, ce fichier peut devenir volumineux avec le temps, c’est pourquoi il existe un mécanisme de réécriture AOF, qui peut être déclenché de temps en temps pour réduire la taille du fichier AOF.

C’est un excellent mécanisme, mais il peut parfois être moins qu’optimal et entraîner une surcharge du système de stockage, ce qui retarde l’exécution de Redis et ralentit votre base de données.

Dans cette version, nous avons apporté diverses améliorations au mécanisme de réécriture AOF, et également introduit le concept de SLA AOF dans lequel vous pouvez définir la taille du fichier AOF et les seuils de temps de chargement pour contrôler le déclenchement des réécritures AOF.

De plus, nous avons ajouté des alertes liées à AOF qui aident à identifier les problèmes d’espace disque et de dégradation des performances d’E/S du disque.

Prise en charge des profils cloud et de réseau local

Nous avons de nombreux clients qui exécutent RLEC dans leur propre centre de données sur leur propre réseau, mais nous en avons également beaucoup qui exécutent RLEC sur des plates-formes de cloud public, où la stabilité du réseau est beaucoup moins fiable. Dans un environnement de cloud public, vous préféreriez attendre un peu avant de déclarer un nœud en panne, car il pourrait simplement ne pas répondre en raison d’un problème de réseau temporaire qui pourrait être résolu après quelques secondes. D’un autre côté, dans un environnement stable sur site ou dans un cloud privé, vous préférerez probablement déclarer immédiatement un nœud en panne et déclencher le basculement automatique dès que l’événement se produit.

Pour permettre aux clients d’optimiser leurs déploiements, quel que soit l’environnement sur lequel ils s’exécutent, nous avons introduit le concept de profils d’environnement. Vous pouvez désormais choisir le profil sur lequel vous exécutez, et RLEC s’adaptera pour fournir des performances optimisées et une garantie de haute disponibilité en fonction de votre environnement spécifique.

Comme indiqué ci-dessus, il existe de nombreuses autres fonctionnalités et améliorations intéressantes et remarquables dans cette version, alors assurez-vous de télécharger la nouvelle version à partir de notre page de téléchargementset passez en revue le notes de version.

Nous travaillons maintenant dur sur d’autres fonctionnalités intéressantes pour la prochaine version – restez à l’écoute.

Si vous avez des questions ou des commentaires, n’hésitez pas à me contacter à : itai.raz@redis.com.

Development Source

Related Posts

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

Redis à AWS re:Invent 2015

Redis à AWS re:Invent 2015

No Comment

Laisser un commentaire

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