Best practices for Amazon SageMaker HyperPod administration and governance

Amazon SageMaker HyperPod 管理与治理最佳实践 | 人工智能

Amazon SageMaker HyperPod 管理与治理最佳实践

Amazon SageMaker HyperPod 为机器学习（ML）团队提供了大量加速计算资源，用于训练和微调模型。当多个团队共享一个集群时，技术配置通常较为直接。具有挑战性的是治理。您需要决定哪些团队可以使用集群、每个团队可获得的容量配额、当一个团队的工作负载与其他团队竞争时会发生什么，以及当使用情况偏离政策时由谁负责。Amazon SageMaker Unified Studio 增加了另一个考量因素：您可以将 SageMaker HyperPod 集群连接到项目，使团队成员能够从其项目工作区启动工作负载。这种便利性很有价值，但当多个团队共享对同一集群的可见性后，控制谁可以执行什么操作的规则变得更加重要。在本文中，我们将展示如何通过 SageMaker Unified Studio 管理 SageMaker HyperPod，同时保留底层治理控制。我们涵盖四个控制层级：组织、项目、集群和工作负载。我们还解释了如何在这些层级之间设计身份、容量和可观测性策略。最终，您将获得一个可重复的模型，可在项目上下文中为 ML 团队提供经过批准的 SageMaker HyperPod 计算资源，同时让基础设施团队管理集群操作。

Amazon SageMaker HyperPod 是 Amazon SageMaker AI 的一项功能。Amazon SageMaker Unified Studio 是团队使用其数据和工具构建模型的数据和 AI 开发环境。通过 SageMaker Unified Studio，您可以将项目连接到现有的 SageMaker HyperPod 集群。成员随后可以启动机器学习工作负载、查看集群和任务信息，并打开 JupyterLab 工作流。您仍通过 Amazon SageMaker AI 的接口和 API 管理集群。

这种分离为基础设施团队提供了有用的运营模型。您可以通过已建立的云运维流程管理集群基础设施。同时，您可以在项目上下文中向机器学习团队提供经过批准的计算资源。在本文中，我们将描述如何设计基础设施边界、治理访问权限、分配共享容量，并通过 SageMaker Unified Studio 一致地操作 SageMaker HyperPod。

理解管理边界

一个治理良好的环境会分离组织管理、项目访问和集群操作。每一层都回答不同的问题并使用不同的控制机制。下表总结了每个边界、其主要控制措施及其管理目的。

| 边界 | 主要控制措施 | 管理目的 | |------------|------------------------------------------------------------------------------|--------------------------------------------------------------------------| | 组织 | SageMaker Unified Studio 域、域单元、关联账户、项目配置文件和授权策略 | 确定谁可以创建项目、项目可使用的账户和区域，以及可用的工具 | | 项目 | 项目成员、项目角色和 SageMaker HyperPod 连接 | 定义协作上下文以及项目成员可访问的 AWS 资源 | | 集群 | SageMaker HyperPod 集群管理员角色、Amazon EKS 访问条目、基于角色的访问控制（RBAC）、EKS Pod 身份或 Slurm 控制 | 管理集群配置、调度器访问、命名空间、任务和基础设施操作 | | 工作负载 | 工作负载策略、资源配额、监控指标和日志配置 | 定义工作负载的资源使用规则、监控要求和日志记录规范 |

计算资源分配、优先级类、借贷与借用策略以及任务权限

控制谁可以提交工作负载以及共享计算资源如何分配

将这些控制机制视为分层结构。SageMaker HyperPod连接将已批准的集群添加到项目中，但不会替代集群本身的AWS Identity and Access Management（IAM）、Amazon Elastic Kubernetes Service（Amazon EKS）或Slurm控制机制。需共同审查项目角色、连接访问角色、EKS访问条目和RBAC或Slurm控制机制、工作负载身份、数据和AWS Key Management Service（AWS KMS）密钥策略、网络策略、任务查看限制以及调度策略。在这些控制机制对齐之前，不得使集群可用。

这些控制机制形成四个层级，如以下图表所示。

图1：控制机制的四个层级：组织、项目、集群和工作负载。每一层级回答不同问题并采用不同控制方式，因此需在各自边界独立审查。

SageMaker Unified Studio项目是协作边界，而非强运行时安全边界。应将SageMaker HyperPod集群、调度器和稀缺加速器资源置于一个指定的容量账户下。已批准的用户和数据集可保留在同一账户，或分别存放于消费账户和数据账户中。AWS文档中针对SageMaker HyperPod任务治理在Amazon EKS集群上的多账户支持进行了说明。尽管按需容量预留可跨账户共享，但应将SageMaker HyperPod集群所有权和容量管理集中于容量账户。建议使用经批准的跨账户访问权限，而非让每个消费账户成为独立的容量管理员。

