1/19 페이지

WRF 대기 모델 해석 클러스터

시스템 성능 분석 보고서

본 자료는 ㈜클루닉스에서 자사 통합 시뮬레이션 시스템 구성 제품인 GridCenter

를 이용하여 지역 규모 대기 모델인 WRF에 대한 클러스터 병렬 해석 성능을 분석

한 보고서입니다. ㈜클루닉스의 협의 없이 발췌 및 배포를 금합니다.

BMT 환경: GridCenter-CAP, GridCenter-HPC

BMT S/W : WRF (Weather Research and Forecasting Model)

BMT 주관 : 클루닉스 기술부

BMT 일자 : 2009년 03월 10일~2009년 03월 20일

시스템 구축 밑 튜닝: 클루닉스 기술부/수석 컨설턴트 서 진우

CAE 어플리케이션 구축 및 튜닝 : 클루닉스 기술부/수석 컨설턴트 서 진우

2/19 페이지

목차

1. BMT 환경 정보

2. BMT 주요 시나리오 소개

3. BMT 항목 별 결과 및 분석

4. BMT 결론

첨부 : GridCenter-HPC를 통한 WRF 해석 주요 화면 자료

3/19 페이지

1. BMT 환경 정보

- H/W 구성 정보

세부 사양 자원 수

Cpu Intel(R) Xeon(TM) Quad E5420 CPU 2.5GHz 2cpu(8core)

Memory DIMM Synchronous 667 MHz 2GByte 4개 (16Gbyte)

Hard disk SAS DELL 230GByte 1개 (160Gbyte)

Network BM NetXtreme II BCM5708 Gigabit Ethernet 2port

nodes Dell (PowerEdge) 4 nodes

기본 BMT 진행은 클루닉스 사내의 준비된 32core(4 nodes) 규모의 HPC 시스템에서

BMT를 진행함. 일부 BMT는 클루닉스에서 구축, 관리 중인 타 기관의 대규모 HPC 시스

템에서 일부 테스트를 진행함. 타 기관 HPC 장비의 규모는 1360 core(170 nodes)이다.

- S/W 구성 정보

S/W 명 S/W 버전

운영체제 Redhat Eenterprise Server(x86_64) V4-update5

HPC 구축 S/W GridCenter 1.9

HPC 운영 S/W GridCenter-HPC, 1.9

HPC 최적화 S/W GridCEnter-CAP 1.9

Compiler Intel Compiler / PGI Compiler Intel v9-10, PGI 6.2

MPI S/W MPICH 1.2.6

BMT S/W NetCDF, WRF NetCDF v3-4, WRF v2-3

본 BMT에 사용된 HPC 환경 구축 및 해석 작업 실행과 성능 최적화 프로그램으로는 ㈜

클루닉스에서 개발한 GridCenter 제품군을 사용하였고, WRF 대기 모델의 Build에 사

용된 Compiler는 Intel compiler v9 와 v10, 그리고 PGI compiler v6.2를 이용하여

Build 하였다. 실제 해석에 이용된 WRF version은 v2 와 v3를 모두 이용하여 BMT를

진행하였다. WRF에 이용되는 병렬 분산 I/O 관련 라이브러리인 NETCDF는 v3과 v4를

모두 사용하여 구성하였다

4/19 페이지

2. BMT 주요 시나리오

본 BMT 진행 주요 절차는 아래와 같다.

BMT는 우선적으로 BMT 환경 구축 후 네트워크 환경, Compiler 종류, Compiler 별 최적

화 옵션, WRF, NETCDF 버전 별 성능 차이를 비교 분석하여, 최적의 환경을 파악하는 단

위 테스트를 먼저 시행한다. 그런 후 최적의 조건으로 구성된 WRF 해석 환경에서, WRF

의 최적화 조건을 HPC 시스템에 적용하고, 전반적인 성능 테스트를 진행한다.

본 테스트에서 수행할 성능 테스트는 지역 규모에 대한 대기 해석 모델인 WRF를 병렬

처리 클러스터 시스템에서 수행하여 그 성능 개선 효과를 측정하고, 해석 모델의 크기

에 따른 가장 효율적인 시스템 규모를 분석하는 형태로 이루어 진다.

구체적인 BMT 항목은 아래와 같다.

- WRF + NetCDF + Compiler 버전 별 성능 비교 분석

- Compiler 최적 옵션 적용에 따른 성능 비교 분석

- 클러스터 네트워크 구성 환경에 따른 성능 비교 분석

- 해석 크기에 따른 병렬 계산 처리 효과 분석

- Processor 스케줄링 방식에 따른 성능 비교 분석

5/19 페이지

3. BMT 항목 별 결과 및 분석

- WRF, NetCDF, Compiler 버전 별 성능 비교 분석

본 테스트 결과는 WRF 해석 환경을 구성하기 위해서는 먼저 WRF 설치 시 이용되는

NetCDF 라이브러리를 설치 해야 한다. WRF 와 NetCDF의 설치에 이용되는 Compiler 종류

에 따라 어떤 성능 차이가 존재하는지를 분석한 결과이다.

아래 테스트는 WRF 설치하면, 기본 제공하는 가상 Sample 예제인 em_b_wave를 1대 서버

의 단일 CPU에서 해석하고, 그 결과를 비교 분석하였다.

(W:WRF, N:NetCDF, P:PGI, I:Intel)

구성 W2+N3+P6 W2+N3+I9 W3+N4+I10 W3+N4+P7

Elapsed Time 9분12초 9분20초 8분40초 8분59초

WRF 구성 S/W 환경별 성능 비교 분석

500

510

520

530

540

550

560

570

W2+N3+P6 W2+N3+I9 W3+N4+I10 W3+N4+P7

WRF 구성 환경

Elapsed T

ime (sec)

Elapsed Time(s)

본 테스트 결과 Intel Compiler v10으로 NetCDF 4.0 과 WRF 3.0.1 버전을 Compile 해서

구성한 WRF 해석 환경이 가장 우수한 성능을 나타내는 걸로 확인되었다.

본 테스트는 가장 다양한 WRF 해석 환경 구성 방법으로 구현된 환경에서 최소 해석 단

위의 예제를 수행함으로 S/W 버전 조합 별로 어떤 조합의 단위 성능이 우수한 지를 분

석한 결과이다.

6/19 페이지

- Compiler 최적화 옵션에 따른 성능 비교 분석

WRF 해석 모델의 배포는 Source 형태로 배포되므로, 해석 시스템 구축 시 해당 시스템

환경에 따라 최적화 구현이 가능하다.

본 테스트 결과는 현재 구성된 WRF 해석 시스템 환경에 맞게 Compiler의 최적화 옵션을

적용하여 WRF를 환경을 구축할 경우 기본 환경과의 성능 차이를 비교 분석한 것이다.

기본 옵션은 WRF 설치 시 자동 생성되는 configure.wrf 파일의 옵션을 그대로 사용한

것이다. 최적화 옵션은 각 Compiler 에서 제공하는 다양한 최적화 옵션을 현 시스템에

맞게 반영한 것이다.

(W:WRF, N:NetCDF, P:PGI, I:Intel)

구성 W2+N3+P6 W2+N3+I9 W3+N4+I10 W3+N4+P7

Tuning 전 9분12초 9분20초 8분40초 8분59초

Tuning 후 8분39초 9분 1초 8분23초 8분50초

Compile Option 최적화를 통한 성능 비교 분석

470

480

490

500

510

520

530

540

550

560

570

W2+N3+P6 W2+N3+I9 W3+N4+I10 W3+N4+P7

WRF 구성 환경

Elapsed T

ime (sec)

Tuning 전

Tuning 후

본 테스트 결과 Compiler 최적 Option 적용 시 가장 좋은 성능을 나타내는 환경은 위

테스트와 동일한 최신 Intel Compiler 환경에서의 최신 WRF, NetCDF 환경이였다.

단 Tuning 전/후의 성능 개선 효과가 가장 크게 일어난 것은 WRF2.1+NetCDF3.6+PGI6.2

환경으로 측정되었다.

WRF와 MM5와 같은 기상 관련 모델은 초창기 개발 단계에서 PGI Compiler에 최적화 되어

