В тази предишна публикация в блога предоставихме преглед на високо ниво на Cloudera Replication Plugin, обяснява как носи кросплатформена репликация с малка конфигурация. В тази публикация ще разгледаме как този плъгин може да се приложи в CDP клъстери и ще обясним как приставката позволява силно удостоверяване между системи, които не споделят взаимно доверие при удостоверяване.
Използване на приставка за репликация на оперативна база данни
Приставката за репликация на оперативна база данни е достъпен както като самостоятелен плъгин, така и инсталиран автоматично чрез Cloudera Replication Manager. Плъгинът позволява на клиентите да настроят репликация в почти реално време на HBase данни от CDH/HDP/AWS EMR/Azure HDInsight клъстери към CDP Private Cloud Base и/или CDP Оперативна база данни (COD) в публичния облак. Той също така се разгръща автоматично при използване на Cloudera Replication Manager за настройка на репликация между CDP Private Cloud Base и COD или между COD екземпляри в публичния облак. Cloudera Replication Manager също така позволява комбиниране на функцията за моментна снимка на HBase заедно с този плъгин, за да управлявате репликацията на вече съществуващи данни в една настройка.
За инструкции за инсталиране, моля, вижте политика за репликация на HBase тема за Мениджър на репликация официална документация.
За наследени CDH/HDP версии, плъгинът се предоставя като пакет, който трябва да бъде инсталиран само в наследения клъстер.
- CDH 5.x
- CDH 6.x
- HDP 2.6
- HDP 3.1
- EMR 5.x и 6.x
Пакетът е версия, заключена със специфични за версията двоични файлове. За всяка от версиите, споменати по-горе, тя трябва да бъде придобита на база на клъстер. Свържете се с вашия екип по продажбите на Cloudera, ако се интересувате да получите някое от тях.
Подробности за внедряването
Пречката е решена от Приставка за репликация на оперативна база данни е взаимното удостоверяване между клъстери при различни конфигурации за сигурност. Припомняйки тази предишна публикация в блога, репликацията по подразбиране на HBase изисква и двата клъстера или да не са конфигурирани за сигурност изобщо, или и двата да са конфигурирани със сигурност. В случай на последното, и двата клъстера трябва да са или в една и съща kerberos сфера, или да имат кръстосано удостоверяване на автентификацията, зададено в системата kerberos. Това би било допълнително предизвикателство в контекста на CDP, където всяка среда работи в самостоятелна област на сигурност. За да разберем това по-подробно, трябва да прегледаме как се прилага сигурността на Apache HBase.
Използване на SASL за установяване на доверие
При репликация на HBase, RegionServers в изходния клъстер се свързват с RegionServers в целевия клъстер чрез RPC връзки. Когато защитата е активирана, удостоверяването се извършва на етапа на установяване на RPC връзка с помощта на рамката за просто удостоверяване и слой за сигурност (SASL). HBase вече предоставя следния вграден SASL удостоверяване механизми:kerberos, дайджест и прости. Когато kerberos е активиран, идентификационните данни от изходния клъстер ще се очакват от целевия клъстер, който след това ще потвърди тези идентификационни данни спрямо собствения си KDC, използвайки SASL kerberos механизъм. Това разчита на kerberos GSSAPI реализация за удостоверяване на предоставените идентификационни данни срещу целевия клъстер KDC, следователно доверието за принципала на изходния клъстер трябва да е било имплементирано на системно ниво на kerberos, като има или и двата клъстера идентификационни данни в една и съща област, или кара целевия клъстер KDC да се доверява на идентификационните данни от източник на клъстерна област (подход, известен като кръстосана област удостоверяване).
Разширяване на HBase SASL удостоверяване
За щастие SASL е проектиран да позволява персонализирани реализации за удостоверяване. Това означава, че може да бъде проектирано базирано на SASL решение, ако допълнителен SASL механизъм може да бъде включен в набора от вградените опции, споменати по-горе. С тази цел Cloudera предложи рефакторинг на RPC слоя на HBase, който беше прегледан и приет от общността на Apache HBase в HBASE-23347 .
Включващ SASL механизъм
С промените, въведени от HBASE-23347 , допълнителни механизми за удостоверяване на SASL могат да бъдат дефинирани чрез конфигурация на HBase, които да се използват от RPC слоя. Входящите RPC връзки дефинират конкретния тип SASL в заглавката, след което RPC сървърът избира конкретната реализация за извършване на действителното удостоверяване:
Приставка за репликация на оперативна база данни внедрява своя персонализиран SASL механизъм, позволявайки на клъстери в различни сфери на kerberos да комуникират с безпроблемни усилия за конфигуриране (без необходимост от kerberos cross-realm ). Той разширява репликацията на HBase, така че източникът да създава SASL токен на Replication Plugin персонализиран тип, с идентификационни данни от предварително дефиниран потребител на машина в целевия COD клъстер. Този тип потребител може лесно да бъде създаден от Конзолата за управление на Cloudera Потребителски интерфейс, и след това се разпространява до COD клъстера, който е в основата на удостоверяващ орган на Kerberos. Подробни инструкции за създаване на потребители на машини за репликация са обхванати в раздела за стъпките с предварителни изисквания в документацията на Cloudera Replication Manager.
Когато RPC сървърът в целта прочете маркера и идентифицира, че това е Приставка за репликация тип, свързаните идентификационни данни се анализират от токена и се използват за удостоверяване.
Приставка за репликация на оперативна база данни използва PAM удостоверяване за валидиране на потребителските идентификационни данни на машината. COD клъстерите винаги са снабдени с PAM удостоверяване срещу домейн за сигурност FreeIPA на CDP среда.
Защита на потребителските идентификационни данни на машината
Критичен проблем в това решение е, че изходният клъстер трябва да получи идентификационните данни от потребителя на машината на целевия клъстер. По очевидни причини това не трябва да се излага по никакъв начин в конфигурацията на източника. Тези идентификационни данни също се изпращат по кабела в SASL токена в RPC връзката, така че трябва да бъдат криптирани преди предаването. Приставката за репликация предоставя свой собствен инструмент за генериране на jceks файл, съхраняващ потребителските идентификационни данни на машината, криптиран. След като този файл бъде създаден, той трябва да бъде копиран и в двата клъстера и да се направи четим от hbase само потребител. Диаграмата по-долу показва общ преглед на внедряването на Приставка за репликация на оперативна база данни компоненти, интегриращи се към стандартните класове за репликация на HBase в контекста на RegionServers. Розовите полета представляват кода за репликация и RPC връзка, който вече е предоставен от HBase, докато жълтите полета показват абстракционния слой, въведен в HBASE-23347. И накрая, оранжевите класове подчертават съответните артефакти, внедряващи Приставка за репликация на оперативна база данни логика.
Заключение
Репликацията е ценен инструмент за внедряване на решения за миграция на DR и DC за HBase. Той има някои предупреждения, както е показано тук, когато се занимавате с конфигурации за сигурност на клъстерите. И все пак, възможността за мигриране на данни от текущи „on-prem“ внедрявания към CDP клъстери в облака е наложителна. Приставка за репликация на оперативна база данни на Cloudera носи гъвкавост при интегрирането на защитени клъстери, заедно с по-добра поддръжка за тази интеграция на сигурността, тъй като е изцяло внедрена на ниво HBase, за разлика от kerberos cross-realm, което изисква промени в дефиницията на системата kerberos, често отговорност на напълно различен екип, със свои собствени ограничителни политики.
Изпробвайте шаблона за оперативна база данни в Cloudera Data Platform (CDP)!
