Microsoft Word - KR-KISTI-HEP_구축_v0.6.doc

Transcription

1 ISBN CDF Analysis Farm 구축보고서 정민호, 김현우, 조기현 High Energy Physics Group

2 머리말 본구축보고서는 CDF Analysis Farm 을 KISTI 내에설치하는과정에서습득한경험을향후 e-science 인프라를구축하고관리, 활용하는데참고할수있게하기위해작성되었습니다. 본구축보고서의작성에도움을주신모든분들께감사드립니다 년 11 월 15 일 작성자 : 정민호 (KISTI) 김현우 (KISTI) 조기현 (KISTI) i

3 목차 Ⅰ. 개요 고에너지물리와 E-SCIENCE 연구환경 고에너지물리 미국페르미연구소 CDF 실험 고에너지물리 E-SCIENCE 의구성요소 데이터생산 데이터처리 데이터출판 구축시스템사양...3 Ⅱ. 사이트등록 사이트등록절차 GOCDB(GRID OPERATIONS CENTRE DATABASE) 정보등록...4 Ⅲ. CE(COMPUTING ELEMENT), WN(WORKER NODE) 설치 WN(WORKER NODE) 설치 운영체제설치 NTP(Network Time Protocol) 설정 YUM update JAVA 설치 lcg-ca 설치 glite-wn 와 glite-torque_client 설치 기타설정파일들 워커노드설치시발생했던문제들 추가설치가필요한패키지 CE (COMPUTING ELEMENT) 설치 YUM update Host Certificate 설치 기타설정파일들 site_info.def 파일설정...18 Ⅳ. 결과...19 참고자료...20 부록...21 ii

4 Ⅰ. 개요 1. 고에너지물리와 e-science 연구환경물질이무엇으로이루어졌고어떤상호작용을하고있는지연구하는학문인고에너지물리연구는대규모가속기와검출기를필요로하며, 연구과정에서 Pbyte 급의대용량데이터가생산된다. 그러므로이를처리하기위한고에너지물리 e-science 연구환경은데이터센터를구축하여, 데이터가생산되는외국의가속기연구소에가지않더라도시간과장소에상관없이고에너지물리연구를실제가속기연구소와동일한연구환경에서할수있게해준다. 그구성요소로서데이터생산, 데이터처리, 데이터출판이있다. 데이터생산은원격제어시스템을활용하여원격으로데이터생산에참여하는것이며, 데이터처리는그리드팜을활용하여 job 을수행하는것이며, 데이터출판은 EVO(Enabling Virtual Organization) 시스템을활용하여연구자들이공동협업환경을이용하여그결과물을출판하는것이다. 이러한개념을미국페르미연구소에 CDF 실험에구현하여연구에활용한것이대표적인사례이다. 2. 고에너지물리물질의근본구성입자를연구하기위해서는관찰할소스 (source) 와검출기가필요하다. 소스와검출기는관찰하고자하는대상에따라다르게되는데, 예를들어은하를관찰하기위해서는전파망원경이필요하며, 세포를관찰하기위해서는현미경이필요하듯이핵속에있는기본입자를관찰하려면가속기와대규모의검출기가필요하다. 특히, 고에너지가속기가필요한이유는드브로이의물질파이론에의하여, 고에너지는작은입자를관찰할수있는작은파장을만들수있기때문이다. 그리고아인슈타인의상대성원리에의하여질량과에너지는같으므로고에너지는질량이큰입자를만들수있다. 따라서, 고에너지물리학분야는고에너지가속기를이용하여우주의초기단계를만들어우주의생성및진화에관한학문을연구하는기초과학이다. 고에너지물리실험은검출기의설계, 제작, 신호처리및자료수집, 분석에이르기까지의일련의작업을가속기가있는연구소에서국제공동연구로수행한다. 참여인원은적게는 100 여명, 많게는전세계에분산된 2000 여명이동시에자료를처리한다. 3. 미국페르미연구소 CDF 실험미국페르미연구소 CDF 실험은미국, 이탈리아, 일본, 영국, 독일, 대만, 한국등 13 개국의 620 여명의물리학자들이참여하는대규모의국제적인가속기실험이다. 그목적은각각 1 TeV 의에너지로가속시킨양성자와반양성자들을정면충돌시켜새로운입자와물리현상을탐구하는것이다. 실험은 2001 년부터시작되어 2009 년까지수행될예정이다. 충돌횟수는 1 초에 760 만 1

5 번이고매초입자검출기에기록된데이터의크기는 25~40 Mbytes 에달한다. 현재까지 RunⅡ에서모은데이터양은 4fb-1 이며, 이것은 6.0*10 9 사건수에해당하며, 수 Pbyte 의데이터를생산하였다. 이러한방대한데이터를처리하고분석하기위해서는대용량의저장장치및계산장치와네트워크환경이구축되어야하고데이터그리드가있어야이러한데이터를처리할수있다. CDF 실험의컴퓨팅모델은 CAF (CDF Analysis Farm) 의구성에두고있으며, 분산된자원을활용하여자료를처리한다그첫번째단계는 DCAF (Decentralized CDF Analysis Farm) 이며그다음단계는그리드를활용하는것이다. 따라서 2006 년에북미, 유럽, 아시아태평양지역에그리드팜이구축되었다. 아시아태평양지역에서는한국, 일본, 대만의 CDF 연구자들은이지역협력체를구성하여 Pacific CDF Analysis Farm(Pacific CAF) 이라는그리드팜을구축하였고, 이협력체의일환으로 KISTI 에서 KR-KISTI-HEP 이라는 LCG 팜을구축하였다. 4. 고에너지물리 e-science 의구성요소 4.1 데이터생산일반적으로고에너지물리연구는가속기가있는장소에서데이터를획득한다. 그런데 e- Science 의개념을적용하여시간과장소의구애를받지않고데이터를획득하는시스템이필요한데, 그방법은원격제어시스템을이용하는것이다. 그예로서미국페르미연구소에서는유럽입자공동물리연구소 (CERN) 의 LHC(Large Hardron Collider) 실험을위한 ROC(Remote Operation Center) 가있다. 이와유사하게 KISTI 에서 CDF 실험을위한원격제어실을구축하였다. 이원격제어실은국내 CDF 사용자들이미국페르미연구소에상주하지않고도한국 KISTI 에서 CO(Consumer Operator) 근무를할수있다. 4.2 데이터처리 고에너지물리 e-science(e-hep) 의데이터처리를위한주전산자원은네트워크와컴퓨팅이다. 네트워크는교육과학기술부의지원을받아 KISTI 에서운영하는국가 R&D 네트워크 KREONET(Korea Research Environment Open Network) 은 GLORIAD(Global Ring Network for Advanced Applications Development) 망에연결되어있다. GLOARIAD 망은홍콩, 한국, 미국사이에 10Gbps 로연결이가능하다. 또한, 고에너지물리연구를하기위해서는대규모데이터처리가필요하다. 이를위해그리드팜과대용량저장장치를사용한다. 이에사용하는미들웨어로는 LCG(LHC Computing Grid) 팜을운영하고있으며, ALICE 실험과 CDF 실험에서가상기관 (VO;Virtual Organization) 을구축하여활용하고있다. 2

6 4.2 데이터출판협업환경을통하여전세계에있는연구자들의연구결과물을출판하는것으로써, KISTI 는 EVO(Enabling Virtual Organization) 시스템을한국최초로유치하여국내연구자들에게제공하고있다. 이로인해기존의미국에있는서버를이용할때보다지연속도를 60 msec 이상줄여서안정적인협업연구를가능하게하였다. 5. 구축시스템사양 CDF Analysis Farm (KR-KISTI-HEP) 을구축하기위하여 PC 9 대와 4 대의서버를워커노드 용으로사용하였고, 1 대의 PC 를이용하여 CE(Computing Element) 를설치하였다. 따라서총 25 코어프로세스를워커노드용으로설정하였다. PC 사양 서버사양 CPU Intel Pentium(R) 4 CPU 2.66GHz Intel Xeon X GHz Memory 512 Mbytes 8 Gbytes HDD 80 Gbytes 500 Gbytes Core 수 9 Core processes (1 Core * 1) 16 Core processes (4 Core * 4) Table 1. 시스템사양 3

7 Ⅱ. 사이트등록 1. 사이트등록절차 APROC 담당자에게이메일또는사이트등록폼을작성하여발송하여 GOCDB(Grid Operations Centre Database) 에새로운사이트등록을요청한다 년 11 월 15 일현재담당자는 Academy Sinica 의 Shu-Ting Liao 이다. KR-KISTI-HEP 을등록하기위해보낸 site 정보는다음의예와같다. Site name KR-KISTI-HEP Domain name kisti.re.kr Contact address Contact telephone **** CSIRT address CSIRT telephone **** Time zone Etc/GMT+9 Table 2. Site 등록정보 APROC 에서제공하는일반적인등록절차는다음과같다. Figure 1. Site 등록절차흐름도 2. GOCDB(Grid Operations Centre Database) 정보등록 APROC 담당자가새로운사이트를등록후이메일을통해서등록된사이트의 GOCDB 상의 URL 을보내오면해당웹페이지에가서등록된사이트의정보를입력, 수정할수있다. 본사이트의주소는 이며, 등록된사이트는일단 에서상태체크가가능하다. 사이트를구성하는서비스들 (CE, WN 등 ) 을설치한후에 APROC 담당자에게연락하면새로등록된사이트를테스트하고, 테스트상이상이없으면공식사이트로인증을해주게된다. 다음그림은 GOCDB 에등록된사이트의정보를보여주는웹사이트이다.. 4

