OpenShift에서 RBLN NPU를 위한 커널 파라미터 설정 (Supermicro AMD)¶
이 문서는 OpenShift 환경에서 RBLN NPU Operator를 사용할 때 필요한 커널 부트 파라미터를 설정하는 방법을 설명합니다.
이러한 파라미터는 디바이스의 안정적인 동작을 위해 필요하며, NPU 워크로드가 스케줄링되는 노드에 반드시 적용되어야 합니다. 설정은 OpenShift MachineConfig Operator(MCO)를 통해 수행됩니다.
이 설정이 적용되지 않으면, NPU가 정상적으로 동작하지 않을 수 있습니다.
대상 하드웨어¶
이 가이드는 다음 환경에서 검증되었습니다:
| 항목 | 값 |
|---|---|
| 벤더 | Supermicro |
| CPU | AMD |
| NPU | RBLN-CA25 |
| 드라이버 | RBLN Driver v3.0.0 |
커널 파라미터¶
다음 커널 파라미터는 NPU의 안정적이고 최적의 동작을 위해 필요합니다:
| 파라미터 | 설명 |
|---|---|
transparent_hugepage=madvise |
THP를 madvise 모드로 설정. 애플리케이션이 madvise(MADV_HUGEPAGE)로 명시적으로 요청한 영역에만 THP 적용 |
pcie_aspm=force |
PCIe Active State Power Management 강제 활성화 |
pci=pcie_bus_perf |
PCIe 버스 성능 최적화 모드 설정 |
pci=bfsort |
PCI 디바이스 BFS(Breadth-First Search) 정렬 활성화 |
iommu.strict=1 |
IOMMU strict 모드 활성화 (DMA unmap 시 즉시 IOTLB flush) |
사전 요구사항¶
- OpenShift Container Platform 4.x 클러스터
cluster-admin권한- OpenShift CLI(
oc) 설치 및 로그인 완료 - (선택) Node Feature Discovery Operator v0.16+ — 자동 하드웨어 식별 사용 시 필요
하드웨어 식별¶
MachineConfig를 적용하기 전에 대상 노드가 Supermicro AMD 서버인지 확인합니다.
수동 확인¶
기대 출력:
(선택) NFD NodeFeatureRule을 활용한 자동 식별¶
NFD v0.16+에서는 system.dmiid.sys_vendor feature를 통해 노드의 DMI 벤더 정보를 읽을 수 있습니다. NodeFeatureRule을 작성하면 조건에 맞는 노드에 자동으로 커스텀 라벨을 부여할 수 있습니다.
Note
system.dmiid는 NFD 내장 feature이지만, 자동으로 라벨이 생성되지는 않습니다. 반드시 NodeFeatureRule을 작성해야 합니다.
참고 문서:
NodeFeatureRule 생성¶
라벨 확인¶
적용 후 대상 노드에서 아래 라벨이 자동 생성되는지 확인합니다:
기대 출력:
NFD 라벨을 MCP nodeSelector에 활용¶
NFD 라벨이 활성화되면 수동 node-role 라벨링 없이 MCP의 nodeSelector에서 직접 활용할 수 있습니다. 이 경우 커스텀 MachineConfigPool 생성의 MCP YAML에서 nodeSelector를 아래와 같이 변경합니다:
이렇게 구성하면 Supermicro AMD 노드가 클러스터에 추가될 때 자동으로 MCP에 포함되어, 수동 라벨링 없이 커널 파라미터가 적용됩니다.
커널 파라미터 적용¶
Warning
MachineConfig의 machineconfiguration.openshift.io/role 라벨이 worker로 설정되면, 해당 설정은 기본 worker MCP에 적용됩니다.
1 2 3 | |
아래 절차에서 __MCP_NAME__을 대상 환경에 맞는 이름으로 변경하세요. (예: smci-ca25-amd)
사전 확인¶
커스텀 MachineConfigPool 생성¶
Note
NFD 자동 식별을 사용하는 경우 nodeSelector를 NFD 라벨을 MCP nodeSelector에 활용의 NFD 라벨로 대체하세요.
MCP 상태 확인:
MachineConfig 적용¶
MachineConfig 이름 규칙 (99- prefix)¶
MCO는 MachineConfig를 이름의 사전순으로 정렬한 뒤 순차적으로 병합하여 최종 rendered config를 생성합니다. 숫자 prefix는 적용 우선순위를 결정합니다:
| Prefix | 용도 |
|---|---|
00- |
OpenShift 기본 설정 (예: 00-worker) |
01- |
기본 런타임/kubelet 설정 |
50- |
운영 커스텀 설정 |
99- |
사용자 커스텀 설정 (최후에 병합, 기존 설정 override) |
99- prefix를 사용하면 기존 OpenShift 기본 MC보다 나중에 병합되어, 커널 파라미터가 최종 config에 확실히 반영됩니다.
멱등성¶
MCO는 MachineConfig 적용 시 선언적(declarative) 방식으로 동작합니다. 동일한 MC를 다시 oc apply하거나, 이미 적용된 커널 파라미터와 동일한 MC가 존재하는 경우:
- MCO가 현재 rendered config와 새 rendered config를 비교합니다.
- 변경이 없으면 노드 재부팅이 발생하지 않습니다.
- MCP 상태는
UPDATED=True를 유지합니다.
즉, 이미 동일한 커널 파라미터가 적용된 상태에서 같은 MC를 다시 apply해도 불필요한 재부팅 없이 안전하게 무시됩니다.
롤아웃 모니터링¶
MachineConfig 적용 후 MCO가 대상 노드를 자동으로 cordon → drain → reboot 합니다.
검증¶
커널 파라미터 확인¶
아래 파라미터가 cmdline 출력에 포함되어 있는지 확인합니다:
transparent_hugepage=madvisepcie_aspm=forcepci=pcie_bus_perfpci=bfsortiommu.strict=1
THP 상태 확인¶
기대 출력:
MCP 최종 상태 확인¶
| 필드 | 기대값 |
|---|---|
| UPDATED | True |
| UPDATING | False |
| DEGRADED | False |
롤백¶
문제 발생 시 MachineConfig를 삭제하면 원래 커널 파라미터로 복원됩니다.
Warning
아래 삭제 순서를 반드시 준수하세요. 순서를 지키지 않으면 노드가 Degraded 상태에 빠질 수 있습니다. (복구 방법: Degraded 복구)
롤백 절차¶
삭제 순서:
Step 1. MachineConfig 삭제
Step 2. 롤아웃 완료 대기
MCO가 kargs 없는 config를 re-render하고 노드를 재부팅합니다. 반드시 완료될 때까지 대기합니다.
Step 3. 커널 파라미터 제거 확인
이전에 추가한 커널 파라미터가 없는지 확인합니다:
정리¶
커널 파라미터 제거 확인 후 MCP와 라벨을 정리합니다.
Step 4. 노드 라벨 제거
Step 5. MCP 삭제
트러블슈팅¶
Degraded 복구¶
증상: MCP 또는 노드 라벨을 MC보다 먼저 삭제한 경우, 노드의 currentConfig annotation이 이미 삭제된 rendered MachineConfig를 참조하여 Degraded 상태에 빠집니다.
원인: MCO는 MC를 삭제할 때 해당 MCP에 소속된 노드에 대해서만 re-render를 수행합니다. 노드가 MCP에서 이탈한 상태에서 MC를 삭제하면 MCO가 처리할 대상 노드가 없어 커널 파라미터가 그대로 남게 됩니다.
복구 절차: