In diesem vorherigen Blogpost haben wir einen allgemeinen Überblick über das Cloudera Replication Plugin, gegeben erklärt, wie es plattformübergreifende Replikation mit wenig Konfiguration bringt. In diesem Beitrag werden wir behandeln, wie dieses Plugin in CDP-Clustern angewendet werden kann, und erklären, wie das Plugin eine starke Authentifizierung zwischen Systemen ermöglicht, die kein gegenseitiges Authentifizierungsvertrauen teilen.
Verwenden des Betriebsdatenbank-Replikations-Plugins
Das Plug-in für die operative Datenbankreplikation ist sowohl als eigenständiges Plug-in verfügbar als auch automatisch über Cloudera Replication Manager installiert. Das Plug-in ermöglicht es Kunden, die Replikation von HBase-Daten von CDH/HDP/AWS EMR/Azure HDInsight-Clustern nahezu in Echtzeit zu CDP Private Cloud Base und/oder CDP Operational Database (COD) in der Public Cloud einzurichten. Es wird auch automatisch bereitgestellt, wenn Sie Cloudera Replication Manager verwenden, um die Replikation zwischen CDP Private Cloud Base und COD oder zwischen COD-Instanzen in der Public Cloud einzurichten. Cloudera Replication Manager ermöglicht auch die Kombination der HBase-Snapshot-Funktion mit diesem Plugin, um auch die Replikation bereits vorhandener Daten in einem einzigen Setup zu verwalten.
Installationsanweisungen finden Sie in der HBase-Replikationsrichtlinie Thema zu Replication Manager offizielle Dokumentation.
Für Legacy-CDH/HDP-Versionen wird das Plug-in als Paket bereitgestellt, das nur im Legacy-Cluster installiert werden kann.
- CDH 5.x
- CDH 6.x
- HDP 2.6
- HDP 3.1
- EMR 5.x &6.x
Das Paket ist mit den versionspezifischen Binärdateien versionlocked. Für jede der oben genannten Versionen sollte es pro Cluster erworben werden. Wenden Sie sich an Ihr Cloudera-Vertriebsteam, wenn Sie daran interessiert sind.
Implementierungsdetails
Das durch das Operational Database Replication Plug-in gelöste Hindernis ist die gegenseitige Authentifizierung zwischen Clustern unter verschiedenen Sicherheitskonfigurationen. In Erinnerung an diesen vorherigen Blogbeitrag erfordert die HBase-Standardreplikation, dass beide Cluster entweder überhaupt nicht für Sicherheit konfiguriert sind oder beide mit Sicherheit konfiguriert sind. Im letzteren Fall müssen sich beide Cluster entweder im selben Kerberos-Bereich befinden oder auf dem Kerberos-System eine bereichsübergreifende Authentifizierung festgelegt haben. Dies wäre eine zusätzliche Herausforderung im Kontext von CDP, wo jede Umgebung auf einem eigenständigen Sicherheitsbereich läuft. Um dies genauer zu verstehen, müssen wir überprüfen, wie die Apache HBase-Sicherheit implementiert wird.
Mit SASL Vertrauen aufbauen
Bei der HBase-Replikation kontaktieren RegionServer im Quellcluster RegionServer im Zielcluster über RPC-Verbindungen. Wenn die Sicherheit aktiviert ist, wird die Authentifizierung in der Phase des RPC-Verbindungsaufbaus unter Verwendung des Simple Authentication and Security Layer Framework (SASL) durchgeführt. HBase stellt bereits das folgende integrierte bereit SASL-Authentifizierung Mechanismen:Kerberos, Digest und einfach. Wenn Kerberos aktiviert ist, erwartet der Zielcluster Anmeldeinformationen aus dem Quellcluster, der diese Anmeldeinformationen dann mithilfe von SASL-Kerberos mit seinem eigenen KDC validiert Mechanismus. Dies basiert auf Kerberos GSSAPI Implementierung zum Authentifizieren der bereitgestellten Anmeldeinformationen gegenüber dem KDC des Zielclusters, daher muss das Vertrauen für den Prinzipal des Quellclusters auf der Kerberos-Systemebene implementiert worden sein, indem entweder beide Cluster-Anmeldeinformationen auf demselben Bereich vorhanden sind oder das KDC des Zielclusters den Anmeldeinformationen vertraut Quell-Cluster-Realm (ein Ansatz, der allgemein als realmübergreifend bekannt ist Authentifizierung).
Erweitern der HBase SASL-Authentifizierung
Glücklicherweise ist SASL so konzipiert, dass benutzerdefinierte Authentifizierungsimplementierungen möglich sind. Das bedeutet, dass eine SASL-basierte Lösung entworfen werden könnte, wenn ein zusätzlicher SASL-Mechanismus in den Satz der oben erwähnten integrierten Optionen eingefügt werden könnte. Zu diesem Zweck schlug Cloudera ein Refactoring der RPC-Schicht von HBase vor, das von der Apache HBase-Community in HBASE-23347 überprüft und akzeptiert wurde .
Plug-fähiger SASL-Mechanismus
Mit den durch HBASE-23347 eingeführten Änderungen , können zusätzliche SASL-Authentifizierungsmechanismen über die HBase-Konfiguration definiert werden, die von der RPC-Schicht verwendet werden. Eingehende RPC-Verbindungen definieren den spezifischen SASL-Typ im Header, dann wählt der RPC-Server die spezifische Implementierung aus, um die eigentliche Authentifizierung durchzuführen:
Plug-In für die operative Datenbankreplikation implementiert seinen benutzerdefinierten SASL-Mechanismus, der es Clustern auf verschiedenen Kerberos-Realms ermöglicht, mit nahtlosem Konfigurationsaufwand zu kommunizieren (ohne die Notwendigkeit von kerberos-übergreifendem Realm). ). Es erweitert die HBase-Replikation, sodass die Quelle ein SASL-Token des Replication Plugin erstellt benutzerdefinierter Typ mit Anmeldeinformationen eines vordefinierten Maschinenbenutzers im Ziel-COD-Cluster. Dieser Benutzertyp kann einfach über die Cloudera Management Console erstellt werden Benutzeroberfläche, und dann an die zugrunde liegende Kerberos-Authentifizierungsstelle des COD-Clusters weitergegeben. Ausführliche Anweisungen zum Erstellen von Benutzern für Replikationsmaschinen finden Sie im Abschnitt mit den erforderlichen Schritten in der Cloudera Replication Manager-Dokumentation.
Wenn der RPC-Server im Ziel das Token liest und identifiziert, dass es sich um ein Replikations-Plug-in handelt Typ, zugehörige Anmeldeinformationen werden aus dem Token geparst und für die Authentifizierung verwendet.
Plug-in für die operative Datenbankreplikation verwendet die PAM-Authentifizierung, um die Anmeldeinformationen des Maschinenbenutzers zu validieren. COD-Cluster werden immer mit PAM bereitgestellt, das gegenüber der FreeIPA-Sicherheitsdomäne der CDP-Umgebung authentifiziert wird.
Sichern von Computerbenutzer-Anmeldeinformationen
Ein kritisches Problem bei dieser Lösung besteht darin, dass der Quellcluster die Anmeldeinformationen vom Maschinenbenutzer des Zielclusters erhalten muss. Aus offensichtlichen Gründen sollte dies auf keinen Fall in der Quellkonfiguration offengelegt werden. Diese Anmeldeinformationen werden auch über das Kabel im SASL-Token innerhalb der RPC-Verbindung gesendet, sodass sie vor der Übertragung verschlüsselt werden müssen. Das Replikations-Plug-in bietet ein eigenes Tool zum Generieren eines jceks Datei, in der die Anmeldeinformationen des Computerbenutzers gespeichert sind, verschlüsselt. Nachdem diese Datei erstellt wurde, muss sie auf beide Cluster kopiert und von der hbase lesbar gemacht werden nur Benutzer. Das folgende Diagramm zeigt eine Bereitstellungsübersicht des Operational Database Replication Plug-in Komponenten, die im Kontext von RegionServers in die standardmäßigen HBase-Replikationsklassen integriert werden. Die rosa Kästchen stellen den bereits von HBase bereitgestellten Replikations- und RPC-Verbindungscode dar, während die gelben Kästchen die in HBASE-23347 eingeführte Abstraktionsschicht zeigen. Schließlich heben die orangefarbenen Klassen die relevanten Artefakte hervor, die das Operational Database Replication Plug-in implementieren Logik.
Schlussfolgerung
Die Replikation ist ein wertvolles Tool zur Implementierung von DR- und DC-Migrationslösungen für HBase. Es gibt einige Einschränkungen, wie hier gezeigt, wenn es um die Sicherheitskonfigurationen von Clustern geht. Die Fähigkeit, Daten von aktuellen „On-Prem“-Bereitstellungen zu CDP-Clustern in der Cloud zu migrieren, ist jedoch unerlässlich. Cloudera Operational Database Replication-Plugin bringt Flexibilität bei der Integration gesicherter Cluster, zusammen mit besserer Wartbarkeit für diese Sicherheitsintegration, da sie im Gegensatz zu bereichsübergreifendem Kerberos vollständig auf HBase-Ebene implementiert ist was Änderungen an der Kerberos-Systemdefinition erfordert, oft in der Verantwortung eines völlig anderen Teams mit eigenen restriktiven Richtlinien.
Probieren Sie die Vorlage für die operative Datenbank in aus Cloudera-Datenplattform (CDP)!
