1. 요약

HPC시스템을 활용하고 있는 기업과 연구소의 업무환경을 최적화 하기 위해서는 많은 고려사항이 있다. HPC 시스템 구축 시, 기본적인 성능을 결정하는 것으로는 CPU의 계산속도, 메모리 보유량, 버스속도 그리고 인터커낵션을 위한 네트워크 장비 등과 같은 많은 요소들이 존재한다. 하지만 작업관리 솔루션을 통해서 구축된 HPC 시스템의 효율성을 높이는 것 또한 HPC시스템의 성능향상에 버금가는 중요한 포인트라고 할수 있다. 이러한 점에서 사용자들이 요청한 작업들의 워크로드를 관리하는 PBS Works 솔루션은 다양한 작업배분(Dispatch)를 통한 사용자 실행환경 최적화, HPC시스템 자원관리 (HPC Resource Management)을 통해 HPC 시스템의 효율성을 증대 시키며 정확한 사용이력 분석 데이터(Analytics)를 제공하므로써 향 후 시스템 확장 계획에 가이드라인을 제시한다.

2. 개요

HPC 클러스터를 도입하므로써 기대할 수 있는 일반적인 효과는 대형 해석과제를 HPC시스템과 병렬계산법을 활용하여 빠른 시간 내에 검증할 수 있다는 것이다.이러한 HPC시스템을 다수의 사용자가 효율적으로 관리하고 사용하기 위해서는 고려해야 할 많은 요소들이 있지만 사용자가 요청한 계산작업을 관리하는 미들웨어인 작업스케줄러(Workload Manager)도 필수적인 요소 중에 하나로 고려되고 있다. 작업스케줄러 도입관점에서 고성능의 HPC시스템을 많은 사용자들이 원활하게 공유하고 사용하기 위한 사용자 실행환경 최적화 작업이 중요한 포인트가 될 수 있다. 다시 말하면 다양한 해석업무의 특징을 파악하고 그에 적합한 관리 정책이 수반되어야 한다. 예를들어, 파견 및 부서이동, 신규 프로젝트 수행등과 같은 경우라도 개인의 연구 작업환경을 그대로 유지하고 동일한 작업환경을 제공해야 한다. 일반적인 경우, 사용자의 다양한 요구사항을 1회 유지관리 작업을 통하여 모든사용자들에게 일괄 적용되어야 하며 또한 사용자들에게는 사용하기 쉬운 사용자 실행 환경을 제공해야 한다. HPC시스템의 효율적인 활용을 위한 필수 항목 중 시스템의 자원에 대한 세부적인 정보를 인식하고 관리하는 HPC자원관리 (Resource Management) 기능이 있다. 작업스케줄러는 하드웨어 자원(CPU, Memory, Disk)뿐 아니라 소프트웨어의 라이선스 및 네트워크 토폴로지 정보와 같은 세부자원들을 관리 하므로써 실행이 요구되는 해석작업의 특성에 맞추어 최적의 계산자원에 작업을 배분(Disfetch)하고 그 결과를 보장 해야한다. 이 글은 사용자 실행환경 최적화와 HPC자원관리라는 2가지 목적으로 PBS Works 솔루션 활용법에 대해서 기술하고자 한다.

3. 사용자 실행환경 최적화

PBS Works의 기본 스케줄링 정책은 FIFO(First In First Out)이지만 설정에 따라서 사용자(user)/부서(group)/큐(queue)에 우선순위를 부가할 수 있다. 또한 최적의 장비선정을 위해서 CPU(속도/개수/부하), 디스크(용량/전송대역), 네트워크 토폴로지, 메모리 보유량, 병렬계산을 위한 인터커낵션(inter-connection)타입, OS(Operating System)타입 등을 고려하여 적절한 계산자원 순서로 정렬(Sort)한다. 앞에서 언급한 기본 기능 외에 효율성을 높이기 위한 PBS Works의 고급 기능인 Hook, Tunable Formula, Check Point를 소개한다.

Hook 기능

