System Compleat.

'수퍼컴퓨팅 클러스터'에 해당되는 글 1건

  1. GPI, PGAS for HPC

GPI, PGAS for HPC

Techs

( younjin.jeong@gmail.com, 정윤진 )

이런 기사가 일요일 새벽에 떴다.

GPU to GPU Communication Over InfiniBand to be Demonstrated at ISC'11



내용이 무엇인고 하니, 제목에서 알 수 있듯이 HPC에서 GPU와 GPU간의 통신을 Infiniband 를 통해 구현하여 동작하는 모습을 ISC'11 이라는 행사에서 데모로 시연하겠다는 말이다.  기사를 좀 읽어 보니 Fraunhofer Institut ITWM 이라는 회사가 GPI 를 통해 구현 했단다.  음.. GPI 는 원래 내 알기로 Graphic Programming Interface 였는데, 혹시나 해서 보니 역시나 아니다. 그래서 포스팅 한건 더 한다. ㅠㅠ

ISC'11 이라는건 International Supercomputing Conference 2011 이다. 올해는 독일 함부르크에서 하고 있단다. 나도 가보고 싶다 ㅠㅠ  이벤트 홈페이지는 http://www.supercomp.de/isc11/




아무튼 세상은 정말 빠르게 발전하고 있는가보다. HPC에 관심있는 분들이라면 이미 MPI에 대해서는 한번쯤은 들어보았을 것이다. MPI는 Message Passing Interface 로서, 물리적으로 서로 다른 노드간에 동일한 데이터를 처리하기 위해 지정된 노드간의 프로세싱과 관련된 메세지 통신을 지원하는 인터페이스를 말한다. 말이 좀 어려운데, 간단하게 풀자면 만약 듀얼 코어 시스템이 4대가 있다 치자. 어떤 대규모의 계산을 수행해야 할때, 컴퓨터 한대에서 수행 하는 것이 아닌 프로세서를 6개를 사용하고 싶다고 할때, 시스템 3대를 사용하게 된다. 이때 3대의 시스템 사이에서 데이터 처리를 위해 주고 받는 메세지를 처리하는 방법을 정의한 것을 MPI 로 이해하면 쉽다. 실제 MPI 자체는 인터페이스를 규정하는 표준 정도로 생각하면 되고, 이를 실제 클러스터에서 구현하려면, 각 노드를 InfiniBand 나 10G 로 묶어서 물리적 환경을 구성해 준 다음, MPICH 또는 MPICH2 환경을 구성해 주면 된다. 이는 보통 MPI 라이브러리를 사용한 포트란이나 gcc, 와 같은 컴파일러와 함께 설치되며, 이러한 컴파일러를 사용하도록 구성된 어플리케이션을 사용하는 경우 자연스럽게 MPI 를 사용 할 수 있도록 지원한다. 이 말은, 즉 최근의 HPC Cloud 에서도 설정하여 사용이 가능하다는 의미 되겠다. 물론 이 MPI 는 기존의 CPU를 사용하는 방법이며, 이를 확장, 발전 시킨 것이 바로 GPI가 되겠다.


MPI에 관련된 자세한 사항은 다음의 링크에서 정보를 얻도록 한다.
http://www.mcs.anl.gov/research/projects/mpi/
http://www.mcs.anl.gov/research/projects/mpich2/index.php


Fraunhofer


http://www.gpi-site.com/
여기에 사용된 모든 이미지는 위의 사이트로 부터 가져온 것임을 미리 밝힌다.


GPI - Global Address Space Programming Interface

이 GPI는, Fraunhofer Institut ITWM 에 의해 새롭게 구현된 개념이며, 새로운 언어를 사용하는 대신 C, C++, Fortran 의 API를 지원한다. 물론 이미 산업 현장에서 검증 받은 기술이며, 기존의 MPI 가 가지고 있던 구조적인 확장의 한계를 종식시켰다. 이는 다수의 GPI 벤치마크 구성을 통해 어떻게 어플리케이션이 멀티 코어 시스템에서 병렬처리가 가능하도록 구성되는지 확인 할 수 있겠다.

The GPI Architecture




GPI

GPI는, Infiniband나 10GE 을 사용하여 연결된 클러스터간의 낮은 지연시간을 충족하는 라이브러리와 런타임 시스템을 제공함으로서 병렬 처리하도록 구성된 어플리케이션의 확장 가능한 실시간 분산 컴퓨팅 시스템의 구성이 가능하게 한다. 이는 어플리케이션에 PGAS(Partitioned Global Address Space)를 사용하여 원격의 데이터 위치에 대한 직접적이고도 완전한 접근을 제공한다. 대부분의 통신의 기본은, 런타임 환경 체크, 패스트 배리어(Fast Barrier)나 글로벌 아토믹 카운터(Global atomic counter)의 동기화에 사용됨으로서, 대규모로 확장이 가능한 병령 프로그램의 개발이 가능하도록 한다.

성능의 측면에서는, 주어진 네트워크 회선 속도를 최대한 활용하고, 계산과 통신을 오버랩하여 통신의 부하를 최소화 한다.(완전한 비동기 통신)

