Funktionen, die Hochverfügbarkeit in einem EMR Amazon-Cluster unterstützen, und wie sie mit Open-Source-Anwendungen funktionieren

Dieses Thema enthält Informationen zu den Hadoop-Hochverfügbarkeitsfunktionen von HDFS NameNode und YARN ResourceManager in einem EMR Amazon-Cluster und darüber, wie die Hochverfügbarkeitsfunktionen mit Open-Source-Anwendungen und anderen Amazon-Funktionen funktionieren. EMR

Hochverfügbarkeit HDFS

Ein EMR Amazon-Cluster mit mehreren Primärknoten ermöglicht HDFS NameNode Hochverfügbarkeitsfunktion in Hadoop. Weitere Informationen finden Sie unter HDFSHochverfügbarkeit.

In einem EMR Amazon-Cluster sind zwei oder mehr separate Knoten konfiguriert als NameNodes. Einer NameNode befindet sich in einem active Staat und die anderen befinden sich in einem standby Staat. Wenn der Knoten mit active NameNode ausfällt, EMR startet Amazon einen automatischen HDFS Failover-Prozess. Ein Knoten mit standby NameNode wird active und übernimmt alle Client-Operationen im Cluster. Amazon EMR ersetzt den ausgefallenen Knoten durch einen neuen, der sich dann wieder als standby Knoten verbindet.

Anmerkung

In den EMR Amazon-Versionen 5.23.0 bis einschließlich 5.30.1 laufen nur zwei der drei Primärknoten. HDFS NameNode

Wenn Sie herausfinden möchten, welcher NameNode istactive, können Sie damit eine Verbindung SSH zu einem beliebigen Primärknoten im Cluster herstellen und den folgenden Befehl ausführen:

hdfs haadmin -getAllServiceState

In der Ausgabe werden die Knoten, auf denen installiert NameNode ist, und ihr Status aufgeführt. Zum Beispiel

ip-##-#-#-##1.ec2.internal:8020 active
ip-##-#-#-##2.ec2.internal:8020 standby
ip-##-#-#-##3.ec2.internal:8020 standby

Hohe Verfügbarkeit YARN ResourceManager

Ein EMR Amazon-Cluster mit mehreren Primärknoten ermöglicht die YARN ResourceManager Hochverfügbarkeitsfunktion in Hadoop. Weitere Informationen finden Sie unter ResourceManager Hochverfügbarkeit.

YARN ResourceManager Läuft in einem EMR Amazon-Cluster mit mehreren Primärknoten auf allen drei Primärknoten. Einer ResourceManager befindet sich im active Bundesstaat, und die anderen beiden befinden sich im standby Bundesstaat. Wenn der primäre Knoten mit active ResourceManager ausfällt, EMR startet Amazon einen automatischen Failover-Prozess. Ein primärer Knoten mit a standby ResourceManager übernimmt alle Operationen. Amazon EMR ersetzt den ausgefallenen Primärknoten durch einen neuen, der dann wieder dem ResourceManager Quorum als beitritt. standby

Sie können eine Verbindung zu „http://“ herstellenmaster-public-dns-name:8088/cluster“ für jeden primären Knoten, wodurch Sie automatisch zum Ressourcenmanager weitergeleitet werden. active Um herauszufinden, welcher Ressourcenmanager das istactive, stellen Sie eine Verbindung SSH zu einem beliebigen primären Knoten im Cluster her. Führen Sie anschließend den folgenden Befehl aus, um die Liste der drei Primärknoten und deren Status abzurufen:

yarn rmadmin -getAllServiceState

Unterstützte Anwendungen in einem EMR Amazon-Cluster mit mehreren Primärknoten

Sie können die folgenden Anwendungen auf einem EMR Amazon-Cluster mit mehreren Primärknoten installieren und ausführen. Für jede Anwendung variiert der Failover-Prozess des Primärknotens.

