Apache HBase Replication est un moyen de copier des données d'un cluster HBase vers un cluster HBase différent et éventuellement distant. Il fonctionne sur le principe que les transactions du cluster d'origine sont poussées vers un autre cluster. Dans le jargon HBase, le cluster effectuant le push est appelé le maître, et celui qui reçoit les transactions est appelé l'esclave. Cette poussée de transactions est effectuée de manière asynchrone et ces transactions sont regroupées dans une taille configurable (la valeur par défaut est de 64 Mo). Le mode asynchrone entraîne une surcharge minimale sur le maître, et l'expédition des modifications dans un lot augmente le débit global.
Cet article de blog traite des cas d'utilisation possibles, de l'architecture sous-jacente et des modes de réplication HBase tels qu'ils sont pris en charge dans CDH4 (basé sur la version 0.92). Nous discuterons de la configuration de la réplication, de l'amorçage et de la tolérance aux pannes dans un article de blog de suivi.
Cas d'utilisation
La réplication HBase prend en charge la réplication des données dans les centres de données. Cela peut être utilisé pour les scénarios de reprise après sinistre, où nous pouvons faire en sorte que le cluster esclave serve le trafic en temps réel au cas où le site maître serait en panne. Étant donné que la réplication HBase n'est pas destinée au basculement automatique, le fait de passer du cluster maître au cluster esclave afin de commencer à servir le trafic est effectué par l'utilisateur. Ensuite, une fois que le cluster maître est à nouveau opérationnel, vous pouvez effectuer une tâche CopyTable pour copier les deltas sur le cluster maître (en fournissant les horodatages de démarrage/d'arrêt) comme décrit dans l'article de blog CopyTable.
Un autre cas d'utilisation de la réplication est lorsqu'un utilisateur souhaite exécuter des tâches MapReduce intensives en charge sur son cluster HBase ; on peut le faire sur le cluster esclave tout en supportant une légère diminution des performances sur le cluster maître.
Architecture
Le principe sous-jacent de la réplication HBase est de rejouer toutes les transactions du maître vers l'esclave. Cela se fait en rejouant les WALEdits (entrées du journal Write Ahead) dans les WAL (Write Ahead Log) du cluster maître, comme décrit dans la section suivante. Ces WALEdits sont envoyés aux serveurs de la région du cluster esclave, après filtrage (qu'une modification spécifique soit destinée à la réplication ou non) et expédiés dans une taille de lot personnalisée (la valeur par défaut est de 64 Mo). Dans le cas où le WAL Reader atteint la fin du WAL actuel, il expédiera tous les WALEdits qui ont été lus jusque-là. Comme il s'agit d'un mode de réplication asynchrone, le cluster esclave peut être en retard par rapport au maître dans une application lourde en écriture de l'ordre de quelques minutes.
WAL/WALEdits/Memstore
Dans HBase, toutes les opérations de mutation (Puts/Deletes) sont écrites dans un magasin de mémoire qui appartient à une région spécifique et également ajoutées à un fichier journal d'écriture anticipée (WAL) sous la forme d'un WALEdit. Un WALEdit est un objet qui représente une transaction et peut avoir plus d'une opération de mutation. Étant donné que HBase prend en charge les transactions au niveau de la ligne unique, un WALEdit ne peut avoir des entrées que pour une seule ligne. Les WAL sont renouvelés à plusieurs reprises après une période de temps configurée (la valeur par défaut est de 60 minutes), de sorte qu'à tout moment, il n'y a qu'un seul WAL actif par serveur de région.
IncrementColumnValue, une opération CAS (vérifier et remplacer), est également convertie en Put lorsqu'elle est écrite dans le WAL.
Un memstore est une carte triée en mémoire contenant les valeurs clés de la région de composition ; il y a un memstore pour chaque famille de colonnes par région. Le magasin de mémoire est vidé sur le disque en tant que HFile une fois qu'il atteint la taille configurée (la valeur par défaut est de 64 Mo).
L'écriture sur WAL est facultative, mais elle est nécessaire pour éviter la perte de données car en cas de panne d'un serveur de région, HBase peut perdre tous les magasins de mémoire hébergés sur ce serveur de région. En cas de défaillance du serveur de région, ses WAL sont rejoués par un processus de fractionnement de journal pour restaurer les données stockées dans les WAL.
Pour que la réplication fonctionne, l'écriture sur les WAL doit être activée.
Identifiant de cluster
Chaque cluster HBase a un clusterID, un type d'UUID généré automatiquement par HBase. Il est conservé dans le système de fichiers sous-jacent (généralement HDFS) afin qu'il ne change pas entre les redémarrages. Ceci est stocké dans le znode /hbase/hbaseid. Cet identifiant est utilisé pour réaliser la réplication maître-maître/acyclique. Un WAL contient des entrées pour un certain nombre de régions qui sont hébergées sur le serveur de région. Le code de réplication lit toutes les valeurs-clés et filtre les valeurs-clés qui sont ciblées pour la réplication. Pour ce faire, il examine l'attribut de famille de colonnes de la valeur-clé et le fait correspondre à la structure de données de carte de famille de colonnes de WALEdit. Dans le cas où une valeur-clé spécifique est étendue à la réplication, il modifie le paramètre clusterId de la valeur-clé en identifiant de cluster HBase.
Source de réplication
Le ReplicationSource est un objet Thread java dans le processus regionserver et est responsable de la réplication des entrées WAL vers un cluster esclave spécifique. Il a une file d'attente prioritaire qui contient les fichiers journaux qui doivent être répliqués. Dès qu'un journal est traité, il est supprimé de la file d'attente. La file d'attente prioritaire utilise un comparateur qui compare les fichiers journaux en fonction de leur horodatage de création (qui est ajouté au nom du fichier journal) ; ainsi, les journaux sont traités dans le même ordre que leur heure de création (les journaux plus anciens sont traités en premier). S'il n'y a qu'un seul fichier journal dans la file d'attente prioritaire, il ne sera pas supprimé car il représente le WAL actuel.
Rôle du gardien de zoo
Zookeeper joue un rôle clé dans la réplication HBase, où il gère/coordonne presque toutes les principales activités de réplication, telles que l'enregistrement d'un cluster esclave, le démarrage/l'arrêt de la réplication, la mise en file d'attente de nouveaux WAL, la gestion du basculement de serveur de région, etc. Quorum Zookeeper (au moins 3 nœuds ou plus) afin qu'il soit opérationnel tout le temps. Zookeeper doit être exécuté indépendamment (et non par HBase). La figure suivante montre un exemple de structure de znodes liés à la réplication dans le cluster maître (le texte après deux-points correspond aux données du znode) :
/hbase/hbaseid: b53f7ec6-ed8a-4227-b088-fd6552bd6a68 …. /hbase/rs/foo1.bar.com,40020,1339435481742: /hbase/rs/foo2.bar.com,40020,1339435481973: /hbase/rs/foo3.bar.com,40020,1339435486713: /hbase/replication: /hbase/replication/state: true /hbase/replication/peers: /hbase/replication/peers/1: zk.quorum.slave:281:/hbase /hbase/replication/rs: /hbase/replication/rs/foo1.bar.com.com,40020,1339435084846: /hbase/replication/rs/foo1.bar.com,40020,1339435481973/1: /hbase/replication/rs/foo1.bar.com,40020,1339435481973/1/foo1.bar.com.1339435485769: 1243232 /hbase/replication/rs/foo3.bar.com,40020,1339435481742: /hbase/replication/rs/foo3.bar.com,40020,1339435481742/1: /hbase/replication/rs/foo3.bar.com,40020,1339435481742/1/foo3.bar..com.1339435485769: 1243232 /hbase/replication/rs/foo2.bar.com,40020,1339435089550: /hbase/replication/rs/foo2.bar.com,40020,1339435481742/1: /hbase/replication/rs/foo2.bar.com,40020,1339435481742/1/foo2.bar..com.13394354343443: 1909033
Figure 1. Hiérarchie des znodes de réplication
Conformément à la figure 1, il existe trois serveurs régionaux dans le cluster maître, à savoir foo[1-3].bar.com. Il existe trois znodes liés à la réplication :
- état :Ce znode indique si la réplication est activée ou non. Toutes les étapes fondamentales (telles que la mise en file d'attente d'un journal nouvellement roulé dans une file d'attente de réplication, la lecture d'un fichier journal pour effectuer des envois WALEdits, etc.), vérifiez cette valeur booléenne avant le traitement. Ceci est défini par la définition de la propriété « hbase.replication » sur true dans hbase-conf.xml. Une autre façon de modifier sa valeur consiste à utiliser la commande « démarrer/arrêter la réplication » dans le shell hbase. Cela sera abordé dans le deuxième article de blog.
- pairs :Ce znode a les pairs/esclaves connectés comme enfants. Dans la figure, il y a un esclave avec le peerId =1, et sa valeur est la chaîne de connexion (Zookeeper_quorum_of_slave:Zookeeper_client_port:root_hbase_znode), où Zookeeper_quorum_of_slave est une liste de serveurs zookeeper séparés par des virgules. Le nom de znode peerId est le même que celui donné lors de l'ajout d'un pair.
- rs :Ce znode contient une liste des serveurs de région actifs dans le cluster maître. Chaque znode de serveur de région a une liste de WAL qui doivent être répliqués, et la valeur de ces znodes de journal est soit null (au cas où le journal n'est pas encore ouvert pour la réplication), soit le décalage d'octet au point où le journal a été lu. La valeur de décalage d'octet pour un znode WAL indique le décalage d'octet du fichier WAL correspondant jusqu'auquel il a été lu et répliqué. Comme il peut y avoir plus d'un cluster esclave et que la progression de la réplication peut varier d'un cluster à l'autre (un peut être en panne par exemple), tous les WAL sont autonomes dans un znode peerId sous rs. Ainsi, dans la figure ci-dessus, les znodes WAL sont sous le sont /rs//1, où "1" est le peerId.
Modes de réplication
Il existe trois modes de configuration de la réplication HBase :
- Maître-Esclave :dans ce mode, la réplication est effectuée dans une seule direction, c'est-à-dire que les transactions d'un cluster sont poussées vers un autre cluster. Notez que le cluster esclave est comme n'importe quel autre cluster et peut avoir ses propres tables, trafic, etc.
- Maître-maître :dans ce mode, la réplication est envoyée dans les deux sens, pour des tables différentes ou identiques, c'est-à-dire que les deux clusters agissent à la fois en tant que maître et esclave. Dans le cas où ils répliquent la même table, on peut penser que cela peut conduire à une boucle sans fin, mais cela est évité en définissant le clusterId d'une mutation (Put/Delete) sur le clusterId du cluster d'origine. La figure 2 explique cela en utilisant deux clusters, à savoir le Soleil et la Terre. Dans la figure 2, nous avons deux blocs représentant les deux clusters HBase. Ils ont respectivement le clusterId 100 et 200. Chacun des clusters a une instance de ReplicationSource, correspondant au cluster esclave vers lequel il souhaite se répliquer ; il connaît les cluster #Ids des deux clusters.
Figure 2. Soleil et Terre, deux clusters HBase
Disons que cluster#Sun reçoit une nouvelle mutation valide M sur une famille de tables et de colonnes qui est destinée à la réplication dans les deux clusters. Il aura un clusterID par défaut (0L). L'instance source de réplication ReplicationSrc-E définira son cluster#Id égal à l'ID de l'expéditeur (100) et l'expédie au cluster#Earth. Lorsque le cluster#Earth reçoit la mutation, il la rejoue et la mutation est enregistrée dans son WAL, selon le flux normal. Le cluster#Id de la mutation est conservé intact dans ce fichier journal au cluster#Earth. égal à cluster#Sun). Puisqu'ils sont égaux, il ignorera cette entrée WALEdit.
- Cyclique :dans ce mode, plus de deux clusters HBase participent à la configuration de la réplication, et l'on peut avoir différentes combinaisons possibles de configuration maître-esclave et maître-maître entre deux clusters. Les deux ci-dessus couvrent bien ces cas; une situation de coin est lorsque nous avons mis en place un cycle
Figure 3. Configuration d'une réplication circulaire
La figure 3 montre une configuration de réplication circulaire, où le cluster#Sun se réplique vers le cluster#Earth, le cluster#Earth se réplique vers le cluster#Venus et le cluster#Venus se réplique vers le cluster#Sun.
Disons cluster#Sun reçoit une nouvelle mutation M et est limité à la réplication dans tous les clusters ci-dessus. Il sera répliqué sur cluster#Earth comme expliqué ci-dessus dans la réplication maître maître. L'instance source de réplication au cluster#Earth, ReplicationSrc-V, lira le WAL et verra la mutation et la répliquera au cluster#Venus. Le cluster#Id de la mutation est conservé intact (à partir du cluster#Sun), au niveau du cluster#Venus. Au niveau de ce cluster, l'instance source de réplication pour le cluster#Sun, ReplicationSrc-S, verra que la mutation a le même clusterId que son slaveCluster# (à partir du cluster#Sun), et par conséquent, ignorera cela de la réplication.
Conclusion
HBase Replication est une fonctionnalité puissante qui peut être utilisée dans un scénario de reprise après sinistre. Il a été ajouté en tant que fonctionnalité d'aperçu dans la version 0.90 et a évolué avec HBase en général, avec l'ajout de fonctionnalités telles que la réplication maître-maître, la réplication acyclique (toutes deux ajoutées dans la version 0.92) et l'activation-désactivation de la réplication au niveau homologue. (ajouté en 0.94).
Dans le prochain article de blog, nous discuterons de diverses fonctionnalités opérationnelles telles que la configuration, etc., et d'autres pièges avec la réplication HBase.
