기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Amazon EKS를 사용한 SageMaker HyperPod 클러스터 오케스트레이션을 위한 클러스터 복원력 기능 SageMaker HyperPod는 다음과 같은 클러스터 복원력 기능을 제공합니다. **Topics** + [상태 모니터링 시스템](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md) + [기본 상태 확인](sagemaker-hyperpod-eks-resiliency-basic-health-check.md) + [심층 상태 확인](sagemaker-hyperpod-eks-resiliency-deep-health-checks.md) + [자동 노드 복구](sagemaker-hyperpod-eks-resiliency-node-recovery.md) + [SageMaker HyperPod의 복원력 관련 Kubernetes 레이블](sagemaker-hyperpod-eks-resiliency-node-labels.md) + [노드를 수동으로 격리, 교체 또는](sagemaker-hyperpod-eks-resiliency-manual.md) + [권장 복원력 구성](sagemaker-hyperpod-eks-resiliency-config-tips.md) # 상태 모니터링 시스템 SageMaker HyperPod 상태 모니터링 시스템에는 두 가지 구성 요소가 포함되어 있습니다. 1. 호스트 상태 모니터 역할을 하는 상태 모니터링 에이전트(HMA)와 노드 out-of-node 상태 모니터 세트를 포함하여 노드에 설치된 에이전트를 모니터링합니다. 1. SageMaker HyperPod에서 관리하는 노드 복구 시스템. 상태 모니터링 시스템은 모니터링 에이전트를 통해 노드 상태를 지속적으로 모니터링한 다음 노드 복구 시스템을 사용하여 장애가 감지되면 자동으로 조치를 취합니다. ![\[이 이미지는 상태 모니터링 시스템이 HyperPod 클러스터와 어떻게 통합되었는지 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/images/hyperpod/hyperpod-resilience-event.png) ## SageMaker HyperPod 상태 모니터링 에이전트에서 수행하는 상태 확인 SageMaker HyperPod 상태 모니터링 에이전트는 다음을 확인합니다. **NVIDIA GPU** + [DCGM 정책 위반 알림](https://docs.nvidia.com/datacenter/dcgm/3.0/user-guide/feature-overview.html#notifications) + `nvidia-smi` 출력 오류 + Amazon Elastic Compute Cloud(EC2) 플랫폼에서 생성된 로그의 다양한 오류 + GPU 수 검증 - 특정 인스턴스 유형의 예상 GPUs 수(예: ml.p5.48xlarge 인스턴스 유형의 GPUs 8개)와에서 반환한 수 간에 불일치가 있는 경우 `nvidia-smi`HMA는 노드를 재부팅합니다. **AWS 훈련** + [AWS Neuron 모니터](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-monitor-user-guide.html)의 출력 오류 + Neuron 노드 문제 감지기에 의해 생성된 출력( AWS Neuron 노드 문제 감지기에 대한 자세한 내용은 [Amazon EKS 클러스터 내의 AWS Neuron 노드에 대한 노드 문제 감지 및 복구를 참조하세요](https://aws.amazon.com/blogs/machine-learning/node-problem-detection-and-recovery-for-aws-neuron-nodes-within-amazon-eks-clusters/).) + Amazon EC2 플랫폼에서 생성된 로그의 다양한 오류 + Neuron 디바이스 수 검증 - 특정 인스턴스 유형의 실제 뉴런 디바이스 수와에서 반환한 수 간에 불일치가 있는 경우 `neuron-ls`HMA는 노드를 재부팅합니다. 위의 검사는 수동 백그라운드 상태 확인 HyperPod가 노드에서 지속적으로 실행됩니다. 이러한 검사 외에도 HyperPod는 HyperPod 클러스터를 생성하고 업데이트하는 동안 심층(또는 활성) 상태 확인도 실행합니다. [심층 상태 확인](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-resiliency-deep-health-checks.html)에 대해 자세히 알아봅니다. ## 결함 감지 SageMaker HyperPod는 장애를 감지하면 네 부분으로 구성된 응답을 구현합니다. 1. **노드 레이블** 1. 상태: `sagemaker.amazonaws.com/node-health-status` 1. 결함 유형: 상위 수준 분류를 위한 `sagemaker.amazonaws.com/fault-types` 레이블 1. 결함 이유: 자세한 결함 정보에 대한 `sagemaker.amazonaws.com/fault-reasons` 레이블 1. **노드 테인트** 1. `sagemaker.amazonaws.com/node-health-status=Unschedulable:NoSchedule` 1. **노드 주석** 1. 결함 세부 정보: `sagemaker.amazonaws.com/fault-details` 1. 노드에서 발생한 타임스탬프로 최대 20개의 오류를 기록합니다. 1. **노드 조건**([Kubernetes 노드 조건](https://kubernetes.io/docs/reference/node/node-status/#condition)) 1. 노드 조건의 현재 상태를 반영합니다. + 유형: 결함 유형과 동일 + 상태: `True` + 이유: 결함 이유와 동일 + LastTransitionTime: 결함 발생 시간 ![\[이 이미지는에서 오류를 감지했을 때 상태 모니터링 시스템이 작동하는 방식을 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/images/hyperpod/hyperpod-resilience-workflow.png) ## SageMaker HyperPod 상태 모니터링 에이전트에서 생성된 로그 SageMaker HyperPod 상태 모니터링 에이전트는 즉시 사용 가능한 상태 확인 기능이며 모든 HyperPod 클러스터에서 지속적으로 실행됩니다. 상태 모니터링 에이전트는 클러스터 로그 그룹 `/aws/sagemaker/Clusters/`의 CloudWatch에 GPU 또는 Trn 인스턴스에서 감지된 상태 이벤트를 게시합니다. HyperPod 상태 모니터링 에이전트의 감지 로그는 각 노드에 대해 `SagemakerHealthMonitoringAgent` 이름이 지정된 별도의 로그 스트림으로 생성됩니다. 다음과 같이 CloudWatch 로그 인사이트를 사용하여 감지 로그를 쿼리할 수 있습니다. ``` fields @timestamp, @message | filter @message like /HealthMonitoringAgentDetectionEvent/ ``` 이는 다음과 비슷한 출력을 반환합니다. ``` 2024-08-21T11:35:35.532-07:00 {"level":"info","ts":"2024-08-21T18:35:35Z","msg":"NPD caught event: %v","details: ":{"severity":"warn","timestamp":"2024-08-22T20:59:29Z","reason":"XidHardwareFailure","message":"Node condition NvidiaErrorReboot is now: True, reason: XidHardwareFailure, message: \"NVRM: Xid (PCI:0000:b9:00): 71, pid=, name=, NVLink: fatal error detected on link 6(0x10000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)\""},"HealthMonitoringAgentDetectionEvent":"HealthEvent"} 2024-08-21T11:35:35.532-07:00 {"level":"info","ts":"2024-08-21T18:35:35Z","msg":"NPD caught event: %v","details: ":{"severity":"warn","timestamp":"2024-08-22T20:59:29Z","reason":"XidHardwareFailure","message":"Node condition NvidiaErrorReboot is now: True, reason: XidHardwareFailure, message: \"NVRM: Xid (PCI:0000:b9:00): 71, pid=, name=, NVLink: fatal error detected on link 6(0x10000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)\""},"HealthMonitoringAgentDetectionEvent":"HealthEvent"} ``` # 기본 상태 확인 SageMaker HyperPod는 HyperPod 클러스터를 생성하고 업데이트하는 동안 클러스터 인스턴스에 대한 일련의 *기본 상태 확인*을 수행합니다. 이러한 기본 상태 확인은 오케스트레이터에 구애받지 않으므로 이러한 확인은 SageMaker HyperPod(Amazon EKS 또는 Slurm)에서 지원하는 기본 오케스트레이션 플랫폼에 관계없이 적용됩니다. 기본 상태 확인은 클러스터 인스턴스에서 액셀러레이터(GPU 및 Trainium 코어) 및 네트워크 디바이스(Elastic Fabric Adapter 또는 EFA)와 같은 디바이스와 관련된 문제를 모니터링합니다. 기본 클러스터 상태 확인 목록을 찾으려면 [클러스터 상태 확인](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm.html#sagemaker-hyperpod-resiliency-slurm-cluster-health-check) 섹션을 참조하세요. # 심층 상태 확인 SageMaker HyperPod는 HyperPod 클러스터를 생성하고 업데이트하는 동안 클러스터 인스턴스에 대한 *심층 상태 확인*을 수행합니다. 심층 상태 확인은 클러스터를 기계 학습 모델 훈련에 사용할 수 있도록 허용하기 전에 기본 하드웨어 및 인프라 구성 요소를 철저히 테스트하여 SageMaker HyperPod 클러스터의 신뢰성과 안정성을 보장합니다. 이 사전 예방적 접근 방식은 클러스터 수명 주기 초기에 잠재적 문제를 식별하고 완화하는 데 도움이 됩니다. ## SageMaker HyperPod에서 수행한 심층 상태 확인 목록 SageMaker HyperPod는 다음과 같은 심층 상태 확인을 실행합니다. **인스턴스 수준 심층 상태 확인** | 카테고리 | 유틸리티 이름 | 인스턴스 유형 호환성 | 설명 | | --- | --- | --- | --- | | 액셀러레이터 | GPU/NVLink 수 | GPU | GPU/NVLink 수를 확인합니다. | | 액셀러레이터 | [DCGM 진단](https://docs.nvidia.com/datacenter/dcgm/latest/user-guide/dcgm-diagnostics.html) 수준 4 | GPU | 추가 메모리 테스트를 포함하여 레벨 4에서 DCGM(NVIDIA Data Center GPU Manager) 진단을 실행하여 NVIDIA GPU의 상태와 기능을 평가합니다. | | 액셀러레이터 | Neuron sysfs | Trainium | Trainium 기반 인스턴스의 경우 Neuron 드라이버가 직접 전파하는 [Neuron sysfs](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-sysfs-user-guide.html)의 카운터를 읽고 Neuron 디바이스의 상태를 확인합니다. | | 액셀러레이터 | Neuron 하드웨어 확인 | Trainium | 훈련 워크로드를 실행하고 결과를 확인하여 하드웨어를 테스트합니다. | | 액셀러레이터 | NCCOM 로컬 테스트 | Trainium | 단일 Trainium 노드에서 집합 통신 작업의 성능을 평가합니다. | | Network | EFA | GPU 및 Trainium | 연결된 EFA 디바이스에서 지연 시간 및 대역폭 벤치마킹을 실행합니다. | **클러스터 수준 심층 상태 확인** | 카테고리 | 유틸리티 이름 | 인스턴스 유형 호환성 | 설명 | | --- | --- | --- | --- | | 액셀러레이터 | NCCL 테스트 | GPU | 여러 NVIDIA GPU에서 집합 통신 작업의 수행을 확인합니다 | | 액셀러레이터 | NCCOM 클러스터 테스트 | Trainium | 여러 Trainium 노드에서 집합 통신 작업의 수행을 확인합니다 | ## 심층 상태 확인의 로그 다음은 SageMaker HyperPod 심층 상태 확인의 로그 예제입니다. **클러스터 수준 로그** 클러스터 수준 심층 상태 확인 로그는 `/aws/sagemaker/Clusters//`의 CloudWatch 로그 그룹에 저장됩니다. 로그 스트림은 `DeepHealthCheckResults/`에 기록됩니다. 아래에 표시된 예제로 심층 상태 확인 출력 로그는 실패 원인과 함께 검사에 실패한 인스턴스 ID를 보여줍니다. ``` { "level": "error", "ts": "2024-06-18T21:15:22Z", "msg": "Encountered FaultyInstance. Replace the Instance. Region: us-west-2, InstanceType: p4d.24xlarge. ERROR:Bandwidth has less than threshold: Expected minimum threshold :80,NCCL Test output Bw: 30" } ``` **인스턴스 수준 로그** 인스턴스 수준 심층 상태 확인 로그는 각 노드의 `/var/log/aws/clusters/sagemaker-deep-health-check.log`에 저장됩니다. SSH를 노드에 넣고 다음 명령을 실행하여 로그 파일을 엽니다. ``` cat /var/log/aws/clusters/sagemaker-deep-health-check.log ``` 다음은 하드웨어 스트레스, [NVIDIA DCGM](https://developer.nvidia.com/dcgm) 스트레스 및 EFA 연결 테스트의 예제 출력입니다. ``` # Hardware Stress Test output 2024-08-20T21:53:58Z info Executing Hardware stress check with command: stress-ng, and args: [--cpu 32 --vm 2 --hdd 1 --fork 8 --switch 4 --timeout 60 --metrics] 2024-08-20T21:54:58Z info stress-ng success 2024-08-20T21:54:58Z info GpuPci Count check success # DCGM Stress Test 2024-08-20T22:25:02Z info DCGM diagnostic health summary: dcgmCheckLevel: 0 dcgmVersion: 3.3.7 gpuDriverVersion: 535.183.01, gpuDeviceIds: [2237] replacementRequired: false rebootRequired:false # EFA Loopback Test 2024-08-20T22:26:28Z info EFA Loopback check passed for device: rdmap0s29 . Output summary is MaxBw: 58.590000, AvgBw: 32.420000, MaxTypicalLat: 30.870000, MinTypicalLat: 20.080000, AvgLat: 21.630000 ``` 다음은 NCCL 연결 테스트의 예시 출력입니다. ``` # size count type redop root time algbw busbw #wrong time algbw busbw #wrong # (B) (elements) (us) (GB/s) (GB/s) (us) (GB/s) (GB/s) 8 2 float sum -1 353.9 0.00 0.00 0 304.2 0.00 0.00 0 16 4 float sum -1 352.8 0.00 0.00 0 422.9 0.00 0.00 0 32 8 float sum -1 520.0 0.00 0.00 0 480.3 0.00 0.00 0 64 16 float sum -1 563.0 0.00 0.00 0 416.1 0.00 0.00 0 128 32 float sum -1 245.1 0.00 0.00 0 308.4 0.00 0.00 0 256 64 float sum -1 310.8 0.00 0.00 0 304.9 0.00 0.00 0 512 128 float sum -1 304.9 0.00 0.00 0 300.8 0.00 0.00 0 1024 256 float sum -1 509.3 0.00 0.00 0 495.4 0.00 0.00 0 2048 512 float sum -1 530.3 0.00 0.00 0 420.0 0.00 0.00 0 4096 1024 float sum -1 391.2 0.01 0.01 0 384.5 0.01 0.01 0 8192 2048 float sum -1 328.5 0.02 0.02 0 253.2 0.03 0.03 0 16384 4096 float sum -1 497.6 0.03 0.03 0 490.9 0.03 0.03 0 32768 8192 float sum -1 496.7 0.07 0.07 0 425.0 0.08 0.08 0 65536 16384 float sum -1 448.0 0.15 0.15 0 501.0 0.13 0.13 0 131072 32768 float sum -1 577.4 0.23 0.23 0 593.4 0.22 0.22 0 262144 65536 float sum -1 757.8 0.35 0.35 0 721.6 0.36 0.36 0 524288 131072 float sum -1 1057.1 0.50 0.50 0 1019.1 0.51 0.51 0 1048576 262144 float sum -1 1460.5 0.72 0.72 0 1435.6 0.73 0.73 0 2097152 524288 float sum -1 2450.6 0.86 0.86 0 2583.1 0.81 0.81 0 4194304 1048576 float sum -1 4344.5 0.97 0.97 0 4419.3 0.95 0.95 0 8388608 2097152 float sum -1 8176.5 1.03 1.03 0 8197.8 1.02 1.02 0 16777216 4194304 float sum -1 15312 1.10 1.10 0 15426 1.09 1.09 0 33554432 8388608 float sum -1 30149 1.11 1.11 0 29941 1.12 1.12 0 67108864 16777216 float sum -1 57819 1.16 1.16 0 58635 1.14 1.14 0 134217728 33554432 float sum -1 115699 1.16 1.16 0 115331 1.16 1.16 0 268435456 67108864 float sum -1 227507 1.18 1.18 0 228047 1.18 1.18 0 536870912 134217728 float sum -1 453751 1.18 1.18 0 456595 1.18 1.18 0 1073741824 268435456 float sum -1 911719 1.18 1.18 0 911808 1.18 1.18 0 2147483648 536870912 float sum -1 1804971 1.19 1.19 0 1806895 1.19 1.19 0 2024-08-20T16:22:43.831-07:00 # Out of bounds values : 0 OK 2024-08-20T16:22:43.831-07:00 # Avg bus bandwidth : 0.488398 2024-08-20T23:22:43Z info Nccl test successful. Summary: NcclMaxAlgoBw: 1.190000, NcclAvgAlgoBw: 0.488398, NcclThresholdAlgoBw: 1.180000, NcclOutOfBoundError: OK, NcclOperations: all_reduce_perf, NcclTotalDevices: 2, NcclNodes: 2, NcclClusterMessage: ``` # 자동 노드 복구 클러스터 생성 또는 업데이트 중에 클러스터 관리자 사용자는 클러스터 수준의 `Automatic`(권장) 및 `None` 사이에서 노드(인스턴스) 복구 옵션을 선택할 수 있습니다. `Automatic`로 설정하면 SageMaker HyperPod가 자동으로 재부팅되거나 결함이 있는 노드를 교체합니다. **중요** `Automatic` 옵션을 설정하는 것이 좋습니다. 자동 노드 복구는 상태 모니터링 에이전트, 기본 상태 확인 및 심층 상태 확인에서 문제가 발견될 때 실행됩니다. `None`로 설정하면 상태 모니터링 에이전트는 오류가 감지될 때 인스턴스에 레이블을 지정하지만 영향을 받는 노드에서 복구 작업을 자동으로 시작하지는 않습니다. 이 옵션은 권장되지 않습니다. # SageMaker HyperPod의 복원력 관련 Kubernetes 레이블 *레이블*은 [Kubernetes 객체](https://kubernetes.io/docs/concepts/overview/working-with-objects/#kubernetes-objects)에 연결된 키-값 페어입니다. SageMaker HyperPod는 제공하는 상태 확인을 위해 다음 레이블을 도입합니다. ## 노드 상태 레이블 `node-health-status` 레이블은 노드의 상태를 나타내며 정상 노드에서 노드 선택기 필터의 일부로 사용됩니다. | Label | 설명 | | --- | --- | | sagemaker.amazonaws.com/node-health-status: Schedulable | 노드가 기본 상태 확인을 통과했으며 워크로드 실행에 사용할 수 있습니다. 이 상태 확인은 [Slurm 클러스터에 대해 현재 사용 가능한 SageMaker HyperPod 복원력 기능](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm.html)과 동일합니다. | | sagemaker.amazonaws.com/node-health-status: Unschedulable | 노드가 심층 상태 확인을 실행 중이며 워크로드 실행에 사용할 수 없습니다. | | sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReplacement | 노드가 심층 상태 확인 또는 상태 모니터링 에이전트 확인에 실패했으며 교체가 필요합니다. 자동 노드 복구가 활성화된 경우 SageMaker HyperPod에 의해 노드가 자동으로 교체됩니다. | | sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReboot | 노드가 심층 상태 확인 또는 상태 모니터링 에이전트 확인에 실패했으며 재부팅이 필요합니다. 자동 노드 복구가 활성화된 경우 SageMaker HyperPod에 의해 노드가 자동으로 재부팅됩니다. | ## 심층 상태 확인 레이블 `deep-health-check-status` 레이블은 특정 노드에 대한 심층 상태 확인의 진행 상황을 나타냅니다. Kubernetes 사용자가 전반적인 심층 상태 확인의 진행 상황을 빠르게 필터링하는 데 유용합니다. | Label | 설명 | | --- | --- | | sagemaker.amazonaws.com/deep-health-check-status: InProgress | 노드가 심층 상태 확인을 실행 중이며 워크로드 실행에 사용할 수 없습니다. | | sagemaker.amazonaws.com/deep-health-check-status: Passed | 노드가 심층 상태 확인 및 상태 모니터링 에이전트 확인을 성공적으로 완료했으며 워크로드를 실행하는 데 사용할 수 있습니다. | | sagemaker.amazonaws.com/deep-health-check-status: Failed | 노드가 심층 상태 확인 또는 상태 모니터링 에이전트 확인에 실패했으며 교체가 필요합니다. 자동 노드 복구가 활성화된 경우 SageMaker HyperPod에 의해 노드가 자동으로 재부팅되거나 교체됩니다. | ## 결함 유형 및 이유 레이블 다음은 `fault-type` 및 `fault-reason` 레이블에 대한 설명입니다. + `fault-type` 레이블은 상태 확인에 실패할 때 상위 수준 장애 범주를 나타냅니다. 이는 심층 상태 및 상태 모니터링 에이전트 확인 중에 식별된 장애에 대해 채워집니다. + `fault-reason` 레이블은 `fault-type`과 관련된 자세한 오류 이유를 나타냅니다. ## SageMaker HyperPod 레이블 지정 방법 다음 주제에서는 다양한 사례에 따라 레이블 지정을 수행하는 방법을 다룹니다. **Topics** + [심층 상태 확인 구성이 비활성화된 SageMaker HyperPod 클러스터에 노드가 추가되는 경우](#sagemaker-hyperpod-eks-resiliency-node-how-it-labels-when-dhc-is-off) + [심층 상태 확인 구성이 활성화된 SageMaker HyperPod 클러스터에 노드가 추가되는 경우](#sagemaker-hyperpod-eks-resiliency-node-how-it-labels-when-dhc-is-on) + [노드에 컴퓨팅 장애가 있는 경우](#sagemaker-hyperpod-eks-resiliency-node-how-it-labels-when-node-fails) ### 심층 상태 확인 구성이 비활성화된 SageMaker HyperPod 클러스터에 노드가 추가되는 경우 새 노드가 클러스터에 추가되고 인스턴스 그룹에 대해 심층 상태 확인이 활성화되지 않은 경우 SageMaker HyperPod는 [Slurm 클러스터에 대해 현재 사용 가능한 SageMaker HyperPod 상태 확인과 동일한 상태 확인을](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm.html) 실행합니다. 상태 확인이 통과하면 노드에 다음 레이블이 표시됩니다. ``` sagemaker.amazonaws.com/node-health-status: Schedulable ``` 상태 확인이 통과되지 않으면 노드가 종료되고 교체됩니다. 이 동작은 SageMaker HyperPod 상태 확인이 Slurm 클러스터에서 작동하는 방식과 동일합니다. ### 심층 상태 확인 구성이 활성화된 SageMaker HyperPod 클러스터에 노드가 추가되는 경우 새 노드가 SageMaker HyperPod 클러스터에 추가되고 인스턴스 그룹에 대해 심층 상태 확인 테스트가 활성화된 경우 HyperPod는 먼저 노드를 테인팅하고 노드에서 \$12시간 심층 상태 확인/스트레스 테스트를 시작합니다. 심층 상태 확인 후 노드 레이블의 출력은 3개일 수 있습니다. 1. 심층 상태 확인 테스트가 통과한 경우 ``` sagemaker.amazonaws.com/node-health-status: Schedulable ``` 1. 심층 상태 확인 테스트가 실패하고 인스턴스를 교체해야 하는 경우 ``` sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReplacement ``` 1. 심층 상태 확인 테스트가 실패하고 심층 상태 확인을 다시 실행하려면 인스턴스를 재부팅해야 하는 경우 ``` sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReboot ``` 인스턴스가 심층 상태 확인 테스트에 실패하면 인스턴스는 항상 교체됩니다. 심층 상태 확인 테스트에 성공하면 노드의 taint이 제거됩니다. ### 노드에 컴퓨팅 장애가 있는 경우 SageMaker HyperPod 상태 모니터링 에이전트는 각 노드의 상태도 지속적으로 모니터링합니다. 장애가 감지되면(예: GPU 장애 및 드라이버 충돌) 에이전트는 노드에 다음 레이블 중 하나를 표시합니다. 1. 노드가 비정상이고 교체해야 하는 경우 ``` sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReplacement ``` 1. 노드가 비정상이고 재부팅해야 하는 경우 ``` sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReboot ``` 상태 모니터링 에이전트는 노드 상태 문제를 감지할 때도 노드를 테인팅합니다. # 노드를 수동으로 격리, 교체 또는 Amazon EKS로 오케스트레이션된 SageMaker HyperPod 클러스터에서 결함이 있는 노드를 수동으로 격리, 교체 및 재부팅하는 방법을 알아봅니다. **노드를 격리하고 훈련 포드를 강제 삭제하려면** ``` kubectl cordon ``` 격리 후 포드를 강제로 배출합니다. 포드가 30분 이상 종료되지 않았거나 이벤트에서 '노드가 준비되지 않음'을 `kubectl describe pod`가 표시할 때 유용합니다. ``` kubectl delete pods --grace-period=0 --force ``` SageMaker HyperPod는 수동 노드 복구를 위한 두 가지 방법을 제공합니다. 선호하는 접근 방식은 모든 오케스트레이터에서 작동하는 더 빠르고 투명한 복구 프로세스를 제공하는 SageMaker HyperPod 재부팅 및 교체 APIs를 사용하는 것입니다. 또는 kubectl 명령을 사용하여 재부팅 및 대체 작업을 위해 노드에 레이블을 지정할 수 있습니다. 두 방법 모두 동일한 SageMaker HyperPod 복구 프로세스를 활성화합니다. **재부팅 API를 사용하여 노드를 재부팅하려면** 노드를 재부팅하려면 BatchRebootClusterNodes API를 사용할 수 있습니다. 다음은를 사용하여 클러스터의 두 인스턴스에서 재부팅 작업을 실행하는 예제입니다 AWS Command Line Interface. ``` aws sagemaker batch-reboot-cluster-nodes \ --cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \ --node-ids i-0123456789abcdef0 i-0fedcba9876543210 ``` **바꾸기 API를 사용하여 노드를 바꾸려면** 노드를 교체하려면 다음과 같이 BatchReplaceClusterNodes API를 사용할 수 있습니다. 다음은를 사용하여 클러스터의 두 인스턴스에서 교체 작업을 실행하는 예제입니다 AWS Command Line Interface. ``` aws sagemaker batch-replace-cluster-nodes \ --cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \ --node-ids i-0123456789abcdef0 i-0fedcba9876543210 ``` **Karpenter 관리형 클러스터** 노드 프로비저닝에 Karpenter를 사용하는 SageMaker HyperPod 클러스터의 경우 `BatchReplaceClusterNodes` API는 대체 노드가 생성된다고 보장하지 않습니다. 지정된 노드*는* 종료되지만 교체는 Karpenter의 pod-demand-based 프로비저닝 모델에 따라 달라집니다. Karpenter는 기존 노드에서 예약할 수 없는 `Pending` 상태의 포드가 있는 경우에만 새 노드를 생성합니다. 삭제된 노드의 워크로드를 클러스터의 나머지 노드로 다시 예약할 수 있는 경우(예: 해당 노드의 용량이 충분한 경우) Karpenter는 대체 노드를 프로비저닝하지 않습니다. 대체 노드가 생성되도록 하려면 워크로드 구성(예: 포드 친화도 방지 규칙 또는 리소스 요청)에 대체된 포드에 대한 새 노드가 필요한지 확인합니다. 이 제한 사항을 알고 있으며 API를 통해 요청 시 노드 교체를 적용하는 솔루션을 적극적으로 개발하고 있습니다. **kubectl을 사용하여 노드를 교체하려면** SageMaker HyperPod [자동 노드 복구](sagemaker-hyperpod-eks-resiliency-node-recovery.md)를 트리거하는 `sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReplacement`로 교체할 노드에 레이블을 지정합니다. 클러스터 생성 또는 업데이트 중에도 자동 노드 복구를 활성화해야 합니다. ``` kubectl label nodes \ sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReplacement ``` **kubectl을 사용하여 노드를 재부팅하려면** SageMaker HyperPod [자동 노드 복구](sagemaker-hyperpod-eks-resiliency-node-recovery.md)를 트리거하며 재부팅할 노드에 `sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReboot`로 레이블을 지정합니다. 클러스터 생성 또는 업데이트 중에도 자동 노드 복구를 활성화해야 합니다. ``` kubectl label nodes \ sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReboot ``` 레이블 `UnschedulablePendingReplacement` 또는를 `UnschedulablePendingReboot` 적용한 후 몇 분 내에 노드가 종료되거나 재부팅되는 것을 확인할 수 있습니다. # 권장 복원력 구성 심층 상태 확인이 활성화되면 새 인스턴스가 HyperPod 클러스터에 추가될 때마다(생성 클러스터 또는 자동 노드 교체 중) 새 인스턴스는 약 2시간 동안 심층 상태 확인 프로세스(인스턴스 수준 스트레스 테스트)를 거칩니다. 다음은 가능한 경우에 따라 권장되는 복원력 구성 조합입니다. 1. **사례**: 백업 리소스로 클러스터 내에 추가 예비 노드가 있거나(전체 용량을 사용하지 않음) 오류가 덜 발생하는 인스턴스를 가져오기 위해 심층 상태 확인 프로세스를 약 2시간 동안 기다릴 수 있는 경우. **권장 사항**: 클러스터 수명 주기 전반에 걸쳐 심층 상태 확인 구성을 활성화합니다. 노드 자동 복구 구성은 기본적으로 활성화되어 있습니다. 1. **사례**: 추가 백업 노드가 없는 경우(일부 훈련 로드에는 용량이 완전히 사용됨). 가능한 한 빨리 교체 노드를 가져와 훈련 작업을 재개하려고 합니다. **권장 사항**: 클러스터 생성 중에 심층 상태 확인을 활성화한 다음 클러스터가 생성된 후 심층 상태 확인 구성을 끕니다. 노드 자동 복구 구성은 기본적으로 활성화되어 있습니다. 1. **사례**: 추가 백업 노드가 없고 \$12시간 심층 상태 확인 프로세스(소형 클러스터)를 기다리지 않으려는 경우. **권장 사항**: 클러스터 수명 주기 동안 심층 상태 확인 구성을 비활성화합니다. 노드 자동 복구 구성은 기본적으로 활성화되어 있습니다. 장애 발생 즉시 훈련 작업을 재개하려면 클러스터에 백업 리소스로 추가 예비 노드가 있는지 확인합니다.