Basculement automatique pour des données cloud en mémoire hautement disponibles

Basculement automatique pour des données cloud en mémoire hautement disponibles

Tout le monde sait que vous devez toujours utiliser une protection, sinon les choses peuvent devenir assez moche rapidement. Dans le monde du cloud, cela se traduit par la résilience aux pannes de notre magasin de données en mémoire, qui détermine efficacement si et comment il résistera et se remettra des scénarios de panne.

Alors que pour certaines applications, la perte de certaines ou de toutes les données est un mode de fonctionnement acceptable, pour la plupart des applications, la persistance des données et la haute disponibilité sont des exigences strictes. Nous avons abordé ce point dans le passé des postesmais compte tenu de son importance, nous souhaitons partager davantage sur le maintien de la haute disponibilité (HA) des datastores en mémoire dans les environnements Cloud.

Avec des technologies telles que Redis, il est possible d’utiliser des outils prêts à l’emploi pour atteindre ces objectifs. Ces capacités enracinées fournissent un bon point de départ, mais ne suffisent généralement pas, en particulier lorsqu’elles sont utilisées dans des environnements Cloud.

Redis, par exemple, est équipé d’une réplication intégrée, mais peut toujours subir des effets indésirables sur la stabilité et les performances lorsqu’il est utilisé sur un réseau encombré. Redis’ Sentinelle relève le défi HA mais n’a pas encore stabiliser et mûrir ainsi que d’être intégré à la plupart bibliothèques clientes.

Les mécanismes de persistance des données intégrés de Redis (à savoir les instantanés et l’ajout de fichiers uniquement) sont très fiables, mais peuvent entraîner une grave baisse des performances lorsqu’ils sont utilisés avec un stockage en nuage. Contrairement à Redis, Memcached n’offre aucune fonctionnalité HA en soi. Deux approches prévalent lors de son augmentation pour atteindre une haute disponibilité : remis en cache ou la réplication côté client. Il y a cependant des inconvénients à chacune de ces approches, ce qui les rend inapplicables pour certaines exigences d’application.

Les principaux handicaps de Repcached sont son incapacité à évoluer et sa disponibilité exclusive pour Memcached v1.2.x, et la multiplicité des écritures côté client peut devenir un frein majeur aux performances. Afin de disposer d’une configuration de niveau de production réelle déployée sur des ressources de calcul cloud, vous devez l’assaisonner avec des auspices de disponibilité supplémentaires.

In Memory Cloud Datastores High Availability System

Réplication et basculement automatique

Nos services Redis & Memcached Cloud prennent en compte plusieurs scénarios de panne et fournissent des mécanismes de disponibilité pour tous les gérer. La forme la plus simple de menace à la disponibilité que nous éliminons est la défaillance d’un seul nœud (c’est-à-dire une instance de serveur cloud).

Les blocs de bas niveau dans l’environnement cloud global, les nœuds peuvent échouer et échouent régulièrement. Nous protégeons nos bases de données de telles défaillances en les répliquant sur deux nœuds ou plus, de sorte que lorsqu’un nœud meurt, il y ait au moins une réplique disponible sur un nœud différent. Notre service détecte automatiquement ces défaillances, promeut de manière transparente une réplique à utiliser et fournit un remplacement au nœud défaillant.

Pour nos plans réguliers, nous offrons le choix entre deux modes de réplication : en mémoire et sur disque. Lors de l’utilisation de la réplication en mémoire, les répliques de la base de données sont conservées chargées et prêtes pour une utilisation immédiate dans la mémoire principale des nœuds de secours. Le basculement vers une réplique en mémoire est presque instantané et, dans la plupart des cas, l’application ne détecte aucun effet notable pendant ou après le basculement.