8 Figure 2. GOCDB 웹사이트 5

9 Ⅲ. CE(Computing Element), WN(Worker Node) 설치 1. WN(Worker Node) 설치 1.1 운영체제설치 본 CDF Analysis Farm 구축에는사용된컴퓨터의운영체제로 Scientific Linux CERN 4.6 (SLC46) 을설치하였다. 1.2 NTP(Network Time Protocol) 설정운영체제설치후시간동기화를위해서다음과같은작업이필요하다. 먼저 NTP(Network Time Protocol) 서버를설치한다. yum install ntp 또는 apt-get install ntp /etc/ntp/step-tickers 파일에 pool.ntp.org 이나해당 IP 를추가한다. /etc/ntp.conf 파일의해당부분을다음과같이수정한다. server pool.ntp.org # Default rule: block unauthorized access restrict default ignore # Allow to access remote ntp server restrict pool.ntp.org nomodify notrap noquery # Allow all from loopback restrict # Standard conf options driftfile /var/lib/ntp/drift broadcastdelay keys /etc/ntp/keys 이후 ntpupdate 명령을통해시간동기화를시킨다. ntpdate pool.ntp.org 실제작업시 server time.kriss.re.kr 를사용하여시간을동기화하였다. 6

10 ~ # --- OUR TIMESERVERS restrict mask nomodify notrap noquery server time.kriss.re.kr ~ 설정후다음작업을통해서설정을확인하였다. # cat /etc/ntp/step-tickers # ntpdate Apr 11:46:41 ntpdate[17170]: the NTP socket is in use, exiting 재부팅시 ntp daemon 이실행될수있도록설정하였다. # chkconfig ntpd on 1.3 YUM update Scientific Linux CERN 4.6 (SLC46) 를설치후 CE, 워커노드를설치하기전에 YUM update 를 실행한다. /etc/yum.repos.d/ 에다음과같은파일을추가하고 yum update 를실행한다. 1 glite.repo [glite-wn] name= glite 3.1 WN baseurl= enabled=1 [glite-torque_client] name=torque clients baseurl= enabled=1 [glite-torque_utils] name=torque utils baseurl= enabled=1 2 lcg-ca.repo [CA] name=cas baseurl= 3 jpackage.repo 7

11 [main] [jpackage17-generic] name=jpackage 1.7, generic baseurl= enabled=1 protect=1 [main] [jpackage5-generic] name=jpackage 5, generic baseurl= enabled=1 protect=1 4 lcg-ca.repo [dries] name=dries rpms baseurl= dries ftp://ftp.scientificlinux.org/linux/extra/dries/redhat/el4/en/$basearch/rpms.dries enabled=1 gpgcheck=0 gpgkey=file:///etc/pki/rpm-gpg/rpm-gpg-key-dries 위의내용은 KISTI 에서개최한 Summer School 에서제시한매뉴얼내용으로 에서확인할수있다. 실제작업에서는 EGEE SEE ROC Wiki 사이트 ( 를참조하여아래와같은파일을추가하고 Yum update 을실행하였다. 1 glite.repo [glite-wn] name=glite 3.1 Worker Node baseurl= enabled=1 [glite-torque_client] name=torque clients baseurl= enabled=1 2 lcg-ca.repo [CA] name=cas baseurl= enabled=1 8

12 3 jpackage5.0.repo [main] [jpackage17-generic] name=jpackage 1.7, generic baseurl= enabled=1 protect=1 [jpackage17-generic-nonfree] name=jpackage 1.7, generic non-free baseurl= enabled=1 protect=1 [main] [jpackage5-generic] name=jpackage 5, generic baseurl= enabled=1 protect=1 [jpackage5-generic-nonfree] name=jpackage 5, generic non-free baseurl= enabled=1 protect=1 1.4 JAVA 설치 JAVA JDK 는 version 1.5 이상 and 1.6 이하를설치한다. Sun site 에서 jdk-version-linux-i586- rpm.bin 다운받아설치후 /etc/profile 에 PATH 를추가하여도되고, EGEE SEE ROC Wiki 사이트에서제공하는매뉴얼에따라다음과같이설치하여도된다. 실제작업에서는 EGEE SEE ROC Wiki 사이트를참조하였다. 사이트에서 rpm 을다운받아설치하거나다음의과정을따라설치한다. rpm --import mkdir -p ~/redhat/build ~/redhat/sources ~/redhat/specs ~/redhat/rpms/i586 ~/redhat/srpms cat <<EOF > ~/.rpmmacros %_topdir $HOME/redhat %packager Firstname Lastname EOF rpm -Uvh 위와같은작업후 jdk-1_5_0_14-linux-i586.bin 파일을 ~/redhat/sources/ 복사하고다음의작업을실행한다. 9

13 rpmbuild -ba ~/redhat/specs/java sun.spec 새로만들어진 JAVA RPM 은 ~/redhat/rpms/i586 폴더에생성되어있으므로해당 rpm 을 카피하여설치한다. rpm -Uvh ~/redhat/rpms/i586/java sun jpp.i586.rpm rpm -Uvh ~/redhat/rpms/i586/java sun-devel jpp.i586.rpm 이 RPM 은 사이트에서도다운받을수있다. 1.5 lcg-ca 설치 lcg-ca 를설치한다. yum install lcg-ca /etc/cron.daily/ 에아래와같은스크립트를추가하여업데이트될수있게설정한다. #!/bin/sh yum update lcg-ca 1.6 glite-wn 와 glite-torque_client 설치 Yum 을이용하여 glite-wn 와 glite-torque_client 를설치한다. yum install glite-wn glite-torque_client glite-torque_utils 1.7 기타설정파일들 yaim 을이용하여워커노드로설정하기전에다음과같은파일들을설정하였다. KISTI 에서제공하는매뉴얼 ( 에따라설정작업이불필요할수도있다. ( 예 : /opt/edg/etc/edg-pbs-knownhosts.conf) 10

14 1 /etc/sysconfig/iptables # Firewall configuration written by redhat-config-securitylevel # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # PBS MOM & MAUI -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 15002: j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 15002: j ACCEPT # NTP port -A INPUT -s p udp --dport 123 -j ACCEPT # AMGA -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport j ACCEPT # ldap search -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport j ACCEPT COMMIT 세팅후 iptables service 를재시작한다. # service iptables restart 2 /etc/ssh/sshd_config CE 와 Word node 간에인증과정이필요없이접속하게하기위해 sshd_config file 을세팅하였다. IgnoreRhosts yes ~~ HostbasedAuthentication yes: ~~ IgnoreUserKnownHosts yes 3 /etc/hosts Hosts 파일에모든 Worker node 와 CE 를추가한다. 11

15 # Do not remove the following line, or various programs # that require network functionality will fail localhost.localdomain localhost hep001.kisti.re.kr hep hep003.kisti.re.kr hep hep004.kisti.re.kr hep hep005.kisti.re.kr hep hep006.kisti.re.kr hep hep007.kisti.re.kr hep hep008.kisti.re.kr hep hep009.kisti.re.kr hep hep010.kisti.re.kr hep hep011.kisti.re.kr hep hep012.kisti.re.kr hep hep013.kisti.re.kr hep hep014.kisti.re.kr hep hep015.kisti.re.kr hep015 4 /etc/ssh/shosts.equiv shosts.equiv 파일에모든 worker node 목록을추가하였다. hep001.kisti.re.kr hep003.kisti.re.kr hep004.kisti.re.kr hep005.kisti.re.kr hep006.kisti.re.kr hep007.kisti.re.kr hep008.kisti.re.kr hep009.kisti.re.kr hep010.kisti.re.kr hep011.kisti.re.kr hep012.kisti.re.kr hep013.kisti.re.kr hep014.kisti.re.kr hep015.kisti.re.kr 5 /opt/edg/etc/edg-pbs-knownhosts.conf edg-pbs-knownhosts.conf 파일을수정하였다. NODES = hep001.kisti.re.kr hep001.kisti.re.kr PBSBIN = /usr/bin KEYTYPES = rsa1,rsa,dsa KNOWNHOSTS = /etc/ssh/ssh_known_hosts 6 /etc/ssh/ssh_known_hosts CE 에서만들어진 ssh_known_hosts 을 worker node 들에복사하였다. 복사후 sshd daemon 을재 시작하였다. 7 워커노드설정 12

16 다음과같이 yaim 을실행하여워커노드로설정하였다. #/opt/glite/yaim/bin/yaim c s /opt/glite/yaim/etc/site-info.def n glite-wn n TORQUE_client 8 Site info 설정 site_info.def 설정파일은 CE 설정시사용된파일을모든워커노드에서사용하였고, 본구축 보고서에서는 CE 설치부분에서설명하였다. 2. 워커노드설치시발생했던문제들 2.1 추가설치가필요한패키지 워커노드설치시다음과같은패키지추가설치가필요했다. 그러나 KISTI 에서제공하는 매뉴얼에따라설치시또는시스템의설정상황에따라설치가필요없을수있다. 해당패키지는 EGEE 사이트및각종사이트에서다운받을수있다. ( 예 : 1 log4j 설치진행시 log4j 가필요하다는메시지에따라다음사이트에서 log4j noarch.rpm 파일을다운받아설치하였다. ( 2 jaxp_parser_impl 와 xml-commons-apis log4j 설치시다음과같은에러가발생하여 jaxp_parser_impl 와 xml-commons-apis 를 추가로설치하였다. warning: log4j jpp_2rh.noarch.rpm: V3 DSA signature: NOKEY, key ID db42a60e error: Failed dependencies: jaxp_parser_impl is needed by log4j jpp_2rh.noarch xml-commons-apis is needed by log4j jpp_2rh.noarch 위의 2 가지패키지를설치시다음과같은패키지가필요하여설치하였다. -xerces-j jpp_1rh.noarch.rpm -xml-commons jpp_1rh.noarch.rpm -xml-commons-jaxp-1.3-apis jpp_1rh.noarch.rpm -xml-commons-resolver jpp_1rh.noarch.rpm. 13