Anwendung	Verfügbarkeit während Failover für den Primärknoten	Hinweise
Flink	Verfügbarkeit nicht durch Failover für den Primärknoten betroffen	Flink-Jobs bei Amazon EMR werden als YARN Anwendungen ausgeführt. Flink JobManagers läuft wie ApplicationMasters auf YARN den Kernknoten. Der JobManager wird durch den Failover-Prozess des Primärknotens nicht beeinflusst. Wenn Sie EMR Amazon-Version 5.27.0 oder früher verwenden, JobManager handelt es sich um einen einzigen Fehlerpunkt. Wenn der JobManager fehlschlägt, gehen alle Jobstatus verloren und die laufenden Jobs werden nicht wieder aufgenommen. Sie können JobManager Hochverfügbarkeit aktivieren, indem Sie die Anzahl der Anwendungsversuche, das Checkpointing und die Aktivierung ZooKeeper als Statusspeicher für Flink konfigurieren. Weitere Informationen finden Sie unter Konfiguration von Flink auf einem EMR Amazon-Cluster mit mehreren Primärknoten. Ab EMR Amazon-Version 5.28.0 ist keine manuelle Konfiguration erforderlich, um JobManager Hochverfügbarkeit zu aktivieren.
Ganglia	Verfügbarkeit nicht durch Failover für den Primärknoten betroffen	Ganglia ist auf allen Primärknoten verfügbar. Daher kann Ganglia während des Failover-Prozesses für den Primärknoten weiter ausgeführt werden.
Hadoop	Hohe Verfügbarkeit	HDFS NameNode und führt YARN ResourceManager automatisch ein Failover zum Standby-Knoten durch, wenn der aktive Primärknoten ausfällt.
HBase	Hohe Verfügbarkeit	HBaseführt automatisch ein Failover zum Standby-Knoten durch, wenn der aktive Primärknoten ausfällt. Wenn Sie die Verbindung HBase über einen REST oder Thrift-Server herstellen, müssen Sie zu einem anderen Primärknoten wechseln, wenn der aktive Primärknoten ausfällt.
HCatalog	Verfügbarkeit nicht durch Failover für den Primärknoten betroffen	HCatalogbasiert auf dem Hive-Metastore, der sich außerhalb des Clusters befindet. HCatalogbleibt während des Failover-Prozesses für den primären Knoten verfügbar.
JupyterHub	Hohe Verfügbarkeit	JupyterHub ist auf allen drei primären Instanzen installiert. Es wird dringend empfohlen, die Notebook-Persistenz zu konfigurieren, um Notebookverlust bei einem Ausfall des Primärknotens zu verhindern. Weitere Informationen finden Sie unter Konfigurieren von Persistenz für Notebooks in Amazon S3.
Livy	Hohe Verfügbarkeit	Livy wird auf allen drei Primärknoten installiert. Bei einem Ausfall des aktiven Primärknotens verlieren Sie den Zugriff auf die aktuelle Livy-Sitzung und müssen eine neue Livy-Sitzung auf einem anderen Primärknoten oder auf dem neuen Ersatzknoten erstellen.
Mahout	Verfügbarkeit nicht durch Failover für den Primärknoten betroffen	Da Mahout keinen Daemon besitzt, hat der Failover-Prozess für den Primärknoten keine Auswirkungen.
MXNet	Verfügbarkeit nicht durch Failover für den Primärknoten betroffen	Da MXNet es keinen Daemon gibt, ist er vom Failover-Prozess des Primärknotens nicht betroffen.
Phoenix	Hochverfügbarkeit	Phoenix QueryServer läuft nur auf einem der drei Primärknoten. Phoenix ist auf allen drei Mastern so konfiguriert, dass er den Phoenix verbindet. QueryServer Sie können die private IP des Phoenix QueryServer anhand der /etc/phoenix/conf/phoenix-env.sh-Datei finden
Pig	Verfügbarkeit nicht durch Failover für den Primärknoten betroffen	Da Pig keinen Daemon besitzt, hat der Failover-Prozess für den Primärknoten keine Auswirkungen.
Spark	Hohe Verfügbarkeit	Alle Spark-Anwendungen werden in YARN Containern ausgeführt und können auf Failover des Primärknotens genauso reagieren wie HochverfügbarkeitsfunktionenYARN.
Sqoop	Hohe Verfügbarkeit	Standardmäßig speichern sqoop-job und sqoop-metastore Daten (Auftragsbeschreibungen) auf der lokalen Festplatte des Masters, der den Befehl ausführt. Wenn Sie Metastore-Daten in einer externen Datenbank speichern möchten, schlagen Sie bitte in der Apache Sqoop-Dokumentation nach.
Tez	Hohe Verfügbarkeit	Da Tez-Container darauf laufenYARN, verhält sich Tez genauso wie YARN während des Failover-Prozesses für den primären Knoten.
TensorFlow	Verfügbarkeit nicht durch Failover für den Primärknoten betroffen	Da TensorFlow es keinen Daemon gibt, ist er vom Failover-Prozess des Primärknotens nicht betroffen.
Zeppelin	Hohe Verfügbarkeit	Zeppelin wird auf allen drei Primärknoten installiert. Zeppelin speichert standardmäßig Notizen und Interpreter-Konfigurationen, um Datenverlust zu HDFS verhindern. Interpretersitzungen sind über alle drei Primär-Instances vollständig isoliert. Sitzungsdaten gehen beim Master-Ausfall verloren. Es wird empfohlen, dieselbe Notiz nicht gleichzeitig auf verschiedenen Primär-Instances zu ändern.
ZooKeeper	Hohe Verfügbarkeit	ZooKeeper ist die Grundlage der HDFS automatischen Failover-Funktion. ZooKeeper bietet einen hochverfügbaren Dienst zur Verwaltung von Koordinationsdaten, zur Benachrichtigung von Clients über Änderungen an diesen Daten und zur Überwachung von Clients im Hinblick auf Ausfälle. Weitere Informationen finden Sie unter HDFSAutomatisches Failover.

