Redis Enterprise Kubernetes Release sur Pivotal Container Service ?

Redis Enterprise Kubernetes Release sur Pivotal Container Service ?

Au cours des derniers mois, notre équipe s’est occupée de déployer Entreprise Redis sur Kubernetes. Notre voyage a commencé par l’écriture d’un simple manette pour la version Kubernetes de Redis Enterprise. Quelques mois plus tard, nous avons présenté Tableau de barre soutien, et au cours des deux derniers mois, nous avons écrit un opérateur pour notre version Kubernetes.

À travers cet article de blog, je souhaite présenter les principes que nous avons utilisés pour déployer la version Kubernetes de Redis Enterprise sur un Pivotal Container Service® groupe.

Pourquoi PKS ?

Il est impératif de gérer les microservices conteneurisés de manière native dans le cloud, et Kubernetes est devenu de facto l’unité de déploiement des architectures de microservices. PKS, une distribution Kubernetes certifiée, peut être utilisée en combinaison avec le Système d’application pivot® (PAS) pour gérer l’ensemble du cycle de vie de votre application. Ces deux plates-formes sont régies par Cloud Foundry® et ÉTALAGES, un outil d’orchestration cloud. Ensemble, ils fournissent une approche efficace pour gérer les services avec état (par exemple, vos bases de données), ainsi que les services sans état (par exemple, vos applications).

Les trois principaux composants de PKS sont :

  • Pivotal Ops Manager – utilisé pour déployer BOSH Director et une tuile PKS ;
  • PKS Client VM – pour les sous-composants tels que UAA CLI, PKS CLI et Kubectl CLI, qui est généralement déployé sur une machine virtuelle distincte
  • “Stemcell” – une image de système d’exploitation personnalisée pour les machines virtuelles gérées par BOSH.

Pour les besoins de cet article de blog, supposons que ces composants sont installés avec succès sur une infrastructure sous-jacente telle que vSphere.

Pourquoi Redis Entreprise ?

Redis Enterprise combine les avantages d’une technologie de base de données de classe mondiale avec l’innovation d’une communauté Redis open source dynamique pour obtenir :

  • Haute disponibilité robuste avec temps de basculement à un chiffre
  • Véritable évolutivité linéaire, offrant plus de 1 million d’opérations/s supplémentaires pour chaque nœud que vous ajoutez au cluster
  • Actif-actif distribué basé sur des types de données répliquées sans conflit (technologie CRDT)
  • Multi-modèle via les modules Redis, qui enrichit les capacités de Redis avec RediRecherche, RéJSON, Graphique Redis, Redis-ML et d’autres
  • Extension DRAM avec Flash/SSD pour réduire les coûts d’infrastructure.

Pourquoi Redis Enterprise sur PKS ?

Nous utilisons quatre principes importants pour Redis Enterprise sur PKS afin de maximiser un déploiement robuste :

  1. Basé sur l’opérateur déploiement avec Statefulset et anti-affinité: Operators nous permet de maintenir un déploiement unifié sur tous les environnements Kubernetes. L’ensemble d’états Kubernetes et l’anti-affinité permettent au nœud Redis Enterprise de résider sur un POD hébergé sur une autre machine virtuelle ou un autre serveur physique. Cette configuration est illustrée ci-dessous :
    |Déploiement basé sur l'opérateur avec diagramme de configuration Statefulset & Anti-Affinity
  2. Stockage persistant en réseau pour Durabilité des données : Pour éviter de perdre des données locales à chaque événement de défaillance de POD, PKS exige que les volumes de stockage soient connectés au réseau pour les instances de calcul. De plus, étant donné que Redis est extrêmement efficace dans la manière dont il utilise le stockage persistant (même lorsqu’un utilisateur choisit de configurer Redis pour écrire chaque modification sur le disque), nous constatons des améliorations significatives des performances avec les environnements PKS typiques. Par rapport à une base de données sur disque qui nécessite plusieurs interactions (dans la plupart des cas) avec un périphérique de stockage pour chaque opération de lecture ou d’écriture, Redis utilise un seul IOPS (dans la plupart des cas) pour une opération d’écriture et zéro IOPS pour une opération de lecture.
    Stockage persistant en réseau pour la durabilité des données : écrivez x100 plus rapidement
    Stockage persistant en réseau pour la durabilité des données : lecture x500 plus rapide
  3. Architecture d’orchestrateur en couches : Nous utilisons cette approche pour traiter toutes les nuances associées à l’exploitation de Redis sur un cluster Kubernetes. Kubernetes est un excellent outil d’orchestration, mais il n’a pas été conçu pour des tâches Redis spécifiques et peut parfois réagir de manière incorrecte aux problèmes internes de Redis. De plus, l’orchestration Kubernetes s’exécute en dehors du déploiement du cluster Redis et peut échouer à déclencher un événement de basculement dans les scénarios de fractionnement du réseau. Notre approche d’architecture en couches surmonte ces problèmes en répartissant les responsabilités entre les choses que Kubernetes fait bien, les choses dans lesquelles le cluster Redis Enterprise est bon et les choses que les deux peuvent orchestrer ensemble. Cette architecture en couches est illustrée ci-dessous :Diagramme d'architecture d'orchestrateur en couches
  4. Déploiement d’instances multiples : Nous avons constaté que la manière traditionnelle de déployer un Redis sur PKS (où chaque POD inclut une seule instance Redis tout en préservant un CPU dédié) est extrêmement inefficace ! Redis est extrêmement rapide et, dans de nombreux cas, ne peut utiliser qu’une fraction du processeur pour fournir le débit demandé. De plus, lors de l’exécution d’un cluster Redis avec plusieurs instances Redis sur plusieurs POD, le réseau PKS (avec ses multiples vSwitches) peut devenir votre goulot d’étranglement. Par conséquent, nous avons adopté une approche différente pour Redis Enterprise sur PKS, dans laquelle chaque POD inclut plusieurs instances Redis (plusieurs services). Cela permet à chaque POD de mieux utiliser les ressources matérielles (CPU, mémoire et réseau), tout en gardant le même niveau d’isolation. Cette approche est illustrée ci-dessous :Diagramme de déploiement d'instances multiples

