Przewodnik po korzystaniu z portów Apache HBase

Dla osób, które dopiero zaczynają korzystać z Apache HBase (wersja 0.90 i nowsze), konfiguracja portów sieciowych używanych przez system może być nieco przytłaczająca.

W tym poście na blogu poznasz wszystkie porty TCP używane przez różne procesy HBase oraz jak i dlaczego są one używane (wszystko w jednym miejscu) — aby pomóc administratorom rozwiązywać problemy i konfigurować ustawienia zapory oraz pomagać nowym programistom w debugowaniu.

Typowy klaster HBase ma jeden aktywny master, jeden lub kilka masterów kopii zapasowych oraz listę serwerów regionalnych. Zapasowe urządzenia nadrzędne to zapasowe urządzenia nadrzędne, które czekają na kolejną aktywną. Zanim będą aktywne, nie nasłuchują na żadnych portach. (Dowiedz się więcej o tym, jak działa skalowalność HBase tutaj.)

Każdy serwer w klastrze nasłuchuje na głównym porcie żądań od klientów i/lub innych serwerów HBase. Każdy serwer ma również wbudowany serwer interfejsu internetowego Jetty.

Poniższy diagram przedstawia komunikację między różnymi komponentami. (Niebieskie komponenty należą do klastra HBase, zwykle za zaporą; szare komponenty to klienci zewnętrzni, zwykle poza zaporą klastra HBase; zielony komponent to przeglądarka internetowa, zwykle również poza zaporą.)

1. Aplikacje klienckie rozmawiają z Apache ZooKeeper, aby znaleźć lokalizację serwera głównego i serwera metaregionu (region główny został usunięty w HBase w wersji 0.96).
2. Aplikacje klienckie komunikują się z serwerami regionu w celu odczytu/zapisu/skanowania tabeli.
3. Aplikacje klienckie rozmawiają z masterem, aby uzyskać informacje o istniejącej tabeli, dynamicznie tworzyć/usuwać tabelę, dodawać/usuwać rodzinę kolumn.
4. Master rozmawia z serwerami regionu, aby otworzyć/zamknąć/przenieść/podzielić/opróżnić/zwarte regiony.
5. Master umieszcza dane w ZooKeeper, aby przechowywać lokalizację aktywnego serwera głównego i metaregionu, tworzyć zadania dzielenia logów, śledzić stany serwerów regionalnych.
6. Serwery regionalne odczytują dane w ZooKeeper w celu dzielenia logów, śledzenia lokalizacji głównej i stanu klastra.
7. Serwery regionalne komunikują się z masterem, aby zgłaszać uruchomienia i obciążenia serwerów regionalnych.
8. Od czasu do czasu serwery regionów komunikują się z metaregionem, aby sprawdzić stan regionu, utworzyć nowe regiony potomne w podziale regionów.
9. Klienci REST rozmawiają z serwerami REST, aby uzyskać dostęp do HBase.
10. Klienci Thrift rozmawiają z serwerami Thrift, aby uzyskać dostęp do HBase.
11. Użytkownicy uzyskują dostęp do głównego interfejsu internetowego z przeglądarek.
12. Użytkownicy uzyskują dostęp do interfejsu sieciowego serwerów regionalnych z przeglądarek.
13. Użytkownicy uzyskują dostęp do interfejsu internetowego serwerów REST z przeglądarek.
14. Użytkownicy uzyskują dostęp do interfejsu internetowego serwerów Thrift z przeglądarek.

Niektóre klastry HBase mogą mieć listę serwerów REST lub Thrift. Zarówno serwer REST, jak i serwer Thrift są opcjonalne; są one potrzebne tylko wtedy, gdy chcesz zapewnić dostęp REST/Thrift do klastra HBase. Dla HBase są to tylko inne aplikacje klienckie. Podobnie jak inne serwery HBase, nasłuchują również głównego portu dla żądań klientów i portu interfejsu internetowego.

Poniższa tabela przedstawia porty używane przez aplikacje klienckie do komunikowania się z klastrem HBase, użytkownicy do sprawdzania informacji o klastrze i różne komponenty HBase do komunikowania się ze sobą.

* Wprowadzono w HBase w wersji 0.94.5. Można je również określić za pomocą opcji wiersza poleceń --infoport podczas uruchamiania odpowiedniego serwera.
** Można je również określić za pomocą opcji wiersza poleceń -p podczas uruchamiania odpowiedniego serwera.

Jeden port nie jest wymieniony w tabeli — port nazwy węzła HDFS — ponieważ tutaj nie ma dla niego osobnego parametru. Jest skonfigurowany jako część „hbase.root” (na przykład „hdfs://namenode.foobar.com:35802/hbase”) z portem HDFS NameNode skonfigurowanym jako 35802. O ile nie określono inaczej w wartości „ hbase.root”, wartość domyślna to 8020.

Oprócz portu głównego każdy serwer w klastrze (z wyjątkiem ZooKeeper) nasłuchuje również portu internetowego interfejsu użytkownika. Internetowy interfejs użytkownika to wbudowany serwer Jetty w odpowiadającym mu serwerze. Internetowy interfejs użytkownika udostępnia czytelne dla człowieka informacje o odpowiednim serwerze — na przykład zrzut wątków i dzienniki lokalne. Główny internetowy interfejs użytkownika zawiera łącza do wszystkich regionalnych interfejsów użytkownika serwera, co czyni go idealnym punktem wejścia do sprawdzania bieżącego stanu klastra HBase.

Serwery REST/Thrift są opcjonalnymi serwerami proxy dla HBase. Rozmawiają z HBase w taki sam sposób, jak robią to inne aplikacje klienckie HBase. Są one jednak zwykle wdrażane w klastrze HBase, razem z innymi serwerami HBase.

Aplikacje klienckie są zwykle wdrażane poza klastrem HBase. Klienci REST/Thrift są również wdrażani poza klastrem. Jeśli klaster HBase znajduje się za zaporą, te odpowiednie porty powinny być domyślnie otwarte:

Aby zezwolić na dostęp aplikacji klienckiej:

• 2181 (hbase.zookeeper.property.clientPort)
• 60000 (hbase.master.port)
• 60020 (hbase.regionserver.port)

Aby zezwolić na dostęp klienta REST/Thrift:

• 8080 (hbase.rest.port)
• 9090 (hbase.regionserver.thrift.port)

Jeśli dozwolony jest dostęp do internetowego interfejsu użytkownika spoza zapory, odpowiednie porty internetowego interfejsu użytkownika również powinny być otwarte:

• 60010 (hbase.master.info.port)
• 60030 (hbase.regionserver.info.port)
• 8085 (hbase.rest.info.port)
• 9095 (hbase.thrift.info.port)

Wniosek

W tym poście masz podsumowanie portów używanych przez wewnętrzne komponenty HBase, aplikacje klienckie i użytkowników/administratorów, uporządkowane według przypadków użycia.

Ponieważ jednak HBase działa na HDFS, ważne jest również, aby znać porty HDFS. Aby uruchomić MapReduce z HBase, musisz również znać porty MapReduce. W przypadku tych portów związanych z usługą Hadoop zapoznaj się z Skróconą instrukcją dotyczącą domyślnych portów usługi Hadoop .

Jimmy Xiang jest inżynierem oprogramowania w zespole Platformy.

> Masz pytania? Opublikuj je na Forum społeczności dla HBase.