• 对于Amazon EKS，应结合RBAC、租户专用服务账户和EKS Pod身份角色、默认拒绝网络策略以及租户专用存储和AWS KMS权限，为每个租户配置独立命名空间。
• 对于Slurm，应使用Slurm计费系统配合层级账户和关联、服务质量（QoS）、优先级和公平共享策略以及分区。同时应使用操作系统身份和文件权限、网络控制以及租户专用数据路径。

• 应使用IAM角色和资源策略，而非仅依赖项目成员资格，来控制对Amazon Simple Storage Service（Amazon S3）存储桶、AWS KMS密钥、密钥、容器注册表和其他数据服务的访问。应使用项目和领域单元策略进行协作和委托。

• 对于Amazon EKS集群，应使用SageMaker HyperPod任务治理机制（包括配额、优先级类、借贷与借用以及抢占机制）来公平共享中心加速器池。对于Slurm集群，应使用原生分区、服务质量（QoS）、优先级、公平共享和抢占控制。Slurm不提供相同的借贷与借用模型。这些调度控制机制决定授权工作负载何时获得计算资源，但不会授予命名空间或数据访问权限。

如需在集群内实现更强的隔离性，应在适当场景下使用专用节点或节点组以及准入控制。当法律、监管或安全要求需要硬性基础设施隔离时，应使用独立集群或账户。跨账户消费者访问可在保留账户级所有权的同时避免重复中央SageMaker HyperPod集群。在容量账户内，应使用项目配置文件和领域单元配合项目授权策略，来委派项目创建和所有权。

以下图表展示了集中式容量与租户特定的工作负载、身份、数据、网络和可见性控制。

图2：集中式SageMaker HyperPod容量。集群和调度器保留在一个容量账户中。每个租户均可获得工作负载、身份、数据、网络和任务可见性控制。硬隔离需求使用专用基础设施。

图3展示了当SageMaker Unified Studio向项目成员暴露批准的SageMaker HyperPod计算资源时，这些边界如何连接。

图3：推荐的SageMaker HyperPod管理模型。SageMaker Unified Studio管理协作上下文，而集群身份、工作负载授权、调度器策略和操作控制保持独立。

确定何时使用SageMaker Unified Studio作为合适的管理体验

通过SageMaker Unified Studio，已经在项目中工作的机器学习团队可以遵循批准的路径共享SageMaker HyperPod计算资源。成员可以查找已连接的集群，查看状态和元数据，检查支持的任务和指标，并无需使用单独的基础设施清单即可进入JupyterLab。

这种体验不会取代集群管理。下表展示了每个角色应如何将SageMaker Unified Studio与特定服务接口结合使用。

角色

使用SageMaker Unified Studio进行

继续使用特定服务工具进行

领域或基础设施管理员

领域单元、项目创建策略、项目配置文件、成员资格策略和账户位置

组织级控制、账户配置和基础设施自动化

SageMaker HyperPod集群管理员

展示批准的集群连接并查看集群、任务、设置和元数据视图

集群创建、更新、弹性配置、插件、EKS或Slurm管理以及事件响应

项目所有者

管理项目成员资格并为批准的计算资源提供一致的项目上下文

请求基础设施变更并批准业务特定的访问需求

机器学习工程师或数据科学家

查找批准的计算资源、查看工作负载状态并打开JupyterLab工作流

通过SageMaker HyperPod CLI、kubectl或Slurm工具提交和管理详细工作负载

当项目成员资格、数据访问、开发工具和计算需要统一上下文时，请使用SageMaker Unified Studio。对于集群变更和可重复的自动化操作，请继续使用SageMaker AI API、基础设施即代码和编排工具。有关参考实现和集成，请参阅SageMaker HyperPod上的AI网站。

在连接集群之前做出基础设施决策

在批准连接之前，请记录容量账户、任何消费者或数据账户、AWS区域、网络路径、身份、所有者、工作负载边界和隔离要求。如果需要集群创建指导，请参考Amazon SageMaker HyperPod文档或SageMaker HyperPod上的AI网站。

将管理身份与工作负载身份分离。在创建项目和访问角色时，保留SageMaker HyperPod对集群管理员和数据科学家用户之间的区分。面向项目的角色不应仅因为其用户运行工作负载而获得集群生命周期权限。有关支持的权限模型，请参阅AWS Identity and Access Management for SageMaker HyperPod。

