Appendix

GPU 가상화를 통한 컨테이너 별 GPU 분할 할당

Backend.AI 는 하나의 물리 GPU 를 여러 개로 분할해서 여러 사용자가 나누어 사용할 수 있는 가상화 기술을 지원하고 있습니다. 따라서, GPU 연산 소요가 크지 않은 작업을 수행하고자 할 경우에는 GPU 의 일부만 할당하여 연산 세션을 생성할 수 있습니다. 1 fGPU 가 실제로 할당하는 GPU 자원의 양은 관리자 설정에 따라 시스템 별로 다양할 수 있습니다. 예를 들어, 관리자가 하나의 GPU 를 다섯 조각으로 분할 설정한 경우, 5 fGPU 가 1 물리 GPU, 또는 1 fGPU 가 0.2 물리 GPU 를 뜻합니다. 이 때 1 fGPU 를 설정하여 연산 세션을 생성하면, 그 세션에서는 0.2 물리 GPU 에 해당하는 SM(streaming multiprocessor) 과 GPU 메모리를 활용할 수 있습니다.

이번에는 GPU 를 일부만 할당하여 연산 세션을 생성한 후 연산 컨테이너 내부에서 인식하는 GPU 가 정말 물리 GPU 의 일부분인지 확인 해보도록 하겠습니다.

먼저 호스트 노드에 장착되어 있는 물리 GPU 의 종류와 메모리 용량 등의 정보를 확인 해보겠습니다. 이 가이드를 작성하면서 사용한 GPU 노드에는 다음과 같이 8 GB 메모리의 GPU 가 장착되어 있습니다. 그리고 관리자 설정을 통해 1 fGPU 를 0.5 개의 물리 GPU(또는 1 개의 물리 GPU 가 2 fGPU) 에 해당하는 양으로 설정하였습니다.

../_images/host_gpu.png

이제 Sessions 페이지로 이동하여 다음과 같이 0.5 개의 fGPU 를 할당하여 연산 세션을 생성 해봅시다:

../_images/session_launch_dialog_with_gpu.png

연산 세션 리스트의 Configuration 열에서 0.5 의 fGPU 가 할당된 것을 확인할 수 있습니다.

../_images/session_list_with_gpu.png

