I det här tidigare blogginlägget gav vi en översikt på hög nivå av Cloudera Replication Plugin, förklarar hur det ger plattformsoberoende replikering med lite konfiguration. I det här inlägget kommer vi att täcka hur denna plugin kan tillämpas i CDP-kluster och förklara hur plugin möjliggör stark autentisering mellan system som inte delar ömsesidigt autentiseringsförtroende.
Använda Operational Database Replication Plugin
Operational Database Replication Plugin finns både som fristående plugin och installeras automatiskt via Cloudera Replication Manager. Plugin-programmet gör det möjligt för kunder att konfigurera replikering i nästan realtid av HBase-data från CDH/HDP/AWS EMR/Azure HDInsight-kluster till CDP Private Cloud Base och/eller CDP Operational Database (COD) i det offentliga molnet. Den distribueras också automatiskt när du använder Cloudera Replication Manager för att ställa in replikering mellan CDP Private Cloud Base och COD eller mellan COD-instanser i det offentliga molnet. Cloudera Replication Manager gör det också möjligt att kombinera HBase-ögonblicksbildsfunktionen tillsammans med detta plugin för att också hantera replikering av redan existerande data i en enda installation.
För installationsinstruktioner, se HBase replikeringspolicy ämne om Replication Manager officiell dokumentation.
För äldre CDH/HDP-versioner tillhandahålls plugin-programmet som ett paket som endast ska installeras i det äldre klustret.
- CDH 5.x
- CDH 6.x
- HDP 2.6
- HDP 3.1
- EMR 5.x &6.x
Paketet är versionslåst med versionsspecifika binärer. För var och en av versionerna som nämns ovan bör den förvärvas per kluster. Kontakta ditt Cloudera-säljteam om du är intresserad av att få någon av dessa.
Implementeringsdetaljer
Hindret löstes av Operational Database Replication Plugin är den ömsesidiga autentiseringen mellan kluster under olika säkerhetskonfigurationer. Med tanke på detta tidigare blogginlägg kräver HBase standardreplikering att båda klustren antingen inte är konfigurerade för säkerhet alls, eller båda är konfigurerade med säkerhet. I det senare fallet måste båda klustren antingen vara i samma kerberos-sfär eller ha korsvärnsautentisering inställd på kerberos-systemet. Detta skulle vara en extra utmaning i CDP-sammanhang, där varje miljö körs på en fristående säkerhetssfär. För att förstå detta mer i detalj måste vi se över hur Apache HBase-säkerhet implementeras.
Använda SASL för att skapa förtroende
I HBase-replikering kontaktar RegionServers i källklustret RegionServers i målklustret via RPC-anslutningar. När säkerhet är aktiverad utförs autentisering vid etableringsfasen av RPC-anslutningen med hjälp av ramverket Simple Authentication and Security Layer (SASL). HBase tillhandahåller redan följande inbyggda SASL-autentisering mekanismer:kerberos, sammandrag och enkel. När kerberos är aktiverat förväntas autentiseringsuppgifter från källklustret av målklustret, som sedan validerar dessa autentiseringsuppgifter mot sin egen KDC, med hjälp av SASL kerberos mekanism. Detta är beroende av kerberos GSSAPI implementering för autentisering av de tillhandahållna autentiseringsuppgifterna mot målklustret KDC, därför måste förtroendet för källklusterhuvudmannen ha implementerats på kerberos-systemnivå, antingen genom att ha båda klustrets autentiseringsuppgifter på samma område eller få målklustret KDC att lita på referenserna från källklustervärld (ett tillvägagångssätt allmänt känt som cross-realm autentisering).
Utöka HBase SASL-autentisering
Lyckligtvis är SASL utformad för att möjliggöra anpassade autentiseringsimplementeringar. Det betyder att en SASL-baserad lösning skulle kunna utformas, om en ytterligare SASL-mekanism kunde kopplas in i uppsättningen av de inbyggda alternativen som nämns ovan. I det syftet föreslog Cloudera en omstrukturering av HBases RPC-lager, som har granskats och accepterats av Apache HBase-communityt i HBASE-23347 .
Plugbar SASL-mekanism
Med de ändringar som införts av HBASE-23347 , kan ytterligare SASL-autentiseringsmekanismer definieras via HBase-konfiguration för att användas av RPC-lagret. Inkommande RPC-anslutningar definierar den specifika SASL-typen i rubriken, sedan väljer RPC-servern den specifika implementeringen för att utföra den faktiska autentiseringen:
Operational Database Replication Plugin implementerar sin anpassade SASL-mekanism, vilket gör det möjligt för kluster på olika kerberos-världen att kommunicera med sömlösa konfigurationsförsök (utan behov av kerberos-gränsöverskridande ). Den utökar HBase-replikeringen så att källan skapar en SASL-token för replikeringsplugin anpassad typ, med autentiseringsuppgifter från en fördefinierad maskinanvändare på mål-COD-klustret. Denna typ av användare kan enkelt skapas från Cloudera Management Console UI, och sprids sedan till COD-klustret som ligger bakom kerberos-autentiseringsmyndigheten. Detaljerade instruktioner om hur du skapar replikeringsmaskinanvändare finns i avsnittet för steg för förhandskrav i Cloudera Replication Manager-dokumentationen.
När RPC-servern i målet läser token och identifierar det är det en replikeringsplugin typ tolkas relaterade autentiseringsuppgifter från token och används för autentisering.
Plugin för operationell databasreplikering använder PAM-autentisering för att validera maskinens användaruppgifter. COD-kluster tillhandahålls alltid med PAM-autentisering mot CDP-miljöns FreeIPA-säkerhetsdomän.
Säkring av maskinens användaruppgifter
Ett kritiskt problem i den här lösningen är att källklustret måste hämta inloggningsuppgifterna från maskinanvändaren av målklustret. Av uppenbara skäl bör det inte exponeras på något sätt i källkonfigurationen. Dessa referenser skickas också över tråden i SASL-tokenet inom RPC-anslutningen, så den måste krypteras innan överföringen. Replikeringspluginen tillhandahåller ett eget verktyg för att generera en jceks fil som lagrar maskinens användaruppgifter, krypterad. När den här filen har skapats måste den kopieras till båda klustren och göras läsbar av hbase endast användare. Diagrammet nedan visar en distributionsöversikt av Operational Database Replication Plugin komponenter som integreras med standard HBase-replikeringsklasser i samband med RegionServers. De rosa rutorna representerar replikerings- och RPC-anslutningskoden som redan tillhandahålls av HBase, medan de gula rutorna visar abstraktionsskiktet som introducerats i HBASE-23347. Slutligen framhäver de orange klasserna de relevanta artefakterna som implementerar Operational Database Replication Plugin logik.
Slutsats
Replikering är ett värdefullt verktyg för att implementera DR- och DC-migreringslösningar för HBase. Den har några varningar, som visas här, när det gäller klusters säkerhetskonfigurationer. Ändå är möjligheten att migrera data från nuvarande "on-prem" distributioner till CDP-kluster i molnet absolut nödvändig. Cloudera Operational Database Replication Plugin ger flexibilitet vid integrering av säkra kluster, tillsammans med bättre underhållsbarhet för denna säkerhetsintegrering, eftersom den är helt implementerad på HBase-nivå, i motsats till kerberos cross-realm, vilket kräver förändringar av kerberos-systemdefinitionen, ofta ett ansvar för ett helt annat team, med sina egna restriktiva policyer.
Prova mallen Operational Database i Cloudera Data Platform (CDP)!