17 rpm -Uvh xerces-j jpp_1rh.noarch.rpm xml-commons jpp_1rh.noarch.rpm xml-commons-jaxp-1.3-apis jpp_1rh.noarch.rpm xml-commons-resolver jpp_1rh.noarch.rpm rpm -Uvh log4j noarch.rpm 3 Perl-SOAP-Lite packages wget rpm -Uvh perl-soap-lite noarch.rpm wget rpm -Uvh bouncycastle-jdk14_1.19-2_noarch.rpm wget rpm -Uvh edg-java-security_ _sl3_noarch.rpm wget rpm -Uvh edg-java-security-client_ _sl3_noarch.rpm wget rpm -Uvh edg-java-security-test_ _sl3_noarch.rpm Perl-SOAP-Lite 설치시다음과같은오류가발생하여다시옵션을조정하여설치하였다. j2sdk >= is needed by edg-java-security_ _sl3_noarch j2sdk >= is needed by edg-java-security-client _sl3.noarch j2sdk >= is needed by edg-java-security-test_ _sl3_noarch rpm Uvh --nodeps edg-java-security_ _sl3_noarch.rpm rpm Uvh --nodeps edg-java-security-client_ _sl3_noarch.rpm rpm Uvh --nodeps edg-java-security-test_ _sl3_noarch.rpm 4 Javamail packag glite-wn 패키지설치시 javamail 패키지가필요하다는에러가발생하여해당패키지를 에서다운받아설치하였다.. jaf is needed by javamail i386 lib-javax-activation so is needed by javamail i386 libgcj-ssa >= 3.5ssa is needed by javamail i386 libgcj.so.4 is needed by javamail i386 14

18 javamail 패키지가다음과같은패키지가필요하여 나 에서다운받아설치하였다. rpm -Uvh jaf i386.rpm libgcj-ssa-3.5ssa i386.rpm katana noarch.rpm javamail i386.rpm 3. CE (Computing Element) 설치 CE 설치는워커노드설치와동일한과정이많아중복된내용은생략하였다. 워커노드설치 과정을반복하며다른부분은아래와같다. 3.1 YUM update Scientific Linux CERN 4.6 (SLC46) 를설치후 CE 를설치하기전에 YUM update 를실시한다. /etc/yum.repos.d/ 에다음과같은파일을추가하고 yum update 를실행한다. 1 sl.repo [slc-base] baseurl= enabled=1 protect=0 [slc-update] baseurl= enabled=1 protect=0 2 dag.repo [dag] name=dag rpms baseurl= ftp://ftp.scientificlinux.org/linux/extra/dag/redhat/el4/en/$basearch/dag/ enabled=1 gpgcheck=0 gpgkey=file:///etc/pki/rpm-gpg/rpm-gpg-key-dag 3 jpackage.repo 15

19 [main] [jpackage17-generic] name=jpackage 1.7, generic baseurl= enabled=1 protect=0 gpgkey= gpgcheck=1 [jpackage17-generic-nonfree] name=jpackage 1.7, generic non-free baseurl= enabled=1 protect=0 gpgkey= gpgcheck=1 [main] [jpackage5-generic] name=jpackage 5, generic baseurl= enabled=1 protect=0 [jpackage5-generic-nonfree] name=jpackage 5, generic non-free baseurl= enabled=1 protect=0 4 ca.repo [CA] name=cas baseurl= 5 glite.repo 16

20 # This is the official YUM repository string for the 3.1 lcg-ce # Fetched from: CE.repo # Place it to /etc/yum.repos.d/ and run 'yum update' [lcg-ce] name=glite 3.1 lcg-ce service baseurl= enabled=1 [glite-torque_server] name=torque server baseurl= enabled=1 [glite-torque_utils] name=torque utils baseurl= enabled=1 [glite-bdii] name=glite 3.1 BDII baseurl= enabled=1 3.2 Host Certificate 설치 Host certificate 을 ca.gridcenter.or.kr 에서발급받아 /etc/grid-security 위치에복사하고다음과 같이권한을수정하였다.. #cd /etc/grid-security #chmod 644 hostcert.pem #chmod 400 hostkey.pem 3.3 기타설정파일들 1 bdiiuser 생성 bdiiuser 를생성한다. adduser bdiiuser 2 wn-list.conf 설정 /opt/glite/yaim/etc/wn-list.conf 파일에 worker node 리스트를추가한다. 17

21 hep003.kisti.re.kr hep004.kisti.re.kr hep005.kisti.re.kr hep006.kisti.re.kr hep007.kisti.re.kr hep008.kisti.re.kr hep009.kisti.re.kr hep010.kisti.re.kr hep011.kisti.re.kr hep012.kisti.re.kr hep013.kisti.re.kr hep014.kisti.re.kr hep015.kisti.re.kr 3 lcg-ce 설정 lcg-ce 를 yaim 을이용하여설정한다. /opt/glite/yaim/bin/yaim -c -s /opt/glite/yaim/etc/site-info.def -n lcg-ce -n TORQUE_server -n TORQUE_utils -n BDII_site 3.4 site_info.def 파일설정 site_info.def 파일설정은일반적인사이트의 CE 설치와크게다른점은없으나, CDF VO 를 설정하기위해서 CDF VO 의해당정보를추가하였다. CDF VO 의정보는다음의사이트들에서 참조하였다. #CDF# VO_CDF_SW_DIR=$VO_SW_DIR/cdf VO_CDF_DEFAULT_SE=$SE_HOST VO_CDF_STORAGE_DIR=$CE_CLOSE_SE1_ACCESS_POINT/cdf VO_CDF_QUEUES="cdf" #VO_CDF_USERS=ldap://grid-vo.cnaf.infn.it/ou=testbed1,o=cdf,dc=eu-datagrid,dc=org VO_CDF_VOMS_SERVERS="vomss://voms.cnaf.infn.it:8443/voms/cdf?/cdf" VO_CDF_VOMSES="cdf voms.cnaf.infn.it /C=IT/O=INFN/OU=Host/L=CNAF/CN=voms.cnaf.infn.it cdf" VO_CDF_VOMS_CA_DN="/C=IT/O=INFN/CN=INFN CA" VO_CDF_DEFAULT_SE=$VO_DEFAULT_SE site_info.def 전체내용은부록에첨부하였다. 18

22 Ⅳ. 결과 CDF 실험에는여러가지컴퓨팅프로세싱방법이활용되고있다. 그중에 KISTI 는 LCG 팜을활용하여, Condor over Globus 방식을사용하여 CDF Analysis Farm 을구축하였다. 이러한시스템을통하여 CDF 실험을위한 CPU 를확보할수있고, 그리드팜을활용하는추세에부합된다. CDF Analysis Farm (KR-KISTI-HEP) 은대만의 ASGC (Academi Sinica Grid Center) 의 OSG (Open Science Grid) 팜및 LCG 팜과연동되어 Pacific CAF 를구성하는데 KISTI 의 CAF Analysis Farm (KR-KISTI-HEP) 은 Pacific CAF 의워커노드로활용된다. 왜냐하면 KR-KISTI-HEP 은자체 Head 노드와 VOMS 서버를가지고있지않고, Head 노드는대만의 paccaf.phys.sinica.edu.tw 를사용하고 VOMS 서버는이탈리아의 voms.cnaf.infn.it 를사용하였기때문이다. 향후 CGCC (CDF Grid Computing Center) 를 KISTI 에구축시더많은워커노드숫자와아울러독자적인 Head 노드와 VOMS 서버를설치하게될것이다. 현재 Pacific CAF 를구성하는팜을자세히살펴보면한국의 KR-KISTI-HEP. 대만의 IPAS_OSG, TW_NCHC_Formosa2, Taiwan_LCG2, IPAS_CS 그리고일본의 JP_TSUKUBA_U_03 으로구성되어있다. 아래그림은 KR-KIST_HEP 을포함한 Pacific CAF 의웹모니터링시스템을보여준다. Figure 3. Pacific CAF 웹모니터링시스템 19

23 참고자료 [1] 한국과학기술정보연구원 e-science 사업단기술개발팀, glite 미들웨어설치 & 관리매뉴얼, 한국과학기술정보연구원 (2007) [2] 조기현, 김현우, 고에너지물리 e-science 연구환경의구현, 한국콘텐츠학회추계종합학술대회 (2007) [3] [4] [5] 20

24 부록 1. site_info.def 파일 2. Minho Jeung, Hyunwoo Kim, Kihyeon Cho* and Ok-Hwan Byeon, The Data Processing of e- Science for High Energy Physics, in Proc. Of International Workshop on e-science for Physics (Daejeon, 2008) 3. 정민호, 조기현, 김현우외 18 명 CDF Grid at KISTI, 2008 한국물리학회가을학술논문발표회발표자료 4. 정민호, 조기현, 김현우, The Data Processing of e-science for High Energy Physics, International Workshop on e-science for Physics 정민호, 조기현, 김현우외 19 명, The current status of CDF Grid, 2008 한국물리학회봄학술논문발표회발표자료 21

