Hvordan sette opp Hadoop Cluster med HDFS høy tilgjengelighet

HDFS 2.x Cluster Architecture for høy tilgjengelighet

I denne bloggen skal jeg snakke om HDFS 2.x High Availability Cluster Architecture og prosedyren for å sette opp en HDFS High Availability-klynge.Dette er en viktig del av . Rekkefølgen temaene har blitt dekket i denne bloggen er som følger:

• HDFS HA-arkitektur
  • Introduksjon
  • NameNode tilgjengelighet
  • Arkitektur av HA
  • Implementering av HA (JournalNode og delt lagring)
• Hvordan sette opp HA (Quorum Journal Nodes) i en Hadoop-klynge?

Introduksjon:

Konseptet med High Availability-klynge ble introdusert i Hadoop 2.x for å løse problemet med det eneste feilpunktet i Hadoop 1.x. Som du vet fra min forrige blogg at følger Master / Slave Topology der NameNode fungerer som en master daemon og er ansvarlig for å administrere andre slave noder kalt DataNodes. Denne eneste Master Daemon eller NameNode blir en flaskehals. Selv om introduksjonen av Secondary NameNode forhindret oss i å miste data og laste ut noe av byrden til NameNode, men det løste ikke problemet med tilgjengeligheten av NameNode.

NameNode tilgjengelighet:

Hvis du vurderer standardkonfigurasjonen av HDFS-klyngen, blir NameNode en enkelt feilpunkt . Det skjer fordi det øyeblikket NameNode blir utilgjengelig, blir hele klyngen utilgjengelig til noen starter NameNode på nytt eller bringer en ny.

Årsakene til at NameNode ikke er tilgjengelige, kan være:

• En planlagt hendelse som vedlikeholdsarbeid, har oppgradering av programvare eller maskinvare.
• Det kan også skyldes en ikke-planlagt hendelse der NameNode krasjer på grunn av noen årsaker.

I noen av de ovennevnte tilfellene har vi en nedetid der vi ikke er i stand til å bruke HDFS-klyngen som blir en utfordring.

HDFS HA-arkitektur:

La oss forstå at hvordan HDFS HA ​​Architecture løste dette kritiske problemet med tilgjengeligheten av NameNode:

HA-arkitekturen løste dette problemet med tilgjengeligheten av NameNode ved å la oss ha to NameNodes i en aktiv / passiv konfigurasjon. Så vi har to kjørende NameNodes samtidig i en høy tilgjengelighetsklynge:

• Aktivt navnNode
• Standby / passiv navnNode.

Hvis den ene NameNode går ned, kan den andre NameNode ta over ansvaret og derfor redusere nedetid for klyngen. Standby NameNode tjener formålet med en backup NameNode (i motsetning til Secondary NameNode) som inkluderer failover-funksjoner i Hadoop-klyngen. Derfor, med StandbyNode, kan vi ha automatisk failover når en NameNode krasjer (ikke planlagt hendelse) eller vi kan ha en grasiøs (manuelt startet) failover i vedlikeholdsperioden.

Det er to problemer med å opprettholde konsistens i HDFS-klyngen for høy tilgjengelighet:

• Active og Standby NameNode skal alltid være synkronisert med hverandre, dvs. de skal ha samme metadata. Dette vil tillate oss å gjenopprette Hadoop-klyngen til den samme navneområdet som den krasjet, og vil derfor gi oss rask failover.
• Det bør bare være en aktiv NameNode om gangen, fordi to aktive NameNode vil føre til korrupsjon av dataene. Denne typen scenario blir betegnet som et splittet hjernescenario der en klynge blir delt inn i mindre klynger, og hver av dem tror at den er den eneste aktive klyngen. For å unngå slike scenarier er gjerder gjort. Fekting er en prosess for å sikre at bare en NameNode forblir aktiv på et bestemt tidspunkt.

Implementering av HA-arkitektur:

Nå vet du at i HDFS HA ​​Architecture har vi to NameNodes som kjører samtidig. Så vi kan implementere Active- og Standby NameNode-konfigurasjonen på følgende to måter:

1. Bruke Quorum Journal Nodes
2. Delt lagring ved hjelp av NFS

