Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Configuration des applications Pour remplacer les configurations par défaut d'une application, vous pouvez fournir un objet de configuration. Vous pouvez soit utiliser une syntaxe abrégée pour fournir la configuration, soit faire référence à l'objet de configuration dans un fichier JSON. Les objets de configuration sont composés d'une classification, de propriétés et de configurations imbriquées en option. Les propriétés correspondent aux paramètres de l'application que vous souhaitez modifier. Vous pouvez spécifier plusieurs classifications pour plusieurs applications d'un seul objet JSON. **Avertissement** Les opérations de l'API Amazon EMR Describe et List émettent des paramètres personnalisés et configurables, qui sont utilisés dans le cadre des flux de travail Amazon EMR, en texte clair. Pour fournir des informations sensibles, telles que des mots de passe, dans ces paramètres, consultez [Stocker les données de configuration sensibles dans AWS Secrets Manager](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/storing-sensitive-data.html). Les classifications de configuration qui sont disponibles varient d'une version d'Amazon EMR à l'autre. Pour obtenir la liste des classifications de configuration prises en charge dans une version de version particulière, reportez-vous à la page de cette version sous [À propos des versions Amazon EMR](emr-release-components.md). Voici un exemple de fichier JSON pour une liste de configurations. ``` [ { "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" } } ] ``` Une classification de configuration correspond généralement à un fichier de configuration spécifique à l'application. Par exemple, la classification `hive-site` est mappée aux paramètres du fichier de configuration `hive-site.xml` pour Hive. Une exception à cette règle est l'action d'amorçage `configure-daemons`, qui n'est plus prise en charge et qui est utilisée pour définir des paramètres d'environnement tels que `--namenode-heap-size`. Les options de ce type sont intégrées dans les classifications `hadoop-env` et `yarn-env` avec leurs propres classifications d'exportation imbriquées. Si des classifications se terminent par `env`, utilisez la sous-classification d'exportation. `s3get` est une autre exception qui est utilisée pour placer un objet `EncryptionMaterialsProvider` client sur chaque nœud d'un cluster pour l'utiliser dans le chiffrement côté client. Une option a été ajoutée à la classification `emrfs-site` à cet effet. Voici un exemple de la classification `hadoop-env`. ``` [ { "Classification": "hadoop-env", "Properties": { }, "Configurations": [ { "Classification": "export", "Properties": { "HADOOP_DATANODE_HEAPSIZE": "2048", "HADOOP_NAMENODE_OPTS": "-XX:GCTimeRatio=19" }, "Configurations": [ ] } ] } ] ``` Voici un exemple de la classification yarn-env. ``` [ { "Classification": "yarn-env", "Properties": { }, "Configurations": [ { "Classification": "export", "Properties": { "YARN_RESOURCEMANAGER_OPTS": "-Xdebug -Xrunjdwp:transport=dt_socket" }, "Configurations": [ ] } ] } ] ``` Les paramètres suivants n'appartiennent pas à un fichier de configuration, mais sont utilisés par Amazon EMR pour configurer potentiellement plusieurs paramètres en votre nom. **Paramètres définis par Amazon EMR** | Application | Classification d'étiquette de version | Propriétés valides | Quand l’utiliser | | --- | --- | --- | --- | | Spark | spark | maximizeResourceAllocation | Configurez des programmes d’exécution pour utiliser le maximum de ressources de chaque nœud. | **Topics** + [Configuration des applications lorsque vous créez un cluster](emr-configure-apps-create-cluster.md) + [Reconfigurer un groupe d'instances dans un cluster en cours d'exécution](emr-configure-apps-running-cluster.md) + [Stockez les données de configuration sensibles dans AWS Secrets Manager](storing-sensitive-data.md) + [Configuration des applications pour l'utilisation d'une machine virtuelle Java spécifique](configuring-java8.md) # Configuration des applications lorsque vous créez un cluster Lorsque vous créez un cluster, vous pouvez remplacer les configurations par défaut pour les applications à l'aide de la console Amazon EMR, AWS Command Line Interface du AWS CLI() ou AWS du SDK. Pour remplacer la configuration par défaut d'une application, vous devez spécifier des valeurs personnalisées dans une classification de configuration. Une classification de configuration correspond à un fichier XML de configuration pour une application, tel que `hive-site.xml`. Les classifications de configuration varient selon la version d'Amazon EMR. Pour obtenir une liste des classifications de configuration disponibles dans une version spécifique, consultez la page des détails de la version. Par exemple, [Amazon EMR version 6.4.0.](emr-640-release.md#emr-640-class) ## Fournir une configuration dans la console lorsque vous créez un cluster Pour fournir une configuration, accédez à la page **Créer un cluster** et développez **les paramètres du logiciel**. Vous pouvez ensuite saisir la configuration directement à l'aide de JSON ou d’une syntaxe raccourcie présentée dans le texte ombré dans la console. Sinon, vous pouvez fournir un URI Amazon S3 pour un fichier avec un objet JSON `Configurations`. Pour fournir une configuration pour un groupe d'instances, choisissez un cluster dans votre liste de clusters, puis cliquez sur l'onglet **Configurations**. Dans le tableau des **configurations des groupes d'instances**, choisissez le groupe d'instances à modifier, puis choisissez **Reconfigurer**. ## Fournissez une configuration à l'aide du AWS CLI lorsque vous créez un cluster Vous pouvez fournir une configuration à **create-cluster** en fournissant un chemin d'accès à un fichier JSON stocké localement ou dans Amazon S3. L'exemple suivant suppose que vous utilisiez les rôles par défaut pour Amazon EMR et que ces rôles ont été créés. Si vous devez créer les rôles, exécutez d'abord `aws emr create-default-roles`. Si votre configuration se trouve dans votre répertoire local, vous pouvez utiliser l'exemple de commande suivant. ``` 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 ``` Si votre configuration se trouve dans un chemin Amazon S3, vous devez configurer la solution de contournement suivante avant de transmettre le chemin Amazon S3 à la commande `create-cluster`. ``` #!/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 ``` ## Fournir une configuration à l'aide du kit SDK Java lors de la création d'un cluster L'extrait de programme suivant montre comment fournir une configuration à l'aide de AWS SDK pour Java. ``` 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") ); ``` # Reconfigurer un groupe d'instances dans un cluster en cours d'exécution Avec Amazon EMR version 5.21.0 et ultérieure, vous pouvez reconfigurer les applications de cluster et spécifier des classifications de configuration supplémentaires pour chaque groupe d'instances dans un cluster en cours d'exécution. Pour ce faire, vous pouvez utiliser la console Amazon EMR, le AWS Command Line Interface (AWS CLI) ou le AWS SDK. Lorsque vous mettez à jour la configuration d'une application pour un groupe d'instances dans la nouvelle console Amazon EMR, la console tente de fusionner la nouvelle configuration avec la configuration existante pour créer une nouvelle configuration active. Dans le cas inhabituel où Amazon EMR ne parvient pas à fusionner la configuration, la console vous avertit. Après avoir soumis une demande de reconfiguration pour un groupe d'instances, Amazon EMR attribue un numéro de version à la nouvelle spécification de configuration. Vous pouvez suivre le numéro de version d'une configuration ou l'état d'un groupe d'instances en consultant les CloudWatch événements. Pour plus d'informations, consultez la section [Surveiller CloudWatch les événements](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-cloudwatch-events.html). **Note** Vous pouvez uniquement remplacer, et non supprimer, les configurations de cluster spécifiées lors de la création du cluster. S'il existe des différences entre la configuration existante et le fichier que vous fournissez, Amazon EMR rétablit les configurations modifiées manuellement, telles que les configurations que vous avez modifiées lors de la connexion à votre cluster via SSH, aux valeurs par défaut du cluster pour le groupe d'instances spécifié. ## Considérations à prendre en compte lors de la reconfiguration d'un groupe d'instances **Actions de reconfiguration** Lorsque vous soumettez une demande de reconfiguration à l'aide de la console Amazon EMR, AWS Command Line Interface du AWS CLI() ou du SDK, Amazon EMR vérifie AWS le fichier de configuration existant sur le cluster. S'il existe des différences entre la configuration existante et le fichier que vous fournissez, Amazon EMR lance des actions de reconfiguration, redémarre certaines applications et réinitialise toutes les configurations modifiées manuellement, telles que les configurations que vous avez modifiées lorsque vous êtes connecté à votre cluster via SSH, aux valeurs par défaut du cluster pour le groupe d'instances spécifié. Amazon EMR exécute certaines actions par défaut lors de chaque reconfiguration de groupe d'instances. Ces actions par défaut peuvent entrer en conflit avec les personnalisations de cluster que vous avez effectuées et entraîner des échecs de reconfiguration. Pour plus d'informations sur le dépannage des échecs de reconfiguration, consultez [Résoudre les problèmes de reconfiguration des groupes d'instances](#emr-configure-apps-running-cluster-troubleshoot). Amazon EMR lance également des actions de reconfiguration pour les classifications de configuration que vous spécifiez dans votre demande. Pour obtenir la liste complète de ces actions, consultez la section Classifications de configuration correspondant à la version d'Amazon EMR que vous utilisez. Par exemple, [Classifications de configuration 6.2.0](emr-620-release.md#emr-620-class). Le guide de mise à jour d'Amazon EMR répertorie uniquement les actions de reconfiguration à partir des versions 5.32.0 et 6.2.0 d'Amazon EMR. **Interruption du service** Amazon EMR suit un processus continu pour reconfigurer les instances dans les groupes d'instances Task et Core. Seules 10 % des instances d’un groupe d'instances peuvent être modifiées et redémarrées à un moment donné. Ce processus est plus long à s’exécuter, mais il permet de réduire le risque de défaillance potentielle des applications dans un cluster en cours d'exécution. Pour exécuter des tâches YARN lors d'un redémarrage de YARN, vous pouvez soit créer un cluster Amazon EMR avec plusieurs nœuds primaires, soit définir `yarn.resourcemanager.recovery.enabled` sur `true` dans votre classification de configuration `yarn-site`. Pour plus d'informations sur l'utilisation de plusieurs nœuds maîtres, consultez [High Availability YARN ResourceManager](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-applications.html#emr-plan-ha-applications-YARN). **Validation des applications** Amazon EMR vérifie que chaque application du cluster est en cours d'exécution après le redémarrage de la reconfiguration. Si une application n'est pas disponible, l'opération de reconfiguration globale échoue. Si une opération de reconfiguration échoue, Amazon EMR inverse les paramètres de configuration pour revenir à la version de travail précédente. Pour éviter tout échec de reconfiguration, nous vous recommandons de n'installer sur votre cluster que les applications que vous comptez utiliser. Nous vous recommandons également de vous assurer que toutes les applications de cluster fonctionnent correctement avant de soumettre une demande de reconfiguration. **Types de reconfiguration** Vous pouvez reconfigurer un groupe d'instances de deux manières suivantes : + **Overwrite**. Méthode de reconfiguration par défaut et la seule disponible dans les versions Amazon EMR antérieures aux versions 5.35.0 et 6.6.0. Cette méthode de reconfiguration remplace sans distinction tous les fichiers du cluster par le nouvel ensemble de configuration soumis. La méthode efface toutes les modifications apportées aux fichiers de configuration en dehors de l'API de reconfiguration. + **Fusionner**. Méthode de reconfiguration prise en charge pour les versions 5.35.0 et 6.6.0 d'Amazon EMR et versions ultérieures, à l'exception de la console Amazon EMR, où aucune version ne la prend en charge. Cette méthode de reconfiguration fusionne les configurations récemment soumises avec les configurations qui existent déjà sur le cluster. Cette option ajoute ou modifie uniquement les nouvelles configurations que vous soumettez. Il préserve les configurations existantes. Amazon EMR continue de remplacer certaines configurations Hadoop essentielles dont il a besoin pour garantir le bon fonctionnement du service. **Limites** Lorsque vous reconfigurez un groupe d'instances dans un cluster en cours d'exécution, tenez compte des limitations suivantes : + Les applications autres que Yarn peuvent échouer au redémarrage ou provoquer des problèmes de cluster, en particulier si les applications ne sont pas correctement configurées. Les clusters approchant le maximum d'utilisation de la mémoire et du processeur peuvent rencontrer des problèmes après le redémarrage. Cela est particulièrement vrai pour le groupe d'instances principal. + Vous ne pouvez pas envoyer de demande de reconfiguration lorsqu'un groupe d'instances est redimensionné. Si une reconfiguration est initiée pendant le redimensionnement d’un groupe d’instances, la reconfiguration ne peut pas démarrer tant que le redimensionnement du groupe d'instances n’est pas terminé, et vice versa. + Après avoir reconfiguré un groupe d'instances, Amazon EMR redémarre les applications afin de permettre la prise en compte des nouvelles configurations. Des échecs de tâches ou d'autres comportements inattendus des applications peuvent se produire si les applications sont utilisées durant la reconfiguration. + Si une reconfiguration échoue pour un groupe d'instances, Amazon EMR réinitialise les paramètres de configuration vers la précédente version fonctionnelle. Si le processus de réinitialisation échoue, vous devez soumettre une nouvelle demande `ModifyInstanceGroup` pour récupérer le groupe d'instances à partir de l'état `SUSPENDED`. + Les demandes de reconfiguration pour les classifications de configuration Phoenix ne sont prises en charge que dans Amazon EMR version 5.23.0 et ultérieure, et ne sont pas prises en charge dans Amazon EMR version 5.21.0 ou 5.22.0. + Les demandes de reconfiguration pour les classifications de HBase configuration ne sont prises en charge que dans les versions 5.30.0 et ultérieures d'Amazon EMR, et non dans les versions 5.23.0 à 5.29.0 d'Amazon EMR. + Amazon EMR prend en charge les demandes de reconfiguration d'applications sur un cluster Amazon EMR comportant plusieurs nœuds primaires uniquement dans les versions 5.27.0 et ultérieures d'Amazon EMR. + La reconfiguration de la classification `hdfs-encryption-zones` ou de l'une des classifications de configuration Hadoop KMS n'est pas prise en charge sur un cluster Amazon EMR comportant plusieurs nœuds primaires. + Amazon EMR ne prend actuellement pas en charge certaines demandes de reconfiguration du planificateur de capacité qui nécessitent le redémarrage du YARN. ResourceManager Par exemple, vous ne pouvez pas supprimer complètement une file d'attente. ## Reconfigurer un groupe d'instances dans la console **Note** La console Amazon EMR ne prend pas en charge les reconfigurations de type **Merge**. 1. [Ouvrez la console Amazon EMR à l'adresse /emr https://console.aws.amazon.com](https://console.aws.amazon.com/emr) 1. Dans la liste des clusters sous **Nom**, sélectionnez le cluster actif que vous souhaitez reconfigurer. 1. Ouvrez la page des détails du cluster et accédez à l'onglet **Configurations**. 1. Dans la liste déroulante **Filter (Filtre)**, sélectionnez le groupe d'instances que vous souhaitez reconfigurer. 1. Dans le menu déroulant **Reconfigurer**, choisissez **Modifier dans la table** ou **Modifier dans le fichier JSON**. + **Modifier dans la table** – Dans la table de classification de configuration, modifiez la propriété et la valeur des configurations existantes ou choisissez **Ajouter une configuration** pour fournir des classifications de configuration supplémentaires. + **Modification dans un fichier JSON** – Saisissez la configuration directement dans JSON, ou utilisez une syntaxe sténographique (démontrée dans le texte ombré). Sinon, fournissez un URI Amazon S3 pour un fichier avec un objet JSON `Configurations`. **Note** La colonne **Source** de la table des classifications de configuration indique si la configuration est fournie lorsque vous créez un cluster ou lorsque vous spécifiez des configurations supplémentaires pour ce groupe d'instances. Vous pouvez modifier les configurations d’un groupe d'instances à partir de ces deux sources. Vous ne pouvez pas supprimer les configurations de cluster initiales, mais vous pouvez les remplacer pour un groupe d'instances. Vous pouvez également ajouter ou modifier les classifications de configuration imbriquées directement dans la table. Par exemple, pour fournir une sous-classification `export` supplémentaire de `hadoop-env`, ajoutez une classification de configuration `hadoop.export` dans la table. Ensuite, indiquez une propriété et une valeur spécifiques pour cette classification. 1. (Facultatif) Sélectionnez **Apply this configuration to all active instance groups (Appliquer cette configuration à tous les groupes d'instances actifs)**. 1. Enregistrez les Modifications. ## Reconfigurer un groupe d'instances à l'aide de la CLI Utilisez la commande **modify-instance-groups** pour spécifier une nouvelle configuration pour un groupe d'instances dans un cluster en cours d'exécution. **Note** Dans les exemples suivants, remplacez ** par votre ID de cluster et remplacez ** par votre ID de groupe d'instances. **Example – Remplacer une configuration pour un groupe d'instances** L'exemple suivant fait référence à un fichier JSON de configuration appelé `instanceGroups.json` pour modifier la propriété du vérificateur de santé du NodeManager disque YARN pour un groupe d'instances. 1. Préparez votre classification de configuration et enregistrez-la comme `instanceGroups.json` dans le répertoire où vous allez exécuter la commande. ``` [ { "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. Exécutez la commande suivante. ``` aws emr modify-instance-groups --cluster-id \ --instance-groups file://instanceGroups.json ``` **Example – Ajoute une configuration à un groupe d'instances** Si vous voulez ajouter une configuration à un groupe d'instances, vous devez inclure toutes les configurations précédemment spécifiées pour ce groupe d'instances dans votre nouvelle demande `ModifyInstanceGroup`. Dans le cas contraire, les configurations précédemment spécifiées sont supprimées. L'exemple suivant ajoute une propriété pour le vérificateur de mémoire NodeManager virtuelle YARN. La configuration inclut également les valeurs précédemment spécifiées pour le vérificateur de santé du NodeManager disque YARN afin que les valeurs ne soient pas remplacées. 1. Préparez le contenu suivant dans `instanceGroups.json` et enregistrez-le dans le même répertoire que celui où vous exécuterez la commande. ``` [ { "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. Exécutez la commande suivante. ``` aws emr modify-instance-groups --cluster-id \ --instance-groups file://instanceGroups.json ``` **Example – Ajoutez une configuration à un groupe d'instances avec une reconfiguration de type **Merge**** Lorsque vous souhaitez utiliser la méthode de reconfiguration **Overwrite** par défaut pour ajouter une configuration, vous devez inclure toutes les configurations précédemment spécifiées pour ce groupe d'instances dans votre nouvelle demande `ModifyInstanceGroup`. Dans le cas contraire, **Overwrite** supprime les configurations que vous avez spécifiées précédemment. Vous n'avez pas besoin de le faire avec la reconfiguration de **Merge**. Vous devez plutôt vous assurer que votre demande inclut uniquement les nouvelles configurations. L'exemple suivant ajoute une propriété pour le vérificateur de mémoire NodeManager virtuelle YARN. Comme il s'agit d'une reconfiguration de type **Merge**, elle ne remplace pas les valeurs précédemment spécifiées pour le vérificateur de santé du NodeManager disque YARN. 1. Préparez le contenu suivant dans `instanceGroups.json` et enregistrez-le dans le même répertoire que celui où vous exécuterez la commande. ``` [ {"InstanceGroupId":"", "ReconfigurationType" :"MERGE", "Configurations":[ {"Classification":"yarn-site", "Properties":{ "yarn.nodemanager.vmem-check-enabled":"true", "yarn.nodemanager.vmem-pmem-ratio":"3.0" }, "Configurations":[] } ] } ] ``` 1. Exécutez la commande suivante. ``` aws emr modify-instance-groups --cluster-id \ --instance-groups file://instanceGroups.json ``` **Example – Supprimer une configuration pour un groupe d'instances** Pour supprimer une configuration pour un groupe d'instances, soumettez une nouvelle demande de reconfiguration excluant la configuration précédente. Vous pouvez uniquement remplacer la configuration de *cluster* initiale. Vous ne pouvez pas la supprimer. Par exemple, pour supprimer la configuration du vérificateur de santé du NodeManager disque YARN de l'exemple précédent, soumettez-en une nouvelle `instanceGroups.json` avec le contenu suivant. ``` [ { "InstanceGroupId":"", "Configurations":[ { "Classification":"yarn-site", "Properties":{ "yarn.nodemanager.vmem-check-enabled":"true", "yarn.nodemanager.vmem-pmem-ratio":"3.0" }, "Configurations":[] } ] } ] ``` Pour supprimer toutes les configurations de votre dernière demande de reconfiguration, soumettez une demande de reconfiguration avec un ensemble de configurations vide. Par exemple, ``` [ { "InstanceGroupId":"", "Configurations":[] } ] ``` **Example – Reconfigurez et redimensionnez un groupe d'instances en une seule demande** L'exemple JSON suivant montre comment reconfigurer et redimensionner un groupe d'instances dans la même demande. ``` [ { "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" } } ] } ] ``` ## Reconfigurer un groupe d'instances à l'aide du SDK Java **Note** Dans les exemples suivants, remplacez ** par votre ID de cluster et remplacez ** par votre ID de groupe d'instances. L'extrait de code suivant fournit une nouvelle configuration pour un groupe d'instances utilisant AWS SDK pour 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); ``` L'extrait de code suivant supprime une configuration précédemment spécifiée pour un groupe d'instances en fournissant un tableau vide de configurations. ``` List configurations = new ArrayList(); InstanceGroupModifyConfig igConfig = new InstanceGroupModifyConfig() .withInstanceGroupId("") .withConfigurations(configurations); ModifyInstanceGroupsRequest migRequest = new ModifyInstanceGroupsRequest() .withClusterId("") .withInstanceGroups(igConfig); emr.modifyInstanceGroups(migRequest); ``` ## Résoudre les problèmes de reconfiguration des groupes d'instances Si le processus de reconfiguration d'un groupe d'instances échoue, Amazon EMR annule la reconfiguration et enregistre un message d'échec à l'aide d'un événement Amazon. CloudWatch L'événement fournit un bref résumé de l'échec de la reconfiguration. Il répertorie les instances pour lesquelles la reconfiguration a échoué et les messages d'échec correspondants. Voici un exemple de message d'échec. ``` 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". ``` Pour recueillir davantage de données sur un échec de reconfiguration, vous pouvez consulter les journaux de provisionnement des nœuds. Cela est particulièrement utile lorsque vous recevez un message comme celui-ci. ``` i-xxxxxxx1 failed with message “Unable to complete transaction and some changes were applied.” ``` ------ #### [ On the node ] **Pour accéder aux journaux de provisionnement des nœuds en vous connectant à un nœud** 1. Utilisez SSH pour vous connecter au nœud sur lequel la reconfiguration a échoué. Pour obtenir des instructions, consultez la section [Connexion à votre instance Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html) dans le *Guide de l'utilisateur* *Amazon EC2 pour les instances Linux*. 1. Accédez au répertoire suivant, qui contient les fichiers journaux de provisionnement des nœuds. ``` /mnt/var/log/provision-node/ ``` 1. Ouvrez le sous-répertoire `reports` et recherchez le rapport de provisionnement des nœuds pour votre reconfiguration. Le répertoire `reports` organise les journaux par numéro de version de reconfiguration, identifiant unique universel (UUID), adresse IP de l'instance Amazon EC2 et horodatage. Chaque rapport est un fichier YAML compressé qui contient des informations détaillées sur le processus de reconfiguration. Vous trouverez ci-dessous un exemple de nom de fichier et de chemin d'accès. ``` /reports/2/ca598xxx-cxxx-4xxx-bxxx-6dbxxxxxxxxx/ip-10-73-xxx-xxx.ec2.internal/202104061715.yaml.gz ``` 1. Vous pouvez examiner un rapport à l'aide d'un visualiseur de fichiers tel que `zless`, comme dans l'exemple suivant. ``` zless 202104061715.yaml.gz ``` ------ #### [ Amazon S3 ] **Pour accéder aux journaux de provisionnement des nœuds à l'aide d'Amazon S3** 1. Connectez-vous à la console Amazon S3 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/). 1. Ouvrez le compartiment Amazon S3 que vous avez spécifié lorsque vous avez configuré le cluster pour archiver les fichiers journaux. 1. Accédez au dossier suivant, qui contient les fichiers journaux de provisionnement des nœuds : ``` amzn-s3-demo-bucket/elasticmapreduce//node//provision-node/ ``` 1. Ouvrez le dossier `reports` et recherchez le rapport de provisionnement des nœuds pour votre reconfiguration. Le dossier `reports` organise les journaux par numéro de version de reconfiguration, identifiant unique universel (UUID), adresse IP de l'instance Amazon EC2 et horodatage. Chaque rapport est un fichier YAML compressé qui contient des informations détaillées sur le processus de reconfiguration. Vous trouverez ci-dessous un exemple de nom de fichier et de chemin d'accès. ``` /reports/2/ca598xxx-cxxx-4xxx-bxxx-6dbxxxxxxxxx/ip-10-73-xxx-xxx.ec2.internal/202104061715.yaml.gz ``` 1. Pour consulter un fichier journal, vous pouvez le télécharger depuis Amazon S3 sur votre machine locale sous forme de fichier texte. Pour obtenir des instructions, consultez la section [Téléchargement d'un objet](https://docs.aws.amazon.com/AmazonS3/latest/userguide/download-objects.html). ------ Chaque fichier journal contient un rapport de provisionnement détaillé pour la reconfiguration associée. Pour trouver les informations relatives aux messages d'erreur, vous pouvez rechercher le niveau de journalisation `err` d'un rapport. Le format du rapport dépend de la version d'Amazon EMR de votre cluster. L'exemple suivant montre les informations d'erreur pour les versions d'Amazon EMR antérieures aux versions 5.32.0 et 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 ``` Les versions 5.32.0 et 6.2.0 et ultérieures d'Amazon EMR utilisent plutôt le format suivant. ``` - level: err message: 'Example detailed error message.' source: Puppet tags: - err time: '2021-01-01 00:00:00.000000 +00:00' file: line: ``` # Stockez les données de configuration sensibles dans AWS Secrets Manager Amazon EMR décrit et répertorie les opérations d'API qui émettent des données de configuration personnalisées (telles que `DescribeCluster` et `ListInstanceGroups`) en texte clair. Amazon EMR s'intègre AWS Secrets Manager afin que vous puissiez stocker vos données dans Secrets Manager et utiliser l'ARN secret dans vos configurations. Ainsi, vous ne transmettez pas de données de configuration sensibles à Amazon EMR en texte brut et ne les exposez pas à des données externes. APIs Si vous indiquez qu'une paire clé-valeur contient un ARN pour un secret stocké dans Secrets Manager, Amazon EMR récupère ce secret lorsqu'il envoie les données de configuration au cluster. Amazon EMR n'envoie pas l'annotation lorsqu'il utilise un outil externe APIs pour afficher la configuration. ## Créer un secret Pour créer un secret, suivez les étapes de la section [Création d'un secret AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) dans le *Guide de l'utilisateur AWS Secrets Manager *. Dans l'**étape 3**, vous devez choisir le champ de **texte en clair** pour saisir votre valeur sensible. Notez que si Secrets Manager autorise un secret à contenir jusqu'à 65 536 octets, Amazon EMR limite la longueur combinée de la clé de propriété (à l'exception de l'annotation) et de la valeur secrète récupérée à 1024 caractères. ## Accordez à Amazon EMR l'accès pour récupérer le secret Amazon EMR utilise un rôle de service IAM pour provisionner et gérer des clusters à votre place. Le rôle de service pour Amazon EMR définit les actions autorisées pour Amazon EMR lorsqu'il alloue des ressources et exécute des tâches de niveau service qui ne sont pas effectuées dans le contexte d'une instance Amazon EC2 exécutée au sein d'un cluster. Pour plus d'informations sur les rôles de service, consultez [Rôle de service pour Amazon EMR (rôle EMR)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-iam-role.html) et [Personnaliser les rôles IAM](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-iam-roles-custom.html). Pour permettre à Amazon EMR de récupérer la valeur secrète depuis Secrets Manager, ajoutez la déclaration de politique suivante à votre rôle Amazon EMR lorsque vous lancez votre cluster. ``` { "Sid":"AllowSecretsRetrieval", "Effect":"Allow", "Action":"secretsmanager:GetSecretValue", "Resource":[ "arn:aws:secretsmanager:::secret:" ] } ``` Si vous créez le secret avec une clé gérée par le client AWS KMS key, vous devez également ajouter une `kms:Decrypt` autorisation au rôle Amazon EMR pour la clé que vous utilisez. Pour plus d'informations, consultez [Authentification et contrôle d'accès pour AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access.html) dans le *Guide de l'utilisateur AWS Secrets Manager *. ## Utiliser le secret dans une classification de configuration Vous pouvez ajouter l'annotation `EMR.secret@` à n'importe quelle propriété de configuration pour indiquer que sa paire clé-valeur contient un ARN pour un secret stocké dans Secrets Manager. L'exemple suivant montre comment fournir un ARN secret dans une classification de configuration : ``` { "Classification":"core-site", "Properties":{ "presto.s3.access-key":"", "EMR.secret@presto.s3.secret-key":"arn:aws:secretsmanager:::secret:" } } ``` Lorsque vous créez votre cluster et soumettez votre configuration annotée, Amazon EMR valide les propriétés de configuration. Si votre configuration est valide, Amazon EMR supprime l'annotation de la configuration et récupère le secret auprès de Secrets Manager pour créer la configuration réelle avant de l'appliquer au cluster : ``` { "Classification":"core-site", "Properties":{ "presto.s3.access-key":"", "presto.s3.secret-key":"" } } ``` Lorsque vous appelez une action telle que `DescribeCluster`, Amazon EMR renvoie la configuration actuelle de l'application sur le cluster. Si une propriété de configuration d'application est marquée comme contenant un ARN secret, la configuration d'application renvoyée par l'appel `DescribeCluster` contient l'ARN et non la valeur secrète. Cela garantit que la valeur secrète n'est visible que sur le cluster : ``` { "Classification":"core-site", "Properties":{ "presto.s3.access-key":"", "presto.s3.secret-key":"arn:aws:secretsmanager:::secret:" } } ``` ## Mettre à jour la valeur d'un secret Amazon EMR récupère la valeur secrète d'une configuration annotée chaque fois que le groupe d'instances attaché démarre, se reconfigure ou se redimensionne. Vous pouvez utiliser Secrets Manager pour modifier la valeur d'un secret utilisé dans la configuration d'un cluster en cours d'exécution. Dans ce cas, vous pouvez envoyer une demande de reconfiguration à chaque groupe d'instances pour lequel vous souhaitez recevoir la valeur mise à jour. Pour plus d'informations sur la façon de reconfigurer un groupe d'instances et sur les éléments à prendre en compte lorsque vous le faites, consultez [Reconfigurer un groupe d'instances dans un cluster en cours d'exécution](emr-configure-apps-running-cluster.md). # Configuration des applications pour l'utilisation d'une machine virtuelle Java spécifique Les versions d'Amazon EMR comportent différentes versions de machine virtuelle Java (JVM) par défaut. Cette page explique la prise en charge de la JVM pour différentes versions et applications. ## Considérations Pour plus d’informations sur les versions de Java prises en charge pour les applications, voir les pages relatives aux applications du [Guide des versions d’Amazon EMR](emr-release-components.md). + Amazon EMR ne prend en charge que l’exécution d’une seule version d’exécution dans un cluster et ne prend pas en charge l’exécution de différents nœuds ou applications sur différentes versions d’exécution sur le même cluster. + Pour les versions 7.x d’Amazon EMR, la machine virtuelle Java (JVM) par défaut est Java 17 pour les applications compatibles avec Java 17, à l’exception d’Apache Livy. Pour plus d’informations sur les versions de JDK prises en charge pour les applications, voir les pages dédiées du Guide des versions d’Amazon EMR. + À partir d'Amazon EMR 7.1.0, Flink prend en charge Java 17 et est configuré sur Java 17 par défaut. Pour utiliser une version différente de l'environnement d'exécution Java, remplacez les paramètres définis dans`flink-conf`. Pour plus d'informations sur la configuration de Flink pour utiliser Java 8 ou Java 11, voir [Configurer Flink pour fonctionner avec Java](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/flink-configure.html#flink-configure-java11) 11. + Pour les versions 5.x et 6.x d’Amazon EMR, la machine virtuelle Java (JVM) par défaut est Java 8. + Pour les versions 6.12.0 et supérieures d'Amazon EMR, certaines applications prennent également en charge Java 11 et 17. + Pour les versions 6.9.0 et supérieures d'Amazon EMR, Trino prend en charge Java 17 par défaut. Pour plus d'informations sur Java 17 avec Trino, consultez [Trino updates to Java 17](https://trino.io/blog/2022/07/14/trino-updates-to-java-17.html) sur le blog de Trino. Tenez compte des considérations spécifiques à l'application suivantes lorsque vous choisissez votre version d'exécution : **Remarques de configuration Java spécifiques à l'application** | Application | Notes sur la configuration de Java | | --- | --- | | Spark | Pour exécuter Spark avec une version de Java autre que celle par défaut, vous devez configurer à la fois Spark et Hadoop. Pour obtenir des exemples, consultez [Remplacer la JVM](#configuring-java8-override). [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/configuring-java8.html) | | Spark RAPIDS | Vous pouvez exécuter RAPIDS avec la version Java configurée pour Spark. | | Iceberg | Vous pouvez exécuter Iceberg avec la version Java configurée de l'application qui l'utilise. | | Delta | Vous pouvez exécuter Delta avec la version Java configurée de l'application qui l'utilise. | | Hudi | Vous pouvez exécuter Hudi avec la version Java configurée de l'application qui l'utilise. | | Hadoop | Pour mettre à jour la JVM pour Flink, modifiez `hadoop-env`. Pour obtenir des exemples, consultez [Remplacer la JVM](#configuring-java8-override). | | Hive | Pour définir la version Java sur 11 ou 17 pour Hive, configurez le paramètre JVM Hadoop sur la version Java que vous souhaitez utiliser. | | HBase | Pour mettre à jour la JVM pour HBase, modifiez`hbase-env`. Par défaut, Amazon EMR définit la HBase JVM en fonction de la configuration JVM pour Hadoop, sauf si vous remplacez les paramètres dans. `hbase-env` Pour obtenir des exemples, consultez [Remplacer la JVM](#configuring-java8-override). | | Flink | Pour mettre à jour la JVM pour Flink, modifiez `flink-conf`. Par défaut, Amazon EMR définit la JVM Flink en fonction de la configuration JVM pour Hadoop, sauf si vous remplacez les paramètres dans `flink-conf`. Pour de plus amples informations, veuillez consulter [Configurer Flink pour qu'il fonctionne avec Java 11](flink-configure.md#flink-configure-java11). | | Oozie | Pour configurer Oozie pour qu'il fonctionne sur Java 11 ou 17, configurez Oozie Server, le Oozie LauncherAM Launcher AM et modifiez les configurations de vos exécutables et tâches côté client. Vous pouvez également configurer `EmbeddedOozieServer` pour l'exécuter sur Java 17. Pour de plus amples informations, veuillez consulter [Configurer la version Java pour Oozie](oozie-java.md). | | Pig | Pig ne supporte que Java 8. Vous ne pouvez pas utiliser Java 11 ou 17 avec Hadoop et exécuter Pig sur le même cluster. | ## Remplacer la JVM Pour remplacer le paramètre JVM d'une version d'Amazon EMR (par exemple, pour utiliser Java 17 avec un cluster utilisant Amazon EMR version 6.12.0), entrez le paramètre `JAVA_HOME` correspondant à sa classification d'environnement, qui est `application-env` pour toutes les applications sauf Flink. Pour Flink, la classification de l'environnement est `flink-conf`. Pour connaître les étapes de configuration de l'environnement d'exécution Java avec Flink, consultez [Configurer Flink pour qu'il fonctionne avec Java 11](flink-configure.md#flink-configure-java11). **Topics** + [Remplacer le paramètre JVM par Apache Spark](#configuring-java8-override-spark) + [Remplacer le paramètre JVM par Apache HBase](#configuring-java8-override-hbase) + [Remplacez le paramètre JVM par Apache Hadoop et Hive](#configuring-java8-override-hadoop) ### Remplacer le paramètre JVM par Apache Spark Lorsque vous utilisez Spark avec Amazon EMR versions 6.12 et supérieures, vous pouvez configurer l'environnement de telle sorte que les exécuteurs utilisent Java 11 ou 17. Et lorsque vous utilisez Spark avec des versions d'Amazon EMR inférieures à 5.x et que vous écrivez un pilote à soumettre en mode cluster, le pilote utilise Java 7. Vous pouvez toutefois configurer l'environnement de manière à ce que les exécuteurs utilisent Java 8. Pour remplacer la JVM pour Spark, définissez le paramètre de classification Spark. Dans cet exemple, la version de Java pour Hadoop est la même, mais cela n'est pas obligatoire. ``` [ { "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": {} } ] ``` Notez qu'il est recommandé pour Hadoop sur Amazon EMR que la version de la JVM soit cohérente entre tous les composants Hadoop. L'exemple suivant montre comment ajouter les paramètres de configuration requis pour EMR 7.0.0\$1 afin de garantir une utilisation cohérente de la version Java sur tous les composants. ``` [ { "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": {} } ] ``` ### Remplacer le paramètre JVM par Apache HBase Pour configurer HBase pour utiliser Java 11, vous pouvez définir la configuration suivante lorsque vous lancez le cluster. ``` [ { "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": [] } ] } ] ``` ### Remplacez le paramètre JVM par Apache Hadoop et Hive L'exemple suivant montre comment configurer la JVM sur la version 17 pour Hadoop et Hive. ``` [ { "Classification": "hadoop-env", "Configurations": [ { "Classification": "export", "Configurations": [], "Properties": { "JAVA_HOME": "/usr/lib/jvm/jre-17" } } ], "Properties": {} } ] ``` ## Ports de service Les éléments suivants sont des ports de service YARN et HDFS. Ces paramètres reflètent les valeurs par défaut de Hadoop. D'autres services d'applications sont hébergés sur les ports par défaut, sauf indication contraire. Pour de plus amples informations, veuillez consulter la documentation du projet de l'application. **Paramètres de port pour YARN and HDFS** | Paramètre | Nom d'hôte/Port | | --- | --- | | `fs.default.name` | par défaut (`hdfs://emrDeterminedIP:8020`) | | `dfs.datanode.address` | par défaut (`0.0.0.0:50010`) | | `dfs.datanode.http.address` | par défaut (`0.0.0.0:50075`) | | `dfs.datanode.https.address` | par défaut (`0.0.0.0:50475`) | | `dfs.datanode.ipc.address` | par défaut (`0.0.0.0:50020`) | | `dfs.http.address` | par défaut (`0.0.0.0:50070`) | | `dfs.https.address` | par défaut (`0.0.0.0:50470`) | | `dfs.secondary.http.address` | par défaut (`0.0.0.0:50090`) | | `yarn.nodemanager.address` | par défaut (`${yarn.nodemanager.hostname}:0`) | | `yarn.nodemanager.localizer.address` | par défaut (`${yarn.nodemanager.hostname}:8040`) | | `yarn.nodemanager.webapp.address` | par défaut (`${yarn.nodemanager.hostname}:8042`) | | `yarn.resourcemanager.address` | par défaut (`${yarn.resourcemanager.hostname}:8032`) | | `yarn.resourcemanager.admin.address` | par défaut (`${yarn.resourcemanager.hostname}:8033`) | | `yarn.resourcemanager.resource-tracker.address` | par défaut (`${yarn.resourcemanager.hostname}:8031`) | | `yarn.resourcemanager.scheduler.address` | par défaut (`${yarn.resourcemanager.hostname}:8030`) | | `yarn.resourcemanager.webapp.address` | par défaut (`${yarn.resourcemanager.hostname}:8088`) | | `yarn.web-proxy.address` | par défaut (`no-value`) | | `yarn.resourcemanager.hostname` | `emrDeterminedIP` | **Note** Le terme *emrDeterminedIP* est une adresse IP générée par le plan de contrôle Amazon EMR. Dans la version la plus récente, cette convention a été supprimée, sauf pour les paramètres `yarn.resourcemanager.hostname` et `fs.default.name`. ## Utilisateurs de l'application Les applications exécutent des processus comme s’il s’agissait de leur propre utilisateur. Par exemple, Hive JVMs s'exécute en tant qu'utilisateur`hive`, MapReduce JVMs exécute en tant qu'utilisateur`mapred`, etc. Ceci est illustré dans l'exemple d'état des processus suivant. ``` 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 ```