Služby s vysokou dostupností podporované službou Azure HDInsight

Článek
10/18/2023

Aby bylo možné zajistit optimální úroveň dostupnosti analytických komponent, služba HDInsight byla vyvinuta s jedinečnou architekturou pro zajištění vysoké dostupnosti důležitých služeb. Společnost Microsoft vyvinula některé komponenty této architektury, aby poskytovala automatické převzetí služeb při selhání. Další komponenty jsou standardní komponenty Apache nasazené pro podporu konkrétních služeb. Tento článek vysvětluje architekturu modelu služby HA v HDInsight, jak HDInsight podporuje převzetí služeb při selhání pro služby vysoké dostupnosti, a osvědčené postupy pro zotavení z jiných přerušení služeb.

Poznámka:

Tento článek obsahuje odkazy na termín slave (podřízený) , což je termín, který už Microsoft nepoužívá. Když se termín odebere ze softwaru, odebereme ho z tohoto článku.

Infrastruktura s vysokou dostupností

HDInsight poskytuje přizpůsobenou infrastrukturu, která zajišťuje vysokou dostupnost čtyř primárních služeb s funkcemi automatického převzetí služeb při selhání:

Server Apache Ambari
Server časové osy aplikací pro Apache YARN
Server historie úloh pro Hadoop MapReduce
Apache Livy

Tato infrastruktura se skládá z mnoha služeb a softwarových komponent, z nichž některé jsou navrženy Společností Microsoft. Následující komponenty jsou jedinečné pro platformu HDInsight:

Kontroler převzetí služeb při selhání otroků
Hlavní kontroler převzetí služeb při selhání
Služba s vysokou dostupností otroků
Hlavní služba s vysokou dostupností

high availability infrastructure.

Existují také další služby s vysokou dostupností, které jsou podporovány opensourcovými komponentami pro spolehlivost Apache. Tyto komponenty se nacházejí také v clusterech HDInsight:

Uzel NameNode systému souborů Hadoop (HDFS)
Správce prostředků YARN
Hlavní server HBase

Následující části obsahují podrobnější informace o tom, jak tyto služby spolupracují.

Služby hdInsight s vysokou dostupností

Microsoft poskytuje podporu pro čtyři služby Apache v následující tabulce v clusterech HDInsight. Abychom je odlišili od služeb s vysokou dostupností, které jsou podporovány komponentami Apache, označují se jako služby HDInsight HA.

Služba	Uzly clusteru	Typy clusterů	Účel
Server Apache Ambari	Aktivní hlavní uzel	Vše	Monitoruje a spravuje cluster.
Server časové osy aplikací pro Apache YARN	Aktivní hlavní uzel	Vše kromě Kafka	Udržuje informace o ladění úloh YARN spuštěných v clusteru.
Server historie úloh pro Hadoop MapReduce	Aktivní hlavní uzel	Vše kromě Kafka	Udržuje ladicí data pro úlohy MapReduce.
Apache Livy	Aktivní hlavní uzel	Spark	Umožňuje snadnou interakci s clusterem Spark přes rozhraní REST.

Poznámka:

Clustery HDInsight Enterprise Security Package (ESP) v současné době poskytují pouze vysokou dostupnost serveru Ambari. Server časové osy aplikací, server historie úloh a Livy jsou spuštěné jenom na hlavním uzlu0 a při selhání Ambari nepřejdou do hlavního uzlu 1. Databáze časové osy aplikace je také na hlavním uzlu0, nikoli na sql serveru Ambari.

Architektura

Každý cluster HDInsight má dva hlavní uzly v aktivním a pohotovostním režimu. Služby HDInsight HA běží jenom na hlavních uzlích. Tyto služby by měly být vždy spuštěné na aktivním hlavním uzlu a zastaveny a v režimu údržby na pohotovostním hlavním uzlu.

Aby bylo možné udržovat správné stavy služeb vysoké dostupnosti a poskytovat rychlé převzetí služeb při selhání, hdInsight využívá Apache ZooKeeper, což je koordinační služba pro distribuované aplikace, k provádění aktivních voleb hlavního uzlu. HDInsight také zřídí několik procesů Javy na pozadí, které koordinuje postup převzetí služeb při selhání pro služby HDInsight HA. Mezi tyto služby patří: hlavní kontroler převzetí služeb při selhání, kontroler převzetí služeb při selhání otroků, hlavní služba ha-service a slave-ha-service.