La oss forstå disse to måtene å implementere på, en og en om gangen:

1. Bruke Quorum Journal Nodes:

• Standby NameNode og den aktive NameNode synkroniseres med hverandre gjennom en egen gruppe noder eller demoner som kalles JournalNodes .JournalNodes følger ringtopologien der nodene er koblet til hverandre for å danne en ring.JournalNode serverer forespørselen som kommer til den og kopierer informasjonen til andre noder i ringen.Dette gir feiltoleranse i tilfelle JournalNode-feil.
• Den aktive NameNode er ansvarlig for å oppdatere EditLogs (metadatainformasjonen) som finnes i JournalNodes.
• StandbyNode leser endringene som er gjort i EditLogs i JournalNode og bruker den på sitt eget navneområde på en konstant måte.
• Under failover sørger StandbyNode for at den har oppdatert metadatainformasjonen fra JournalNodes før den ble den nye Active NameNode. Dette gjør gjeldende navneromstilstand synkronisert med staten før failover.
• IP-adressene til begge NameNodes er tilgjengelige for alle DataNodes, og de sender hjerteslag og blokkerer posisjonsinformasjon til både NameNode. Dette gir en rask failover (mindre nedetid) ettersom StandbyNode har oppdatert informasjon om blokkeringsplasseringen i klyngen.

Fekting av NameNode:

Nå, som diskutert tidligere, er det veldig viktig å sikre at det bare er en Active NameNode om gangen. Fekting er altså en prosess for å sikre denne egenskapen i en klynge.

• JournalNodes utfører denne gjerdingen ved å la bare én NameNode være skribenten om gangen.
• Standby NameNode overtar ansvaret for å skrive til JournalNodes og forby enhver annen NameNode å forbli aktiv.
• Endelig kan den nye Active NameNode utføre sine aktiviteter trygt.

2. Bruke delt lagring:

• StandbyNode og den aktive NameNode synkroniseres med hverandre ved å bruke a delt lagringsenhet .Den aktive NameNode logger registreringen av endringer som er gjort i navneområdet til en EditLog som er tilstede i denne delte lagringen.StandbyNode leser endringene som er gjort i EditLogs i denne delte lagringen og bruker den på sitt eget navneområde.
• Nå, i tilfelle failover, oppdaterer StandbyNode først metadatainformasjonen ved hjelp av EditLogs i den delte lagringen. Deretter tar det ansvaret for Active NameNode. Dette gjør gjeldende navneromstilstand synkronisert med staten før failover.
• Administratoren må konfigurere minst en gjerdemetode for å unngå et scenario med delt hjerne.
• Systemet kan benytte en rekke gjerdemekanismer. Det kan omfatte avlivning av NameNode-prosessen og tilbakekalling av tilgangen til katalogen for delt lagring.
• Som en siste utvei kan vi gjerde den tidligere aktive NameNode med en teknikk kjent som STONITH, eller 'skyte den andre noden i hodet'. STONITH bruker en spesialisert kraftfordelingsenhet for å slå av NameNode-maskinen med makt.

Automatisk failover:

Failover er en prosedyre der et system automatisk overfører kontroll til sekundært system når det oppdager en feil eller feil. Det er to typer failover:

Grasiøs redning: I dette tilfellet starter vi failover manuelt for rutinemessig vedlikehold.

Automatisk failover: I dette tilfellet startes failover automatisk i tilfelle NameNode-feil (ikke planlagt hendelse).

Apache Zookeeper er en tjeneste som gir automatisk failover-funksjonalitet i HDFS-klyngen med høy tilgjengelighet. Den opprettholder små mengder koordineringsdata, informerer klienter om endringer i disse dataene og overvåker klienter for feil. Zookeeper opprettholder en økt med NameNodes. I tilfelle feil, økten vil utløpe, og dyrehagen vil informere andre navnekoder om å starte failover-prosessen. I tilfelle NameNode-feil, kan andre passive NameNode ta en lås i Zookeeper som sier at den vil bli neste Active NameNode.

ZookeerFailoverController (ZKFC) er en Zookeeper-klient som også overvåker og administrerer NameNode-statusen. Hver av NameNode kjører også en ZKFC. ZKFC er ansvarlig for å overvåke helsen til NameNodes med jevne mellomrom.

