TERA HPC Cluster Administrator Guide Basic 이문서의 저작권은 TERA TEC에 있으며, 이 문서를 허가 받지 않고 무단으로 사용하는 것을 금지하 고 있으며, 이 출판물의 특정부분, 파일 또는 문서에 대해 정보제공 및 비상업용으로 사용을 할 수 있 으며, 복사본이나 그 일부 문서에도 반드시 저작권고지문을 포함하고 있어야함. 본 출판물에는 기술적 인 또는 기타 오류 및 오자가 있을 수 있다.
목 차 클러스터 기본 계념 및 역사 1. 들어가며 1 2. 클러스터란 무엇인가? 3 3. 관련 기술 ( 슈퍼컴퓨터 구조의 변천 역사 5 3.1. 1980년대~1990년대 초반 5 3.2. 1994년 ~1997년 5 3.3. 1998년 ~ 현재 6 클러스터 기본 구성 4. 구성 9 클러스터 기본 사용 및 설치 5. 설치 및 구성 10 5.1. 점검하기 10 5.2. 전원연결 및 부팅 12 5.3. 초기 세팅 17 5.3.1. 시간 설정 17 5.4. 사용자 생성 20 5.4.1. /home 디렉터리에 사용자 생성 20 5.4.2. /users 디렉터리에 사용자 생성 21 5.5. 파워 끄기 24 5.6. 공 유 25 5.7. 가상 메모리 (Virtual Memory) 늘리기 27 5.8. 하드디스크 추가 및 제거 29 5.8.1. 동작 중에 디스크 추가하기 29 5.8.2. 동작 중에 디스크 제거하기 29 6. 소프트웨어 30 6.1. 시스템 소프트위어 및 사용 방법 30 6.1.1. PTOOLS 30
6.1.2. Ganglia Web based Monitor 31 6.1.3. MPICH 32 6.1.3.1. Intel Compiler MPICH 32 6.1.3.2. PGI Compiler MPICH 33 6.1.3.3. GNU Compiler MPICH 34 6.1.4. rdist 35 7. 정전 및 복구 37 7.2. 클러스터 노드 복구 38 8. LSF 40 8.1. 병렬 코드 실행 40 8.2. 반복적 작업 수행 :Parametric Study 42 9. PBS 46 9.1. PBS(Portable Batch System) 46 9.2. PBS 사용방법 47 9.2.1 사용가능한 노드 보기 47 9.2.2 PBS를 통하여 큐 사용하기 48 9.2.3 큐 상태 확인하기 49 9.2.4 작업 중인 큐 지우기 49 9.2.5 Standard Out 결과 50 9.2.6 Error output 50 9.3. PBS의 구조 51 9.4. PBS 설치 51 9.4.1. PBS download and install 51 9.4.2. PBS 설정 51 9.4.2.1. 서버 51 9.4.2.2. 클라이언트 53 9.4.2.3. Qmgr 53 9.4.2.4. 서버 설정 값 저장 및 재사용 55 9.4.2.5. qmgr 설정 예제 56 9.4.2.6. qsub 예제 58 9.5 RedHat 8 이상 또는 gcc 3.2 기반 설치 59 9.5.1 OpenPBS patch 사용 59 9.5.2 Tera-scale Open-source Resource and QUEue manager 62 클러스터 복구 및 유지 보수 10. Beowolf Cluster제작을 위한 설정 파일 64
10.1. Demon 구성 요약 67 11. Q.A 74 클러스터 평가 및 예제 프로그래밍 12. 성능 평가 90 12.1. LinPack 테스트 90 12.2. High Performance Linpack Test 97 12.3. NPB (NAS Parallel Benchmark) 101 13. 예제 프로그래밍 107 13.1 SUM 107 13.2 Pi 계산 110 13.3 HELLO 113
1. 들어가며 공학자나 모든 사람들이 "better, faster, cheaper"한 컴퓨터를 원하고 있습니다. 그러나 웍 스테이션 구입을 해본 사람들은 잘 알겠지만, 이런 바램과는 멀리 하이-엔드 컴퓨터 이른바 우리가 잘 알고 있는 웍스테이션 벤더인, HP, SGI, SUN, DEC의 제품들을 보면 우리의 이러 한 바램과는 달리 좋은 것은 하나도 없지만, PC보다 약간 빠른 속도로 인해 엄청난 비용을 지 불해야 하는 경우를 만나게 됩니다. 특히 이러한 하이-엔드 컴퓨팅 환경에서는 제한된 벤더의 수로 인해 시스템간의 하드웨어와 소프트웨어 호환성의 부족으로 PC와 같이 사용자가 직접 조립하여 적당한 소프트웨어를 설치하여 사용한다는 것은 생각 할 수 없는 현실입니다. 당연 히 이러 한 특성으로 인해 하드웨어와 소프트웨어의 가격은 비쌀수 밖에 없고 유지와 보수에 드는 비용 또한 무시할 수 없는 현실입니다. 이러한 고가의 하이-엔드 컴퓨팅 환경의 대안으 로 NASA에서 Beowulf 프로젝트라는 이름으로, 시장에서 누구나 살수 있는 PC 하드웨어와 누 구나 사용할 수 있는 소프트웨어인 리눅스를 이용한 하이엔드 컴퓨팅 영역에 대한 새로운 시 도를 하게 되었습니다. 1) Beowulf 프로젝트가 성공하게 된 몇 가지 중요한 요인으로 PC 프로세스(Intel x86, DEC Alpha, Power PC)의 급속한 발전입니다. 근래에 들어 부동소수점 연산에 획기적인 향상이 있 었으며, PC 프로세서의 발전 속도는 이미 기존의 하이-엔드 프로세스보다 3배 이상 빠르며, 리눅스가 사용 가능한 알파 프로세서는 이미 그 속도를 앞질렀습니다. 이와 더불어 고급 유닉 스 서버나 웍스테이션에 만 사용되었던 SCSI 장비의 대중화와 그리고, 네트워크 장비의 급속 한 발전과 더불어 100Mbps switching hub의 가격하락으로 인해 Beowulf 클러스터를 구축할 수 있는 하드웨어를 PC급으로도 충분히 구축 가능해졌습니다. (외국에서는 100Mbps switching hub를 포트당 100불 미만으로 구입 가능하지만, 국내는 여전히 고가입니다.) 물론 이러한 하드웨어 발전만으로 Beowulf 프로젝트가 성공할 수 있었던 것은 절대 아닙니 다. 이렇게 다른 목적을 두고 발전해온 하드웨어를 리눅스는 하나의 시스템으로 통합하여 Beowulf 라는 새로운 타입의 병렬컴퓨터를 만들어 낸 것입니다. 너무나 잘 아는 얘기지만, 리 눅스는 기존의 상용 유닉스보다 더 낳은 환경을 제공하였는데, 바로 소스 코드의 100% 개방 으로 Beowulf cluster에 적합하게 자유롭게 소스 코드를 수정하고 새롭게 개발하여 배포할 수 있는 환경을 제공하였는데, 이러한 리눅스의 자유함이 없었다면 이 프로젝트는 실패하였을 것 입니다. 이외에도 MPI, PVM같은 message passing library의 표준화가 이루어져 상용 병렬컴 퓨터와 마찬가지로 Beowulf cluster에서도 자유롭게 사용할 수 있게 됨으로 인해 Cray로 시작 하는 슈퍼컴퓨터에서 시작해서 Desktop PC까지 일관된 프로그래밍 작업을 할 수 있게 되었습니 다. 슈퍼컴퓨터를 구조적으로 살펴보면, RC5/DES 크랙같이 전 세계적으로 internet으로 연결된 컴퓨터들도 하나의 병렬처리 슈퍼컴퓨터로 볼 수 있으며, 이와 반대로 상용 슈퍼컴퓨터로서 초고속 네트워크로 구성된 MPP, vector, SIMD cluster도 있습니다. 이러한 상용 슈퍼컴퓨터는 시스템 디자인과 개발 시간으로 인해 급속히 발전하고 있는 마이크로프로세서를 즉각적으로 수용하기 힘든 단점이 있는 반면 Beowulf Cluster는 각각의 node가 개별적인 OS를 가지고 있 으며 고속의 local area network를 이루고 있기 때문에 뛰어난 확장성이 있으며, 급속히 발전 1) Beowulf Cluster, 박정환, 1998년 10월 28일
하고 있는 마이크로프로세서를 즉각적으로 수용하기가 용이합니다. 물론 SUN같은 대중적인 웍스테이션을 이용하여 network clustering을 할 수 있지만, 고비용으로 인해 확장성에 한계를 가지게 됩니다. Beowulf cluster는 각 slave node는 기본적으로 M/B, RAM, NIC, CPU만을 가 지고 키보드, 마우스, 모니터는 공유기를 통하여 master node에서 전체 node를 제어하고 전 적으로 병렬처리에 사용된다는 점에서 일반적인 workstation cluster와 구분됩니다. 가장 간단 한 beowulf cluster는 switching hub 없이 직접 cross link하여 2 node로 구성할 수 있는데 각 node에 CPU를 2개씩 설치한다면 간단한 4 processor mini beowulf cluster를 만들 수 있습니 다. 초기 beowulf cluster은 8-node 또는 16-node로 ethernet을 바탕으로 시작하였지만, 현재 제대로 된 Beowulf cluster을 구성하기 위해서 shared 100MBPS급인 일반 fast ethernet hub 보다는 각 node간의 network I/O bandwidth를 보장하기 위해서 dedicated 100MBPS를 제공 하는 switching hub가 필수적입니다. 현재 16포트 switch를 사용할 경우 최대 16 node를 구 성할 수 있으며, network I/O의 bandwidth가 부족할 경우 각 node에 NIC를 추가 설치하여 network channel bonding을 하여 node수는 줄어들지만, 네트워크 대역폭을 증가시킬 수도 있 습니다. 100 node이상 설치하여 운영하고 있는 곳은 대개 gigabit uplink가 가능한 100Mbps switch 를 사용하여 각 node를 연결시키고 이러한 switch를 gigabit switch로 연결하여 각 node간의 network를 통한 I/O bandwidth를 손실을 최소화 합니다. 이런 방식으로 네트워크를 구성할 경 우 극단적인 경우를 생각하면, beowulf cluster과 네트워크 구성은 틀리지만, Intel의 Pentium Pro CPU를 9152개를 사용한 ASCI 의 Red System (현재 Top500 list에서 1위)으로 beowulf cluster의 가능성을 충분히 짐작할 수 있을 것입니다. 이와 같이, Beowulf cluster의 각 node 는 시장에서 쉽게 구할 수 있는 PC 하드웨어로 구축되지만, 네트워크 구성에 사용되는 장비는 예외로서, 전체 Beowulf cluster예산 중에 큰 부분을 차지하고 있으며 기술의 발달로 Myrinet 같은 새로운 네트워크 장비가 등장하고 있으나, channel bonding한 네트워크 구성에 비해 가 격대 성능비에서 큰 효과를 보이지 못하고 있어 지금은 널리 사용되고 있지 못합니다.
2. 클러스터란 무엇인가? 클러스터를 사전에서 찾아보면 다음과 같습니다. cluster [klʌśtər] n. 1 (과실 꽃 따위의) 송이, 한덩어리(bunch)(of). 2 (같은 종류의 물건 사람의) 떼, 집단(group); (공용의 넓은 공터 사용을 위한) 집단주택; 천문학 성단( 星 團 ). 3 미국육군 (같은 훈장을 거푸 받았음을 표시하는) 훈장(리본에 붙이는 메달). 4 음성 연속 자음(한 음으로 발음하는 둘 이상의 연속 자음). 5 컴퓨터 다발(데이터 통신에서 단말 제어장치와 그에 접속된 복수단말의 총칭). 6 군사 =CLUSTER BOMB; 클러스터(지뢰부설의 단위). a of grapes 포도 한송이.1 a of stars 성군( 星 群 ), 성단.2 in a 송이를 이루어; 일단이[덩어리가] 되어. cluster [klʌśtər] vi., vt. 1 송이를 이루다, 줄줄이 열리다. 2 ( 의 주변에) 군생하다[시키다](around); 집중 발생하다; 밀집하다[시키다]; 떼짓다[짓 게 하다]. a ed column 건축 누주( 樓 柱 ); 다발 기둥, 족주( 簇 株 ). 파-tery a. 일반적인 의미의 클러스터와 마찬가지로 컴퓨터용어에서의 Cluster는 한덩어리의 컴퓨터, 컴 퓨터의 묶음을 말합니다. 클러스터는 개별적인 여러 개의 컴퓨터 시스템을 하나의 컴퓨터 시 스템처럼 보이게 만드는 기술입니다. 컴퓨터 클러스터링은 Digital VAX 플랫폼을 시초로 1980 년대부터 다양한 형태로 만들어지기 시작했으며 이는 예전에는 VAX 하드웨어를 조합하여 클 러스터링 서비스를 제공했었습니다. 이러한 VAX 클러스터는 디스크 공간 같은 하드웨어 자원 을 공유 할 수 있었고, 여러 사용자에게 컴퓨팅 자원을 제공 할 수 있었습니다. 클러스터링은 일종의 병렬 컴퓨팅입니다. 클러스터링과 다른 관련 기술의 중요한 차이는 클 러스터를 단일 서버로 볼 수 있고 독립형 시스템들의 조합으로 볼 수도 있다는 것입니다. 예 를 들어, 웹 서버 클러스터는 하나의 거대한 웹서버로 보일 수도 있지만, 그와 동시에, 필요에 따라 클러스터 안의 각 시스템을 개별적인 시스템으로 액세스 할 수도 있습니다. 클러스터 안의 각 시스템은 독립적인 컴퓨터이기 때문에, 개별적인 운영 체재와 하드웨어 및 소프트웨어를 갖습니다. 클러스터는 모든 시스템이 비슷한 하드웨어에서 동일한 소프트웨어를 실행하는 동종 클러스 터 일 수도 있고, 클러스터 안의 시스템이 다양한 하드웨어에서 서로 다른 운영체제를 실행하 는 이종 클러스터일 수도 있습니다.
여기서 사용자는 한 가지 의구심이 들것입니다. 그러면, 전산실이나 전산 실습실에 있는 컴 퓨터도 클러스터인가? 여기에 대한 답변은 아니다 입니다. 앞서 말한바와 같이 클러스터는 개별적인 여러 개의 컴퓨터 시스템을 하나의 컴퓨터 시스템처럼 보이게 만드는 기술 이며 클러스터를 단일 서버로 볼 수 있고 독립형 시스템들의 조합으로 볼 수도 있다 에서 우리는 클러스터가 될 수 있는 필수 조건에 대하여 생각을 해 보아야 합니다. 이 조건은 전산 실습실 이나 PC 방이 왜 클러스터가 되지를 못하는지를 판별할 기준이 됩니다. 클러스터가 되기 위한 첫 번째 조건은 사용자는 다수의 컴퓨터가 있다고 하더라도 오직 하 나의 컴퓨터처럼 사용이 가능하여야 한다는 것입니다. 클러스터가 되기 위한 조건인 개별적인 여러 개의 컴퓨터 시스템을 하나의 컴퓨터 시스템처 럼 보이게 만드는 기술 을 위하여서는 두 번째 조건인 Cluster Application이 존재하여야 한다 는 것입니다. 한 가지 예를 들면 Web 클러스터는 부하분산을 위한 Load Balancer라는 Cluster Application 혹 Libraries가 필요하며 HPC(High Performance Computer)에서는 MPI나 PVM등이 필요하다는 것입니다. 다음 도표는 클러스터의 구성을 간략하게 묘사한 것입니다.
3. 관련 기술 ( 슈퍼컴퓨터 구조의 변천 역사 3.1. 1980년대~1990년대 초반 당시 컴퓨터에 탑재된 CPU성능을 2001년 현재 시점과 비교를 해본다면 현재, 시중에 쓰고 있는 PC들의 1/10 정도 밖에 되지 않습니다. 하지만, 가격 측면에 있어서는 현재의 PC 보다 약 1000배 정도가 비싼 CPU를 사용한 시스템이었으며 고성능의 단일 CPU를 탐재 하거나 벡 터 레지스터(Vector register) 기능을 포함해 CPU성능 향상을 통해 고성능 연산 능력을 제공하 는 벡터형 SMP(Symmetric Multi Processor) 슈퍼컴퓨터가 주류였습니다. 입출력 성능과 벡터 레지스터를 이용한 CPU의 계산 능력은 우수하였으나 비용이 매우 비쌌다는 점과 시스템의 확 장성에 대한 한계가 문제로 대두가 되었습니다. SMP의 경우, 시스템이 하나의 운영체제를 이용해 여러 개의 CPU를 작업량에 맞게 효율적 으로 활용하는 기능이 있었으며 이는 좀 더 쉽게 설명한다면, 하나의 몸체를 가진 개가 여러 생각(계산작업)을 여러 개의 머리(CPU)를 이용해 동시에 할 수 있다는 것입니다. 따라서 이들 머리(CPU)들은 별다른 연결장치 없이 내부적으로 생각(계산작업) 및 그에 대한 정보(memory) 를공유해 효율적인 성능을 보일 수 있는 것입니다. 2~4개의 프로세서를 갖는 SMP 시스템은 아주 간단하게 구축할 수 있지만, 그 이상의 프로세서를 갖는 시스템의 경우에는 문제가 다릅 니다. 이는 모든 프로세서가 모든 I/O 및 메모리 자원을 엑세스할 수 있어야 하기 때문입니다. 4개 이상의 프로세서를 갖는 시스템의 경우, 공유 자원이 병목 현상에 빠지기 시작하며, CPU를 더 추가 할 경우 반환률이 감소됩니다. 3.2. 1994년 ~1997년 RISC(Reduced Instruction Set Computer) CPU의 등장으로 CPU에 대한 단가가 저렴해졌기 때문에 다수의 일반적인 CPU(4~1024CPUs)를 이용하는 MPP(Massively Parallel Processor) 형 병렬 슈퍼컴퓨터가 등장한 시기입니다. MPP란 프로그램을 여러 부분으로 나누어 여러 프 로세서가 각 부분을 동시에 수행시키는 것을 말합니다. 이때 각 프로세서는 각기 운영체계와 메모리를 따로 가지고 일을 수행하며 각 프로세서 간에는 메시지 패싱과 같은 기법을 이용하 여 통신을 합니다. 따라서 하나의 프로그램을 수행하는데 수 백 혹은 수천 개의 프로세서를 이용할 수 있는 것입니다. MPP의 성능을 제대로 발휘하려면, 프로그램을 독립적으로 수행되 는 여러 부분으로 나누고, 각 프로세서가 다른 프로세서와 정보를 주고받는 일을 최대한 효율적으
로 할 수 있는 하드웨어 구조와, 이를 뒷받침하는 운영체계의 성능이 잘 조화를 이루어야 합니다. 보통 MPP시스템은 SMP와 비교하여 loosely coupled 시스템이라 부르기도 합니다. SMP시 스템에 비하여 MPP시스템은 여러 데이터베이스를 동시에 검색하는 의사결정시스템이나 데이 터웨어하우징 시스템에서 보다 나은 성능을 나타내며, 또한 같은 패턴이 반복되는 이미지 프 로세싱에도 적합한 것으로 알려져 있습니다. 한때는 병렬화를 통한 대용량 계산 수행 시간이 오래 걸리던 작업을 사용 CPU 수만큼의 최 대 시간 단축 효율을 가능케 해 차세대 슈퍼컴퓨터군의 주류로 인식 되었으나, 치명적인 단점 을 가지고 있는데, 병렬 환경으로 지원되는 상용 소프트웨어들의 부재와 병렬 시스템을 사용 하는 사용자들이 병렬화라는 특수한 개념의 프로그램 기법을 습득해야 했으며, 더구나 병렬기 법을 통한 프로그래밍이 매우 어려웠기 때문에 대중적으로 널리 퍼지지 못했다는 점입니다. 물론 두 가지 측면의 장점이 있습니다. 그 중 첫 번째 장점으로는 사용자 측면의 단위 계산 성능 향상을 추구 할 때에는 다른 어느 슈퍼컴퓨터들보다도 훨씬 더 좋은 성능을 병렬화를 통 하여 보일 수 있다는 점입니다. 다른 하나의 장점으로는 사용자들이 병렬 슈퍼컴퓨터 시스템 에 탑재되어 있는 CPU 수만큼의 웍스테이션들이라고 생각 할 수 있어 작업량이 많을 때는 여 러 대의 웍스테이션들을 보유하고 있는 것처럼 Through-Put(단위 시간당 작업 소화 능력)개념 으로 확대해 사용할 수 있다는 점입니다. 3.3. 1998년 ~ 현재 SMP와 MPP의 장점을 따온 CC-NUMA(Cache Coherent Non-Uniform Memory Access)라 는 DSMP(Distributed Shared Memory Processor)구조의 슈퍼컴퓨터들이 인기를 끌며 주류를 이루었습니다. 그 이유는 손쉽게 작업 성능을 향상 시켜 줄 수 있는 SMP 구조와 최대 성능을 보장해 줄 수 있는 MPP 구조가 어우러져 있어 사용자의 욕구에 양측 면으로 대응 할 수 있기 때문입니 다. 또한, 상요 소프트웨어 역시 지원되기 때문이다. 대부분의 CPU 사용수는 4개에서 256개 를 사용하는 것이 보통입니다. CC-NUMA는 SMP와 MPP의 구조를 공유하고 있다는 점 이외에 큰 장점으로 내 정보 (memory)가 부족할시 옆에 있는 개의 정보(memory)를 빌려서 자신의 것처럼 활용 할 수 있 다는 것입니다. CC-NUMA 아키텍처의 슈퍼컴퓨터들이 상용 애플리케이션을 주도하는 시스템들이었다면, 1996년부터 불어오기 시작한 리눅스 열풍은 기초과학 분야 및 연구소등에서 값비싼 슈퍼컴퓨
터들을 구입해 활용하기보다 저비용으로 고성능을 보일 수 있는 리눅스 기반의 PC 클러스터 시스템을 선호하게 만들었습니다. 즉, off-the-shelf'방식으로 구성하는 PC 클러스터가 차세대 과학계산 서버로 대두되기 시작한 것입니다. 클러스터(Cluster)는 MPP 보다 좀더 관리자 면에서 효율적인 운영체제가 필요한 시스템이 나, 사용자가 직접 각각의 개들을 관리/통제(병렬프로그래밍)해야 한다는 점이 MPP와 같습니 다.
4. 구성 클러스터는 기본적으로 Computing Node, Login Node, Management Node, NFS Node 등으 로 나누어집니다. 클러스터 노드제어와 사용자 프로그램의 컴파일 및 실행의 제어를 위한 로 그인 노드와 실제 계산을 위한 노드 및 파일 서버 노드로 구분이 되며 각각의 역할은 다음과 같습니다. Computing Node Block High-Performance Computing Network Login Node Block NFS Node Block RAID Storage Cluster Management Block Management and Public Network 구분 Management Node Computing Node NFS Node (Storage Node) Login Node Stage Node 내 용 Cluster 관리, 설치, 컴파일등의역할을담당 실제 연산을 수행하는 노드로써 Cluster의중심역할 작업 결과 및 프로그램을 저장하는 Storage 서버 사용자 계정 및 작업 분배 사용자 프로그램 컴파일 등의 역할을 담당 대규모 Cluster 구성시일정노드그룹당하나씩Management Node 외 별도의 서버 를두어그룹단위관리를담당 별도관리(필요 시 추가)
5. 설치 및 구성 클러스터를 설치하기에 앞서 사용자는 다음 사항을 미리 점검하여 보시기 바랍니다. 1 전원공급 클러스터는 한 Rack에 다수의 컴퓨터들로 구성이 되어 있습니다, 따라서 단일 컴퓨터 를 쓸 때와는 그 소비 전력이 달라 이에 대한 대비가 되어 있어야 합니다. 예를 들어 Xeon Dual 1U 클러스터는 그 소비 전력이 약 400W입니다. 따라서 1U 16 노드로 구 성된 클러스터 소비 전력은 약 6400W 정도 됩니다. 설치하실 장소의 전력 사항을 고 려하여 충분한 전력공급을 하여 주시기 바랍니다. 2 항온항습 클러스터는 한 Rack에 다수의 컴퓨터들로 구성이 되어 그 냉각 문제가 심각합니다. 물론 노드당 발생되는 열 방출을 위하여 냉각팬이 달려 있지만, 별도의 항온항습 장치 가 필요로 하는 경우가 있습니다. 이점을 고려하여 직사광선이 들지 않는 곳에 설치를 하여 주시기 바랍니다. 5.1. 점검하기 테라텍에서 공급하는 클러스터 시스템은 기본적으로 클러스터 노드 외에 전체 클러스터 노드 제어를 위한 컨트롤 머신이 연결되어 공급이 됩니다. 컨트롤 머신이 포함되지 않을 경우 첫 번째 노드가 컨트롤 머신의 역할을 하도록 되어 있습니다. 컨트롤 노드는 대부분 맨 위부분 에 구성이 되거나 맨 아래 부분, 또는 별도로 분리가 되어 있습니다.
클러스터노드 컨트롤노드 또한, 각 노드의 관리 편리를 위하여 KVM(키보드, 비디오, 마우스 공유기)이 포함이 될 수 있습니다. 아울러 각 노드간 통신을 위하여 기본적으로 Fast Ethernet으로 구성이 되어 있으며 사용자의 요청에 따라 다양한 network 로 구성이 됩니다. 각 Ethernet의 장치는 별도 사용자 설명서를 참조하시기 바랍니다. 1 충분한 파워가 제공이 되도록 하여 주시기 바랍니다. 2 온도가 일정한 직사광선이 들지 않는 그늘진 장소에 설치하여 주시기 바랍니다. 3 경사지지 않은 장소에 설치하시기 바랍니다. 4 외부 네트워크 연결을 고려 IP를 준비하여 주시기 바랍니다.
5.2. 전원연결 및 부팅 1 Rack 전원을 연결하여 주시가 바랍니다. - 각 노드의 파워 케이불이 Rack에 달려 있는 멀티 커넥터에 연결하여 주시기 바랍니다. 2 각 노드의 파워를 켜 주시기 바랍니다. - 각 노드의 파워는 컨트롤 노드를 먼저 클러스터 노드 순으로 켜 주시는 것이 좋습니다. 3 KVM이 연결 되어 있다면 KVM 스위치를 컨트롤 노드로 전환을 시켜 주시기 바랍니다. 4 정상대로 부팅이 되면 아래와 같은 화면을 보실 수 있습니다. 5 root 로 로긴하시기 바랍니다. 초기 암호는 1234567입니다 6 각 노드가 정상대로 부팅이 되었는지 확인을 하여 주시기 바랍니다. 7 네트워크가 정상인지 palive 명령어를 사용하여 주시기 바랍니다. palive는 각 노드에 ping 을 하여 정상이면 up 비정상이면 xxx is NOT responding이라고 나옵니다. 만일 xxx is NOT responding이라고 나오면 스위치 및 노드의 네트워크 카드를 점검을 하여 주시기 바랍니다.
이 작업은 처음 클러스터 가동 시 반드시 제일 먼저 하여 주시기 바라며 아울러 이 명령어는 root만이 사용이 가능합니다. 7 각 노드의 부하를 알기 위하여 pload 명령어를 사용하여 주시기 바랍니다. pload의 메시지 중 오른쪽 끝의 3개의 숫자들은 각각 지난 1분, 5분, 15분동안의 시스템 부하 율을 각각 평균하여 나타내고 있습니다. 만일 작업을 돌리지 않은 가운데 load average 값이 높게 나오면 쓸데없는 데몬이나 프로세서 들이 가동 중이므로 확인을 하여 주시기 바랍니다.
ssh를 통한 원격에서 접속 기본적으로 cluster는 보안이 취약한 관계로 telnet 접속이 막혀 있습니다. 따라서 사용자는 ssh를 통하여 접속을 하셔야 합니다. windows windows에서 ssh를 통한 접속을 하기 위해서는 ssh를 지원하는 telnet 프로그램을 사용 하셔 야 합니다. ssh를 지원하는 telnet은 다음과 같이 있습니다, ztem : 간단한 기능만을 가지고 있으며 크기가 140KB 밖에 되지 않을 정도로 가볍습니다. 작은 크기이지만 zmodem을 지원을 하는 등 기능은 막강합니다. putty : zterm과는 달리 호스트 관리가 가능합니다. 348KB 정도의 크기를 가집니다. scp : windows에서 파일 전송 시 필요한 파일 전송 프로그램입니다. ftp와 비슷합니다. 다음은 putty를 통한 예제입니다. 1 putty를 실행을 시키면 아래와 같이 configuration windows가 나옵니다. 각 항목에 접속할 host name(or IP address)를 입력후 ssh 접속을 위하여 ssh를 선택하여 주신 후 open을 하여 주시기 바랍니다. 2 잠시 후에 인증키 작업을 경고하는 메시지 창이 뜹니다.
3 인증을 허락을 하면 기존의 telnet과 똑같은 창이 뜹니다. 4 각 UID(User ID)로 login 하시기 바랍니다.
UNIX에서 접속 - 접속 시 ssh -l login_name full_hostname 예) ssh -l ecctest hpceng.snu.ac.kr * 접속 후 사용방법은 일반 telnet과 동일합니다. sftp login_name@full_hostname 예) sftp ecctest@hpceng.snu.ac.kr * 접속 후 사용방법은 일반 ftp와 동일합니다.
5.3. 초기 세팅 클러스터를 가동하기에 앞서 우선적으로 해 주어야 할 셋은 다음과 같습니다. 5.3.1. 시간 설정 클러스터에 있어서 시간 동기화는 중요한 작업입니다. 사용자는 반드시 아래 사항을 점검 시 간을 맞추어 주시기 바랍니다. 1 컨트롤 노드에서 date명령으로 시간을 확인을 하여 주시가 바랍니다, 만일 시간이 실제 시 간과 차이가 생긴다면 시간을 맞추어 주시기 바랍니다. 명령어는 date 이며 형식은 다음과 같습니다. date MMDDhhmmYY (월일시분년) 2 시간을 맞추어 주신 다음 시스템의 시간으로 하드웨어시간을 맞추어 주시기 위하여 hwclock명령을 사용하여 시간을 맞추어 주시기 바랍니다. hwclock --systohc
3 컨트롤 노드의 시간을 맞추어 주신다음 클러스터 노드의 시간을 맞추어 주실 차례입니다. 먼저 다음 명령어로 각 노드의 시간을 확인하여 주시기 바랍니다. pexec date 4 클러스터 노드의 시간 변경을 위하여 다음 명령을 사용하시기 바랍니다. pexec /etc/cron.hourly/settime.sh 5 클러스터 노드의 시스템 시간과 하드웨어 시간을 일치시켜 주시기 바랍니다.
pexec /usr/sbin/hwclock --systohc 6 이상으로 컨트롤 노드와 클러스터 노드의 시간이 일치 작업이 끝났습니다. 이 작업은 초기 설치시 한번만 작업을 해주시면 다음부터는 매시간 cron에 의하여 시간 일치 작업이 자동 적으로 이루어집니다.
5.4. 사용자 생성 클러스터에서 사용자 생성은 앞서 말씀드린 대로 컨트롤 노드(n000)에서 하셔야 합니다. 사용자 생성을 위한 방법은 두 가지가 있습니다. 5.4.1. /home 디렉터리에 사용자 생성 사용자 생성을 위하여 아래 명령어를 사용하시기 바랍니다. useradd [-c comment] [-d home_dir] [-e expire_date] [-f inactive_time] [-g initial_group] [-G group[,...]] [-m [-k skeleton_dir] -M] [-p passwd] [-s shell] [-u uid [ -o]] [-n] [-r] login 각 항목을 알맞게 적어 주시고 홈 디렉터리에서는 주의를 하여 주시기 바랍니다. 클러스터는 각 노드는 파일 서버의 /homed,f 공유하고 있습니다. 그러므로 각 사용자의 홈 디 렉터리는 반드시 /home 디렉터리 아래에 위치하여야 합니다. 예를 들면 다음과 같습니다. ecctest란 사용자를 만든다고 가정을 하면, 공유가 가능한 파티션(/home) 에 만드셔야 모든 노드에서 정보를 공유할 수 있습니다. [root@nooo ptools]# useradd ecctest -d /home/ecctest (/home 공유파티션 아래 ecctest 디렉터리를 홈 디렉터리로 사용) [root@n000 ptools]# passwd ecctest (ecctest의 passwd 변경) 그다음에 이를 전체 노드로 복사하는 pusersync를 사용하시면 됩니다. [root@n000 ptools]# pusersync 이와 같이 하게 되면 모든 노드(n001~n016로 ecctest라는 사용자정보를 복사해줍니다. 사용자 생성이 끝나면 정상대로 생성이 되었는지 확인을 하여 주시기 바랍니다.
[root@nooo ptools]su - ecctest [ecctest@n000 ecctest] [ecctest@n000 ecctest]pexec pwd n001s: /home/ecctest n002s: /home/ecctest n003s: /home/ecctest n004s: /home/ecctest n005s: /home/ecctest n006s: /home/ecctest n007s: /home/ecctest n008s: /home/ecctest n009s: /home/ecctest n010s: /home/ecctest n011s: /home/ecctest n012s: /home/ecctest n013s: /home/ecctest n014s: /home/ecctest n015s: /home/ecctest n016s: /home/ecctest 5.4.2. /users 디렉터리에 사용자 생성 사용자 생성을 위하여 아래 명령어를 사용하시기 바랍니다. useradd [-c comment] [-d home_dir] [-e expire_date] [-f inactive_time] [-g initial_group] [-G group[,...]] [-m [-k skeleton_dir] -M] [-p passwd] [-s shell] [-u uid [ -o]] [-n] [-r] login 각 항목을 알맞게 적어 주시고 홈 디렉터리에서는 주의를 하여 주시기 바랍니다. 클러스터는 각 노드의 /scratch란 파티션을 각각 /users/home001, /users/home002 로 공 유를 하고 있습니다. 그러므로 각 사용자의 홈 디렉터리를 /home로 하지 않을 시에는 반드시 /users/home001/xxxx 또는 /users/home002/xxxx 로 되어야 합니다. 예를 들면 다음과 같습니다.
ecctest란 사용자를 만든다고 가정을 하면, 공유가 가능한 파티션 (/users/home001~home016) 에 만드셔야 모든 노드에서 정보를 공유할 수 있습니다. [root@n000 ptools]# useradd ecctest -d /users/home001/ecctest (n001의 /scratch 공유 파티션 아래 ecctest 디렉터리를 홈 디렉터리로 사용) [root@n000 ptools]# passwd ecctest (ecctest의 passwd 변경) 그다음에 이를 전체 노드로 복사하는 pusersync를 사용하시면 됩니다. [root@n000 ptools]# pusersync 이와 같이 하게 되면 모든 노드로 ocs라는 사용자정보를 복사해줍니다. 사용자 생성이 끝나면 정상대로 생성이 되었는지 확인을 하여 주시기 바랍니다.
[root@nooo ptools]su - ecctest [ecctest@n000 ecctest] [ecctest@n000 ecctest]pexec pwd n001s: /users/home001/ecctest n002s: /users/home001/ecctest n003s: /users/home001/ecctest n004s: /users/home001/ecctest n005s: /users/home001/ecctest n006s: /users/home001/ecctest n007s: /users/home001/ecctest n008s: /users/home001/ecctest n009s: /users/home001/ecctest n010s: /users/home001/ecctest n011s: /users/home001/ecctest n012s: /users/home001/ecctest n013s: /users/home001/ecctest n014s: /users/home001/ecctest n015s: /users/home001/ecctest n016s: /users/home001/ecctest 만일 로그인이 안 된다면 네트워크에 문제가 있는 관계로 palive를 실행을 하여 네트워크가 이 상한 노드를 찾아 조치를 하여 주시가 바랍니다.
5.5. 파워 끄기 1 클러스터를 끄기에 앞서 관리자는 반드시 작업 중인 프로세서 및 유저가 있는지 확인을 하 여 주시기 바랍니다. pexec ps more pexec who 2 전원을 끄거나 리부팅(reboot)을 시키는 명령은 다음과 같습니다. 전체 노드의 reboot(컨트롤 노드 제외) pexec reboot 전체 노드의 shutdown(컨트롤 노드 제외) pexec shutdown -h now 특정 노드의 reboot rsh blastaxxx(xxx는 노드 번호) reboot pexec -h blastaxxx(xxx는 노드 번호) reboot 특정 노드의 shutdown rsh nodexx(xxx는 노드 번호) shutdown -h now pexec -h nodexxx(xxx는 노드 번호) shutdown -h now
5.6. 공 유 클러스터는 각 노드의 /cluster를 공유하고 있습니다. 이는 다음과 같은 규칙이 있습니다. 노드 파티션 공유이름 NFS Option n001 /scratch /users/home001 rw,bg,soft,intr,tcp n002 /scratch /users/home002 rw,bg,soft,intr,tcp n003 /scratch /users/home003 rw,bg,soft,intr,tcp n004 /scratch /users/home004 rw,bg,soft,intr,tcp n011 /scratch /users/home011 rw,bg,soft,intr,tcp n012 /scratch /users/home012 rw,bg,soft,intr,tcp n013 /scratch /users/home013 rw,bg,soft,intr,tcp n014 /scratch /users/home014 rw,bg,soft,intr,tcp n015 /scratch /users/home015 rw,bg,soft,intr,tcp n016 /scratch /users/home016 rw,bg,soft,intr,tcp n000 /home /home rw,bg,soft,intr,tcp 위 표에서 보듯, 각 노드의 /scratch는 /users/homexxx로 공유가 되어 있습니다. /users/homexxx 파티션은 사용자의 접속이 있을 시에만 공유가 되도록 auto mount기능이 설 정이 되어 있습니다. 단, n000에 연결된 /home는 NFS가 static 하게 구성이 되어 있습니다. 이는 auto mount가 사용자가 접근시만 활성화가 되고 빠져나가면 자동적으로 비활성화 되는 특징으로 일반적인 NFS방식보다 보다 노드 부하가 줄어들며 안전하게 사용하실 수가 있으나 대량의 파일이 주고 받는 클러스터 구성시 권하지 않는 방법입니다.
5.7. 가상 메모리 (Virtual Memory) 늘리기 가. 가상 메모리란? 리눅스에서 가상 메모리(Virtual Memory)를 지원합니다. 그럼 가상 메모리란 무엇 인가? 메모리는 보통 물리적 메모리인 RAM을 생각하기 쉽습니다. 하지만 이 RAM만을 가지고 시스템을 운용하기에는 힘듭니다. 특히 적은 RAM을 보유하고 있는 시스템은 더욱더 힘듭니다. 그것을 보완하기 위해서 디스크의 일부를 마치 확장된 RAM처럼 이용하는 것입니다. 나. 가상 메모리의 유용성 리눅스 커널은 실제메모리에 올라와 있는 메모리 블록 중에 쓰이지 않는 것은 가 상 메모리에 저장하고, 필요한 메모리 블록만 불러서 실제 메모리에서 사용합니 다. 그리고 필요 없으면 다시 가상메모리 공간으로 보냅니다. 이렇게 가상메모리 를 이용함으로서 실제메모리의 효율성을 높일 수가 있습니다. 라. 스왑 공간 생성 스왑 공간 생성 방법은 두 가지가 있는데 먼저 스왑 파티션을 따로 생성 하는 것 이고 두 번째는 스왑 파일을 만드는 것입니다. dd if=/dev/zero of=/extra-swap bs=1024 count=1024 위에서 /extra-swap은 스왑 화일 이름 bs= 1024 입출력 단위 크기 count = 입출력 단위의 몇 배 크기의 파일을 만들 것인지 지정 *count는 꼭 4의 배수로 지정하는 것이 좋다. 스왑 파일이나 스왑 파티션을 생성하면 그에 해당하는 인식표를 달아야 합니다. mkswap /extra-swap 1024: Setting up swapspace. size = 104480 bytes 스왑 공간을 초기화를 위해서는 swapon을 사용 합니다.
swapon /extra-swap 스왑 공간들은 /etc/fstab 파일에 의해서 자동적으로 사용가능합니다. free 명령을 내리면 스왑 의 사용상황을 알 수 있습니다. 스왑 공간은 swapoff로 멈출 수 있습니다. (임시로 잡은 스왑이 아니라면 굳이 멈출 필요가 없다.) 주의 할 점은 임시로 잡은 스왑 공간이라면 스왑 종료시 그 공간에 있던 메모리 페이지들은 실제 메모리에 들어가게 됩니다. 실제 메모리 보다 작은 페이지들이 있으면 다행이지만 실제 메모리 보다 큰 메모리 페이지가 있을 경우 다른 스왑 공간으로 내보내고, 다른 스왑공간도 부족하다면 리눅스 시스템은 상당히 느려질 수 있습니다. 그러므로 스왑을 정지하기 전에 free 를 이용해 실제 메모리 공간이 충분히 있는지 확인을 하셔야 합니다.
5.8. 하드디스크 추가 및 제거 경우에 따라서는 사용 중에 하드디스크를 교체를 해야 될 경우도 있습니다. 요새 나오는 서버들은 전원을 끌 필요 없이 하드디스크를 추가 또는 제거(Hot Swap) 할 수 있습니다. 이를 통해 얻을 수 있는 가장 유용한 점은 동작 중에 저장 장치를 더 추가하거나 동작하지 않는 다른 곳으로 옮기기 위해서 저장 장치를 빼낼 수 있다는 것입니다. 물론 서버에서 이런 특징을 지원하기 위해서는 실제 서버에서 이런 기능(핫 스왑:Hot Swap)을 지원해야 합니다. 만약 서버에서 이것을 지원하지 않으면 이상 현상이 일어나거나 시스템이 멈출 수 있습니다. 5.8.1. 동작 중에 디스크 추가하기 가. 동작 중 추가를 지원하는 드라이버를 사용하고 있는지 확인한다. 나. "/proc/scsi/scsi"에 드라이버가 올라오지 않으면 수동으로 추가해야 한다. * 다음 명령을 실행합니다. "echo "scsi add-single-device A B C D" > /proc/scsi/scsi" 여기서 A=Host ID, B=Channel ID, C=Device ID 그리고 D=LUN ID입니다. 예: 두 번째 어댑터의 채널 0번의 15번 디바이스의 LUN 0를 추가한다면 "echo "scsi add-single-device 1 0 15 0" > /proc/scsi/scsi"가 됩니다. 5.8.2. 동작 중에 디스크 제거하기 가. 동작 중 제거를 지원하는 드라이버를 사용하는지 확인한다. 나. 드라이브의 파일 시스템을 언마운트한다. * 다음 명령을 실행합니다. "echo "scsi remove-single-device A B C D" > /proc/scsi/scsi" 여기서 A=Host ID, B=Channel ID, C=Device ID 그리고 D=LUN ID입니다.
6. 소프트웨어 6.1. 시스템 소프트위어 및 사용 방법 6.1.1. PTOOLS 모든 노드의 /usr/local/ptools 아래에 parallel tool이 설치되어 있습니다. 이를 통해 시스템 설정을 위해서 모든 클러스터에 한곳에서 명령을 내릴 수 있습니다. n000(147.46.37.36)에서 내리는 클러스터 관리명령은 n001~n016 까지 전부 다 실행되도록 되어 있습니다. 각 명령에 대한 간략한 사용법은 다음과 같읍니다. - palive : 현재 클러스터 내에서 살아있는 노드의 정보를 검색합니다. cluster 파일에 등록된 노드들에게 ping을 보내서 반응이 오는 노드들만 alive란 파일에 등록합니다. 이를 통해 다른 p- 명령들이 alive내에 있는 노드들에게 rsh을 통해서 명령을 실행합니다. - pcp : parallel copy 명령입니다. [root@n000 ptools]# pcp /etc/passwd /etc 와 같이 실행하면 n000의 /etc/passwd를 모든 노드의 /etc 아래로 복사합니다. - pexec : parallel execution 명령입니다. [root@n000 ptools]# pexec date 와 같이 실행하면 모든 노드에서 date를 실행해줍니다. - pload : 모든 노드의 kernel load를 표시해줍니다. [root@n000 ptools]# pload - ploadu : 모든 노드의 특정사용자 load와 프로세스를 보여줍니다. [root@n000 ptools]# ploadu bslee - pmem : 모든 노드의 memory 상태를 표시 - preboot : 모든 노드를 reboot 시킵니다. 이 명령을 사용해도 되고 pexec reboot 와
같이 실행해도 됩니다. - pshutdown : 모든 노드의 shutdown - pswap : 모든 노드의 swap 상태 표시 - pup : 모든 노드의 uptime 표시 - puseradd, puserdel, pusersync : 모든 노드의 사용자를 add하고 delete하는 명령이며 pusersync는 현재 노드의 다른 노드의 사용자 정보를 일치시킵니다. 따라서 사용자를 추가하고자 할 때는 puseradd를 사용하셔도 되지만 blasta에서 유저를 만든 후에 [root@n000 ptools]# pusersync 를 실행하면 됩니다. 6.1.2. Ganglia Web based Monitor 전체 노드를 모니터링을 하기위한 tools로 사용자는 http://147.46.37.36 로 접속을 하면 각노 들의 상태를 모니터링을 하실 수가 있습니다. 만일, 노드의 부하가 많을시 에는 가운데 서버의 색이 부하에 따라 Red(Over 100% Utilization. Utilization is: (1 min load) / (number of CPUs) * 100%), Orange(75~100%), Yellow(50~74%), Green(25~49%), Blue(0~24%)로 변하며 서버가 다운이 될 시에는
Crossbones로 나타내 납니다. 자세한 내용은 http://ganglia.sourceforge.net/를 참조하시기 바랍니다. 6.1.3. MPICH 모든 노드의 /usr/local에는 mpich-1.2.5가 설치되어 있으며 gcc, intel, pgi와 연동이 되도록 mpich-1.2.5-gcc, mpich-1.2.5-intel, mpich-1.2.5-pgi로 설치가 되어 있습니다. MPICH에 대한 자세한 사항은 http://www-unix.mcs.anl.gov/mpi/mpich/를 참조하기 바라며 본 문서에서는 클러스터에서의 간략한 사용법 및 실행방법에 대해서만 언급할 것입니다. 6.1.3.1. Intel Compiler MPICH Intel Compiler MPICH를 사용한 프로그램은 mpicc, mpif77, mpicc, mpif90등의 명령을 사 용하여 컴파일 할 수 있으며 별도의 라이브러리나 인클루드 파일 경로를 지정할 필요가 없습 니다. 컨트롤 머신에서 컴파일된 프로그램은 다음의 명령을 통하여 노드에서 실행됩니다. $ mpirun -np X -nolocal./a.out 위의 명령에서 X는 프로그램 실행에 사용될 프로세서의 수를 나타내며 -nolocal 옵션은 컨트 롤 머신을 제외한 노드에서만 실행이 되도록 하는 옵션입니다. 만약 -nolocal옵션을 지정하지 않고서 컨트롤 머신에서 실행할 경우 실행이 되지 않을 수도 있습니다. 노드로 로그인 하여 실행할 경우는 -nolocal 옵션을 지정할 필요가 없습니다. 프로그램 실행에 사용될 노드의 리스트는 /usr/local/mpich-1.2.5-intel/shared/machine.linux에 지정되어 있으며 기본적으로 n001부터 n016까지 지정되어 있습니다. 따라서 병렬프로그램은 n001부터 순서대로 X 개가 각 노드에서 실행됩니다. 만약 특정 노드를 사용하여 계산을 수행하고자 할 경우는 자신의 홈 디렉토리에 다음과 같이 machine list 파일을 생성한 다음 수행하면 됩니다. machine.list 파일 n001 n002 n003 n004
만일 SMP 머신일 경우는 SMP 머신의 CPU 수만큼 CPU수를 노드번호 위에 써줍니다. SMP 일 경우 machine.list 파일 n001:2 n002:2 n003:2 n004:2 $mpirun -np 8 -nolocal -machinefile machine.list./a.out 이때도 만약 n001~n004사이의 노드가 아닌 다른 노드에서 실행할 경우는 반드시 -nolocal옵 션을 사용해야 합니다. 기타 자세한 내용은 앞서 언급한 URL을 참조하기 바랍니다. 6.1.3.2. PGI Compiler MPICH PGI Compiler 로 MPICH를 돌리기 위해서는 pmpicc, pmpif77, pmpicc, pmpif90등의 명령 을 사용하여 컴파일을 하여야 합니다. 이는 기본 mpicc, mpif77, mpicc, mpif90이 Intel Compiler와 기본으로 라이브러리가 연결이 되어 있기 때문입니다. 실행 방법은 앞서 Intel Compiler와 같습니다. 컨트롤 머신에서 컴파일된 프로그램은 다음의 명령을 통하여 노드에서 실행됩니다. $ pmpirun -np X -nolocal./a.out 위의 명령에서 X는 프로그램 실행에 사용될 프로세서의 수를 나타내며 -nolocal 옵션은 컨트 롤 머신을 제외한 노드에서만 실행이 되도록 하는 옵션입니다. 만약 -nolocal옵션을 지정하지 않고서 컨트롤 머신에서 실행할 경우 실행이 되지 않을 수도 있습니다. 노드로 로그인 하여 실행할 경우는 -nolocal 옵션을 지정할 필요가 없습니다. 프로그램 실행에 사용될 노드의 리스트는 /usr/local/mpich-1.2.5-pgi/shared/machine.linux 에 지정되어 있으며 기본적으로 n001부터 n016까지 지정되어 있습니다. 따라서 병렬프로그램 은 n001부터 순서대로 X 개가 각 노드에서 실행됩니다. 만약 특정 노드를 사용하여 계산을 수행하고자 할 경우는 자신의 홈 디렉터리에 다음과 같이 machine list 파일을 생성한 다음 수행하면 됩니다.
machine.list 파일 n001 n002 n003 n004 만일 SMP 머신일 경우는 SMP 머신의 CPU 수만큼 CPU수를 노드번호 위에 써줍니다. SMP 일 경우 machine.list 파일 n001:2 n002:2 n003:2 n004:2 $pmpirun -np 8 -nolocal -machinefile machine.list./a.out 이때도 만약 n001~n004사이의 노드가 아닌 다른 노드에서 실행할 경우는 반드시 -nolocal옵 션을 사용해야 합니다. 기타 자세한 내용은 앞서 언급한 URL을 참조하기 바랍니다. 6.1.3.3. GNU Compiler MPICH 기본적으로 c와 c++, f77은 리눅스 상에서 지원이 되므로 gmpicc, gmpicc, gmpif77등은 문 제없이 동작하나 fortran90의 경우 별도의 포트란90 컴파일러를 설치하지 않으면 동작하지 않 습니다. 컨트롤 머신에서 컴파일 된 프로그램은 다음의 명령을 통하여 노드에서 실행됩니다. $ gmpirun -np X -nolocal./a.out 위의 명령에서 X는 프로그램 실행에 사용될 프로세서의 수를 나타내며 -nolocal 옵션은 컨트 롤 머신을 제외한 노드에서만 실행이 되도록 하는 옵션입니다. 만약 -nolocal옵션을 지정하지 않고서 컨트롤 머신에서 실행할 경우 실행이 되지 않을 수도 있습니다.
노드로 로그인 하여 실행할 경우는 -nolocal 옵션을 지정할 필요가 없습니다. 프로그램 실행에 사용될 노드의 리스트는 /usr/local/mpich-1.2.5-gcc/shared/machine.linux 에 지정되어 있으며 기본적으로 n001부터 n016까지 지정되어 있습니다. 따라서 병렬프로그램 은 n001부터 순서대로 X 개가 각 노드에서 실행됩니다. 만약 특정 노드를 사용하여 계산을 수행하고자 할 경우는 자신의 홈 디렉터리에 다음과 같이 machine list 파일을 생성한 다음 수행하면 됩니다. machine.list 파일 n001 n002 n003 n004 만일 SMP 머신일 경우는 SMP 머신의 CPU 수만큼 CPU수를 노드번호 위에 써줍니다. SMP 일 경우 machine.list 파일 n001:2 n002:2 n003:2 n004:2 $mpirun -np 8 -nolocal -machinefile machine.list./a.out 이때도 만약 n001~n004사이의 노드가 아닌 다른 노드에서 실행할 경우는 반드시 -nolocal옵 션을 사용해야 합니다. 기타 자세한 내용은 앞서 언급한 URL을 참조하기 바랍니다. 6.1.4. rdist rdist 명령은 시스템 관리 및 전체 노드의 저장장치를 항상 동일하게 유지시키는데 사용되는 명령어입니다. 이러한 rdist명령을 사용하여 소프트웨어의 설치가 대단히 용이해집니다. 예를 들 어 전체 노드에 MPI를 인스톨한다고 생각해본다면 세 가지 방식이 존재할 수 있습니다. 1) 각 노드에 MPI를 인스톨한다.
2) 컨트롤 머신에 인스톨한 다음에 이를 각 노드에 ftp 혹은 rcp를 사용하여 복사한다. 3) rdist를 사용한다. rdist는 앞의 2가지 방식과는 파일 퍼미션 및 날짜 등을 일치시켜준다는 점에서 차이가 있습니 다. 뿐만 아니라 특정 파일이 갱신되었을 경우 갱신된 파일만을 다시 전송하여 준다는 점에서 대단히 편리합니다. 컨트롤 머신의 슈퍼유저 홈 디렉터리( /root )에 install_files 이 존재합니다. 이 파일의 내용은 다음과 같습니다. SYS_FILES=( /usr/local/mpich /usr/local/ptools/* /etc/profile.d/* ) GET_ALL=( n001 n002 n003 n004 n005 n006 n007 n008 ) all : ${SYS_FILES} -> ${GET_ALL} 위의 파일에서 SYS_FILES라는 필드가 복사하고자 하는 파일 혹은 디렉터리를 말합니다. 여기에 여러 개의 파일이나 디렉터리를 써줍니다. GET_ALL 이라는 필드는 파일이 전송되어야 할 호스트네임을 나타내며 여기서는 n001~n008 까지가 SYS_FILES에 있는 파일들을 전송 받게 됩니다. 위와 같이 파일을 만들고 다음과 같이 실행합니다. [root@n000 /root]# rdist -f install_files 이와 같이 수행할 경우 파일 혹은 디렉터리가 존재하지 않을 경우 자동으로 생성하고 만약 존재할 경 우는 갱신된 파일만 업데이트하게 됩니다. 만약 특정한 소프트웨어를 전체 노드에 인스톨하고자 할 경우 컨트롤 머신에 인스톨한 다음에 SYS_FILES에 소프트웨어가 인스톨 된 디렉터리 이름을 기입한 후 rdist를 실행하면 됩니다.
7. 정전 및 복구 7.1. 클러스터 정전시 클러스터의 환경은 다양한 환경에 위치합니다. 때로는 정전이 되기도 하는데 본 장에서는 정 전시 시스템을 안전하게 끄기 위한 방법을 기술합니다. 다음 사항 작업을 모두 매니지먼트 노드에서 실행이 되어야 합니다. 가. 시스템에 로그인 및 사용 중인 작업자를 살펴봅니다. 로그인 사용자 및 작업 중인 상태는 who: 및 pload"를 통하여 알 수 있습니다. pexec /usr/bin/who and pload 나. 사용자들에게 긴급 사항을 통보합니다. 이때 각 사용자들은 다양한 툴을 사용을 하실 수가 있는데 wall이란 명령어를 사용 하여 사용자들에게 시스템 shutdown을 알릴 수가 있습니다. wall "{message}" 사용 예)
나. 각 사용자들에게 통보 후 클러스터 노드와 NFS 노드에 연결된 마운트를 해제를 시켜 주어야 합니다. 이는 각 노드의 유저 홈 디렉터리가 NFS를 통하여 NFS 노 드에 공유되기 때문에 NFS mount를 먼저 풀어줌으로서 유저 데이터를 보호하기 위해서입니다. pexec /bin/umount {NFS mount point} 다. NFS 노드를 셧다운을 시켜 주시기 바랍니다. pexec -s <hostname> /sbin/shutdown -t now or pexec -s <hostname> /sbin/halt 주의 : pexec 옵션으로 -s를 사용하고 있음을 주의하시기 바랍니다. 라. 클러스터 노드를 셧다운을 시켜 주시기 바랍니다. pexec /sbin/shutdown -t now or pexec /sbin/halt 마. 매니지먼트 노드를 셧다운을 시켜 주시기 바랍니다. /sbin/shutdown -t now or /sbin/halt
7.2. 클러스터 노드 복구 클러스터를 복구하기위해서는 복구 CD가 있어야 합니다. 제공해드린 복구 CD는 RedHat 7.3을 기반으로 하여 제작한 복구 CD로 사용자는 간단히 몇 번의 키 조작으로 본래의 상태로 되돌릴 수가 있습니다. 복구 과장은 크게 3단계로 나누어집니다. 클러스터 구성 노드 중 Management 노드는 처음 구성시 DHCP로 구성이 됩니다. 이때 다른 컴퓨팅 노드는 추기 설치시 Management 노드로부터 아이피를 받아오고 처음 재 부팅시 Management 노드로부터 받은 아이피에 해당되는 호스트이름 및 기타 정보를 자동적으로 구 성 파일을 만들어 주도록 만들어져 있습니다. 다음 설치 때부터는 각 노드의 Mac 어드레스가 기억이 되므로 다음 설치시 자동적으로 예전 에 받은 아이피를 받아 재구성이 가능합니다. 다시 정리하면 복구 과장은 세단계로 이루어집니다. 첫째, DHCP 서버의 가동 둘째, 복구 CD를 통한 재 인스톨 셋째, 초기 부팅시 사용자 환경 자동 셋팅 복구시작 복구CD 인스톨 DHCP서버 재부팅 IP 할당 no 첫번째부팅? yes Eth0, eth1셋팅 Hostname 셋팅 복구완료
8. LSF 8.1. 병렬 코드 실행 LSF 병렬코드는 LSF Scheduler submit 를 이용하여 하여 실행한다. 우선 시스템의 상황을 살펴보는 명령은 다음과 같다. [ hpcman@n001 hpcman] $bhosts HOST_NAME STATUS JL/U MAX NJOBS RUN SSUSP USUSP RSV n001 ok -200 000 n002 ok -200 000 n003 ok -200 000 n004 ok -200 000 n005 ok -200 000 n006 ok -200 000 n007 ok -200 000 n008 ok -200 000 n009 ok -200 000 n010 ok -200 000 n011 ok -200 000 n012 ok -200 000 n013 unavail -2 0 0 0 0 0 n014 unavail -2 0 0 0 0 0 n015 unavail -2 0 0 0 0 0 n016 unavail -2 0 0 0 0 0 위의 상황은 현재 n001 ~n012시스템까지 이용가능하며 MAX라는 것은 각 노드별 수행할 수 있는 작업의 최대 수이다 각 노드별로 2개의 CPU가 설치되어 있으므로 모든 노드의 MAX값은 2로 설정 되어 있으며 RUN이라는 것은 현재 수행되고 있는 작업의수이다. NJOBS는 현재 수행 되고 있는 작업의 수이다. n013 부터 n016 까지는 Package서비스 노드이므로 병렬작업 수행에는 이용할 수 없다 특별히 32개의 작업을 수행해야 하는 경우에는 담당조교에게 연락해서 상의해야 한다. 그 리고 각 노드별 Resource의 현황을 살펴보기 위해서는 lsload라는 명령을 수행한다. 각 노드별 CPU 가동률과 이용 가능한 RAM 메모리 현황 등을 볼 수 있다 [ hpcman@n001 hpcman] $lsload HOST_NAME status r15s r1m r15m ut pg ls it tmp swp mem n001 ok 0.0 0.0 0.0 0%1.1 2 3 5748M 1028M 1771M
n006 ok 0.0 0.0 0.0 0%0.3 0 213 6260M 1027M 1859M n003 ok 0.0 0.0 0.0 0%0.3 1 52 6092M 1027M 1858M n002 ok 0.0 0.0 0.0 0%0.3 0 220 5996M 1027M 1860M n007 ok 0.0 0.0 0.0 0%0.3 0 214 6260M 1027M 1859M n004 ok 0.0 0.0 0.0 0%0.3 0 53 6260M 1027M 1859M n010 ok 0.0 0.0 0.0 0%0.3 0 214 6260M 1027M 1859M n011 ok 0.0 0.0 0.0 0%0.3 0 214 6096M 1027M 1859M n008 ok 0.0 0.0 0.0 0%0.3 0 214 6260M 1027M 1859M n005 ok 0.0 0.0 0.0 0%0.3 0 52 6100M 1027M 1859M n012 ok 0.0 0.0 0.0 0%0.3 0 214 6152M 1027M 1861M n009 ok 0.0 0.0 0.0 0%0.3 0 213 6316M 1027M 1861M n013 unavail n014 unavail n015 unavail n016 unavail 그런 다음에는 Job sumbit 파일을 작성한다 간단한 submit파일 예제는 다음과 같다. #BSUB -n 24 #BSUB -o 1.out #BSUB -e 1.err mpijob./xhpl 첫 번째 라인은 CPU를 24개 활용하겠다는 것이며 -o 옵션은 코드의 stdout 출력을 저장할 파 일이며 -e 옵션은 코드의 stderr 출력을 저장할 파일명이다 마지막 라인이 수행할 명령어를 적어주는 라인인데, 실제로 유저가 컴파일한 실행파일 앞에 mpijob이라는 keyword 반드시 적 어 주어야 한다. 그리고병렬프로그램컴파일시에사용한명령어와반드시일치시켜 주어야 하는데 규칙은 다음과 같다. mpijob :mpicc/mpicc/mpif77/mpif90 으로 컴파일했을 시 mpijob_gcc :gmpicc/gmpicc/gmpif77 으로 컴파일했을 시 mpijob_pgc :pgmpicc/pmpicc/pmpif77/pmpif90 으로 컴파일했을 시 작업 Submit을 작성하고 적절한 이름으로 저장 한다 예를 들어 위의 Submit 파일예제를 test1 이라고 저장했다면 다음의 명령어를 사용해서 submit 한다 $bsub <test1
submit 한 작업이 정상적으로 수행되는지를 알아보기 위해서는 bjobs라는 명령어를 수행시켜 본다 submit을 한 직후에는 stat가 PEND상태로 있다가 정상적으로 필요한 Resources를 할당받 으면 RUN으로 바뀌어 진다 그러면 bjobs명령어를 수행시키면 EXEC_HOST에 현재 작업을 수행하 고 있는 시스템의 리스트가 표시된다. 만약에 submit된 작업이 잘못 수행된 것이어서 유저가 취소하고 싶은 경우에는 bkill 명령어 를 실행시킨다. 명령어로 JOBID를 확인한 다음 실행한다. $bkill 671 8.2. 반복적 작업 수행 :Parametric Study 클러스터 시스템은 병렬 응용 프로그래밍의 개발 및 수행에도 많이 활용되지만 많은 공학 분 야에서 널리 활용되는 Parametirc Study와 같이 동일한 작업을 여러 개의 입력데이터를 이용 해서 수행해야 하는 이른 바 High-throughput Computing 환경에도 매우 적합하다, hpceng 시스템의 Scheduler인 LSF에서도 High-throughput Computing을 쉽게 구현할 수 있다. 예) p4c라는 실행코드를 이용하여 10개의 서로 다른 입력데이터를 이용해서 계산을 수행한 후 Stdout 출력을 서로 다른 파일에 저장할 경우 먼저 수행할 프로그램을 컴파일 한다 인텔 컴파일러, GNU gcc 컴파일러 등 적합한 컴파일러로 컴파일 한다 그런 다음 입력데이터 파일을 첨자를 이용해서 구별되도록 작성한다. 10 개의 입 력데이터일 경우 다음과 같이 작성하고 실행코드와 같은 위치에 옮겨 놓는다. input.1 input.2...input.10 그런 다음 bsub명령을 통해서 작업을 submit을 하는데 문법은 다음과 같다. bsub -J "arrayname[ indexlist,...] "myjob 위의 예제의 경우에는 다음과 같이 수행할 수 있다. $bsub -J "testarray[ 1-10] "-i"input.%i"-o"output.%i"-e"err.%i"./p4c ( 주의 에서 %l는 대문자 i입니다 )
위의 명령을 통해서 실제로 수행하는 작업은 다음과 같다../p4c input.1 :stdout =>output.1,stderr =>err.1./p4c input.2 :stdout =>output.2,stderr =>err.2./p4c input.10 :stdout =>output.10,stderr =>err.10 submit 한 작업을 상황을 알아보기 위해서는 앞에서 설명한 bjobs명령을 통해서 살펴 볼 수 있다 array를 이용해서 한 작업은 모두 동일한 JOBID를 가지게 된다 bjobs 명령을 통해서 array를 통해 submit된 작업의 전체 정보를 보려면 다음과 같이 사용한다. bjobs -A JOBID submit 한 작업을 취소할 때도 array 전체 작업을 한번에 취소할 수 있고 각각의 단위 작업별 로 취소할 수 있다. $bkill JOBID : 전체 작업 취소 (Ex.bkill 798 ) $bkill "JOBID[ Index] " (Ex.bkill "798[ 2] "798의 JOBID 작업 중 2번째 작업 취소 ) hpceng 시스템에서 작업의 dependency를 설정하는 방법은 -w "done(jobname)"이라는 옵션을 사용하는 것입니다. 한 가지 명심할 것은 jobname을 이용하기 위해서 -J옵션으로 모든 Q작업에 Jobname을 설정해 주는 것입니다. 예를 들어서 p4c라는 serial job과 test1파일에 명시된 병렬 job을 이용해서 돌리는 것을 살 펴보겠습니다. 먼저 test1파일에 병렬 job을 설정해 줍니다. #BSUB -n 8 #BSUB -o 1.out #BSUB -e 1.err mpijob./xhpl 그런 다음, jobexec 라는 파일을 만들어서 다음과 같이 적습니다..
bsub -J Job1./p4c bsub -J mpijob1 -w "done(job1)"<test1 bsub -J Job2 -w "done(mpijob1)"./p4c bsub -J mpijob2 -w "done(job2)"<test1 저장하고 나와서 chmod +x jobexec라는 명령을 통해서 실행권한을 설정해 줍니다. jobexec 파일을 살펴보면 두 번째 라인의 의미는 job1 이라는 이름의 jobname을 가지는 작업 이 완료되면 test1에 설정된 병렬작업을 수행하라는 의미입니다. job1 은 첫 번째 라인에 명 시된 p4c serial 작업입니다. 세 번째 라인의 의미는 두 번째 라인에 정의된 mpijob1이 완료되면 p4c코드를 돌리라는 의미 입니다. jobexec 를 수행하실 때는./jobexec라고 하시면 되고 각 단계별로 bjobs를 살펴보면 다음과 같습니다. [ hpcman@n009 Linux_mpich_intel] $./jobtest3 Job <1099>is submitted to default queue <normal>. Job <1100>is submitted to default queue <normal>. Job <1101>is submitted to default queue <normal>. Job <1102>is submitted to default queue <normal>. [ hpcman@n009 Linux_mpich_intel] $bjobs JOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME 1099 hpcman PEND normal n009 Job1 Mar 25 11:10 1100 hpcman PEND normal n009 mpijob1 Mar 25 11:10 1101 hpcman PEND normal n009 Job2 Mar 25 11:10 1102 hpcman PEND normal n009 mpijob2 Mar 25 11:10 [ hpcman@n009 Linux_mpich_intel] $bjobs JOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME 1099 hpcman RUN normal n009 n002 Job1 Mar 25 11:10 1100 hpcman PEND normal n009 mpijob1 Mar 25 11:10 1101 hpcman PEND normal n009 Job2 Mar 25 11:10 1102 hpcman PEND normal n009 mpijob2 Mar 25 11:10 [ hpcman@n009 Linux_mpich_intel] $bjobs
JOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME 1100 hpcman RUN normal n009 n005 mpijob1 Mar 25 11:10 n005 n012 n012 n007 n007 n006 n006 1101 hpcman PEND normal n009 Job2 Mar 25 11:10 1102 hpcman PEND normal n009 mpijob2 Mar 25 11:10 [ hpcman@n009 Linux_mpich_intel] $bjobs JOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME 1101 hpcman RUN normal n009 n011 Job2 Mar 25 11:10 1102 hpcman PEND normal n009 mpijob2 Mar 25 11:10 [ hpcman@n009 Linux_mpich_intel] $bjobs JOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME 1102 hpcman RUN normal n009 n003 mpijob2 Mar 25 11:10 n003 n008 n008 n004 n004 n010 n010
9. PBS 9.1. PBS(Portable Batch System) PBS는 Portable Batch System으로서 NASA Ames 연구 센타의 NAS(National Aerospace Simulation)와 Lawrence Livermore 국립 연구소의 NERSC(National Energy Research Supercomputer Center)의 합작 프로젝트의 결 과물입니다. 이 PBS는 POSIX 1003.2d의 배치 환경 표준 (Batch Enviromment Standard)을 따르며, 배치 작업을 수 용하거나, 작업의 특성을 컨트롤하거나, 작업이 실행되기 전에 중단, 실행, 작업을 준 노드에 결과물을 줄 수 있는 시스템입니다. PBS의 기능을 보면 다음과 같습니다. 1. job 실행 건트롤 기능 : 가장 기본적인 기능으로 job을 실행 및 정지, 우선 순의 (priority)도 설정을 할 수 있습니다. 2. 보안 및 사용자 제한 기능 : job을 실행 할 수 있는 노드, 그릅, 사용자를 지정하여 다양 한 정책을 사용할 수 있습니다. 3. 계산서(account)발행 : 사용자별로 사용 시간이나 사용 지원에 따른 상세한 명세표 를 발급할 수 있습니다. 4. 병렬 작업 처리 기능 : 리눅스를 포함한 다양한 플랫폼에서 병렬화를 위한 패키지를 지원을 합니다. 5. 표준의 API 제공 : POSIX표준의 API를 지원 합니다. 그로 인하여 다양한 다른 프로그램에서 PBS와 연동하는 기능을 손쉽게 구현을 할 수 있습니다.
9.2. PBS 사용방법 PBS를 사용하는 방법은 의외로 간단합니다. 먼저 PBS를 사용하기 위한 간단한 명령어에 대하여 알아보겠습니다. 자세한 사용방법은 http://www.openpbs.org/를 참조하시기 바랍니다. 9.2.1 사용가능한 노드 보기 pbsnodes : pbs node manipulation pbsnodes 란 명령어는 현재 PBS가 동작이 가능한 노드 및 작업에 걸린 상태를 볼수 있도록 해주는 명령어 입니다. 명령어 형식은 다음과 같습니다. pbsnodes [-{c o r}] [-s server] [nodename...] pbsnodes -{a l} [-s server] 각 옵션은 다음을 의미합니다. -a All nodes and their attributes are listed. The attributes include "state" and "properities". -c Clear OFFLINE or DOWN from listed nodes. The listed nodes are "free" to be allocated to jobs. -l List all nodes marked in any way. -o Mark listed nodes as OFFLINE even if currently in use. This is different from being marked DOWN. An automated script that checks nodes being up or down and calls pbsnodes with a list of nodes down will not change the status of nodes marked OFFLINE. This gives the administrator a tool to hold a node out of service without changing the automatic script. -r clear OFFLINE from listed nodes. 실행예는 다음과 같습니다.
화면에 보이듯이 현재 노드는 아무런 작업이 걸려 있지 않고 각 노드의 프로세서는 2개임을 알려 주고 있습니다. 9.2.2 PBS를 통하여 큐 사용하기 처음 사용자는 다음과 같은 스크립트를 통하여 자신의 작업을 PBS에게 알려 주어야 합니다. 다음은 가장 간단한 실행 스크립트 예입니다. #PBS -l nodes=1:ppn=1,walltime=00:30:00 #PBS -q dque {User running Command} 위에서 PBS -l 옵션은 PBS에게 User running Command를 연동시 사용할 노드 및 프로세서 수를 정해 주고 있습니다. 아래 PBS -q 옵션은 사용할 큐를 지정해주고 있습니다. 실행은 단순히 qsub {PBS_Running_Scripts}
주의 : qsub는 superuser (root)로 실행을 하시면 안 됩니다. 9.2.3 큐 상태 확인 하기 큐 상태를 확인하기 위하여서는 qstat란 명령어를 사용 할 수 있습니다. 실행 결과를 보면 다 음과 같습니다. 위 그림에서 보여주듯 pbs.qsub란 User_Running_Scripts를 qsub로 큐를 주었을 때 job id는 993.blasta이며 실행 유저는 baron, 작업 이름은 pbs.qsub이며 현 큐 상태는 R(uning)임을 보 여주고 있습니다. 아울러 앞서 설명한 pbsnodes란 명령어로 노드 상태를 보면 다음과 같이 blasta001 노드에 993.blasta.kisti.re.kr 이란 작업이 하나가 돌고 있음을 보여주고 있습니다. 9.2.4 작업중인 큐 지우기 이미 실행 혹은 대기 상태중인 큐를 지우는 명령어는 qdel이며 큐를 지우기 위해서는 job id 가 필요로 합니다. job id는 qstat란 명령어를 통하여 알 수 있습니다.
qdel [-W delay] job_identifier... 다음은 실행 예입니다. 9.2.5 Standard Out 결과 - 실행 Directory에 생성 file_name.o## : ##은 Queue Job ID입니다. 예) [baron@blasta baron]$ ls pbs.qsub.e993 정상 종료 시, 비정상 종료 시 생성 pbs.qsub.o993 정상 종료 시 생성 9.2.6 Error output - 실행 Directory에 생성 file_name.e## : ##은 Queue Job ID입니다
9.3. PBS의 구조 9.4. PBS 설치 9.4.1. PBS download and install http://www.openpbs.org 에서 OpenPBS_2_3_16.tar.gz을 /usr/loca/src/에 다운로드 후 아래 순서대로 설치하여주시기 바랍니다. $ gunzip -c OpenPBS_2_3_16.tar.gz tar xovf - $ cd OpenPBS_2_3_16 $./configure $ make $ make install 9.4.2. PBS 설정 9.4.2.1. 서버 PBS Server로 구동하기 위한 중요한 설정 파일은 아래와 같습니다. /usr/spool/pbs/server_name /usr/spool/pbs/server_priv/nodes /usr/spool/pbs/mom_priv_config
먼저, pbs server 이름을 server_name란 파일로 만들어 주시가 바랍니다. $ vi /usr/spool/pbs/server_name blasta 다음으로, pbs가 job을 돌릴 수 있는 노드 목록을 만들어 주어야 합니다. $ vi /usr/spool/pbs/server_priv/nodes blasta002 np=2 blasta003 np=2 np=number는 가상 프로세서(vp)를 정의를 합니다. 예를 들어 np=4라 하면 이 표현은 1명의 직 업 또는 1명 이상의 직업을 할당받는 것을 허락하는 것입니다. 만일 np=#가 클러스터 노드를 위해 지정되어 있지 않으면 VP는1로 간주 합니다. 주의 : pbs server에서 pbs job이 돌기를 원치 않을 경우는 반드시 nodes 파일에 pbs server를 제외를 시켜야 합니다. config에는 pbs로 관리를 하고 싶은 노드들을 포함해야만 합니다. $ vi /usr/spool/pbs/mom_priv/config $logevent 0x1ff $clienthost blasta001 $clienthost blasta002 $clienthost blasta003 주의 : pbs server에서 pbs job이 돌기를 원치 않을 경우라도 반드시 config 파일에는 pbs server가 포함이 되어야 합니다. mom demon을 실행을 시켜주시기 바랍니다. $ /usr/local/sbin/pbs_mom 처음 셋팅시에만 pbs_server을 실행시 아래와 같이 -t create 옵션을 사용하여 주시기 바랍니다. $ /usr/local/sbin/pbs_server -t create
pbs scheduler를 실행하여 주시기 바랍니다. $ /usr/local/sbin/pbs_sched 9.4.2.2. 클라이언트 클라이언트 셋팅은 아래 두 가지 파일만 설정을 하시면 됩니다. /usr/spool/pbs/server_name /usr/spool/pbs/mom_priv_config 서버 셋팅과 마찬가지로 server_name에 PBS server를 지정하시면 됩니다. $ vi /usr/spool/pbs/server_name blasta config에는 pbs로 관리를 하고 싶은 노드들을 포함해야만 합니다. $ vi /usr/spool/pbs/mom_priv/config $logevent 0x1ff $clienthost blasta001 $clienthost blasta002 $clienthost blasta003 pbs_mom daemon을 실행하여 주시기 바랍니다. $ /usr/local/sbin/pbs_mom (you need to be root to do this!!!) pbsnodes -a라 치면 모든 노드들의 status가 free라고 나와야 정상입니다. $ pbsnodes -a 9.4.2.3. Qmgr 실제 작업을 위해서는 PBS 서버에서 Queue Manager 설정을 하셔야 합니다. queue manager를 시작하여 주시기 바랍니다.
$ qmgr 다음은 설정 예입니다. Qmgr: create queue defaultq queue_type=e Qmgr: s q defaultq resources_min.cput=1 Qmgr: s q defaultq resources_max.cput=12:00:00 Qmgr: s q defaultq resources_default.cput=30:00 Qmgr: s q defaultq enabled=true Qmgr: s q defaultq started=true Qmgr: s s defaultq scheduling=true Qmgr: s s default_queue=defaultq Qmgr: set server managers=user_name@server_name Qmgr: set server resources_default.nodect = 1 (This is crucial for exclusive run!) Qmgr: set server resources_default.nodes = 1 (This is crucial for exclusive run!) 서버 설정을 체크하여 주시기 바랍니다. Qmgr: print server # Create queue and set their attributes # # # Create and define queue defaultq # create queue defaultq set queue defaultq queue_type = Execution set queue defaultq resource_max.cput = 12:00:00 set queue defaultq resource_min.cput = 00:00:01 set queue defaultq resource_default.cput = 00:30:00 set queue defaultq enabled = True set queue defaultq started = True # # Set server attributes # set server scheduling = True
set server managers = ypuser@workshop set server default_queue = defaultq set server log_events = 511 set server mail_from = adm set server resources_default.neednodes = 1 set server resources_default.nodect = 1 set server resources_default.nodes = 1 set server scheduler_iteration = 600 Qmgr: Qmgr: quit pbs damon을 다시 실행하여 주시기 바랍니다.(이작업은 root 계정으로 하여 주시기 바랍니다. $ /usr/local/sbin/pbs_mom $ /usr/local/sbin/pbs_sched $ /usr/local/sbin/pbs_server 클라이언트 쪽도 마찬가지로 pbs_mon 데몬을 다시 시작하여 주시기 바랍니다. (root 계정으로 실 행하셔야 합니다.): $ /usr/local/sbin/pbs_mom pbsnodes -a라 치면 모든 노드들의 status가 free라고 나와야 정상입니다. $ pbsnodes -a 9.4.2.4. 서버 설정 값 저장 및 재사용 앞서 pbs server 설정 값을 저장을 할 수도 있으며 이 저장된 값을 이용하여 다시 셋팅시 사용을 할수도 있습니다. qmgr -c "print server" > /tmp/server.con 저장된 셋팅 값을 사용하여 나중에 다시 셋팅시 적용을 할 수가 있습니다. qmgr < /tmp/server.con
9.4.2.5. qmgr 설정 예제 # Create queues and set their attributes. # # # Create and define queue verylong # create queue verylong set queue verylong queue_type = Execution set queue verylong Priority = 40 set queue verylong max_running = 10 set queue verylong resources_max.cput = 72:00:00 set queue verylong resources_min.cput = 12:00:01 set queue verylong resources_default.cput = 72:00:00 set queue verylong enabled = True set queue verylong started = True # # Create and define queue long # create queue long set queue long queue_type = Execution set queue long Priority = 60 set queue long max_running = 10 set queue long resources_max.cput = 12:00:00 set queue long resources_min.cput = 02:00:01 set queue long resources_default.cput = 12:00:00 set queue long enabled = True set queue long started = True # # Create and define queue medium # create queue medium set queue medium queue_type = Execution set queue medium Priority = 10 set queue medium max_running = 96 set queue medium resources_max.cput = 02:00:00 set queue medium resources_min.cput = 00:20:01 set queue medium resources_default.cput = 02:00:00
set queue medium enabled = True set queue medium started = True # # Create and define queue small # create queue small set queue small queue_type = Execution set queue small Priority = 100 set queue small max_running = 10 set queue small resources_max.cput = 00:20:00 set queue small resources_default.cput = 00:20:00 set queue small enabled = True set queue small started = True # # Create and define queue default # create queue default set queue default queue_type = Route set queue default max_running = 10 set queue default route_destinations = small set queue default route_destinations += medium set queue default route_destinations += long set queue default route_destinations += verylong set queue default enabled = True set queue default started = True # # Set server attributes. # set server scheduling = True set server max_user_run = 6 set server acl_host_enable = True set server acl_hosts = *.ntckorea.com set server acl_hosts = *. ntckorea.com set server default_queue = default set server log_events = 63 set server mail_from = adm set server query_other_jobs = True
set server resources_default.cput = 01:00:00 set server resources_default.neednodes = 1 set server resources_default.nodect = 1 set server resources_default.nodes = 1 set server scheduler_iteration = 60 set server default_node = 1#shared 9.4.2.6. qsub 예제 You must used script or qsub command. Sample PBS run script is vi PBS.run #PBS -l nodes=8:ppn=1,walltime=00:30:00 #PBS -q dque echo echo echo ====================================================== echo Working directory is $PBS_O_WORKDIR echo echo Running on host `hostname` echo echo Start time is `date` echo echo Running Directory is `pwd` echo echo This jobs runs on the following nodes : echo `cat $PBS_NODEFILE` NOP=$(wc -l $PBS_NODEFILE awk '{print $1}') echo echo This job runs on the following process : $NOP echo echo ========================================================
##export P4_SOCKBUFSIZE=0x40000 #export P4_GLOBMEMSIZE=33554432 ##export P4_GLOBMEMSIZE=16777296 #export P4_GLOBMEMSIZE=8388648 #export P4_GLOBMEMSIZE=4194304 cd $PBS_O_WORKDIR mpirun -machinefile $PBS_NODEFILE -np $NOP {source} qsub PBS.run 9.4.2.7. 9.5 RedHat 8 이상 또는 gcc 3.2 기반 설치 Open PBS를 RedHat 8 이상 gcc3.2 기반 이상에서 설치하기 위해서는 두 가지 방업이 있다. 9.5.1 OpenPBS patch 사용 Open PBS를 RedHat 8 이상 또는 gcc 3.2 기반 이상에서 설치 할 때는 반드시 패치가 필요로 한 다. 본 패치는 다음 사이트에서 구할수 있다. http://bellatrix.pcl.ox.ac.uk/~ben/pbs/ 위 사이트에 접속을 하여 보면 PBS에 관련된 여러 패치를 구할 수 있다. fifo_improv.patch Updated: 24-10-2002 Various improvements to the FIFO scheduler and server:- The server variable "node_pack" is now also a queue variable (if set for a queue, jobs in this queue use the queue's node_pack value rather than the server's) A new queue property "required_property" is added which can be used to tie queues to nodes; this is one or more colon-separated node properties, which the FIFO scheduler will add to the node specification of all jobs run on this queue. Thus, jobs on this queue can run only on nodes with "required_property". A new server property "proc_pack" is added. If set to TRUE, then any jobs with a "simple" node specification (i.e. a number of nodes, optionally followed by properties, with no "+" or "ppn=" given) will be "packed" onto processors by the FIFO scheduler so that full advantage of available SMP machines is taken. For example the specification "nodes=4:blue" will be changed to "nodes=1:ppn=4#blue" if a 4-processor SMP machine is available,
"nodes=2:ppn=2#blue" if two 2-processor machines are available, "nodes=1:ppn=2+2:ppn=1#blue" if a 2-processor machine and two 1-processor machines are available, etc. Packing is carried out to minimise the number of nodes (i.e. maximise the number of processors per node). Even if "proc_pack" is TRUE, a complex specification, containing "+" or "ppn=", will be left unchanged - e.g. "nodes=4:ppn=1:blue" will always run on 4 separate nodes, and will never be packed into 4 processors on one node. fifo_nomomtalk_offline.patch Updated: 23-1-2001 Patches the FIFO scheduler to prevent it from inquiring after resources from MOM on nodes which are marked as "offline". nodefix.patch Updated: 7-11-2000 Fixes a problem with the PBS server; under some circumstances the server will claim that insufficient nodes are available to run a job, due to a bug in the node allocation code. This simple patch fixes that behaviour. nodespeed.patch Updated: 24-1-2001 Adds a new node attribute "speed". This is used by the server when "node_pack" is set; nodes are sorted by the speed attribute before being sorted by the number of free/in use VPs. Nodes are sorted such that those with the higher "speed" values are chosen first. proclimit.patch Updated: 13-2-2002 Adds a new queue variable max_user_proc. This is similar in behaviour to the existing max_user_run variable, except that it enforces an upper limit on the number of processors used by a user's jobs in a particular queue, rather than a limit on the number of jobs. It can also be used to limit named users on the given queue. Syntax: max_user_proc = n[:user1:x][:user2:y]... where n is the maximum number of processors that any user can use; additionally user1 will be limited to "x" processors (or n, if n is smaller than x), and user2 to y. fairshareproc.patch Updated: 13-2-2002 Tweaks the default FIFO PBS scheduler, to weight fairshare usage by the number of processors used by a job (e.g. a 10 hour job on 4 processors would count as equal to a 40 hour job on 1 processor, before the half-life is applied). This is useful when running non-pbs-aware parallel jobs, e.g. via. MPICH's "mpirun". N.B. Requires proclimit.patch to first be applied.
qterm.patch Updated: 13-11-2000 Modifies the qterm command to make the -t specification mandatory. Useful to avoid accidentally invoking the default behaviour, which may be undesirable on platforms that do not support checkpointing. quickshutsig.patch Updated: 7-11-2000 Modifies the PBS server to do a "quick" shutdown on receipt of a terminating signal. Useful for Linux clusters, where the default behaviour is to restart all jobs from the beginning when the server is restarted (due to the lack of checkpointing support on this platform). readline.patch Updated: 05-6-2002 Adds readline support to qmgr on systems that have the readline library, to allow history support, improved editing and filename completion on the qmgr command line. Since this patch modifies configure.in, to properly rebuild PBS after the patch is applied you should run "autoconf" to rebuild configure, and then delete config.cache before rerunning configure. mom_softkill.patch Updated: 22-5-2002 Modifies the MOM code (on Linux systems only) to "gracefully" kill processes. (The current behaviour under many circumstances is to send SIGKILL signals to each process, which kills them instantly.) With this patch, SIGTERM signals will be sent instead; only if the process fails to shut down and exit within 5 seconds will the SIGKILL signal then be sent. This is useful for ensuring that any daemons (e.g. with LAM/MPI) started by a job are given the chance to shut down properly at job termination time. openpbs-buildroot.patch Updated: 24-4-2002 Fixes the OpenPBS Makefiles to honour the DESTDIR environment variable, such that "make install" can install into a buildroot (e.g. for making RPMs). openpbs-sendmail.patch Updated: 24-4-2002 Disables the "configure" test for sendmail when building OpenPBS; instead, the path /usr/sbin/sendmail is hardcoded. This is useful when the machine that you're building OpenPBS on does not have sendmail installed, and you intend to deploy it on a machine that does. openpbs-gcc32.patch Updated: 17-02-2003 Allows OpenPBS to be built with the gcc-3.2 compiler.
openpbs-errno.patch Updated: 10-04-2003 Allows OpenPBS to be built under RedHat 9 (and presumably on other systems that use the Linux Native Posix Thread Library). Note that if you are not applying this patch on top of the OSC fault tolerance patch (see below) then you'll have to add an "#include <errno.h>" to the file src/server/svr_connect.c to get things to work. fault-tol-fix-offline.patch Updated: 17-02-2003 Apply this on top of the OSC fault tolerance patch (available from the OSC website) to allow the PBS server to talk to offline nodes, so that jobs finish properly, etc. 이중 gcc.32 에 관련된 패치만 적용을 하면 gcc3.2 기반에서도 OpenPBS를 사용 할 수 있다. patch 적용 방법은 다음과 같다. patch -p1 < openpbs-gcc32.patch 9.5.2 TORQUE 사용 (Tera-scale Open-source Resource and QUEue manager) OpenPBS 는 2001년 12월 6일 버전 2.3.16 이후로 새로운 버전이 발표가 되고 있지 않았다. 그러 다가, Cluster Resources Inc.에서 OpnePBS 기반으로 TORQUE 란 이름으로 새롭게 탄생하게 되 었다. TORQUE의 특징은 다음과 같다, TORQUE provides enhancements over standard OpenPBS in the following areas: Fault Tolerance Additional failure conditions checked/handled Many, many bugs fixed Node health check script support Scheduling Interface Extended query interface providing the scheduler with additional and more accurate information Extended control interface allowing the scheduler increased control over job behavior and attributes Allows the collection of statistics for completed jobs Scalability Significantly improved server to MOM communication model Ability to handle larger clusters (over 15 TF/2,500 processors)