将网络视为端到端的控制点。限制对Amazon EKS Kubernetes API端点的访问，仅允许经过批准的管理网络路径，控制Pod的入站和出站流量，并验证项目、连接角色、工作负载角色和集群网络是否仅支持预期的数据路径。有关特定编排器的配置，请参阅《使用Amazon EKS编排SageMaker HyperPod集群》。

例如，配置Amazon EKS API端点的私有访问，并仅允许来自批准的管理员或工作负载子网的访问。应用默认拒绝的Kubernetes NetworkPolicy，并显式允许必要的服务间通信和出站路径。在适当的情况下，为Amazon S3、Amazon Elastic Container Registry（Amazon ECR）和Amazon CloudWatch等服务使用虚拟私有云（VPC）端点，并为每个租户分配专用的工作负载角色以进行数据访问。

创建连接合同。连接合同是客户管理的治理记录，例如维基页面、工单、服务目录记录或基础设施即代码仓库中跟踪的文件。它不是平台功能。为每个批准的项目到集群连接记录以下信息：

• 业务负责人、运维负责人和成本负责人。
• SageMaker Unified Studio域单元和项目。
• 集群账户、区域、名称和编排器。
• 项目角色和连接使用的访问角色Amazon资源名称（ARN）。
• 批准的工作负载类型和数据分类。
• EKS命名空间或Slurm访问范围。
• 调度策略和例外负责人。
• 监控、支持和退役预期。

此合同为审核人员提供了一个记录，用于评估和批准完整的访问路径。

治理身份和任务可见性

控制操作和可见性。任务名称、命名空间、资源请求和使用模式的不当设置可能会泄露其他团队工作的信息。

尽可能使用组而非个人授权来管理项目成员和集群访问权限。在域、项目、集群和工作负载策略范围内审查每个角色的权限，而不是创建一个涵盖所有范围的广泛角色。

以下工作流程展示了如何将用户可见的内容与其可执行的操作分离。

图4：治理身份和任务可见性。通过组分配访问权限，将每个角色的作用域限制在其边界内，限制任务可见性，并将查看工作内容的能力与执行操作的能力分开。

在用户入职前审查默认任务可见性。SageMaker AI Studio中的SageMaker HyperPod文档说明，默认情况下SageMaker AI Studio用户可以看到所有Amazon EKS集群任务。对于Slurm集群，每个SageMaker AI Studio用户都可以查看、管理和交互所有可用任务。在为多个团队入职前配置任务查看限制：请参阅《在Studio中限制EKS集群的任务查看》和《在Studio中限制Slurm集群的任务查看》。项目成员身份不是集群级别的安全边界。

对于 Amazon EKS 集群，将每个团队映射到已批准的命名空间和 RBAC 权限，并将每个工作负载服务账户映射到特定租户的 IAM 角色。对于跨账户数据访问，将服务账户与容量（集群）账户中的 EKS Pod Identity 角色关联，并在关联中设置目标 IAM 角色（targetRoleArn）。EKS Pod Identity 会自动执行跨账户角色假设，因此应用程序代码无需调用 AssumeRole。目标角色位于消费者或数据账户中。将只读可见性与创建、更新或删除工作负载的权限分开。对于 Slurm 集群，定义等效的用户、账户、分区、文件系统和任务可见性控制。

例如，以下 Kubernetes RBAC Role 仅授予团队在其自己的命名空间中查看作业的只读权限。需要单独的角色来创建或删除工作负载，这将“查看”与“操作”分离。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: team-research
  name: research-job-viewer
