728x90
왜 장애 노드 복구 자동화가 필요한가
HPC/GPU 클러스터 운영에서 노드 장애는 피할 수 없습니다.
GPU ECC 에러, 파일시스템 손상, OS 패키지 충돌, Slurm 설정 불일치 등 다양한 원인으로 노드가 비정상 상태가 될 수 있습니다.
특히 생산 환경에서는 **MTTR(Mean Time To Recovery)**를 최소화하는 것이 중요합니다.
Ansible을 활용하면 다음과 같은 복구가 가능합니다.
- 장애 노드 OS/패키지 재설정
- GPU 드라이버·CUDA 재설치
- Slurm/K8s 설정 복구
- 이전 버전 구성으로 롤백
1. 복구 자동화 구성 개념
복구 Playbook은 크게 3단계로 구성됩니다.
- 상태 진단: 노드 연결 여부, 서비스 상태, GPU 헬스 체크
- 복구 실행: 패키지·설정 재배포, 서비스 재시작
- 검증 및 보고: 정상 동작 확인, 결과 보고서 생성
2. Inventory 예시
[all:vars]
ansible_user=hpcadmin
ansible_ssh_private_key_file=~/.ssh/id_rsa
rollback_version=v1.2.3
[failed_nodes]
node03 ansible_host=192.168.0.13
node07 ansible_host=192.168.0.17💡 rollback_version 변수는 복구 시 적용할 버전 태그를 지정합니다.
GitOps 환경이라면 해당 버전의 설정/패키지를 체크아웃해 배포합니다.
3. 장애 노드 복구 Playbook
# node_recovery.yaml
- hosts: failed_nodes
become: yes
tasks:
- name: 네트워크 연결 확인
ping:
- name: GPU 상태 확인
shell: nvidia-smi --query-gpu=name,temperature.gpu,utilization.gpu --format=csv
register: gpu_health
changed_when: false
- debug:
var: gpu_health.stdout_lines
- name: 장애 노드 공통 패키지 재설치
apt:
name:
- slurm-wlm
- nvidia-driver-535
- cuda-toolkit-12-2
state: present
- name: 설정 파일 복구
template:
src: "templates/{{ rollback_version }}/slurm.conf.j2"
dest: /etc/slurm/slurm.conf
- name: 서비스 재시작
systemd:
name: "{{ item }}"
state: restarted
enabled: yes
loop:
- slurmd
- kubelet
4. 롤백 자동화 개념
롤백은 주로 버전 태그 기반으로 동작합니다.
- Git 저장소에서 해당 버전 체크아웃
- 해당 버전의 설정 파일·스크립트를 Ansible로 배포
- 패키지 버전도 고정 설치
5. 롤백 Playbook 예시
# rollback.yaml
- hosts: failed_nodes
become: yes
vars:
rollback_tag: "{{ rollback_version }}"
tasks:
- name: Git 저장소에서 롤백 버전 가져오기
git:
repo: git@repo.example.com:hpc-configs.git
dest: /tmp/hpc-configs
version: "{{ rollback_tag }}"
- name: 롤백 버전 Slurm 설정 배포
copy:
src: "/tmp/hpc-configs/slurm.conf"
dest: /etc/slurm/slurm.conf
owner: root
group: root
mode: 0644
- name: GPU 드라이버 버전 고정 설치
apt:
name: nvidia-driver-525
state: present
6. 검증 및 보고 자동화
복구/롤백 후에는 반드시 검증 단계를 거쳐야 합니다.
- name: Slurm 노드 상태 확인
command: sinfo -N -l
register: sinfo_out
changed_when: false
- name: 결과 저장
local_action:
module: copy
content: "{{ sinfo_out.stdout }}"
dest: "./recovery_report_{{ inventory_hostname }}.txt"보고서에는 GPU 상태, Slurm 인식 상태, 서비스 가동 여부가 포함됩니다.
7. 운영 시나리오
| 상황 | 대응 방식 |
| GPU 드라이버 업데이트 실패 | 롤백 Playbook 실행, 이전 버전 복원 |
| Slurm 설정 불일치 | Git에서 최신 버전 가져와 재배포 |
| 노드 부팅 실패 | PXE Boot 또는 OS 이미지 재설치 후 Playbook 실행 |
| K8s Device Plugin 장애 | 해당 노드 kubelet 재설정 및 재시작 |
8. 안정성·효율성 팁
- Serial 모드(--serial)로 한 번에 1~2대씩 복구
- Tags로 필요한 작업만 선택 실행 (--tags "rollback")
- GPU Health Check를 별도 스크립트로 만들어 사전 검증
- 복구 대상 노드 IP를 동적으로 수집하여 Inventory 자동 생성
정리하며
Ansible 기반 장애 노드 복구·롤백 자동화는 HPC/GPU 운영에서 MTTR 단축에 핵심 역할을 합니다.
버전 태그·템플릿·자동 검증을 조합하면 안정성과 일관성을 확보할 수 있으며,
대규모 클러스터에서도 안전하게 장애 대응이 가능합니다.
다음 30편부터는 GPU 인프라 최적화 파트로 넘어가,
NVIDIA H100/H200 아키텍처 심층 분석부터 다루겠습니다.
728x90