Um die folgenden Anwendungen in einem EMR Amazon-Cluster mit mehreren Primärknoten auszuführen, müssen Sie eine externe Datenbank konfigurieren. Die externe Datenbank befindet sich außerhalb des Clusters. Daher sind Daten während des Failover-Prozesses für den Primärknoten persistent. Für die folgenden Anwendungen werden die Servicekomponenten während des Primärknoten-Failoverprozesses automatisch wiederhergestellt, aktive Aufträge können jedoch fehlschlagen und müssen erneut versucht werden.

Anwendung	Verfügbarkeit während Failover für den Primärknoten	Hinweise
Hive	Hohe Verfügbarkeit, jedoch ausschließlich für Service-Komponenten	Ein externer Metastore für Hive ist erforderlich. Dabei muss es sich um einen SQL externen Metastore von My external handeln, da Postgre SQL für Multi-Master-Cluster nicht unterstützt wird. Weiter Informationen finden Sie unter Konfigurieren eines externen Metastores für Hive.
Hue	Hohe Verfügbarkeit, jedoch ausschließlich für Service-Komponenten	Eine externe Datenbank für Hue ist erforderlich. Weitere Informationen finden Sie unter Verwenden von Hue mit einer Remote-Datenbank in Amazon RDS.
Oozie	Hohe Verfügbarkeit, jedoch ausschließlich für Service-Komponenten	Eine externe Datenbank für Oozie ist erforderlich. Weitere Informationen finden Sie unter Verwenden von Oozie mit einer Remote-Datenbank in Amazon RDS. Oozie-Server und Oozie-Client sind auf allen drei Primärknoten installiert. Die oozie-clients sind so konfiguriert, dass sie standardmäßig eine Verbindung mit dem richtigen oozie-server herstellen.
PrestoDB oder Presto /Trino SQL	Hohe Verfügbarkeit, jedoch ausschließlich für Service-Komponenten	Ein externer Hive-Metastore für PrestoDB (Presto SQL auf Amazon EMR 6.1.0-6.3.0 oder Trino auf Amazon 6.4.0 und höher) ist erforderlich. EMR Sie können Presto mit dem AWS Glue Data Catalog oder eine externe My SQL database for Hive verwenden. Presto CLI ist auf allen drei Primärknoten installiert, sodass Sie damit von jedem der Primärknoten aus auf den Presto Coordinator zugreifen können. Der Presto Coordinator ist nur auf einem Primärknoten installiert. Sie können den DNS Namen des primären Knotens ermitteln, auf dem der Presto Coordinator installiert ist, indem Sie Amazon anrufen EMR describe-cluster API und den zurückgegebenen Wert des MasterPublicDnsName Felds in der Antwort lesen.

Anmerkung

Wenn ein primärer Knoten ausfällt, beendet Ihre Java Database Connectivity (JDBC) oder Open Database Connectivity (ODBC) ihre Verbindung zum primären Knoten. Sie können eine Verbindung mit einem der verbleibenden Primärknoten herstellen und Ihre Arbeit fortsetzen, da der Hive-Metastore-Daemon auf allen Primärknoten ausgeführt wird. Sie können auch warten, bis der ausgefallene Primärknoten ersetzt wird.

So funktionieren EMR Amazon-Funktionen in einem Cluster mit mehreren Primärknoten

Verbindung zu Primärknoten herstellen mit SSH

Sie können sich mit jedem der drei Primärknoten in einem EMR Amazon-Cluster auf dieselbe Weise verbinden wie mit SSH einem einzelnen Primärknoten. Weitere Informationen finden Sie unter Connect dem Primärknoten herstellen mit SSH.