25 # 부록 1. site_info.def 파일 # YAIM example site configuration file - adapt it to your site! MY_DOMAIN=gridcenter.or.kr # Node names # Note: - SE_HOST --> Removed, see CLASSIC_HOST, DCACHE_ADMIN, DPM_HOST below # - REG_HOST --> There is only 1 central registry for the time being. CE_HOST=hep001.kisti.re.kr BDII_HOST=hep001.kisti.re.kr SITE_BDII_HOST=hep001.kisti.re.kr MON_HOST=rgma.sdfarm.kr REG_HOST=lcgic01.gridpp.rl.ac.uk VO_DEFAULT_SE=dpm01.grid.sinica.edu.tw # Debug variable. If set then some function will print additional # debugging information. # Possible values: NONE, ABORT, ERROR, WARNING, INFO, DEBUG YAIM_LOGGING_LEVEL=INFO # VO-BOX - Set this if you are building a VO-BOX VOBOX_PORT=1975 # Set this to "yes" your site provides an X509toKERBEROS Authentication Server # Only for sites with Experiment Software Area under AFS GSSKLOG=no GSSKLOG_SERVER=my-gssklog.$MY_DOMAIN # LFC - Set these if you are installing an LFC LFC_DB_PASSWORD="*******" # These are set to default to using the standard database on the same hosts # as the LFC daemon is on LFC_DB_HOST=$LFC_HOST LFC_DB=cns_db # If you use a DNS alias in front of your LFC, specify it here - 1 -

26 LFC_HOST_ALIAS="" # All catalogues are local unless you add a VO to # LFC_CENTRAL, in which case that will be central LFC_CENTRAL="" # If you want to limit the VOs your LFC serves, add the locals here LFC_LOCAL="" # TORQUE - Change this if your torque server is not on the CE # it's ingored for other batch systems BATCH_SERVER=$CE_HOST # These variables tell YAIM where to find additional configuration files. WN_LIST=/opt/glite/yaim/etc/wn-list.conf USERS_CONF=/opt/glite/yaim/etc/users.conf GROUPS_CONF=/opt/glite/yaim/etc/groups.conf FUNCTIONS_DIR=/opt/glite/yaim/functions YAIM_VERSION= # Repository settings LCG_REPOSITORY="'rpm rhel30 externals Release3.0 updates'" CA_REPOSITORY="rpm LCG-CAs/current production" REPOSITORY_TYPE="apt" # or "yum" # For the relocatable (tarball) distribution, ensure # that INSTALL_ROOT is set correctly INSTALL_ROOT=/opt # You will probably want to change these too for the relocatable dist OUTPUT_STORAGE=/tmp/jobOutput JAVA_LOCATION="/usr/lib/jvm/java sun " # Set this to '/dev/null' or some other dir if you want # to turn off yaim installation of cron jobs CRON_DIR=/etc/cron.d # Set this to your prefered and firewall allowed port range GLOBUS_TCP_PORT_RANGE=" " - 2 -

27 # Choose a good password! And be sure that this file cannot be read by # any grid job! # GRID_TRUSTED_BROKERS: DNs of services (RBs) allowed to renew/retrives # credentials from/at the myproxy server. Put single quotes around each trusted DN!!! GRID_TRUSTED_BROKERS=" 'broker one' 'broker two' " # The RB now uses the DLI by default; set VOs here which should use RLS RB_RLS="" # "atlas cms" # GridIce server host name (usually run on the MON node). #GRIDICE_SERVER_HOST=$MON_HOST # Site-wide settings SITE_ =m***g@kisti.re.kr SITE_CRON_ =$SITE_ # not yet used will appear in a later release SITE_SUPPORT_ =$SITE_ SITE_NAME=KR-KISTI-HEP SITE_LOC="Daejeon, Korea" SITE_LAT= # -90 to 90 degrees SITE_LONG= # -180 to 180 degrees SITE_WEB=unset SITE_TIER=unset SITE_SUPPORT_SITE=unset # If you have a http proxy configure it on order to decrease the load on the CA hosts #SITE_HTTP_PROXY="myproxy.my.domain" # Jobmanager specific settings JOB_MANAGER=lcgpbs CE_BATCH_SYS=torque BATCH_BIN_DIR=/usr/bin BATCH_VERSION=torque BATCH_LOG_DIR=/var/spool/pbs/server_priv/accounting - 3 -

28 # Architecture and enviroment specific settings CE_CPU_MODEL=P4 CE_CPU_VENDOR=intel CE_CPU_SPEED=2666 CE_OS="ScientificCERNSLC" CE_OS_RELEASE=4.6 CE_OS_VERSION="Baryllium" # CE_OS_ARCH should be set to result of `uname -m` runned on WN CE_OS_ARCH=i686 CE_MINPHYSMEM=512 CE_MINVIRTMEM=1024 CE_PHYSCPU=1 CE_LOGCPU=1 CE_SMPSIZE=2 CE_SI00=381 CE_SF00=0 CE_OUTBOUNDIP=TRUE CE_INBOUNDIP=FALSE CE_RUNTIMEENV=" LCG-2 LCG-2_1_0 LCG-2_1_1 LCG-2_2_0 LCG-2_3_0 LCG-2_3_1 LCG-2_4_0 LCG-2_5_0 LCG-2_6_0 LCG-2_7_0 GLITE-3_0_0 GLITE-3_1_0 R-GMA " # Set this if your WNs have a shared directory for temporary storage CE_DATADIR="" # Classic SE # CLASSIC_HOST="classic_SE_host" # CLASSIC_STORAGE_DIR="/storage" - 4 -

29 # dcache-specific settings # ignore if you are not running d-cache # Your dcache admin node # DCACHE_ADMIN="my-admin-node" # Pools must include host:/absolutepath and may optionally include # size host:size:/absolutepath if the size is not set the pool will # fill the partition it is installed upon. size cannot be smaller # than 4 (Gb) unless you are an expert. # DCACHE_POOLS="my-pool-node1:[size]:/pool-path1 my-pool-node2:/pool-path2" # Optional # For large sites the load on the admin-node is a limiting factor. Pnfs # accounts for a lot of this load and so can be placed on a different # node to balance the load better. # Set DCACHE_DOOR_* to "off" if you dont want the door to start on any host # # DCACHE_DOOR_SRM="door_node1[:port]" # DCACHE_DOOR_GSIFTP="door_node1[:port] door_node2[:port]" # DCACHE_DOOR_GSIDCAP="door_node1[:port] door_node2[:port]" # DCACHE_DOOR_DCAP="door_node1[:port] door_node2[:port]" # DCACHE_DOOR_XROOTD="door_node1[:port] door_node2[:port]" # DCACHE_DOOR_LDAP="admin_node" # DCACHE_DOOR_XROOTD="door_node1[:port] door_node2[:port]" # This option sets the pnfs server it defaults to the admin node if # not stated. # # DCACHE_PNFS_SERVER="pnfs_node" # # Sets the portrange for dcache as a GSIFTP server in "passive" mode # # DCACHE_PORT_RANGE_PROTOCOLS_SERVER_GSIFTP=50000,

30 # # Sets the portrange for dcache as a (GSI)DCAP and xrootd server in # "passive" mode # # DCACHE_PORT_RANGE_PROTOCOLS_SERVER_MISC=60000,62000 # # Sets the portrange for dcache as a GSIFTP client in "active" mode # # DCACHE_PORT_RANGE_PROTOCOLS_CLIENT_GSIFTP=33115,33215 # This option sets the pnfs server it defaults to the admin node if # not stated. # # DCACHE_PNFS_SERVER="pnfs_node" # Only change if your site has an existing D-Cache installed # To a different storage root. # DCACHE_PNFS_VO_DIR="/pnfs/${MY_DOMAIN}/data" # Set to "yes" only if YAIM shall reset the dcache configuration, # or install DCache for the first time. # i.e. if you want YAIM to configure dcache - WARNING: # this may wipe out any dcache parameters previously configured! # RESET_DCACHE_CONFIGURATION=no # Set to "yes" only if YAIM shall reset the dcache nameserver, # Or install DCache for the first time. # i.e. if you want YAIM to clear the content of dcache - WARNING: # this may wipe out any dcache files previously stored! # RESET_DCACHE_PNFS=no # Set to "yes" only if YAIM shall reset the dcache Databases, # or install DCache for the first time. # i.e. if you want YAIM to clear the metadata of dcache - WARNING: # this may wipe out any dcache files names previously stored! # Leaving your system without any way to reestablish which files # are stored. # RESET_DCACHE_RDBMS=no - 6 -

31 # # SE_dpm-specific settings - Ignore if you are not running a DPM # # Set these if you are installing a DPM yourself # and/or if you need a default DPM for the lcg-stdout-mon # # DPMDATA is now deprecated. Use an entry like $DPM_HOST:/filesystem in # the DPM_FILESYSTEMS variable. # From now on we use DPM_DB_USER and DPM_DB_PASSWORD to make clear # it's different role from that of the dpmmgr unix user who owns the # directories and runs the daemons. # The name of the DPM head node DPM_HOST=hansolo.kisti.re.kr # my-dpm.$my_domain #DPM_HOST=dpm01.grid.sinica.edu.tw # The DPM pool name DPMPOOL=lcgPool # The filesystems/partitions parts of the pool DPM_FILESYSTEMS="leia.kisti.re.kr:/data01 leia.kisti.re.kr:/data02" #DPM_FILESYSTEMS="$DPM_HOST:/path1 my-dpm-poolnode.$my_domain:/path2" # The database user DPM_DB_USER=dpmmgr # The database user password DPM_DB_PASSWORD=*** # The DPM database host DPM_DB_HOST=$DPM_HOST # Specifies the default amount of space reserved for a file DPMFSIZE=1G # Variable for the port range - Optional, default value is shown # RFIO_PORT_RANGE=" " - 7 -