rules:
  - apiGroups: ["batch"]
    resources: ["jobs"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["kubeflow.org"]
    resources: ["pytorchjobs"]
    verbs: ["get", "list", "watch"]

将业务优先级转化为调度策略

对于 Amazon EKS 集群，在身份和工作负载访问控制到位后，再应用任务治理。

下图展示了涉及的两个决策的分离。

图 5：将授权与调度策略分开。EKS RBAC 或 Slurm ACL 确定用户是否可以提交工作负载。Amazon EKS 的 SageMaker HyperPod 任务治理或原生 Slurm 调度控制确定该工作负载何时获得计算资源。

记录保证容量和共享容量、优先级类以及团队是否可以使用其他团队的空闲分配。为每个例外分配一个负责人。任务治理同样适用于 SageMaker HyperPod 空间（直接在集群上运行的自包含 JupyterLab 或 Code Editor 环境），因此将这些交互式开发工作负载纳入分配策略。

例如，在 Amazon EKS 集群上，您可以为生产训练团队分配 60% 的保证容量并设置高优先级类，允许研究团队以较低优先级借用空闲容量，并在生产团队提交工作时允许抢占该借用容量。为任何例外情况指定一个负责人，以防止一次性请求悄无声息地成为常态。

将授权与调度策略分开。EKS RBAC 或 Slurm ACL 确定用户是否可以提交工作负载。Amazon EKS 的 SageMaker HyperPod 任务治理或原生 Slurm 调度控制决定授权工作负载何时获得计算资源。将调度配额用作访问控制，或使用授权控制作为调度策略，会产生不明确的行为，并使事件更难诊断。

文章《Amazon SageMaker HyperPod 任务治理最佳实践》解释了公平共享权重、配额、借贷、优先级类和常见分配场景。对于 Amazon EKS 集群，在定义分配策略时使用这些模式。对于 Slurm 集群，使用前面描述的原生调度器控制。

将可观测性用作治理反馈循环

使用 SageMaker 统一工作室，您可以查看 SageMaker HyperPod 集群的详细信息，包括任务、指标、设置和元数据。对于 Amazon EKS 集群，任务治理指标包括硬件、团队和任务视图。这些视图可帮助您将政策意图与实际使用情况进行对比。

将可观测性视为一个循环，如下图所示。

图 6：将可观测性作为治理反馈循环。监控信号，将其与政策意图进行比较，决定响应措施，并调整政策和资源分配，为每个信号指定负责人和响应措施。

为每个监控信号定义负责人和响应措施。以下示例将仪表板数据转化为管理决策。

| 信号 | 管理决策 | |------|----------| | 集群容量和加速器利用率 | 确定低利用率是临时性的、由政策驱动的还是由工作负载限制引起的 | | 团队分配和利用率 | 检查预留和共享容量是否仍反映业务需求 | | 任务运行时间和等待时间 | 调查优先级策略、工作负载规模或容量争用情况 | | 挂起和被抢占的任务 | 确认调度器结果是否符合已批准的优先级模型 | | 节点健康状况和恢复事件 | 启动集群事件流程并验证恢复目标 |

对于 Amazon EKS 集群，任务表显示 Kubeflow 任务（PyTorch、MPI 和 TensorFlow），默认显示 PyTorch 任务。通过其他机制提交的工作负载可能不会显示在此处。对于 Slurm 集群，任务表显示当前调度器队列中的作业，而 Slurm 账户通过 sacct 等工具提供历史作业数据。定义您获取历史任务数据、审计证据和事件详情的位置。

要使用文档中描述的指标视图，需要安装 Amazon CloudWatch Observability EKS 插件。该插件有其自身的前提条件：版本 2.4.0 或更高版本，以及附加到 Kubernetes 工作节点角色的 CloudWatchAgentServerPolicy IAM 策略。Kueue 指标提供任务治理视图，超出免费层级后可能会产生 CloudWatch 指标费用。有关当前设置和定价考虑，请参阅 SageMaker HyperPod 仪表板文档。

在整个生命周期中审查连接

为每个连接设置审查计划。同时定义事件驱动的审查，用于项目所有权、访问角色、账户或区域、集群容量、编排器版本、数据分类或监控范围的变更。使用连接合同记录每个决策。

下图显示了生命周期阶段。

图 7：连接生命周期。通过记录的连接合同批准连接，对其进行操作和监控，按计划和定义的事件进行审查，然后续订或撤销连接。

在能减少人工工作量的场景中自动化库存和证据收集，但需保留可问责管理员的审批权限。撤销不再具有商业目的或负责人的连接。

结论

使用 Amazon SageMaker 统一工作室，机器学习团队可以按照以项目为中心的路径获得批准的 SageMaker HyperPod 计算资源，同时基础设施团队仍可控制集中式集群。从一个非生产环境集群和一个测试项目开始。在添加成员之前，为 Amazon EKS 配置工作负载身份、命名空间或 Slurm 范围、数据权限、网络策略、任务视图限制和任务治理，或为 Slurm 配置原生调度控制。安装 Amazon CloudWatch Observability EKS 插件以生成指标视图，并在连接合同中记录完整的审批信息。对于已批准的消费者账户，使用跨账户角色；在需要严格隔离时，使用专用基础设施。按照 SageMaker HyperPod 连接流程执行实施步骤。

关于作者

'\"