W poprzednim poście na blogu przedstawiliśmy ogólne omówienie wtyczki Cloudera Replication, wyjaśnia, w jaki sposób zapewnia replikację międzyplatformową przy niewielkiej konfiguracji. W tym poście omówimy, w jaki sposób można zastosować tę wtyczkę w klastrach CDP i wyjaśnimy, w jaki sposób wtyczka umożliwia silne uwierzytelnianie między systemami, które nie dzielą wzajemnego zaufania w zakresie uwierzytelniania.
Korzystanie z wtyczki operacyjnej replikacji bazy danych
Wtyczka operacyjnej replikacji baz danych jest dostępny zarówno jako samodzielna wtyczka, jak i instalowany automatycznie poprzez Cloudera Replication Manager. Wtyczka umożliwia klientom skonfigurowanie replikacji danych HBase w czasie zbliżonym do rzeczywistego z klastrów CDH/HDP/AWS EMR/Azure HDInsight do CDP Private Cloud Base i/lub operacyjnej bazy danych CDP (COD) w chmurze publicznej. Jest również automatycznie wdrażany podczas korzystania z Cloudera Replication Manager do skonfigurowania replikacji między CDP Private Cloud Base i COD lub między instancjami COD w chmurze publicznej. Cloudera Replication Manager pozwala również na połączenie funkcji migawek HBase z tą wtyczką, aby zarządzać replikacją wcześniej istniejących danych w jednej konfiguracji.
Aby uzyskać instrukcje dotyczące instalacji, zapoznaj się z zasadami replikacji HBase temat dotyczący Menedżera replikacji oficjalna dokumentacja.
W przypadku starszych wersji CDH/HDP wtyczka jest dostarczana jako pakiet do zainstalowania wyłącznie w starszym klastrze.
- CDH 5.x
- CDH 6.x
- HDP 2.6
- HDP 3.1
- EMR 5.x i 6.x
Paczka jest w wersji zablokowanej z plikami binarnymi specyficznymi dla wersji. Dla każdej z wymienionych powyżej wersji należy ją nabyć na podstawie klastra. Skontaktuj się z zespołem sprzedaży Cloudera, jeśli jesteś zainteresowany uzyskaniem któregokolwiek z nich.
Szczegóły implementacji
Przeszkoda rozwiązana przez Operational Database Replication Plugin to wzajemne uwierzytelnianie między klastrami w różnych konfiguracjach zabezpieczeń. Przywołując ten poprzedni wpis w blogu, domyślna replikacja HBase wymaga, aby oba klastry albo nie były w ogóle skonfigurowane pod kątem zabezpieczeń, albo oba były skonfigurowane z zabezpieczeniami. W przypadku tego ostatniego oba klastry muszą znajdować się w tym samym obszarze Kerberos lub mieć ustawione uwierzytelnianie między obszarami w systemie Kerberos. Byłoby to dodatkowym wyzwaniem w kontekście CDP, gdzie każde środowisko działa w zamkniętej sferze bezpieczeństwa. Aby zrozumieć to bardziej szczegółowo, musimy sprawdzić, jak zaimplementowano zabezpieczenia Apache HBase.
Używanie SASL do budowania zaufania
W replikacji HBase serwery regionów w klastrze źródłowym kontaktują się z serwerami regionów w klastrze docelowym za pośrednictwem połączeń RPC. Gdy zabezpieczenia są włączone, uwierzytelnianie jest przeprowadzane w fazie ustanawiania połączenia RPC przy użyciu struktury Simple Authentication and Security Layer (SASL). HBase zapewnia już następujące wbudowane Uwierzytelnianie SASL mechanizmy:kerberos, skrót i proste. Gdy protokół Kerberos jest włączony, klaster docelowy będzie oczekiwał poświadczeń z klastra źródłowego, który następnie sprawdzi poprawność tych poświadczeń we własnym KDC, używając kerberos SASL mechanizm. Opiera się to na kerberos GSSAPI implementacja do uwierzytelniania dostarczonych poświadczeń w KDC klastra docelowego, dlatego zaufanie do podmiotu głównego klastra źródłowego musiało zostać zaimplementowane na poziomie systemu Kerberos, przez posiadanie poświadczeń obu klastrów w tej samej dziedzinie lub sprawienie, aby KDC klastra docelowego ufał poświadczeniom z dziedzina klastra źródłowego (podejście powszechnie znane jako cross-realm uwierzytelnianie).
Rozszerzanie uwierzytelniania HBase SASL
Na szczęście SASL został zaprojektowany, aby umożliwić niestandardowe implementacje uwierzytelniania. Oznacza to, że można by zaprojektować rozwiązanie oparte na SASL, gdyby dodatkowy mechanizm SASL można było podłączyć do zestawu wbudowanych opcji wspomnianych powyżej. W tym celu Cloudera zaproponowała refaktoryzację warstwy RPC HBase, która została sprawdzona i zaakceptowana przez społeczność Apache HBase w HBASE-23347 .
Wtykowy mechanizm SASL
Ze zmianami wprowadzonymi przez HBASE-23347 , dodatkowe mechanizmy uwierzytelniania SASL można zdefiniować za pomocą konfiguracji HBase, które będą używane przez warstwę RPC. Przychodzące połączenia RPC definiują określony typ SASL w nagłówku, a następnie serwer RPC wybiera konkretną implementację do przeprowadzenia rzeczywistego uwierzytelnienia:
Wtyczka operacyjnej replikacji bazy danych implementuje swój niestandardowy mechanizm SASL, umożliwiając klastrom w różnych obszarach Kerberos komunikację z bezproblemową konfiguracją (bez potrzeby kerberos cross-realm ). Rozszerza replikację HBase, dzięki czemu źródło tworzy token SASL Wtyczki replikacji typ niestandardowy z poświadczeniami od wstępnie zdefiniowanego użytkownika komputera w docelowym klastrze COD. Tego typu użytkownika można łatwo utworzyć z Konsoli zarządzania Cloudera interfejs użytkownika, a następnie propagowane do klastra COD będącego podstawą uwierzytelniania Kerberos. Szczegółowe instrukcje dotyczące tworzenia użytkowników maszyn replikacyjnych znajdują się w sekcji kroków wstępnych w dokumentacji Cloudera Replication Manager.
Gdy serwer RPC w miejscu docelowym odczytuje token i zidentyfikuje, że jest to wtyczka replikacji typ, powiązane dane uwierzytelniające są analizowane z tokena i używane do uwierzytelniania.
Wtyczka operacyjnej replikacji bazy danych używa uwierzytelniania PAM do weryfikacji poświadczeń użytkownika urządzenia. Klastry COD są zawsze wyposażone w uwierzytelnianie PAM względem domeny bezpieczeństwa FreeIPA środowiska CDP.
Zabezpieczanie poświadczeń użytkownika komputera
Krytycznym problemem w tym rozwiązaniu jest to, że klaster źródłowy musi uzyskać poświadczenia od użytkownika maszyny klastra docelowego. Z oczywistych powodów nie powinno to być w żaden sposób ujawnione w konfiguracji źródłowej. Te poświadczenia są również przesyłane przez sieć w tokenie SASL w ramach połączenia RPC, więc muszą zostać zaszyfrowane przed transmisją. Wtyczka replikacji udostępnia własne narzędzie do generowania jceks plik przechowujący dane uwierzytelniające użytkownika maszyny, zaszyfrowany. Po utworzeniu tego pliku należy go skopiować do obu klastrów i udostępnić do odczytu przez hbase tylko użytkownik. Poniższy diagram przedstawia przegląd wdrożenia Operational Database Replication Plugin komponenty integrujące się ze standardowymi klasami replikacji HBase w kontekście RegionServers. Różowe ramki reprezentują kod replikacji i połączenia RPC już dostarczony przez HBase, podczas gdy żółte ramki pokazują warstwę abstrakcji wprowadzoną w HBASE-23347. Na koniec, pomarańczowe klasy wyróżniają odpowiednie artefakty implementujące wtyczkę Operational Database Replication Plugin logika.
Wniosek
Replikacja to cenne narzędzie do wdrażania rozwiązań migracji DR i DC dla HBase. Ma pewne zastrzeżenia, jak pokazano tutaj, w przypadku konfiguracji bezpieczeństwa klastrów. Jednak możliwość migracji danych z obecnych wdrożeń „on-prem” do klastrów CDP w chmurze jest niezbędna. Wtyczka Cloudera Operational Database Replication zapewnia elastyczność podczas integracji zabezpieczonych klastrów, a także lepszą konserwację tej integracji zabezpieczeń, ponieważ jest ona w całości zaimplementowana na poziomie HBase, w przeciwieństwie do kerberos cross-realm, co wymaga zmian w definicji systemu Kerberos, często w gestii zupełnie innego zespołu, z własnymi restrykcyjnymi zasadami.
Wypróbuj szablon operacyjnej bazy danych w Platforma danych Cloudera (CDP)!