Wenn ein primärer Knoten ausfällt, wird Ihre SSH Verbindung zu diesem primären Knoten beendet. Um Ihre Arbeit fortzusetzen, können Sie eine Verbindung mit einem der beiden anderen Primärknoten herstellen. Alternativ können Sie auf den neuen Primärknoten zugreifen, nachdem Amazon den ausgefallenen Knoten durch einen neuen EMR ersetzt hat.

Anmerkung

Die private IP-Adresse des ersetzenden Primärknoten ist mit der privaten IP-Adresse des vorherigen Primärknotens identisch. Die öffentliche IP-Adresse des ersetzenden Primärknotens wird möglicherweise geändert. Sie können die neuen IP-Adressen in der Konsole oder mithilfe des describe-cluster Befehls in der abrufen AWS CLI.

NameNode läuft nur auf zwei der primären Knoten. Sie können jedoch hdfs CLI Befehle ausführen und Jobs ausführen, um HDFS auf alle drei primären Knoten zuzugreifen.

Arbeiten mit Schritten in einem EMR Amazon-Cluster mit mehreren Primärknoten

Sie können Schritte an einen EMR Amazon-Cluster mit mehreren Primärknoten genauso senden, wie Sie mit Schritten in einem Cluster mit einem einzigen primären Knoten arbeiten. Weitere Informationen finden Sie unter Übermitteln von Arbeit an einen Cluster.

Im Folgenden finden Sie Überlegungen zur Arbeit mit Schritten in einem EMR Amazon-Cluster mit mehreren Primärknoten:

• Wenn ein primärer Knoten ausfällt, werden die Schritte, die auf dem primären Knoten ausgeführt werden, als gekennzeichnetFAILED. Alle lokal geschriebenen Daten gehen verloren. Der Status spiegelt jedoch FAILED möglicherweise nicht den tatsächlichen Status der Schritte wider.

• Wenn ein laufender Schritt eine YARN Anwendung gestartet hat, obwohl der primäre Knoten ausfällt, kann der Schritt aufgrund des automatischen Failovers des primären Knotens fortgesetzt und erfolgreich ausgeführt werden.

• Sie sollten den Status von Schritten anhand der Ausgaben der Aufgaben überprüfen. MapReduce Jobs verwenden beispielsweise eine _SUCCESS Datei, um festzustellen, ob der Job erfolgreich abgeschlossen wurde.

• Es wird empfohlenCONTINUE, den ActionOnFailure Parameter auf oder CANCEL _ AND _ WAIT statt auf TERMINATE _ JOB _ FLOW oder TERMINATE _ festzulegenCLUSTER.

Automatischer Beendigungsschutz

Amazon aktiviert EMR automatisch den Kündigungsschutz für alle Cluster mit mehreren Primärknoten und überschreibt alle Einstellungen für die Schrittausführung, die Sie bei der Erstellung des Clusters angeben. Sie können den Kündigungsschutz deaktivieren, nachdem der Cluster gestartet wurde. Siehe Konfigurieren des Beendigungsschutzes für aktive Cluster. Um einen Cluster mit mehreren Primärknoten herunterzufahren, müssen Sie zunächst die Clusterattribute ändern, um den Kündigungsschutz zu deaktivieren. Detaillierte Anweisungen finden Sie unter Einen EMR Amazon-Cluster mit mehreren Primärknoten beenden.

Weitere Informationen zum Beendigungsschutz finden Sie unter Verwenden Sie den Kündigungsschutz, um Ihre EMR Amazon-Cluster vor einem versehentlichen Herunterfahren zu schützen.

Nicht unterstützte Funktionen in einem EMR Amazon-Cluster mit mehreren Primärknoten

Die folgenden EMR Amazon-Funktionen sind derzeit in einem EMR Amazon-Cluster mit mehreren Primärknoten nicht verfügbar:

• EMRNotizbücher

• Zugriff auf den permanenten Spark History Server mit nur einem Klick

• Persistente Anwendungsbenutzeroberflächen

• Der Ein-Klick-Zugriff auf persistente Anwendungsbenutzeroberflächen ist derzeit für EMR Amazon-Cluster mit mehreren Primärknoten oder für EMR Amazon-Cluster, die in AWS Lake Formation integriert sind, nicht verfügbar.

Anmerkung

Um die Kerberos-Authentifizierung in Ihrem Cluster zu verwenden, müssen Sie ein externes System konfigurieren. KDC

Ab EMR Amazon-Version 5.27.0 können Sie die HDFS transparente Verschlüsselung auf einem EMR Amazon-Cluster mit mehreren Primärknoten konfigurieren. Weitere Informationen finden Sie unter Transparente Verschlüsselung HDFS bei Amazon EMR.