Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Funktionen, die Hochverfügbarkeit in einem Amazon EMR-Cluster unterstützen, und deren Funktionsweise mit Open-Source-Anwendungen
Dieses Thema enthält Informationen zu den Hadoop-Hochverfügbarkeitsfunktionen von HDFS NameNode und YARN ResourceManager in einem Amazon EMR-Cluster und zur Funktionsweise der Hochverfügbarkeitsfunktionen mit Open-Source-Anwendungen und anderen Amazon EMR-Funktionen.
High-availability HDFS
Ein Amazon-EMR-Cluster mit mehreren Primärknoten aktiviert das Hochverfügbarkeitsfeature HDFS NameNode in Hadoop. Weitere Informationen finden Sie unter HDFS – hohe Verfügbarkeit
In einem Amazon EMR-Cluster sind zwei oder mehr separate Knoten als konfiguriert. NameNodes Einer NameNode befindet sich in einem active Zustand und die anderen befinden sich in einem standby Zustand. Wenn der Knoten 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 5.36.2 wird HDFS nur auf zwei der drei primären Knoten ausgeführt. NameNode
In den Amazon EMR-Versionen 6.x und höher wird HDFS auf allen drei primären Knoten ausgeführt. NameNode
Wenn Sie herausfinden möchten, welcher der beiden 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
Die Ausgabe listet die Knoten auf, auf denen installiert NameNode ist, und deren Status. Zum Beispiel
ip-##-#-#-##1.ec2.internal:8020 active ip-##-#-#-##2.ec2.internal:8020 standby ip-##-#-#-##3.ec2.internal:8020 standby
High-availability YARN 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ären Knoten ResourceManager wird YARN auf allen drei primären Knoten ausgeführt. Einer ResourceManager befindet sich im active Zustand, und die anderen beiden sind im standby Zustand. Wenn der primäre Knoten active ResourceManager ausfällt, startet Amazon EMR einen automatischen Failover-Prozess. Ein primärer Knoten mit einem standby ResourceManager übernimmt alle Operationen. Amazon EMR ersetzt den ausgefallenen Primärknoten durch einen neuen, der dann als wieder dem ResourceManager Quorum beitritt. standby
Sie können für jeden primären Knoten eine Verbindung zu „httpmaster-public-dns-name://:8088/cluster“ 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. Flinks JobManagers laufen wie YARNS ApplicationMasters auf den Kernknoten. Der JobManager ist vom Failover-Prozess für den primären Knoten nicht betroffen. Wenn Sie Amazon EMR Version 5.27.0 oder früher verwenden, JobManager handelt es sich um eine einzige Fehlerquelle. Wenn das JobManager fehlschlägt, verliert es alle Job-Status und die laufenden Jobs werden nicht wieder aufgenommen. Sie können JobManager Hochverfügbarkeit aktivieren, indem Sie die Anzahl der Anwendungsversuche, Checkpoints 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 führen ResourceManager automatisch ein Failover auf den Standby-Knoten durch, wenn der aktive primäre Knoten ausfällt. |
| HBase |
Hohe Verfügbarkeit |
HBase führt bei einem Ausfall des Primärknotens automatisch einen Failover zum Standby-Knoten aus. Wenn Sie eine Verbindung zu HBase über einen REST- oder Thrift-Server hergestellt haben, müssen Sie bei einem Ausfall des Primärknotens zu einem anderen Primärknoten wechseln. |
| HCatalog |
Verfügbarkeit nicht durch Failover für den Primärknoten betroffen |
HCatalog basiert auf einem Hive-Metastore. Dieser befindet sich außerhalb des Clusters. HCatalog bleibt während des Failover-Prozesses für den Primärknoten 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 keinen Daemon besitzt, hat der Failover-Prozess für den Primärknoten keine Auswirkungen. |
| Phoenix |
Hochverfügbarkeit |
Phoenix QueryServer läuft nur auf einem der drei Primärknoten. Phoenix auf allen drei Mastern ist so konfiguriert, dass der Phoenix angeschlossen wird. QueryServer Sie können die private IP des Phoenix QueryServer anhand der |
| 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 es keinen Daemon TensorFlow hat, ist es 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-Failoverfunktion. ZooKeeper bietet einen Dienst mit hoher Verfügbarkeit zur Verwaltung von Koordinationsdaten, zur Benachrichtigung von Kunden über Änderungen an diesen Daten und zur Überwachung von Clients 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ären Knoten 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-Datenkatalog verwenden 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- |
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 oder drei der Primärknoten. 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. Beispielsweise verwenden MapReduce Jobs eine
_SUCCESSDatei, 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 Terminierungsschutz, um Ihre Amazon EMR-Cluster vor versehentlichem 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
-
One-click Zugriff auf den persistenten Spark-Verlaufsserver
-
Persistente Anwendungsbenutzeroberflächen
-
One-click Der Zugriff auf persistente Anwendungsbenutzeroberflächen ist derzeit für Amazon EMR-Cluster mit mehreren primären Knoten oder für Amazon EMR-Cluster, die in AWS Lake Formation integriert sind, nicht verfügbar.
-
Rollenbasierte Runtime-Zugriffskontrolle. Weitere Informationen finden Sie unter Weitere Überlegungen in Schritte für Laufzeit-Rollen für Amazon EMR.
-
Amazon EMR-Integration mit AWS IAM Identity Center (vertrauenswürdige Identitätsverbreitung). Weitere Informationen finden Sie unter Integrieren Sie Amazon EMR mit AWS IAM Identity Center.
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.