Nå som du har forstått hva som er høy tilgjengelighet i en Hadoop-klynge, er det på tide å sette den opp. For å sette opp høy tilgjengelighet i Hadoop-klyngen må du bruke Zookeeper i alle nodene.

Demonene i Active NameNode er:

• Dyrepasser
• Zookeeper Fail Over-kontrolleren
• JournalNode
• NameNode

Demonene i Standby NameNode er:

• Dyrepasser
• Zookeeper Fail Over-kontrolleren
• JournalNode
• NameNode

Demonene i DataNode er:

• Dyrepasser
• JournalNode
• DataNode

Hvis du ønsker å mestre HDFS og Hadoop, kan du ta en titt på det spesiallagde Big Data- og Hadoop-kurset av Edureka. Klikk på knappen nedenfor for å komme i gang.

Konfigurere og konfigurere klyngen for høy tilgjengelighet i Hadoop:

Du må først sette opp Java og vertsnavn for hver node.

Last ned den binære tarfilen Hadoop og Zookeeper, pakk ut filene for å redigere konfigurasjonsfiler.

Kommando: wget https://archive.apache.org/dist/zookeeper/zookeeper-3.4.6/zookeeper-3.4.6.tar.gz

Spre dyrehage-3.4.6.tar.gz

Kommando : tar –xvf zookeeper-3.4.6.tar.gz

Last ned den stabile Hadoop binære tjære til fra Apache Hadoop-nettstedet.

Kommando : wget https://archive.apache.org/dist/hadoop/core/hadoop-2.6.0/hadoop-2.6.0.tar.gz

Trekk ut Hadoop-tjærekulen.

Kommando : tar –xvf hadoop-2.6.0.tar.gz

Spread hadoop binært.

Legg til Hadoop, Zookeeper og stier til .bashrc-filen.

hva er bønne i java

Åpne .bashrc-filen.

Kommando : sudo gedit ~ / .bashrc

Legg til stiene nedenfor:

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 / Hadoop eksport JAVA_HOME = eksport ZOOKEEPER_HOME = export PATH = $ PATH: $ JAVA_HOME / bin: $ HADOOP_HOME / bin: $ HADOOP_HOME / sbin: $ ZOOKEEPER_HOME / bin

Rediger .bashrc-filen.

Aktiver SSH i hele noden.

Generer SSH-nøkkelen i alle nodene.

Kommando : ssh-keygen –t rsa (Dette trinnet i alle nodene)

Sett opp SSH-nøkkel i alle nodene.

Ikke gi noen sti til Enter-filen for å lagre nøkkelen, og ikke gi noen passordfrase. Trykk på enter-knappen.

Generer ssh-nøkkelprosessen i alle nodene.

Når ssh-nøkkel er generert, får du den offentlige nøkkelen og den private nøkkelen.

.Ssh-nøkkelkatalogen skal inneholde Tillatelse 700, og alle nøklene i .ssh-katalogen skal inneholde tillatelsene 600.

Endre SSH-katalogtillatelsen.

Endre katalogen til .ssh og endre tillatelsen til filer til 600

Endre tillatelse for offentlig og privat nøkkel.

Du må kopiere Navn noder ssh offentlig nøkkel til alle noder.

I Active Namenode kopierer du id_rsa.pub ved hjelp av cat-kommandoen.

Kommando : katt ~ / .ssh / id_rsa.pub >> ~ / .ssh / autoriserte_taster

Kopier Namenode ssh-nøkkel til de autoriserte nøklene.

Kopier den offentlige nøkkelen til NameNode til alle nodene ved hjelp av ssh-copy-id kommando.

Kommando : ssh-copy-id –i .ssh / id_rsa.pub edureka@nn2.cluster.com

Kopier formålstasten til Standby NameNode.

Kopier den offentlige nøkkelen til NameNode til datanoden.

Kommando : ssh-copy-id –i .ssh / id_rsa.pub edureka@dn1.cluster.com

Kopier Namenode offentlig nøkkel til datanode.

Start sshd-tjenesten på nytt i alle nodene.

