Base de données opérationnelle CDP (COD) est une base de données transactionnelle autonome alimentée par Apache HBase et Apache Phoenix. C'est l'un des principaux services de données qui s'exécute sur Cloudera Data Platform (CDP) Public Cloud. Vous pouvez accéder à COD directement depuis votre console CDP. Avec COD, les développeurs d'applications peuvent désormais tirer parti de la puissance de HBase et de Phoenix sans les frais généraux souvent liés au déploiement et à la gestion. COD est facile à provisionner et autogéré, ce qui signifie que les développeurs peuvent provisionner une nouvelle instance de base de données en quelques minutes et commencer à créer rapidement des prototypes. Des fonctionnalités autonomes telles que la mise à l'échelle automatique, la réparation automatique et le réglage automatique garantissent qu'il n'y a pas de gestion et d'administration de la base de données à se soucier.
Dans ce blog, nous expliquerons comment la base de données opérationnelle CDP peut offrir une haute disponibilité pour vos applications lorsqu'elles sont exécutées sur plusieurs zones de disponibilité dans AWS.
Pour bien comprendre ce qu'est un déploiement multi-AZ Cela signifie que pour votre infrastructure, il est essentiel de reconnaître comment Amazon Web Services est configuré à travers le monde et donc comment il fournit les services de redondance, quel que soit votre emplacement. Comme indiqué dans la documentation officielle d'Amazon, le cloud AWS est composé d'un certain nombre de régions, qui sont des emplacements physiques à travers le monde. Bien que les pannes AZ ne soient pas officiellement suivies, les clients de Cloudera ont signalé avoir subi des pannes AZ 1 à 2 fois par an. Ainsi, les déploiements étendus multi-AZ sont nécessaires pour atteindre une disponibilité de plus de 99,95 %.
Chaque région comprend un certain nombre de centres de données physiques distincts, appelés zones de disponibilité (AZ) . Chaque AZ est une installation autonome avec ses propres capacités d'alimentation, de connectivité et de mise en réseau. La plupart des régions abritent chacune 2 à 3 zones de disponibilité différentes, offrant une redondance adéquate au sein d'une région donnée (une AZ est représentée par un code de région suivi d'une lettre d'identification ; par exemple, us-west-1a) .
Cependant, cette redondance ne s'applique qu'à la couche de stockage (S3) et n'existe pas pour les machines virtuelles utilisées pour votre instance de base de données. Si quelque chose devait provoquer une panne dans la zone de disponibilité où résident vos instances de serveur, votre base de données cesserait de fonctionner, car toute l'infrastructure de calcul serait hors ligne.
C'est là qu'intervient le déploiement multi-AZ. Un déploiement multi-AZ signifie que l'infrastructure de calcul pour les serveurs maître et de région de HBase est répartie sur plusieurs zones de disponibilité, ce qui garantit qu'en cas de panne d'une seule zone de disponibilité, seule une partie des serveurs de région sera impactés et les clients basculeront automatiquement vers les serveurs restants dans les AZ disponibles. De même, le maître de sauvegarde (en supposant que le maître principal était dans l'AZ ayant une panne) prendra automatiquement le rôle du maître défaillant puisqu'il est déployé dans un AZ distinct du serveur maître principal. Tout cela est automatique et ne nécessite aucune configuration, aucune gestion et aucune action d'un point de vue utilisateur / administratif. Cela fonctionne simplement pour s'assurer qu'une application ne subit pas de panne en raison de la perte d'un seul AZ.
Démo
Les bases de données COD nouvellement créées tireront automatiquement parti de toutes les zones de disponibilité configurées dans l'environnement. Il est donc crucial de configurer l'environnement avec les zones que nous aimerions utiliser.
Par exemple, nous avons un environnement avec les AZ suivantes :us-west-1a, us-west-1b et us-west-1c. Lorsque nous déployons une base de données COD, elle se déploie automatiquement de manière multi-AZ — il n'y a rien à faire ! Examinons les coulisses et voyons ce qu'il y a sur la console AWS.
COD s'assure que les nœuds de travail sont répartis de manière égale sur les AZ configurées. (Les maîtres et le leader sont également déployés dans différentes AZ afin de fournir une haute disponibilité pour le quorum ZooKeeper.)
Apache HBase a déjà des capacités de basculement intégrées, donc dans le cas où un AZ se déconnecte, le système est déjà en place pour continuer instantanément et automatiquement les services de votre base de données.
Afin d'ajouter un peu plus de plaisir, exécutons un simple test de charge HBase pendant nos tests. HBase dispose d'un outil de test de charge intégré que nous pouvons utiliser pour un test d'écriture de longue durée :
hbase ltt -write 10:1024:10 -num_keys 10000000
Simulons maintenant un échec AZ et voyons ce qui se passe. Pour ce faire, le moyen le plus simple consiste à ajouter une nouvelle ACL réseau qui désactive le trafic entrant et sortant d'un sous-réseau donné dans des conditions similaires à une véritable panne AWS.
Dans la première minute, nous ne voyons rien de particulièrement intéressant sur la page d'état, car du point de vue de COD, la base de données est toujours saine.
Mais remarqué que le client a cessé de progresser.
Au bout de 10 à 20 secondes, le maître se rend compte que certains des serveurs de la région sont morts.
Si la panne affecte le maître actif, HBase basculera automatiquement vers la sauvegarde qui reprendra le rôle après 10-20 secondes..
L'échec ne prend pas trop de temps, après 2-3 minutes et quelques erreurs de région transitoires, le client est capable de progresser à nouveau. Le maître a dû faire la transition des régions mortes vers des serveurs de région actifs.
Pour simuler la fin de la panne, annulons la création de l'ACL réseau en la supprimant. Les serveurs de région se reconnectent au maître.
Nous sommes maintenant de retour là où nous avons commencé. COD s'est complètement remis de la panne. Dans les demandes d'écriture, nous pouvons voir deux baisses :la première est lorsque le client est passé aux serveurs de région actifs restants, la seconde un peu plus tard lorsque l'équilibreur de charge de HBase a ramené les régions sur les serveurs reconnectés.
DCO sur HDFS
Le stockage d'objets dans le cloud est la couche de stockage par défaut pour COD et répartit les données sur 3 zones de disponibilité en arrière-plan et rééquilibrera en arrière-plan. HBase n'a qu'à faire un peu de ménage (transition de région) pour desservir les régions par les serveurs restants, ce qui en fait une opération relativement rapide.
Pour les cas d'utilisation hautes performances, COD prend en charge l'utilisation de HDFS comme stockage sous-jacent. Dans ce paradigme de déploiement, nous configurons automatiquement la reconnaissance des racks HDFS pour la tolérance aux pannes en plaçant une réplique de bloc sur un rack différent et en mappant les racks aux zones de disponibilité. Cela assure la disponibilité des données en cas de défaillance d'un commutateur réseau ou d'une partition au sein du cluster. Ainsi, le comportement dans la démo ci-dessus est très similaire à ce que vous verriez lors du déploiement de COD avec HDFS.
Résumé
Le déploiement multi-AZ est crucial pour les bases de données hautement disponibles et maintenant COD le prend en charge dans AWS en tant qu'aperçu technique dans les coulisses sans frais supplémentaires. Il rend votre charge de travail opérationnelle plus robuste et fiable sans aucune configuration supplémentaire. Il sera à la fois généralement disponible et prendra bientôt en charge d'autres fournisseurs de cloud (Microsoft, Google).
Contactez votre équipe de compte Cloudera si vous souhaitez en savoir plus sur la migration de votre déploiement de HBase vers la base de données opérationnelle CDP dans le cloud public ou essayez-le avec le Cloudera Test Drive.
