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. # Anwendungen konfigurieren Um die Standardkonfigurationen für eine Anwendung zu überschreiben, können Sie ein Konfigurationsobjekt bereitstellen. Sie können entweder eine Syntax-Kurznotation verwenden, um die Konfiguration anzugeben oder Sie können auf die Konfiguration in einer JSON-Datei zu verweisen. Konfigurationsobjekte bestehen aus einer Klassifizierung, Eigenschaften und optionalen verschachtelten Konfigurationen. Die Eigenschaften entsprechen den Anwendungseinstellungen, die Sie ändern möchten. Sie können mehrere Klassifizierungen für mehrere Anwendungen in einem einzigen JSON-Objekt angeben. **Warnung** Die API-Operationen Describe und List von Amazon EMR geben benutzerdefinierte und konfigurierbare Einstellungen, die als Teil der Amazon-EMR-Auftragsabläufe verwendet werden, im Klartext aus. Informationen zur Angabe vertraulicher Informationen wie Kennwörter in diesen Einstellungen finden Sie unter [Vertrauliche Konfigurationsdaten in AWS Secrets Manager speichern](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/storing-sensitive-data.html). Die verfügbaren Konfigurationsklassifizierungen variieren je nach Amazon-EMR-Version. Eine Liste der Konfigurationsklassifizierungen, die in einer bestimmten Release-Version unterstützt werden, finden Sie auf der Seite für diese Release-Version unter [Informationen über Amazon-EMR-Versionen](emr-release-components.md). Das folgende JSON-Beispieldatei gilt für eine Liste von Konfigurationen. ``` [ { "Classification": "core-site", "Properties": { "hadoop.security.groups.cache.secs": "250" } }, { "Classification": "mapred-site", "Properties": { "mapred.tasktracker.map.tasks.maximum": "2", "mapreduce.map.sort.spill.percent": "0.90", "mapreduce.tasktracker.reduce.tasks.maximum": "5" } } ] ``` Eine Konfigurationsklassifizierung bezieht sich häufig auf eine anwendungsspezifische Konfigurationsdatei. Die `hive-site`-Klassifizierung ist Einstellungen in der `hive-site.xml`-Konfigurationsdatei für Hive zugeordnet. Eine Ausnahme bildet die veraltete Bootstrap-Aktion `configure-daemons`, mit der Umgebungsparameter wie z. B. `--namenode-heap-size` definiert werden. Optionen wie diese sind in den Klassifizierungen `hadoop-env` und `yarn-env` mit ihren eigenen verschachtelten Exportklassifizierungen zusammengefasst. Verwenden Sie die Export-Unterklassifizierung, wenn eine Klassifizierung auf `env` endet. Eine weitere Ausnahme ist `s3get`. Sie wurde verwendet, um ein `EncryptionMaterialsProvider`-Kundenobjekt auf jedem Knoten in einem Cluster für die Verwendung bei der clientseitigen Verschlüsselung zu platzieren. Der Klassifizierung `emrfs-site` wurde zu diesem Zweck eine Option hinzugefügt. Im Folgenden finden Sie ein Beispiel für die `hadoop-env`-Klassifizierung. ``` [ { "Classification": "hadoop-env", "Properties": { }, "Configurations": [ { "Classification": "export", "Properties": { "HADOOP_DATANODE_HEAPSIZE": "2048", "HADOOP_NAMENODE_OPTS": "-XX:GCTimeRatio=19" }, "Configurations": [ ] } ] } ] ``` Im Folgenden finden Sie ein Beispiel für die yarn-env-Klassifizierung. ``` [ { "Classification": "yarn-env", "Properties": { }, "Configurations": [ { "Classification": "export", "Properties": { "YARN_RESOURCEMANAGER_OPTS": "-Xdebug -Xrunjdwp:transport=dt_socket" }, "Configurations": [ ] } ] } ] ``` Die folgenden Einstellungen gehören nicht zu einer Konfigurationsdatei, werden aber von Amazon EMR verwendet, um ggf. mehrere Einstellungen in Ihrem Namen zu konfigurieren. **Von Amazon EMR zusammengestellte Einstellungen** | Anwendung | Klassifizierung der Versionsbezeichnung | Gültige Eigenschaften | Wann sollte dies verwendet werden? | | --- | --- | --- | --- | | Spark | spark | maximizeResourceAllocation | Konfigurieren von Executors zur Nutzung der maximalen Ressourcen eines jeden Knotens | **Topics** + [Anwendungen bei der Clustererstellung konfigurieren](emr-configure-apps-create-cluster.md) + [Eine Instance-Gruppe in einem laufenden Cluster neu konfigurieren](emr-configure-apps-running-cluster.md) + [Speichern Sie vertrauliche Konfigurationsdaten in AWS Secrets Manager](storing-sensitive-data.md) + [Anwendungen für die Verwendung einer bestimmten Java Virtual Machine konfigurieren](configuring-java8.md) # Anwendungen bei der Clustererstellung konfigurieren Wenn Sie einen Cluster erstellen, können Sie die Standardkonfigurationen für Anwendungen mithilfe der Amazon EMR-Konsole, der AWS Command Line Interface (AWS CLI) oder des AWS SDK überschreiben. Um die Standardkonfiguration für eine Anwendung zu überschreiben, geben Sie benutzerdefinierte Werte in einer Konfigurationsklassifizierung an. Eine Konfigurationsklassifizierung entspricht einer XML-Konfigurationsdatei für eine Anwendung, z. B. `hive-site.xml` Konfigurationsklassifizierungen variieren je nach Amazon-EMR-Version. Eine Liste der Konfigurationsklassifizierungen, die in einer bestimmten Release-Version verfügbar sind, finden Sie auf der Release-Detailseite. In diesem Beispiel wird [Amazon-EMR-Version 6.4.0](emr-640-release.md#emr-640-class) verwendet. ## Geben Sie beim Erstellen eines Clusters eine Konfiguration in der Konsole an Um eine Konfiguration bereitzustellen, navigieren Sie zur Seite **Cluster erstellen** und erweitern Sie **Softwareeinstellungen**. Sie können dann die Konfiguration direkt mittels JSON oder einer Syntax-Kurznotation angeben, dargestellt als abgedunkelter Text in der Konsole. Andernfalls können Sie eine Amazon-S3-URI für eine Datei mit einem `Configurations`-JSON-Objekt bereitstellen. Um eine Konfiguration für eine Instanzgruppe bereitzustellen, wählen Sie einen Cluster in Ihrer Clusterliste aus und wählen Sie dann die Registerkarte **Konfigurationen**. Wählen Sie in der Tabelle mit den **Instanzgruppenkonfigurationen** die zu bearbeitende Instanzgruppe aus und klicken Sie dann auf **Neu konfigurieren**. ## Geben Sie AWS CLI beim Erstellen eines Clusters eine Konfiguration an, indem Sie Sie können eine Konfiguration für **create-cluster** bereitstellen, indem Sie den Pfad zu einer JSON-Datei angeben, die lokal oder in Amazon S3 gespeichert ist. Im folgenden Beispiel wird davon ausgegangen, dass Sie bereits erstellte Standardrollen für Amazon EMR verwenden. Wenn Sie die Rollen erstellen müssen, führen Sie zuerst `aws emr create-default-roles` aus. Wenn sich die Konfiguration im lokalen Verzeichnis befindet, können Sie den folgenden Beispielbefehl verwenden. ``` aws emr create-cluster --use-default-roles --release-label emr-7.12.0 --applications Name=Hive \ --instance-type m5.xlarge --instance-count 3 --configurations file://./configurations.json ``` Wenn sich Ihre Konfiguration in einem Amazon-S3-Pfad befindet, müssen Sie die folgende Problemumgehung einrichten, bevor Sie den Amazon-S3-Pfad an den `create-cluster`-Befehl übergeben. ``` #!/bin/sh # Assume the ConfigurationS3Path is not public, and its present in the same AWS account as the EMR cluster ConfigurationS3Path="s3://amzn-s3-demo-bucket/config.json" # Get a presigned HTTP URL for the s3Path ConfigurationURL=`aws s3 presign $ConfigurationS3Path --expires-in 300` # Fetch the presigned URL, and minify the JSON so that it spans only a single line Configurations=`curl $ConfigurationURL | jq -c .` aws emr create-cluster --use-default-roles --release-label emr-5.34.0 --instance-type m5.xlarge --instance-count 2 --applications Name=Hadoop Name=Spark --configurations $Configurations ``` ## Beim Erstellen eines Clusters eine Konfiguration mit dem Java SDK angeben Der folgende Programmausschnitt zeigt, wie eine Konfiguration mit AWS SDK für Java bereitgestellt wird. ``` Application hive = new Application().withName("Hive"); Map hiveProperties = new HashMap(); hiveProperties.put("hive.join.emit.interval","1000"); hiveProperties.put("hive.merge.mapfiles","true"); Configuration myHiveConfig = new Configuration() .withClassification("hive-site") .withProperties(hiveProperties); RunJobFlowRequest request = new RunJobFlowRequest() .withName("Create cluster with ReleaseLabel") .withReleaseLabel("emr-5.20.0") .withApplications(hive) .withConfigurations(myHiveConfig) .withServiceRole("EMR_DefaultRole") .withJobFlowRole("EMR_EC2_DefaultRole") .withInstances(new JobFlowInstancesConfig() .withEc2KeyName("myEc2Key") .withInstanceCount(3) .withKeepJobFlowAliveWhenNoSteps(true) .withMasterInstanceType("m4.large") .withSlaveInstanceType("m4.large") ); ``` # Eine Instance-Gruppe in einem laufenden Cluster neu konfigurieren Ab Amazon-EMR-Version 5.21.0 können Sie Cluster-Konfigurationen neu konfigurieren und zusätzliche Konfigurationsklassifikationen für jede Instance-Gruppe in einem ausgeführten Cluster angeben. Dazu können Sie die Amazon EMR-Konsole, das AWS Command Line Interface (AWS CLI) oder das AWS SDK verwenden. Wenn Sie eine Anwendungskonfiguration für eine Instance-Gruppe in der neuen Amazon-EMR-Konsole aktualisieren, versucht die Konsole, die neue Konfiguration mit der vorhandenen Konfiguration zusammenzuführen, um eine neue, aktive Konfiguration zu erstellen. In dem ungewöhnlichen Fall, dass Amazon EMR die Konfiguration nicht zusammenführen kann, werden Sie von der Konsole benachrichtigt. Nachdem Sie eine Neukonfigurationsanforderung für eine Instance-Gruppe übermittelt haben, weist Amazon EMR der neuen Konfigurationsspezifikation eine Versionsnummer zu. Sie können die Versionsnummer einer Konfiguration oder den Status einer Instance-Gruppe verfolgen, indem Sie sich die CloudWatch Ereignisse ansehen. Weitere Informationen finden Sie unter [ CloudWatch Ereignisse überwachen](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-cloudwatch-events.html). **Anmerkung** Sie können Clusterkonfigurationen, die bei der Clustererstellung angegeben wurden, nur überschreiben und nicht löschen. Wenn es Unterschiede zwischen der vorhandenen Konfiguration und der von Ihnen bereitgestellten Datei gibt, setzt Amazon EMR manuell geänderte Konfigurationen, z. B. Konfigurationen, die Sie geändert haben, während Sie über SSH mit Ihrem Cluster verbunden waren, auf die Cluster-Standardeinstellungen für die angegebene Instance-Gruppe zurück. ## Überlegungen bei der Neukonfiguration einer Instance-Gruppe **Aktionen zur Neukonfiguration** Wenn Sie eine Rekonfigurationsanfrage über die Amazon EMR-Konsole, das AWS Command Line Interface (AWS CLI) oder das AWS SDK einreichen, überprüft Amazon EMR die vorhandene Cluster-Konfigurationsdatei. Wenn es Unterschiede zwischen der vorhandenen Konfiguration und der von Ihnen bereitgestellten Datei gibt, initiiert Amazon EMR Neukonfigurationsaktionen, startet einige Anwendungen neu und setzt alle manuell geänderten Konfigurationen, wie Konfigurationen, die Sie geändert haben, während Sie über SSH mit Ihrem Cluster verbunden waren, auf die Cluster-Standardeinstellungen für die angegebene Instance-Gruppe zurück. Amazon EMR führt bei jeder Neukonfiguration der Instance-Gruppe einige Standardaktionen durch. Diese Standardaktionen können zu Konflikten mit den von Ihnen vorgenommenen Cluster-Anpassungen führen und zu Fehlern bei der Neukonfiguration führen. Weitere Informationen, wie Sie bei fehlgeschlagener Neukonfiguration beheben können, finden Sie unter [Probleme bei der Neukonfiguration von Instance-Gruppen beheben](#emr-configure-apps-running-cluster-troubleshoot). Amazon EMR leitet auch Neukonfigurationsaktionen für die Konfigurationsklassifizierungen ein, die Sie in Ihrer Anfrage angeben. Eine vollständige Liste dieser Aktionen finden Sie im Abschnitt Konfigurationsklassifizierungen für die Version von Amazon EMR, die Sie verwenden. Zum Beispiel [6.2.0.-Konfigurationsklassifizierungen](emr-620-release.md#emr-620-class). Im Amazon-EMR-Versionshandbuch sind nur Neukonfigurationsaktionen aufgeführt, die mit den Amazon-EMR-Versionen 5.32.0 und 6.2.0 beginnen. **Betriebsunterbrechung** Amazon EMR führt die Rekonfiguration der Instances in den Instance-Gruppen Core und Task rollierend durch. Zu einem bestimmten Zeitpunkt werden nur 10 % der Instances in einer Instance-Gruppe geändert und neu gestartet. So benötigt der Prozess mehr Zeit, gleichzeitig ist aber die Wahrscheinlichkeit eines Anwendungsausfalls in einem aktiven Cluster geringer. Um YARN-Aufträge während eines YARN-Neustarts auszuführen, können Sie entweder einen Amazon-EMR-Cluster mit mehreren Hauptknoten erstellen oder `yarn.resourcemanager.recovery.enabled` in Ihrer `yarn-site`-Konfigurationsklassifizierung `true` auf einstellen. [Weitere Informationen zur Verwendung mehrerer Master-Knoten finden Sie unter YARN für hohe Verfügbarkeit. ResourceManager](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-applications.html#emr-plan-ha-applications-YARN) **Validierung der Anwendung** Amazon EMR überprüft, ob jede Anwendung auf dem Cluster nach dem Neustart der Neukonfiguration ausgeführt wird. Wenn eine Anwendung nicht verfügbar ist, schlägt der gesamte Neukonfigurationsvorgang fehl. Wenn eine Rekonfigurationoperation fehlschlägt, stellt Amazon EMR die Konfigurationsparameter der zuvor funktionierenden Version wieder her. Um Fehler bei der Neukonfiguration zu vermeiden, empfehlen wir, nur die Anwendungen auf Ihrem Cluster zu installieren, die Sie verwenden möchten. Wir empfehlen Ihnen außerdem, sicherzustellen, dass alle Clusteranwendungen fehlerfrei sind und ausgeführt werden, bevor Sie eine Rekonfigurationsanfrage einreichen. **Arten der Neukonfiguration** Sie können eine Instance-Gruppe auf zwei Arten neu konfigurieren: + **Überschreiben**. Standardmethode für die Rekonfiguration und die einzige, die in Amazon-EMR-Versionen vor 5.35.0 und 6.6.0 verfügbar ist. Diese Rekonfigurationsmethode überschreibt wahllos alle Dateien im Cluster mit dem neu eingereichten Konfigurationssatz. Die Methode löscht alle Änderungen an Konfigurationsdateien, die außerhalb der Rekonfigurations-API vorgenommen wurden. + **Mischen**. Die Rekonfigurationsmethode wird für die Amazon-EMR-Versionen 5.35.0 und 6.6.0 und höher unterstützt, außer in der Amazon-EMR-Konsole, wo sie von keiner Version unterstützt wird. Diese Rekonfigurationsmethode führt die neu eingereichten Konfigurationen mit Konfigurationen zusammen, die bereits auf dem Cluster vorhanden sind. Diese Option fügt nur die neuen Konfigurationen hinzu oder ändert sie, die Sie einreichen. Sie behält bestehende Konfigurationen bei. Amazon EMR überschreibt weiterhin einige wichtige Hadoop-Konfigurationen, die es benötigt, um sicherzustellen, dass der Service ordnungsgemäß ausgeführt wird. **Einschränkungen** Beachten Sie bei der Neukonfiguration einer Instance-Gruppe in einem laufenden Cluster die folgenden Einschränkungen: + Anwendungen, die nicht von Yarn stammen, können beim Neustart fehlschlagen oder Clusterprobleme verursachen, insbesondere wenn die Anwendungen nicht richtig konfiguriert sind. Bei Clustern, die sich der maximalen Speicher- und CPU-Auslastung nähern, können nach dem Neustart Probleme auftreten. Dies gilt insbesondere für die Master-Instance-Gruppe. + Sie können keine Rekonfigurationsanfrage stellen, wenn die Größe einer Instance-Gruppe geändert wird. Wenn eine Rekonfiguration initiiert wird, während die Größe einer Instance-Gruppe geändert wird, kann die Rekonfiguration erst durchgeführt werden, nachdem die Größenänderung abgeschlossen wurde (und umgekehrt). + Nachdem eine Instance-Gruppe rekonfiguriert wurde, startet Amazon EMR die Anwendungen, um die neuen Konfigurationen zu aktivieren. Auftragsfehler und anderes unerwartetes Anwendungsverhalten kann auftreten, wenn die Anwendungen während der Rekonfiguration genutzt werden. + Wenn eine Rekonfiguration für eine Instance-Gruppe fehlschlägt, stellt Amazon EMR die Konfigurationsparameter der zuvor funktionierenden Version wieder her. Schlägt auch diese Wiederherstellung fehl, müssen Sie eine neue `ModifyInstanceGroup`-Anforderung zur Wiederherstellung der Instance-Gruppe aus dem Status `SUSPENDED` senden. + Rekonfigurationsanforderungen für Phoenix-Konfigurationsklassifizierungen werden nur in Amazon EMR ab Version 5.23.0, nicht jedoch in den Amazon-EMR-Versionen 5.21.0 und 5.22.0 unterstützt. + Rekonfigurationsanfragen für HBase Konfigurationsklassifizierungen werden nur in Amazon EMR Version 5.30.0 und höher unterstützt und werden in den Amazon EMR-Versionen 5.23.0 bis 5.29.0 nicht unterstützt. + Amazon EMR unterstützt Anfragen zur Neukonfiguration von Anwendungen auf einem Amazon-EMR-Cluster mit mehreren Primärknoten nur in Amazon-EMR-Versionen 5.27.0 und höher. + Die Neukonfiguration der `hdfs-encryption-zones`–Klassifizierung oder einer der Hadoop KMS-Konfigurationsklassifizierungen auf einem ausgeführten Cluster wird in Amazon EMR nicht unterstützt. + Amazon EMR unterstützt derzeit bestimmte Rekonfigurationsanfragen für den Capacity Scheduler nicht, die einen Neustart des YARN erfordern. ResourceManager Beispielsweise können Sie eine Warteschlange nicht vollständig entfernen. ## Eine Instance-Gruppe in der Konsole neu konfigurieren **Anmerkung** Die Amazon-EMR-Konsole unterstützt keine Rekonfigurationen vom Typ **Merge**. 1. [Öffnen Sie die Amazon EMR-Konsole unter https://console.aws.amazon.com /emr](https://console.aws.amazon.com/emr) 1. Wählen Sie in der Cluster-Liste den aktiven Cluster, der umkonfiguriert werden soll, unter **Name**. 1. Öffnen Sie die Seite mit den Cluster-Details für den Cluster und wechseln Sie zur Registerkarte **Konfigurationen**. 1. Wählen Sie in der Dropdown-Liste **Filter** die Instance-Gruppe aus, die rekonfiguriert werden soll. 1. Wählen Sie in der Dropdown-Liste **Rekonfigurieren** die Option **In Tabelle bearbeiten** oder **In JSON-Datei bearbeiten**. + **In Tabelle bearbeiten**: Bearbeiten Sie in der Tabelle der Konfigurationsklassifizierungen Eigenschaft und Wert vorhandener Konfigurationen oder wählen Sie **Konfiguration hinzufügen**, um für weitere Konfigurationsklassifizierungen anzugeben. + **In JSON-Datei bearbeiten** – Geben Sie die Konfiguration direkt in JSON ein oder verwenden Sie die Kurzschriftsyntax (demonstriert im Schattentext). Stellen Sie andernfalls eine Amazon-S3-URI für eine Datei mit einem JSON-`Configurations`-Objekt bereit. **Anmerkung** Die Spalte **Quelle** in der Tabelle der Konfigurationsklassifizierungen zeigt, ob die Konfiguration beim Erstellen eines Clusters oder beim Angeben zusätzlicher Konfigurationen für diese Instance-Gruppe bereitgestellt wird. Sie können Konfigurationen für eine Instance-Gruppe aus beiden Quellen bearbeiten. Sie können die ursprünglichen Cluster-Konfigurationen nicht löschen, aber sie für eine Instance-Gruppe überschreiben. Sie können außerdem verschachtelte Konfigurationsklassifizierungen direkt in der Tabelle hinzufügen oder bearbeiten. Um beispielsweise eine zusätzliche `export`-Unterklassifizierung von `hadoop-env` bereitzustellen, fügen Sie eine `hadoop.export`-Konfigurationsklassifizierung in die Tabelle ein. Anschließend stellen Sie eine Eigenschaft samt Wert für diese Klassifizierung bereit. 1. (Optional) Wählen Sie **Apply this configuration to all active instance groups (Diese Konfiguration allen aktiven Instance-Gruppen zuweisen)**. 1. Speichern Sie die Änderungen. ## Eine Instance-Gruppe mithilfe der CLI rekonfigurieren Verwenden Sie den Befehl **modify-instance-groups**, um eine neue Konfiguration für eine Instance-Gruppe in einem laufenden Cluster anzugeben. **Anmerkung** Ersetzen Sie in den folgenden Beispielen durch Ihre Cluster-ID und ** ** ersetzen Sie sie durch Ihre Instance-Gruppen-ID. **Example – Eine Konfiguration für eine Instance-Gruppe ersetzen** Das folgende Beispiel verweist auf eine JSON-Konfigurationsdatei, die aufgerufen wird`instanceGroups.json`, um die Eigenschaft der NodeManager YARN-Festplattenintegritätsprüfung für eine Instanzgruppe zu bearbeiten. 1. Bereiten Sie Ihre Konfigurationsklassifizierung vor und speichern Sie sie als `instanceGroups.json` in demselben Verzeichnis, in dem Sie den Befehl ausführen werden. ``` [ { "InstanceGroupId":"", "Configurations":[ { "Classification":"yarn-site", "Properties":{ "yarn.nodemanager.disk-health-checker.enable":"true", "yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage":"100.0" }, "Configurations":[] } ] } ] ``` 1. Führen Sie den folgenden Befehl aus. ``` aws emr modify-instance-groups --cluster-id \ --instance-groups file://instanceGroups.json ``` **Example – Einer Instance-Gruppe eine Konfiguration hinzufügen** Wenn Sie einer Instance-Gruppe eine Konfiguration hinzufügen möchten, müssen Sie alle zuvor angegebenen Konfigurationen für diese Instance-Gruppe in Ihre neue `ModifyInstanceGroup`-Anforderung aufnehmen. Andernfalls werden die zuvor für die angegebenen Konfigurationen entfernt. Das folgende Beispiel fügt eine Eigenschaft für den NodeManager virtuellen YARN-Speicherprüfer hinzu. Die Konfiguration enthält auch zuvor angegebene Werte für den NodeManager YARN-Festplattenintegritätsprüfer, sodass die Werte nicht überschrieben werden. 1. Bereiten Sie den folgenden Inhalt in `instanceGroups.json` vor und speichern Sie ihn im selben Verzeichnis, in dem Sie den Befehl ausführen werden. ``` [ { "InstanceGroupId":"", "Configurations":[ { "Classification":"yarn-site", "Properties":{ "yarn.nodemanager.disk-health-checker.enable":"true", "yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage":"100.0", "yarn.nodemanager.vmem-check-enabled":"true", "yarn.nodemanager.vmem-pmem-ratio":"3.0" }, "Configurations":[] } ] } ] ``` 1. Führen Sie den folgenden Befehl aus. ``` aws emr modify-instance-groups --cluster-id \ --instance-groups file://instanceGroups.json ``` **Example – Einer Instance-Gruppe mit Rekonfiguration vom Typ **Zusammenführen** eine Konfiguration hinzufügen** Wenn Sie die Standardmethode Rekonfiguration **Überschreiben** verwenden möchten, um eine Konfiguration hinzuzufügen, müssen Sie alle zuvor angegebenen Konfigurationen für diese Instance-Gruppe in Ihre neue `ModifyInstanceGroup`-Anfrage aufnehmen. Andernfalls entfernt **Überschreiben** die Konfigurationen, die Sie zuvor angegeben haben. Bei der Neukonfiguration mit **Zusammenführen** müssen Sie dies nicht tun. Stattdessen müssen Sie sicherstellen, dass Ihre Anfrage nur die neuen Konfigurationen enthält. Das folgende Beispiel fügt eine Eigenschaft für den NodeManager virtuellen YARN-Speicherprüfer hinzu. Da es sich um eine Rekonfiguration vom Typ **Merge** handelt, werden zuvor angegebene Werte für die NodeManager YARN-Festplattenintegritätsprüfung nicht überschrieben. 1. Bereiten Sie den folgenden Inhalt in `instanceGroups.json` vor und speichern Sie ihn im selben Verzeichnis, in dem Sie den Befehl ausführen werden. ``` [ {"InstanceGroupId":"", "ReconfigurationType" :"MERGE", "Configurations":[ {"Classification":"yarn-site", "Properties":{ "yarn.nodemanager.vmem-check-enabled":"true", "yarn.nodemanager.vmem-pmem-ratio":"3.0" }, "Configurations":[] } ] } ] ``` 1. Führen Sie den folgenden Befehl aus. ``` aws emr modify-instance-groups --cluster-id \ --instance-groups file://instanceGroups.json ``` **Example – Eine Konfiguration für eine Instance-Gruppe löschen** Um eine Konfiguration für eine Instance-Gruppe zu löschen, senden Sie eine neue Neukonfigurationsanforderung, die die vorherige Konfiguration ausschließt. Sie können die ursprüngliche *Cluster*-Konfiguration nur überschreiben. Sie kann nicht gelöscht werden. Um beispielsweise die Konfiguration für die NodeManager YARN-Festplattenintegritätsprüfung aus dem vorherigen Beispiel zu löschen, reichen Sie eine neue `instanceGroups.json` mit dem folgenden Inhalt ein. ``` [ { "InstanceGroupId":"", "Configurations":[ { "Classification":"yarn-site", "Properties":{ "yarn.nodemanager.vmem-check-enabled":"true", "yarn.nodemanager.vmem-pmem-ratio":"3.0" }, "Configurations":[] } ] } ] ``` Um alle Konfigurationen der letzten Rekonfigurationsanforderung zu löschen, senden Sie eine Rekonfigurationsanforderung mit einem leeren Konfigurations-Array. Zum Beispiel ``` [ { "InstanceGroupId":"", "Configurations":[] } ] ``` **Example – Eine Instance-Gruppe in einer Anfrage neu konfigurieren oder die Größe ändern** Das folgende JSON-Beispiel zeigt, wie eine Instance-Gruppe in derselben Anfrage neu konfiguriert und in der Größe geändert wird. ``` [ { "InstanceGroupId":"", "InstanceCount":5, "EC2InstanceIdsToTerminate":["i-123"], "ForceShutdown":true, "ShrinkPolicy":{ "DecommissionTimeout":10, "InstanceResizePolicy":{ "InstancesToTerminate":["i-123"], "InstancesToProtect":["i-345"], "InstanceTerminationTimeout":20 } }, "Configurations":[ { "Classification":"yarn-site", "Configurations":[], "Properties":{ "yarn.nodemanager.disk-health-checker.enable":"true", "yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage":"100.0" } } ] } ] ``` ## Eine Instance-Gruppe mithilfe des Java SDK neu konfigurieren **Anmerkung** Ersetzen ** Sie in den folgenden Beispielen durch Ihre Cluster-ID und ** ersetzen Sie sie durch Ihre Instanzgruppen-ID. Der folgende Codeausschnitt bietet eine neue Konfiguration für eine Instance-Gruppe unter Verwendung von AWS SDK für Java. ``` AWSCredentials credentials = new BasicAWSCredentials("access-key", "secret-key"); AmazonElasticMapReduce emr = new AmazonElasticMapReduceClient(credentials); Map hiveProperties = new HashMap(); hiveProperties.put("hive.join.emit.interval","1000"); hiveProperties.put("hive.merge.mapfiles","true"); Configuration configuration = new Configuration() .withClassification("hive-site") .withProperties(hiveProperties); InstanceGroupModifyConfig igConfig = new InstanceGroupModifyConfig() .withInstanceGroupId("") .withReconfigurationType("MERGE"); .withConfigurations(configuration); ModifyInstanceGroupsRequest migRequest = new ModifyInstanceGroupsRequest() .withClusterId("") .withInstanceGroups(igConfig); emr.modifyInstanceGroups(migRequest); ``` Der folgende Codeausschnitt löscht eine zuvor angegebene Konfiguration für eine Instance-Gruppe, indem ein leeres Array von Konfigurationen bereitgestellt wird. ``` List configurations = new ArrayList(); InstanceGroupModifyConfig igConfig = new InstanceGroupModifyConfig() .withInstanceGroupId("") .withConfigurations(configurations); ModifyInstanceGroupsRequest migRequest = new ModifyInstanceGroupsRequest() .withClusterId("") .withInstanceGroups(igConfig); emr.modifyInstanceGroups(migRequest); ``` ## Probleme bei der Neukonfiguration von Instance-Gruppen beheben Wenn der Neukonfigurationsprozess für eine Instance-Gruppe fehlschlägt, macht Amazon EMR die Neukonfiguration rückgängig und protokolliert eine Fehlermeldung mithilfe eines Amazon-Ereignisses. CloudWatch Das Ereignis bietet eine kurze Zusammenfassung des Neukonfigurationsfehlers. Es listet die Instances auf, bei denen die Rekonfiguration fehlgeschlagen ist, sowie die entsprechenden Fehlermeldungen. Das Folgende ist ein Beispiel für eine Fehlermeldung. ``` The reconfiguration operation for instance group ig-1xxxxxxx9 in Amazon EMR cluster j-2AL4XXXXXX5T9 (ExampleClusterName) failed at 2021-01-01 00:00 UTC and took 2 minutes to fail. Failed configuration version is example12345. Failure message: Instance i-xxxxxxx1, i-xxxxxxx2, i-xxxxxxx3 failed with message "This is an example failure message". ``` Weitere Daten zu einem Fehler bei der Rekonfiguration können Sie in den Protokollen zur Knotenbereitstellung nachlesen. Dies ist besonders nützlich, wenn Sie eine Nachricht wie die folgende erhalten. ``` i-xxxxxxx1 failed with message “Unable to complete transaction and some changes were applied.” ``` ------ #### [ On the node ] **So greifen Sie auf die Bereitstellungsprotokolle von Knoten zu, indem Sie eine Verbindung zu einem Knoten herstellen** 1. Verwenden Sie SSH, um eine Verbindung zu dem Knoten herzustellen, auf dem die Neukonfiguration fehlgeschlagen ist. Anweisungen finden Sie unter [Herstellen einer Verbindung mit Ihrer Linux-Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html) im *Amazon-EC2*-*Benutzerhandbuch für Linux-Instances*. 1. Navigieren Sie zum folgenden Verzeichnis, das die Protokolldateien für die Knotenbereitstellung enthält. ``` /mnt/var/log/provision-node/ ``` 1. Öffnen Sie das `reports`-Unterverzeichnis und suchen Sie nach dem Knotenbereitstellungsbericht für Ihre Neukonfiguration. Das `reports`-Verzeichnis organisiert Protokolle nach Versionsnummer der Rekonfiguration, UUID (Universally Unique Identifier), IP-Adresse der Amazon-EC2-Instance und Zeitstempel. Jeder Bericht ist eine komprimierte YAML-Datei, die detaillierte Informationen über den Rekonfigurationsprozess enthält. Im Folgenden finden Sie ein Beispiel für einen Berichts-Dateiname und einen Pfad. ``` /reports/2/ca598xxx-cxxx-4xxx-bxxx-6dbxxxxxxxxx/ip-10-73-xxx-xxx.ec2.internal/202104061715.yaml.gz ``` 1. Sie können einen Bericht mit einem Dateibetrachter wie `zless` im folgenden Beispiel untersuchen. ``` zless 202104061715.yaml.gz ``` ------ #### [ Amazon S3 ] **So greifen Sie mit Amazon S3 auf Knotenbereitstellungsprotokolle zu** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/). 1. Öffnen Sie den Amazon-S3-Bucket, den Sie angegeben haben, als Sie den Cluster für die Archivierung von Protokolldateien in konfiguriert haben. 1. Navigieren Sie zum folgenden Ordner, der die Protokolldateien für die Knotenbereitstellung enthält: ``` amzn-s3-demo-bucket/elasticmapreduce//node//provision-node/ ``` 1. Öffnen Sie den `reports`-Ordner und suchen Sie nach dem Bericht zur Knotenbereitstellung für Ihre Rekonfiguration. Der `reports`-Ordner organisiert die Protokolle nach Versionsnummer der Rekonfiguration, UUID (Universally Unique Identifier), IP-Adresse der Amazon EC2 Instance und Zeitstempel. Jeder Bericht ist eine komprimierte YAML-Datei, die detaillierte Informationen über den Rekonfigurationsprozess enthält. Im Folgenden finden Sie ein Beispiel für einen Berichts-Dateiname und einen Pfad. ``` /reports/2/ca598xxx-cxxx-4xxx-bxxx-6dbxxxxxxxxx/ip-10-73-xxx-xxx.ec2.internal/202104061715.yaml.gz ``` 1. Um eine Protokolldatei anzuzeigen, können Sie sie als Textdatei von Amazon S3 auf Ihren lokalen Computer herunterladen. Anweisungen finden Sie unter [Objekt herunterladen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/download-objects.html). ------ Jede Protokolldatei enthält einen detaillierten Bereitstellungsbericht für die zugehörige Rekonfiguration. Um Informationen zu Fehlermeldungen zu finden, können Sie nach der `err`-Protokollebene eines Berichts suchen. Das Berichtsformat hängt von der Amazon-EMR-Version auf Ihrem Cluster ab. Das folgende Beispiel zeigt Fehlerinformationen für Amazon-EMR-Release-Versionen vor 5.32.0 und 6.2.0. ``` - !ruby/object:Puppet::Util::Log level: !ruby/sym err tags: - err message: "Example detailed error message." source: Puppet time: 2021-01-01 00:00:00.000000 +00:00 ``` Die Amazon-EMR-Release-Versionen 5.32.0 und 6.2.0 und höher verwenden stattdessen das folgende Format. ``` - level: err message: 'Example detailed error message.' source: Puppet tags: - err time: '2021-01-01 00:00:00.000000 +00:00' file: line: ``` # Speichern Sie vertrauliche Konfigurationsdaten in AWS Secrets Manager Amazon EMR beschreibt und listet API-Vorgänge auf, die benutzerdefinierte Konfigurationsdaten (wie `DescribeCluster` und `ListInstanceGroups`) ausgeben, und zwar in Klartext. Amazon EMR lässt sich integrieren, AWS Secrets Manager sodass Sie Ihre Daten in Secrets Manager speichern und den geheimen ARN in Ihren Konfigurationen verwenden können. Auf diese Weise geben Sie vertrauliche Konfigurationsdaten nicht im Klartext an Amazon EMR weiter und stellen sie externen Benutzern zur Verfügung. APIs Wenn Sie angeben, dass ein Schlüssel-Wert-Paar einen ARN für ein in Secrets Manager gespeichertes Geheimnis enthält, ruft Amazon EMR dieses Geheimnis ab, wenn es Konfigurationsdaten an den Cluster sendet. Amazon EMR sendet die Anmerkung nicht, wenn die Konfiguration APIs extern angezeigt wird. ## Ein Secret erstellen Um ein Geheimnis zu erstellen, befolgen Sie die Schritte unter [AWS Secrets Manager -Geheimnis erstellen](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) im *AWS Secrets Manager -Benutzerhandbuch*. In **Schritt 3** müssen Sie das **Klartext-Feld** auswählen, um Ihren sensiblen Wert einzugeben. Beachten Sie, dass Secrets Manager zwar zulässt, dass ein Geheimnis bis zu 65 536 Byte enthält, Amazon EMR jedoch die kombinierte Länge des Eigenschaftsschlüssels (ohne Anmerkung) und des abgerufenen geheimen Werts auf 1 024 Zeichen begrenzt. ## Gewähren Sie Amazon EMR Zugriff, um das Geheimnis abzurufen Amazon EMR verwendet eine IAM-Servicerolle, um Cluster für Sie bereitzustellen und zu verwalten. Die Servicerolle für Amazon-EMR-Rolle definiert die zulässigen Aktionen für bei der Bereitstellung von Ressourcen und der Ausführung von Service-Level-Aufgaben, die nicht im Kontext einer EC2-Instance innerhalb eines Clusters ausgeführt werden. Weitere Informationen zu Servicerollen finden Sie unter [Servicerolle für Amazon EMR (EMR-Rolle)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-iam-role.html) und [IAM-Rollen anpassen](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-iam-roles-custom.html). Damit Amazon EMR den geheimen Wert aus Secrets Manager abrufen kann, fügen Sie Ihrer Amazon-EMR-Rolle die folgende Richtlinienerklärung hinzu, wenn Sie Ihren Cluster starten. ``` { "Sid":"AllowSecretsRetrieval", "Effect":"Allow", "Action":"secretsmanager:GetSecretValue", "Resource":[ "arn:aws:secretsmanager:::secret:" ] } ``` Wenn Sie den geheimen Schlüssel mit einem vom Kunden verwalteten Schlüssel erstellen AWS KMS key, müssen Sie der Amazon EMR-Rolle auch eine `kms:Decrypt` Berechtigung für den von Ihnen verwendeten Schlüssel hinzufügen. Weitere Informationen finden Sie unter [Authentifizierung und Zugriffskontrolle für AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access.html) im *AWS Secrets Manager -Benutzerhandbuch*. ## Das Secret in einer Konfigurationsklassifizierung verwenden Sie können die `EMR.secret@`-Anmerkung zu jeder Konfigurationseigenschaft hinzufügen, um anzugeben, dass ihr Schlüssel-Wert-Paar einen ARN für ein in Secrets Manager gespeichertes Secret enthält. Das folgende Beispiel veranschaulicht, wie Sie eine geheime ARN in einer Konfigurationsklassifizierung angeben: ``` { "Classification":"core-site", "Properties":{ "presto.s3.access-key":"", "EMR.secret@presto.s3.secret-key":"arn:aws:secretsmanager:::secret:" } } ``` Wenn Sie Ihren Cluster erstellen und Ihre kommentierte Konfiguration einreichen, validiert Amazon EMR die Konfigurationseigenschaften. Wenn Ihre Konfiguration gültig ist, entfernt Amazon EMR die Anmerkung aus der Konfiguration und ruft das Secret von Secrets Manager ab, um die eigentliche Konfiguration zu erstellen, bevor sie auf den Cluster angewendet wird: ``` { "Classification":"core-site", "Properties":{ "presto.s3.access-key":"", "presto.s3.secret-key":"" } } ``` Wenn Sie eine Aktion wie `DescribeCluster` aufrufen, gibt Amazon EMR die aktuelle Anwendungskonfiguration auf dem Cluster zurück. Wenn eine Anwendungskonfigurationseigenschaft so gekennzeichnet ist, dass sie einen geheimen ARN enthält, enthält die vom `DescribeCluster`-Aufruf zurückgegebene Anwendungskonfiguration den ARN und nicht den geheimen Wert. Dadurch wird sichergestellt, dass der geheime Wert nur auf dem Cluster sichtbar ist: ``` { "Classification":"core-site", "Properties":{ "presto.s3.access-key":"", "presto.s3.secret-key":"arn:aws:secretsmanager:::secret:" } } ``` ## Den Secret-Wert aktualisieren Amazon EMR ruft den geheimen Wert aus einer mit Anmerkungen versehenen Konfiguration ab, wenn die angehängte Instance-Gruppe gestartet, neu konfiguriert oder ihre Größe geändert wird. Sie können Secrets Manager verwenden, um den Wert eines Secrets zu ändern, das in der Konfiguration eines laufenden Clusters verwendet wird. Wenn Sie dies tun, können Sie eine Rekonfigurationsanfrage an jede Instance-Gruppe senden, die den aktualisierten Wert erhalten soll. Weitere Informationen zur Neukonfiguration einer Instance-Gruppe und zu den Dingen, die Sie dabei beachten sollten, finden Sie unter [Eine Instance-Gruppe in einem laufenden Cluster neu konfigurieren](emr-configure-apps-running-cluster.md). # Anwendungen für die Verwendung einer bestimmten Java Virtual Machine konfigurieren Amazon-EMR-Versionen haben unterschiedliche Standardversionen von Java Virtual Machine (JVM). Auf dieser Seite wird die JVM-Unterstützung für verschiedene Versionen und Anwendungen erklärt. ## Überlegungen Weitere Informationen über die unterstützten Java-Versionen für Anwendungen finden Sie in den [Amazon-EMR-Versionshinweisen](emr-release-components.md). + Amazon EMR unterstützt nur die Ausführung einer Laufzeit-Version in einem Cluster und nicht die Ausführung verschiedener Knoten oder Anwendungen auf verschiedenen Laufzeit-Versionen auf demselben Cluster. + Für Amazon EMR 7.x ist Java 17 die standardmäßige Java Virtual Machine (JVM) für Anwendungen, die Java 17 unterstützen, mit Ausnahme von Apache Livy. Weitere Informationen über die unterstützten JDK-Versionen für Anwendungen finden Sie in den entsprechenden Versionsseiten in den Amazon-EMR-Versionshinweisen. + Ab Amazon EMR 7.1.0 unterstützt Flink Java 17 und ist standardmäßig auf Java 17 eingestellt. Um eine andere Version der Java-Runtime zu verwenden, überschreiben Sie die Einstellungen in. `flink-conf` Weitere Informationen zur Konfiguration von Flink für die Verwendung von Java 8 oder Java 11 finden [Sie unter Konfigurieren von Flink für die Ausführung mit Java](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/flink-configure.html#flink-configure-java11) 11. + Für Amazon EMR 5.x und 6.x ist Java 8 die standardmäßige Java Virtual Machine (JVM). + Für Amazon-EMR-Versionen 6.12.0 und höher unterstützen einige Anwendungen auch Java 11 und 17. + Für Amazon-EMR-Versionen 6.9.0 und höher unterstützt Trino standardmäßig Java 17. Weitere Informationen über Java 17 mit Trino finden Sie unter [Trino-Updates für Java 17](https://trino.io/blog/2022/07/14/trino-updates-to-java-17.html) im Trino-Blog. Beachten Sie bei der Auswahl Ihrer Laufzeit-Version die folgenden anwendungsspezifischen Überlegungen: **Anwendungsspezifische Java-Konfigurationshinweise** | Anwendung | Hinweise zur Java-Konfigurationen | | --- | --- | | Spark | Um Spark mit einer nicht standardmäßigen Java-Version auszuführen, müssen Sie sowohl Spark als auch Hadoop konfigurieren. Beispiele finden Sie unter [Die JVM überschreiben](#configuring-java8-override). [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ReleaseGuide/configuring-java8.html) | | Spark RAPIDS | Sie können RAPIDS mit der konfigurierten Java-Version für Spark ausführen. | | Iceberg | Sie können Iceberg mit der konfigurierten Java-Version der Anwendung ausführen, die es verwendet. | | Delta | Sie können Delta mit der konfigurierten Java-Version der Anwendung ausführen, die es verwendet. | | Hudi | Sie können Hudi mit der konfigurierten Java-Version der Anwendung ausführen, die es verwendet. | | Hadoop | Um die JVM für Hadoop zu aktualisieren, ändern Sie `hadoop-env`. Beispiele finden Sie unter [Die JVM überschreiben](#configuring-java8-override). | | Hive | Um die Java-Version für Hive auf 11 oder 17 festzulegen, konfigurieren Sie die Hadoop JVM-Einstellung auf die Java-Version, die Sie verwenden möchten. | | HBase | Um die JVM für HBase zu aktualisieren, ändern Sie. `hbase-env` Standardmäßig legt Amazon EMR die HBase JVM auf der Grundlage der JVM-Konfiguration für Hadoop fest, sofern Sie die Einstellungen in nicht überschreiben. `hbase-env` Beispiele finden Sie unter [Die JVM überschreiben](#configuring-java8-override). | | Flink | Um die JVM für Flink zu aktualisieren, ändern Sie `flink-conf`. Standardmäßig legt Amazon EMR die Flink-JVM auf der Grundlage der JVM-Konfiguration für Hadoop fest, sofern Sie die Einstellungen in `flink-conf` nicht überschreiben. Weitere Informationen finden Sie unter [Flink für die Ausführung mit Java 11 konfigurieren](flink-configure.md#flink-configure-java11). | | Oozie | Um Oozie für die Ausführung unter Java 11 oder 17 zu konfigurieren, konfigurieren Sie Oozie Server, den Oozie LauncherAM Launcher AM und ändern Sie Ihre clientseitigen ausführbaren Dateien und Auftragskonfigurationen. Sie können `EmbeddedOozieServer` auch für die Ausführung unter Java 17 konfigurieren. Weitere Informationen finden Sie unter [Die Java-Version für Oozie konfigurieren](oozie-java.md). | | Pig | Pig unterstützt nur Java 8. Sie können Java 11 oder 17 nicht mit Hadoop verwenden und Pig auf demselben Cluster ausführen. | ## Die JVM überschreiben Um die JVM-Einstellung für eine Amazon-EMR-Version zu überschreiben – z. B. um Java 17 mit einem Cluster zu verwenden, der Amazon-EMR-Version 6.12.0 verwendet – geben Sie die `JAVA_HOME`-Einstellung an die Umgebungsklassifizierung an, die `application-env` für alle Anwendungen außer Flink ist. Für Flink lautet die Umgebungsklassifizierung `flink-conf`. Schritte zur Konfiguration der Java-Laufzeit mit Flink finden Sie unter [Flink für die Ausführung mit Java 11 konfigurieren](flink-configure.md#flink-configure-java11). **Topics** + [Die JVM-Einstellung mit Apache Spark überschreiben](#configuring-java8-override-spark) + [Überschreiben Sie die JVM-Einstellung mit Apache HBase](#configuring-java8-override-hbase) + [Die JVM-Einstellung mit Apache Hadoop und Hive überschreiben](#configuring-java8-override-hadoop) ### Die JVM-Einstellung mit Apache Spark überschreiben Wenn Sie Spark mit Amazon EMR-Versionen 6.12 und höher verwenden, können Sie die Umgebung so einrichten, dass die Executoren Java 11 oder 17 verwenden. Und wenn Sie Spark mit Amazon-EMR-Versionen unter 5.x verwenden und einen Treiber für die Einreichung im Cluster-Modus schreiben, verwendet der Treiber Java 7. Die Umgebung kann dann aber so eingestellt werden, dass die Executors Java 8 verwenden. Um die JVM für Spark zu überschreiben, legen Sie die Spark-Klassifizierungseinstellung fest. In diesem Beispiel ist die Java-Version für Hadoop dieselbe, aber das ist nicht erforderlich. ``` [ { "Classification": "hadoop-env", "Configurations": [ { "Classification": "export", "Configurations": [], "Properties": { "JAVA_HOME": "/usr/lib/jvm/java-1.8.0" } } ], "Properties": {} }, { "Classification": "spark-env", "Configurations": [ { "Classification": "export", "Configurations": [], "Properties": { "JAVA_HOME": "/usr/lib/jvm/java-1.8.0" } } ], "Properties": {} } ] ``` Beachten Sie, dass es eine empfohlene bewährte Methode für Hadoop auf Amazon EMR ist, dass die JVM-Version für alle Hadoop-Komponenten konsistent sein sollte. Das folgende Beispiel zeigt, wie Sie die erforderlichen Konfigurationsparameter für EMR 7.0.0\$1 hinzufügen, um eine konsistente Verwendung der Java-Version für alle Komponenten sicherzustellen. ``` [ { "Classification": "spark-defaults", "Properties": { "spark.executorEnv.JAVA_HOME": "/usr/lib/jvm/java-1.8.0", "spark.yarn.appMasterEnv.JAVA_HOME": "/usr/lib/jvm/java-1.8.0" } }, { "Classification": "hadoop-env", "Configurations": [ { "Classification": "export", "Configurations": [], "Properties": { "JAVA_HOME": "/usr/lib/jvm/java-1.8.0" } } ], "Properties": {} }, { "Classification": "spark-env", "Configurations": [ { "Classification": "export", "Configurations": [], "Properties": { "JAVA_HOME": "/usr/lib/jvm/java-1.8.0" } } ], "Properties": {} } ] ``` ### Überschreiben Sie die JVM-Einstellung mit Apache HBase Um die Verwendung von Java 11 HBase zu konfigurieren, können Sie beim Starten des Clusters die folgende Konfiguration festlegen. ``` [ { "Classification": "hbase-env", "Properties": {}, "Configurations": [ { "Classification": "export", "Properties": { "JAVA_HOME": "/usr/lib/jvm/jre-11", "HBASE_OPTS": "-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -Dsun.net.inetaddr.ttl=5" }, "Configurations": [] } ] } ] ``` ### Die JVM-Einstellung mit Apache Hadoop und Hive überschreiben Im folgenden Beispiel wird gezeigt, wie Sie die JVM für Hadoop und Hive auf Version 17 setzen. ``` [ { "Classification": "hadoop-env", "Configurations": [ { "Classification": "export", "Configurations": [], "Properties": { "JAVA_HOME": "/usr/lib/jvm/jre-17" } } ], "Properties": {} } ] ``` ## Service-Ports Die folgenden Ports sind YARN- und HDFS-Service-Ports. Diese Einstellungen stellen die Hadoop-Standardwerte dar. Andere Anwendungsservices werden bei Standard-Ports gehostet, sofern nicht anders dokumentiert. Weitere Informationen enthält die Projektdokumentation der Anwendung. **Port-Einstellungen für YARN und HDFS** | Einstellung | Hostname/Port | | --- | --- | | `fs.default.name` | Standard (`hdfs://emrDeterminedIP:8020`) | | `dfs.datanode.address` | Standard (`0.0.0.0:50010`) | | `dfs.datanode.http.address` | Standard (`0.0.0.0:50075`) | | `dfs.datanode.https.address` | Standard (`0.0.0.0:50475`) | | `dfs.datanode.ipc.address` | Standard (`0.0.0.0:50020`) | | `dfs.http.address` | Standard (`0.0.0.0:50070`) | | `dfs.https.address` | Standard (`0.0.0.0:50470`) | | `dfs.secondary.http.address` | Standard (`0.0.0.0:50090`) | | `yarn.nodemanager.address` | Standard (`${yarn.nodemanager.hostname}:0`) | | `yarn.nodemanager.localizer.address` | Standard (`${yarn.nodemanager.hostname}:8040`) | | `yarn.nodemanager.webapp.address` | Standard (`${yarn.nodemanager.hostname}:8042`) | | `yarn.resourcemanager.address` | Standard (`${yarn.resourcemanager.hostname}:8032`) | | `yarn.resourcemanager.admin.address` | Standard (`${yarn.resourcemanager.hostname}:8033`) | | `yarn.resourcemanager.resource-tracker.address` | Standard (`${yarn.resourcemanager.hostname}:8031`) | | `yarn.resourcemanager.scheduler.address` | Standard (`${yarn.resourcemanager.hostname}:8030`) | | `yarn.resourcemanager.webapp.address` | Standard (`${yarn.resourcemanager.hostname}:8088`) | | `yarn.web-proxy.address` | Standard (`no-value`) | | `yarn.resourcemanager.hostname` | `emrDeterminedIP` | **Anmerkung** Der Begriff *emrDeterminedIP* ist eine IP-Adresse, die von der Amazon EMR-Steuerebene generiert wird. In der neueren Version wurde diese Konvention entfernt, mit Ausnahme der Einstellungen `yarn.resourcemanager.hostname` und `fs.default.name`. ## Anwendungsbenutzer Die Anwendungen führen Prozesse als deren eigene Benutzer aus. Zum Beispiel Hive „Als Benutzer JVMs ausführen“`hive`, „ MapReduce JVMs Ausführen als`mapred`“ usw. Dies wird im folgenden Prozessstatusbeispiel gezeigt. ``` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND hive 6452 0.2 0.7 853684 218520 ? Sl 16:32 0:13 /usr/lib/jvm/java-openjdk/bin/java -Xmx256m -Dhive.log.dir=/var/log/hive -Dhive.log.file=hive-metastore.log -Dhive.log.threshold=INFO -Dhadoop.log.dir=/usr/lib/hadoop hive 6557 0.2 0.6 849508 202396 ? Sl 16:32 0:09 /usr/lib/jvm/java-openjdk/bin/java -Xmx256m -Dhive.log.dir=/var/log/hive -Dhive.log.file=hive-server2.log -Dhive.log.threshold=INFO -Dhadoop.log.dir=/usr/lib/hadoop/l hbase 6716 0.1 1.0 1755516 336600 ? Sl Jun21 2:20 /usr/lib/jvm/java-openjdk/bin/java -Dproc_master -XX:OnOutOfMemoryError=kill -9 %p -Xmx1024m -ea -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -Dhbase.log.dir=/var/ hbase 6871 0.0 0.7 1672196 237648 ? Sl Jun21 0:46 /usr/lib/jvm/java-openjdk/bin/java -Dproc_thrift -XX:OnOutOfMemoryError=kill -9 %p -Xmx1024m -ea -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -Dhbase.log.dir=/var/ hdfs 7491 0.4 1.0 1719476 309820 ? Sl 16:32 0:22 /usr/lib/jvm/java-openjdk/bin/java -Dproc_namenode -Xmx1000m -Dhadoop.log.dir=/var/log/hadoop-hdfs -Dhadoop.log.file=hadoop-hdfs-namenode-ip-10-71-203-213.log -Dhadoo yarn 8524 0.1 0.6 1626164 211300 ? Sl 16:33 0:05 /usr/lib/jvm/java-openjdk/bin/java -Dproc_proxyserver -Xmx1000m -Dhadoop.log.dir=/var/log/hadoop-yarn -Dyarn.log.dir=/var/log/hadoop-yarn -Dhadoop.log.file=yarn-yarn- yarn 8646 1.0 1.2 1876916 385308 ? Sl 16:33 0:46 /usr/lib/jvm/java-openjdk/bin/java -Dproc_resourcemanager -Xmx1000m -Dhadoop.log.dir=/var/log/hadoop-yarn -Dyarn.log.dir=/var/log/hadoop-yarn -Dhadoop.log.file=yarn-y mapred 9265 0.2 0.8 1666628 260484 ? Sl 16:33 0:12 /usr/lib/jvm/java-openjdk/bin/java -Dproc_historyserver -Xmx1000m -Dhadoop.log.dir=/usr/lib/hadoop/logs -Dhadoop.log.file=hadoop.log -Dhadoop.home.dir=/usr/lib/hadoop ```