32 # This largely replaces CE_CLOSE_SE but it is a list of hostnames SE_LIST="$DPM_HOST" SE_ARCH="disk" # "disk, tape, multidisk, other" #FTS_SERVER_URL=" FTS_SERVER_URL=" ################################ # BDII configuration variables # ################################ BDII_SITE_TIMEOUT=120 BDII_RESOURCE_TIMEOUT=`expr "$BDII_SITE_TIMEOUT" - 5` GIP_RESPONSE=`expr "$BDII_RESOURCE_TIMEOUT" - 5` GIP_FRESHNESS=60 GIP_CACHE_TTL=300 GIP_TIMEOUT=150 # Check the validity of this URL in the documentation BDII_HTTP_URL=" # The Freedom of Choice of Resources service allows a top-level BDII # to be instructed to remove VO-specific access control lines for # resources that do not meet the VO requirements BDII_FCR= LCG_GFAL_INFOSYS=bdii02.grid.sinica.edu.tw:2170 # Ex.: BDII_REGIONS="CE SE RB PX VOBOX" BDII_REGIONS="CE SE" # list of the services provided by the site # The following examples are valid for glite 3.0 # If you are configuring a 3.1 node change the port to 2170 and mds-vo-name=resource BDII_CE_URL="ldap://$CE_HOST:2135/mds-vo-name=local,o=grid" BDII_SE_URL="ldap://$CLASSIC_HOST:2135/mds-vo-name=local,o=grid" BDII_RB_URL="ldap://$RB_HOST:2135/mds-vo-name=local,o=grid" BDII_PX_URL="ldap://$PX_HOST:2135/mds-vo-name=local,o=grid" BDII_LFC_URL="ldap://$LFC_HOST:2135/mds-vo-name=local,o=grid" BDII_VOBOX_URL="ldap://$VOBOX_HOST:2135/mds-vo-name=local,o=grid" - 8 -

33 BDII_FTS_URL="ldap://$FTS_HOST:2170/mds-vo-name=resource,o=grid" ############################## # VO configuration variables # ############################## # # This file contains variables defined for the following VOs # alice # dteam # ops # # Edit the following set of variables if you want to configure a different VO: # VO_<vo_name>_SW_DIR # VO_<vo_name>_DEFAULT_SE # VO_<vo_name>_STORAGE_DIR # VO_<vo_name>_POOL_PATH (optional) # VO_<vo_name>_VOMS_SERVERS # VO_<vo_name>_VOMS_EXTRA_MAPS (optional) # VO_<vo_name>_VOMSES # VO_<vo_name>_VOMS_CA_DN # # If you are configuring a DNS-like VO, please check # the following URL: # # IMPORTANT! Please, take into account that in the future YAIM will no longer provide VO # related variables for these VOs. This information should be obtained out of the CIC portal: # # # The VO variables will be automatically generated by the YAIM configurator and integrated in YAIM. # Space separated list of supported VOs by your site #VOS="atlas alice lhcb cms dteam biomed ops" VOS="alice dteam ops cdf" QUEUES=${VOS} # For each queue define a _GROUP_ENABLE variable which is a list # of VO names and VOMS FQANs # Ex.: MYQUEUE_GROUP_ENABLE="ops atlas cms /VO=cms/GROUP=/cms/Susy" - 9 -

34 # In DNS like VO names dots and dashes shoul be replaced with underscore: # Ex.: MYQUEUE_GROUP_ENABLE="my.test-queue" # MY_TEST_QUEUE_GROUP_ENABLE="ops atlas" ALICE_GROUP_ENABLE="alice" DTEAM_GROUP_ENABLE="dteam" OPS_GROUP_ENABLE="ops" CDF_GROUP_ENABLE="cdf" VO_SW_DIR=/opt/exp_soft # Set this if you want a scratch directory for jobs EDG_WL_SCRATCH="" ########## # alice # ########## VO_ALICE_SW_DIR=$VO_SW_DIR/alice VO_ALICE_DEFAULT_SE=$CLASSIC_HOST VO_ALICE_STORAGE_DIR=$CLASSIC_STORAGE_DIR/alice VO_ALICE_VOMS_SERVERS='vomss://voms.cern.ch:8443/voms/alice?/alice/' VO_ALICE_VOMSES="'alice lcg-voms.cern.ch /DC=ch/DC=cern/OU=computers/CN=lcgvoms.cern.ch alice 24' 'alice voms.cern.ch /DC=ch/DC=cern/OU=computers/CN=voms.cern.ch alice 24'" VO_ALICE_VOMS_CA_DN="'/DC=ch/DC=cern/CN=CERN Trusted Certification Authority' '/DC=ch/DC=cern/CN=CERN Trusted Certification Authority'" VO_ALICE_DEFAULT_SE=$VO_DEFAULT_SE ######### # dteam # ######### VO_DTEAM_SW_DIR=$VO_SW_DIR/dteam VO_DTEAM_DEFAULT_SE=$CLASSIC_HOST VO_DTEAM_STORAGE_DIR=$CLASSIC_STORAGE_DIR/dteam VO_DTEAM_VOMS_SERVERS='vomss://voms.cern.ch:8443/voms/dteam?/dteam/' VO_DTEAM_VOMSES="'dteam lcg-voms.cern.ch /DC=ch/DC=cern/OU=computers/CN=lcgvoms.cern.ch dteam 24' 'dteam voms.cern.ch /DC=ch/DC=cern/OU=computers/CN=voms.cern.ch dteam 24'" VO_DTEAM_VOMS_CA_DN="'/DC=ch/DC=cern/CN=CERN Trusted Certification Authority' '/DC=ch/DC=cern/CN=CERN Trusted Certification Authority'" VO_DTEAM_DEFAULT_SE=$VO_DEFAULT_SE

35 ####### # ops # ####### VO_OPS_SW_DIR=$VO_SW_DIR/ops VO_OPS_DEFAULT_SE=$CLASSIC_HOST VO_OPS_STORAGE_DIR=$CLASSIC_STORAGE_DIR/ops VO_OPS_VOMS_SERVERS="vomss://voms.cern.ch:8443/voms/ops?/ops/" VO_OPS_VOMSES="'ops lcg-voms.cern.ch /DC=ch/DC=cern/OU=computers/CN=lcg-voms.cern.ch ops 24' 'ops voms.cern.ch /DC=ch/DC=cern/OU=computers/CN=voms.cern.ch ops 24'" VO_OPS_VOMS_CA_DN="'/DC=ch/DC=cern/CN=CERN Trusted Certification Authority' '/DC=ch/DC=cern/CN=CERN Trusted Certification Authority'" VO_OPS_DEFAULT_SE=$VO_DEFAULT_SE #CDF# VO_CDF_SW_DIR=$VO_SW_DIR/cdf VO_CDF_DEFAULT_SE=$SE_HOST VO_CDF_STORAGE_DIR=$CE_CLOSE_SE1_ACCESS_POINT/cdf VO_CDF_QUEUES="cdf" #VO_CDF_USERS=ldap://grid-vo.cnaf.infn.it/ou=testbed1,o=cdf,dc=eu-datagrid,dc=org VO_CDF_VOMS_SERVERS="vomss://voms.cnaf.infn.it:8443/voms/cdf?/cdf" VO_CDF_VOMSES="cdf voms.cnaf.infn.it /C=IT/O=INFN/OU=Host/L=CNAF/CN=voms.cnaf.infn.it cdf" VO_CDF_VOMS_CA_DN="/C=IT/O=INFN/CN=INFN CA" VO_CDF_DEFAULT_SE=$VO_DEFAULT_SE

36 The Data Processing of e-science for High Energy Physics Minho Jeung, Hyunwoo Kim, Kihyeon Cho* and Ok-Hwan Byeon e-science Division, Korea Institute of Science and Technology Information, Daejeon, , Korea The goal of high-energy physics is to understand the basic properties of elementary particles and their interactions. High-energy physics is usually conducted at the major accelerator sites, in which detector design, construction, signal processing, data acquisition, and data analysis are performed on a large scale. However, in order to study high-energy physics anytime and anywhere even if we are not on-site of accelerator laboratories, we have created new research paradigm, e-science. The e-science for high-energy physics has three components: data production, data processing, and data analysis. In this paper, we focus on data processing of e-science for high-energy physics. We show current implementations and experiments of data processing for ALICE (A Large Ion Collider Experiment) Tier 2 center and CDF (Collider Detector at Fermilab) grid farms. PACS number: c, t, Bx Keywords: e-science; High-energy physics data grid; Grid computing; Data processing cho@kisti.re.kr Fax:

37 I. INTRODUCTION The goal of HEP (High-Energy Physics) is to understand the basic properties of elementary particles and their interactions. Since the invention of the cyclotron by Ernest Orlando Lawrence at the University of California [1], HEP has usually conducted at the major accelerator sites, in which detector design, construction, signal processing, data acquisition, and data analysis are performed on a large scale. In order to cope with more data and more collaboration, we have created the concept of e-science. The goal of the e-science for high-energy physics is to study high-energy physics anytime and anywhere even if we are not on-site of accelerator laboratories. To perform computing processing at the required HEP scale, the data grid technology is a strong requirement [2]. An amazing advance in IT (Information Technology) such as Moore s law and widespread use of IT also helps computing processing [3]. The objective of HEP data grid is to construct a system to manage and process HEP data and to support a high energy physics community. In this paper, we introduce data processing as a component of e-science for ALICE (A Large Ion Collider Experiment) and CDF (Collider Detector at Fermilab) experiments. We have built an ALICE Tier 2 center and CDF Analysis Farm based on LCG (LHC Computing Grid) farm. II. DATA PROCESSING OF E-SCIENCE 1. e-science e-science is a new research paradigm for science, which is computationally intensive science [4]. Consequently, e-science uses immense data sets that require grid computing and is carried out in highly distributed network environments [4]. HEP requires a particularly well-developed e-science infrastructure due to its need for adequate computing facilities for the analysis of results and the storage of data originating from accelerator laboratories [5]. Therefore, HEP is one of best applications for e-science [5]. The components of e-science are 1) data production, 2) data 2

38 processing and 3) data analysis. In this paper, we focus on data processing. First, data production is to take both on-line shift and off-line shift anywhere. Second, data processing is to process data by using high-energy physics data and to support the high-energy physics community [6]. Third, data analysis is for collaborations around the world to analyze and publish the results by using collaborative environments. 2. Data processing as a component of e-science The main infrastructure of data processing for e-science is network and computing resources. The first infrastructure is both domestic network (KREONET) and international networks (GLORIAD). The KREONET (Korea Research Environment Open NETwork) is a 1~40 Gbps national research and development network operated by the KISTI. The KREONET is also connected to GLORIAD (Global Ring Network for Advanced Applications Development). The GLORIAD is built on 10-Gbps of a fiber-optic ring of networks around the northern hemisphere of earth linked with Russia, China, Korea, Canada, USA, the Netherlands and the five Nordic countries (Denmark, Finland, Iceland, Norway and Sweden). It provides scientists, educators and students with advanced networking tools that improve communications and data exchange, enabling active, daily collaboration on common problems [7]. With GLORIAD, the high-energy physics community can move unprecedented volumes of valuable data effortlessly, stream video and communicate through quality audio- and video-conferencing [7]. The KISTI is directly peered to CERN (European Organization for Nuclear Research) via a 10-Gbps network with GLORIAD. The second infrastructure is computing resources. For current and future HEP activities for large-scale data, the HEP data grid is indispensable. We need to maintain a mass storage system of hard disks and tapes in a stable state. If the HEP data are to be made transparent, CPU power should be extendable and accessible [5]. Transparent HEP data means that the data should be analyzed even if high energy physicists as users do not know the actual source of the data [6]. 3

39 III. ACHIVEMENTS 1. Data processing with ALICE Experiment The objective of ALICE experiment at CERN as RHIC (Relativistic Heavy Ion Collider) experiments at BNL (Brookhaven National Laboratory) [8] is to study the physics of strongly interacting matter at extreme energy densities, where the formation of a new phase of matter, the quark-gluon plasma, is expected. ALICE has been conducted at CERN in which detector design, construction, signal processing, data acquisition, and data analysis are performed. The data size will be a few PBytes data per year. In order to handle this amount of data, we use grid technology. For this work, we assembled LCG farm at KISTI for ALICE experiment. The LCG is a world-wide infrastructure where all the computations relevant to the analysis of the data coming out of the four LHC experiments are taking place. LCG organization involves a hierarchy of computing centers from CERN, labeled Tier1, Tier 2 and Tier 3. In 2007, the MOST (Ministry of Science and Technology) in Korea and CERN had MOU (Memorandum of Understanding) to build and operate ALICE Tier 2 center at the KISTI. Table 1 shows ALICE Tier2 computing capacities at the KISTI on the MOU. We have built and operate ALICE Tier2 center using LCG farms (KR-KISTI-CTRT-01). The Figure 1 [9] shows the scheme of the ALICE Tier2 center at the KISTI which consists of 120 ksi2k CPU and 30 TBytes of storage. The farm maintains 96 percent operating capacity (8,000 jobs per month) recently. Now the ALICE Tier2 center at the KISTI become a federation of global ALICE farms which consists of 13,804 ksi2k CPU and PBytes disk around the world. Currently, around 1000 physicists from 109 institutes, 31 countries use the ALICE farms. 2. Data processing with CDF Experiment 1. Introduction The CDF is an experiment on the Tevatron, in Fermilab. The CDF group began its Run II phase in CDF computing needs include raw data reconstruction, data reduction, event simulation, 4

40 and user analysis [10]. Although very different in the amount of resources needed, they are all naturally parallel activities [10]. The CDF computing model is based on the concept of CAF (Central Analysis Farm) [11]. To date, Run II has gathered more than 2 PBytes of data of 4fb -1. The increasing luminosity of the Tevatron collider has caused the computing requirement for data analysis and Monte Carlo production to grow larger than the dedicated CPU resources that was available [12]. In order to meet future demand, CDF has examined the possibility of using shared computing resources. CDF is using several computing processing systems, such as CAF, DCAF (Decentralized CDF Analysis Farm) and grid systems. Korea group has built DCAF for the first time [6]. Finally, we have constructed the CDF Grid farm at KISTI as well as the LCG farm for ALICE experiments. Only 60% of CPU resources of CDF experiments run at Central Analysis Farm inside Fermilab. Now, global DCAF and grid farms constituted 40 % of total CPU resources of the CDF experiment [6]. 2. CAF (Central Analysis Farm) In 2001, we have built CAF, which is a cluster farm inside Fermilab in USA. The CAF was developed as a portal. A set of daemons accept requests from the users, via kerberized socket connections and a legacy protocol [10]. Those requests are then converted into commands to the under laying batch system that does the real work [10]. The CAF is a large farm of computers running Linux with access to the CDF data handling system and databases to allow the CDF collaborators to run batch analysis jobs [11]. The submission uses a CAF portal which has two special features. The one is that users can submit jobs from anywhere. The other feature is that job output can be sent directly to a desktop or stored on CAF FTP server for later retrieval. 3. DCAF (Decentralized CDF Analysis Farm) In 2003, we have built DCAF, a cluster farm outside Fermilab, for the CDF collaboration so that the CDF users around the world may use it like CAF at Fermilab. DCAF enabled a user to submit a job to the cluster either at CAF or at the DCAF. In order to run the remote data stored at Fermilab in 5

41 USA, we used SAM (Sequential data Access via Meta-data) [6]. We used the same GUI (Graphic User Interface) used in CAF. Difference is only in selection of the analysis farm for the DCAF [6]. 4. CDF Grid In 2006, we have built CDF grid farms in North America, Europe and Pacific Asia Areas. HEP user activity patterns are CPU intensive and large data file transportation. These activity patterns required to change a HEP computing model from clusters to grid to meet required hardware resources. Dedicated Linux Clusters on the FBSNG (Farm Batch System Next Generation) batch system were used when CAF launched in However, the CAF portal has gone from interfacing to a FBSNG-managed pool to Condor as a grid based implementation, without the need for users to learn new interfaces [10]. Now, we have adapted and converted out a workflow to the grid. The goal of movement to grid at CDF experiment is world wide trend for HEP experiment. We need to take advantage of global innovations and resources since CDF still has a lot of data to be analyzed. CAF portal is allowed to change the underlying batch system without changing the user interface. CDF used several batch systems: 1) FBSNG, 2) Condor, 3) Condor over Globus 4) glite WMS (Workload Management System). The third and the forth are grid based production systems. North America CDF Analysis Farm and the Pacific CDF Analysis Farm is a Condor over Globus model whereas European CDF Analysis Farm is a glite WMS (Workload Management System) model. Table 2 summarizes the comparison of Grid CDF Analysis Farm [5]. Figure 2 shows the scheme of CDF grid farms. The users submit a job after they input required information about the job (shell script to run, local path to executables and shared libraries, etc.) into a kerberized client interface [11]. The Condor over Globus model uses a created virtual private Condor pool out of grid resources. A job containing Condor daemons is also known as a glide-in job [10]. The advantage of this approach is that all Grid infrastructures are hidden by the glide-ins [10]. The glite WMS model talks directly to the glite WMS, also known as the Resource Broker [10]. It allows us to use grid sites where the 6

42 Condor over Globus model would not work at all, and is adequate for grid job needs [10]. Since the Condor based grid farm is more flexible, we applied this method to the Pacific CDF Analysis Farm. 5. Pacific CDF Analysis Farm The regional CDF Collaboration of Taiwan, Korea and Japanese groups have built the CDF Analysis Farm which is based on grid farms. We called this federation of grid farms as the Pacific CDF Analysis Farm. Figure 3 shows the components of the farm. The Pacific CDF Analysis Farm is a distributed computing model on the grid. It is based on the Condor glide-in concept, where Condor daemons are submitted to the grid, effectively creating a virtual private batch pool [10]. Thus, submitted jobs and results are integrated and are shared in grid sites. For work nodes, we use both LCG and OSG (Open Science Grid) farms. The head node of Pacific CDF Analysis Farm is located at the Academia Sinica in Taiwan. Now it has become a federation of one LCG farm at the KISTI in Korea (KR-KISTI-HEP), one LCG farm at the University of Tsukuba in Japan (JP-TSUKUBA-U-03) and one OSG and two LCG farms in Taiwan (IPAS_OSG, IPAS_CS, Taiwan-LCG2). 6. CGCC (CDF Grid Computing Center) In 2008, we have made a plan to build CGCC which is a big grid farm with storage farm. We have known that expected CPU needs by CDF experiment in 2008 about 65,000 kspi2k. However, available CPUs at Fermilab are about 5,000 ksi2k [13]. In addition, it needs to guarantee resources because LHC is starting. CGCC has been proposed and created in countries where there are big computing centers [13]. The candidate sites are IN2P3 in France, CNAF in Italy and KISTI in Korea. By 2011, the KISTI will purchase 2,000 CPUs and 1,500 TByte storages for high-energy physics experiments - CDF, ALICE and Belle. Among the resources we will make CGCC which will be 300 TBytes of the new systems for CDF data with Fermilab. Table 3 shows the comparison of Pacific CDF Analysis Farm and CDF Grid Computing Center at the KISTI. 7