Apache ZooKeeper

Apache ZooKeeper je vysoce výkonná koordinační služba pro distribuované aplikace. V produkčním prostředí se ZooKeeper obvykle spouští v replikovaném režimu, kde replikovaná skupina serveru ZooKeeper tvoří kvorum. Každý cluster HDInsight má tři uzly ZooKeeper, které umožňují třem serverům ZooKeeper vytvořit kvorum. HDInsight má dvě kvora ZooKeeper spuštěná paralelně. Jedno kvorum rozhoduje o aktivním hlavním uzlu v clusteru, na kterém by se měly spouštět služby HDInsight HA. Další kvorum se používá ke koordinaci služeb ha poskytovaných Apacheem, jak je popsáno v dalších částech.

Kontroler převzetí služeb při selhání otroků

Kontroler převzetí služeb při selhání otroků běží na každém uzlu v clusteru HDInsight. Tento kontroler zodpovídá za spuštění agenta Ambari a služby slave-ha-service na každém uzlu. Pravidelně dotazuje první kvorum ZooKeeper o aktivním hlavním uzlu. Když se změní aktivní a pohotovostní hlavní uzly, kontroler převzetí služeb při selhání otroků provede následující kroky:

Aktualizace konfigurační soubor hostitele.
Restartuje agenta Ambari.

Služba slave-ha-service zodpovídá za zastavení služeb HDInsight HA (s výjimkou serveru Ambari) na pohotovostním hlavním uzlu.

Hlavní kontroler převzetí služeb při selhání

Hlavní kontroler převzetí služeb při selhání běží na obou hlavních uzly. Oba hlavní kontrolery převzetí služeb při selhání komunikují s prvním kvorem ZooKeeper a nominují hlavní uzel, na kterém běží jako aktivní hlavní uzel.

Pokud například hlavní kontroler převzetí služeb při selhání na hlavním uzlu 0 vyhraje volby, proběhnou následující změny:

Hlavní uzel 0 se aktivuje.
Hlavní kontroler převzetí služeb při selhání spustí server Ambari a hlavní službu na hlavním uzlu 0.
Druhý hlavní kontroler převzetí služeb při selhání zastaví server Ambari a hlavní službu na hlavním uzlu 1.

Hlavní služba běží pouze na aktivním hlavním uzlu, zastaví služby HDInsight HA (s výjimkou serveru Ambari) na pohotovostním hlavním uzlu a spustí je na aktivním hlavním uzlu.

Proces převzetí služeb při selhání

failover process.

Monitorování stavu běží na každém hlavním uzlu spolu s hlavním kontrolerem převzetí služeb při selhání a odesílá oznámení prezenčních signálů do kvora Zookeeper. Hlavní uzel se v tomto scénáři považuje za službu vysoké dostupnosti. Monitorování stavu kontroluje, jestli je každá služba s vysokou dostupností v pořádku a jestli je připravená se připojit ke zvolení vedení. Pokud ano, tento hlavní uzel soutěžil ve volbách. Pokud ne, ukončí volby, dokud se znovu nepřihodí.

Pokud hlavní uzel pohotovostního režimu někdy dosáhne vedení a stane se aktivní (například v případě selhání s předchozím aktivním uzlem), spustí hlavní kontroler převzetí služeb při selhání všechny služby HDInsight HA. Hlavní kontroler převzetí služeb při selhání zastaví tyto služby na druhém hlavním uzlu.

V případě selhání služby HDInsight HA, jako je například služba, která není v pořádku, by se hlavní kontroler převzetí služeb při selhání měl automaticky restartovat nebo zastavit služby podle stavu hlavního uzlu. Uživatelé by neměli ručně spouštět služby HDInsight HA na obou hlavních uzlech. Místo toho povolte automatické nebo ruční převzetí služeb při selhání, které pomáhá službě obnovit.

Neúmyslný ruční zásah

Služby HDInsight HA by se měly spouštět jenom na aktivním hlavním uzlu a v případě potřeby se automaticky restartují. Vzhledem k tomu, že jednotlivé služby vysoké dostupnosti nemají vlastní monitorování stavu, nejde převzetí služeb při selhání aktivovat na úrovni jednotlivých služeb. Převzetí služeb při selhání je zajištěno na úrovni uzlu, nikoli na úrovni služby.

Některé známé problémy