배포되었다. 리눅스 운영체제를 이용한 HPC 환경 구축 시 2000년~2005년 시점의 기상

모델의 최적 시스템 환경은 AMD 계열의 Opteron 시스템과 PGI Compiler를 이용하여 구

7/19 페이지

축하는 것이 가장 좋은 성능이 나타났다. 하지만 2~3년전부터 Intel CPU의 Floating

Point 연산 성능이 획기적으로 개선되었고, 대부분의 범용 해석 프로그램의 해석 성능

이 AMD 계열의 CPU보다 Intel 계열의 CPU가 더 우수하게 측정되어 왔다. 본 테스트에

사용된 시스템 역시 Intel Xeon 계열의 최신 프로세서로 Intel Compiler에서 제공되는

프로세서 최적화 기능을 이용할 때 최고의 성능이 나타나는 것을 확인하였다. Intel

CPU 계열의 시스템 환경에서 PGI의 프로세서 최적화 효과는 상대적으로 낮게 평가 되었

다. WRF2.1과 PGI6.2에서의 Tuning 전후 성능 차이가 크게 나는 것은 WRF2.1+PGI조합에

서 생성된 configure.wrf의 compile 옵션은 아무런 최적화가 포함되지 않은 상태였기에,

보다 큰 성능 개선이 일어난 것으로 판단된다.

본 테스트를 통해 WRF2.x 대를 사용할 경우에는 PGI Compiler를 이용하고, WRF3.x를 사

용할 경우에는 Intel Compiler를 이용하는 것이 효율적이라 판단된다.

- 클러스터 네트워크 구성 환경에 따른 성능 비교 분석

본 테스트 결과는 WRF 병렬 처리 해석 시 중요한 성능 요소인 네트워크 환경에 따른 성

능 비교 분석 결과이다. 여러 대의 분산 시스템을 하나의 클러스터로 구성하여 HPC 시

스템을 구성할 때 구성 시스템의 규모에 따라 요구되는 네트워크 환경이 달라지게 된다.

도입 비용 대비 성능 측면에서 고려했을 때, 작은 규모의 HPC 시스템에서는 계산 시 서

로 통신을 해야 Processor의 수가 상대적으로 작으므로, 고가의 네트워크 장비를 굳이

필요로 하지 않게 된다. 하지만 HPC의 규모가 점점 커지면서, 구성 Processor 수가 많

아 지게 되면, 근래 일반적으로 사용하는 Gigabit 환경으로는 성능이 보장되지 않는다.

WRF를 제외한 일반적인 범용 해석 프로그램으로 테스트 한 경우 병렬 계산 효과가 좋은

프로그램이더라도 해석에 이용된 프로세서 수가 40~50 core 이상 되면, Gigabit 환경에

서는 성능이 더 이상 증가하지 않는다. (오히려 16core, 32core 때 성능 보다 더 떨어

지는 경우도 많음)

본 테스트에서는 WRF에 대한 네트워크 의존성과 프로세서 수에 따른 최적 네트워크 환

경을 선별하기 위한 테스트이다.

본 테스트는 1개 Gigabit port를 이용한 일반 구성과 2개 Gigabit port를 Network

channel bonding으로 대역폭을 Tuning하여 최적화한 환경을 비교 분석한 것이다.

본 테스트에 사용된 예제는 http://www.mmm.ucar.edu/WG2bench 사이트에서 배포하는

WRF Benchmark Model을 이용하였다. 사용된 해석 모델은 IVAN 예제이고, 주요 해석 조

건은 아래와 같다.

해석 조건 해석 조건 값 조건 설명 조건 값 의미

8/19 페이지

run_days 5 해석 범위 5일

history_interval 1440 해석 결과 저장 주기 1일

time_step 72 적분 간격 72초

dx 12000 격자 크기 12km

테스트 결과는 아래와 같다.

네트워크환경 Core=1 Core=32 Core=64 Core=128

Gigabit 123시간59분16초 22시간55분12초 23시간38분17초 25시간58분51초

Gigabitx2

(bonding) 123시간59분16초 13시간19분43초 10시간23분11초 10시간45분9초

네트워크 환경 별 WRF 해석 성능 비교

0

20

40

60

80

100

120

140