Nous vous recommandons d’utiliser la réplication en mémoire pour les applications critiques, mais les ressources RAM sont nettement plus coûteuses que l’espace disque. Par conséquent, nous prenons également en charge l’utilisation de la réplication sur disque sans frais supplémentaires. Nous réalisons une réplication sur disque en stockant la base de données sur le stockage local du nœud actif et en la copiant sur le stockage local d’un nœud de sauvegarde inactif. Lorsque le basculement est déclenché par le service, le nœud de sauvegarde charge la base de données stockée sur disque et prend la place de la réplique désormais inactive. Bien sûr, les temps de réponse et d’accès au stockage sont intrinsèquement plus élevés par ordre de grandeur que ceux requis pour accéder à la mémoire, de sorte que la durée du basculement est plus élevée que la probabilité de perte de données non synchronisées.

Plusieurs zones de disponibilité

Certains des plans que nous proposons peuvent survivre à la panne d’une zone de disponibilité entière et continuer à fonctionner normalement avec seulement un minimum de perturbations. Ces instances, créées à l’aide de plans multi-AZ, ont leurs répliques conservées dans différentes zones de disponibilité. Si une zone entière tombe en panne, notre mécanisme de basculement automatique bascule pour servir les données de la réplique restante. Pour des raisons de performances, la réplication sur disque n’est pas proposée pour nos plans multi-AZ et seule la réplication en mémoire est prise en charge.

Persistance des données et récupération automatique

Un autre scénario de panne, plus rare mais toujours probable, est celui dans lequel les deux répliques sont affectées. Dans de tels cas, une simple réplication n’aidera pas car il ne reste plus de survivants. Nous traitons de tels événements en utilisant des mécanismes natifs de persistance des données, à savoir Append Only Files et des instantanés, en plus des services de stockage en nuage persistants tels que l’EBS d’AWS. Nous utilisons un outil de récupération de cluster pour reconstruire les configurations endommagées et amorcer les ensembles de données à partir du stockage lorsque de telles pannes spectaculaires se produisent.

Sauvegardes

Le dernier sur la liste des échecs possibles est le scénario apocalyptique dans lequel une partie importante du cloud – comme un centre de données entier (aka zone) ou même plusieurs centres de données (aka région de données) – se désintègre dans l’air. De telles pannes ont été subies pas moins de 4 fois l’an dernier par le principal fournisseur de cloud du marché, AWS.

Ces effondrements sont impossibles à contre-mesurer (au moins dans la région affectée du cloud), mais notre service en protège vos bases de données en maintenant des sauvegardes quotidiennes et à la demande automatisées vers un stockage distant (c’est-à-dire un serveur S3 ou FTP). Ceux-ci permettent à notre outil de récupération de cluster de restaurer le contenu de vos bases de données ravagées après avoir terminé la récupération et la configuration des ressources d’infrastructure.

Éclatement extrême

En fonction de leur plan et de leurs besoins, les ensembles de données hébergés dans notre service sont partagés en arrière-plan pour permettre une évolutivité quasi infinie.

Un sous-produit bienvenu de cette conception est un gain positif dans la disponibilité globale de la base de données :

  • Le risque d’échec de l’intégralité de l’ensemble de données est réduit en raison de la répartition des fragments sur plusieurs nœuds.
  • Lorsqu’un nœud tombe en panne et supprime un fragment avec lui, la perte de données potentielle est minimisée en raison de l’espace d’adressage et du jeu de données relativement plus petits du fragment.
  • Le temps de récupération global de la base de données, même dans les cas les plus extrêmes, est plus court par rapport à une base de données non partitionnée, car la base de données partitionnée est récupérée par plusieurs nœuds en parallèle.

Conclusion

Garantir la disponibilité des datastores en mémoire dans l’environnement turbulent des clouds de calcul modernes n’est pas une mince tâche. La mise en place d’une configuration résiliente capable de récupérer des pannes pour maintenir le fonctionnement continu de l’application est tout sauf un effort ponctuel et nécessite une surveillance et une maintenance constantes.

Bien que l’approche Do-It-Yourself puisse convenir à certains, notre service offre (entre autres avantages) une haute disponibilité en un clic pour ceux qui souhaitent utilisation une banque de données en mémoire plutôt que de la gérer.

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 *