Premiers pas avec Redis Enterprise sur PKS

L’image docker du déploiement de Redis Enterprise pour PKS se trouve ici. Vous pouvez en savoir plus sur l’architecture de la version de Redis Enterprise Kubernetes ici.

Pour commencer:

  1. Vérifiez que le cluster PKS fonctionne en vérifiant les paramètres suivants.
    $ pks cluster redis
    Nom: redis
    Nom du forfait : grand
    UUID : 5f4af2c0-5330-4dae-bdfc-6251ea3eecf2
    Dernière action : CRÉER
    État de la dernière action : réussi
    Description de la dernière action : Provisionnement d’instance terminé
    Hôte maître Kubernetes : 104.196.4.15
    Port maître Kubernetes : 8443
    Nœuds de travail : 4
    IP(s) maître(s) Kubernetes : 192.168.20.46, 192.168.20.47, 192.168.20.45
  2. Vérifiez que les nœuds PKS gérés par BOSH ont été provisionnés. Par exemple, cette image montre un cluster PKS à quatre nœuds :
    Cluster PKS à quatre nœuds
  3. Déployez votre cluster Redis Enterprise sur PKS : créez une définition de ressource personnalisée (CRD) pour Redis Enterprise sur PKS :
    kubectl apply -f redis-enterprise-crd.ymlDéployez Redis Enterprise Operator sur PKS :
    kubectl apply -f redis-enterprise-operator.ymlUtilisez l’opérateur et le CRD pour déployer un cluster Redis Enterprise sur PKS :
    kubectl apply -f redis-enterprise-cluster.yml
  4. Vérifiez que votre cluster Redis Enterprise est dans un état sain à l’aide de l’interface Web Redis Enterprise qui est exposée sur le port 8443. Cela montre un cluster Redis Enterprise à trois nœuds s’exécutant au-dessus d’un cluster PKS :Cluster Redis Enterprise à trois nœuds s'exécutant sur un cluster PKS
  5. Vérifiez toutes les ressources Redis Enterprise déployées sur le cluster PKS. Cette image montre une empreinte de déploiement Redis Enterprise à trois nœuds :

Empreinte de déploiement Redis Enterprise à trois nœuds

Analyse comparative de Redis Enterprise sur PKS

Afin de mesurer les performances, vous pouvez créer une base de données Redis à l’aide de l’interface utilisateur (ou API) Redis Enterprise avec les paramètres suivants (Remarque : cette configuration suppose qu’il y a suffisamment de cœurs dans le nœud Kubernetes pour prendre en charge le cluster Redis Enterprise. Dans l’exemple ci-dessous, nous utilisé une base de données de 14 partitions) :

Base de données à 14 partitions

Ensuite, déployez memtier_benchmark sur un autre POD sur le même cluster Kubernetes et exécutez memtier_benchmark avec les paramètres suivants :

-d 100 –pipeline=35 -c 10 -t 8 -n 2000000 –ratio=1:5 –key-pattern=G:G –key-stddev=3 –distinct-client-seed –randomize

Utilisez l’écran des métriques dans l’interface utilisateur Redis Enterprise pour surveiller les performances de votre base de données en charge. Comme vous pouvez le voir dans la figure ci-dessous, Redis Enterprise peut facilement atteindre plus de 0,5 million d’opérations/s en utilisant un seul des nœuds de cluster sur l’infrastructure Kubernetes, tout en maintenant une latence inférieure à la milliseconde.

Redis Enterprise peut facilement atteindre plus de 0,5 million d'opérations/s en utilisant un seul des nœuds de cluster sur l'infrastructure Kubernetes, tout en maintenant une latence inférieure à la milliseconde.

Et après?

Dans cet article de blog, nous avons démontré un déploiement simplifié de PKS en déployant toutes les ressources sur un réseau plat. Pour écrire ce blog, nous avons utilisé la version tech-preview de la version Redis Enterprise pour PKS. Alors que nous nous efforçons d’atteindre une disponibilité générale, nous continuerons d’explorer nos efforts d’intégration PKS autour des domaines de la segmentation du réseau ainsi que de la primitive d’entrée Kubernetes. De plus, nous ajouterons bientôt la prise en charge de Actif-Actif des CRDT Redis géo-distribués sur PKS pour servir des applications distribuées à l’échelle mondiale.

Si vous souhaitez commencer à expérimenter notre version Redis Enterprise pour PKS, veuillez contacter expert@redis.com afin que nous puissions vous aider avec vos besoins Redis.

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 *