Když ručně spustíte službu ha v pohotovostním hlavním uzlu, nezastaví se, dokud nedojde k dalšímu převzetí služeb při selhání. Když jsou na obou hlavních uzlech spuštěné služby vysoké dostupnosti, mezi potenciální problémy patří: Uživatelské rozhraní Ambari je nepřístupné, Ambari vyvolá chyby, YARN, Spark a úlohy Oozie se můžou zaseknout.
Když se služba vysoké dostupnosti na aktivním hlavním uzlu zastaví, nerestartuje se, dokud nedojde k dalšímu převzetí služeb při selhání, nebo se restartuje hlavní kontroler převzetí služeb při selhání / master-ha-service. Pokud se jedna nebo více služeb vysoké dostupnosti zastaví na aktivním hlavním uzlu, zejména když se server Ambari zastaví, uživatelské rozhraní Ambari je nepřístupné, mezi další potenciální problémy patří selhání úloh YARN, Spark a Oozie.

Služby vysoké dostupnosti Apache

Apache poskytuje vysokou dostupnost pro hdFS NameNode, YARN ResourceManager a HBase Master, které jsou také k dispozici v clusterech HDInsight. Na rozdíl od služeb HDInsight HA se podporují v clusterech ESP. Služby Apache HA komunikují s druhým kvorem ZooKeeper (popsané v předchozí části), aby zvolily aktivní/pohotovostní stavy a prováděly automatické převzetí služeb při selhání. Následující části podrobně popisuje, jak tyto služby fungují.

Uzel NameNode systému souborů HDFS (Hadoop Distributed File System)

Clustery HDInsight založené na Apache Hadoopu 2.0 nebo vyšší poskytují vysokou dostupnost uzlu NameNode. Na hlavních uzly jsou spuštěné dva uzly NameNodes, které jsou nakonfigurované pro automatické převzetí služeb při selhání. Uzly NameNodes používají ZKFailoverController ke komunikaci se službou Zookeeper, aby zvolily aktivní/pohotovostní stav. ZKFailoverController běží na obou hlavních uzlech a funguje stejným způsobem jako hlavní kontroler převzetí služeb při selhání.

Druhé kvorum Zookeeper je nezávislé na prvním kvoru, takže aktivní uzel NameNode nemusí běžet na aktivním hlavním uzlu. Pokud je aktivní uzel NameNode mrtvý nebo není v pořádku, pohotovostní uzel NameNode vyhraje volby a stane se aktivní.

Správce prostředků YARN

Clustery HDInsight založené na Apache Hadoopu 2.4 nebo vyšší podporují vysokou dostupnost resourceManageru YARN. Existují dva resourcemanagery, rm1 a rm2, spuštěné na hlavním uzlu 0 a hlavním uzlu 1. Podobně jako NameNode se pro automatické převzetí služeb při selhání konfiguruje také resourceManager YARN. Jiný ResourceManager je automaticky zvolen, aby byl aktivní, když aktuální aktivní ResourceManager přestane reagovat nebo přestane reagovat.

YARN ResourceManager používá svůj vložený ActiveStandbyElector jako detektor selhání a vedoucí volič. Na rozdíl od uzlu NameNode SYSTÉMU HDFS správce prostředků YARN nepotřebuje samostatný démon ZKFC. Aktivní ResourceManager zapisuje své stavy do Apache Zookeeperu.

Vysoká dostupnost ResourceManageru YARN je nezávislá na uzlu NameNode a dalších službách HDInsight HA. Aktivní ResourceManager nemusí běžet na aktivním hlavním uzlu nebo hlavním uzlu, na kterém je spuštěn aktivní uzel NameNode. Další informace o vysoké dostupnosti YARN ResourceManager naleznete v části ResourceManager Vysoká dostupnost.

Hlavní server HBase

Clustery HDInsight HBase podporují vysokou dostupnost HBase Master. Na rozdíl od jiných služeb vysoké dostupnosti, které běží na hlavních uzlech, běží hlavní servery HBase na třech uzlech Zookeeper, kde jeden z nich je aktivní hlavní server a ostatní dva jsou pohotovostní. Podobně jako NameNode se hlavní server HBase koordinuje s Apache Zookeeperem pro volbu vedoucího serveru a provede automatické převzetí služeb při selhání, když má aktuální aktivní hlavní server problémy. Kdykoli je k dispozici pouze jeden aktivní hlavní server HBase.

Sdílet prostřednictvím