Microsoft Word - WRF_BMT보고서.doc

Size: px

Start display at page:

Download "Microsoft Word - WRF_BMT보고서.doc"

은우 반
4 years ago
Views:

1 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 어플리케이션구축및튜닝 : 클루닉스기술부 / 수석컨설턴트서진우 1/19 페이지

2 목차 1. BMT 환경정보 2. BMT 주요시나리오소개 3. BMT 항목별결과및분석 4. BMT 결론 첨부 : GridCenter-HPC 를통한 WRF 해석주요화면자료 2/19 페이지

3 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 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를모두사용하여구성하였다 3/19 페이지

4 2. BMT 주요시나리오 본 BMT 진행주요절차는아래와같다. BMT는우선적으로 BMT 환경구축후네트워크환경, Compiler 종류, Compiler 별최적화옵션, WRF, NETCDF 버전별성능차이를비교분석하여, 최적의환경을파악하는단위테스트를먼저시행한다. 그런후최적의조건으로구성된 WRF 해석환경에서, WRF 의최적화조건을 HPC 시스템에적용하고, 전반적인성능테스트를진행한다. 본테스트에서수행할성능테스트는지역규모에대한대기해석모델인 WRF를병렬처리클러스터시스템에서수행하여그성능개선효과를측정하고, 해석모델의크기에따른가장효율적인시스템규모를분석하는형태로이루어진다. 구체적인 BMT 항목은아래와같다. - WRF + NetCDF + Compiler 버전별성능비교분석 - Compiler 최적옵션적용에따른성능비교분석 - 클러스터네트워크구성환경에따른성능비교분석 - 해석크기에따른병렬계산처리효과분석 - Processor 스케줄링방식에따른성능비교분석 4/19 페이지

5 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 환경별성능비교분석 Elapsed Time (sec) Elapsed Time(s) W2+N3+P6 W2+N3+I9 W3+N4+I10 W3+N4+P7 WRF 구성환경 본테스트결과 Intel Compiler v10으로 NetCDF 4.0 과 WRF 버전을 Compile 해서구성한 WRF 해석환경이가장우수한성능을나타내는걸로확인되었다. 본테스트는가장다양한 WRF 해석환경구성방법으로구현된환경에서최소해석단위의예제를수행함으로 S/W 버전조합별로어떤조합의단위성능이우수한지를분석한결과이다. 5/19 페이지

6 - 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 최적화를통한성능비교분석 Elapsed Time (sec) Tuning 전 Tuning 후 470 W2+N3+P6 W2+N3+I9 W3+N4+I10 W3+N4+P7 WRF 구성환경 본테스트결과 Compiler 최적 Option 적용시가장좋은성능을나타내는환경은위테스트와동일한최신 Intel Compiler 환경에서의최신 WRF, NetCDF 환경이였다. 단 Tuning 전 / 후의성능개선효과가가장크게일어난것은 WRF2.1+NetCDF3.6+PGI6.2 환경으로측정되었다. WRF와 MM5와같은기상관련모델은초창기개발단계에서 PGI Compiler에최적화되어배포되었다. 리눅스운영체제를이용한 HPC 환경구축시 2000년 ~2005년시점의기상모델의최적시스템환경은 AMD 계열의 Opteron 시스템과 PGI Compiler를이용하여구 6/19 페이지

7 축하는것이가장좋은성능이나타났다. 하지만 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하여최적화한환경을비교분석한것이다. 본테스트에사용된예제는 사이트에서배포하는 WRF Benchmark Model을이용하였다. 사용된해석모델은 IVAN 예제이고, 주요해석조건은아래와같다. 해석조건해석조건값조건설명조건값의미 7/19 페이지