Hook의 기본개념은 사용자들의 작업제출 과정에서 일어나는 모든 이벤트에 인터럽트를 발생시키고 특정 스크립트를 실행시켜 작업 또는 사용자를 핸들링할 수 있다는 것이다. 예를 들어 관리자가 원할 경우 사용자가 범하기 쉬운 작업 제출 상의 오류를 Hook기능을 통해 보정하거나 관리정책에 맞도록 핸들링 할 수 있다. Hook를 통해 관리자가 인터럽트 할 수 있는 이벤트는 [표1]과 같다. Hook는 qmgr을 통해 [예제1]와 같이 간단하게 설정이 가능하며 파이썬스크립트를 통해 작동된다.

[표1] Hook가 핸들링하는 이벤트

qsub :사용자가 작업을 제출
qalter : 사용자가 대기중(queueing)인 작업의 속성을 변경
qmove : 사용자가 대기중(queuing)인 작업을 다른 클러스터(cluster)나 큐로(queue) 변경
pbs_rsub : 사용자가 원하는 시간에 특정 리소스를 사용하기위해 작업실행을 예약
qrun : 사용자가 대기중인 작업을 실행

[예제1] Qmgr을 통한 Hook 설정

Qmgr: set hook event =
Qmgr: create hook hook1
Qmgr: import hook hook1 application/x-python
Qmgr: set hook hook1 event = queuejob
Qmgr: set hook hook1 order = 2
Qmgr: set hook hook1 alarm = 60
Qmgr: set hook hook1 enabled = True

[예제2],[예제3]은 사용자가 8개의 CPU를 요청한 작업이지만 PPN의 값이 24이기 때문에 실제로 제출은 되었으나 Q상태에 머물며 작업이 실행되지 않게 된다. Hook기능을 통해 CPUS의 요청된 값은 24로 바꾸어 보정해주게 되면 작업실행이 가능하다.

[예제2] Qmgr을 통한 Hook 실행스크립트 등록

# Qmgr 명령을 통해 Hook를 만들고 동작 스크립트를 등록한다.
qmgr -c ‘create hook ChangeNcpus event=”queuejob”
qmgr -c ‘import hook ChangeNcpus application/x-python default ChangeNcpus.py’

[예제3] 잘못 요청된 CPU개수를 보정하는 Hook 실행스크립트

# 실제 동작 될 ChangeNcpus.py 스크립트
import pbs
import sys
try: je = pbs.event()
j = je.job
j.Resource_List[“ncpus”] =
max(j.Resource_List[“ncpus”],
j.Resource_List[“ppn”])
except SystemExit:
pass

except (pbs.UnsetResourceNameError, pbs.BadResourceVal- Error):
je.reject(“Failed to reset ncpus value”)

간단한 예제를 보았고 스크립트로 실행되는 Hook기능의 응용범위는 매우 광범위하다.
HPC 시스템이 자동 PXE 부팅이 지원된다면 아래의 예제처럼 Hook기능을 사용하여 사용자가 원하는 OS(Operating System)를 선택하여 사용하는 것(OS Provisioning)도 가능하다.

[예제4] OS 프로비져닝을 위한 Hook 실행스크립트 등록

Qmgr: set node V1 resources_available.aoe = “rhel, sles”
Qmgr: set node pluto current_aoe = sles10
Qmgr: create hook Provision_Hook
Qmgr: import hook Provision_Hook application/x-python default /root/data/master_provision.py
Qmgr: set hook Provision_Hook enabled = True
Qmgr: export hook Provision_Hook application/x-python default /usr/user1/hook_contents

[예제5] OS 프로비져닝을 위한 Hook 실행스크립트

# 실제 동작 될 master_provision.py 스크립트
import pbs
import os
e = pbs.event()
vnode = e.vnode
aoe = e.aoe
if (aoe == “sles10″):
appret = os.system(“/var/user/app_prov.sh” + vnode + ” ” + aoe );
if appret != 1:
e.reject(“Provisioning without rebootfailed”, 210)
else:
e.accept(1)
ret = os.system(“/var/vendor/vendorprov.sh” + vnode + ” ” + aoe );
if ret != 0:
e.reject(“Provisioning with reboot failed”, 211)
else:
e.accept(0)

