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仪表板

日志是解决问题的有用资源。例如,如果要删除出现故障的群集,首先创建群集日志的存档可能会很有用。请按照以下步骤创建存档。

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

$ 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>删除集群但保留存储在亚马逊中的日志组CloudWatch.

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

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

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

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.1.2", "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要查看的 CLICloudFormation活动上CREATE_FAILED有助于找到根本原因的错误。

在中查看事件CloudFormation控制台

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

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

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

  2. 选择名为的堆栈cluster er_name.

  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" } ]

在前面的示例中,失败的位置在HeadNode设置。

使用 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.1.2", "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 及更高版本使用 Surm 任务计划程序。有关配置多个队列的更多信息,请参阅配置多个队列.

如果您的某个正在运行的集群遇到问题,请将集群放在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仪表板

用于调试的关键日志

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

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

  • /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-这是 Surm 控制守护进程日志。Amazon ParallelCluster不做扩展决策。相反,它只是尝试启动资源来满足 Surm 的要求。它对于扩展和分配问题、与作业相关的问题以及任何与计划程序相关的启动和终止问题都非常有用。

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

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

  • /var/log/parallelcluster/computemgtd-这是computemgtd日志。它在每个计算节点上运行,以便在罕见的情况下监控节点clustermgtd头节点上的守护程序处于脱机状态。它对于解决意外的终止问题非常有用。

  • /var/log/slurmd.log-这是 Surm 计算守护进程日志。它对于排除初始化和计算故障相关问题非常有用。

排查节点初始化问题

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

Head 节点

适用日志:

  • /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) 来确定 Surm 是否曾经试过打电话ResumeProgram与节点一起)。

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

  • 如果ResumeProgram被调用,请检查是否为该节点启动了实例。如果没有启动实例,您可以看到描述启动失败的错误消息。

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

静态计算节点:

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

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

排查意外的节点替换和终止

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

  • 适用日志:

    • /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被确定为不健康。Checkcomputemgtd日志 (/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-xyz --disable-api-termination
    • 使用此命令从节点检索控制台输出。

      aws ec2 get-console-output --instance-id i-xyz --output text

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

  • 适用日志:

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

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

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

  • 对于动态节点失败SlurmSettings属性,签入SuspendProgram登录以查看是否SuspendProgram被称为slurmctld以特定节点作为参数。请注意SuspendProgram实际上没有执行任何操作。相反,它只会在调用时记录。所有实例终止和NodeAddr重置完成clustermgtd. Surm 将节点放回POWER_SAVING之后的状态SuspendTimeout自动。

排查其他已知节点和作业问题

另一种已知问题是Amazon ParallelCluster可能无法分配作业或做出扩展决策。有了这种类型的问题,Amazon ParallelCluster仅根据 Surm 的说明启动、终止或维护资源。对于这些问题,请检查slurmctld登录以对其进行故障排除

置放群组和实例启动问题

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

如果您需要高性能共享文件系统,请考虑使用Amazon FSx for Lustre.

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

无法替换的目录

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

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

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

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

在 NICE DCV 中排查问题

NICE DCV 的日志写入/var/log/dcv/目录。查看这些日志有助于排查问题。

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

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

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

本节与集群相关Amazon Batch调度程序集成。

Head 节点问题

与头节点相关的设置问题可以像Slurm集群(除外Slurm特定日志)。有关这些问题的更多信息,请参阅Head 节点.

计算问题

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

Job 失败

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

排查多用户与 Active Directory 集成的

此部分与 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

如何重置用户密码

在对目录具有写入权限的用户和角色的情况下运行以下命令:

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

有关更多信息,请参阅 。重置用户密码中的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 进入 Head 节点提供用户密码:

    $ 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 引导。

因已知Surm 错误这导致用户名解析错误,作业可能会失败并出现类似的错误error setting up the bootstrap proxies.

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

用户名解析的已知问题

本节与在作业中检索用户名相关。

因已知Surm 中的 bug,在作业流程中检索到的用户名可能是nobody如果你没有运行作业srun.

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

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

  1. 使用启动您的任务'srun'而不是'sbatch',如果可能。

  2. 通过设置AdditionalSssd配置在群集配置中,如下所示。

    AdditionalSssdConfigs: enumerate: true

如何对登录计算节点进行故障排除

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

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

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

用户可以在首次登录后在头节点中检索他们的 SSH 密钥,如果GenerateSshKeysForUsers已在群集配置中启用。

当用户首次登录头节点时,他们可以检索作为目录用户自动生成的 SSH 密钥。还创建了用户的主目录。这也可能在 sudo-User 首次切换到头节点中的用户时发生。

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

已知问题SimCenter多用户环境中的 StarCCM + 作业

本部分与西门子 Simcenter StarCCM + 计算流体动力学软件在多用户环境中启动的职位相关。

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

因已知Surm 错误这导致用户名解析错误,作业可能会失败并出现类似的错误error setting up the bootstrap proxies.

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

如何解决主目录创建问题

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

如果您看到类似以下示例中显示的错误,那么当您首次登录头节点时,没有为您创建主目录。或者,当你第一次从 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 配置文件以确保创建了主目录。为此,请在 Head 节点中运行命令,如以下示例所示。

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

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

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

其他支持

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

页面或问题页. 有关更多紧急问题,请联系Amazon Web Services Support或者打开新的GitHub签发.