이제 컨테이너에 직접 연결하여 할당 된 GPU 메모리가 실제로 0.5 단위 (~ 2GB)와 동일한지 확인하겠습니다. 웹 터미널을 띄웁니다. 터미널이 나타나면``nvidia-smi`` 명령을 실행합니다. 다음 그림에서 볼 수 있듯이 약 2GB의 GPU 메모리가 할당 되었음을 알 수 있습니다. 이는 물리적 GPU가 실제로 네 부분으로 나뉘어 이 연산 세션에 할당되었음을 보여줍니다. 이는 PCI 패스스루(passthrough0와 같은 방식으로는 불가능합니다.

../_images/nvidia_smi_inside_container.png

이번에는 Jupyter Notebook 을 띄워서 간단한 ML 학습 코드를 실행해보겠습니다.

../_images/mnist_train.png

학습이 진행되는 동안 GPU 호스트 노드의 쉘로 접속해서 nvidia-smi 명령을 실행합니다. 다음과 같이 하나의 GPU 사용 프로세스가 있고 이 프로세스는 물리 GPU의 약 25% 에 해당 하는 자원을 점유중임을 알 수 있습니다. (GPU 점유량은 학습 코드와 GPU 모델에 따라 크게 다를 수 있습니다.)

../_images/host_nvidia_smi.png

또는, 아까 띄워둔 웹 터미널에서 nvidia-smi 명령을 내려 컨테이너 내부에서 인식하는 GPU 사용 내역을 조회해보는 것도 가능합니다.

GUI 를 통한 자원 모니터링 및 스케줄링 자동화

Backend.AI 서버는 자체 개발한 작업 스케줄러를 내장하고 있습니다. 자동으로 모든 워커 (worker) 노드의 자원 상태를 확인하여 사용자의 자원 요청에 맞는 워커로 연산 세션 생성 요청을 위임 합니다. 또한, 자원이 부족할 경우에는 일단 작업 큐에 사용자의 연산 세션 생성 요청을 대기 (pending) 시키고 나중에 자원이 다시 가용 상태가 되면 대기 요청을 활성화 해서 연산 세션 생성 작업을 수행하게 됩니다.

사용자 Web-UI에서 간단한 방법으로 작업 스케줄러의 작동을 확인할 수 있습니다. GPU 호스트가 최대 2 단위의 fGPU를 할당 할 수있는 경우 1 단위의 fGPU 할당을 요청하는 3 개의 연산 세션을 동시에 생성해 보겠습니다. 세션 시작 대화 상자의 사용자 지정 할당 패널에는 GPU 및 세션 슬라이더가 있습니다. Sessions에서 1보다 큰 값을 지정하고 LAUNCH 버튼을 클릭하면 여러 개의 세션이 동시에 생성됩니다. GPU와 Sessions을 각각 1과 3으로 설정하겠습니다. 이는 fGPU가 2 단위밖에 없는 상황에서 총 3 단위의 fGPU를 요청하는 상황입니다.

../_images/session_launch_dialog_3_sessions.png

잠시 기다리면 세 개의 연산 세션이 나타납니다. 상태 패널을 자세히 살펴보면 세 개의 연산 세션 중 두 개는 RUNNING 상태에 있지만 다른 연산 세션은 PENDING 상태로 남아 있음을 알 수 있습니다. 이 PENDING 세션은 작업 대기열에만 등록되며 GPU 자원 부족으로 인해 실제로 컨테이너 할당을 받지 못했습니다.

../_images/pending_session_list.png

이제 RUNNING 상태의 세션 두 개 중 하나를 삭제 해보겠습니다. 그러면 PENDING 상태의 연산 세션은 곧 작업 스케줄러에 의해 자원을 할당 받고 RUNNING 상태로 변환되는 것을 볼 수 있습니다. 이처럼, 작업 스케줄러는 작업 큐를 활용해 사용자의 연산 세션 요청을 간직하고 있다가 자원이 가용해질 때 자동으로 요청을 처리하게 됩니다.

../_images/pending_to_running.png

Multi-version 머신러닝 컨테이너 지원

Backend.AI 는 다양한 ML 및 HPC 커널 이미지를 사전 빌드하여 제공 합니다. 따라서, 사용 자는 스스로 패키지 설치를 굳이 하지 않더라도 주요 라이브러리 및 패키지를 즉시 활용할 수 있습니다. 여기서는 다종 ML 라이브러리의 여러 버전을 즉시 활용하는 예제를 진행합니다.

Sessions 페이지로 이동하여 연산 세션 생성 다이얼로그를 엽니다. Backend.AI에서는 설치 환경에 따른 다양한 커널 이미지를 제공합니다.

../_images/various_kernel_images.png

여기서는 TensorFlow 2.3 환경을 선택하고 세션을 생성해보았습니다.

../_images/session_launch_dialog_tf23.png

생성된 세션의 웹 터미널을 열고 다음 Python 명령을 실행합니다. TensorFlow 2.3 버전이 실제 설치되어 있음을 확인할 수 있습니다.

../_images/tf23_version_print.png

이번에는 TensorFlow 1.15 환경을 선택해서 연산 세션을 생성합니다. (자원이 부족한 경우 이전 세션은 삭제합니다)

../_images/session_launch_dialog_tf115.png

생성된 세션의 웹 터미널을 열고 이전과 동일한 Python 명령을 실행합니다. TensorFlow 1.15(.4) 버전이 실제 설치되어 있음을 확인할 수 있습니다.

../_images/tf115_version_print.png

마지막으로 PyTorch 1.5 버전을 이용해서 연산 세션을 생성합니다.

../_images/session_launch_dialog_pytorch15.png

생성된 세션의 웹 터미널을 열고 다음 Python 명령을 실행합니다. PyTorch 1.5 버전이 실제 설치되어 있음을 확인할 수 있습니다.

../_images/pytorch15_version_print.png

이처럼, Backend.AI 를 통해 TensorFlow, PyTorch 등 주요 라이브러리의 다양한 버전을 불필요한 설치 노력 없이 활용할 수 있습니다.

Backend.AI 서버 설정 가이드

Backend.AI 데몬/서비스 구동을 위해서는 다음과 같은 하드웨어가 필요합니다. 최적 성능을 위해서는 아래 명기된 사양의 두 배 이상 필요합니다.

  • Manager: 2 cores, 4 GiB memory
  • Agent: 4 cores, 32 GiB memory, NVIDIA GPU (for GPU workload), > 512 GiB SSD
  • Webserver: 2 cores, 4 GiB memory
  • WSProxy: 2 cores, 4 GiB memory
  • PostgreSQL DB: 2 cores, 4 GiB memory
  • Redis: 1 core, 2 GiB memory
  • Etcd: 1 core, 2 GiB memory

각 서비스를 설치하기 전에 사전에 설치되어야 할 주요 의존 호스트 패키지는 다음과 같습니다:

  • Web-UI: 최신 브라우저를 구동할 수 있는 운영체제 (Windows, Mac OS, Ubuntu 등)
  • Manager: Python (≥3.8), pyenv/pyenv-virtualenv (≥1.2)
  • Agent: docker (≥19.03), CUDA/CUDA Toolkit (≥8, 11 recommend), nvidia-docker v2, Python (≥3.8), pyenv/pyenv-virtualenv (≥1.2)
  • Webserver: Python (≥3.8), pyenv/pyenv-virtualenv (≥1.2)
  • WSProxy: docker (≥19.03), docker-compose (≥1.24)
  • PostgreSQL DB: docker (≥19.03), docker-compose (≥1.24)
  • Redis: docker (≥19.03), docker-compose (≥1.24)
  • Etcd: docker (≥19.03), docker-compose (≥1.24)

엔터프라이즈 버전의 Backend.AI 서버 데몬은 래블업의 지원팀에서 설치합니다. 초기 설치 후 기본적으로 다음과 같은 자료 및 서비스가 제공됩니다:

  • DVD 1 장 (Backend.AI 패키지 포함)
  • 사용자 GUI 가이드 매뉴얼
  • 관리자 GUI 가이드 매뉴얼 (엔터프라이즈 고객 전용)
  • 설치 리포트
  • 사용자/관리자 초기 방문 교육 (3-5 시간)

제품의 유지보수 및 지원 정보: 상용 계약에는 기본적으로 엔터프라이즈 버전의 월간/연간 구독 사용료가 포함됩니다. 최초 설치 후 약 2주 간 초기 사용자/관리자 교육 (1-2 회) 및 유무선 상의 고객 지원 서비스가 제공되며, 3-6 개월 간 마이너 릴리즈 업데이터 지원 및 온라인 채널을 통한 고객 지원 서비스가 제공됩니다. 이후 제공되는 유지보수 및 지원 서비스는 계약 조건에 따라 세부 내용이 다를 수 있습니다.

오픈소스 무료 버전 사용자의 경우에도 유지보수 및 지원 플랜을 별도로 구입할 수 있습니다.

간단한 Backend.AI 서버 관리 가이드

Backend.AI 는 여러 개의 모듈과 데몬으로 구성되어 있습니다. 여기서는 각 서비스에 관한 짧은 설명과 서비스 별로 문제가 발생하였을 때 사용할 수 있는 간단한 관리 가이드를 제공합니다. 관리 명령은 일반적으로 사용 가능하지만, 호스트 별 설치 상황에 따라 구체적인 사항은 달라질 수 있습니다.

Manager

사용자로부터 오는 모든 요청을 받아 처리하는 게이트웨이 서버입니다. 사용자의 요청이 연산 세션(컨테이너)과 관련 있다면, 해당 세션을 관리하는 Agent 또는 해당 컨테이너로 작업을 위임합니다.

# check status
sudo systemctl status backendai-manager
# start service
sudo systemctl start backendai-manager
# stop service
sudo systemctl stop backendai-manager
# restart service
sudo systemctl restart backendai-manager
# see logs
sudo journalctl --output cat -u backendai-manager

Agent

연산 워커 노드입니다. 연산 세션 (컨테이너) 의 수명주기를 관리합니다.

# check status
sudo systemctl status backendai-agent
# start service
sudo systemctl start backendai-agent
# stop service
sudo systemctl stop backendai-agent
# restart service
sudo systemctl restart backendai-agent
# see logs
sudo journalctl --output cat -u backendai-agent

Webserver

사용자 웹 GUI 환경을 제공하고, 이메일/비밀번호 기반의 사용자 인증 또한 지원합니다.

# check status
sudo systemctl status backendai-webserver
# start service
sudo systemctl start backendai-webserver
# stop service
sudo systemctl stop backendai-webserver
# restart service
sudo systemctl restart backendai-webserver
# see logs
sudo journalctl --output cat -u backendai-webserver

WSProxy

사용자가 띄운 웹기반 앱 (터미널, Jupyter Notebook 등) 과 매니저 사이의 통신을 중계하는 서비스입니다.

cd /home/lablup/halfstack
# check status
docker-compose -f docker-compose.wsproxy-simple.yaml -p <project> ps
# start service
docker-compose -f docker-compose.wsproxy-simple.yaml -p <project> up -d
# stop service
docker-compose -f docker-compose.wsproxy-simple.yaml -p <project> down
# restart service
docker-compose -f docker-compose.wsproxy-simple.yaml -p <project> restart
# see logs
docker-compose -f docker-compose.wsproxy-simple.yaml -p <project> logs

PostgreSQL DB

Manager 가 사용하는 데이터베이스입니다.

cd /home/lablup/halfstack
# check status
docker-compose -f docker-compose.hs.postgres.yaml -p <project> ps
# start service
docker-compose -f docker-compose.hs.postgres.yaml -p <project> up -d
# stop service
docker-compose -f docker-compose.hs.postgres.yaml -p <project> down
# restart service
docker-compose -f docker-compose.hs.postgres.yaml -p <project> restart
# see logs
docker-compose -f docker-compose.hs.postgres.yaml -p <project> logs

DB 를 백업하기 위해서는 다음과 같은 명령을 사용할 수 있습니다. 구체적인 명령은 설치 환경에 따라 다양할 수 있습니다.

# query postgresql container's ID
docker ps | grep halfstack-db
# Connect to the postgresql container via bash
docker exec -it <postgresql-container-id> bash
# Backup DB data. PGPASSWORD may vary depending on the system configuration
PGPASSWORD=develove pg_dumpall -U postgres > /var/lib/postgresql/backup_db_data.sql
# Exit container
exit

백업 데이터를 통해 DB 를 복원하려면 다음과 같은 명령을 실행할 수 있습니다. 구체적인 옵션은 설치 환경에 따라 다양할 수 있습니다.

# query postgresql container's ID
docker ps | grep halfstack-db
# Connect to the postgresql container via bash
docker exec -it <postgresql-container-id> bash
# Disconnect all connection, for safety
psql -U postgres
postgres=# SELECT pg_terminate_backend(pg_stat_activity.pid)
postgres-# FROM pg_stat_activity
postgres-# WHERE pg_stat_activity.datname = 'backend'
postgres-# AND pid <> pg_backend_pid();
# Ensure previous data be cleaned (to prevent overwrite)
postgres=# DROP DATABASE backend;
postgres=# \q
# Restore from data
psql -U postgres < backup_db_data.sql

Redis

캐시 서비스로, Agent 와 연산 세션의 사용량 정보를 수집하고, Agent 에서 Manager 로 가는 heartbeat 신호를 중계합니다. 사용자의 로그인 인증 정보를 보관하기도 합니다.

cd /home/lablup/halfstack
# check status
docker-compose -f docker-compose.hs.redis.yaml -p <project> ps
# start service
docker-compose -f docker-compose.hs.redis.yaml -p <project> up -d
# stop service
docker-compose -f docker-compose.hs.redis.yaml -p <project> down
# restart service
docker-compose -f docker-compose.hs.redis.yaml -p <project> restart
# see logs
docker-compose -f docker-compose.hs.redis.yaml -p <project> logs

일반적으로, Redis 데이터를 백업할 필요가 없습니다. 사용자 로그인 세션 쿠키 정보, 컨테이너 별 실시간 사용량 등과 같은 일시적으로만 존재하면 되는 정보를 저장하고 있기 때문입니다.

Etcd

설정 서버로, Backend.AI 의 전역 설정값을 보관하고 있습니다.

cd /home/lablup/halfstack
# check status
docker-compose -f docker-compose.hs.etcd.yaml -p <project> ps
# start service
docker-compose -f docker-compose.hs.etcd.yaml -p <project> up -d
# stop service
docker-compose -f docker-compose.hs.etcd.yaml -p <project> down
# restart service
docker-compose -f docker-compose.hs.etcd.yaml -p <project> restart
# see logs
docker-compose -f docker-compose.hs.etcd.yaml -p <project> logs

Manager 에서 사용하는 Etcd 설정 데이터를 백업하려면 Manager 가 설치된 폴더로 이동한 후 다음과 같은 명령을 사용하면 됩니다.

cd /home/lablup/manager  # paths may vary
backend.ai mgr etcd get --prefix '' > etcd_backup.json

백업 데이터를 통해 Etcd 설정을 복원하려면 다음과 같은 명령을 실행할 수 있습니다.

cd /home/lablup/manager  # paths may vary
backend.ai mgr etcd put-json '' etcd_backup.json