8 run_days 5 해석범위 5일 history_interval 1440 해석결과저장주기 1일 time_step 72 적분간격 72초 dx 격자크기 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 해석성능비교 Elapsed Time( 시간 Gigabit Gigabitx core 수 본결과를분석하면 WRF의경우병렬해석성능에서네트워크성능이매우큰영향을주는것으로나타났다. 본테스트의결과를보면, 32core ( 4대계산서버 ) 를이용하여계산을수행할경우일반 Gigabit 환경에서는 23시간정도소요되는반면, 최적화된 Gigabit 환경에서는 13시간대에해석이완료되는것을확인하였다. 이는 Gigabit 대역을 2배로확장하여 1.7배정도의성능개선이이룬결과이다. 계산서버의수가 8대, 16대로늘어날경우일반 Gigabit 환경에서는 4대의서버로계산한성능보다더떨어지는성능결과를나타냈고, 최적화된 Gigabit 환경에서는 8대서버까지성능개선이있는것을확인하였다. 16대 (128core) 를이용한해석의경우최적화된 gigabit 환경에서도 8대 (64core) 에서의해석성능보다저하되는증세가나타났다. 본테스트결론은 WRF 클러스터해석환경을 Gigabit 네트워크를통해구축할경우네 8/19 페이지

9 트워크최적화에따른성능개선효과는매우크며, 적절한최적화가이루어진경우, 해석작업이 1개당 32core~64core 규모를이용하는것이가장이상적이라판단된다. - 해석크기에따른병렬계산처리효과분석 본테스트는 WRF 해석예제의크기에따라병렬계산효과의차이를비교한테스트이다. 일반적인범용해석프로그램의경우작은크기의예제에서무조건많은프로세서를이용하더라도성능의개선이보장되지않는경우가대부분이다. 병렬계산효과가좋은해석프로그램의경우해석규모가크면클수록병렬처리효과는커지는것이일반적인사례다. 본테스트에선 WRF의경우를확인해보고자한다. 본테스트에사용된예제는 사이트에서배포하는두가지예제로작은규모의예제는 conus12km 예제를, 큰규모의예제는상위테스트에서사용된 ivan 예제를이용하였다. 예제 Run_hours History_interval Time_step Time_step Conus12km(small) Ivan(big) Conus12km 예제해석결과 Core=1 Core=8 Core=16 Core=32 Elapsed(min) Speedup WRF 소형모델의병렬해석성능분석 Elapsed Time (min Elapsed(min) Speedup Number of Cores 0 9/19 페이지

10 작은규모의예제의경우 32core 해석시단일코어대비최대 8.2배의해석성능개선이이루어지는것이확인되었다. 아래는본예제에비교했을때매우큰해석모델에대한결과이다. IVAN 예제해석결과 Core=1 Core=8 Core=16 Core=32 Elapsed(hour) speedup WRF 대형모델의병렬해석성능분석 elapsed time(hours) Elapsed(hour) speedup number of cores 0 큰크기의 WRF 예제의경우 32core 해석시단일코어대비최대 9.4배의성능개선이이루어지는것을확인하였다. - Processor 스케줄링방식에따른성능비교분석 본테스트는 WRF 병렬해석시계산서버당몇개의 core를할당하는것이가장효율적인지를선별하기위한테스트이다. 본테스트는상위테스트에서사용된 ivan 예제를이용하여테스트하였고, 첫번째테스트로 1대서버로 8core를구성한경우와 2대서버를이용하여 8core를구성한경우를비교분석하였다. 4core x 2nodes 8core x 1nodes Elapsed Time(hour) /19 페이지

11 서버당 Core 배열별 WRF 성능비교분석 Elapsed Time (hour Elapsed Time(hour) 0 4core x 2nodes 서버당코어배열 8core x 1nodes 본테스트결과 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) /19 페이지

12 WRF 작업처리량비교분석 Elapsed Time (hour) Elapsed Time(hour) 39 4core x 2nodes) x 2job 작업형태 (8core + 1node) x 2job 테스트결과 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 이상에서도충분히성능개선이가능하리라여겨진다. 12/19 페이지

13 첨부 : GridCenter-HPC 를통한 WRF 해석주요화면자료 아래는본보고서의 WRF 벤치마크테스트시이용된 GridCenter-HPC의자료화면이다. GridCenter에서제공하는 WRF에최적화된네트워크구성기능과프로세서할당기능들을이용하여 WRF 성능을최적화하는데사용되었고, BMT 시반복적인해석작업을모두웹에서편리하게일괄제출하면, GridCenter-HPC 내의스케줄러가자동으로제출된작업을처리해주는역할을하였다. - WRF 해석중인 GridCenter-HPC 로그인화면 GridCenter-HPC 웹사용환경으로접속하면, 현재스케줄러에등록되어동작중이 WRF 작업정보들이모니터링되어진다. 13/19 페이지

14 - WRF 해석시 HPC 시스템전체자원현황모니터링화면 여러대의분산된클러스터시스템의다양한자원현황을통합모니터링하고, 누적된자원의이용률을누적하여기록함으로, 도입된시스템의효율적인자원운영을가능케하는기능이다. 또한해석시해석별자원활용현황을분석하여, 다양한 Tuning의근거자료로활용되어진다. 14/19 페이지

15 - WRF 해석시 wrf.exe 프로세서와메모리점유율모니터링화면 여러대의분산된클러스터서버에서 WRF 병렬계산시 wrf.exe 프로세서만으로통합모니터링함으로보다편하게프로세서현황을감시, 제어할수있다. 15/19 페이지

16 - GridCenter-HPC 에서 WRF 해석작업제출화면 GridCenter-HPC를통해 WRF 해석시해석작업제출을터미널에서 command 방식으로제출하지않고, 웹에서직접제출함으로, 복잡한 HPC 운영방법을모르는사용자라도손쉽게해석작업을진행할수있다. 16/19 페이지

17 - WRF 해석작업모니터링화면 여러명의연구원이중앙의 HPC ( 통합해석 ) 시스템을공유하여사용할경우, 동시에요청되는작업을현재보유하고있는자원에맞게적절하게스케줄링해야하고, 사용자별할당된작업의상태를손쉽게모니터링할필요가있다. GridCenter-HPC의경우이모드기능이웹에서수행되어진다. 위모니터링화면에서해당작업명을클릭하면, 해당작업실행세부정보및 wrf 해석시해석진행상항을기록되는 rsl.error0000 로그파일의내용을웹에서실시간모니터링이가능하다. 아래는해당기능의자료화면이다. 17/19 페이지

18 - WRF 해석작업세부정보및작업로그모니터링화면 18/19 페이지

19 - 기간별 WRF 해석작업검색및작업결과데이터관리화면 GridCenter-HPC에서제출된모든작업정보와작업결과데이터정보는 DB상에저장됨으로, 과거수행된작업결과를기간별검색및해석작업명검색등으로해석결과에대해손쉽게관리가가능하다. 19/19 페이지

<4D F736F F D20C5EBC7D5C7D8BCAEBDC3BDBAC5DB5F D2BC0C720424D54B0E1B0FABAB8B0EDBCAD2E646F63>

<4D F736F F D20C5EBC7D5C7D8BCAEBDC3BDBAC5DB5F D2BC0C720424D54B0E1B0FABAB8B0EDBCAD2E646F63> 통합해석시스템기반 STARCCM+ 의병렬계산성능 BMT 결과보고서 클루닉스 본자료는 클루닉스에서 CAE 해석 S/W(STARCCM+) 의병렬처리성능을측정한 BMT 결과보고서입니다. BMT 환경 : GridCenter-CAP, GridCenter-HPC BMT S/W : STARCCM+ BMT 진행 : 클루닉스 BMT 일자 : 2009년 08월 12일 ~2009년