Vermeiden Sie dhclient-script auf Amazon Linux Ami

538
Thomas Kettenbach

Wir verwenden emr cluster auf amazon Webservices 'aws'. Wir verwenden standardmäßig 'Amazon Linux AMI' Images ohne Anpassung. Es scheint mir, dass das Dhclient-Skript Konfigurationen von unseren Firmen abruft, dhcp (dynamisches Hostkonfigurationsprotokoll), insbesondere ntp (Netzwerkzeitprotokoll).

Als Beispiel für den Master-Knoten hängt das dhclient-script unsere ntp-Server des Unternehmens an die /etc/ntp.confDatei an.

[hadoop@ip-10-5-21-157 ~]$ grep ^server /etc/ntp.conf  server 0.amazon.pool.ntp.org iburst server 1.amazon.pool.ntp.org iburst server 2.amazon.pool.ntp.org iburst server 3.amazon.pool.ntp.org iburst server 10.2.78.21 # added by /sbin/dhclient-script server 10.2.78.22 # added by /sbin/dhclient-script server 10.2.78.23 # added by /sbin/dhclient-script server 10.2.78.24 # added by /sbin/dhclient-script

Die IP-Adressen 10.2.78.21-24 werden in aufgelöst clockNN.ntp.mycompany.com

Wie kann dies vermieden werden, so dass wir einfach die Standardeinstellungen von Amazon verwenden?

BEARBEITUNG Wir hatten Probleme beim Ausführen einer Schweine-Aggregation in einem Emr-Cluster. Ein Beispiel für eine Stacktrace-Ausnahme ist:

18/01/07 13:50:23 INFO tez.TezJob: DAG Status: status=FAILED, progress=TotalTasks: 4737 Succeeded: 3777 Running: 0 Failed: 1 Killed: 959 FailedTaskAttempts: 428 KilledTaskAttempts: 309, diagnostics=Vertex failed, vertexName=scope-421, vertexId=vertex_1515326570070_0001_1_04, diagnostics=[Task failed, taskId=task_1515326570070_0001_1_04_002846, diagnostics=[TaskAttempt 0 failed, info=[Container launch failed for container_1515326570070_0001_01_000599 : org.apache.hadoop.yarn.exceptions.YarnException: Unauthorized request to start container. This token is expired. current time is 1515332813920 found 1515330236564 Note: System times on machines may be out of sync. Check system time and time zones. at sun.reflect.GeneratedConstructorAccessor51.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.apache.hadoop.yarn.api.records.impl.pb.SerializedExceptionPBImpl.instantiateException(SerializedExceptionPBImpl.java:168) at org.apache.hadoop.yarn.api.records.impl.pb.SerializedExceptionPBImpl.deSerialize(SerializedExceptionPBImpl.java:106) at org.apache.tez.dag.app.launcher.TezContainerLauncherImpl$Container.launch(TezContainerLauncherImpl.java:160) at org.apache.tez.dag.app.launcher.TezContainerLauncherImpl$EventProcessor.run(TezContainerLauncherImpl.java:353) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)

Eine der Hauptursachen für (einige) der emr-Maschinen (VMs, Images, Nodes?), Um die Systemzeit abzuschalten, könnten die DNS-Server unseres Unternehmens gewesen sein. (Aber das ist eine wilde Vermutung.) Um diese Möglichkeit zu entfernen, müssen Sie die NTTP-Server aus der Datei /etc/ntp.conf entfernen und die Systemzeiten neu initialisieren.

0

1 Antwort auf die Frage

0
Thomas Kettenbach

Nach einigen Nachforschungen kam ich auf folgendes:

Erstellte Datei modify_ntp_config.shauf S3:

#!/bin/bash  set -eEu  ntp_config_file="$" echo "Removing 'server 10.*' entries from \"$ntp_config_file\"" sudo sed -i -e '/server 10.*/d' $ntp_config_file echo "Reinitialize ntp" sudo service ntpd stop sudo ntpdate -s time.nist.gov sudo service ntpd start

Kopiere diese Datei nach s3:

$ aws s3 cp /var/tmp/modify_ntp_config.sh \ s3://<s3-bucket-name>/data/scripts/modify_ntp_config.sh

Und dann mit aws-tools:

aws emr create-cluster --name "..." [...cluster create options ...] \ --steps \ Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\ Jar=s3://<region>.elasticmapreduce/libs/script-runner/script-runner.jar,\ Args=["s3://<s3-bucket-name>/data/scripts/modify_ntp_config.sh","/etc/ntp.conf"]

Ergebnisse in der folgenden Protokollausgabe (von s3 nach localdisk kopiert)

$ aws s3 cp --recursive s3://<s3-bucket-name>/log/<cluster-id>/steps/<step-id>/ /var/tmp/5HKO7 download: s3://[...]/stdout.gz to ../../var/tmp/5HKO7/stdout.gz download: s3://[...]/stderr.gz to ../../var/tmp/5HKO7/stderr.gz download: s3://[...]/controller.gz to ../../var/tmp/5HKO7/controller.gz  $ zcat /var/tmp/5HKO7/stdout.gz  Downloading 's3://<s3-bucket-name>/data/scripts/modify_ntp_config.sh' to '/mnt/var/lib/hadoop/steps/[...]/.' Removing 'server 10.*' entries from "/etc/ntp.conf" Reinitialize ntp Shutting down ntpd: [ OK ] Starting ntpd: [ OK ]  $ zcat /var/tmp/5HKO7/stderr.gz  Command exiting with ret '0'

ANMERKUNG: Eine andere Möglichkeit wäre die Verwendung des EMR-Clusters mit aws emr add-steps.

$ aws emr add-steps --cluster-id "j-<emr_cluster_id>"\ --steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\ Jar=s3://<region>.elasticmapreduce/libs/script-runner/script-runner.jar,\ Args=["s3://<s3-bucket-name>/data/scripts/modify_ntp_config.sh","/etc/ntp.conf"]

Referenzen: https://docs.aws.amazon.com/emr/latest/DeveloperGuide//emr-hadoop-script.html https://docs.aws.amazon.com/cli/latest/reference/emr/add- steps.html https://askubuntu.com/questions/254826/how-to-force-a-clock-update-using-ntp https://unix.stackexchange.com/questions/158802/how-to-update- ntp-without-the-ntp-daemon heruntergefahren

Verwandte Probleme