Tunable Formula

일반적으로 작업스케줄러는 제출된 작업들의 우선순위를 결정하기위한 기준을 가지고 있다.
예를들어 PBS Works의 경우 아래와 같은 작업 우선순위 등급을 제공한다.

[표 2] 작업 우선 순위 등급

Tunable Formula는 제출된 작업들의 우선순위를 결정하는 새로운 방법 중 하나인데, 제출된 작업이 요청한 리소스를 기반으로 수식을 만들어 계산된 결과값을 우선순위로 사용하는 방식이다.
이 방법은 매우 유연하므로 더 많은 사용자들이 만족할만한 우선순위 결정방식을 수식을 통해 만들수 있게 해준다.

[예제6] OS 프로비져닝을 위한 Hook 실행스크립트

# qmgr에서 Tunable Formula 사용법
예제1)
Qmgr: s s job_sort_formula= ‘5*ncpus+0.05*walltime’
요청된 CPU의 개수와 walltime을 기준으로 우선순위가 결정된다.
예제2)
Qmgr: s s job_sort_formula=‘queue_priority + ncpus’
큐(Queue)가 가진 우선순위에 요청된 CPU개수를 더한 값이 우선순위가 결정된다.
예제3)
Qmgr: s s job_sort_formula=‘5*job_priority + 10*queue_priority’
위와 같은 방법으로 작업(Job)의 우선순위보다 큐(queue)의 우선순위에 가중치를 줄수 있다.

위에서 본것처럼 PBS Works가 관리하는 모든 자원을 우선순위를 결정하는 요소로 사용할 수 있게 되며 최적의 우선순위를 찾게된다. 효율성이라는 측면에서 극단적인 예를들면, 고가의 라이선스 또는 업무중요도가 높은 부서나 특수직급 등에 우선순위를 줄수있도록 각각의 리소스를 조합하여 결합계수를 찾는 것이 관건이 될것이다.

4. HPC 자원관리(Resource Management)

PBS Works를 설치하게 되면 MOM(Machine Oiented Mini-server) 이라는 프로세스가 각각의 컴퓨팅노드에 데몬형태로 상주하며, MOM은 컴퓨팅노드의 자원 정보와 현재 상태를 주기적으로 PBS서버에 업데이트하게 된다. PBS서버는 MOM이 주는 정보 외에 관리하고자 하는 컴퓨팅 자원에 대해서는 Custom Resource 관리기능을 이용해서 추가할 수 있다. MOM이 기본적으로 가지고 있는 자원에 대한 정보는 CPU갯수, OS타입, 메모리 보유량, 호스트 이름 등이다. [예제 7]은 Qmgr을 통해서 MOM이 주는 기본정보와 그 외에 사용자가 관리하기 위해 추가한 자원에 대한 정보를 보여준다.

그림 1. PBS Professional Block Diagram

[예제7] PBS를 통한 Custom Resource 관리

# MOM이 기본적으로 제공하는 컴퓨팅 노드의 정보
set node vnode01 state = job-busy
set node vnode01 resources_available.arch = linux
set node vnode01 resources_available.host = vnode01
set node vnode01 resources_available.mem = 49448440kb
set node vnode01 resources_available.ncpus = 8
# 관리자가 추가로 관리하기위해 등록한 자원정보의 예
set node vnode01 resources_available.mpi = True (병렬 계산작업 가능여부)
set node vnode01 resources_available.cpuclock = 3.46 (CPU클럭스피드)
set node vnode01 resources_available.ibdstat = 1 (openibd 서비스 구동여부)
set node vnode01 resources_available.nfs = 1 (네트워크 파일 시스템 연결성 체크)
set node vnode01 resources_available.radioss = 8 (Radioss 어플리케이션 보유 라이선스)
set node vnode01 resources_available.freedisk = 876 (전체 가용 디스크 용량)
set node vnode01 resources_available.scratch = 512 (/scratch 디스크 가용량)
set node vnode01 resources_available.switch = switch1 (네트워크 스위치 그룹정보)
set node vnode01 resources_available. Qlist=PhysicsQ,ChemQ (Vnode01이 속한 큐정보)

