Funktionen, die Hochverfügbarkeit in einem Amazon EMR-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 Amazon EMR-Cluster und darüber, wie die Hochverfügbarkeitsfunktionen mit Open-Source-Anwendungen und anderen Amazon EMR-Funktionen funktionieren.

Hohe Verfügbarkeit – HDFS

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

In einem Amazon EMR-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, startet Amazon EMR einen automatischen HDFS-Failover-Prozess. Ein Knoten mit standby NameNode wird active und übernimmt alle Client-Operationen im Cluster. Amazon EMR ersetzt den Knoten durch einen neuen, der dann als standby erneut beitritt.

Anmerkung

In den Amazon EMR-Versionen 5.23.0 bis einschließlich 5.30.1 wird HDFS nur auf zwei der drei Primärknoten ausgeführt. NameNode

Wenn Sie herausfinden möchten, welcher NameNode istactive, können Sie SSH verwenden, um eine Verbindung zu einem beliebigen primären Knoten im Cluster herzustellen 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

Garn mit hoher Verfügbarkeit ResourceManager

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

In einem Amazon EMR-Cluster mit mehreren Primärknoten ResourceManager wird YARN auf allen drei Primärknoten ausgeführt. 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, startet Amazon EMR 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 hinzugefügt wird. standby

Sie können für jeden primären Knoten eine Verbindung zu „http: //:8088/clustermaster-public-dns-name“ herstellen, wodurch Sie automatisch zum Ressourcenmanager weitergeleitet werden. active Um zu ermitteln, welcher ResourceManager den Zustand active hat, verwenden Sie SSH, um eine Verbindung mit einem Primärknoten im Cluster herzustellen. 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 Amazon-EMR-Cluster mit mehreren Primärknoten

Sie können die folgenden Anwendungen auf einem Amazon-EMR-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-Aufträge auf Amazon EMR werden als YARN-Anwendungen ausgeführt. Flink JobManagers läuft wie YARN auf den Kernknoten. ApplicationMasters Der JobManager wird vom Failover-Prozess des primären Knotens nicht beeinflusst. Wenn Sie Amazon EMR Version 5.27.0 oder früher verwenden, JobManager handelt es sich um einen einzigen Fehlerpunkt. Wenn der JobManager fehlschlägt, gehen alle Job-Status 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 Konfigurieren von Flink auf einem Amazon-EMR-Cluster mit mehreren Primärknoten. Ab Amazon EMR Version 5.28.0 ist keine manuelle Konfiguration erforderlich, um Hochverfügbarkeit zu ermöglichen JobManager .
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 YARN schalten ResourceManager automatisch auf den Standby-Knoten um, wenn der aktive Primärknoten ausfällt.
HBase	Hohe Verfügbarkeit	HBase führt automatisch ein Failover zum Standby-Knoten durch, wenn der aktive Primärknoten ausfällt. Wenn Sie HBase über einen REST- oder Thrift-Server eine Verbindung 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	HCatalog basiert auf dem Hive-Metastore, der außerhalb des Clusters existiert. HCatalog bleibt 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 reagieren auf den Failover-Prozess für einen Primärknoten auf die gleiche Weise wie YARN-Hochverfügbarkeitsfeatures.
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 auf YARN ausgeführt werden, verhält sich Tez während des Failover-Prozesses für den Primärknoten wie YARN.
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 Notizen und Interpreterkonfigurationen standardmäßig in HDFS, um Datenverlust zu 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 automatischen HDFS-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 Fehler. Weitere Informationen finden Sie unter HDFS-Funktion für automatische Failover.

Um die folgenden Anwendungen in einem Amazon-EMR-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. Dies muss ein externer MySQL-Metastore sein, da PostgreSQL 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 PrestoSQL/Trino	Hohe Verfügbarkeit, jedoch ausschließlich für Service-Komponenten	Ein externer Hive-Metastore für PrestoDB (PrestoSQL auf Amazon EMR 6.1.0-6.3.0 oder Trino auf Amazon EMR 6.4.0 und höher) ist erforderlich. Sie können Presto mit dem AWS Glue Data Catalog oder eine externe MySQL-Datenbank für Hive verwenden. Die 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ärknotens ermitteln, auf dem der Presto Coordinator installiert ist, indem Sie die Amazon-describe-cluster-EMR-API aufrufen und den zurückgegebenen Wert des MasterPublicDnsName-Felds in der Antwort lesen.

Anmerkung

Beim Ausfall eines Primärknoten wird die Verbindung Ihrer Java Database Connectivity (JDBC) oder Open Database Connectivity (ODBC) mit dem Primärknoten beendet. 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 Amazon-EMR-Feature in einem Cluster mit mehreren Primärknoten

Herstellen von Verbindungen mit Primärknoten über SSH

Sie können mit jedem der drei Primärknoten in einem Amazon-EMR-Cluster auf die gleiche Art Verbindungen über SSH herstellen, wie Sie Verbindungen mit einem einzelnen Primärknoten herstellen. Weitere Informationen finden Sie unter Mit dem Primärknoten über SSH verbinden.

Beim Ausfall eines Primärknotens wird Ihre Verbindung mit diesem Primärknoten 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 EMR den ausgefallenen Primärknoten durch einen neuen Primärknoten 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 neue IP-Adressen in der Konsole oder über den Befehl describe-cluster in der AWS -CLI abrufen.

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

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

Sie können Schritte an einen Amazon-EMR-Cluster mit mehreren Primärknoten auf die gleiche Weise übermitteln, wie Sie mit Schritten in einem Cluster mit einem einzelnen Primärknoten arbeiten. Weitere Informationen finden Sie unter Übermitteln von Arbeit an einen Cluster.

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

• Beim Ausfall eines Primärknotens werden die Schritte, die auf dem Primärknoten ausgeführt werden, als FAILED (fehlgeschlagen) markiert. Alle lokal geschriebenen Daten gehen verloren. Der Status FAILED gibt jedoch möglicherweise nicht den tatsächlichen Zustand der Schritte wider.

• Wenn ein Schritt, der ausgeführt wurde, als der Primärknoten ausfiel, eine YARN-Anwendung gestartet hatte, kann der Schritt aufgrund des automatischen Failover-Prozesses für den Primärknoten weiter ausgeführt und erfolgreich abgeschlossen 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 empfohlen, den ActionOnFailure Parameter auf CONTINUE oder CANCEL_AND_WAIT statt auf TERMINATE_JOB_FLOW oder TERMINATE_CLUSTER festzulegen.

Automatischer Beendigungsschutz

Amazon EMR aktiviert 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 Amazon-EMR-Clustern mit mehreren Primärknoten beenden.

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

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

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

• EMR Notebooks

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

• Persistente Anwendungsbenutzeroberflächen

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

Anmerkung

Um in Ihrem Cluster Kerberos-Authentifizierung zu verwenden, müssen Sie einen externen KDC konfigurieren.

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