Redis Cloud disponible dans plusieurs zones de disponibilité

Redis Cloud disponible dans plusieurs zones de disponibilité

Nous venons d’annoncer le lancement de nos Multiple Availability Zones pour les clouds Redis & Memecached de Garantia Data. Pour savoir comment fonctionne notre solution Multi-AZ, continuez à lire. Les zones de disponibilité sont utilisées pour segmenter la structure physique du centre de données d’un cloud (ou région) en sections indépendantes afin de compartimenter l’impact des catastrophes majeures. Les pratiques modernes de haute disponibilité utilisent plusieurs zones de disponibilité à partir desquelles exécuter plusieurs instances de l’application. Ceci est fait pour qu’une défaillance d’une seule zone n’empêche pas l’exécution de l’application à partir des zones survivantes. Selon la nature réelle de la configuration que vous souhaitez “zoner”, l’effort requis pour y parvenir va de trivial à absurdement difficile. Une application typique est généralement un moteur sans état, donc son exécution à partir de plusieurs zones nécessite très peu d’efforts, voire aucun. Les banques de données, en revanche, sont presque toujours avec état et nécessitent donc une forme de cohérence plus difficile à atteindre. Dans le cas des magasins de données en mémoire, le défi est plus grand compte tenu de la volatilité du stockage principal et des taux de mise à jour nettement plus élevés. La description suivante concerne notre solution Redis Multi-AZ, mais elle s’applique également à notre solution Memcached Multi-AZ. Un environnement multi-AZ typique est illustré dans le diagramme ci-dessous. Plusieurs zones de disponibilité : état normal

Comme on peut le voir, dans un état normal, les instances de l’application s’exécutent à partir de la zone A ou à la fois de A et de B. Le magasin de données, cependant, n’est présent que dans la zone A et est utilisé pour servir les instances de l’application dans les deux zones. Cela signifie que le magasin de données peut devenir indisponible si la zone A tombe en panne, laissant les instances d’application survivantes dans la zone B sans leurs données. Dans notre solution multi-AZ, le magasin de données est répliqué de la zone A vers la zone B, comme illustré ici : Zones de disponibilité multiples : banque de données répliquée

Avec notre réplication Multi-AZ, la banque de données active reste dans la zone A. La réplique de la zone B est uniquement mise à jour avec les modifications et maintenue en mode veille tant qu’il n’y a pas de défaillance de zone. Si et quand la zone A échoue, le réplica de secours de la zone B est automatiquement invité à l’état actif et l’application y est basculée, comme suit : Zones de disponibilité multiples : échec et basculement Cela permet au fonctionnement de l’application de continuer sans interruption malgré un événement de défaillance majeur. Le basculement vers le réplica du magasin de données de la zone B est entièrement géré et effectué en externe à votre application, de sorte qu’aucune modification de code/configuration n’est nécessaire, et en mettant à jour les enregistrements DNS du magasin de données, même son URL reste inchangée. L’environnement de basculement dans la zone B continuera à servir le trafic de l’application avec une dégradation des performances minimale et temporaire, le cas échéant, due au renouvellement des connexions à la banque de données. À un moment ultérieur, la zone A sera probablement récupérée par le fournisseur d’infrastructure cloud. Selon notre solution Multi-AZ, une fois que la Zone A sera à nouveau disponible, elle sera reconstruite pour restaurer le déploiement Multi-AZ en prévision de la prochaine panne. En règle générale, les serveurs d’applications seront les premiers à démarrer dans la zone récupérée et se connecteront au réplica du magasin de données désormais actif dans la zone B. De même, aucune modification n’est nécessaire côté client puisque le magasin de données conserve son URL : Zones de disponibilité multiples : récupération d'application

Un peu plus tard, le nouveau réplica de secours de la banque de données dans la zone A terminera sa synchronisation à partir du réplica actif et le flux de flux de réplication de la zone B vers A commencera. À ce stade, la configuration sera entièrement revenue à son état multi-AZ, zone-failure-resilient, comme illustré ici : Zones de disponibilité multiples : récupération de la banque de données

Voici quelques-uns des défis auxquels l’équipe de Garantia Data a dû faire face lorsque nous avons préparé notre service pour prendre en charge plusieurs zones de disponibilité pour Redis et Memcached :

  • En faisant la distinction entre les scissions de réseau ordinaires et les défaillances de zone réelles – comme la première est beaucoup plus courante dans toutes les zones, nous avons développé un mécanisme de commérage spécialisé pour identifier correctement la situation et agir de manière appropriée. Nous avons également conçu la topologie de notre service pour éviter plus facilement les divisions lors d’un scénario de défaillance de zone réel.
  • Assurer la cohérence des données pendant les conditions de fractionnement
  • Réplication des banques de données sur des liaisons réseau inter-zones encombrées
  • Réduire au minimum les écarts entre les ensembles de données répliqués

Toute la bonté de ce travail acharné est maintenant à votre disposition avec la même configuration simple et la même facilité d’utilisation que n’importe quel autre de nos plans. Et il offre l’assurance que la prochaine fois qu’une catastrophe paralysant la zone de disponibilité se produira, vos ensembles de données seront à l’abri des dangers tout en restant pleinement fonctionnels. Pour commencer à utiliser plusieurs zones de disponibilité avec vos clouds Redis et Memcached, cochez simplement la case “Déploiement multi-AZ” la prochaine fois que vous lancerez une nouvelle base de données Redis ou un nouveau compartiment Memcached. Nos plans de zones de disponibilité multiples pour les ensembles de données sont disponibles aujourd’hui dans la région de données us-east d’AWS, et nous avons l’intention d’ajouter des plans pour plus de régions, de clouds et de fournisseurs dans les mois à venir.

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 *