1 8 16 32 64 128

core 수

Elapsed T

ime(시

간

Gigabit

Gigabitx2

본 결과를 분석하면 WRF의 경우 병렬 해석 성능에서 네트워크 성능이 매우 큰 영향을

주는 것으로 나타났다. 본 테스트의 결과를 보면, 32core ( 4대 계산 서버)를 이용하여

계산을 수행할 경우 일반 Gigabit 환경에서는 23시간 정도 소요되는 반면, 최적화된

Gigabit 환경에서는 13시간대에 해석이 완료되는 것을 확인하였다. 이는 Gigabit 대역

을 2배로 확장하여 1.7배 정도의 성능 개선이 이룬 결과이다. 계산 서버의 수가 8대,

16대로 늘어날 경우 일반 Gigabit 환경에서는 4대의 서버로 계산한 성능 보다 더 떨어

지는 성능 결과를 나타냈고, 최적화된 Gigabit 환경에서는 8대 서버까지 성능 개선이

있는 것을 확인하였다. 16대 (128core)를 이용한 해석의 경우 최적화된 gigabit 환경에

서도 8대(64core)에서의 해석 성능보다 저하되는 증세가 나타났다.

본 테스트 결론은 WRF 클러스터 해석 환경을 Gigabit 네트워크를 통해 구축할 경우 네

9/19 페이지

트워크 최적화에 따른 성능 개선 효과는 매우 크며, 적절한 최적화가 이루어진 경우,

해석 작업이 1개당 32core~64core 규모를 이용하는 것이 가장 이상적이라 판단된다.

- 해석 크기에 따른 병렬 계산 처리 효과 분석

본 테스트는 WRF 해석 예제의 크기에 따라 병렬 계산 효과의 차이를 비교한 테스트이다.

일반적인 범용 해석 프로그램의 경우 작은 크기의 예제에서 무조건 많은 프로세서를 이

용하더라도 성능의 개선이 보장되지 않는 경우가 대부분이다. 병렬 계산 효과가 좋은

해석 프로그램의 경우 해석 규모가 크면 클수록 병렬 처리 효과는 커지는 것이 일반적

인 사례다. 본 테스트에선 WRF의 경우를 확인해 보고자 한다.

본 테스트에 사용된 예제는 http://www.mmm.ucar.edu/WG2bench 사이트에서 배포하는 두

가지 예제로 작은 규모의 예제는 conus12km 예제를, 큰 규모의 예제는 상위 테스트에서

사용된 ivan 예제를 이용하였다.

예제 Run_hours History_interval Time_step Time_step

Conus12km(small) 3 180 72 12000

Ivan(big) 120 1440 72 12000

Conus12km 예제 해석 결과

Core=1 Core=8 Core=16 Core=32

Elapsed(min) 41.1 15 8.5 5

Speedup 1 2.7 4.8 8.2

WRF 소형 모델의 병렬 해석 성능 분석

0

5

10

15

20

25

30

35

40

45

1 8 16 32

Number of Cores

Ela

psed

Tim

e (m

in

0

1

2

3

4

5

6

7

8

9

Elapsed(min)Speedup

10/19 페이지

작은 규모의 예제의 경우 32core 해석 시 단일 코어 대비 최대 8.2배의 해석 성능 개선

이 이루어 지는 것이 확인 되었다. 아래는 본 예제에 비교했을 때 매우 큰 해석 모델에

대한 결과이다.

IVAN 예제 해석 결과

Core=1 Core=8 Core=16 Core=32

Elapsed(hour) 123.9 42.5 23.9 13.2

speedup 1 2.9 5.1 9.4

WRF 대형 모델의 병렬 해석 성능 분석

0

20

40

60

80

100

120

140

1 8 16 32

number of cores

elap

sed

time(

hour

s)

0

1

2

3

4

5

6

7

8

9

10

Elapsed(hour)speedup

큰 크기의 WRF 예제의 경우 32core 해석 시 단일 코어 대비 최대 9.4배의 성능 개선

이 이루어 지는 것을 확인 하였다.

- Processor 스케줄링 방식에 따른 성능 비교 분석

본 테스트는 WRF 병렬 해석 시 계산 서버 당 몇 개의 core를 할당하는 것이 가장 효율

적인지를 선별하기 위한 테스트이다. 본 테스트는 상위 테스트에서 사용된 ivan 예제를

이용하여 테스트하였고, 첫 번째 테스트로 1대 서버로 8core를 구성한 경우와 2대 서버

를 이용하여 8core를 구성한 경우를 비교 분석 하였다.

4core x 2nodes 8core x 1nodes

Elapsed Time(hour) 25.9 42.5

11/19 페이지

서버당 Core 배열별 WRF 성능 비교 분석

0

5

10

15

20

25

30

35

40

45

4core x 2nodes 8core x 1nodes

서버당 코어 배열

Elapsed T

ime (hour

Elapsed Time(hour)

본 테스트 결과 WRF의 경우 서버당 4core 구성의 병렬 계산 방식이 서버 당 8core 구성

의 계산 보다 1.6배 더 우수한 성능을 나타내는 것을 확인하였다.

이런 형태의 해석 프로그램의 경우 도입된 시스템을 효율적으로 운영하기 위해 다양한

주변 환경의 변수가 존재하는데, 그 중 가장 큰 변수는 해석 프로그램의 라이센스 비용

이 해당된다. 대부분의 상용 해석 프로그램의 경우 core 기준으로 매우 고가의 라이센

스 비용을 지불하게 되는데, 이 때 이 라이센스 비용과 도입되는 하드웨어 비용을 성능

기준으로 효율성을 찾게 된다면, 서버당 4core 구성으로 해석을 하는 것이 효율적이라

볼 수 있다. 하지만 WRF의 경우 별도의 라이센스 비용이 없기 때문에 4core를 사용하는

것 보다 8core를 사용하는 것이 절대적 성능에서 조금이라도 우수하다면, 8core를 이용

하는 것이 최선일 것이다.

본 테스트 범위를 조금 더 확장하여, 정해진 시간 내에 4core x 2nodes 환경과 8core x

1node 환경에서의 작업 처리량을 비교해 보았다. 즉 서버당 8core를 보유한 2대의 계산

서버를 통해 8core짜리 작업 2개를 동시에 수행할 경우 (4core x 2nodes) x 2job 환경

과 (8core + 1node) x 2job 환경의 작업 처리량을 비교하였다. 결과는 아래와 같다.

4core x 2nodes) x 2job (8core + 1node) x 2job

Elapsed Time(hour) 40.2 42.5

12/19 페이지

WRF 작업 처리량 비교 분석

39

39.5

40

40.5

41

41.5

42

42.5

43

4core x 2nodes) x 2job (8core + 1node) x 2job

작업 형태

Elapsed T

ime (hour)

Elapsed Time(hour)

테스트 결과 WRF의 경우 4core x 2nodes의 작업 효율이 매우 우수하여 8core 짜리 2개

작업을 동시에 제출할 경우, 8core 짜리 작업 1개를 서버에 각각 독립적으로 수행하는

것 보다, 서버 2대를 이용하여 4core x 2nodes 형태로 8core를 구성하여, 2개 작업을

수행하는 것이 6%더 성능이 우수한 걸로 측정되었다.

4. BMT 결론

본 테스트를 통해 WRF 해석을 여러 대의 분산 클러스터 시스템에서 가장 이상적으로 구

성하기 위해서는 해석에 이용될 WRF 모델 자체의 최적화와 네트워크 환경의 최적화, 그

리고 WRF 작업 시 해석 규모에 따른 적절한 core 수와 병렬 해석 시 서버당 이용되는

프로세서의 수를 적절하게 조합할 경우 최적의 성능과 효율을 보장하는 걸로 확인 되었

다. 이 중 가장 큰 성능 결정 요소는 네트워크 환경으로 측정되었다. 본 테스트에서

아쉬운 것은 Infiniband 고속 네트워크 환경을 준비하지 못해 네트워크 구성 별 테스트

에서 Infiniband 환경에서의 해석 성능 결과를 측정하지 못한 것 이다. 본 테스트 중

Gigabit 최적화 환경에서 IVAN(큰 모델) 예제 해석 시 32core를 이용할 경우 core당

CPU 점유률은 40~50% 정도 사용되었다. 일반 Gigabit 환경에서는 20~30% 정도의 CPU 점

유가 일어났다. 만일 Infiniband와 같은 고속 네트워크 환경이라면 32core 해석 시 90%

이상의 프로세서 계산 효율이 예상되며, 그럴 경우 매우 뛰어난 성능이 보장되리라 판

단되어진다. 또한 본 테스트에서는 64개 이상의 core를 사용할 경우 해석 속도가 더 저

하되는 증세가 나타나는데, Infiniband로 구성할 경우 해석 예제 크기가 크면, 512core

이상에서도 충분히 성능 개선이 가능하리라 여겨 진다.

13/19 페이지

첨부 : GridCenter-HPC를 통한 WRF 해석 주요 화면 자료

아래는 본 보고서의 WRF 벤치마크 테스트 시 이용된 GridCenter-HPC의 자료 화면이다.

GridCenter에서 제공하는 WRF에 최적화된 네트워크 구성 기능과 프로세서 할당 기능들을 이

용하여 WRF 성능을 최적화하는데 사용되었고, BMT 시 반복적인 해석 작업을 모두 웹에서 편

리하게 일괄 제출하면, GridCenter-HPC 내의 스케줄러가 자동으로 제출된 작업을 처리해 주

는 역할을 하였다.

- WRF 해석 중인 GridCenter-HPC 로그인 화면

GridCenter-HPC 웹 사용 환경으로 접속하면, 현재 스케줄러에 등록되어 동작 중이 WRF 작업

정보들이 모니터링 되어 진다.

14/19 페이지

- WRF 해석 시 HPC 시스템 전체 자원 현황 모니터링 화면

여러대의 분산된 클러스터 시스템의 다양한 자원 현황을 통합 모니터링하고, 누적된 자원의

이용률을 누적하여 기록함으로, 도입된 시스템의 효율적인 자원 운영을 가능케 하는 기능이

다. 또한 해석 시 해석 별 자원 활용 현황을 분석하여, 다양한 Tuning의 근거 자료로 활용

되어 진다.

15/19 페이지

- WRF 해석 시 wrf.exe 프로세서와 메모리 점유율 모니터링 화면

여러 대의 분산된 클러스터 서버에서 WRF 병렬 계산 시 wrf.exe 프로세서만으로 통합 모니

터링함으로 보다 편하게 프로세서 현황을 감시, 제어할 수 있다.

16/19 페이지

- GridCenter-HPC 에서 WRF 해석 작업 제출 화면

GridCenter-HPC를 통해 WRF 해석 시 해석 작업 제출을 터미널에서 command 방식으로 제출하

지 않고, 웹에서 직접 제출함으로, 복잡한 HPC 운영 방법을 모르는 사용자라도 손 쉽게 해

석 작업을 진행할 수 있다.

17/19 페이지

- WRF 해석 작업 모니터링 화면

여러 명의 연구원이 중앙의 HPC (통합해석)시스템을 공유하여 사용할 경우, 동시에 요청되

는 작업을 현재 보유하고 있는 자원에 맞게 적절하게 스케줄링 해야 하고, 사용자 별 할당

된 작업의 상태를 손 쉽게 모니터링 할 필요가 있다. GridCenter-HPC의 경우 이 모드 기능

이 웹에서 수행 되어진다.

위 모니터링 화면에서 해당 작업명을 클릭하면, 해당 작업 실행 세부 정보 및 wrf 해석 시

해석 진행 상항을 기록되는 rsl.error0000 로그 파일의 내용을 웹에서 실시간 모니터링이

가능하다. 아래는 해당 기능의 자료 화면이다.

18/19 페이지

- WRF 해석 작업 세부 정보 및 작업 로그 모니터링 화면

19/19 페이지

- 기간 별 WRF 해석 작업 검색 및 작업 결과 데이터 관리 화면

GridCenter-HPC에서 제출된 모든 작업 정보와 작업 결과 데이터 정보는 DB상에 저장됨으로,

과거 수행된 작업 결과를 기간별 검색 및 해석 작업 명 검색 등으로 해석 결과에 대해 손

쉽게 관리가 가능하다.