GPI는 대량의 데이터에 대한 간단하고도 신뢰할만한 시스템을 제공하며, 빡센 I/O와 계산을 위한 동적이고도 불규칙적인 어플리케이션의 사용을 가능하게 한다.


MCTP

MCTP는 GPI를 노드레벨에서 지원한다. 소프트웨어 개발자들은 이제 더이상 프로세서의 속도를 기반으로 개발할 수 없게 되었다. 따라서 다중 스레드 디자인은 대규모로 확장이 가능한 어플리케이션의 개발을 위한 필수적인 사항이다.

MCTP는 기존의 프로그래머들에게 친숙한 멀티 스레딩 프로그래밍을 지원하는 일종의 스레딩 패키지다. 이는 플랫폼에서 발생하는 네이티브 스레드를 추상화하고, 스레드, 스레드풀, 그리고 높은 주파수의 타이머 또는 동기화와 같은 해결이 어려운 부분에 대해 최첨단의 해법을 제공한다.

일반적인 스레드 라이브러리와 구분되는 MCTP의 중요한 기능중 하나는, 코어 매핑을 위한 캐시와 NUMA 레이아웃을 하드웨어 레벨에서 완전히 지원한다는 점이다.


Benchmarks

MD Benchmark


일반적인 Molecular dynamics 어플리케이션에서의 MPI 와 GPI 의 성능 차이를 보여주고 있다. 그래프를 보면 알겠지만, MPI에 비해 GPI가 보다 큰 데이터를 처리할때 보다 많은 노드를 사용하여 높은 성능을 구가할 수 있음을 보여준다.


Bandwidth


2대의 노드를 사용하여 MPI 와 GPI의 메세지 전달에 사용될 수 있는 최대 대역폭에 대한 그래프를 보여주고 있다. 쉽게 설명하자면, 데이터 처리를 위해 공유되는 메세지의 크기는 각 메세지 별로 크거나 작을 수 있는데, GPI는 일반적으로 MPI 보다 훨씬 작은 메세지 사이즈에서도 최대의 대역폭을 사용할 수 있음을 확인 할 수 있다. 이는 병렬 컴퓨팅에서 매우 중요한 부분중 하나인데, 만약 메세지 전달의 오버헤드가 크면 실제 계산의 속도는 32개의 노드보다 16개의 노드가 빨라지게 되는 웃지못할 사건이 생기게 된다. 물론 이러한 현상은 비단 대역폭 때문만은 아니라 처리해야 할 데이터의 성격에도 관련이 있기는 하지만, 이러한 대역폭은 클러스터링의 구성에 대한 선택에 매우 중요한 포인트가 된다.

2D-FFT


이런 시스템을 사용하시는 분들이라면 잘 알고 계실 병렬 컴퓨팅의 계산 방법 중 하나이다. 그래프를 보면 일반적인 MPI는 128개의 코어가 넘어가게 되면 계산을 위한 시간이 다시 증가하는 것을 볼 수 있는데, 이는 메세지 통신의 오버헤드 또는 데이터의 동기화에 코어가 많아질 수록 처리시간이 증가하기 때문이다. 하지만 GPI는 노드 증가에 따라 꾸준히 그 성능이 좋아지는 것을 확인 할 수 있다.


Collectives



All Reduce 에 대한 그래프이다. 단순히 MPI 에 비해 빠른것 뿐만 아니라, 확장성에서도 매우 뛰어난 것에 주목해야 한다. 512 코어에서는 MPI 가 GPI 에 비해 70% 의 시간이 더 소요되는 것에 주목하자.

Mem barrier



이는 서로다른 라이브러리의 스레드 성능을 나타낸다. MCTP_NUMA 1.52 가 가장 좋은 성능을 나타내고 있으며, 이러한 성능이 코어가 증가될 때에도 지속적으로 유지되는 점에 주목하여야 한다.


Tile Rendering



일반적인 3D 렌더링이나 2D 작업에 사용되는 타일 렌더링에 대한 벤치마킹 그래프이다. 역시, MCTP가 가장 우월한 성능을 보임을 나타낸다. 세로축의 숫자는 초당 처리되는 프레임(사진 한장)의 갯수라고 보면 된다.




Installation

현재 해당 업체의 홈페이지의 다운로드 페이지에 갔더니 가입하라고 한다. 지금 당장 테스트 해볼 플랫폼도 없어서 그냥 설명으로 대신 한다. 하긴 생각해 보면 이런 툴 사용하시는 분들은 굳이 여기에 적어놓지 않아도 벌써 사용하고 계시지 싶다. ㅋ 뻘짓인가..  물론 직접 설치해 본 것이 아니기 때문에 발생 할 수 있는 예외사항에 대한 고려는 읍다.

플랫폼 요구사항.

  • 반드시 Linux , Supported Linux distribution. ( GPI가 OFED 스택 기반이므로 )
  • 64bit 지원한다.
  • GPI 데몬은 root 권한으로 동작해야 한다.
  • Infiniband/Ethernet 드라이버 및 완벽한 설정
  • Infiniband/Ethernet 의 멀티캐스트 네트워크 설정
  • 파일 캐시 제어
  • 사용자 인증 (PAM)
  • GPI 프로세스에 대한 완벽한 제어. 일반적으로 발생하는 문제는 거의 배치 시스템 연동 부분
  • GPI 바이너리에 대한 의존성 확인 ( ldd 등으로 필요한 라이브러리 확인 )