Kommando : sudo service sshd restart (Gjør i alle noder)

Start SSH-tjenesten på nytt.

Nå kan du logge på hvilken som helst node fra Namenode uten godkjenning.

Åpne core-site.xml-filen fra Active Name-noden og legg til egenskapene nedenfor.

Rediger core-site.xml fra Active namenode

Åpne hdfs-site.xml-filen i Active Namenode. Legg til egenskapene nedenfor.

dfs.namenode.name.dir / home / edureka / HA / data / namenode dfs.replication 1 dfs.permissies falske dfs.nameservices ha-klynge dfs.ha.namenodes.ha-cluster nn1, nn2 dfs.namenode.rpc-adresse .ha-cluster.nn1 nn1.cluster.com:9000 dfs.namenode.rpc-adresse.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

Endre katalogen til zookeepers conf-katalog.

Kommando : cd zookeeper-3.4.6 / conf

Zookeeper Conf-katalog.

I en conf-katalog har du zoo_sample.cfg-fil, opprett zoo.cfg ved hjelp av zoo_sample.cfg-fil.

Kommando : cp zoo_sample.cfg zoo.cfg

Opprett zoo.cfg-fil.

Opprett katalogen hvor som helst og bruk denne katalogen til å lagre dyrehageinformasjonen.

Kommando : mkdir

Lag en katalog for å lagre dyrehageinformasjonen.

Åpne zoo.cfg-filen.

Kommando : gedit zoo.cfg

Legg til katalogstien som er opprettet i trinn ovenfor, til dataDir-egenskapen, og legg til detaljene nedenfor angående gjenværende node, i zoo.cfg-filen.

finn største antall i array java

Server.1 = nn1.cluster.com: 2888: 3888

Server.2 = nn2.cluster.com: 2888: 3888

Server.3 = dn1.cluster.com: 2888: 3888

Rediger zoo.cfg-filen.

Kopier nå Java- og Hadoop-2.6.0-, zookeeper-3.4.6-katalogene og .bashrc-filen til alle nodene (Standby name node, Data node) ved hjelp av scp-kommandoen.

Kommando : scp –r edureka @:

Kopier Hadoop, Zookeeper og .bashrc-filen til alle noder.

På samme måte kopierer du .bashrc-filen og dyrehage-katalogen til alle nodene og endrer miljøvariablene i hver i henhold til den respektive noden.

I en datanode oppretter du hvilken som helst katalog der du trenger å lagre HDFS-blokkene.

I en datanode må du legge til egenskapene dfs.datanode.data.dir.

I mitt tilfelle skapte jeg datanode katalog for å lagre blokkene.

Opprett Datanode-katalogen.

Endre tillatelsen til datanodekatalogen.

Endre tillatelsen til Datanode-katalogen.

Åpne HDFS-site.xml-filen, legg til denne Datanode-katalogbanen i dfs.datanode.data.dir-egenskapen.

Merk: Behold alle egenskapene som er kopiert fra Active namenode, legg til dfs.datanode.data.dir en ekstraktegenskap i namenode.

dfs.datanode.data.dir / home / edureka / HA / data / datanode

I Active namenode endrer du katalogen der du vil lagre zookeeper-konfigurasjonsfilen (dataDir-egenskapssti).

Opprett myid-filen i katalogen og legg til numerisk 1 i filen og lagre filen.

Kommando : vi myid

Opprett myid-fil.

I en standby-navnekode endrer du katalogen der du vil lagre zookeeper-konfigurasjonsfilen (dataDir-eiendomssti).

Opprett myid-filen i katalogen og legg til numerisk 2 i filen og lagre filen.

I en datanode endrer du katalogen der du vil lagre zookeeper-konfigurasjonsfilen (dataDir-egenskapssti).

Opprett myid-filen i katalogen og legg til numerisk 3 i filen og lagre filen.

Start Journalnode i alle de tre nodene.

Kommando : hadoop-daemon.sh start journalnode

Start Journalnode.

Når du skriver inn jps-kommando, vil du se JournalNode-demonen i alle nodene.

FormatereAktivt formål.

Kommando : HDFS ment -format

Aktivt NameNode-format.

