Amazon ParallelCluster 故障排除 - Amazon ParallelCluster
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

Amazon ParallelCluster 故障排除

这些区域有:Amazon ParallelCluster社区维护着一个 Wiki 页面,其中提供了许多故障排除技巧Amazon ParallelCluster GitHub 维基. 有关已知问题的列表,请参见已知问题.

检索和保存日志

Amazon ParallelCluster为创建 EC2 指标 HeadNode 以及计算实例和存储。您可以在中查看指标 CloudWatch 控制台自定义控制面板.Amazon ParallelCluster还创建集群 CloudWatch 日志组中的日志流。您可以在中查看这些日志 CloudWatch 控制台自定义控制面板要么日志组. 这些区域有:监控集群配置部分介绍如何修改集群 CloudWatch日志和仪表板。有关更多信息,请参阅 与 Amazon 集成 CloudWatch 日志亚马逊 CloudWatch 仪表板

日志是解决问题的有用资源。例如,如果您想删除故障集群,则首先创建集群日志的存档可能会很有用。按中的步骤操作存档日志创建存档。

集群日志在中不可用 CloudWatch

如果集群日志在中不可用 CloudWatch,请检查以确保你没有覆盖Amazon ParallelCluster CloudWatch 向配置中添加自定义日志时的日志配置。

将自定义日志添加到 CloudWatch 配置,请确保向配置中添加内容,而不是提取并覆盖配置。有关以下内容的更多信息fetch-configappend-config,请参阅多种 CloudWatch 代理配置文件在里面CloudWatch 用户指南.

要还原的Amazon ParallelCluster CloudWatch 日志配置您可以在Amazon ParallelClusternode。

$ /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json -s

存档日志

您可以将日志存档在 S3 或本地文件中(取决于--output-file参数)。

注意

您必须添加到 Amazon S3 存储桶策略中的权限才能授予 CloudWatch 访问。有关更多信息,请参阅设置 Amazon S3 存储桶上的权限在里面CloudWatch 日志用户指南.

$ pcluster export-cluster-logs --cluster-name mycluster --region eu-west-1 \ --bucket bucketname --bucket-prefix logs { "url": "https://bucketname.s3.eu-west-1.amazonaws.com/export-log/mycluster-logs-202109071136.tar.gz?..." } # use the --output-file parameter to save the logs locally $ pcluster export-cluster-logs --cluster-name mycluster --region eu-west-1 \ --bucket bucketname --bucket-prefix logs --output-file /tmp/archive.tar.gz { "path": "/tmp/archive.tar.gz" }

档案中包含亚马逊 CloudWatch 记录直播和Amazon CloudFormation堆栈过去 14 天来自头节点和计算节点的事件,除非在配置或参数中明确指定export-cluster-logs命令。完成命令所需的时间取决于集群中的节点数和中可用的日志流数 CloudWatch 日志。有关可用日志流的更多信息,请参阅与 Amazon 集成 CloudWatch 日志.

已保存的日志

从 3.0.0 开始,Amazon ParallelCluster拯救 CloudWatch 默认情况下,删除集群时会记录日志。如果您想删除集群并保留其日志,请确保Monitoring/Logs/CloudWatch/DeletionPolicy未设置为Delete在群集配置中。否则,将此字段的值更改为Retain然后运行pcluster update-cluster命令。然后,运行pcluster delete-cluster --cluster-name <cluster_name>删除集群但保留存储在 Amazon 中的日志组 CloudWatch.

已终止的节点日志

如果计算节点在启动后自行终止,并且其中没有任何计算节点日志 CloudWatch,提交触发集群扩展操作的任务。等待实例失败并检索实例控制台日志。

登录到集群头节点并获取计算节点instance-id来自 的/var/log/parallelcluster/slurm_resume.logfile。

使用以下命令检索实例控制台日志。

aws ec2 get-console-output --instance-id i-abcdef01234567890

当计算节点日志不可用时,控制台输出日志可以帮助你调试计算节点故障的根本原因。

排集群部署问题

如果您的集群无法创建并回滚堆栈创建,则可以查看日志文件以诊断问题。失败消息可能看起来像以下输出:

$ pcluster create-cluster --cluster-name mycluster --region eu-west-1 \ --cluster-configuration cluster-config.yaml { "cluster": { "clusterName": "mycluster", "cloudformationStackStatus": "CREATE_IN_PROGRESS", "cloudformationStackArn": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f01-11ec-a3b9-024fcc6f3387", "region": "eu-west-1", "version": "3.2.1", "clusterStatus": "CREATE_IN_PROGRESS" } } $ pcluster describe-cluster --cluster-name mycluster --region eu-west-1 { "creationTime": "2021-09-06T11:03:47.696Z", ... "cloudFormationStackStatus": "ROLLBACK_IN_PROGRESS", "clusterName": "mycluster", "computeFleetStatus": "UNKNOWN", "cloudformationStackArn": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f01-11ec-a3b9-024fcc6f3387", "lastUpdatedTime": "2021-09-06T11:03:47.696Z", "region": "eu-west-1", "clusterStatus": "CREATE_FAILED" }

查看Amazon CloudFormation活动开启CREATE_FAILED

您可以使用控制台或Amazon ParallelCluster要查看的 CLI CloudFormation 活动开启CREATE_FAILED错误以帮助找到根本原因。

在中查看事件 CloudFormation 控制台

要查看有关原因的更多信息"CREATE_FAILED"状态,你可以使用 CloudFormation 控制台。

查看 CloudFormation 控制台中的错误消息。

  1. 登录到Amazon Web Services Management Console并导航到https://console.aws.amazon.com/cloudformation.

  2. 选择名为的堆栈集群名称.

  3. 选择事件选项卡。

  4. 检查状态通过滚动浏览资源事件列表来查找创建失败的资源逻辑 ID. 如果子任务创建失败,请向后查找失败的资源事件。

  5. 例如,如果您看到以下状态消息,则必须使用不会超过当前 vCPU 限制或请求更多 vCPU 容量的实例类型。

    2022-02-04 16:09:44 UTC-0800 HeadNode CREATE_FAILED You have requested more vCPU capacity than your current vCPU limit of 0 allows for the instance bucket that the specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit. (Service: AmazonEC2; Status Code: 400; Error Code: VcpuLimitExceeded; Request ID: a9876543-b321-c765-d432-dcba98766789; Proxy: null).

使用 CLI 查看和筛选 CloudFormation 活动开启CREATE_FAILED

要诊断集群创建问题,您可以使用pcluster get-cluster-stack-events命令,通过筛选CREATE_FAILED状态。有关更多信息,请参阅过滤Amazon CLI输出在里面Amazon Command Line Interface用户指南.

$ pcluster get-cluster-stack-events --cluster-name mycluster --region eu-west-1 \ --query 'events[?resourceStatus==`CREATE_FAILED`]' [ { "eventId": "3ccdedd0-0f03-11ec-8c06-02c352fe2ef9", "physicalResourceId": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f02-11ec-a3b9-024fcc6f3387", "resourceStatus": "CREATE_FAILED", "resourceStatusReason": "The following resource(s) failed to create: [HeadNode]. ", "stackId": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f02-11ec-a3b9-024fcc6f3387", "stackName": "mycluster", "logicalResourceId": "mycluster", "resourceType": "AWS::CloudFormation::Stack", "timestamp": "2021-09-06T11:11:51.780Z" }, { "eventId": "HeadNode-CREATE_FAILED-2021-09-06T11:11:50.127Z", "physicalResourceId": "i-04e91cc1f4ea796fe", "resourceStatus": "CREATE_FAILED", "resourceStatusReason": "Received FAILURE signal with UniqueId i-04e91cc1f4ea796fe", "resourceProperties": "{\"LaunchTemplate\":{\"Version\":\"1\",\"LaunchTemplateId\":\"lt-057d2b1e687f05a62\"}}", "stackId": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f02-11ec-a3b9-024fcc6f3387", "stackName": "mycluster", "logicalResourceId": "HeadNode", "resourceType": "AWS::EC2::Instance", "timestamp": "2021-09-06T11:11:50.127Z" } ]

在前面的示例中,故障出在头节点设置中。

使用 CLI 查看日志流

要调试此类问题,可以使用pcluster list-cluster-log-streams通过筛选node-type,然后分析日志流内容。

$ pcluster list-cluster-log-streams --cluster-name mycluster --region eu-west-1 \ --filters 'Name=node-type,Values=HeadNode' { "logStreams": [ { "logStreamArn": "arn:aws:logs:eu-west-1:xxx:log-group:/aws/parallelcluster/mycluster-202109061103:log-stream:ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init", "logStreamName": "ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init", ... }, { "logStreamArn": "arn:aws:logs:eu-west-1:xxx:log-group:/aws/parallelcluster/mycluster-202109061103:log-stream:ip-10-0-0-13.i-04e91cc1f4ea796fe.chef-client", "logStreamName": "ip-10-0-0-13.i-04e91cc1f4ea796fe.chef-client", ... }, { "logStreamArn": "arn:aws:logs:eu-west-1:xxx:log-group:/aws/parallelcluster/mycluster-202109061103:log-stream:ip-10-0-0-13.i-04e91cc1f4ea796fe.cloud-init", "logStreamName": "ip-10-0-0-13.i-04e91cc1f4ea796fe.cloud-init", ... }, ... ] }

您可以使用以下两个主要日志流来查明初始化错误:

  • cfn-init是的日志cfn-init脚本。首先检查此日志流。你可能会看到Command chef failed此日志中有错误。查看此行前面的行,了解与错误消息相关的更多细节。有关更多信息,请参阅cfn-init.

  • cloud-init是的日志cloud-init. 如果您没有在中看到任何内容cfn-init,然后尝试接下来查看此日志。

您可以使用以下方法检索日志流的内容pcluster get-cluster-log-events(注意--limit 5选项以限制检索到的事件数):

$ pcluster get-cluster-log-events --cluster-name mycluster \ --region eu-west-1 --log-stream-name ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init \ --limit 5 { "nextToken": "f/36370880979637159565202782352491087067973952362220945409/s", "prevToken": "b/36370880752972385367337528725601470541902663176996585497/s", "events": [ { "message": "2021-09-06 11:11:39,049 [ERROR] Unhandled exception during build: Command runpostinstall failed", "timestamp": "2021-09-06T11:11:39.049Z" }, { "message": "Traceback (most recent call last):\n File \"/opt/aws/bin/cfn-init\", line 176, in <module>\n worklog.build(metadata, configSets)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 135, in build\n Contractor(metadata).build(configSets, self)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 561, in build\n self.run_config(config, worklog)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 573, in run_config\n CloudFormationCarpenter(config, self._auth_config).build(worklog)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 273, in build\n self._config.commands)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/command_tool.py\", line 127, in apply\n raise ToolError(u\"Command %s failed\" % name)", "timestamp": "2021-09-06T11:11:39.049Z" }, { "message": "cfnbootstrap.construction_errors.ToolError: Command runpostinstall failed", "timestamp": "2021-09-06T11:11:39.049Z" }, { "message": "2021-09-06 11:11:49,212 [DEBUG] CloudFormation client initialized with endpoint https://cloudformation.eu-west-1.amazonaws.com", "timestamp": "2021-09-06T11:11:49.212Z" }, { "message": "2021-09-06 11:11:49,213 [DEBUG] Signaling resource HeadNode in stack mycluster with unique ID i-04e91cc1f4ea796fe and status FAILURE", "timestamp": "2021-09-06T11:11:49.213Z" } ] }

在上一个示例中,失败是由于runpostinstall失败,因此与在引导脚本中使用的自定义引导脚本的内容密切相关OnNodeConfigured的配置参数CustomActions.

使用以下命令重新创建失败的集群rollback-on-failure

Amazon ParallelCluster创建集群 CloudWatch 日志组中的日志流。您可以在中查看这些日志 CloudWatch 控制台自定义控制面板要么日志组. 有关更多信息,请参阅 与 Amazon 集成 CloudWatch 日志亚马逊 CloudWatch 仪表板。如果没有可用的日志流,则失败可能是由于CustomActions自定义引导脚本或 AMI 相关问题。要诊断这种情况下的创建问题,请使用再次创建集群pcluster create-cluster,包括--rollback-on-failure参数设置为false. 然后,通过 SSH 进入集群:

$ pcluster create-cluster --cluster-name mycluster --region eu-west-1 \ --cluster-configuration cluster-config.yaml --rollback-on-failure false { "cluster": { "clusterName": "mycluster", "cloudformationStackStatus": "CREATE_IN_PROGRESS", "cloudformationStackArn": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f01-11ec-a3b9-024fcc6f3387", "region": "eu-west-1", "version": "3.2.1", "clusterStatus": "CREATE_IN_PROGRESS" } } $ pcluster ssh --cluster-name mycluster

登录到头节点后,你应该找到三个主要的日志文件,你可以用它们来查明错误。

  • /var/log/cfn-init.log是的日志cfn-init脚本。首先检查这个日志。你可能会看到类似的错误Command chef failed在此日志中。查看此行前面的行,了解与错误消息相关的更多细节。有关更多信息,请参阅cfn-init.

  • /var/log/cloud-init.log是的日志cloud-init. 如果您没有在中看到任何内容cfn-init.log,然后尝试接下来查看此日志。

  • /var/log/cloud-init-output.log是运行的命令的输出cloud-init. 这包括来自的输出cfn-init. 在大多数情况下,您无需查看此日志即可解决此类问题。

排查扩展问题

本节与使用安装的集群相关Amazon ParallelCluster版本 3.0.0 及更高版本的 Slurm 作业调度程序。有关配置多个队列的更多信息,请参阅配置多个队列.

如果您的某个正在运行的集群出现问题,请将该集群置于STOPPED在开始进行故障排除之前,请运行以下命令进行状态。这样可以防止产生任何意想不到的费用。

$ pcluster update-compute-fleet --cluster-name mycluster \ --status STOP_REQUESTED

您可以使用以下方法列出群集节点上可用的日志流pcluster list-cluster-log-streams命令并使用private-dns-name其中一个故障节点或头节点。

$ pcluster list-cluster-log-streams --cluster-name mycluster --region eu-west-1 \ --filters 'Name=private-dns-name,Values=ip-10-0-0-101'

然后,您可以检索日志流的内容以进行分析,方法是使用pcluster get-cluster-log-events命令并传递--log-stream-name对应于下一节中提到的关键日志之一。

$ pcluster get-cluster-log-events --cluster-name mycluster \ --region eu-west-1 --log-stream-name ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init

Amazon ParallelCluster创建集群 CloudWatch 日志组中的日志流。您可以在中查看这些日志 CloudWatch 控制台自定义控制面板要么日志组. 有关更多信息,请参阅 与 Amazon 集成 CloudWatch 日志亚马逊 CloudWatch 仪表板

调试的关键日志

下表概述了头节点的关键日志:

  • /var/log/cfn-init.log-这是Amazon CloudFormation初始化日志。它包含在设置实例时运行的所有命令。它对于解决初始化问题很有用。

  • /var/log/chef-client.log-这是 Chef 客户端日志。它包含通过 Chef/Cinc 运行的所有命令。它对于解决初始化问题很有用。

  • /var/log/parallelcluster/slurm_resume.log-这是一个ResumeProgram日志。它为动态节点启动实例,可用于解决动态节点启动问题。

  • /var/log/parallelcluster/slurm_suspend.log-这是SuspendProgram日志。它在动态节点的实例终止时调用,对于解决动态节点终止问题很有用。当您查看此日志时,还应检查clustermgtd日志。

  • /var/log/parallelcluster/clustermgtd-这是clustermgtd日志。它作为管理大多数集群操作操作的集中守护程序运行。它对于解决任何启动、终止或集群操作问题非常有用。

  • /var/log/slurmctld.log-这是 Slurm 控制守护程序日志。Amazon ParallelCluster不做出扩展决策。相反,它只尝试启动资源来满足 Slurm 的要求。它对于扩展和分配问题、与作业相关的问题以及任何与调度程序相关的启动和终止问题非常有用。

以下是计算节点的关键日志:

  • /var/log/cloud-init-output.log-这是cloud-init日志。它包含在设置实例时运行的所有命令。它对于解决初始化问题很有用。

  • /var/log/parallelcluster/computemgtd-这是computemgtd日志。它在每个计算节点上运行,以在极少数情况下监视节点clustermgtd头节点上的后台程序处于脱机状态。它对于解决意外终止问题很有用。

  • /var/log/slurmd.log-这是 Slurm 计算守护程序日志。它对于解决初始化和计算故障相关问题很有用。

节点初始化问题疑难解答

本节介绍如何解决节点初始化问题。这包括节点无法启动、启动或加入群集的问题。

头节点

适用的日志:

  • /var/log/cfn-init.log

  • /var/log/chef-client.log

  • /var/log/parallelcluster/clustermgtd

  • /var/log/parallelcluster/slurm_resume.log

  • /var/log/slurmctld.log

检查/var/log/cfn-init.log/var/log/chef-client.log日志或相应的日志流。这些日志包含设置头节点时运行的所有操作。安装过程中出现的大多数错误都应将错误消息放在/var/log/chef-client.log日志。如果OnNodeStart要么OnNodeConfigured脚本是在群集的配置中指定的,请通过日志消息仔细检查脚本是否成功运行。

创建集群时,头节点必须等待计算节点加入集群后才能加入集群。因此,如果计算节点无法加入集群,则头节点也会失败。您可以按照其中一组过程操作,具体取决于您使用的计算笔记的类型,以解决此类问题:

计算节点

  • 适用的日志:

    • /var/log/cloud-init-output.log

    • /var/log/slurmd.log

  • 如果计算节点已启动,请先检查/var/log/cloud-init-output.log,其中应包含类似的安装日志/var/log/chef-client.log登录头节点。安装过程中出现的大多数错误都应将错误消息放在/var/log/cloud-init-output.log日志。如果在群集配置中指定了预安装或安装后脚本,请检查它们是否成功运行。

  • 如果您使用的是自定义 AMI 并修改为Slurm配置,那么可能有一个Slurm相关错误阻止计算节点加入集群。有关与调度程序相关的错误,请查看/var/log/slurmd.log日志。

动态计算节点:

  • 搜索ResumeProgram日志 (/var/log/parallelcluster/slurm_resume.log) 以获取计算节点名称,以查看是否ResumeProgram曾经用节点调用。(如果ResumeProgram从没打过电话,您可以查看slurmctld日志 (/var/log/slurmctld.log) 以确定 Slurm 是否曾经尝试过打电话ResumeProgram用节点)。

  • 请注意,的权限不正确ResumeProgram可能会导致ResumeProgram静默失败。如果您使用的是自定义 AMI 并修改为ResumeProgram设置,检查是否ResumeProgram归属于slurm用户,有744(rwxr--r--) 许可。

  • 如果ResumeProgram被调用,请检查是否为该节点启动了实例。如果未启动实例,则会看到一条描述启动失败的错误消息。

  • 如果实例已启动,则在安装过程中可能出现了问题。您应该可以从中看到相应的私有 IP 地址和实例 IDResumeProgram日志。此外,您可以查看特定实例的相应安装日志。有关计算节点设置错误故障的详细信息,请参阅下一节。

静态计算节点:

  • 检查clustermgtd(/var/log/parallelcluster/clustermgtd) 日志以查看是否已为该节点启动实例。如果它们没有启动,则应该有明确的错误消息,详细说明启动失败。

  • 如果启动实例,则在安装过程中会出现一些问题。您应该可以从中看到相应的私有 IP 地址和实例 IDResumeProgram日志。此外,您可以查看特定实例的相应安装日志。

由 Spot 实例支持的计算节点:

  • 如果这是您第一次使用竞价型实例,并且任务仍处于 PD(待处理状态),请仔细检查/var/log/parallelcluster/slurm_resume.logfile。您可能会发现类似如下内容的错误:

    2022-05-20 13:06:24,796 - [slurm_plugin.common:add_instances_for_nodes] - ERROR - Encountered exception when launching instances for nodes (x1) ['spot-dy-t2micro-2']: An error occurred (AuthFailure.ServiceLinkedRoleCreationNotPermitted) when calling the RunInstances operation: The provided credentials do not have permission to create the service-linked role for EC2 Spot Instances.

    在使用 Spot 实例时,AWSServiceRoleForEC2Spot您的账户中必须存在服务相关角色。要在您的账户中创建此角色,请使用Amazon CLI,运行以下命令:

    $ aws iam create-service-linked-role --aws-service-name spot.amazonaws.com

    有关更多信息,请参阅使用竞价型实例在里面Amazon ParallelCluster用户指南和竞价型实例请求的服务相关角色在里面适用于 Linus 实例的 Amazon EC2 用户指南.

排除意外节点更换和终止故障

本节继续探讨如何解决与节点相关的问题,特别是在节点被意外替换或终止时。

  • 适用的日志:

    • /var/log/parallelcluster/clustermgtd(头节点)

    • /var/log/slurmctld.log(头节点)

    • /var/log/parallelcluster/computemgtd(计算节点)

节点意外被替换或终止

  • 检查clustermgtd日志 (/var/log/parallelcluster/clustermgtd) 看看是否clustermgtd已采取措施替换或终止节点。请改进clustermgtd处理所有正常的节点维护操作。

  • 如果clustermgtd替换或终止了节点,应该有一条消息详细说明在该节点上采取此操作的原因。如果原因与调度器有关(例如,因为节点在DOWN),办理登机手续slurmctld登录以获取更多信息。如果原因与 Amazon EC2 有关,则应提供信息性消息,详细说明需要更换的 Amazon EC2 相关问题。

  • 如果clustermgtd没有终止节点,首先检查这是否是 Amazon EC2 的预期终止,更具体地说是现货终止。computemgtd,在 Compute 节点上运行,如果出现以下情况,也可以采取行动终止节点clustermgtd被确定为不健康。检查computemgtd日志 (/var/log/parallelcluster/computemgtd) 看看是否computemgtd终止了节点。

节点出现故障

  • 检查slurmctld日志 (/var/log/slurmctld.log)以查看任务或节点失败的原因。请注意,如果节点出现故障,作业会自动重新排队。

  • 如果slurm_resume报告节点已启动,clustermgtd几分钟后报告该节点在 Amazon EC2 中没有相应的实例,该节点可能在安装过程中出现故障。要从计算中检索日志 (/var/log/cloud-init-output.log),执行以下步骤:

    • 提交任务让Slurm启动新节点。

    • 节点启动后,使用此命令启用终止保护。

      $ aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --disable-api-termination
    • 使用此命令从节点检索控制台输出。

      $ aws ec2 get-console-output --instance-id i-1234567890abcdef0 --output text

替换、终止或关闭有问题的实例和节点

  • 适用的日志:

    • /var/log/parallelcluster/clustermgtd(头节点)

    • /var/log/parallelcluster/slurm_suspend.log(头节点)

  • 在大多数情况下,clustermgtd处理所有预期的实例终止操作。检查clustermgtd记录以查看为什么它无法替换或终止节点。

  • 对于出现故障的动态节点SlurmSettings属性,请在SuspendProgram登录看看是否SuspendProgram被打电话给slurmctld使用特定的节点作为参数。请改进SuspendProgram实际上不执行任何操作。相反,它只在被调用时才会记录。所有实例终止和NodeAddr重置由以下方式完成clustermgtd. Slurm 将节点放回到POWER_SAVING之后的状态SuspendTimeout自动。

  • 如果计算节点由于引导失败而持续出现故障,请使用以下命令验证它们是否正在启动Surm 集群保护模式已启用。如果未启用保护模式,请修改保护模式设置以启用保护模式。对引导脚本进行故障排除和修复。

队列(分区)Inactive状态

如果你跑sinfo输出显示队列中有AVAIL状态inact,你的集群可能有Surm 集群保护模式已启用,队列已设置为INACTIVE在预定义的时间段内保持状态。

对其他已知的节点和作业问题进行故障排除

另一种已知问题是Amazon ParallelCluster可能无法分配工作或做出扩展决策。对于这种类型的问题,Amazon ParallelCluster仅按照 Slurm 指令启动、终止或维护资源。有关这些问题,请查看slurmctld登录以排除故障。

置放式组和实例启动问题

要获得最低的节点间延迟,请使用置放群组. 置放群组可确保您的实例位于同一网络主干中。如果发出请求时没有足够的可用实例,InsufficientInstanceCapacity返回错误。要减少在使用集群置放群组时出现此错误的可能性,请将SlurmQueues/Networking/PlacementGroup/Enabled参数为false.

要进一步控制容量访问权限,请考虑使用 ODCR(按需容量预留)启动实例.

有关更多信息,请参阅排查实例启动问题置放群组、角色和限制在里面适用于 Linus 实例的 Amazon EC2 用户指南.

无法替换的目录

以下目录在节点之间共享,无法替换。

  • /home-这包括默认的用户主文件夹 (/home/ec2_user在Amazon Linux/home/centos在 CentOS 上,以及/home/ubuntu在 Ubuntu 上)。

  • /opt/intel-这包括英特尔 MPI、英特尔 Parallel Studio 和相关文件。

  • /opt/slurm-这包括 Slurm 工作负载管理器和相关文件。(有条件,仅当 Scheduler: slurm 时。)

排查 NICE DCV 中的问题

NICE DCV 的日志

NICE DCV 的日志写入到文件中/var/log/dcv/目录。查看这些日志有助于解决问题。

实例类型应至少有 1.7 千兆字节 (GiB) 的 RAM 才能运行 NICE DCV。纳米和微型实例类型没有足够的内存来运行 NICE DCV。

Amazon ParallelCluster在日志组中创建 NICE DCV 日志流。您可以在中查看这些日志 CloudWatch 控制台自定义控制面板要么日志组. 有关更多信息,请参阅 与 Amazon 集成 CloudWatch 日志亚马逊 CloudWatch 仪表板

Ubuntu NICE DCV 问题

在 Ubuntu 上通过 DCV 会话运行 Gnome Terminal 时,你可能无法自动访问以下用户环境Amazon ParallelCluster通过登录 shell 可用。用户环境提供 openmpi 或 intelmpi 等环境模块以及其他用户设置。

Gnome Terminal 的默认设置阻止外壳作为登录 shell 启动。这意味着外壳配置文件不是自动获取的,而且Amazon ParallelCluster用户环境未加载。

要正确获取 shell 配置文件并访问Amazon ParallelCluster用户环境,执行以下操作之一:

  • 更改原定设置终端设置:

    1. 选择编辑Gnome 终端中的菜单。

    2. SelectPreferences(首选项),那么配置文件.

    3. 选择命令然后select以登录 shell 的身份运行命令.

    4. 打开新终端。

  • 使用命令行获取可用的配置文件:

    $ source /etc/profile && source $HOME/.bashrc

排查集群中的问题Amazon Batch一体化

本节与以下群集相关Amazon Batch调度器集成。

头节点问题

可以用与头节点相同的方式解决与头节点相关的设置问题Slurm集群(除了Slurm特定日志)。有关这些问题的更多信息,请参阅头节点.

计算问题

Amazon Batch管理服务的扩展和计算方面。如果您遇到与计算相关的问题,请参阅Amazon Batch 故障排除提供帮助的文档。

Job 失败

如果作业失败,则可以运行awsbout命令来检索任务输出。您还可以运行awsbstat命令获取指向亚马逊存储的任务日志的链接 CloudWatch.

端点 URL 错误导致Connect 超时

如果多节点parallel 作业失败并出现错误:Connect timeout on endpoint URL

  • 在里面awsbout输出日志,检查作业是否与输出parallel 执行多节点:Detected 3/3 compute nodes. Waiting for all compute nodes to start.

  • 验证计算节点子网是否为公有子网。

多节点parallel 作业在使用时不支持使用公有子网Amazon Batch在Amazon ParallelCluster. 您必须为计算节点和任务使用私有子网。有关更多信息,请参阅计算环境注意事项在里面Amazon Batch用户指南. 要为您的计算节点配置私有子网,请参阅Amazon ParallelCluster和Amazon Batch计划程序.

排除多用户与 Active Director

本节与与 Active Directory (AD) 集成的集群有关。

如果 Active Directory (AD) 集成功能无法按预期运行,SSSD 日志可以提供有用的诊断信息。这些日志位于/var/log/sssd在集群节点上。默认情况下,它们也存储在集群的 Amazon 中 CloudWatch 日志组。

AD 特定故障排查

本节与特定于 AD 类型的故障排除有关。

Simple AD

  • 这些区域有:DomainReadOnlyUser值必须与用户的 Simple AD 目录基础搜索相匹配:

    cn=ReadOnlyUser,cn=Users,dc=corp,dc=pcluster,dc=com

    注意cn为了Users.

  • 默认管理员用户是Administrator.

  • Ldapsearch在用户名之前需要 Netbios 名称。

    Ldapsearch语法必须如下:

    $ ldapsearch -x -D "corp\\Administrator" -w "Password" -H ldap://192.0.2.103 \ -b "cn=Users,dc=corp,dc=pcluster,dc=com"

Amazon Managed Microsoft AD

  • 这些区域有:DomainReadOnlyUser值必须匹配Amazon Managed Microsoft AD搜索用户的目录库:

    cn=ReadOnlyUser,ou=Users,ou=CORP,dc=corp,dc=pcluster,dc=com

  • 默认管理员用户是Admin.

  • Ldapsearch语法必须如下:

    $ ldapsearch -x -D "Admin" -w "Password" -H ldap://192.0.2.103 \ -b "ou=Users,ou=CORP,dc=corp,dc=pcluster,dc=com"

启用调试模式

来自 SSSD 的调试日志可用于解决问题。要启用调试模式,必须使用对集群配置所做的以下更改来更新集群:

DirectoryService: AdditionalSssdConfigs: debug_level: "0x1ff"

如何从 LDAPS 迁移到 LDAP

不鼓励从 LDAPS(使用 TLS/SSL 的 LDAP)迁移到 LDAP,因为只有 LDAP 并不能提供任何加密。但是,它对于测试目的和故障排除可能很有用。

您可以使用以前的配置定义更新集群,将集群恢复到以前的配置。

要从 LDAPS 迁移到 LDAP,必须使用群集配置中的以下更改来更新群集:

DirectoryService: LdapTlsReqCert: never AdditionalSssdConfigs: ldap_auth_disable_tls_never_use_in_production: True

如何禁用 LDAPS 服务器证书验证

暂时禁用头节点上的 LDAPS 服务器证书验证可能很有用,用于测试或故障排除。

您可以使用以前的配置定义更新集群,将集群恢复到以前的配置。

要禁用 LDAPS 服务器证书验证,必须使用集群配置中的以下更改来更新集群:

DirectoryService: LdapTlsReqCert: never

如何使用 SSH 密钥而不是密码登录

SSH 密钥是在中创建的/home/$user/.ssh/id_rsa在你第一次使用密码登录之后。要使用 SSH 密钥登录,必须使用密码登录,将 SSH 密钥复制到本地,然后像往常一样使用 SSH 无密码:

$ ssh -i $LOCAL_PATH_TO_SSH_KEY $username@$head_node_ip

如何重置用户密码和过期密码

如果用户失去了对集群的访问权限,他们的Amazon Managed Microsoft AD密码可能已过期.

要重置密码,请使用具有目录写入权限的用户和角色运行以下命令:

$ aws ds reset-user-password \ --directory-id "d-abcdef01234567890" \ --user-name "USER_NAME" \ --new-password "NEW_PASSWORD" \ --region "region-id"

如果您重置了的密码DirectoryService/DomainReadOnlyUser

  1. 一定要更新DirectoryService/PasswordSecretArn使用新密码进行密钥。

  2. 更新集群以获取新的密钥值:

    1. 使用pcluster update-compute-fleet命令。

    2. 从集群头节点中运行以下命令。

      $ sudo /opt/parallelcluster/scripts/directory_service/update_directory_service_password.sh

密码重置和集群更新后,应恢复用户的群集访问权限。

有关更多信息,请参阅重置用户密码在里面Amazon Directory Service管理指南.

如何验证已加入的域名

以下命令必须从已加入域的实例运行,而不是从头节点运行。

$ realm list corp.pcluster.com \ type: kerberos \ realm-name: CORP.PCLUSTER.COM \ domain-name: corp.pcluster.com \ configured: kerberos-member \ server-software: active-directory \ client-software: sssd \ required-package: oddjob \ required-package: oddjob-mkhomedir \ required-package: sssd \ required-package: adcli \ required-package: samba-common-tools \ login-formats: %U \ login-policy: allow-realm-logins

如何解决证书问题疑难解答

当 LDAPS 通信不起作用时,可能是由于 TLS 通信中的错误,而这又可能是由于证书问题造成的。

有关证书的说明:

  • 集群配置中指定的证书LdapTlsCaCert必须是一组 PEM 证书,其中包含为域控制器颁发证书的整个颁发机构证书 (CA) 链的证书。

  • PEM 证书捆绑包是由 PEM 证书串联构成的文件。

  • PEM 格式(通常在 Linux 中使用)的证书等同于 Base64 DER 格式的证书(通常由 Windows 导出)。

  • 如果域控制器的证书由下级 CA 颁发,则证书包必须包含从属 CA 和根 CA 的证书。

故障排除验证步骤:

以下验证步骤假设命令是在群集头节点内运行的,并且域控制器可通过以下网址访问SERVER:PORT.

要解决与证书相关的问题,请执行以下验证步骤:

验证步骤:

  1. 检查与 AD 域控制器的连接:

    确认您可以连接到域控制器。如果此步骤成功,则与域控制器的 SSL 连接成功并验证证书。你的问题与证书无关。

    如果此步骤失败,请继续进行下一次验证。

    $ openssl s_client -connect SERVER:PORT -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE
  2. 检查证书验证:

    验证本地 CA 证书包是否可以验证域控制器提供的证书。如果此步骤成功,则您的问题与证书无关,而是与其他网络问题有关。

    如果此步骤失败,请继续进行下一次验证。

    $ openssl verify -verbose -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE PATH_TO_A_SERVER_CERTIFICATE
  3. 检查 AD 域控制器提供的证书:

    验证域控制器提供的证书的内容是否符合预期。如果此步骤成功,则用于验证控制器的 CA 证书可能有问题,请转到下一个故障排除步骤。

    如果此步骤失败,则必须更正为域控制器颁发的证书,然后重新执行故障排除步骤。

    $ openssl s_client -connect SERVER:PORT -showcerts
  4. 检查证书的内容:

    验证域控制器提供的证书内容是否符合预期。如果此步骤成功,则用于验证控制器的 CA 证书可能有问题,请转到下一个故障排除步骤。

    如果此步骤失败,则必须更正为域控制器颁发的证书,然后重新运行故障排除步骤。

    $ openssl s_client -connect SERVER:PORT -showcerts
  5. 检查本地 CA 证书包的内容:

    验证用于验证域控制器证书的本地 CA 证书包的内容是否符合预期。如果此步骤成功,则域控制器提供的证书可能有问题。

    如果此步骤失败,则必须更正为域控制器颁发的 CA 证书包,然后重新运行故障排除步骤。

    $ openssl x509 -in PATH_TO_A_CERTIFICATE -text

如何验证与 AD 的集成是否正常

如果以下两项检查成功,则说明与 Active Directory (AD) 的集成正在运行。

检查:

  1. 您可以发现在目录中定义的用户:

    在集群头节点内部,作为ec2-user

    $ getent passwd $ANY_AD_USER
  2. 您可以提供用户密码通过 SSH 进入头节点:

    $ ssh $ANY_AD_USER@$HEAD_NODE_IP

如果支票一失败,我们预计支票二也会失败。

其他故障排除检查:

如何解决登录计算节点的问题

本节与登录集成 AD 的集群中的计算节点有关。

与Amazon ParallelCluster,设计上禁用了群集计算节点的密码登录。

所有用户都必须使用自己的 SSH 密钥登录计算节点。

在以下情况下,用户可以在首次身份验证(例如登录)后在头节点中检索其 SSH 密钥GenerateSshKeysForUsers已在群集配置中启用。

当用户首次在头节点上进行身份验证时,他们可以检索作为目录用户自动为他们生成的 SSH 密钥。还会为用户创建主目录。当 sudo-user 首次切换到头节点中的用户时,也可能发生这种情况。

如果用户尚未登录到头节点,则不会生成 SSH 密钥,并且该用户将无法登录到计算节点。

的已知问题 SimCenter Starccm+ 在多用户环境中工作

本节与西门子的 Simcenter StarCCM+ 计算流体力学软件在多用户环境中启动的工作有关。

如果你运行配置为使用嵌入式 IntelMPI 的 Starccm+ v16 作业,则默认情况下,MPI 进程是使用 SSH 引导的。

由于已知Selurm 错误这会导致用户名解析错误,作业可能会因错误而失败error setting up the bootstrap proxies. 这个错误只会影响Amazon ParallelCluster版本 3.1.1 和 3.1.2。

为了防止这种情况发生,强制 IntelMPI 使用 Slurm 作为 MPI 启动方法。导出环境变量I_MPI_HYDRA_BOOTSTRAP=slurm进入启动 StarCCM+ 的作业脚本中,如中所述IntelMPI 官方文档.

用户名解析的已知问题

本节与检索工作中的用户名有关。

由于已知Slurm 中的错误,则在作业进程中检索到的用户名可能是nobody如果您运行任务没有srun. 这个错误只会影响Amazon ParallelCluster版本 3.1.1 和 3.1.2。

例如,如果您运行命令sbatch --wrap 'srun id'作为目录用户,将返回正确的用户名。但是,如果你运行sbatch --wrap 'id'作为目录用户,nobody可能会作为用户名返回。

您可以使用以下解决方法。

  1. 使用以下命令启动您的任务'srun'而不支持'sbatch',如果可能的话。

  2. 通过设置启用 SSSD 枚举AdditionalSssdConfigs在群集配置中,如下所示。

    AdditionalSssdConfigs: enumerate: true

如何解决主目录创建问题

本节与主目录创建问题有关。

如果您看到类似以下示例中显示的错误,则说明您首次登录头节点时没有为您创建主目录。或者,当你第一次在头节点中从 sudoer 切换到 AD 用户时,没有为你创建主目录。

$ ssh AD_USER@$HEAD_NODE_IP /opt/parallelcluster/scripts/generate_ssh_key.sh failed: exit code 1 __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ Could not chdir to home directory /home/PclusterUser85: No such file or directory

主目录创建失败可能是由于oddjoboddjob-mkhomedir安装在群集头节点中的软件包。

如果没有主目录和 SSH 密钥,用户就无法向集群节点提交任务或 SSH。

如果你需要oddjob系统中的软件包,请验证oddjobd服务正在运行并刷新 PAM 配置文件以确保已创建主目录。为此,请在头节点中运行命令,如以下示例所示。

sudo systemctl start oddjobd sudo authconfig --enablemkhomedir --updateall

如果您不需要oddjob系统中的软件包,将其卸载并刷新 PAM 配置文件以确保已创建主目录。为此,请在头节点中运行命令,如以下示例所示。

sudo yum remove -y oddjob oddjob-mkhomedir sudo authconfig --enablemkhomedir --updateall

排查自定义 AMI 问题

当您使用自定义 AMI 时,您会看到以下警告:

"validationMessages": [ { "level": "WARNING", "type": "CustomAmiTagValidator", "message": "The custom AMI may not have been created by pcluster. You can ignore this warning if the AMI is shared or copied from another pcluster AMI. If the AMI is indeed not created by pcluster, cluster creation will fail. If the cluster creation fails, please go to https://docs.aws.amazon.com/parallelcluster/latest/ug/troubleshooting.html#troubleshooting-stack-creation-failures for troubleshooting." }, { "level": "WARNING", "type": "AmiOsCompatibleValidator", "message": "Could not check node AMI ami-0000012345 OS and cluster OS alinux2 compatibility, please make sure they are compatible before cluster creation and update operations." } ]

如果您确定正在使用正确的 AMI,则可以忽略这些警告。

如果您不想在将来看到这些警告,请使用以下标签标记自定义 AMI,其中my-os是其中之一alinux2,ubuntu1804,ubuntu2004,或centos7“3.2.1”pcluster正在使用的版本:

$ aws ec2 create-tags \ --resources ami-yourcustomAmi \ --tags Key="parallelcluster:version",Value="3.2.1" Key="parallelcluster:os",Value="my-os"

对集群更新超时进行故障排除cfn-hup未运行

这些区域有:cfn-hup帮助程序作为一项后台程序,旨在检测资源元数据中出现的变更,并在检测出变更的情况下,运行用户指定操作。通过此项操作,您可以通过以下方式对您正在运行的 Amazon EC2 实例进行配置更新UpdateStackAPI 操作。

目前cfn-hup守护程序由启动supervisord. 但是发射后,cfn-hup进程已从中分离supervisord控制。如果cfn-hup恶魔被外部角色杀死,它不会自动重启。如果cfn-hup未运行,在集群更新期间, CloudFormation 堆栈按预期启动更新过程,但更新过程未在头节点上激活,堆栈最终进入超时状态。来自集群日志/var/log/chef-client,你可以看到更新配方从未被调用。

检查并重新启动cfn-hup万一出现故障

  1. 在头节点上,检查是否cfn-hup正在运行:

    $ ps aux | grep cfn-hup
  2. 检查cfn-hup日志/var/log/cfn-hup.log/var/log/supervisord.log在头节点上。

  3. 如果cfn-hup没有运行,请尝试运行以下命令重启它:

    $ sudo /opt/parallelcluster/pyenv/versions/cookbook_virtualenv/bin/supervisorctl start cfn-hup

网络故障排查

单个公有子网中的集群问题

检查cloud-init-output.log来自其中一个计算节点。如果您发现以下内容表明该节点在 slurm 初始化中卡住了,则很可能是因为缺少 DynamoDB VPC 终端节点。您必须添加 DynamoDB 终端节点。有关更多信息,请参阅Amazon ParallelCluster在无法访问 Internet 的单一子网中.

ruby_block[retrieve compute node info] action run[2022-03-11T17:47:11+00:00] INFO: Processing ruby_block[retrieve compute node info] action run (aws-parallelcluster-slurm::init line 31)

其他支持

有关已知问题的列表,请参阅正文GitHub 维基.

page 或问题页面。如有更紧急的问题,请联系Amazon Web Services Support或者打开一个新的 GitHub 签发.