Architektura klastra HDFS 2.x o wysokiej dostępności
Na tym blogu omówię architekturę klastra wysokiej dostępności HDFS 2.x oraz procedurę konfigurowania klastra wysokiej dostępności HDFS.To jest ważna część . Kolejność poruszania tematów na tym blogu jest następująca:
- Architektura HDFS HA
- Wprowadzenie
- Dostępność NameNode
- Architektura HA
- Implementacja HA (JournalNode i Shared Storage)
- Jak skonfigurować HA (Quorum Journal Nodes) w klastrze Hadoop?
Wprowadzenie:
Koncepcja klastra wysokiej dostępności została wprowadzona w Hadoop 2.x, aby rozwiązać problem pojedynczego punktu awarii w Hadoop 1.x. Jak wiesz z mojego poprzedniego bloga, że podąża za topologią Master / Slave, w której NameNode działa jako demon główny i jest odpowiedzialny za zarządzanie innymi węzłami podrzędnymi zwanymi DataNodes. Ten pojedynczy demon główny lub NameNode staje się wąskim gardłem. Chociaż wprowadzenie Secondary NameNode uchroniło nas przed utratą danych i odciążeniem części NameNode, ale nie rozwiązało problemu dostępności NameNode.
Dostępność NameNode:
Jeśli weźmiesz pod uwagę standardową konfigurację klastra HDFS, NameNode zmieni się w plik pojedynczy punkt awarii . Dzieje się tak, ponieważ w momencie, gdy NameNode staje się niedostępny, cały klaster staje się niedostępny, dopóki ktoś nie uruchomi ponownie NameNode lub nie przyniesie nowego.
Przyczyny niedostępności NameNode mogą być następujące:
- Planowane zdarzenie, takie jak prace konserwacyjne, wymaga aktualizacji oprogramowania lub sprzętu.
- Może to być również spowodowane nieplanowanym zdarzeniem, w którym NameNode ulega awarii z pewnych powodów.
W każdym z powyższych przypadków mamy przestój, w którym nie możemy korzystać z klastra HDFS, co staje się wyzwaniem.
Architektura HDFS HA:
Rozumiemy, jak architektura HDFS HA rozwiązała ten krytyczny problem dostępności NameNode:
Architektura HA rozwiązała ten problem dostępności NameNode, pozwalając nam mieć dwa NameNodes w konfiguracji aktywnej / pasywnej. Mamy więc dwa działające NameNodes w tym samym czasie w klastrze o wysokiej dostępności:
- Aktywny NameNode
- Standby / Passive NameNode.
Jeśli jeden NameNode ulegnie awarii, drugi NameNode może przejąć odpowiedzialność, a tym samym skrócić czas przestoju klastra. Standby NameNode służy jako zapasowy NameNode (w przeciwieństwie do Secondary NameNode), który obejmuje funkcje przełączania awaryjnego w klastrze Hadoop. Dlatego dzięki StandbyNode możemy mieć automatyczne przełączanie awaryjne za każdym razem, gdy NameNode ulegnie awarii (zdarzenie nieplanowane) lub możemy mieć wdzięczne (ręcznie zainicjowane) przełączenie awaryjne w okresie konserwacji.
Istnieją dwa problemy z utrzymaniem spójności w klastrze HDFS High Availability:
- Active i Standby NameNode powinny być zawsze zsynchronizowane ze sobą, tj. Powinny mieć te same metadane. Umożliwi nam to przywrócenie klastra Hadoop do tego samego stanu przestrzeni nazw, w którym uległ awarii, a tym samym zapewni szybkie przełączanie awaryjne.
- W danym momencie powinien istnieć tylko jeden aktywny NameNode, ponieważ dwa aktywne NameNode spowodują uszkodzenie danych. Ten rodzaj scenariusza jest określany jako scenariusz podzielonego mózgu, w którym klaster zostaje podzielony na mniejsze klastry, z których każdy uważa, że jest jedynym aktywnym klastrem. Aby uniknąć takich scenariuszy, robi się szermierkę. Szermierka to proces zapewniający, że tylko jeden NameNode pozostaje aktywny w określonym czasie.
Wdrożenie Architektury HA:
Teraz wiesz, że w architekturze HDFS HA mamy dwa NameNodes działające w tym samym czasie. Tak więc możemy zaimplementować konfigurację Active i Standby NameNode na dwa sposoby:
- Korzystanie z węzłów dziennika kworum
- Pamięć współdzielona przy użyciu NFS
Rozumiemy te dwa sposoby implementacji po kolei:
1. Korzystanie z węzłów dziennika kworum:
- Stan gotowości NameNode i aktywny NameNode są ze sobą zsynchronizowane poprzez oddzielną grupę węzłów lub demonów - nazywane JournalNodes .JournalNodes jest zgodny z topologią pierścienia, w której węzły są połączone ze sobą, tworząc pierścień.JournalNode obsługuje przychodzące do niego żądanie i kopiuje informacje do innych węzłów w pierścieniu.Zapewnia to odporność na uszkodzenia w przypadku awarii JournalNode.
- Aktywny NameNode jest odpowiedzialny za aktualizację EditLogs (informacje metadanych) obecnych w JournalNodes.
- StandbyNode odczytuje zmiany wprowadzone w EditLogs w JournalNode i stosuje je do własnej przestrzeni nazw w sposób stały.
- Podczas przełączania awaryjnego StandbyNode upewnia się, że zaktualizował swoje metadane z JournalNodes, zanim stanie się nowym Active NameNode. Dzięki temu bieżący stan przestrzeni nazw jest synchronizowany ze stanem sprzed przełączenia awaryjnego.
- Adresy IP obu NameNodes są dostępne dla wszystkich DataNodes i wysyłają one swoje bicie serca i blokują informacje o lokalizacji do obu NameNode. Zapewnia to szybkie przełączanie awaryjne (krótszy czas przestoju), ponieważ węzeł StandbyNode ma zaktualizowane informacje o lokalizacji bloku w klastrze.
Ogrodzenie NameNode:
Teraz, jak omówiono wcześniej, bardzo ważne jest, aby w danym momencie istniał tylko jeden aktywny węzeł NameNode. Ogrodzenie jest więc procesem zapewniającym tę właśnie własność w klastrze.
- JournalNodes wykonuje to ogrodzenie, pozwalając tylko jednemu NameNode być pisarzem naraz.
- Standby NameNode przejmuje odpowiedzialność za zapisywanie do JournalNodes i zabrania innym NameNode pozostania aktywnym.
- Wreszcie, nowy Active NameNode może bezpiecznie wykonywać swoje działania.
2. Korzystanie z pamięci współdzielonej:
- StandbyNode i aktywny NameNode są zsynchronizowane ze sobą przy użyciu pliku udostępnione urządzenie pamięci masowej .Aktywny NameNode rejestruje wszelkie modyfikacje dokonane w jego przestrzeni nazw w EditLog obecnym w tym współużytkowanym magazynie.StandbyNode odczytuje zmiany wprowadzone w EditLogs w tym współużytkowanym magazynie i stosuje je do własnej przestrzeni nazw.
- Teraz, w przypadku przełączenia awaryjnego, StandbyNode aktualizuje najpierw informacje metadanych przy użyciu EditLogs w pamięci współużytkowanej. Następnie przejmuje odpowiedzialność za Active NameNode. Dzięki temu bieżący stan przestrzeni nazw jest synchronizowany ze stanem sprzed przełączenia awaryjnego.
- Administrator musi skonfigurować co najmniej jedną metodę ogrodzenia, aby uniknąć scenariusza z podzielonym mózgiem.
- System może wykorzystywać szereg mechanizmów ogrodzeniowych. Może obejmować zabicie procesu NameNode i odebranie mu dostępu do katalogu współdzielonej pamięci.
- W ostateczności możemy odgrodzić aktywny wcześniej NameNode techniką znaną jako STONITH lub „strzelić drugiemu węzłowi w głowę”. STONITH używa wyspecjalizowanej jednostki dystrybucji zasilania, aby wymusić wyłączenie maszyny NameNode.
Automatyczne przełączanie awaryjne:
Przełączanie awaryjne to procedura, za pomocą której system automatycznie przekazuje sterowanie do systemu pomocniczego w przypadku wykrycia usterki lub awarii. Istnieją dwa rodzaje przełączania awaryjnego:
Wdzięczne przełączanie awaryjne: W takim przypadku ręcznie inicjujemy przełączanie awaryjne w celu rutynowej konserwacji.
Automatyczne przełączanie awaryjne: W takim przypadku przełączenie awaryjne jest inicjowane automatycznie w przypadku awarii NameNode (nieplanowane zdarzenie).
Apache Zookeeper to usługa zapewniająca możliwość automatycznego przełączania awaryjnego w klastrze HDFS High Availabilty. Utrzymuje niewielkie ilości danych koordynacyjnych, informuje klientów o zmianach w tych danych i monitoruje klientów pod kątem awarii. Zookeeper utrzymuje sesję z NameNodes. W przypadku niepowodzenia sesja wygaśnie, a Zookeeper poinformuje inne NameNodes o zainicjowaniu procesu przełączania awaryjnego. W przypadku awarii NameNode, inny pasywny NameNode może zablokować Zookeepera, stwierdzając, że chce stać się kolejnym aktywnym NameNode.
ZookeerFailoverController (ZKFC) to klient Zookeeper, który również monitoruje i zarządza stanem NameNode. Każdy z NameNode uruchamia również ZKFC. ZKFC jest odpowiedzialne za okresowe monitorowanie stanu węzłów NameNodes.
Skoro już wiesz, czym jest wysoka dostępność w klastrze Hadoop, czas ją skonfigurować. Aby skonfigurować wysoką dostępność w klastrze Hadoop, musisz używać Zookeepera we wszystkich węzłach.
Demony w Active NameNode to:
- Zookeeper
- Kontroler Zookeeper Fail Over
- JournalNode
- NameNode
Demony w Standby NameNode to:
- Zookeeper
- Kontroler Zookeeper Fail Over
- JournalNode
- NameNode
Demony w DataNode to:
- Zookeeper
- JournalNode
- DataNode
Jeśli chcesz opanować HDFS i Hadoop, sprawdź specjalnie przygotowany kurs Big Data i Hadoop firmy Edureka. Kliknij poniższy przycisk, aby rozpocząć.
Konfigurowanie i konfigurowanie klastra wysokiej dostępności na platformie Hadoop:
Najpierw musisz ustawić Java i nazwy hostów dla każdego węzła.
Maszyna wirtualna | adres IP | Nazwa hosta |
Aktywny NameNode | 192.168.1.81 | nn1.cluster.com lub nn1 |
Standby NameNode | 192.168.1.58 | nn2.cluster.com lub nn2 |
DataNode | 192.168.1.82 | dn1.cluster.com lub dn1 |
Pobierz binarny plik tar Hadoop i Zookeeper, wyodrębnij pliki, aby edytować pliki konfiguracyjne.
Komenda : wget https://archive.apache.org/dist/zookeeper/zookeeper-3.4.6/zookeeper-3.4.6.tar.gz
Rozłóż zookeeper-3.4.6.tar.gz
Komenda : tar –xvf zookeeper-3.4.6.tar.gz
Pobierz stabilną binarną tarę Hadoop z witryny Apache Hadoop.
Komenda : wget https://archive.apache.org/dist/hadoop/core/hadoop-2.6.0/hadoop-2.6.0.tar.gz
Wyciągnij kulkę smoły Hadoop.
Komenda : tar –xvf hadoop-2.6.0.tar.gz
czym jest abstrakcja w c ++
Rozprzestrzeniaj binarny hadoop.
Dodaj Hadoop, Zookeeper i ścieżki do pliku .bashrc.
Otwórz plik .bashrc.
Komenda : sudo gedit ~ / .bashrc
Dodaj poniższe ścieżki:
eksport HADOOP_HOME = eksport HADOOP_MAPRED_HOME = $ HADOOP_HOME eksport HADOOP_COMMON_HOME = $ HADOOP_HOME eksport HADOOP_HDFS_HOME = $ HADOOP_HOME eksport YARN_HOME = $ HADOOP_HOME eksport HADOOP_CONF_DIR = $ HADOOP_HOME / etc / Hadoop eksport YARN_CONF_DIR = $ HADOOP_HOME / etc / eksport Hadoop JAVA_HOME = eksport ZOOKEEPER_HOME = export PATH = $ PATH: $ JAVA_HOME / bin: $ HADOOP_HOME / bin: $ HADOOP_HOME / sbin: $ ZOOKEEPER_HOME / bin
Edytuj plik .bashrc.
Włącz SSH we wszystkich węzłach.
Wygeneruj klucz SSH we wszystkich węzłach.
Komenda : ssh-keygen –t rsa (ten krok we wszystkich węzłach)
Skonfiguruj klucz SSH we wszystkich węzłach.
Nie podawaj żadnej ścieżki do pliku Enter, aby zapisać klucz i nie podawaj żadnego hasła. Naciśnij przycisk Enter.
Wygeneruj proces klucza ssh we wszystkich węzłach.
Po wygenerowaniu klucza ssh otrzymasz klucz publiczny i klucz prywatny.
Katalog kluczy .ssh powinien zawierać Permission 700, a wszystkie klucze w katalogu .ssh powinny zawierać uprawnienia 600.
Zmień uprawnienia katalogu SSH.
Zmień katalog na .ssh i zmień uprawnienia plików na 600
Zmień uprawnienia klucza publicznego i prywatnego.
Musisz skopiować klucz publiczny Name nodes ssh do wszystkich węzłów.
W Active Namenode skopiuj id_rsa.pub za pomocą polecenia cat.
Komenda : cat ~ / .ssh / id_rsa.pub >> ~ / .ssh / autoryzowane_klucze
Skopiuj klucz Namenode ssh do jego autoryzowanych kluczy.
Skopiuj klucz publiczny NameNode do wszystkich węzłów przy użyciu ssh-copy-id Komenda.
Komenda : ssh-copy-id –i .ssh / id_rsa.pub edureka@nn2.cluster.com
Skopiuj klucz celu do Standby NameNode.
Skopiuj klucz publiczny NameNode do węzła danych.
Komenda : ssh-copy-id –i .ssh / id_rsa.pub edureka@dn1.cluster.com
Skopiuj klucz publiczny Namenode do węzła danych.
Uruchom ponownie usługę sshd we wszystkich węzłach.
Komenda : sudo service sshd restart (wykonaj we wszystkich węzłach)
Uruchom ponownie usługę SSH.
Teraz możesz zalogować się do dowolnego węzła z Namenode bez żadnego uwierzytelniania.
Otwórz plik core-site.xml z węzła Active Name i dodaj poniższe właściwości.
Edytuj core-site.xml z Active namenode
Otwórz plik hdfs-site.xml w Active Namenode. Dodaj poniższe właściwości.
dfs.namenode.name.dir / home / edureka / HA / data / namenode dfs.replication 1 dfs.permissions false dfs.nameservices ha-cluster dfs.ha.namenodes.ha-cluster nn1, nn2 dfs.namenode.rpc-address .ha-cluster.nn1 nn1.cluster.com:9000 dfs.namenode.rpc-address.ha-cluster.nn2 nn2.cluster.com:9000 dfs.namenode.http-address.ha-cluster.nn1 nn1.cluster. com: 50070 dfs.namenode.http-address.ha-cluster.nn2 nn2.cluster.com:50070 dfs.namenode.shared.edits.dir qjournal: //nn1.cluster.com: 8485nn2.cluster.com: 8485dn1. cluster.com:8485/ha-cluster dfs.client.failover.proxy.provider.ha-cluster org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider dfs.ha.automatic-failover.enabled true ha.zookeeper .quorum nn1.cluster.com:2181,nn2.cluster.com:2181,dn1.cluster.com:2181 dfs.ha.fencing.methods sshfence dfs.ha.fencing.ssh.private-key-files / home / edureka /.ssh/id_rsa
Zmień katalog na katalog conf zookeepera.
Komenda : cd zookeeper-3.4.6 / conf
Katalog Zookeeper Conf.
W katalogu conf masz plik zoo_sample.cfg, utwórz zoo.cfg używając pliku zoo_sample.cfg.
jak zmienić ścieżkę java
Komenda : cp zoo_sample.cfg zoo.cfg
Utwórz plik zoo.cfg.
Utwórz katalog w dowolnym miejscu i użyj tego katalogu do przechowywania danych zookeeper.
Komenda : mkdir
Utwórz katalog do przechowywania danych zookeeper.
Otwórz plik zoo.cfg.
Komenda : gedit zoo.cfg
Dodaj ścieżkę do katalogu utworzoną w powyższym kroku do właściwości dataDir i dodaj poniższe szczegóły dotyczące pozostałego węzła w pliku zoo.cfg.
Serwer.1 = nn1.cluster.com: 2888: 3888
Serwer.2 = nn2.cluster.com: 2888: 3888
Server.3 = dn1.cluster.com: 2888: 3888
Edytuj plik zoo.cfg.
Teraz skopiuj katalogi Java i Hadoop-2.6.0, zookeeper-3.4.6 oraz plik .bashrc do wszystkich węzłów (węzeł nazwy trybu gotowości, węzeł danych) za pomocą polecenia scp.
Komenda : scp –r edureka @:
Skopiuj pliki Hadoop, Zookeeper i .bashrc do wszystkich węzłów.
Podobnie, skopiuj plik .bashrc i katalog zookeeper do wszystkich węzłów i zmień zmienne środowiskowe w każdym z nich zgodnie z odpowiednim węzłem.
W węźle danych utwórz dowolny katalog, w którym chcesz przechowywać bloki HDFS.
W węźle danych należy dodać właściwości dfs.datanode.data.dir.
W moim przypadku stworzyłem datanode katalog do przechowywania bloków.
Utwórz katalog Datanode.
Zmień uprawnienia do katalogu węzłów danych.
Zmień uprawnienia do katalogu Datanode.
Otwórz plik HDFS-site.xml, dodaj tę ścieżkę katalogu Datanode do właściwości dfs.datanode.data.dir.
Uwaga: Zachowaj wszystkie właściwości skopiowane z aktywnego namenode add dfs.datanode.data.dir jedną właściwość wyodrębniania w namenode.
dfs.datanode.data.dir / home / edureka / HA / data / datanode
W Active namenode zmień katalog, w którym chcesz przechowywać plik konfiguracyjny zookeeper (ścieżka właściwości dataDir).
Utwórz plik myid w katalogu, dodaj numer 1 do pliku i zapisz plik.
Komenda : vi myid
Utwórz plik myid.
W stanie gotowości zmień katalog, w którym chcesz przechowywać plik konfiguracyjny zookeeper (ścieżka właściwości dataDir).
Utwórz plik myid w katalogu, dodaj numer 2 do pliku i zapisz plik.
W węźle danych zmień katalog, w którym chcesz przechowywać plik konfiguracyjny zookeeper (ścieżka właściwości dataDir).
Utwórz plik myid w katalogu, dodaj numer 3 do pliku i zapisz plik.
Uruchom węzeł dziennika we wszystkich trzech węzłach.
Komenda : hadoop-daemon.sh start journalnode
Uruchom Journalnode.
Po wpisaniu polecenia jps zobaczysz demona JournalNode we wszystkich węzłach.
Sformatuj plikAktywny cel.
Komenda : Przeznaczony dla HDFS -format
Aktywny format NameNode.
Uruchom demona Namenode i Active Namedode.
Komenda : hadoop-daemon.sh cel początkowy
Uruchom Namenode.
Skopiuj metadane HDFS z węzła nazwy aktywnej do rezerwowego węzła nazwy.
Komenda : Przeznaczony dla HDFS -bootstrapStandby
Skopiuj metadane HDFS z węzła Active name do Standby Namenode.
Po uruchomieniu tego polecenia uzyskasz informacje, z którego węzła i lokalizacji kopiowane są metadane i czy są one kopiowane pomyślnie, czy nie.
Informacje o szczegółach aktywnego celu.
Po skopiowaniu metadanych z aktywnego namenode do gotowego namenode, pojawi się komunikat pokazany poniżej na zrzucie ekranu.
Informacje dotyczące HDFS w Standby Namenode.
Uruchom demona namenode w Standby namenode machine.
Komenda : hadoop-daemon.sh cel początkowy
Teraz uruchom usługę Zookeeper we wszystkich trzech węzłach.
Komenda : zkServer.sh start (uruchom to polecenie we wszystkich węzłach)
W aktywnym celu:
Uruchom zookeeper w Active NameNode.
W trybie czuwania Namenode:
Uruchom zookeeper w trybie gotowości NameNode.
W węźle danych:
Uruchom zookeeper w DataNode.
Po uruchomieniu serwera Zookeeper wprowadź polecenie JPS. We wszystkich węzłach zobaczysz usługę QuorumPeerMain.
Uruchom demona węzła danych na komputerze węzła danych.
Komenda : hadoop-daemon.sh start datanode
Uruchom kontroler failover Zookeeper w węźle nazwy aktywnej i węźle nazwy rezerwowej.
Sformatuj kontroler failover zookeeper w Active namenode.
Komenda: HDFS zkfc - format ZK
Formatuj ZKFC.
Uruchom ZKFC w Active namenode.
Komenda : hadoop-daemon.sh start zkfc
Wpisz polecenie jps, aby sprawdzić demony DFSZkFailoverController.
Uruchom ZKFC.
Sformatuj kontroler failover zookeeper w trybie nazwy Standby.
Komenda : hdfs zkfc –formatZK
Uruchom ZKFC w trybie nazw Standby.
Komenda : hadoop-daemon.sh start zkfc
Wpisz polecenie jps, aby sprawdzić demony DFSZkFailoverController.
Teraz sprawdź stan każdego Namenode, który węzeł jest aktywny lub który węzeł jest w trybie gotowości, używając poniższego polecenia.
Komenda : hdfs haadmin –getServiceState nn1
Sprawdź stan każdego NameNode.
pobierz długość tablicy js
Teraz sprawdź stan każdego Namenode za pomocą przeglądarki internetowej.
Otwórz przeglądarkę internetową i wprowadź poniższy adres URL.
: 50070
Pokaże, czy nazwa węzła jest aktywna czy w stanie wstrzymania.
Aktywny NameNode.
Otwórz szczegóły innego węzła nazw za pomocą przeglądarki internetowej.
Standby NameNode.
W aktywnym kodzie nazw zabij demona kodu nazw, aby zmienić węzeł nazwy trybu gotowości na aktywny kod nazwy.
Wpisz jps w Active namenode i zabij demona.
Komenda: sudo kill -9
Identyfikator procesu demona.
Identyfikator procesu Namenode to 7606, zabij namenode.
Komenda : Sudo kill -9 7606
Zabij proces Name Node
Otwórz dwa węzły za pomocą przeglądarki internetowej i sprawdź stan.
Szczegóły Namenode.
Status NameNode.
Gratulacje, pomyślnie skonfigurowałeś klaster wysokiej dostępności HDFS na platformie Hadoop.
Po zapoznaniu się z architekturą klastra o wysokiej dostępności Hadoop zapoznaj się z autorstwa Edureka, zaufanej firmy zajmującej się edukacją online, z siecią ponad 250 000 zadowolonych uczniów rozsianych po całym świecie. Szkolenie Edureka Big Data Hadoop Certification Training pomaga uczniom stać się ekspertami w dziedzinie HDFS, Yarn, MapReduce, Pig, Hive, HBase, Oozie, Flume i Sqoop, wykorzystując przypadki użycia w czasie rzeczywistym w domenie handlu detalicznego, mediów społecznościowych, lotnictwa, turystyki, finansów.
Masz do nas pytanie? Wspomnij o tym w sekcji komentarzy, a my skontaktujemy się z Tobą.
window._LQ_ = window._LQ_ || {}
lqQuizModal (window, document, {quizId: ’XAIVp8 ′, baseUrl:’ https: //quiz.leadquizzes.com/’,trigger: ’exit’}, _LQ_)