위의 내용 말고도 몇가지 더 있지만 워낙 당연한 것들이라 제외했다.


GPI 데몬 설치

설치를 위해서는 단 하나의 스크립트만이 존재한다. install.sh  이 스크립트는 GPI 데몬을 설치한다. 이 스크립트를 동작할 때는 반드시 -i 옵션과 함께 사용하여야 한다. -i 옵션은 라이센스 서버의 IP 이며, -p 옵션은 GPI 가 설치될 경로를 지정한다. GPI 데몬은 RPM 으로 제공되며, 설치가 완료된 이후에는 다음의 설정 파일들이 생긴다.

  • /usr/sbin/gpid.exe
  • /usr/sbin/gpid_NetCheck.exe 
  • /etc/ 하위에 설정 파일
  • /etc/init.d/ 에 gpid 스크립트. 런레벨 3과 5가 기본으로 활성화 되어있음
  • /etc/pam.d/ 에 gpid_users

/etc/init.d/gpid 가 올바른 설정값을 가지고 있다면, 설치 된 이후에 데몬은 바로 시작될 것이다.
설정 파일은 /etc/gpid.conf 에 위치한다. 구동하기 전에 잘 살펴보자. 이는 machinefile 이 위치한 디렉토리를 설정해야 하는데, 이 machinefile 이라는건 병렬 처리할 클러스터의 각 노드 리스트를 넣어준 것이라고 보면 된다.

보통 PBS와 함께 연동하는 경우가 많을텐데, 이런 경우 /etc/gpid.conf 에 보면 다음과 같은 설정이 있을 것이다.

NODE\_FILE\_DIR=/var/spool/torque/aux   # 아... 망할 윈도우 \ 표시 증말 싫다 ㅠㅠ

만약 machinefile에 중복된 호스트네임 엔트리가 있으면,  해당 노드는 사용되지 않는다. 옵션에 대한 설명은 따로 하지 않는다.


GPI SDK

역시 설치를 위해서는 1개의 스크립트가 지원된다. install.sh 이는 -p 옵션으로 반드시 설치될 위치를 지정해 주어야 한다. 설치가 완료되면 다음의 내용들이 시스템에 존재할 것이다.

  • /include/  어플리케이션 개발자를 위한 헤더
  • /lib64/  라이브러리
  • /bin/ 사용자의 바이너리가 위치할 디렉토리. 서브디렉토리의 사용도 허용된다.
  • /bin/gpi_logger  워커 노드 GPI 어플리케이션의 stdout 을 확인하는데 사용 될 수 있다.


다들 잘 아시겠지만, 이는 그저 MPI 와 같이 그 자체만으로는 아무것도 하지 않는다. SDK 를 사용하여 클러스터를 사용하도록 지원되는 라이브러리를 사용하여 어플리케이션을 개발하고, 빌드하여야 비로소 동작한다. 물론 PBS와 같은 시스템과의 연동을 위해서는 추가적인 작업이 좀 필요하긴 하지만, 전반적으로 MPICH 와 비슷한 구성이므로 분야에 익숙하신 분들께는 그 내용이 그다지 어렵지는 않을 것이다.


보다 자세한 내용은 해당 홈페이지에서 다운로드가 가능한 문서들을 참조하도록 한다.  어차피 라이브러리를 블로그 한페이지에 다 설명하는 것 자체가 정상이 아니라고 본다 나는.  흑.. 이미 충분히 길다.  아.. 나도 자바스크립트 열심히 배워서 간지나는 코드 박스 넣어줘야지. ㅠㅠ


개발 된지 얼마 되지 않은 라이브러리인 듯 하다. 이런 추세를 살펴보면, 일반적인 웹과 수퍼컴퓨팅이 결합될 날도 머지 않은 듯 하다. HPC나 수퍼컴퓨팅은 예로부터 PBS 와 같은 시스템에서 배치로 클러스터에 잡을 떨구는 형태였는데, 이를 조금만 웹 스타일로 세련되게 바꾸면 디게 멋져질 것 같다. 어떤 서비스에 적합할런지는 아직 모르겠지만, 만약 나중에 트위터 정도의 데이터를 실시간으로 분석해야 한다면 이런 결합이 필요하지 않을까? 말이 트위터지만, 전 세계의 주식 거래에서 오고가는 주가 변동의 정보와 이에대한 실시간 분석등이 웹으로 지원 될 수 있다면. 뭐, 그저 꿈일 수도 있지만 어쨌든 그만한 데이터의 처리를 위해서는 단순한 클라우드 뿐 아니라 HPC 도 주요한 역할을 할 수 있다고 생각한다.
단지 기상 데이터나 천체의 시뮬레이션과 같은 연구 목적에서 벗어나서 말이다.


(younjin.jeong@gmail.com, 정윤진)