43 IV. CONCLUSION Figure 4 shows the LCG monitoring system of Pacific region. At the KISTI, we see both sites of the ALICE Tier2 Center (KR-KISTI_GCRT-01) and Pacific CDF Analysis Farm (KR-KISTI-HEP) which run successfully. We also see the work node of Pacific CDF Analysis Farm in Taiwan (Taiwan-LCG2). The e-science for high-energy physics shows a new paradigm of science. As one components of e-science for high-energy physics, we have introduced data processing. We succeeded in developing and installing high-energy physics data grid farms. We successfully run the official ALICE Tier2 center and Pacific CDF Analysis Farm. Conclusively, high-energy physics is one of good leading areas for data processing of e-science. ACKNOWLEDGEMENT We would like to thank to Beobkyun Kim, and Soonwook Hwang (KISTI) for LCG farm, Yuchul Yang, Mark Neubauer (UCSD) and Frank Wuerthwein (UCSD) for CAF (Central Analysis Farm), and Igor Sfillioi (Fermilab) and Hsieh Tsan Lung (AS) for Pacific CAF. 8

44 REREFENCES [1] W.T. Chu, J. Korean Phys. Soc. 50, 1385 (2007). [2] I.Foster, C. Kesselman and S. Tuecke, International J. of High-Performance Computing Applications, 15, 200 (2001). [3] K. Cho, Comp. Phys. Comm. 177, 247 (2007). [4] See [5] K. Cho, J. Korean Phys. Soc. 53, 1187 (2008). [6] K. Cho, Internat. J. of Comp. Sci. and Network Sec. 7, 49 (2007). [7] See [8] E. Shuryak, I. Zahed and S.-J. Sin, J. Korean Phys. Soc. 50, 384 (2007). [9] B. Kim, In Proc. of 2008 LHC Physics Workshop at Korea, (Seoul, Korea, 2008). [10] I. Sffligoi, Comp. Phys. Comm. 177, 235 (2007). [11] M. Neubauer, Nucl. Instr. and Meth. A 502, 386 (2008). [12] A. Fella, S. C. Hsu, S. Sarkar, D. Jeans, F. Delli Paoli, D. Lucchesi, I. Sfiligoi, S. Belforte, E. Lipeles, M. Neubauer and F. Wuerthwein, In Proc. of Conf. on Computing on High Energy Physics (Mumbai, India, 2006). [13] G. Compostella, D. Lucchesi, S. P. Griso and I. Sfiligoi, In Proc. of 3rd IEEE Internat. Conf. on e-science and Grid Computing (Bangalore, India, 2007). 9

45 Fig. 1. The scheme of the ALICE Tier2 center at the KISTI. Fig. 2. The Scheme of CDF grid farms. 10

46 Fig. 3. The Components of Pacific CDF Analysis Farm. 11

47 Fig. 4. The LCG monitoring system of Pacific region. At the KISTI, we see both sites of the ALICE Tier2 Center (KR-KISTI_GCRT-01) and Pacific CDF Analysis Farm (KR-KISTI-HEP). 12

