In deze vorige blogpost hebben we een algemeen overzicht gegeven van Cloudera Replication Plugin, waarin wordt uitgelegd hoe het platformonafhankelijke replicatie met weinig configuratie tot stand brengt. In dit bericht bespreken we hoe deze plug-in kan worden toegepast in CDP-clusters en leggen we uit hoe de plug-in sterke authenticatie mogelijk maakt tussen systemen die geen wederzijds authenticatievertrouwen delen.
De plug-in voor operationele databasereplicatie gebruiken
De Operationele Database Replicatie Plugin is zowel beschikbaar als een zelfstandige plug-in en wordt automatisch geïnstalleerd via Cloudera Replication Manager. Met de plug-in kunnen klanten bijna realtime replicatie van HBase-gegevens instellen van CDH/HDP/AWS EMR/Azure HDInsight-clusters naar CDP Private Cloud Base en/of CDP Operational Database (COD) in de openbare cloud. Het wordt ook automatisch geïmplementeerd wanneer Cloudera Replication Manager wordt gebruikt om replicatie in te stellen tussen CDP Private Cloud Base en COD of tussen COD-instanties in de Public Cloud. Cloudera Replication Manager maakt het ook mogelijk om de HBase snapshot-functie samen met deze plug-in te combineren om ook de replicatie van reeds bestaande gegevens in een enkele installatie te beheren.
Raadpleeg voor installatie-instructies het HBase-replicatiebeleid onderwerp op Replicatiebeheer officiële documentatie.
Voor legacy CDH/HDP-versies wordt de plug-in geleverd als een pakket dat alleen in het legacy-cluster moet worden geïnstalleerd.
- CDH 5.x
- CDH 6.x
- HDP 2.6
- HDP 3.1
- EMR 5.x &6.x
Het pakket is versie vergrendeld met de versiespecifieke binaire bestanden. Voor elk van de bovengenoemde versies moet het per cluster worden verkregen. Neem contact op met uw Cloudera-verkoopteam als u geïnteresseerd bent in het verkrijgen van een van deze.
Implementatiedetails
De belemmering opgelost door Operational Database Replication Plugin is de wederzijdse authenticatie tussen clusters onder verschillende beveiligingsconfiguraties. Herinnerend aan dit vorige blogbericht, vereist de standaardreplicatie van HBase dat beide clusters ofwel helemaal niet zijn geconfigureerd voor beveiliging, of beide zijn geconfigureerd met beveiliging. In het laatste geval moeten beide clusters zich ofwel in hetzelfde kerberos-realm bevinden, of cross-realm-authenticatie hebben ingesteld op het kerberos-systeem. Dit zou een extra uitdaging zijn in de context van CDP, waar elke omgeving op een op zichzelf staand beveiligingsdomein draait. Om dit in meer detail te begrijpen, moeten we bekijken hoe Apache HBase-beveiliging is geïmplementeerd.
SASL gebruiken om vertrouwen op te bouwen
In HBase-replicatie maken RegionServers in het broncluster contact met RegionServers in het doelcluster via RPC-verbindingen. Wanneer beveiliging is ingeschakeld, wordt authenticatie uitgevoerd in de fase van het tot stand brengen van de RPC-verbinding met behulp van het Simple Authentication and Security Layer-framework (SASL). HBase biedt al de volgende ingebouwde SASL-verificatie mechanismen:kerberos, digest en eenvoudig. Wanneer kerberos is ingeschakeld, worden referenties van het broncluster verwacht door het doelcluster, dat deze referenties vervolgens valideert tegen zijn eigen KDC, met behulp van de SASL kerberos mechanisme. Dit is afhankelijk van kerberos GSSAPI implementatie voor authenticatie van de verstrekte referenties tegen de doelcluster-KDC, daarom moet de vertrouwensrelatie voor de broncluster-principal zijn geïmplementeerd op het Kerberos-systeemniveau, door beide clusterreferenties op dezelfde realm te hebben, of door doelcluster KDC de referenties van te laten vertrouwen source cluster realm (een benadering die algemeen bekend staat als cross-realm authenticatie).
HBase SASL-verificatie uitbreiden
Gelukkig is SASL ontworpen om aangepaste authenticatie-implementaties mogelijk te maken. Dat betekent dat er een op SASL gebaseerde oplossing zou kunnen worden ontworpen, als een extra SASL-mechanisme zou kunnen worden aangesloten op de reeks ingebouwde opties die hierboven zijn vermeld. Met dat doel stelde Cloudera een refactoring van de RPC-laag van HBase voor, die is beoordeeld en geaccepteerd door de Apache HBase-gemeenschap in HBASE-23347 .
Insteekbaar SASL-mechanisme
Met de wijzigingen die zijn geïntroduceerd door HBASE-23347 , kunnen aanvullende SASL-authenticatiemechanismen worden gedefinieerd via HBase-configuratie voor gebruik door de RPC-laag. Inkomende RPC-verbindingen definiëren het specifieke SASL-type in de header, waarna de RPC-server de specifieke implementatie selecteert om de daadwerkelijke authenticatie uit te voeren:
Operationele invoegtoepassing voor databasereplicatie implementeert zijn aangepaste SASL-mechanisme, waardoor clusters op verschillende kerberos-realms kunnen communiceren met naadloze configuratie-inspanningen (zonder de noodzaak van kerberos cross-realm ). Het breidt de HBase-replicatie uit zodat de bron een SASL-token van Replication Plugin maakt aangepast type, met referenties van een vooraf gedefinieerde computergebruiker op het doel-CZV-cluster. Dit type gebruiker kan eenvoudig worden aangemaakt vanuit Cloudera Management Console UI, en vervolgens doorgegeven aan het COD-cluster dat ten grondslag ligt aan de kerberos-authenticatieautoriteit. Gedetailleerde instructies over het maken van gebruikers van replicatiemachines worden behandeld in het gedeelte met de vereiste stappen in de documentatie van Cloudera Replication Manager.
Wanneer de RPC-server in het doel het token leest en identificeert dat het een Replicatie-plug-in is type, worden gerelateerde inloggegevens geparseerd van het token en gebruikt voor authenticatie.
Operationele invoegtoepassing voor databasereplicatie gebruikt PAM-verificatie om de gebruikersgegevens van de machine te valideren. COD-clusters zijn altijd voorzien van PAM-authenticatie tegen het FreeIPA-beveiligingsdomein van de CDP-omgeving.
Inloggegevens van computergebruikers beveiligen
Een kritiek probleem bij deze oplossing is dat het broncluster de referenties moet verkrijgen van de computergebruiker van het doelcluster. Om voor de hand liggende redenen mag dat op geen enkele manier worden weergegeven in de bronconfiguratie. Deze inloggegevens worden ook via de kabel verzonden in het SASL-token binnen de RPC-verbinding, dus het moet vóór verzending worden versleuteld. De Replicatie Plugin biedt zijn eigen tool om een jceks . te genereren bestand dat de gebruikersgegevens van de machine opslaat, versleuteld. Zodra dit bestand is gemaakt, moet het naar beide clusters worden gekopieerd en leesbaar worden gemaakt door de hbase alleen gebruiker. Het onderstaande diagram toont een implementatieoverzicht van Operational Database Replication Plugin componenten die integreren met de standaard HBase-replicatieklassen in de context van RegionServers. De roze vakken vertegenwoordigen de replicatie- en RPC-verbindingscode die al door HBase is geleverd, terwijl de gele vakken de abstractielaag weergeven die is geïntroduceerd in HBASE-23347. Ten slotte markeren de oranje klassen de relevante artefacten die Operational Database Replication Plugin implementing implementeren logica.
Conclusie
Replicatie is een waardevol hulpmiddel voor het implementeren van DR- en DC-migratieoplossingen voor HBase. Het heeft enkele kanttekeningen, zoals hier getoond, bij het omgaan met de beveiligingsconfiguraties van clusters. Toch is de mogelijkheid om gegevens te migreren van huidige "on-prem" implementaties naar CDP-clusters in de cloud absoluut noodzakelijk. Cloudera Operational Database Replication-plug-in brengt flexibiliteit bij het integreren van beveiligde clusters, samen met betere onderhoudbaarheid voor deze beveiligingsintegratie, aangezien het volledig op HBase-niveau is geïmplementeerd, in tegenstelling tot kerberos cross-realm, wat veranderingen vereist in de definitie van het kerberos-systeem, vaak een verantwoordelijkheid van een heel ander team, met zijn eigen restrictieve beleid.
Probeer de sjabloon voor de operationele database uit in Cloudera Data Platform (CDP)!