그림 2. HPC시스템 내의 네트워크 구성도

만약 현재 구성된 클러스터의 네트워크 스위치의 구성이 위의 그림과 같다면 PBS Works는 작업 할당 시에 Vnode1이 Switch1에 연결이 되어 있고 병렬계산 작업의 요청이 들어올 경우 작업배치 시에 이를 고려한 자원할당을 할수 있게 된다.

Custom Resource Management를 활용한 GPU스케줄링

GPU는 그 특성 상 1개의 카드가 많은 수의 코어를 가지고 있으며 이를 활용한 HPC 시스템을 구축하는 사례가 늘어나고 있다. PBS Works를 활용한 대표적인 예로 일본의 동경과학기술대학의 TSUBAME 2.0이 있다. 이 슈퍼컴퓨터의 계산능력은 1.192PF(페타플롭스)로 현재 Top500에서 5위에 랭크되어 있다. [그림 3]은 GPU가 장착된 HPC시스템에서 PBS를 스케줄링시스템으로 활용한 블록 다이어그램이다. 먼저 기본적인 GPU스케줄링 방법에 대해서 알아보자. 앞에서 기술한 것처럼 컴퓨팅 노드에 장착된 GPU의 정보를 PBS를 통해 자원으로 등록한다.

그림 3. GPU스케줄링을 위한 PBS 블록 다이어그램

[예제8] Qmgr을 통해 컴퓨팅 노드에 GPU자원 등록

앞에서 기술한 것처럼 컴퓨팅 노드에 장착된 GPU의 정보를 PBS를 통해 자원으로 등록한다.
qmgr –c “set node Vnode1 resources_available.ngpus=4”
qmgr –c “set node Vnode2 resources_available.ngpus=4”
사용자는 아래 명령을 통해 계산작업에 필요한 GPU자원을 요청하고 할당 받을 수 있다.
qsub –lselect=1:ncpus=1:ngpus=2 my_gpu_job

위와 같은 설정은 사용자가 GPU장비를 지정하지 않아도 되고, 모든 GPU자원이 동일한 우선순위를 가진다는 점에서 매우 단순하다. 하지만 1대의 GPU컴퓨팅 노드의 계산능력이 수십대의 CPU클러스터에 준하므로 여러대의 컴퓨팅노드에 대한 요구가 없을 경우에 활용이 가능할것으로 판단된다. 그렇다면 노드에 장착된 GPU의 정보를 좀 더 세부적을 등록하여 활용해보자. PBS서버는 위와 같은 방법으로 가용한 GPU자원을 작업에 할당할 수 있으며 할당된 작업은 어각각의 GPU코어에 CUDA 가 호출한 프로세스를 바인드하게 된다.

[예제9] Qmgr을 통해 컴퓨팅 노드에 세부 GPU자원 등록

qmgr –c “set node Vnode1 resources_available. ncpus =0”
qmgr –c “set node Vnode1[0] resources_available. mem=8gb”
qmgr –c “set node Vnode1[0] resources_available. ncpus =4”
qmgr –c “set node Vnode1[0] resources_available.ngpus=24”
qmgr –c “set node Vnode1[0] resources_available.gpu_id=gpu0”
컴퓨팅노드 Vnode1에 장착된 GPU카드 2개에 대한 정보를 ID를 부여하여 구분하여 등록한다.
qmgr –c “set node Vnode1[1] resources_available. mem=8gb”
qmgr –c “set node Vnode1[1] resources_available. ncpus =4”
qmgr –c “set node Vnode1[1] resources_available.ngpus=24”
qmgr –c “set node Vnode1[1] resources_available.gpu_id=gpu1”
아래와 같은 명령으로 1개의 GPU카드에 계산작업을 할당할 수 있다.
qsub –lselect=1:ncpus=1:ngpus=1 my_gpu_job
qsub –lselect=4:ncpus=1:gpu_id=gpu0 my_gpu_job