Start Namenode-demonen og Active Namedode.

Kommando : hadoop-daemon.sh startformål

Start Namenode.

Kopier HDFS Meta-data fra aktiv navnekode til standby-navnekode.

Kommando : HDFS ment -bootstrapStandby

Kopier HDFS Meta-data fra Active name node til Standby Namenode.

Når du har kjørt denne kommandoen, får du informasjonen fra hvilken node og sted metadataene kopieres, og om den kopieres vellykket eller ikke.

Informasjon om detaljer om aktivt formål.

Når metadata er kopiert fra aktiv navnenode til standby-namenode, får du meldingen vist nedenfor på skjermbildet.

Informasjon om HDFS i standby Namenode.

Start namenode-demonen i standby-namenode-maskinen.

Kommando : hadoop-daemon.sh startformål

Start nå Zookeeper-tjenesten i alle de tre nodene.

Kommando : zkServer.sh start (Kjør denne kommandoen i alle nodene)

I aktivt formål:

Start dyrehage i Active NameNode.

I standby Namenode:

Start dyrehage i standby NameNode.

I datanode:

Start dyrehage i DataNode.

Etter å ha kjørt Zookeeper-serveren, skriv inn JPS-kommandoen. I alle nodene vil du se QuorumPeerMain-tjenesten.

Start Data node daemon i Data node machine.

Kommando : hadoop-daemon.sh start datanode

Start Zookeeper fail over controller i Active name node og standby name node.

Formater zookeeper fail over controller i Active namenode.

Kommando: HDFS zkfc –formatZK

Formater ZKFC.

Start ZKFC i Active namenode.

Kommando : hadoop-daemon.sh start zkfc

Skriv inn jps-kommandoen for å sjekke DFSZkFailoverController-demoner.

Start ZKFC.

Formater zookeeper fail over kontrolleren i standby-navnekoden.

Kommando : hdfs zkfc –formatZK

Start ZKFC i standby-navnekode.

Kommando : hadoop-daemon.sh start zkfc

Skriv inn jps-kommandoen for å sjekke DFSZkFailoverController-demoner.

Sjekk nå statusen til hver Namenode, hvilken node som er aktiv eller hvilken node som er i beredskap ved å bruke kommandoen nedenfor.

Kommando : hdfs haadmin –getServiceState nn1

Sjekk status for hver NameNode.

Sjekk nå statusen til hver Namenode ved hjelp av nettleseren.

Åpne nettleseren og skriv inn URL-en nedenfor.

: 50070

Den viser om navnetoden er Aktiv eller i beredskap.

Aktivt navnNode.

Åpne en annen navneknutedetaljer ved hjelp av nettleseren.

Standby NameNode.

I Aktiv namenode, drep namenode-demonen for å endre standby-navnekoden til aktiv namenode.

Skriv inn jps i Active namenode og drep demonen.

Kommando: sudo kill -9

Daemons prosess-ID.

Namenode-prosess-ID er 7606, drep namenoden.

dataabstrahering i c ++

Kommando : Sudo kill -9 7606

Drep Name Node-prosessen

Åpne de to nodene gjennom nettleseren og sjekk statusen.

Namenode detaljer.

NameNode status.

Gratulerer, du har klart å konfigurere en HDFS High Availability Cluster i Hadoop.

Nå som du har forstått Hadoop High Availability Cluster Architecture, sjekk ut av Edureka, et pålitelig online læringsfirma med et nettverk med mer enn 250 000 fornøyde elever spredt over hele verden. Edureka Big Data Hadoop-sertifiseringstreningskurs hjelper lærere å bli eksperter på HDFS, Garn, MapReduce, Pig, Hive, HBase, Oozie, Flume og Sqoop ved å bruke sanntidsbruk på Retail, Social Media, Aviation, Tourism, Finance.

Har du spørsmål til oss? Vennligst nevn det i kommentarfeltet, så kommer vi tilbake til deg.

window._LQ_ = window._LQ_ || {}

lqQuizModal (vindu, dokument, {quizId: ’XAIVp8 ′, baseUrl:’ https: //quiz.leadquizzes.com/’,trigger: ’exit’}, _LQ_)