Dans ce précédent article de blog, nous avons fourni un aperçu de haut niveau du plug-in de réplication Cloudera, expliquant comment il apporte une réplication multiplateforme avec peu de configuration. Dans cet article, nous expliquerons comment ce plugin peut être appliqué dans les clusters CDP et expliquerons comment le plugin permet une authentification forte entre des systèmes qui ne partagent pas la confiance mutuelle en matière d'authentification.
Utilisation du plug-in de réplication de base de données opérationnelle
Le plug-in de réplication de base de données opérationnelle est disponible à la fois en tant que plug-in autonome et installé automatiquement via Cloudera Replication Manager. Le plug-in permet aux clients de configurer la réplication en temps quasi réel des données HBase des clusters CDH/HDP/AWS EMR/Azure HDInsight vers CDP Private Cloud Base et/ou CDP Operational Database (COD) dans le cloud public. Il est également déployé automatiquement lors de l'utilisation de Cloudera Replication Manager pour configurer la réplication entre CDP Private Cloud Base et COD ou entre les instances COD dans le Public Cloud. Cloudera Replication Manager permet également de combiner la fonctionnalité d'instantané HBase avec ce plugin pour gérer également la réplication des données préexistantes dans une seule configuration.
Pour les instructions d'installation, veuillez vous référer à la politique de réplication HBase sujet sur Replication Manager documentation officielle.
Pour les anciennes versions CDH/HDP, le plug-in est fourni sous forme de colis à installer uniquement dans le cluster hérité.
- CDH 5.x
- CDH 6.x
- HDP 2.6
- HDP 3.1
- EMR 5.x &6.x
Le colis est verrouillé en version avec les fichiers binaires spécifiques à la version. Pour chacune des versions mentionnées ci-dessus, il convient de l'acquérir par cluster. Contactez votre équipe commerciale Cloudera si vous souhaitez en obtenir un.
Détails de mise en œuvre
L'obstacle résolu par le plug-in de réplication de base de données opérationnelle est l'authentification mutuelle entre clusters sous différentes configurations de sécurité. Rappelant ce billet de blog précédent, la réplication par défaut HBase nécessite que les deux clusters ne soient pas du tout configurés pour la sécurité, ou soient tous deux configurés avec la sécurité. Dans ce dernier cas, les deux clusters doivent être soit dans le même domaine Kerberos, soit avoir une authentification entre domaines définie sur le système Kerberos. Ce serait un défi supplémentaire dans le contexte du CDP, où chaque environnement s'exécute sur un domaine de sécurité autonome. Pour comprendre cela plus en détail, nous devons examiner comment la sécurité Apache HBase est implémentée.
Utiliser SASL pour établir la confiance
Dans la réplication HBase, les RegionServers du cluster source contactent les RegionServers du cluster cible via des connexions RPC. Lorsque la sécurité est activée, l'authentification est effectuée lors de la phase d'établissement de la connexion RPC à l'aide de la structure Simple Authentication and Security Layer (SASL). HBase fournit déjà les éléments intégrés suivants Authentification SASL mécanismes :kerberos, digest et simples. Lorsque kerberos est activé, les informations d'identification du cluster source seront attendues par le cluster cible, qui validera ensuite ces informations d'identification par rapport à son propre KDC, à l'aide du kerberos SASL mécanisme. Cela repose sur kerberos GSSAPI mise en œuvre pour authentifier les informations d'identification fournies par rapport au KDC du cluster cible, par conséquent, la confiance pour le principal du cluster source doit avoir été implémentée au niveau du système kerberos, soit en ayant les deux informations d'identification des clusters sur le même domaine, soit en faisant en sorte que le KDC du cluster cible fasse confiance aux informations d'identification de domaine du cluster source (une approche communément appelée cross-realm authentification).
Étendre l'authentification HBase SASL
Heureusement, SASL est conçu pour permettre des implémentations d'authentification personnalisées. Cela signifie qu'une solution basée sur SASL pourrait être conçue, si un mécanisme SASL supplémentaire pouvait être connecté à l'ensemble des options intégrées mentionnées ci-dessus. Dans ce but, Cloudera a proposé une refactorisation de la couche RPC de HBase, qui a été examinée et acceptée par la communauté Apache HBase dans HBASE-23347 .
Mécanisme SASL enfichable
Avec les changements introduits par HBASE-23347 , des mécanismes d'authentification SASL supplémentaires peuvent être définis via la configuration HBase pour être utilisés par la couche RPC. Les connexions RPC entrantes définissent le type SASL spécifique dans l'en-tête, puis le serveur RPC sélectionne l'implémentation spécifique pour effectuer l'authentification proprement dite :
Plug-in de réplication de base de données opérationnelle implémente son mécanisme SASL personnalisé, permettant aux clusters sur différents domaines Kerberos de communiquer avec des efforts de configuration transparents (sans avoir besoin de kerberos cross-realm ). Il étend la réplication HBase afin que la source crée un jeton SASL de Replication Plugin type personnalisé, avec les informations d'identification d'un utilisateur de machine prédéfini sur le cluster COD cible. Ce type d'utilisateur peut être facilement créé à partir de Cloudera Management Console Interface utilisateur, puis propagé au cluster COD sous-jacent à l'autorité d'authentification kerberos. Des instructions détaillées sur la création d'utilisateurs de machine de réplication sont couvertes dans la section des étapes préalables de la documentation de Cloudera Replication Manager.
Lorsque le serveur RPC de la cible lit le jeton et identifie qu'il s'agit d'un plug-in de réplication type, les informations d'identification associées sont analysées à partir du jeton et utilisées pour l'authentification.
Plug-in de réplication de base de données opérationnelle utilise l'authentification PAM pour valider les informations d'identification de l'utilisateur de la machine. Les clusters COD sont toujours provisionnés avec l'authentification PAM par rapport au domaine de sécurité FreeIPA de l'environnement CDP.
Sécuriser les informations d'identification de l'utilisateur de la machine
Un problème critique dans cette solution est que le cluster source doit obtenir les informations d'identification de l'utilisateur de la machine du cluster cible. Pour des raisons évidentes, cela ne devrait en aucun cas être exposé sur la configuration source. Ces informations d'identification sont également envoyées via le câble dans le jeton SASL au sein de la connexion RPC, elles doivent donc être chiffrées avant la transmission. Le plugin de réplication fournit son propre outil pour générer un jceks fichier stockant les informations d'identification de l'utilisateur de la machine, cryptées. Une fois ce fichier créé, il doit être copié dans les deux clusters et rendu lisible par la hbase utilisateur uniquement. Le schéma ci-dessous montre un aperçu du déploiement du plug-in de réplication de base de données opérationnelle composants s'intégrant aux classes de réplication standard HBase dans le contexte de RegionServers. Les cases roses représentent la réplication et le code de connexion RPC déjà fournis par HBase, tandis que les cases jaunes montrent la couche d'abstraction introduite dans HBASE-23347. Enfin, les classes orange mettent en évidence les artefacts pertinents implémentant le plug-in de réplication de base de données opérationnelle logique.
Conclusion
La réplication est un outil précieux pour la mise en œuvre de solutions de migration DR et DC pour HBase. Il comporte quelques mises en garde, comme indiqué ici, lorsqu'il s'agit de configurations de sécurité des clusters. Pourtant, la capacité de migrer les données des déploiements « sur site » actuels vers des clusters CDP sur le cloud est impérative. Plug-in de réplication de base de données opérationnelle Cloudera apporte de la flexibilité lors de l'intégration de clusters sécurisés, ainsi qu'une meilleure maintenabilité de cette intégration de sécurité, puisqu'elle est entièrement implémentée au niveau HBase, contrairement à kerberos cross-realm, ce qui nécessite des modifications de la définition du système Kerberos, souvent la responsabilité d'une équipe complètement différente, avec ses propres politiques restrictives.
Essayez le modèle de base de données opérationnelle dans Plate-forme de données Cloudera (CDP) !
