I dette tidligere blogindlæg gav vi en oversigt på højt niveau over Cloudera Replication Plugin, forklarer, hvordan det bringer replikering på tværs af platforme med lidt konfiguration. I dette indlæg vil vi dække, hvordan dette plugin kan anvendes i CDP-klynger og forklare, hvordan plugin'et muliggør stærk godkendelse mellem systemer, der ikke deler gensidig godkendelsestillid.
Brug af Operational Database Replication Plugin
Operational Database Replication Plugin er tilgængelig både som et selvstændigt plugin samt installeret automatisk via Cloudera Replication Manager. Pluginnet gør det muligt for kunder at opsætte næsten-realtidsreplikering af HBase-data fra CDH/HDP/AWS EMR/Azure HDInsight-klynger til CDP Private Cloud Base og/eller CDP Operational Database (COD) i Public Cloud. Den implementeres også automatisk, når du bruger Cloudera Replication Manager til at konfigurere replikering mellem CDP Private Cloud Base og COD eller mellem COD-instanser i den offentlige sky. Cloudera Replication Manager giver også mulighed for at kombinere HBase snapshot-funktionen sammen med dette plugin for også at administrere replikering af allerede eksisterende data i en enkelt opsætning.
For installationsinstruktioner henvises til HBase replikeringspolitik emne om Replication Manager officiel dokumentation.
For ældre CDH/HDP-versioner leveres plugin'et som en pakke, der kun skal installeres i den ældre klynge.
- CDH 5.x
- CDH 6.x
- HDP 2.6
- HDP 3.1
- EMR 5.x &6.x
Pakken er versionslåst med de versionsspecifikke binære filer. For hver af de ovenfor nævnte versioner bør den anskaffes på en klyngebasis. Kontakt dit Cloudera-salgsteam, hvis du er interesseret i at få nogen af dem.
Implementeringsdetaljer
Hindringen løst af Operational Database Replication Plugin er den gensidige godkendelse mellem klynger under forskellige sikkerhedskonfigurationer. I betragtning af dette tidligere blogindlæg kræver HBase standardreplikering, at begge klynger enten slet ikke er konfigureret til sikkerhed, eller begge er konfigureret med sikkerhed. I tilfælde af sidstnævnte skal begge klynger enten være i det samme kerberos-rige eller have krydsrige-godkendelse indstillet på kerberos-systemet. Dette ville være en ekstra udfordring i forbindelse med CDP, hvor hvert miljø kører på et selvstændigt sikkerhedsområde. For at forstå dette mere detaljeret, er vi nødt til at gennemgå, hvordan Apache HBase-sikkerhed implementeres.
Brug af SASL til at etablere tillid
I HBase-replikering kontakter RegionServers i kildeklyngen RegionServers i målklyngen via RPC-forbindelser. Når sikkerhed er aktiveret, udføres godkendelse i RPC-forbindelsens etableringsfase ved hjælp af Simple Authentication and Security Layer framework (SASL). HBase leverer allerede følgende indbyggede SASL-godkendelse mekanismer:kerberos, fordøjelse og simpelt. Når kerberos er aktiveret, forventes legitimationsoplysninger fra kildeklyngen af målklyngen, som derefter vil validere disse legitimationsoplysninger mod sin egen KDC ved hjælp af SASL kerberos mekanisme. Dette er afhængigt af kerberos GSSAPI implementering til godkendelse af de angivne legitimationsoplysninger mod målklyngen KDC, derfor skal tilliden til kildeklyngens principal være blevet implementeret på kerberos-systemniveau, ved enten at have begge klyngers legitimationsoplysninger på samme område eller få målklyngen KDC til at stole på legitimationsoplysningerne fra source cluster realm (en tilgang, der almindeligvis er kendt som cross-realm Godkendelse).
Udvidelse af HBase SASL-godkendelse
Heldigvis er SASL designet til at tillade brugerdefinerede godkendelsesimplementeringer. Det betyder, at en SASL-baseret løsning kunne designes, hvis en ekstra SASL-mekanisme kunne tilsluttes sættet af de indbyggede muligheder nævnt ovenfor. Med det formål foreslog Cloudera en omstrukturering af HBases RPC-lag, som er blevet gennemgået og accepteret af Apache HBase-fællesskabet i HBASE-23347 .
Plugbar SASL-mekanisme
Med ændringerne introduceret af HBASE-23347 , kan yderligere SASL-godkendelsesmekanismer defineres via HBase-konfiguration, der skal bruges af RPC-laget. Indgående RPC-forbindelser definerer den specifikke SASL-type i headeren, derefter vælger RPC-serveren den specifikke implementering til at udføre den faktiske godkendelse:
Operational Database Replication Plugin implementerer sin tilpassede SASL-mekanisme, der tillader klynger på forskellige kerberos-riger at kommunikere med sømløse konfigurationsbestræbelser (uden behov for kerberos-kryds-rige ). Den udvider HBase-replikering, så kilden opretter et SASL-token for replikeringsplugin tilpasset type med legitimationsoplysninger fra en foruddefineret maskinbruger på mål-COD-klyngen. Denne type bruger kan nemt oprettes fra Cloudera Management Console UI, og derefter udbredt til COD-klyngen, der ligger til grund for kerberos-godkendelsesmyndigheden. Detaljerede instruktioner om oprettelse af replikeringsmaskinebrugere er dækket i afsnittet med forudgående trin i Cloudera Replication Manager-dokumentationen.
Når RPC-serveren i målet læser tokenet og identificerer det, er det et replikeringsplugin type, relaterede legitimationsoplysninger parses fra tokenet og bruges til godkendelse.
Operational Database Replication Plugin bruger PAM-godkendelse til at validere maskinens brugerlegitimationsoplysninger. COD-klynger leveres altid med PAM-godkendelse mod CDP-miljøets FreeIPA-sikkerhedsdomæne.
Sikring af maskinbrugeroplysninger
Et kritisk problem i denne løsning er, at kildeklyngen skal hente legitimationsoplysningerne fra maskinbrugeren af målklyngen. Af indlysende årsager bør det ikke afsløres på nogen måde på kildekonfigurationen. Disse legitimationsoplysninger sendes også over ledningen i SASL-tokenet i RPC-forbindelsen, så det skal krypteres før transmission. Replikeringsplugin'et giver sit eget værktøj til at generere en jceks fil, der lagrer maskinens brugeroplysninger, krypteret. Når denne fil er oprettet, skal den kopieres til begge klynger og gøres læsbar af hbase kun bruger. Nedenstående diagram viser en implementeringsoversigt over Operational Database Replication Plugin komponenter, der integreres med standard HBase-replikeringsklasser i sammenhæng med RegionServers. De lyserøde felter repræsenterer replikerings- og RPC-forbindelseskoden, der allerede er leveret af HBase, mens de gule felter viser abstraktionslaget introduceret i HBASE-23347. Endelig fremhæver de orange klasser de relevante artefakter, der implementerer Operational Database Replication Plugin logik.
Konklusion
Replikering er et værdifuldt værktøj til implementering af DR- og DC-migreringsløsninger til HBase. Det har nogle forbehold, som vist her, når det håndterer klyngers sikkerhedskonfigurationer. Alligevel er evnen til at migrere data fra nuværende "on-prem" implementeringer til CDP-klynger i skyen bydende nødvendigt. Cloudera Operational Database Replication plugin bringer fleksibilitet ved integration af sikre klynger sammen med bedre vedligeholdelsesmuligheder for denne sikkerhedsintegration, da den er fuldstændig implementeret på HBase-niveau i modsætning til kerberos cross-realm, hvilket kræver ændringer af kerberos systemdefinitionen, ofte et helt andet teams ansvar, med sine egne restriktive politikker.
Prøv den operationelle databaseskabelon i Cloudera Data Platform (CDP)!