HDFS 2.x hög tillgänglighet klusterarkitektur
I den här bloggen ska jag prata om HDFS 2.x High Availability Cluster Architecture och proceduren för att skapa ett HDFS High Availability-kluster.Detta är en viktig del av . Följande ordning har behandlats i den här bloggen:
- HDFS HA-arkitektur
- Introduktion
- NameNode tillgänglighet
- HA-arkitektur
- Implementering av HA (JournalNode och Shared Storage)
- Hur ställer jag in HA (Quorum Journal Nodes) i ett Hadoop-kluster?
Introduktion:
Begreppet High Availability-kluster introducerades i Hadoop 2.x för att lösa problemet med enstaka fel i Hadoop 1.x. Som du vet från min tidigare blogg att följer Master / Slave Topology där NameNode fungerar som en master daemon och är ansvarig för att hantera andra slavnoder som kallas DataNodes. Denna enda Master Daemon eller NameNode blir en flaskhals. Även om introduktionen av Secondary NameNode hindrade oss från att förlora data och ladda ner en del av belastningen på NameNode, men det löste inte tillgänglighetsproblemet med NameNode.
NameNode tillgänglighet:
Om du tar hänsyn till standardkonfigurationen för HDFS-kluster blir NameNode en enda felpunkt . Det händer eftersom det ögonblick som NameNode blir otillgänglig blir hela klustret otillgängligt tills någon startar om NameNode eller tar med en ny.
Orsakerna till att NameNode inte är tillgängliga kan vara:
- En planerad händelse som underhållsarbete har uppgradering av programvara eller hårdvara.
- Det kan också bero på en oplanerad händelse där NameNode kraschar av några anledningar.
I något av ovanstående fall har vi en driftstopp där vi inte kan använda HDFS-klustret som blir en utmaning.
HDFS HA-arkitektur:
Låt oss förstå att hur HDFS HA Architecture löste detta kritiska problem med NameNode-tillgänglighet:
HA-arkitekturen löste detta problem med NameNode-tillgänglighet genom att låta oss ha två NameNodes i en aktiv / passiv konfiguration. Så vi har två körande NameNodes samtidigt i ett hög tillgänglighetskluster:
- Aktivt namnNode
- Standby / passivt namnNode.
Om en NameNode går ner kan den andra NameNode ta över ansvaret och därmed minska tiden för klustret. Standby NameNode tjänar syftet med en backup NameNode (till skillnad från Secondary NameNode) som innehåller failover-funktioner i Hadoop-klustret. Därför kan vi med StandbyNode ha automatisk failover när en NameNode kraschar (oplanerad händelse) eller så kan vi ha en graciös (manuellt initierad) failover under underhållsperioden.
Det finns två problem med att upprätthålla enhetlighet i HDFS-klustret för hög tillgänglighet:
- Active och Standby NameNode ska alltid vara synkroniserade med varandra, dvs. de ska ha samma metadata. Detta gör att vi kan återställa Hadoop-klustret till samma namnutrymmestillstånd där det kraschade och därför kommer vi att få snabb failover.
- Det borde bara finnas en aktiv NameNode åt gången eftersom två aktiva NameNode kommer att leda till korruption av data. Denna typ av scenario kallas ett split-hjärnscenario där ett kluster delas in i mindre kluster, var och en tror att det är det enda aktiva klustret. För att undvika sådana scenarier görs stängsel. Fäktning är en process för att säkerställa att endast en NameNode förblir aktiv vid en viss tidpunkt.
Implementering av HA-arkitektur:
Nu vet du att i HDFS HA Architecture har vi två NameNodes som körs samtidigt. Så vi kan implementera Active- och Standby NameNode-konfigurationen på följande två sätt:
- Använda kvorumjournalloder
- Delad lagring med NFS
Låt oss förstå dessa två sätt att implementera på ett och ett:
1. Använda kvorumjournalnoder:
- Vänteläge NameNode och den aktiva NameNode synkroniseras med varandra genom en separat grupp av noder eller daemoner-kallas JournalNodes .JournalNodes följer ringtopologin där noderna är kopplade till varandra för att bilda en ring.JournalNode serverar begäran som kommer till den och kopierar informationen till andra noder i ringen.Detta ger feltolerans vid JournalNode-fel.
- Den aktiva NameNode är ansvarig för att uppdatera EditLogs (metadatainformation) som finns i JournalNodes.
- StandbyNode läser ändringarna i EditLogs i JournalNode och tillämpar den på sitt eget namnområde på ett konstant sätt.
- Under redundans säkerställer StandbyNode att den har uppdaterat sin metadatainformation från JournalNodes innan den blev den nya Active NameNode. Detta gör att det aktuella namnutrymmestillståndet synkroniseras med tillståndet innan failover.
- IP-adresserna för båda namnen är tillgängliga för alla datanoder och de skickar sina hjärtslag och blockerar platsinformation till båda namnen. Detta ger en snabb failover (mindre stilleståndstid) eftersom StandbyNode har uppdaterad information om blockplatsen i klustret.
Fäktning av NameNode:
Nu, som diskuterats tidigare, är det mycket viktigt att se till att det bara finns en Active NameNode åt gången. Fäktning är en process för att säkerställa just denna egendom i ett kluster.
- JournalNodes utför detta stängsel genom att endast tillåta en NameNode att vara författare åt gången.
- Standby NameNode tar över ansvaret för att skriva till JournalNodes och förbjuder alla andra NameNode att förbli aktiva.
- Slutligen kan den nya Active NameNode utföra sina aktiviteter säkert.
2. Använda delad lagring:
- StandbyNode och den aktiva NameNode synkroniseras med varandra genom att använda a delad lagringsenhet .Den aktiva NameNode loggar posten för eventuella ändringar som gjorts i namnområdet till en EditLog som finns i denna delade lagring.StandbyNode läser ändringarna som gjorts i EditLogs i denna delade lagring och tillämpar den på sitt eget namnområde.
- I händelse av failover uppdaterar StandbyNode först sin metadatainformation med EditLogs i det delade lagringsutrymmet. Sedan tar det ansvaret för Active NameNode. Detta gör att det aktuella namnutrymmestillståndet synkroniseras med tillståndet innan failover.
- Administratören måste konfigurera minst en stängselmetod för att undvika ett split-hjärnscenario.
- Systemet kan använda en rad stängningsmekanismer. Det kan innefatta dödande av NameNode-processen och återkallande av dess åtkomst till den delade lagringskatalogen.
- Som en sista utväg kan vi stänga den tidigare aktiva NameNode med en teknik som kallas STONITH, eller 'skjuta den andra noden i huvudet'. STONITH använder en specialiserad kraftdistributionsenhet för att stänga av NameNode-maskinen med våld.
Automatisk redundans:
Failover är ett förfarande genom vilket ett system automatiskt överför kontroll till sekundärt system när det upptäcker ett fel eller ett fel. Det finns två typer av failover:
Graciös misslyckande: I det här fallet initierar vi manuellt failover för rutinunderhåll.
Automatisk redundans: I det här fallet initieras failover automatiskt i fall av NameNode-fel (oplanerad händelse).
Apache Zookeeper är en tjänst som tillhandahåller automatisk failover-funktion i HDFS-kluster med hög tillgänglighet. Det underhåller små mängder samordningsdata, informerar kunder om förändringar i den informationen och övervakar klienter för fel. Zookeeper håller en session med Namnoderna. I händelse av misslyckande kommer sessionen att upphöra och Zookeeper kommer att informera andra Namnoder för att starta redundansprocessen. I händelse av NameNode-fel kan andra passiva NameNode ta ett lås i Zookeeper om att det vill bli nästa Active NameNode.
ZookeerFailoverController (ZKFC) är en Zookeeper-klient som också övervakar och hanterar NameNode-status. Var och en av NameNode kör också en ZKFC. ZKFC ansvarar för att regelbundet övervaka NamnNodernas hälsa.
Nu när du har förstått vad som är hög tillgänglighet i ett Hadoop-kluster är det dags att ställa in det. För att ställa in hög tillgänglighet i Hadoop-klustret måste du använda Zookeeper i alla noder.
Demonerna i Active NameNode är:
- Djurvakt
- Zookeeper Fail Over controller
- JournalNode
- NameNode
Demonerna i Standby NameNode är:
- Djurvakt
- Zookeeper Fail Over controller
- JournalNode
- NameNode
Demonerna i DataNode är:
- Djurvakt
- JournalNode
- DataNode
Om du vill behärska HDFS och Hadoop, kolla in den speciellt samlade Big Data- och Hadoop-kursen av Edureka. Klicka på knappen nedan för att komma igång.
Konfigurera och konfigurera hög tillgänglighetskluster i Hadoop:
Du måste först ställa in Java- och värdnamn för varje nod.
Virtuell maskin | IP-adress | Värdnamn |
Aktivt namnNode | 192.168.1.81 | nn1.cluster.com eller nn1 |
Standby NameNode | 192.168.1.58 | nn2.cluster.com eller nn2 |
DataNode | 192.168.1.82 | dn1.cluster.com eller dn1 |
Ladda ner Hadoop och Zookeeper binära tar-fil, extrahera filerna för att redigera konfigurationsfiler.
Kommando: wget https://archive.apache.org/dist/zookeeper/zookeeper-3.4.6/zookeeper-3.4.6.tar.gz
Sprid zooeeper-3.4.6.tar.gz
Kommando : tar –xvf zookeeper-3.4.6.tar.gz
Ladda ner den stabila binära tjära Hadoop till från Apache Hadoop-webbplatsen.
Kommando : wget https://archive.apache.org/dist/hadoop/core/hadoop-2.6.0/hadoop-2.6.0.tar.gz
Extrahera Hadoop-tjärkulan.
Kommando : tar –xvf hadoop-2.6.0.tar.gz
Spread hadoop binär.
Lägg till Hadoop, Zookeeper och sökvägar till .bashrc-filen.
Öppna .bashrc-filen.
Kommando : sudo gedit ~ / .bashrc
Lägg till nedanstående vägar:
export HADOOP_HOME = export HADOOP_MAPRED_HOME = $ HADOOP_HOME export HADOOP_COMMON_HOME = $ HADOOP_HOME export HADOOP_HDFS_HOME = $ HADOOP_HOME export YARN_HOME = $ HADOOP_HOME export HADOOP_CONF_DIR = $ HADOOP_HOME / etc / Hadoop export YARN_CONF_DIR = $ HADOOP_HOME / etc / Hadoop export JAVA_HOME = export ZOOKEEPER_HOME = export PATH = $ PATH: $ JAVA_HOME / bin: $ HADOOP_HOME / bin: $ HADOOP_HOME / sbin: $ ZOOKEEPER_HOME / bin
Redigera .bashrc-filen.
Aktivera SSH i hela noden.
Generera SSH-nyckeln i alla noder.
Kommando : ssh-keygen –t rsa (Detta steg i alla noder)
Ställ in SSH-nyckel i alla noder.
Ge inte någon sökväg till Enter-filen för att spara nyckeln och ange inte någon lösenfras. Tryck på Enter-knappen.
Generera ssh-nyckelprocessen i alla noder.
När ssh-nyckel har genererats får du den offentliga nyckeln och den privata nyckeln.
.Ssh-nyckelkatalogen bör innehålla behörighet 700 och alla nycklar i .ssh-katalogen ska innehålla behörigheterna 600.
Ändra SSH-katalogbehörighet.
Ändra katalogen till .ssh och ändra behörigheten för filer till 600
Ändra tillstånd för offentlig och privat nyckel.
Du måste kopiera Namn noder ssh offentlig nyckel till alla noder.
I Active Namenode kopierar du id_rsa.pub med hjälp av cat-kommandot.
Kommando : katt ~ / .ssh / id_rsa.pub >> ~ / .ssh / auktoriserade_knappar
Kopiera Namenode ssh-nyckel till dess auktoriserade nycklar.
Kopiera den allmänna nyckeln NameNode till alla noder med ssh-copy-id kommando.
Kommando : ssh-copy-id –i .ssh / id_rsa.pub edureka@nn2.cluster.com
Kopiera syftetangenten till Standby NameNode.
Kopiera NameNode offentlig nyckel till datanod.
Kommando : ssh-copy-id –i .ssh / id_rsa.pub edureka@dn1.cluster.com
Kopiera Namenode offentlig nyckel till datanod.
Starta om sshd-tjänsten i alla noder.
Kommando : sudo service sshd restart (Gör i alla noder)
Starta om SSH-tjänsten.
Nu kan du logga in på valfri nod från Namenode utan någon autentisering.
Öppna filen core-site.xml från Active Name-noden och lägg till egenskaperna nedan.
Redigera core-site.xml från Active namenode
Öppna hdfs-site.xml-filen i Active Namenode. Lägg till egenskaperna nedan.
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
Ändra katalogen till zookeepers conf-katalog.
Kommando : cd zookeeper-3.4.6 / conf
Zookeeper Conf-katalog.
I en conf-katalog har du zoo_sample.cfg-filen, skapa zoo.cfg med zoo_sample.cfg-filen.
Kommando : cp zoo_sample.cfg zoo.cfg
Skapa zoo.cfg-fil.
Skapa katalogen på vilken plats som helst och använd den här katalogen för att lagra zookeeper-data.
Kommando : mkdir
Skapa en katalog för att lagra zookeeper-data.
Öppna zoo.cfg-filen.
Kommando : gedit zoo.cfg
Lägg till katalogvägen som skapades i ovanstående steg till egenskapen dataDir och lägg till nedanstående information om återstående nod i zoo.cfg-filen.
Server.1 = nn1.cluster.com: 2888: 3888
Server.2 = nn2.cluster.com: 2888: 3888
Server.3 = dn1.cluster.com: 2888: 3888
Redigera zoo.cfg-filen.
Kopiera nu Java- och Hadoop-2.6.0-, zookeeper-3.4.6-katalogerna och .bashrc-filen till alla noder (Standby-namnnod, Data-nod) med scp-kommandot.
Kommando : scp –r edureka @:
Kopiera Hadoop-, Zookeeper- och .bashrc-fil till alla noder.
Kopiera på samma sätt .bashrc-filen och zookeeper-katalogen till alla noder och ändra miljövariablerna i var och en enligt respektive nod.
I en datanod skapar du valfri katalog där du behöver lagra HDFS-blocken.
I en datanod måste du lägga till egenskaperna dfs.datanode.data.dir.
I mitt fall skapade jag datanod katalog för att lagra blocken.
Skapa Datanode-katalog.
Ändra behörigheten till datanodkatalogen.
Ändra Datanode-katalogbehörighet.
Öppna filen HDFS-site.xml, lägg till denna Datanode-katalogsökväg i egenskapen dfs.datanode.data.dir.
Obs: Behåll alla egenskaper som kopieras från Active namenode lägg till dfs.datanode.data.dir en extraheringsegenskap i namenode.
dfs.datanode.data.dir / home / edureka / HA / data / datanode
I Active namenode ändrar du katalogen där du vill lagra zookeeper-konfigurationsfilen (dataDir-egenskapssökväg).
Skapa myid-filen i katalogen och lägg till nummer 1 i filen och spara filen.
Kommando : vi myid
Skapa myid-fil.
Ändra katalogen där du vill lagra zookeeper-konfigurationsfilen (dataDir-egenskapssökväg) i en vänteläge.
Skapa myid-filen i katalogen och lägg till nummer 2 i filen och spara filen.
I en datanod ändrar du katalogen där du vill lagra zookeeper-konfigurationsfilen (dataDir-egenskapssökväg).
Skapa myid-filen i katalogen och lägg till nummer 3 i filen och spara filen.
Starta Journalnode i alla tre noder.
Kommando : hadoop-daemon.sh start journalnode
Starta Journalnode.
När du anger jps-kommandot ser du JournalNode-demonen i alla noder.
FormateraAktivt syfte.
Kommando : HDFS avsedd -format
Aktivt NameNode-format.
Starta Namenode-demonen och Active Namedode.
Kommando : hadoop-daemon.sh start syfte
Starta Namenode.
Kopiera HDFS Meta-data från aktivt namn nod till standby namenode.
Kommando : HDFS avsedd -bootstrapStandby
Kopiera HDFS-metadata från Active name-nod till Standby Namenode.
När du kör det här kommandot får du informationen från vilken nod och plats metadata kopieras och om den kopieras framgångsrikt eller inte.
Information om detaljer för aktivt syfte.
När Metadata har kopierats från Aktiv namenode till standby namenode får du meddelandet nedan på skärmdumpen.
Information om HDFS i Standby Namenode.
Starta namenode-demon i standby-namenode-maskin.
Kommando : hadoop-daemon.sh start syfte
Starta nu Zookeeper-tjänsten i alla tre noder.
Kommando : zkServer.sh start (Kör det här kommandot i alla noder)
I aktivt syfte:
Starta zookeeper i Active NameNode.
I Standby Namenode:
Starta zooeeper i standby NameNode.
I datanod:
Starta zookeeper i DataNode.
När du har kört Zookeeper-servern anger du JPS-kommandot. I alla noder ser du QuorumPeerMain-tjänsten.
Starta datanoddemonen i datanodsmaskinen.
Kommando : hadoop-daemon.sh starta datanod
Starta Zookeeper fail over controller i Active name node och standby name node.
Formatera zookeeper fail over controller i Active namenode.
Kommando: HDFS zkfc –formatZK
Formatera ZKFC.
Starta ZKFC i Active namenode.
Kommando : hadoop-daemon.sh starta zkfc
Ange jps-kommandot för att kontrollera DFSZkFailoverController-demonerna.
Starta ZKFC.
Formatera zookeeper fail over controller i Standby-namnet.
Kommando : hdfs zkfc –formatZK
Starta ZKFC i standby-namnet.
Kommando : hadoop-daemon.sh starta zkfc
Ange jps-kommandot för att kontrollera DFSZkFailoverController-demonerna.
Kontrollera nu statusen för varje Namenode, vilken nod som är aktiv eller vilken nod som är i beredskap genom att använda kommandot nedan.
Kommando : hdfs haadmin –getServiceState nn1
Kontrollera status för varje NameNode.
Kontrollera nu statusen för varje Namenode med hjälp av webbläsaren.
Öppna webbläsaren och ange webbadressen nedan.
: 50070
Det kommer att visa om namnet är aktiv eller i beredskap.
Aktivt namnNode.
Öppna information om en annan namnnod med hjälp av webbläsaren.
Standby NameNode.
I Active namenode dödar du namenode-demonen för att ändra standby-namnnoden till aktiv namenode.
Ange jps i Active namenode och döda daemon.
Kommando: sudo kill -9
Daemons Process ID.
Namenode-process-ID: t är 7606, döda namenoden.
Kommando : Sudo kill -9 7606
datastrukturer och algoritmer i Java
Döda Namnodsprocessen
Öppna de två noderna via webbläsaren och kontrollera statusen.
Namenode detaljer.
NamnNodsstatus.
Grattis, du har framgångsrikt konfigurerat ett HDFS-kluster med hög tillgänglighet i Hadoop.
Nu när du har förstått Hadoop High Availability Cluster Architecture, kolla in av Edureka, ett pålitligt inlärningsföretag online med ett nätverk av mer än 250 000 nöjda elever spridda över hela världen. Edureka Big Data Hadoop-certifieringskursen hjälper eleverna att bli experter på HDFS, Garn, MapReduce, Pig, Hive, HBase, Oozie, Flume och Sqoop med realtidsanvändningsfall på Retail, Social Media, Aviation, Tourism, Finance.
Har du en fråga till oss? Vänligen nämna det i kommentarfältet så återkommer vi till dig.
fönster._LQ_ = fönster._LQ_ || {}
lqQuizModal (fönster, dokument, {quizId: 'XAIVp8', baseUrl: 'https: //quiz.leadquizzes.com/',trigger:' exit '}, _LQ_)