그림 4. 사용자 이력 데이터 집중을 위한 구성도

사용자 이력 분석과 확장계획 수립

시스템의 활용도를 높이기 위해서는 현재 사용자들의 사용자 이력 Data를 기반으로 HPC 자원별로 사용율을 분석하고 부족한 부분을 보완해나가는 정책수립이 필수적이다. Analytics는 PBS로 구성된 멀티클러스터 환경에서 각각의 PBS 서버에 Data Collector라고 하는 데이터마이닝 에이전트를 설치하여 중앙 데이터베이스에 사용자이력 데이터를 가공하여 저장한다.이 기능은 PBS Pro의 9.0버전에 맞추어 추가되었으나 기존사용자를 위해 5.3버전부터 현재 최신버전인 11버전까지 지원하고 있다.

그림 5. HPC 시스템에 요청된 메모리와 실제 사용메모리의 비교 그래프

[그림 5]의 그래프들은 현재 구축된 HPC시스템의 기간별 사용 이력 중 요청된 메모리와 실제 메모리를 비교한 것인데 그래프를 보면 요청된 메모리와 실제로 실행에 사용된 메모리의 차이가 많다는 것을 한눈에 볼수 있다. 이 같은 경우에는 관리자가 사용자들에게 적절한 가이드라인을 만들어 공지하여 자원의 활용도를 높일수 있을 것이다.관리자는 Analytics가 제공하는 10가지 타입의 그래프와 다양한 차트를 원하는 형태로 구성하여 하나의 대쉬보드로 구성할 수 있다. [그림 6]은 HPC 시스템이 보유하고 있는 소프트웨어 라이선스에 대한 보유량, 금일 요청된 라이선스의 부족건 수(Denial 정보), 현재 사용량에 대한 그래프와 차트를 한장의 페이지에 구성한 대쉬보드의 예제이다. 현재 부족현상이 발생 중인 라이선스 부족건 수 그래프를 마우스를 조작하여 메뉴를 확장하면 관리자는 관련 데이터들에 대한 데이터셋을 볼수 있다. 또한 구체적으로 몇개의 라이선스를 확장 구매할 것을 가정하고 숫자를 변경하여 분석해보는 What-if 시뮬레이션이 지원되므로 가능한 이상적인 확장계획을 세울 수 있게 된다.

그림 6. HPC 시스템이 보유한 소프트웨어 라이선스 모니터링 대쉬보드

5. 글을 마치며

PBS Works는 미 국방성에 현재까지 약130,000코어로 구성된 클러스터의 워크로드 메니저로 사용되고 있으며, X86계열의 단일클러스터로는 가장 큰 NASA Pleiades의 전체 시스템에서 사용되고 있다. 국내의 사용 예로는 기상청의 슈퍼컴퓨터 3호기(약100,000코어)가 있는데 바로 이러한 구축사례가 안정성과 확장성에 대한 증거로 볼수 있다. 성공적인 HPC시스템을 위한 초기설계 및 구축, 시스템 운영관리, 유지보수 및 확장에서 적절한 비용투자 및 기술구현이 이루어져야 하며 워크로드 메니저의 도입은 초기설계의 단계에서 고려되어야 한다. 위에 소개한 몇가지 기능들은 효율성 증대을 목적으로 운영관리, 유지보수, 확장과 같은 단계적인 과정의 정책과 계획수립에 기여할 수 있다는 점에서 선정하고 기술해보았다. PBS Pro의 개발공급사인 알테어엔지니어링은 기존의 워크로드 메니저의 기능을 가진 PBS Pro를 PBS Works 솔루션의 일부로 병합했으며, 더 나아가 HPC클라우드의 토탈 솔루션으로 그 로드맵을 점차 확장해 나가고 있다.