Tjänster med hög tillgänglighet som stöds av Azure HDInsight
För att ge dig optimal tillgänglighet för dina analyskomponenter utvecklades HDInsight med en unik arkitektur för att säkerställa hög tillgänglighet (HA) för kritiska tjänster. Microsoft utvecklade vissa komponenter i den här arkitekturen för att tillhandahålla automatisk redundans. Andra komponenter är Apache-standardkomponenter som distribueras för att stödja specifika tjänster. Den här artikeln beskriver arkitekturen för HA-tjänstmodellen i HDInsight, hur HDInsight stöder redundans för HA-tjänster och metodtips för att återställa från andra tjänstavbrott.
Kommentar
Den här artikeln innehåller referenser till termen slav, en term som Microsoft inte längre använder. När termen tas bort från programvaran tar vi bort den från den här artikeln.
Infrastruktur med hög tillgänglighet
HDInsight tillhandahåller anpassad infrastruktur för att säkerställa att fyra primära tjänster har hög tillgänglighet med funktioner för automatisk redundans:
- Apache Ambari-server
- Programtidslinjeserver för Apache YARN
- Jobbhistorikserver för Hadoop MapReduce
- Apache Livy
Den här infrastrukturen består av många tjänster och programvarukomponenter, varav vissa är utformade av Microsoft. Följande komponenter är unika för HDInsight-plattformen:
- Slave-redundansstyrenhet
- Master-redundansstyrenhet
- Tjänst med hög tillgänglighet för slave
- Master-tjänsten för hög tillgänglighet
Det finns också andra tjänster med hög tillgänglighet som stöds av Apache-tillförlitlighetskomponenter med öppen källkod. Dessa komponenter finns också i HDInsight-kluster:
- Namnnod för Hadoop-filsystem (HDFS)
- YARN ResourceManager
- HBase-huvud
Följande avsnitt innehåller mer information om hur dessa tjänster fungerar tillsammans.
HDInsight-tjänster med hög tillgänglighet
Microsoft tillhandahåller stöd för de fyra Apache-tjänsterna i följande tabell i HDInsight-kluster. För att skilja dem från tjänster med hög tillgänglighet som stöds av komponenter från Apache kallas de HDInsight HA-tjänster.
| Tjänst | Klusternoder | Klustertyper | Syfte |
|---|---|---|---|
| Apache Ambari-server | Aktiv huvudnod | Alla | Övervakar och hanterar klustret. |
| Programtidslinjeserver för Apache YARN | Aktiv huvudnod | Alla utom Kafka | Underhåller felsökningsinformation om YARN-jobb som körs i klustret. |
| Jobbhistorikserver för Hadoop MapReduce | Aktiv huvudnod | Alla utom Kafka | Underhåller felsökningsdata för MapReduce-jobb. |
| Apache Livy | Aktiv huvudnod | Spark | Möjliggör enkel interaktion med ett Spark-kluster via ett REST-gränssnitt |
Kommentar
HDInsight Enterprise Security Package-kluster (ESP) ger för närvarande endast Ambari-servern hög tillgänglighet. Application Timeline Server, Job History Server och Livy körs bara på headnode0 och de redundansväxlar inte till headnode1 när Ambari redundansväxlar. Programmets tidslinjedatabas finns också på headnode0 och inte på Ambari SQL-servern.
Arkitektur
Varje HDInsight-kluster har två huvudnoder i aktiva respektive väntelägen. HDInsight HA-tjänsterna körs endast på huvudnoder. Dessa tjänster bör alltid köras på den aktiva huvudnoden och stoppas och placeras i underhållsläge på väntelägeshuvudnoden.
För att upprätthålla rätt tillstånd för HA-tjänster och tillhandahålla en snabb redundansväxling använder HDInsight Apache ZooKeeper, som är en samordningstjänst för distribuerade program, för att genomföra aktiva headnode-val. HDInsight etablerar också några Java-bakgrundsprocesser som samordnar redundansproceduren för HDInsight HA-tjänster. Dessa tjänster är: den överordnade redundansstyrenheten, den slavbaserade redundansstyrenheten, master-ha-service och slave-ha-service.
Apache ZooKeeper
Apache ZooKeeper är en samordningstjänst med höga prestanda för distribuerade program. I produktion körs ZooKeeper vanligtvis i replikerat läge där en replikerad grupp ZooKeeper-server utgör ett kvorum. Varje HDInsight-kluster har tre ZooKeeper-noder som gör att tre ZooKeeper-servrar kan bilda ett kvorum. HDInsight har två ZooKeeper-kvorum som körs parallellt med varandra. Ett kvorum avgör den aktiva huvudnoden i ett kluster där HDInsight HA-tjänster ska köras. Ett annat kvorum används för att samordna HA-tjänster som tillhandahålls av Apache, enligt beskrivningen i senare avsnitt.
Slave-redundansstyrenhet
Den sekundära redundansstyrenheten körs på varje nod i ett HDInsight-kluster. Den här kontrollanten ansvarar för att starta Ambari-agenten och slave-ha-service på varje nod. Den frågar regelbundet det första ZooKeeper-kvorumet om den aktiva huvudnoden. När de aktiva och standby-huvudnoderna ändras utför den slav-redundansstyrenheten följande steg:
- Uppdateringar värdkonfigurationsfilen.
- Startar om Ambari-agenten.
Slave-ha-service ansvarar för att stoppa HDInsight HA-tjänsterna (utom Ambari-servern) på standby-huvudnoden.
Master-redundansstyrenhet
En master-redundansstyrenhet körs på båda huvudnoderna. Båda de överordnade redundansstyrenheterna kommunicerar med det första ZooKeeper-kvorumet för att nominera huvudnoden som de körs på som aktiv huvudnod.
Om till exempel den överordnade redundansstyrenheten på headnode 0 vinner valet sker följande ändringar:
- Headnode 0 blir aktiv.
- Master-redundansstyrenheten startar Ambari-servern och master-ha-service på headnode 0.
- Den andra master-redundansstyrenheten stoppar Ambari-servern och master-ha-service på headnode 1.
Master-ha-service körs endast på den aktiva huvudnoden, den stoppar HDInsight HA-tjänsterna (utom Ambari-servern) i väntelägeshuvudnoden och startar dem på aktiv huvudnod.
Redundansväxlingsprocessen
En hälsoövervakare körs på varje huvudnod tillsammans med den överordnade redundansstyrenheten för att skicka pulsslagsmeddelanden till Zookeeper-kvorumet. Huvudnoden betraktas som en HA-tjänst i det här scenariot. Hälsoövervakaren kontrollerar om varje tjänst med hög tillgänglighet är felfri och om den är redo att delta i ledarskapsvalet. Om ja, tävlar den här huvudnoden i valet. Om inte, slutar det valet tills det blir redo igen.
Om standby-huvudnoden någonsin uppnår ledarskap och blir aktiv (till exempel vid ett fel med den tidigare aktiva noden) startar dess huvudredundansstyrenhet alla HDInsight HA-tjänster på den. Den överordnade redundansstyrenheten stoppar dessa tjänster på den andra huvudnoden.
Vid fel i HDInsight HA-tjänsten, till exempel att en tjänst är avstängd eller inte fungerar, bör den överordnade redundansstyrenheten automatiskt starta om eller stoppa tjänsterna enligt headnode-statusen. Användare bör inte starta HDInsight HA-tjänster manuellt på båda huvudnoderna. Tillåt i stället automatisk eller manuell redundans för att hjälpa tjänsten att återställas.
Oavsiktlig manuell åtgärd
HDInsight HA-tjänster bör endast köras på den aktiva huvudnoden och startas om automatiskt vid behov. Eftersom enskilda HA-tjänster inte har en egen hälsoövervakare kan redundans inte utlösas på nivån för den enskilda tjänsten. Redundans säkerställs på nodnivå och inte på tjänstnivå.
Några kända problem
När du startar en HA-tjänst manuellt i väntelägeshuvudnoden stoppas den inte förrän nästa redundansväxling sker. När HA-tjänsterna körs på båda huvudnoderna kan några potentiella problem vara: Ambari-användargränssnittet är otillgängligt, Ambari genererar fel, YARN, Spark och Oozie-jobb kan fastna.
När en HA-tjänst på den aktiva huvudnoden stoppas startas den inte om förrän nästa redundansväxling sker eller om master-redundansstyrenheten/master-ha-service startas om. När en eller flera HA-tjänster stoppas på den aktiva huvudnoden, särskilt när Ambari-servern stoppas, är Ambari-användargränssnittet otillgängligt, andra potentiella problem är yarn-, Spark- och Oozie-jobbfel.
Apache-tjänster med hög tillgänglighet
Apache ger hög tillgänglighet för HDFS NameNode, YARN ResourceManager och HBase Master, som också är tillgängliga i HDInsight-kluster. Till skillnad från HDInsight HA-tjänster stöds de i ESP-kluster. Apache HA-tjänster kommunicerar med det andra ZooKeeper-kvorumet (beskrivs i ovanstående avsnitt) för att välja aktiva/väntelägestillstånd och utföra automatisk redundans. I följande avsnitt beskrivs hur dessa tjänster fungerar.
Hadoop Distributed File System (HDFS) NameNode
HDInsight-kluster baserade på Apache Hadoop 2.0 eller senare ger NameNode hög tillgänglighet. Det finns två NameNodes som körs på huvudnoderna, som är konfigurerade för automatisk redundans. NameNodes använder ZKFailoverController för att kommunicera med Zookeeper för att välja aktiv/väntelägesstatus. ZKFailoverController körs på båda huvudnoderna och fungerar på samma sätt som den överordnade redundansstyrenheten.
Det andra Zookeeper-kvorumet är oberoende av det första kvorumet, så den aktiva NameNode får inte köras på den aktiva huvudnoden. När den aktiva NameNode är död eller inte felfri vinner vänteläget NameNode valet och blir aktiv.
YARN ResourceManager
HDInsight-kluster baserade på Apache Hadoop 2.4 eller senare har stöd för YARN ResourceManager med hög tillgänglighet. Det finns två ResourceManagers, rm1 och rm2, som körs på headnode 0 respektive headnode 1. Precis som NameNode är YARN ResourceManager också konfigurerat för automatisk redundans. En annan ResourceManager väljs automatiskt att vara aktiv när den aktuella aktiva ResourceManager slutar svara.
YARN ResourceManager använder sin inbäddade ActiveStandbyElector som feldetektor och ledare. Till skillnad från HDFS NameNode behöver YARN ResourceManager inte någon separat ZKFC-daemon. Den aktiva ResourceManager skriver sina tillstånd till Apache Zookeeper.
Den höga tillgängligheten för YARN ResourceManager är oberoende av NameNode och andra HDInsight HA-tjänster. Den aktiva ResourceManager kanske inte körs på den aktiva huvudnoden eller huvudnoden där den aktiva NameNode körs. Mer information om YARN ResourceManager med hög tillgänglighet finns i ResourceManager High Availability( ResourceManager High Availability).
HBase-huvud
HDInsight HBase-kluster har stöd för hög tillgänglighet för HBase Master. Till skillnad från andra HA-tjänster, som körs på huvudnoder, körs HBase Masters på de tre Zookeeper-noderna, där en av dem är den aktiva huvudservern och de andra två är vänteläge. Precis som NameNode koordinerar HBase Master med Apache Zookeeper för val av ledare och utför automatisk redundans när den aktuella aktiva huvudservern har problem. Det finns bara en aktiv HBase Master när som helst.