48 Table 1. The ALICE Tier2 computing capacities at the KISTI. KISTI, Pledged Planned to be pledged Daejon, Korea CPU (ksi2k) Disk Nominal Wan (Mbps/s) Table 2. The comparison of Grid CDF Analysis Farm. Grid CDF Analysis Farm North America CDF Analysis Farm European CDF Analysis Farm Pacific CDF Analysis Farm Head node Fermilab (USA) CNAF (Italia) AS (Taiwan) Work node USSD (USA) etc IN2P3 (France) etc KISTI (Korea) etc Grid middleware OSG LCG LCG, OSG Method Condor over Globus WMS (Workload Management System Condor over Globus VO (Virtual Organization) CDF VO CDF VO CDF VO Table 3. The comparison of Pacific CDF Analysis Farm and CGCC. Pacific CDF Analysis Farm at KISTI CGCC at KISTI Head node paccaf.phys.sinica.edu.tw New Head node VOMS (Virtual Organization Management voms.cnaf.infn.it New VOMS server Service) server Work nodes 13 nodes (25 core KISTI Supercomputer Storage processes) 15 TBytes (NFS) (Sun Blade 6048 Cluster system) 300 TBytes (dcache) 13

49 한국물리학회 ~24 광주김대중컨벤션센터 CDF Grid at KISTI 정민호, 조기현 *, 김현우, 김동희 1, 양유철 1, 서준석 1, 공대정 1, 김지은 1, 장성현 1, 칸아딜 1, 김수봉 2, 이재승 2, 이영장 2, 문창성 2, 정지은 2, 유인태 3, 임규빈 3, 주경광 4, 김현수 5, 오영도 6, 전은주 7 KISTI 응용연구개발팀. 1경북대물리및에너지학부. 2서울대물리학부. 3성균관대물리학과. 4전남대물리학과. 5전북대물리학과. 6포항공대물리학과. 7세종대물리학과. * Corresponding author October 24, 2008 KISTI Contents 1. e-science for High-Energy Physics 2. CDF Farms around world 3. Progress of CDF Farms 4. Grid CAF 5. The Comparison of Grid CAF 6. Pacific CAF at KISTI 7. Monitoring of Pacific CAF 8. The Reason of exploiting GRID on CDF 9. CDF Grid Computing Center (CGCC) 10. Summary

50 1. e-science for High-Energy Physics Three components of e-hep Data publication Data processing Data production EVO (Enabling Virtual Organization) CDF Farm Remote Control Room 3 2. CDF Farms around world CAF (2001) DCAF (2003) Grid CAF (2006) CGCC (2008) Toronto CAF Lyon CAF Korean CAF : KISTI, KNU European CAF Pacific UCSD CAF Rut CAF BCN CAF CNAF CAF Japan CAF Taiwan AS North American CAF CAF KNU Tsukuba U KISTI ASGC, Taiwan 4

51 3. Progress of CDF Farms Name Starting Date Grid middleware Job scheduling Content Site CAF Condor Cluster farm inside Fermilab USA (Fermilab( Fermilab) DCAF Condor Cluster farm outside Fermilab Korea, Japan, Taiwan, Spain (Varcelona( Varcelona, Cantabria), USA (Rutgers, San Diego), Canada, France Grid CAF 2006 LCG/OSG Resource Broker, Condor Grid farm North America CAF European CAF Pacific CAF CGCC (CDF Grid Computing Center) 2008 LCG Resource Broker, Condor Big Grid farm Korea (KISTI) France (IN2p3) Italy (CNAF) 5 4. Grid CAF Context Diagram of Grid CAF Grid Farm (European CAF) Grid Farm (North America CAF) CAF GUI User Interface Grid Farm (Pacific CAF) Grid Site (IPAS_OSG) Grid Site (KR-KISTI-HEP) Grid Site (Taiwan-LCG2 ) Grid Site (JP-TSUKUBA) Grid Site (IPAS_CS) Legend Grid CAF Boundary Grid Pool Grid Site Boundary Service Component Job Transport 6

52 5. The comparison of Grid CAF Grid CAF Head node Work node Grid Middleware Method VO (Virtual Organization) North America CAF Fermilab (USA) USSD (USA) etc OSG Condor over Globus CDF VO European CAF CNAF (Italia) IN2P3 (France) Etc LCG WMS (Workload Management System) CDF VO Pacific CAF AS (Taiwan) KISTI (Korea) etc LCG, OSG Condor over Globus CDF VO 7 6. Pacific CAF at KISTI (1) VOMS Grid Farm (Pacific CAF) Authentication User Interface CafGui CafSubmit CafMon Job Submission Web monitoring CAF Head Node Collector Submitter Negotiator Condor Monitor Schedd Glideins Globus Grid Site (KR-KISTI-HEP) Work Node (hep003) (hep004) Worker Node (hep015) CE (hep001)... Job Output dcache dcache Pool (se-hep) Legend Grid CAF Boundary Grid Pool Grid Site Boundary Service Component Repository Job Data Transportation Control Data Transportation 8

53 6. Pacific CAF at KISTI (2) Current hardware allocation status of KR-KISTI-HEP Head node paccaf.phys.sinica.edu.tw at Academia Sinica (Taiwan) VOMS server voms.cnaf.infn.it at CNAF (Italy) Work nodes 25 core processes Storage at KISTI 30 T byte 9 7. Monitoring of Pacific CAF (1) 10

54 7. Monitoring of Pacific CAF (2) The reason of exploiting GRID on CDF Donatella Lucchesi (December 11, 2007) e-science 07 12

55 9. CDF Grid Computing Center (CGCC) A hardware allocation plan for CGCC Head node VOMS server Work nodes Storage Pacific CAF at KISTI paccaf.phys.sinica.edu.tw voms.cnaf.infn.it 25 core processes 30 T byte CGCC at KISTI New Head node New VOMS server 400 core processes 300 T byte Summary High-energy physics is a good application of e-science. The e-science for high-energy physics has three components: data production, data processing and data analysis The system for data processing for CDF experiments is embedded at KISTI. CGCC (CDF Grid Computing Center) is being built at KISTI. 14

56 References Kihyeon Cho (KISTI), e-science for High-Energy Physics in Korea, JKPS, Vol. 53, N0. 2, August 2008, pp. 1187~1191 Igor Sfiligoi, CDF computing, Computer Physics Communications 177 (2007) 235~238 Gabriele Compostella, Donatella Lucchesi, Simone Pagan Griso, Igor Sfiligoi, CDF Monte Carlo Production on LCG GRID via LcgCAF, 3 rd IEEE International Conference on e-science and Grid Computing, December 10~13, 2007 Kihyeon Cho (KISTI), CDF 그리드현재및발전방향, KISTI HEP Seminar, January 30, 2008 Kihyeon Cho (KISTI), CDF Grid - DCAF (Decentralized CDF Analysis Farm), KISTI HEP Seminar, March 8,

57 The Data Processing of e-science for High Energy Physics Minho Jeung, Hyunwoo Kim, Kihyeon Cho*, Okhwan Byun (KISTI) September 8, * Corresponding author Contents 1. e-science for High-Energy Physics 2. CDF Farms around world 3. Progress of CDF Grid 4. Grid CAF 5. Pacific CAF at KISTI 6. CDF Grid Computing Center (CGCC) 7. The CDF has to exploit GRID 8. Conclusion 2

58 1. e-science for High-Energy Physics Three components Data production Data process CDF Farm Data analysis 3 2. CDF Farms around world CAF DCAF Grid CAF CGCC (2001) (2003) (2006) (2008) Toronto CAF Lyon CAF Korean CAF : KISTI, KNU KISTI KNU Tsukuba U UCSD CAF Rut CAF BCN CAF CNAF CAF Japan CAF Taiwan AS ASGC, Taiwan North American CAF European CAF Pacific CAF 4

59 3. Progress of CDF Grid Name Starting Date Grid middle Job scheduling Content Site CAF Condor Cluster farm inside Fermilab USA (Fermilab) DCAF Condor Cluster farm outside Fermilab Korea, Japan, Taiwan, Spain (Varcelona, Cantabria), USA (Rutgers, San Diego), Canada, France Grid CAF 2006 LCG/OSG Resource Broker + Condor Grid farm North America CAF European CAF Pacific CAF CGCC (CDF Grid Computing Center) 2008 (Plan) LCG Resource Broker + Condor Big Grid farm Korea (KISTI) France (IN2p3) Italy (CNAF) 5 4. Grid CAF Context Diagram of Grid CAF Grid Farm (European CAF) Grid Farm (North America CAF) Grid Farm (Pacific CAF) User Interface CAF Head Node Grid Site (IPAS_OSG) Grid Site (Taiwan-LCG2 ) Grid Site (KR-KISTI-HEP) Grid Site (JP-TSUKUBA-U-03) Grid Site (IPAS_CS) Legend Data Transport Grid CAF Boundary Grid Pool Grid Site Boundary CAF Service Component 6

60 5. Pacific CAF at KISTI (1) Communicating processes view of the KR-KISTI-HEP system Grid Farm (Pacific CAF) VOMS User Interface CafGui CafSubmit CafMon Job Submission Web monitor Authentication CAF Head Node Collector Submitter Negotiator Monitor Schedd Glide-ins Globus Grid Site (KR-KISTI-HEP) Worker Node (hep003) (hep004) Worker Node (hep015) Computing Element (hep001) Job Output dcache Pool (se-hep) dcache Legend Grid CAF Boundary Grid Pool Grid Site Boundary CAF Service Component Grid Service Component Repository 7 5. Pacific CAF at KISTI (2) Hardware allocation status of KR-KISTI-HEP Head node paccaf.phys.sinica.edu.tw Head node at Academia Sinica (Taiwan) VOMS server voms.cnaf.infn.it VOMS server at CNAF (Italy) Work nodes 13 nodes - 25 core processes 9 Desktop Computers : Pentium4, 512 M byte memory, 60 G byte HDD 4 Servers: Quad core, 8 G byte memory, 500 G byte HDD Storage at KISTI 15 T byte (dcache) 8

61 6. CDF Grid Computing Center (CGCC) A hardware allocation plan for CGCC Head node Pacific CAF at KISTI paccaf.phys.sinica.edu.tw CGCC at KISTI New Head node VOMS server Work nodes Storage voms.cnaf.infn.it 13 nodes - 25 core processes 15 T byte New VOMS server Super computer - tachyon (Sun Blade 6048 Cluster system) 300 T byte 9 7. The CDF has to exploit GRID 10 Donatella Lucchesi (December 11, 2007) e-science 07

62 8. Conclusion High-energy physics is a good application of e-science. The e-science for high-energy physics has three components: data production, data processing and data analysis The system for data processing is embedded at KISTI. CGCC (CDF Grid Computing Center) will be built at KISTI. 11 References Kihyeon Cho (KISTI), e-science for High-Energy Physics in Korea, JKPS, Vol. 53, N0. 2, August 2008, pp. 1187~1191 Igor Sfiligoi, CDF computing, Computer Physics Communications 177 (2007) 235~238 Gabriele Compostella, Donatella Lucchesi, Simone Pagan Griso, Igor Sfiligoi, CDF Monte Carlo Production on LCG GRID via LcgCAF, 3 rd IEEE International Conference on e-science and Grid Computing, December 10~13, 2007 Kihyeon Cho (KISTI), CDF 그리드현재및발전방향, KISTI HEP Seminar, January 30, 2008 Kihyeon Cho (KISTI), CDF Grid - DCAF (Decentralized CDF Analysis Farm), KISTI HEP Seminar, March 8,

63 The current status of CDF Grid 정민호, 김현우, 조기현, 김동희 1, 양유철 1, 서준석 1, 공대정 1, 김지은 1, 장성현 1, 아메드사비르미안 1, 칸아딜 1, 아즈말모하메드 1, 김수봉 2, 이재승 2, 김현수 2, 전은주 2, 이영장 2, 문창성 2, 유인태 3, 임규빈 3, 주경광 4, 오영도 5 KISTI, 응용연구개발팀. 1 경북대, 물리및에너지학부. 2 서울대, 물리학부. 3 성균관대, 물리학과. 4 전남대, 물리학과. 5 포항공대, 물리학과. April 18, 2008 Contents 1. CDF Grid Farms around world 2. KISTI Current status: Pacific CAF 3. KISTI Plan 1: CGCC 4. CGCC Schematic 5. KISTI Plan 2: CDF 독자적 VO 구축 6. Current VO Status (2007) 7. Future CDF VO 2008 and after 2

64 Toronto CAF 1. CDF Grid Farms around world CAF DCAF Grid Farm CGCC (2001) (2003) (2006) (2008) Lyon CAF Korean CAF : KISTI, KNU KISTI KNU Tsukuba U UCSD CAF Rut CAF BCN CAF CNAF CAF Japan CAF Taiwan AS ASGC, Taiwan North American CAF European CAF Pacific CAF 3 2. KISTI Current status: Pacific CAF Headnode Academia Sinica (Taiwan) Worknodes Venus 30 node CDF job 을받지않도록막혀있음 ( 많은양의 CDF job 으로인하여 ALICE Tier2 센터가동에지장을주지않기위한목적 ) Pacific CAF 의 Work nodes 구성을위한 CE,WN 설치작업중 Pacific CAF 와연동하여독자 CDF job 수행목표현재 PC 클러스터와새로도입한리눅스머신을이용하여구축작업중 PC 클러스터 11 대 : Pentium4, 512 M byte memory, 60 G byte HDD 리눅스머신 4대 : Quad core, 8 G byte memory, 500 G byte HDD 이후, 슈퍼컴 4 호기 (SUN Cluster) 에 CE, WN 설치예정 CDF UI 구축중 UI 로사용하던경북대 cluster52 machine 2008년 1월부터정지 KISTI 에새로운 UI (cdfkisti.kisti.re.kr) machine 설치중 국내 CDF 연구자들이사용할수있게할예정 (5월중) Fermi CDF 에있는fcdflnx4.fnal.gov 와동일한기능을제공예정 4

65 3. KISTI Plan 1: CGCC 대용량저장장치연구 Hardware Quad core, 16G byte memory, 270 G byte HDD 현재사용중 15 T byte NAS 시스템도입예정 Software DPM, dcache, SRM 연동연구 5 4. CGCC Schematic lcg job (HEP) => UI glite job (non-hep) VOMS lcg-rb WMS+LB lcg-ce (LRMS) hep001 hep003 슈퍼컴 4 호기 VOBOX R-GMA DGAS glite-ce hep011 PX BDII Computational Resources CDF LFC SE-classic Storage Pool File Server (6TByte) SAM Station FTS KISTI, KNU 6

66 5. KISTI Plan 2: CDF 독자적 VO 구축 Both Pacific CAF and CGCC CDF 독립 VO 현재 ALICE VO를빌려사용중 CDF 독립 VO 구축 대만 TsanLung Hsieh 와공동연구 이탈리아의 CDF VOMS 를사용 ( 향후 CGCC 구축시 KISTI 에 VOMS 설치예정 7 6. Current VO Status (2007) Pacific CAF ALICE VO CDF VO Bio VO LCG Tier2 (ALICE Tier2) Center Venus 40 nodes 8