NVIDIA deepops는 GPU 서버 클러스터 배포 및 하나의 강력한 GPU 노드(NVIDIA DGX System과 같은) 를 공유하여 사용 가능하도록 캡슐화(encapsulate) 해 주는 오픈소스 프로젝트이다. 거창해보이는 설명이지만, 좀 더 담백하게 풀어 말하자면, GPU HPC 클러스터를 쉽게 구성할 수 있도록 도와주는 SOTA 도구들을 뽑아놓은 ansible 모듈 오픈소스라고 볼 수 있다.
DeepOps를 활용하면 script 와 playbook 몇 개로 필요한 도구를 설치하고 환경변수를 설정할 수 있다. 각각의 도구를 모든 노드에 동일하게 설치하고 클러스터를 구성하는 작업을 할 필요 없이 자동으로 모든 것이 실행되므로 획기적으로 빠르게 클러스터를 구성할 수 있다.
설치하기에 앞서 mgmt node(master node)와 실제 GPU를 장착한 working node, 설치를 위한provisioning node를 준비한다. provisioning node는 mgmt node중 아무거나 하나 골라서 사용해도 무방하며, VM을 한 대 준비하거나 개인 desktop을 이용하는 것도 가능하다. SSH를 통해 ansible이 각 노드에 접근할 수 있는 디바이스이기만 하면 충분하다.
모든 설치는 provisioning node에서 실행된다.
deepops github 저장소에서 소스코드를 다운로드 받은 후 원하는 버전을 체크아웃한다. 이후 scripts/setup.sh 스크립트를 실행해 ansible 설치 및 기본 폴더를 구성한다.
source ./scripts/setup.sh
deepops 실행을 위해 먼저 configuration을 수정해야 한다.
config/inventory 파일을 열어 다음과 같이 항목들을 수정한다.
아래 예시는 kubernetes cluster 구성 예시이다.
mgmt 노드는 kubernetes master 노드, gpu 노드는 kubernetes work node로 구성하였다.
[all]
mgmt01 ansible_host=10.128.0.10 # ssh reachable한 manager IP 주소
gpu01 ansible_host=10.128.0.11 #ssh reachable한 gpu server IP 주소
[etcd]
mgmt01
[kube-master]
mgmt01
[kube-node]
gpu01
[all:vars]
# SSH User
ansible_user=deepops #ssh 접속 가능 계정
ansible_ssh_private_key_file='~/.ssh/id_rsa'
Kubernetes 클러스터의 환경설정은 config/group_vars/k8s-cluster.yml 파일에서 수정 가능하다.
아래 예시는 kubernetes cluster 구성 예시이다.
[all]
mgmt01 ansible_host=10.128.0.10 # ssh reachable한 manager IP 주소
gpu01 ansible_host=10.128.0.11 #ssh reachable한 gpu server IP 주소
######
# SLURM
######
[slurm-master]
mgmt01
[slurm-node]
gpu01
[slurm-cluster:children]
slurm-master
slurm-node
[all:vars]
# SSH User
ansible_user=deepops #ssh 접속 가능 계정
ansible_ssh_private_key_file='~/.ssh/id_rsa'
Slurm 클러스터의 환경 설정은 config/group_vars/slurm-cluster.yml 파일에서 수정 가능하다.
playbook 파일을 사용해 클러스터 설치를 할 수 있다.
ansible-playbook -l k8s-cluster playbooks/k8s-cluster.yml #k8s cluster 구성
ansible-playbook -l slurm-cluster playbooks/slurm-cluster.yml #slurm cluster 구성
ssh + sudo 비밀번호를 요구할 경우 -kK 옵션을 맨 뒤에 추가해준다.
deepops에서 제공하는 두 가지 플랫폼인 k8s와 slurm은 각각 사용해본 결과 다음의 장단점이 있다. 필요한 워크로드에 따라 선정하면 된다.
플랫폼 | 장점 | 한계 |
---|---|---|
k8s | 컨테이너 오케스트레이션을 위한 풍부한 기능 제공 기존 애플리케이션보다 유연하게 확장할 수 있는 클라우드 네이티브 기술과 컨테이너 기반 마이크로서비스를 더 잘 관리할 수 있음 컨테이너화된 워크로드만 사용할 계획이라면 Kubernetes는 매우 빠른 솔루션을 제공 가능 Kubeflow를 배포하여 ML 워크플로를 구축하고 배포하기 위한 플랫폼을 제공받을 수 있음. | lab scale을 넘어선 대규모 클러스터에서 관리의 용이성이 떨어짐. Container 를 pod/deployment 등의 레벨로 격리하는 과정에서 더 많은 하드웨어 오버헤드가 발생 |
Slurm | 일반적인 HPC 프레임워크와 통합하여 사용할 수 있는 유연성 Cray's ALPS(Application Level Placement Scheduler)와 결합하여 대규모 앱 구축 가능 Batch HPC에 최적화 batch scheduling, gang scheduling 지원으로 다중 노드 작업에 대한 지원이 우수함 대기열 관리, Backfill 스케줄링, 사용자 계정에 대한 완벽한 기능 제공 컨테이너 작업도 배포 가능 | 컨테이너 오케스트레이션의 요소 중 스케줄링을 제외한 나머지 요소들 (배포자동화, 오토스케일링 등)은 부족함. |
안녕하세요? 좋은 글 감사합니다! 다름이 아니라 질문이 하나 있어서 이렇게 댓글 남겼습니다.
'공통 프레임워크와 통합하여 사용할 수 있는 유연성' 에서 공통 프레임워크란 어떤것을 말씀하시는 걸까요?
'Application Launch & Provisioning System 과 결합하여 대규모 앱 구축 가능' 에서 'Application Launch & Provisioning System' 이란 어떤것을 말씀하시는 걸까요?
이해가 부족하여 이렇게 질문 드린점 죄송하게 생각합니다! 미리 정말 감사드립니다!