[개발] 그리드센터 SGE 환경 구축하기
SgGun Grid Engine 5.3 – 6.x 대 설치 및 이용하기
작성일 : 2006년 3월 3일
작성자 : 시스존/서진우 (alang@syszone.co.kr)
1. Sun Grid Engine(SGE) 이란
Sun Grid Engine 소프트웨어는 여러노드의 분산된 컴퓨팅 자원을 사용자 입장에서
자원 요청 시 효율적으로 자원을 분배 시켜 주는 역활의 프로그램이다.
흔히 OpenPBS, PBSPro, LSF 와 같은 Job 스케줄러와 같은 역활의 프로그램이다.
sge 는 sun open source project에서 공개로 제공하는 소프트웨어이지만 같은
공개인 open pbs 에 비해 보다 안정적이며, 많은 기능을 제공하고, 사용자 편이
에 가까운 프로그램이라 할 수 있다.
기본적으로 OpenPBS에서 제공하는 시스템 자원 분배 기능과 작업 대기열 기능을
기본 제공하며, 상용 프로그램에서 제공하는 보다 세부적인 컴플렉스 정의 및
라이센스 제어, 병렬 프로그램 제어등의 기능을 제공하고 있다.
흔히 EDA,ASIC 관련 연구 분야에 많이 사용되는 Synopsys 와 같은 프로그램에서
디자인 모듈 컴파일등에서 분산 컴파일이 가능함으로 작업 처리 능력을 향상시
킬 수 있는 방안으로 사용되며, 고가의 라이센스로 작동하는 프로그램의 경우
프로그램 별 라이센스 수로 자원 정의를 한 후 라이센스 관리를 하는 역활로도
사용이 가능하다.
본 테스트는 리눅스 커널 2.4.x 와 2.6.x에서 테스트 되었고, Solaris 8에서도
테스트가 완료되었다.
현재 제공되는 5.3 대 버전과 6.x 대 버전에 대한 테스트가 완료되었고일반적인
사용방법은 동일 하나 병렬 분산 make 등의 기능에서 6.x 대의 방식이 보다 더
안정함을 확인 할 수 있어 설치 이외의 다른 사용 방법에 대한것은 6.x대을 기준
으로 설명 하도록 할 것이다.
SGE 설치에 앞서 기본적인 rsh, rlogin 서비스 설정은 해두도록 한다.
2. Sun Grid Engine 설치 하기
SGE 소프트웨어 다운로드는 http://gridengine.sunsource.net 사이트에서 가능
하며 현재 5.3 대 버전과 6.0대 버전이 제공 되고 있다.
설치 가능한 플랫폼은 Linux Kernel 2.4.x ~ 2.6.x(x86/amd64) 와 Solaris 7.8.9
(32bit/64bit) 버전대에서 가능하며 각 플랫폼별로 실행 바이너리 패키지와 설정
관련 common 패키지로 제공 되고 있으며 두개의 패키지 모두를 다운 받아야 한다.
– sge 5.3 설치 하기
필요 패키지 리스트 :
sge-5.3p7-bin-glinux.tar.gz
sge-5.3p7-common.tar.gz
SGE 는 SGE를 관리할 root 이외의 관리자 계정이 필요하기 때문에 먼저 SGE관리자
계정을 만들도록 한다.
[root@ora01 ~]# adduser sgeadmin
[root@ora01 ~]# passwd sgeadmin
SGE 가 설치될 디렉토리를 생성하도록 한다.
[root@ora01 ~]# mkdir -p /usr/clx/sge
[root@ora01 ~]# chown sgeadmin. /usr/clx/sge
[root@ora01 ~]# chmod 755 /usr/clx/sge
/etc/services 에 sge 가 서로 통신을 할 수 있게 해당 포트와 서비스 명을 정의 한다.
[root@ora01 ~]# vi /etc/services
—————————————————————————
.
sge_commd 535/tcp
.
—————————————————————————
sge-5.3p7-common.tar.gz / sge-5.3p7-bin-glinux.tar.gz 두개의 패키지를 /usr/clx/sge
에 옮겨 놓고 압축을 푼다.
[root@ora01 ~]# mv sge-5.3p7-bin-glinux.tar.gz /usr/clx/sge
[root@ora01 ~]# mv sge-5.3p7-common.tar.gz /usr/clx/sge
[root@ora01 ~]# cd /usr/clx/sge/
[root@ora01 sge]# tar xzvf sge-5.3p7-common.tar.gz
[root@ora01 sge]# tar xzvf sge-5.3p7-bin-glinux.tar.gz
administrator 서버 (관리서버)에서는install_qmaster 실행 파일을, 일반 제출 서버에서는
install_execd 파일을 실행 한다.
[root@ora01 sge]# ./install_qmaster
—————————————————————————-
설치 진행 과정 : 대부분 defaults 설정으로 [enter]를 쳐서 넘어가면 된고, 특정 설정이
필요한 곳은 아래 진행과정 중간에 첨부된 설명에 맞게 진행하도록 한다.
Welcome to the Grid Engine installation
—————————————
Grid Engine qmaster host installation
————————————-
Before you continue with the installation please read these hints:
– Your terminal window should have a size of at least
80×24 characters
– The INTR character is often bound to the key Ctrl-C.
The term >Ctrl-C< is used during the installation if you
have the possibility to abort the installation
The qmaster installation procedure will take approximately 5-10 minutes.
Hit <RETURN> to continue >> <—[ Enter ]
Confirm Grid Engine default installation settings
————————————————-
The following default settings can be used for an accelerated
installation procedure:
$SGE_ROOT = /usr/clx/sge
service = sge_commd
admin user account = sgeadmin
Do you want to use these configuration parameters (y/n) [y] >>
Verifying and setting file permissions
————————————–
Did you install this version with >pkgadd< or did you already
verify and set the file permissions of your distribution (y/n) [y] >>
We do not verify file permissions. Hit <RETURN> to continue >>
Making directories
——————
creating directory: default
creating directory: default/common
creating directory: default/common/history
creating directory: default/common/local_conf
creating directory: /usr/clx/sge/default/spool/qmaster
creating directory: /usr/clx/sge/default/spool/qmaster/admin_hosts
creating directory: /usr/clx/sge/default/spool/qmaster/ckpt
creating directory: /usr/clx/sge/default/spool/qmaster/complexes
creating directory: /usr/clx/sge/default/spool/qmaster/exec_hosts
creating directory: /usr/clx/sge/default/spool/qmaster/job_scripts
creating directory: /usr/clx/sge/default/spool/qmaster/jobs
creating directory: /usr/clx/sge/default/spool/qmaster/pe
creating directory: /usr/clx/sge/default/spool/qmaster/queues
creating directory: /usr/clx/sge/default/spool/qmaster/submit_hosts
creating directory: /usr/clx/sge/default/spool/qmaster/usersets
Hit <RETURN> to continue >>
Select default Grid Engine hostname resolving method
—————————————————-
Are all hosts of your cluster in one DNS domain? If this is
the case the hostnames
>hostA< and >hostA.foo.com<
would be treated as equal, because the DNS domain name >foo.com<
is ignored when comparing hostnames.
Are all hosts of your cluster in a single DNS domain (y/n) [y] >>
Ignoring domainname when comparing hostnames.
Hit <RETURN> to continue >>
Grid Engine group id range
————————–
When jobs are started under the control of Grid Engine an additional group id
is set on platforms which do not support jobs.
This additional UNIX group id range must be unused group id’s in your system.
The range must be big enough to provide enough numbers for the maximum number
of Grid Engine jobs running at a single moment on a single host. E.g. a range
like >20000-20100< means, that Grid Engine will use the group id’s from
20000-20100 and thus provides a range for 101 jobs running at the same time
on a single host.
You can change at any time the group id range in your cluster configuration.
Please enter a range >> 20000-20200 <– 20000-20200 입력
이는 sge에서 job을 관리한때 job gid 를 부여하게 되는데 동시에 부여할수 있는
gid 의 범위와 개수이다. 즉 동시에 큐잉에 job을 대기 시킬 수 있는 작업 수라
보면 되겠다.
Using >20000-20200< as gid range. Hit <RETURN> to continue >>
Creating local configuration
—————————-
Creating >act_qmaster< file
Adding default complexes >host< and >queue<
Adding default parallel environment (PE) for >qmake<
Adding >sge_aliases< path aliases file
Adding >qtask< qtcsh sample default request file
Adding >sge_request< default submit options file
Creating settings files for >.profile/.cshrc<
Hit <RETURN> to continue >>
Grid Engine startup script
————————–
Your Grid Engine cluster wide startup script is installed as:
/usr/clx/sge/default/common/rcsge<
Hit <RETURN> to continue >>
Grid Engine startup script
————————–
We can install the startup script that
Grid Engine is started at machine boot (y/n) [y] >>
Installing startup script /etc/rc.d/rc3.d/S95rcsge
Installing startup script also in /etc/rc.d/rc5.d/S95rcsge
Hit <RETURN> to continue >>
Grid Engine qmaster and scheduler startup
—————————————–
Starting qmaster and scheduler daemon. Please wait …
starting sge_qmaster
starting program: /usr/clx/sge/bin/glinux/sge_commd
using service “sge_commd”
bound to port 535
Reading in complexes:
Complex “host”.
Complex “queue”.
Reading in parallel environments:
PE “make”.
Reading in scheduler configuration
starting sge_schedd
Hit <RETURN> to continue >>
Adding Grid Engine hosts
————————
Please now add the list of hosts, where you will later install your execution
daemons. These hosts will be also added as valid submit hosts.
Please enter a blank separated list of your execution hosts. You may
press <RETURN> if the line is getting too long. Once you are finished
simply press <RETURN> without entering a name.
You also may prepare a file with the hostnames of the machines where you plan
to install Grid Engine. This may be convenient if you are installing Grid
Engine on many hosts.
Do you want to use a file which contains the list of hosts (y/n) [n] >>
<- 이는 sge 의 제출 서버에 포함된 서버 리스트를 정의 하는 곳이다. 만일 제출서버
의 호스트네임리스트가 정의된 파일이 있으면 “y”, 없이 직접 입력 하기 위해서는
그냥 [enter]를 입력한다.
Adding admin and submit hosts
—————————–
Please enter a blank seperated list of hosts.
Stop by entering <RETURN>. You may repeat this step until you are
entering an empty list. You will see messages from Grid Engine
when the hosts are added.
Host(s): ora01 < – 해당 호스트 네임 입력
Adding admin and submit hosts
—————————–
Please enter a blank seperated list of hosts.
Stop by entering <RETURN>. You may repeat this step until you are
entering an empty list. You will see messages from Grid Engine
when the hosts are added.
Host(s): ora02 < – 해당 호스트 네임 입력
ora02 added to administrative host list
ora02 added to submit host list
Hit <RETURN> to continue >>
.
Finished adding hosts. Hit <RETURN> to continue >>
Using Grid Engine
—————–
You should now enter the command:
source /usr/clx/sge/default/common/settings.csh
if you are a csh/tcsh user or
# . /usr/clx/sge/default/common/settings.sh
if you are a sh/ksh user.
This will set or expand the following environment variables:
– $SGE_ROOT (always necessary)
– $SGE_CELL (if you are using a cell other than >default<)
– $COMMD_PORT (if you haven’t added the service >sge_commd<)
– $PATH/$path (to find the Grid Engine binaries)
– $MANPATH (to access the manual pages)
Hit <RETURN> to see where Grid Engine logs messages >>
<- SGE 기본 환경 설정 파일이다. 설치가 완료 후 ..
/usr/clx/sge/default/common/settings.sh 을 적용한 후 해당 파일을 /etc/profile.d
밑에 복사해 두도록 한다.
Grid Engine messages
——————–
Grid Engine messages can be found at:
/tmp/qmaster_messages (during qmaster startup)
/tmp/execd_messages (during execution daemon startup)
After startup the daemons log thier messages in their spool directories.
Qmaster: /usr/clx/sge/default/spool/qmaster/messages
Exec daemon: <execd_spool_dir>/<hostname>/messages
Do you want to see previous screen about using Grid Engine again (y/n) [n] >>
Your Grid Engine qmaster installation is now completed
——————————————————
Please now login to all hosts where you want to run an execution daemon
and start the execution host installation procedure.
If you want to run an execution daemon on this host, please do not forget
to make the execution host installation in this host as well.
All execution hosts must be administrative hosts during the installation.
All hosts which you added to the list of administrative hosts during this
installation procedure can now be installed.
You may verify your administrative hosts with the command
# qconf -sh
and you may add new administrative hosts with the command
# qconf -ah <hostname>
—————————————————————————————-
이것으로 SGE 의 master 서버 설치가 완료 되었다.
일반 job 실행 서버 설치는 ./install_execd 를 실행하도록 한다.
[root@ora01 sge]# ./install_execd
—————————————————————————————-
Welcome to the Grid Engine execution host installation
——————————————————
If you haven’t installed the Grid Engine qmaster host yet, you must execute
this step (with >install_qmaster<) prior the execution host installation.
For a sucessfull installation you need a running Grid Engine qmaster. It is
also neccesary that this host is an administrative host.
You can verify your current list of administrative hosts with
the command:
# qconf -sh
You can add an administrative host with the command:
# qconf -ah <hostname>
The execution host installation will take approximately 5 minutes.
Hit <RETURN> to continue >>
Confirm Grid Engine default installation settings
————————————————-
The following default settings can be used for an accelerated
installation procedure:
$SGE_ROOT = /usr/clx/sge
service = sge_commd
admin user account = sgeadmin
Do you want to use these configuration parameters (y/n) [y] >>
Creating local configuration
—————————-
Creating local configuration for host >ora01<
root@ora01 modified “ora01” in configuration list
Local configuration for host >ora01< created.
Hit <RETURN> to continue >>
Grid Engine startup script
————————–
We can install the startup script that
Grid Engine is started at machine boot (y/n) [y] >>
Grid Engine startup script
————————–
We can install the startup script that
Grid Engine is started at machine boot (y/n) [y] >>
Installing startup script /etc/rc.d/rc3.d/S95rcsge
Installing startup script also in /etc/rc.d/rc5.d/S95rcsge
Hit <RETURN> to continue >>
Grid Engine execution daemon startup
————————————
Starting execution daemon daemon. Please wait …
starting sge_execd
Hit <RETURN> to continue >>
Adding a default Grid Engine queue for this host
————————————————
We can now add a sample queue for this host with following attributes:
– the queue has the name >ora01.q<
– the queue provides 2 slot(s) for jobs
– the queue provides access for any user with an account on this machine
– the queue has no Unix resource limits
You do not need to add a queue now, but before running jobs on this host
need to add a queue with >qconf< or the GUI >qmon<.
Do you want to add a default queue for this host (y/n) [y] >>
root@ora01 added “ora01.q” to queue list
Hit <RETURN> to continue >>
Using Grid Engine
—————–
You should now enter the command:
source /usr/clx/sge/default/common/settings.csh
if you are a csh/tcsh user or
# . /usr/clx/sge/default/common/settings.sh
if you are a sh/ksh user.
This will set or expand the following environment variables:
– $SGE_ROOT (always necessary)
– $SGE_CELL (if you are using a cell other than >default<)
– $COMMD_PORT (if you haven’t added the service >sge_commd<)
– $PATH/$path (to find the Grid Engine binaries)
– $MANPATH (to access the manual pages)
Hit <RETURN> to see where Grid Engine logs messages >>
Grid Engine messages
——————–
Grid Engine messages can be found at:
/tmp/qmaster_messages (during qmaster startup)
/tmp/execd_messages (during execution daemon startup)
After startup the daemons log thier messages in their spool directories.
Qmaster: /usr/clx/sge/default/spool/qmaster/messages
Exec daemon: <execd_spool_dir>/<hostname>/messages
Do you want to see previous screen about using Grid Engine again (y/n) [n] >>
———————————————————————————–
이것으로 실행 서버의 설치가 완료되었다. 실행 서버는 SGE 클러스터 구성의 모든 서버
에서 진행해도록 한다. 설치가 완료되면 간단한 테스트를 해보도록 한다.
* 제출 호스트 확인
[root@ora01 sge]# qconf -ss
ora01
ora02
* 관리 호스트 확인
[root@ora01 sge]# qconf -sh
ora01
ora02
* 큐 등록 확인
[root@ora01 sge]# qstat -f
queuename qtype used/tot. load_avg arch states
—————————————————————————-
ora01.q BIP 0/2 0.00 glinux
—————————————————————————-
ora02.q BIP 0/2 0.00 glinux
참고로 SGE 가 NFS상에 설치 되지 않은 경우 qmaster 가 설치 되지 않는 호스트에서 execd
를 설치 하면 ..
Checking cell directory
———————–
Cannot find required files. The following error was returned:
>common directory not found: default/common<
와 같은 메세지를 보이면서 진행이 중단 된다.
이때는 qmaster 서버가 설치 된 노드에서 /usr/clx/sge/default 이하 폴더를 execd 가 설치
될 노드에 모두 복제를 시킨 후 진행하도록 한다.
[root@ora01 sge]# ensync default
[root@ora02 sge]# ./install_execd
..
설치 가 완료되면 위에서 언급 했듯이 default/common/settings.sh 파일을 /etc/profile.d
밑에 복사하도록 한다.
[root@ora01 sge]# cp default/common/settings.sh /etc/profile.d
[root@ora02 sge]# cp default/common/settings.sh /etc/profile.d
SGE 실행 제어 스크립터는 다음과 같다.
[root@ora01 sge]# /etc/rc.d/init.d/rcsge start | stop | restart
– sge 6.x 설치 하기
sge 6.0 대 설치는 5.3 대와 다소 차이가 있다. 설치 진행 과정에서의 차이는 크게 없지만
설치 준비에서 /etc/services 의 등록 시 서비스네임이 변경된 부분이 존재 한다.
* 필요 패키지 리스트
sge-6.0u7_1-bin-lx24-x86.tar.gz
sge-6.0u7-common.tar.gz
sge 관리 계정과 설치 디렉토리 관련 준비 과정은 5.3대와 동일 하다.
[root@ora01 ~]# adduser sgeadmin
[root@ora01 ~]# passwd sgeadmin
[root@ora01 ~]# mkdir -p /usr/clx/sge
[root@ora01 ~]# chown sgeadmin. /usr/clx/sge
[root@ora01 ~]# chmod 755 /usr/clx/sge
/etc/services 에서는 5.3 에서는 sge_commd 를 등록 했는데 6.0 대에서는 sge_qmaster,
sge_execd 로 정의 해야 한다.
[root@ora01 sge]# vi /etc/services
——————————————————————————-
.
sge_qmaster 536/tcp
sge_execd 537/tcp
.
——————————————————————————-
압축을 푼다.
[root@ora01 sge]# tar xzvf sge-6.0u7-common.tar.gz
[root@ora01 sge]# tar xzvf sge-6.0u7_1-bin-lx24-x86.tar.gz
설치 전 SGE_ROOT에 대한 환경 설정을 적용한다.
[root@ora01 sge]# export SGE_ROOT=/usr/clx/sge
master 서버에서는 qmaster 서버 설치 스크립터를, 실행 서버에서는 execd 서버 설치
스크립터를 실행한다.
[root@ora01 sge]# ./install_qmaster
——————————————————————————–
Welcome to the Grid Engine installation
—————————————
Grid Engine qmaster host installation
————————————-
Before you continue with the installation please read these hints:
– Your terminal window should have a size of at least
80×24 characters
– The INTR character is often bound to the key Ctrl-C.
The term >Ctrl-C< is used during the installation if you
have the possibility to abort the installation
The qmaster installation procedure will take approximately 5-10 minutes.
Hit <RETURN> to continue >>
Grid Engine admin user account
——————————
The current directory
/usr/clx/sge
is owned by user
sgeadmin
If user >root< does not have write permissions in this directory on *all*
of the machines where Grid Engine will be installed (NFS partitions not
exported for user >root< with read/write permissions) it is recommended to
install Grid Engine that all spool files will be created under the user id
of user >clunix<.
IMPORTANT NOTE: The daemons still have to be started by user >root<.
Do you want to install Grid Engine as admin user >sgeadmin< (y/n) [y] >>
Installing Grid Engine as admin user >sgeadmin<
Hit <RETURN> to continue >>
Checking $SGE_ROOT directory
—————————-
The Grid Engine root directory is:
$SGE_ROOT = /usr/clx/sge
If this directory is not correct (e.g. it may contain an automounter
prefix) enter the correct path to this directory or hit <RETURN>
to use default [/usr/clx/sge] >>
Hit <RETURN> to continue >>
Grid Engine TCP/IP service >sge_qmaster<
—————————————-
Using the service
sge_qmaster
for communication with Grid Engine.
Hit <RETURN> to continue >>
Grid Engine cells
—————–
Grid Engine supports multiple cells.
If you are not planning to run multiple Grid Engine clusters or if you don’t
know yet what is a Grid Engine cell it is safe to keep the default cell name
default
If you want to install multiple cells you can enter a cell name now.
The environment variable
$SGE_CELL=<your_cell_name>
will be set for all further Grid Engine commands.
Enter cell name [default] >>
Using cell >default<.
Hit <RETURN> to continue >>
Grid Engine qmaster spool directory
———————————–
The qmaster spool directory is the place where the qmaster daemon stores
the configuration and the state of the queuing system.
The admin user >clunix< must have read/write access
to the qmaster spool directory.
If you will install shadow master hosts or if you want to be able to start
the qmaster daemon on other hosts (see the corresponding section in the
Grid Engine Installation and Administration Manual for details) the account
on the shadow master hosts also needs read/write access to this directory.
The following directory
[/usr/clx/sge/default/spool/qmaster]
will be used as qmaster spool directory by default!
Do you want to select another qmaster spool directory (y/n) [n] >>
Windows Execution Host Support
——————————
Are you going to install Windows Execution Hosts? (y/n) [n] >>
Verifying and setting file permissions
————————————–
Did you install this version with >pkgadd< or did you already
verify and set the file permissions of your distribution (y/n) [y] >>
We do not verify file permissions. Hit <RETURN> to continue >>
Select default Grid Engine hostname resolving method
—————————————————-
Are all hosts of your cluster in one DNS domain? If this is
the case the hostnames
>hostA< and >hostA.foo.com<
would be treated as equal, because the DNS domain name >foo.com<
is ignored when comparing hostnames.
Are all hosts of your cluster in a single DNS domain (y/n) [y] >>
Ignoring domainname when comparing hostnames.
Hit <RETURN> to continue >>
Making directories
——————
creating directory: default
creating directory: default/common
creating directory: /usr/clx/sge/default/spool/qmaster
creating directory: /usr/clx/sge/default/spool/qmaster/job_scripts
Hit <RETURN> to continue >>
Setup spooling
————–
Your SGE binaries are compiled to link the spooling libraries
during runtime (dynamically). So you can choose between Berkeley DB
spooling and Classic spooling method.
Please choose a spooling method (berkeleydb|classic) [berkeleydb] >>
The Berkeley DB spooling method provides two configurations!
Local spooling:
The Berkeley DB spools into a local directory on this host (qmaster host)
This setup is faster, but you can’t setup a shadow master host
Berkeley DB Spooling Server:
If you want to setup a shadow master host, you need to use
Berkeley DB Spooling Server!
In this case you have to choose a host with a configured RPC service.
The qmaster host connects via RPC to the Berkeley DB. This setup is more
failsafe, but results in a clear potential security hole. RPC communication
(as used by Berkeley DB) can be easily compromised. Please only use this
alternative if your site is secure or if you are not concerned about
security. Check the installation guide for further advice on how to achieve
failsafety without compromising security.
Do you want to use a Berkeley DB Spooling Server? (y/n) [n] >>
Hit <RETURN> to continue >>
Berkeley Database spooling parameters
————————————-
Please enter the Database Directory now, even if you want to spool locally,
it is necessary to enter this Database Directory.
Default: [/usr/clx/sge/default/spool/spooldb] >>
creating directory: /usr/clx/sge/default/spool/spooldb
Dumping bootstrapping information
Initializing spooling database
Hit <RETURN> to continue >>
Grid Engine group id range
————————–
When jobs are started under the control of Grid Engine an additional group id
is set on platforms which do not support jobs. This is done to provide maximum
control for Grid Engine jobs.
This additional UNIX group id range must be unused group id’s in your system.
Each job will be assigned a unique id during the time it is running.
Therefore you need to provide a range of id’s which will be assigned
dynamically for jobs.
The range must be big enough to provide enough numbers for the maximum number
of Grid Engine jobs running at a single moment on a single host. E.g. a range
like >20000-20100< means, that Grid Engine will use the group ids from
20000-20100 and provides a range for 100 Grid Engine jobs at the same time
on a single host.
You can change at any time the group id range in your cluster configuration.
Please enter a range >> 20000-20200
Using >20000-20200< as gid range. Hit <RETURN> to continue >>
Grid Engine cluster configuration
———————————
Please give the basic configuration parameters of your Grid Engine
installation:
<execd_spool_dir>
The pathname of the spool directory of the execution hosts. User >clunix<
must have the right to create this directory and to write into it.
Default: [/usr/clx/sge/default/spool] >>
Grid Engine cluster configuration (continued)
———————————————
<administrator_mail>
The email address of the administrator to whom problem reports are sent.
It’s is recommended to configure this parameter. You may use >none<
if you do not wish to receive administrator mail.
Please enter an email address in the form >user@foo.com<.
Default: [none] >>
The following parameters for the cluster configuration were configured:
execd_spool_dir /usr/clx/sge/default/spool
administrator_mail none
Do you want to change the configuration parameters (y/n) [n] >>
Creating local configuration
—————————-
Creating >act_qmaster< file
Adding default complex attributes
Reading in complex attributes.
Adding default parallel environments (PE)
Reading in parallel environments:
PE “make.sge_pqs_api”.
Adding SGE default usersets
Reading in usersets:
Userset “defaultdepartment”.
Userset “deadlineusers”.
Adding >sge_aliases< path aliases file
Adding >qtask< qtcsh sample default request file
Adding >sge_request< default submit options file
Creating >sgemaster< script
Creating >sgeexecd< script
Creating settings files for >.profile/.cshrc<
Hit <RETURN> to continue >>
qmaster/scheduler startup script
——————————–
We can install the startup script that will
start qmaster/scheduler at machine boot (y/n) [y] >>
cp /usr/clx/sge/default/common/sgemaster /etc/init.d/sgemaster
/usr/lib/lsb/install_initd /etc/init.d/sgemaster
Hit <RETURN> to continue >>
Grid Engine qmaster and scheduler startup
—————————————–
Starting qmaster and scheduler daemon. Please wait …
starting sge_qmaster
starting sge_schedd
Hit <RETURN> to continue >>
Adding Grid Engine hosts
————————
Please now add the list of hosts, where you will later install your execution
daemons. These hosts will be also added as valid submit hosts.
Please enter a blank separated list of your execution hosts. You may
press <RETURN> if the line is getting too long. Once you are finished
simply press <RETURN> without entering a name.
You also may prepare a file with the hostnames of the machines where you plan
to install Grid Engine. This may be convenient if you are installing Grid
Engine on many hosts.
Do you want to use a file which contains the list of hosts (y/n) [n] >>
Adding admin and submit hosts
—————————–
Please enter a blank seperated list of hosts.
Stop by entering <RETURN>. You may repeat this step until you are
entering an empty list. You will see messages from Grid Engine
when the hosts are added.
Host(s): ora01
adminhost “ora01” already exists
ora01 added to submit host list
Hit <RETURN> to continue >>
Adding admin and submit hosts
—————————–
Please enter a blank seperated list of hosts.
Stop by entering <RETURN>. You may repeat this step until you are
entering an empty list. You will see messages from Grid Engine
when the hosts are added.
Host(s): ora02
ora02 added to administrative host list
ora02 added to submit host list
Hit <RETURN> to continue >>
Finished adding hosts. Hit <RETURN> to continue >>
If you want to use a shadow host, it is recommended to add this host
to the list of administrative hosts.
If you are not sure, it is also possible to add or remove hosts after the
installation with <qconf -ah hostname> for adding and <qconf -dh hostname>
for removing this host
Attention: This is not the shadow host installationprocedure.
You still have to install the shadow host separately
Do you want to add your shadow host(s) now? (y/n) [y] >>
Adding Grid Engine shadow hosts
——————————-
Please now add the list of hosts, where you will later install your shadow
daemon.
Please enter a blank separated list of your execution hosts. You may
press <RETURN> if the line is getting too long. Once you are finished
simply press <RETURN> without entering a name.
You also may prepare a file with the hostnames of the machines where you plan
to install Grid Engine. This may be convenient if you are installing Grid
Engine on many hosts.
Do you want to use a file which contains the list of hosts (y/n) [n] >>
Adding admin hosts
——————
Please enter a blank seperated list of hosts.
Stop by entering <RETURN>. You may repeat this step until you are
entering an empty list. You will see messages from Grid Engine
when the hosts are added.
Host(s): ora01
Creating the default <all.q> queue and <allhosts> hostgroup
———————————————————–
root@ora01 added “@allhosts” to host group list
root@ora01 added “all.q” to cluster queue list
Hit <RETURN> to continue >>
Scheduler Tuning
—————-
The details on the different options are described in the manual.
Configurations
————–
1) Normal
Fixed interval scheduling, report scheduling information,
actual + assumed load
2) High
Fixed interval scheduling, report limited scheduling information,
actual load
3) Max
Immediate Scheduling, report no scheduling information,
actual load
Enter the number of your prefered configuration and hit <RETURN>!
Default configuration is [1] >>
We’re configuring the scheduler with >Normal< settings!
Do you agree? (y/n) [y] >>
Using Grid Engine
—————–
You should now enter the command:
source /usr/clx/sge/default/common/settings.csh
if you are a csh/tcsh user or
# . /usr/clx/sge/default/common/settings.sh
if you are a sh/ksh user.
This will set or expand the following environment variables:
– $SGE_ROOT (always necessary)
– $SGE_CELL (if you are using a cell other than >default<)
– $SGE_QMASTER_PORT (if you haven’t added the service >sge_qmaster<)
– $SGE_EXECD_PORT (if you haven’t added the service >sge_execd<)
– $PATH/$path (to find the Grid Engine binaries)
– $MANPATH (to access the manual pages)
Hit <RETURN> to see where Grid Engine logs messages >>
Grid Engine messages
——————–
Grid Engine messages can be found at:
/tmp/qmaster_messages (during qmaster startup)
/tmp/execd_messages (during execution daemon startup)
After startup the daemons log their messages in their spool directories.
Qmaster: /usr/clx/sge/default/spool/qmaster/messages
Exec daemon: <execd_spool_dir>/<hostname>/messages
Grid Engine startup scripts
—————————
Grid Engine startup scripts can be found at:
/usr/clx/sge/default/common/sgemaster (qmaster and scheduler)
/usr/clx/sge/default/common/sgeexecd (execd)
Do you want to see previous screen about using Grid Engine again (y/n) [n] >>
Your Grid Engine qmaster installation is now completed
——————————————————
Please now login to all hosts where you want to run an execution daemon
and start the execution host installation procedure.
If you want to run an execution daemon on this host, please do not forget
to make the execution host installation in this host as well.
All execution hosts must be administrative hosts during the installation.
All hosts which you added to the list of administrative hosts during this
installation procedure can now be installed.
You may verify your administrative hosts with the command
# qconf -sh
and you may add new administrative hosts with the command
# qconf -ah <hostname>
Please hit <RETURN> >>
————————————————————————————-
설치가 완료되었다. SGE 환경 설정 파일을 /etc/profile.d 밑에 복사하고 적용한다.
[root@ora01 sge]# cp default/common/settings.sh /etc/profile.d/
[root@ora01 sge]# source /etc/profile.d/settings.sh
간단한 확인을 한다.
[root@ora01 sge]# qconf -sh
ora01
ora02
[root@ora01 sge]# qconf -ss
ora01
ora02
이제 실행 호스트 프로그램을 설치 하고 설정 한다.
[root@ora01 sge]# ./install_execd
————————————————————————————-
Welcome to the Grid Engine execution host installation
——————————————————
If you haven’t installed the Grid Engine qmaster host yet, you must execute
this step (with >install_qmaster<) prior the execution host installation.
For a sucessfull installation you need a running Grid Engine qmaster. It is
also neccesary that this host is an administrative host.
You can verify your current list of administrative hosts with
the command:
# qconf -sh
You can add an administrative host with the command:
# qconf -ah <hostname>
The execution host installation will take approximately 5 minutes.
Hit <RETURN> to continue >>
Checking $SGE_ROOT directory
—————————-
The Grid Engine root directory is:
$SGE_ROOT = /usr/clx/sge
If this directory is not correct (e.g. it may contain an automounter
prefix) enter the correct path to this directory or hit <RETURN>
to use default [/usr/clx/sge] >>
Your $SGE_ROOT directory: /usr/clx/sge
Hit <RETURN> to continue >>
Grid Engine cells
—————–
Please enter cell name which you used for the qmaster
installation or press <RETURN> to use [default] >>
Using cell: >default<
Hit <RETURN> to continue >>
Checking hostname resolving
—————————
This hostname is known at qmaster as an administrative host.
Hit <RETURN> to continue >>
Local execd spool directory configuration
—————————————–
During the qmaster installation you’ve already entered a global
execd spool directory. This is used, if no local spool directory is configured.
Now you can enter a local spool directory for this host.
Do you want to configure a local spool directory
for this host (y/n) [n] >>
Creating local configuration
—————————-
clunix@ora01 modified “ora01” in configuration list
Local configuration for host >ora01< created.
Hit <RETURN> to continue >>
execd startup script
——————–
We can install the startup script that will
start execd at machine boot (y/n) [y] >>
cp /usr/clx/sge/default/common/sgeexecd /etc/init.d/sgeexecd
/usr/lib/lsb/install_initd /etc/init.d/sgeexecd
Hit <RETURN> to continue >>
Grid Engine execution daemon startup
————————————
Starting execution daemon. Please wait …
starting sge_execd
Hit <RETURN> to continue >>
Adding a queue for this host
—————————-
We can now add a queue instance for this host:
– it is added to the >allhosts< hostgroup
– the queue provides 2 slot(s) for jobs in all queues
referencing the >allhosts< hostgroup
You do not need to add this host now, but before running jobs on this host
it must be added to at least one queue.
Do you want to add a default queue instance for this host (y/n) [y] >>
root@ora01 modified “@allhosts” in host group list
root@ora01 modified “all.q” in cluster queue list
Hit <RETURN> to continue >>
Using Grid Engine
—————–
You should now enter the command:
source /usr/clx/sge/default/common/settings.csh
if you are a csh/tcsh user or
# . /usr/clx/sge/default/common/settings.sh
if you are a sh/ksh user.
This will set or expand the following environment variables:
– $SGE_ROOT (always necessary)
– $SGE_CELL (if you are using a cell other than >default<)
– $SGE_QMASTER_PORT (if you haven’t added the service >sge_qmaster<)
– $SGE_EXECD_PORT (if you haven’t added the service >sge_execd<)
– $PATH/$path (to find the Grid Engine binaries)
– $MANPATH (to access the manual pages)
Hit <RETURN> to see where Grid Engine logs messages >>
Grid Engine messages
——————–
Grid Engine messages can be found at:
/tmp/qmaster_messages (during qmaster startup)
/tmp/execd_messages (during execution daemon startup)
After startup the daemons log their messages in their spool directories.
Qmaster: /usr/clx/sge/default/spool/qmaster/messages
Exec daemon: <execd_spool_dir>/<hostname>/messages
Grid Engine startup scripts
—————————
Grid Engine startup scripts can be found at:
/usr/clx/sge/default/common/sgemaster (qmaster and scheduler)
/usr/clx/sge/default/common/sgeexecd (execd)
Do you want to see previous screen about using Grid Engine again (y/n) [n] >>
Your execution daemon installation is now completed.
———————————————————————————-
5.3 대와 같이 NFS 상에 SGE 가 설치되는 경우가 아니라면 다른 노드에는 qmaster 서버의
default 디렉토리를 복제해 준뒤 install_execd 를 실행해서 설치 하도록 한다.
[root@ora01 sge]# ensync default
[root@ora02 sge]# ./install_execd
.
.
모든 실행 호스트에 프로그램 설치가 완료 되면 전체 호스트가 재대로 등록 되었는지 확인한다.
[root@ora01 sge]# qstat -f
queuename qtype used/tot. load_avg arch states
—————————————————————————-
all.q@ora01 BIP 0/2 0.00 lx24-x86
—————————————————————————-
all.q@ora02 BIP 0/2 0.00 lx24-x86
이것으로 SGE 의 설치 관련 설명을 마치도록 하겠다. 다음에는 SGE의 사용 시 필요한 주요
명령어 설명 및 사용방법에 대해 알아보도록 한다.
3. Sun Grid Engine Command 사용 하기
SGE의 가장 기본적인 용도는 역시 PBS 와 같은 작업 큐잉을 통한 배치작업 관리 부분이다.
이는 다른 큐잉 시스템과 같이 qsub 란 명령을 통해 관리가 가능한다.
PBS 의 경우는 작업을 대기열에 제출하기 위해 PBS 전용 스크립터를 제작해야 하는데 SGE
은 일반적인 sh, csh 스크립터를 바로 적용 시킬 수 있다.
아래에서는 qsub 와 같은 sge 의 사용자 명령어와 SGE 시스템의 구성을 제어하는 관리자
명령어에 대해 알아보도록 한다.
– 주요 사용자 Command
– qsub :
작업을 SGE 에 제출 할때 사용되는 명령어 이다. 사용방법은 아래와 같다.
ex> qsub <submit scripts>
[root@ora01 sge]# qsub examples/jobs/simple.sh
Your job 1 (“simple.sh”) has been submitted.
* 작업 제출 확인
[root@ora01 sge]# qstat -f
queuename qtype used/tot. load_avg arch states
—————————————————————————-
all.q@ora01 BIP 1/2 0.00 lx24-x86
1 0.55500 simple.sh root r 03/03/2006 13:18:01 1
—————————————————————————-
all.q@ora02 BIP 2/2 0.00 lx24-x86
2 0.55500 simple.sh root r 03/03/2006 13:18:01 1
3 0.55500 simple.sh root r 03/03/2006 13:18:01 1
– qmod :
qmod 는 작업 대겨열을 제어 하는 명령이다. 특정 대기열에서 동작하는 모든 작업
을 제어할 수 있다.
참고로 대겨열은 qstat -f 로 확인 가능하다. all.q@ora01,all.q@ora02 이 모두 대기열
에 해당한다.
ex > qmod <option> 대기열
qmod -s 대기열 이름 : 해당 대기열의 작업을 일시 중단한다.
qmod -us 대기열 이름 : 중단된 대기열 상태를 해제한다.
qmod -d 대기열 이름 : 해당 대기열에 모든 실행 권한을 중단한다.
qmod -e 대기열 이름 : 중단된 실행 권한을 해제한다.
qmod -c 대기열 이름 : 작업 중 E 가 발생하여 holding 된 대기열의 상태를 정상으로복구한다.
– qacct :
SGE 사용 리소스에 대한 회계 정보를 보여 주는 명령어 이다.
qdel :
제출된 job 을 대기열에서 제거하는 명령이다.
[root@ora01 sge]# qstat
job-ID prior name user state submit/start at queue slots ja-task-ID
—————————————————————————————————————–
16 0.55500 simple.sh root r 03/03/2006 13:29:46 all.q@ora01 1
18 0.55500 simple.sh root r 03/03/2006 13:29:46 all.q@ora01 1
15 0.55500 simple.sh root r 03/03/2006 13:29:46 all.q@ora02 1
17 0.55500 simple.sh root r 03/03/2006 13:29:46 all.q@ora02 1
19 0.55500 simple.sh root qw 03/03/2006 13:29:44 1
20 0.55500 simple.sh root qw 03/03/2006 13:29:44 1
21 0.55500 simple.sh root qw 03/03/2006 13:29:45 1
22 0.55500 simple.sh root qw 03/03/2006 13:29:45 1
23 0.55500 simple.sh root qw 03/03/2006 13:29:45 1
24 0.55500 simple.sh root qw 03/03/2006 13:29:45 1
25 0.00000 simple.sh root qw 03/03/2006 13:29:46 1
[root@ora01 sge]# qdel 25
root has deleted job 25
[root@ora01 sge]# qstat
job-ID prior name user state submit/start at queue slots ja-task-ID
—————————————————————————————————————–
16 0.55500 simple.sh root r 03/03/2006 13:29:46 all.q@ora01 1
18 0.55500 simple.sh root r 03/03/2006 13:29:46 all.q@ora01 1
15 0.55500 simple.sh root r 03/03/2006 13:29:46 all.q@ora02 1
17 0.55500 simple.sh root r 03/03/2006 13:29:46 all.q@ora02 1
19 0.55500 simple.sh root qw 03/03/2006 13:29:44 1
20 0.55500 simple.sh root qw 03/03/2006 13:29:44 1
21 0.55500 simple.sh root qw 03/03/2006 13:29:45 1
22 0.55500 simple.sh root qw 03/03/2006 13:29:45 1
23 0.55500 simple.sh root qw 03/03/2006 13:29:45 1
24 0.55500 simple.sh root qw 03/03/2006 13:29:45 1
[root@ora01 sge]# qdel -u root
// root 사용자로 실행 된 모든 job 이 큐잉에서 제거 된다.
– qhold :
큐잉을 구성하는 SGE상의 대기열에서 사용자/관리자/시스템/작업등의 요소를 큐잉 시스템에서
배재 시키는 명령어이다. qhold 에서 holding 된 리소스는 SGE 에서 작업을 실행 모드로 제출
하지 않고 대기 시키게 된다.
ex> qhold < -u 사용자 -o 운영자 -s 호스트 > 작업ID
[root@ora01 sge]# qstat
job-ID prior name user state submit/start at queue slots ja-task-ID
—————————————————————————————————————–
27 0.55500 simple.sh root r 03/03/2006 13:32:01 all.q@ora01 1
29 0.55500 simple.sh root r 03/03/2006 13:32:01 all.q@ora01 1
26 0.55500 simple.sh root r 03/03/2006 13:32:01 all.q@ora02 1
28 0.55500 simple.sh root r 03/03/2006 13:32:01 all.q@ora02 1
30 0.55500 simple.sh root qw 03/03/2006 13:31:58 1
31 0.55500 simple.sh root qw 03/03/2006 13:31:59 1
32 0.55500 simple.sh root qw 03/03/2006 13:31:59 1
33 0.55500 simple.sh root qw 03/03/2006 13:31:59 1
34 0.55500 simple.sh root qw 03/03/2006 13:31:59 1
35 0.55500 simple.sh root qw 03/03/2006 13:31:59 1
36 0.55500 simple.sh root qw 03/03/2006 13:31:59 1
37 0.55500 simple.sh root qw 03/03/2006 13:32:00 1
38 0.55500 simple.sh root qw 03/03/2006 13:32:00 1
39 0.55500 simple.sh root qw 03/03/2006 13:32:00 1
[root@ora01 sge]# qhold 39
modified hold of job 39
[root@ora01 sge]# qstat
job-ID prior name user state submit/start at queue slots ja-task-ID
—————————————————————————————————————–
27 0.55500 simple.sh root r 03/03/2006 13:32:01 all.q@ora01 1
29 0.55500 simple.sh root r 03/03/2006 13:32:01 all.q@ora01 1
26 0.55500 simple.sh root r 03/03/2006 13:32:01 all.q@ora02 1
28 0.55500 simple.sh root r 03/03/2006 13:32:01 all.q@ora02 1
30 0.55500 simple.sh root qw 03/03/2006 13:31:58 1
31 0.55500 simple.sh root qw 03/03/2006 13:31:59 1
32 0.55500 simple.sh root qw 03/03/2006 13:31:59 1
33 0.55500 simple.sh root qw 03/03/2006 13:31:59 1
34 0.55500 simple.sh root qw 03/03/2006 13:31:59 1
35 0.55500 simple.sh root qw 03/03/2006 13:31:59 1
36 0.55500 simple.sh root qw 03/03/2006 13:31:59 1
37 0.55500 simple.sh root qw 03/03/2006 13:32:00 1
38 0.55500 simple.sh root qw 03/03/2006 13:32:00 1
39 0.55500 simple.sh root hqw 03/03/2006 13:32:00 1
[root@ora01 sge]# qhold -u root
modified hold of job 40
modified hold of job 41
modified hold of job 42
modified hold of job 43
modified hold of job 44
modified hold of job 45
modified hold of job 46
modified hold of job 47
modified hold of job 48
[root@ora01 sge]# qstat
job-ID prior name user state submit/start at queue slots ja-task-ID
—————————————————————————————————————–
40 0.55500 simple.sh root hr 03/03/2006 13:38:16 all.q@ora01 1
41 0.55500 simple.sh root hr 03/03/2006 13:38:16 all.q@ora02 1
42 0.55500 simple.sh root hr 03/03/2006 13:38:16 all.q@ora02 1
39 0.00000 simple.sh root hqw 03/03/2006 13:32:00 1
43 0.00000 simple.sh root hqw 03/03/2006 13:38:16 1
44 0.00000 simple.sh root hqw 03/03/2006 13:38:16 1
45 0.00000 simple.sh root hqw 03/03/2006 13:38:16 1
46 0.00000 simple.sh root hqw 03/03/2006 13:38:16 1
47 0.00000 simple.sh root hqw 03/03/2006 13:38:16 1
qhold로 holding 한 작업은 qrls 혹은 qalter 로 해재 할 수 있다.
– qhost :
SGE 시스템의 큐잉 시스템을 구성하는 호스트에 대한 리소스 상태를 보여주는 명령어 이다.
ex> qhost -u <사용자> -h <호스트>
[root@ora01 sge]# qhost
HOSTNAME ARCH NCPU LOAD MEMTOT MEMUSE SWAPTO SWAPUS
——————————————————————————-
global – – – – – – –
ora01 lx24-x86 2 0.01 2.0G 165.2M 4.0G 0.0
ora02 lx24-x86 2 0.00 2.0G 142.0M 4.0G 160.0K
[root@ora01 sge]# qhost -h ora01
HOSTNAME ARCH NCPU LOAD MEMTOT MEMUSE SWAPTO SWAPUS
——————————————————————————-
global – – – – – – –
ora01 lx24-x86 2 0.00 2.0G 164.3M 4.0G 0.0
[root@ora01 sge]# qhost -u root
HOSTNAME ARCH NCPU LOAD MEMTOT MEMUSE SWAPTO SWAPUS
——————————————————————————-
global – – – – – – –
ora01 lx24-x86 2 0.00 2.0G 164.3M 4.0G 0.0
ora02 lx24-x86 2 0.00 2.0G 141.3M 4.0G 160.0K
-qrls :
qhost 로 holding 된 자원의 상태를 풀어 주는 명령어 이다.
[root@ora01 sge]# qstat
job-ID prior name user state submit/start at queue slots ja-task-ID
—————————————————————————————————————–
43 0.00000 simple.sh root hqw 03/03/2006 13:38:16 1
44 0.00000 simple.sh root hqw 03/03/2006 13:38:16 1
45 0.00000 simple.sh root hqw 03/03/2006 13:38:16 1
46 0.00000 simple.sh root hqw 03/03/2006 13:38:16 1
47 0.00000 simple.sh root hqw 03/03/2006 13:38:16 1
48 0.00000 simple.sh root hqw 03/03/2006 13:38:17 1
49 0.00000 simple.sh root hqw 03/03/2006 13:38:17 1
[root@ora01 sge]# qrls 43
modified hold of job 43
[root@ora01 sge]# qstat
job-ID prior name user state submit/start at queue slots ja-task-ID
—————————————————————————————————————–
43 0.00000 simple.sh root qw 03/03/2006 13:38:16 1
44 0.00000 simple.sh root hqw 03/03/2006 13:38:16 1
45 0.00000 simple.sh root hqw 03/03/2006 13:38:16 1
46 0.00000 simple.sh root hqw 03/03/2006 13:38:16 1
47 0.00000 simple.sh root hqw 03/03/2006 13:38:16 1
48 0.00000 simple.sh root hqw 03/03/2006 13:38:17 1
49 0.00000 simple.sh root hqw 03/03/2006 13:38:17 1
– qconf :
SGE 의 구성을 제어하는 기본 관리 명령어 이다. qconf를 통해 sge 구성 요소들을 확인, 추가, 삭제
할수 있다.
[root@ora01 sge]# qconf -sconf // sge 시스템 설정 구성 정보
global:
execd_spool_dir /usr/clx/sge/default/spool
mailer /bin/mail
xterm /usr/bin/X11/xterm
load_sensor none
prolog none
epilog none
shell_start_mode posix_compliant
login_shells sh,ksh,csh,tcsh
min_uid 0
min_gid 0
user_lists none
xuser_lists none
projects none
xprojects none
enforce_project false
enforce_user auto
load_report_time 00:00:40
max_unheard 00:05:00
reschedule_unknown 00:00:00
loglevel log_warning
administrator_mail none
set_token_cmd none
pag_cmd none
token_extend_time none
shepherd_cmd none
qmaster_params none
execd_params none
reporting_params accounting=true reporting=false \\
flush_time=00:00:15 joblog=false sharelog=00:00:00
finished_jobs 100
gid_range 20000-20200
qlogin_command telnet
qlogin_daemon /usr/sbin/in.telnetd
rlogin_daemon /usr/sbin/in.rlogind
max_aj_instances 2000
max_aj_tasks 75000
max_u_jobs 0
max_jobs 0
auto_user_oticket 0
auto_user_fshare 0
auto_user_default_project none
auto_user_delete_time 86400
delegated_file_staging false
reprioritize 0
[root@ora01 sge]# qconf -sh /// adminitrative host 리스트 확인
[root@ora01 sge]# qconf -ah <hostname> /// adminitrative host 추가 하기
[root@ora01 sge]# qconf -dh <hostname> /// adminitrative host 삭제 하기
[root@ora01 sge]# qconf -ss /// submit host 리스트 확인
[root@ora01 sge]# qconf -as <hostname> /// submit host 리스트 추가
[root@ora01 sge]# qconf -ds <hostname> /// submit host 리스트 삭제
[root@ora01 sge]# qconf -se <hostname> /// 실행 호스트의 세부 목록 확인
[root@ora01 sge]# qconf -se ora01
hostname ora01
load_scaling NONE
complex_values NONE
load_values load_avg=0.020000,load_short=0.000000, \\
load_medium=0.020000,load_long=0.000000,arch=lx24-x86, \\
num_proc=2,mem_free=1862.238281M,swap_free=4094.621094M, \\
virtual_free=5956.859375M,mem_total=2026.257812M, \\
swap_total=4094.621094M,virtual_total=6120.878906M, \\
mem_used=164.019531M,swap_used=0.000000M, \\
virtual_used=164.019531M,cpu=0.200000, \\
np_load_avg=0.010000,np_load_short=0.000000, \\
np_load_medium=0.010000,np_load_long=0.000000
processors 2
user_lists NONE
xuser_lists NONE
projects NONE
xprojects NONE
usage_scaling NONE
report_variables NONE
[root@ora01 sge]# qconf -sc /// 요청 가능한 콤플렉스 속성 확인
#name shortcut type relop requestable consumable default urgency
#—————————————————————————————-
arch a RESTRING == YES NO NONE 0
calendar c RESTRING == YES NO NONE 0
cpu cpu DOUBLE >= YES NO 0 0
h_core h_core MEMORY <= YES NO 0 0
h_cpu h_cpu TIME <= YES NO 0:0:0 0
h_data h_data MEMORY <= YES NO 0 0
h_fsize h_fsize MEMORY <= YES NO 0 0
h_rss h_rss MEMORY <= YES NO 0 0
h_rt h_rt TIME <= YES NO 0:0:0 0
h_stack h_stack MEMORY <= YES NO 0 0
h_vmem h_vmem MEMORY <= YES NO 0 0
hostname h HOST == YES NO NONE 0
load_avg la DOUBLE >= NO NO 0 0
load_long ll DOUBLE >= NO NO 0 0
load_medium lm DOUBLE >= NO NO 0 0
load_short ls DOUBLE >= NO NO 0 0
mem_free mf MEMORY <= YES NO 0 0
mem_total mt MEMORY <= YES NO 0 0
mem_used mu MEMORY >= YES NO 0 0
min_cpu_interval mci TIME <= NO NO 0:0:0 0
np_load_avg nla DOUBLE >= NO NO 0 0
np_load_long nll DOUBLE >= NO NO 0 0
np_load_medium nlm DOUBLE >= NO NO 0 0
np_load_short nls DOUBLE >= NO NO 0 0
num_proc p INT == YES NO 0 0
qname q RESTRING == YES NO NONE 0
rerun re BOOL == NO NO 0 0
s_core s_core MEMORY <= YES NO 0 0
s_cpu s_cpu TIME <= YES NO 0:0:0 0
s_data s_data MEMORY <= YES NO 0 0
s_fsize s_fsize MEMORY <= YES NO 0 0
s_rss s_rss MEMORY <= YES NO 0 0
s_rt s_rt TIME <= YES NO 0:0:0 0
s_stack s_stack MEMORY <= YES NO 0 0
s_vmem s_vmem MEMORY <= YES NO 0 0
seq_no seq INT == NO NO 0 0
slots s INT <= YES YES 1 1000
swap_free sf MEMORY <= YES NO 0 0
swap_rate sr MEMORY >= YES NO 0 0
swap_rsvd srsv MEMORY >= YES NO 0 0
swap_total st MEMORY <= YES NO 0 0
swap_used su MEMORY >= YES NO 0 0
tmpdir tmp RESTRING == NO NO NONE 0
virtual_free vf MEMORY <= YES NO 0 0
virtual_total vt MEMORY <= YES NO 0 0
virtual_used vu MEMORY >= YES NO 0 0
– qstat :
SGE 상에 대기열 상태 확인
[root@ora01 sge]# qstat -f
queuename qtype used/tot. load_avg arch states
—————————————————————————-
all.q@ora01 BIP 2/2 0.02 lx24-x86
45 0.55500 simple.sh root r 03/03/2006 13:57:16 1
47 0.55500 simple.sh root r 03/03/2006 13:57:16 1
—————————————————————————-
all.q@ora02 BIP 2/2 0.00 lx24-x86
44 0.55500 simple.sh root r 03/03/2006 13:57:16 1
46 0.55500 simple.sh root r 03/03/2006 13:57:16 1
############################################################################
– PENDING JOBS – PENDING JOBS – PENDING JOBS – PENDING JOBS – PENDING JOBS
############################################################################
48 0.55500 simple.sh root qw 03/03/2006 13:38:17 1
49 0.55500 simple.sh root qw 03/03/2006 13:38:17 1
– qmon :
SGE GUI 명령어이다. qmon 을 실행하면 GUI 상에서 시스템 관리 부터 작업 제출까지 모든것이
가능하다.
– qrsh :
대화형 작업 제출 시 사용하는 명령이다.
[root@ora01 sge]# qrsh
Last login: Fri Mar 3 10:08:02 from 192.168.123.2
[root@ora02 ~]# qrsh
Last login: Fri Mar 3 10:09:05 from 192.168.123.2
[root@ora01 ~]# qstat
job-ID prior name user state submit/start at queue slots ja-task-ID
—————————————————————————————————————–
51 0.55500 QRLOGIN root r 03/03/2006 13:58:51 all.q@ora01 1
50 0.55500 QRLOGIN root r 03/03/2006 13:58:48 all.q@ora02 1
[root@ora01 ~]# qrsh uname -a
Linux ora02 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:32:14 EDT 2005 i686 i686 i386 GNU/Linux
4. Sun Grid Engine UI (qmon) 이용하기
qmon 명령어로 Grid Engine Gui를 실행 하도록 한다.
SGE GUI를 이용하면 복잡한 command 와 option을 사용하지 않아도 쉽게 SGE 정책을
재구성하거나 Job 상태를 관리 할 수 있다.
5. Sung Grid Engine 의 Parallel distributed make (qmake) 적용하기
SGE 에는 qmake 라는 parallal distributed make 명령어가 존재 한다.
이 명령어를 이용하여 Makefile을 통한 Compiling 작업을 여러 노드로 분산해서 동시에
처리가 가능하다. 이 기능을 이용하면 EDA 계열의 회로 디자인 모듈 설계 프로그램계열에서
모듈을 분산해서 컴파일링 하는 작업등에 효율적으로 이용이 가능하다.
단 이는 컴파일 대상 데이터가 모두 NFS 상에 존재해야 한다.
간단한 테스트를 해보도록 하자.
[root@n001 sgeadmin]# tar xzvf php-5.1.2.tar.gz
[root@n001 sgeadmin]# cd php-5.1.2
[root@n001 php-5.1.2]# ./configure
[root@n001 php-5.1.2]# qmake -cwd -v PATH -l arch=lx24-x86 — -j 24
—————————————————————————————–
dynamic mode
/bin/sh /home/sgeadmin/php-5.1.2/libtool –silent –preserve-dup-deps –mode=compile gcc -Iext/ctype/ -I/home/sgeadmin/php-5.1.2/ext/ctype/ -DPHP_ATOM_INC -I/home/sgeadmin/php-5.1.2/include -I/home/sgeadmin/php-5.1.2/main -I/home/sgeadmin/php-5.1.2 -I/usr/include/libxml2 -I/home/sgeadmin/php-5.1.2/ext/date/lib -I/home/sgeadmin/php-5.1.2/TSRM -I/home/sgeadmin/php-5.1.2/Zend -I/usr/include -g -O2 -c /home/sgeadmin/php-5.1.2/ext/ctype/ctype.c -o ext/ctype/ctype.lo
—————————————————————————————–
Compile 진행 중에 다른 노드에서 qstat -f 로 상태를 확인해 보자
[root@n001 php-5.1.2]# qstat -f
—————————————————————————————–
queuename qtype used/tot. load_avg arch states
—————————————————————————-
all.q@n001 BIP 3/8 0.35 lx24-x86
2865 0.55500 sh root r 03/03/2006 14:04:58 1
2876 0.55500 sh root r 03/03/2006 14:04:58 1
2877 0.55500 sh root r 03/03/2006 14:04:58 1
—————————————————————————-
all.q@n002 BIP 6/8 0.11 lx24-x86
2807 0.55500 qmake root r 03/03/2006 14:03:58 1
2868 0.55500 sh root r 03/03/2006 14:04:58 1
2875 0.55500 sh root r 03/03/2006 14:04:58 1
2878 0.55500 sh root r 03/03/2006 14:04:58 1
2880 0.55500 sh root r 03/03/2006 14:04:58 1
2881 0.55500 sh root r 03/03/2006 14:04:58 1
—————————————————————————-
all.q@n003 BIP 4/8 0.12 lx24-x86
2866 0.55500 sh root r 03/03/2006 14:04:58 1
2873 0.55500 sh root r 03/03/2006 14:04:58 1
2879 0.55500 sh root r 03/03/2006 14:04:58 1
2882 0.55500 sh root r 03/03/2006 14:04:58 1
############################################################################
– PENDING JOBS – PENDING JOBS – PENDING JOBS – PENDING JOBS – PENDING JOBS
############################################################################
2883 0.55500 sh root qw 03/03/2006 14:04:46 1
2884 0.55500 sh root qw 03/03/2006 14:04:46 1
2885 0.55500 sh root qw 03/03/2006 14:04:46 1
2886 0.55500 sh root qw 03/03/2006 14:04:46 1
2887 0.55500 sh root qw 03/03/2006 14:04:46 1
2888 0.55500 sh root qw 03/03/2006 14:04:46 1
2889 0.00000 sh root qw 03/03/2006 14:04:59 1
2890 0.00000 sh root qw 03/03/2006 14:04:59 1
2891 0.00000 sh root qw 03/03/2006 14:04:59 1
2892 0.00000 sh root qw 03/03/2006 14:05:00 1
2893 0.00000 sh root qw 03/03/2006 14:05:00 1
2894 0.00000 sh root qw 03/03/2006 14:05:00 1
2895 0.00000 sh root qw 03/03/2006 14:05:00 1
2896 0.00000 sh root qw 03/03/2006 14:05:00 1
2897 0.00000 sh root qw 03/03/2006 14:05:00 1
2898 0.00000 sh root qw 03/03/2006 14:05:00 1
——————————————————————————————
그럼 위와 같이 Makefile 상에 나열된 Compiling batch 작업을 SGE 시스템에서 허용할 수
있는 작업 수 만큼 대기열에 대기 시켰다가 각 노드별로 작업을 분산 시켜 compiling 을
하게 한다.
주의 ) qmake 의 경우 모든 Compiling 작업에서 효과를 볼 수 있는 것은 아니다.
실제 개별 Object Compile 의 작업 크기가 작은 경우는 오히려 SGE 큐에 아주 작은 개별
작업을 등록해서 큐잉 시스템의 정책에 의해 재 분배 되어 처리 된다고 하면 오히려
단일 노드의 프로세스에서 쉬지 않고 순차적으로 처리하는것 보다 SGE 상에서 큐잉 제어
하는 시간이 더 많이 걸릴 수도 있다. qmake 가 효율적으로 이용가능한 경우는 하나의
object 의 compiling 시간이 아주 긴 경우 (1분이상)에는 단일 노드에서는 매 obj 마다
1분씩 소요되면서 순차적으로 처리하는데 qmake 를 이용하면 수십노드에서 수십개의 obj
를 동시에 compiling 하기 때문에 전체 작업 시간을 단축 시킬 수 있을 것이다.
qmake 사용 시 “-cwd -v PATH -l arch=lx24-x86 –” 같은 옵션을 붙여 주는데 이는 병렬
컴파일로 작업을 진행 할때 사용되는 옵션이다.
“qmake -cwd -v PATH -l arch=lx24-x86 –” 뒤에 일반 GNU make 의 옵션을 붙여 사용하면
병렬로 컴파일링이 가능하다.
만일 Synopsys와 같이 Application을 구동하기 위해 별도의 환경 설정이 필요한 경우엔
사용자의 bashrc 에 환경 설정을 적용해도 분산 환경에서 -cmd -v PATH 만으로는 환경
설정 까지 위임 시키지 않으므로 문제가 발생할 수 있다. 이때는 qmake 에 -V 옵션을
추가 함으로 해결이 가능하다.
Synopsys Compile 시 qmake 사용 옵션
“qmake -V -cwd -v PATH -l arch=lx24-x86 — -f pass0/Makefile -j 16”
이밖에 Synopsys의 경우 초기 db 데이터를 로딩해서 로딩된 db파일을 재 구성하게 되는데
이때 NFS방식에서 많은 노드가 동시에 초기 db를 로딩함으로 해서 일부 로딩이 정상적으로
완료되지 않은 상태에서 Synopsys가 다음 단계로 넘어감으로 해서 문제가 발생 할 수 있다.
이때는 dc_shell-t 초기 로딩 시 약간의 time gap 를 추가하여 문제를 해결 할 수 있다.
6. SGE 의 Complex 관리 기능을 이용한 라이센스 관리 하기
1. SGE를 통한 License Management 기능 이용하기
SGE 의 Complex 기능을 이용하면 사용자가 작업의 속성을 정의하고 이 속성의 활성
유무를 통해 SGE 큐에서 전체 시스템에서 사용자 속성에 해당하는 작업의 수를 큐
에서 관리 할 수가 있다.
이는 고가의 라이센스를 취득해야 사용이 가능한 어플리케이션의 라이센스를 관리
하는데 유용하게 사용할 수 있다.예를 들면..
작업을 실행 할 수 있는 시스템의 수는 10대이고 Synopsys라는 프로그램의 동시
사용 가능 라이센스 수는 5개이다.
Synopsys의 경우 별도의 라이센스 서버가 있어 10대의 작업 서버에서 Synopsys
프로그램이 구동이 되면 라이센스 서버에서 1개의 라이센스가 발급되고 실행된
Synopsys의 작동이 완료되면 1개의 라이센스를 반납하게 된다.
만일 Synopsys를 사용해야 하는 사용자 수가 30명이면 이 중 5명의 사용자가 먼저
Synopsys를 사용하면 뒤에 Synopsys를 실행하는 사용자는 라이센스가 없다하여
사용이 금지될 것이다.
그럼 30명의 사용자는 서로가 서로에게 어플리케이션을 현재 사용하는지를 수동으로
체크해야 하고 서로가 순서를 정해 작업을 해야 하는 번거로움이 생긴다.
이런 문제를 SGE의 라이센스 관리기능을 이용하면 사용자는 평소와 같이 Synopsys
실행을 SGE의 큐에 등록하는 방식으로 실행하고 SGE에서 Synopsys 속성을 추가하여
동시에 5개의 실행 권한을 주면 SGE를 통해 실행한 Synopsys는 SGE에서 동시에 5개
씩 사용이 가능토록 관리를 해주게 된다.
설정 방법은 단순하다.
SGE의 관리 서버 중 하나로 접속하여 관리 UI인 qmon 을 실행한다. 그런후..
[Complex Configuration] 메뉴를 선택한다.
상위에 Attributes 추가 폼에
——————————————————————————-
Name Shortcut Type Relation Requestable Consumable Default Urgency
——————————————————————————-
[Synopsys] [sp] [INT] [<=] [YES] [YES] [0] [0]
——————————————————————————-
와 같이 입력 하고 [Add] 버턴을 누른다. 그런 후 [Commit] 버턴을 눌려서 설정을
적용한다.
그런후 [Host Configuration] 메뉴를 선택하여 [Execution Host]로 들어가면 아래에
Host list 에 global 항목을 선택하고 [Modify] 메뉴를 선택한다.
그럼 Add/Modify Executtion 창이 뜨게 된다.
그럼 [Consumables/Fixed Attribute] 탭으로 가서 [Name] 메뉴를 누르면 [select an item]
이란 창이 뜨는데..Available attribute 리스트에서 Synopsys 를 찾아 클릭하면 추가가 된다.
그런 후 Synopsys 항목의 Values 값을 입력할 수 있게 되는데 여기에 보유 라이센스 개수를
적어 주면 된다.
이제 이것으로 SGE의 어플리케이션 라이센스 설정이 완료되었다.
이제 터미널에서 qsub 를 이용해서 작업을 실행하면 되는데 이때 -l 옵션을 이용하여
sp=1 (sp 는 Synopsys의 shortcut)이란 속성을 전달 하면 SGE에서 이를 받아 들여
관리하게 된다.
SGE로 구성된 여러대의 제출 서버에서 아래와 같이 작업을 실행한다.
[root@uni04 sge]# qsub -l sp=1 examples/jobs/simple.sh
그런 후 qstat -f 로 큐 사태를 확인하면..
# qstat -f
—————————————————————————-
queuename qtype used/tot. load_avg arch states
—————————————————————————-
all.q@uni01 BIP 1/2 0.00 lx24-amd64
111 0.55500 simple.sh root r 03/16/2006 19:28:00 1
—————————————————————————-
all.q@uni02 BIP 1/2 0.00 lx24-amd64
110 0.55500 simple.sh root r 03/16/2006 19:28:00 1
—————————————————————————-
all.q@uni03 BIP 1/2 0.00 lx24-amd64
112 0.55500 simple.sh root r 03/16/2006 19:28:00 1
—————————————————————————-
all.q@uni04 BIP 0/2 0.00 lx24-amd64
############################################################################
– PENDING JOBS – PENDING JOBS – PENDING JOBS – PENDING JOBS – PENDING JOBS
############################################################################
113 0.55500 simple.sh root qw 03/16/2006 19:27:50 1
114 0.55500 simple.sh root qw 03/16/2006 19:27:51 1
115 0.55500 simple.sh root qw 03/16/2006 19:27:51 1
116 0.55500 simple.sh root qw 03/16/2006 19:27:51 1
117 0.55500 simple.sh root qw 03/16/2006 19:27:52 1
118 0.55500 simple.sh root qw 03/16/2006 19:27:52 1
—————————————————————————
위와 같이 SGE 의 synopsys complex에 정해진 수 (여기서는 3개) 만큼만 실행을 하고
나머지는 모두 큐에 대기 상태로 남아 있게 된다.
앞서 실행 되던 작업이 하나 씩 완료가되면 완료되는 대로 다음 순의 작업의 하나씩
실행 되게 되는 것이다.
이 같은 방식으로 여러개의 어플리케이션의 라이센스를 효율적으로 관리 할 수가 있다.
7. SGE와 MPICH, LAMMPI 통합하기
SGE 는 MPICH 와 함께 연동되어 MPICH에서 호출되는 프로세스를 스케줄링 하여 MPICH
의 Parall Processing 작업을 큐잉 시스템으로 제어할 수 있게 한다.
이는 소규모 MPP 시스템 환경에서는 필요하지 않으나 대규모의 시스템을 여러명의
사용자가 동시에 사용할 때는 반드시 필요한 기능이다.
예를 들면 40개의 processor 를 가진 MPP 환경에서 한 유저가 10개의 processor로 작업
을 실행 했다고 하자. 그 후 또 다른 유저가 10개의 프로세서로 작업을 실행 할때..
이 사용자는 MPI 시스템의 전체 서버에 각각 접속하여 앞에 사용자가 실행한 작업에
사용되는 프로세스를 확인 한 후 현재 유휴중인 프로세스만으로 machines 파일을 만들고
mpirun 구동 시 -machinefile 옵션을 이용하여 작업을 실행해야 할것이다.
위와 같이 원론적으로 작업을 하는 거 역시 사용자 수가 많으면 거의 불가능한 일이라
볼 수 있다.
여기서 mpirun 을 구동하는 구문을 sge 의 qsub 를 통해 실행하면 알아서 스케줄링이
되지 않냐는 의문을 제기 할 수 있다.
SGE 와 MPICH 가 곧 아래에 설명할 방법으로 연동이 되어 있지 않는 경우 qsub로 실행
을 시켰을때 mpirun 의 master processor 만을 SGE 프로세스 관리 엔진에서 인식하게
된다.
즉 mpirun 에서 10개의 CPU를 이용하여 작업을 전달하더라도 SGE에서는 1개의 작업으로
인식하게 되는 것이다.
이 같이 계속 SGE를 이용하여 작업을 전달 할때 40개의 CPU를 가진 시스템일 경우
40개의 mpi 작업이 동시에 실행되고 각 mpi 작업 별로 10개의 CPU를 호출했을 경우
전체 400개의 프로세스가 동시에 사용되게 되는 것이다.
만일 10개의 CPU를 가진 MPP 시스템이 있을 있고, 작업이 무조건 10개의 CPU를 모두
사용해야 할 경우라면 앞서 설명한 SGE의 라이센스 관리 방법을 이용하여 이 문제를
해결 할 수 있으나 보유한 CPU 수 보다 작은 CPU를 이용하여 여러개의 작업을 동시에
해야 할 경우엔 반드시 MPICH 와 SGE 의 연동이 필요하게 될것이다.
그럼 연동 방법에 대해 알아 보도록 하자.
먼저 ..SGE 에서 mpich 에 대한 parallel environment 환경을 설정해야 한다.
이는 qmon 을 이용하여 설정이 가능하다.
# qmon
-> parallel environment 메뉴로 간다.
-> Add 버턴을 이용하여 새로운 PE 를 생성한다.
설정 내용은 아래와 같다.
pe_name mpich
slots 9
user_lists NONE
xuser_lists NONE
start_proc_args /engrid/ensge/mpi/startmpi.sh -catch_rsh $pe_hostfile
stop_proc_args /engrid/ensge/mpi/stopmpi.sh
allocation_rule $fill_up
control_slaves TRUE
job_is_first_task FALSE
urgency_slots min
저장하고 나온다.
start_proc_args 와 stop_proc_args 에서 호출되는 startmpi.sh, stopmpi.sh 스크립터
는 현재 설치된 SGE 경로와 맞게 입력하면 된다.
이제 사용되어지는 queue 에 새로 생성된 PE 를 입력한다.
현재 큐을 확인 하는 방법은 아래와 같다.
# qconf -sql
all.q
큐의 설정 내용을 확인 및 수정하는 방법은 아래와 같다.
# qconf -mq all.q
————————————————————————————-
qname all.q
hostlist @allhosts
seq_no 0
load_thresholds np_load_avg=1.75
suspend_thresholds NONE
nsuspend 1
suspend_interval 00:05:00
priority 0
min_cpu_interval 00:05:00
processors UNDEFINED
qtype BATCH INTERACTIVE
ckpt_list NONE
pe_list make mpich <- 추가
rerun FALSE
slots 1,[node03=4],[node04=4],[node05=1]
.
.
———————————————————————————–
위 설정에서 pe_list 에 새로 추가한 mpich 를 포함하도록 한다.
이제 SGE의 작업 제출 환경을 수정하도록 한다.
# vi $SGE_ROOT/default/common/sge_request
————————————————————–
.
-v MPICH_PROCESS_GROUP=no
————————————————————–
# vi $SGE_ROOT/mpi/rsh
————————————————————–
echo $SGE_ROOT/bin/$ARC/qrsh -inherit -nostdin $rhost $cmd
exec $SGE_ROOT/bin/$ARC/qrsh -inherit -nostdin $rhost $cmd
else
echo $SGE_ROOT/bin/$ARC/qrsh -inherit $rhost $cmd
exec $SGE_ROOT/bin/$ARC/qrsh -inherit $rhost $cmd
to ..
echo $SGE_ROOT/bin/$ARC/qrsh -V -inherit -nostdin $rhost $cmd
exec $SGE_ROOT/bin/$ARC/qrsh -V -inherit -nostdin $rhost $cmd
else
echo $SGE_ROOT/bin/$ARC/qrsh -V -inherit $rhost $cmd
exec $SGE_ROOT/bin/$ARC/qrsh -V -inherit $rhost $cmd
—————————————————————
이제 qsub 에 제출 할 sge_scripts 를 생성하도록 한다.
# vi sge_mpi_run.sh
——————————————————————
#!/bin/sh
#$ -N mpitest
#$ -cwd
#$ -v -V
#$ -v MPIHOME=/usr/local/mpich-gcc
$MPIHOME/bin/mpirun -np $NSLOTS -machinefile $TMPDIR/machines $MPIHOME/examples/cpi
——————————————————————
qsub 명령을 이용하여 작업을 제출 한다.
# qsub -pe mpich <cpu_num> sge_mpi_run.sh
아래는 PE를 제어할 수 있는 간단한 명령 구문이다.
[root@node05 ensge]# qconf -spl
mpich
-> 현재 설정된 PE를 확인한다.
[root@node05 ensge]# qconf -sp mpich
pe_name mpich
slots 9
user_lists NONE
xuser_lists NONE
start_proc_args /engrid/ensge/mpi/startmpi.sh -catch_rsh $pe_hostfile
stop_proc_args /engrid/ensge/mpi/stopmpi.sh
allocation_rule $fill_up
control_slaves TRUE
job_is_first_task FALSE
urgency_slots min
-> 해당 PE 의 설정값을 확인한다.
[root@node05 ensge]# qconf -ap mpi
——————————————————————
pe_name mpi
slots 0
user_lists NONE
xuser_lists NONE
start_proc_args /bin/true
stop_proc_args /bin/true
allocation_rule $pe_slots
control_slaves FALSE
job_is_first_task TRUE
urgency_slots min
-> qmon 을 이용하지 않고 특정 PE를 추가한다. 해당 설정을 변경 후 wq 로 저장하면
된다.
[root@node05 ensge]# qconf -sql
all.q
-> 현재 존재하는 queue 를 확인하다.
[root@node05 ensge]# qconf -sq all.q
-> 해당 queue의 설정 값을 확인한다.
[root@node05 ensge]# qconf -mq all.q
-> 해당 queue의 설정 값을 변경한다.
다음 장에서는 SGE Scripts 생성하기를 이용하여 보다 더 세밀한 작업 제출 스크립터를
만들어 보자.
8. SGE Scripts 생성하기
### sample scripts
아래는 povray 를 sge 에 제출하는 스크립터이다.
——————————————————————————-
#!/bin/sh
#$ -cwd
#$ -V
#$ -S /bin/bash
#$ -N povray
#$ -v MPIHOME=/engrid/enhpc/mpich/gcc
#$ -l povray=2
#$ -pe mpich 10
#$ -o $HOME/log/result_log.out
#$ -e $HOME/log/result_log.err
export DISPLAY=192.168.123.2:0.0
$MPIHOME/bin/mpirun -np $NSLOTS -machinefile $TMPDIR/machines \\
/usr/local/bin/mpi-x-povray \\
+i/engrid/enhpc/bench/povray/pvm/pvmpov3_1g_2/povray31/scenes/advanced/chess2.pov \\
+h768 +w1024 +FT +v100 -q9 -mv2.0 -b1000 -nw32 -nh32 -nt16 \\
-L/engrid/enhpc/bench/povray/pvm/pvmpov3_1g_2/povray31/include +v +D
——————————————————————————-
### SGE 변수 정의 설명
-cwd : 현재 작업이 수행되는 경로를 다른 노드에서 유지 시킨다.
-v : 현재 작업이 수행되는 환경의 특정 환경 변수를 다른 노드에도 유지 시킨다.
-S : 해당 스크립터가 수행될 SHELL 환경을 정의한다.
-N : 해당 작업의 작업 이름 ( qstat -f ) 로 큐잉 상태를 확인 할때 표기된다.
-l : SGE complex 에서 정의된 특정 리소스의 값을 정의한다.
-pe : PE 에 정의된 설정을 반영한다.
-o : 작업 수행 시 콘솔에 출력되는 output message 를 저장한다.
-e : 작업 수행 시 콘솔에 출력되는 error message 를 저장한다.
-o, -e 에 저장되는 log 파일은 tail -f 를 이용하여 작업 진행 상태를 확인 할수
있다.
#### 설치 후 주로 발생 하는 문제
1. 일반 계정으로 qrsh 실행 시 ..
rcmd: socket: Permission denied
같은 오류 발생 ..
해결방법 :
$SGE_ROOT/utilbin/arch/ 밑에 있는 rsh, rlogin 의 퍼미션을 setuid 로 변경해줌
# chown root rsh
# chown root rlogin
# chmod 4511 rsh
# chmod 4511 rlogin
2. Warning: no access to tty (잘못된 파일 기술자).
Thus no job control in this shell.
해결 방법 qsub 에 제풀할 스크립터에
#$ -S /bin/sh
를 추가한다.
3. SGE Scripts 주요 옵션
-j y : output, error log merged
-m be
-M alang@clunix.com
-o test
-pe mpich 4
-S /bin/sh
-v MPICH_PROCESS_GROUP=no,__SGE_PREFIX__O_WORKDIR=/engrid/ensge
4. IP Multipathing 환경에서의 host_aliases 설정
Network Interface 가 여러개인 환경에서 SGE 는 실제 system 의 호스트네임에 해당하는 hostname
만을 인식하게 된다.
하지만 클러스터 시스템 구축 시 성능등의 문제로 여러개의 네트워크 채널을 나누는 경우가 대부분
인데 이때 실제 시스템 호스트네임이 적용된 NIC 가 아닌 다른 NIC를 통해 SGE를 구축하고자 할때
host_aliases 설정을 이용하여 여러개의 호스트를 하나의 호스트 처럼 사용이 가능하다.
예 ) /etc/hosts 설정 내용 ..
192.168.123.71 waveform
192.168.10.1 node01
위 두개의 호스트는 같은 서버에 장착된 NIC에 각각 부여된 호스트네임이다.
기본적으로 waveform 이 시스템의 호스트네임으로 잡혀 있지만 SGE의 경우 node01 을 통해 동작 시키고
싶다. 이런 경우 ..
$SGE_ROOT/default/common/host_aliases 파일 생성 후
vi host_aliases
——————————————————————————-
node01 waveform
과 같이 설정하면 된다. 그런 후 반드시 sge_qmaster 데몬과 sge_execd 데몬 재시작.
이 밖에 IP의 변동은 없지만 실제 셋팅 당시의 지정한 호스트네임을 사이트 구축 시 변경하고자
할때 동일한 방식으로 처리 하면 된다.
vi /etc/hosts
——————————————————————————-
192.168.123.71 waveform node01
5. Fluent 연동
# fluent 3d -i fluent_jou -sge -sgepe mpich 6
# qsub -cwd -pe mpich 6 -v FLUENT_INC=/usr/local/fluent/Fluent.Inc,DISPLAY=192.168.123.2:0.0 -N alang_test -j y -o alang_test.log /usr/local/fluent/Fluent.Inc/bin/fluent 3d -pnmpi -i fluent_jou
fluent 6.2.x 대에서는 정상적으로 제출이 되지만 6.3.x 에서 멀티노드를 이용한 MPI
작업 제출 시에는
SGE 의 작업 노드 선정 단계에서 sgemaster 에 연결할 수 없다는 메세지와 함께
노드 선출이 되지 않는 경우가 발생한다. 이때는 아래와 같이 pe 를 재구성한다.
# qconf -ap fluent_pe
——————————————————————————-
pe_name fluent_pe
slots 22
user_lists NONE
xuser_lists NONE
start_proc_args /engrid/ensge/mpi/startmpi.sh $pe_hostfile
stop_proc_args /engrid/ensge/mpi/stopmpi.sh
allocation_rule $fill_up
control_slaves TRUE
job_is_first_task FALSE
urgency_slots min
——————————————————————————-
만일 작업 수행 제일 마지막에 아래와 같은 에러가 로그가 발생하면..
rm: cannot remove `/tmp/113.1.all.q/rsh’: No such file or directory
stop_proc_args를 /bin/true 로 변경하면 된다.
6. 특정 노드에 작업 전달 하기
– 특정 큐에 작업 전달하기
qsub -q all.q@grid00,all.q@grid01 job_scripts
– MPI 작업 시 특정 노드를 마스트로 작업 전달 하기
qsub -masterq all.q@grid00 -pe mpich 6 job_scripts
7. DISPLAY 를 이용한 원격 UI 작업을 실행 시.
qsub 로 작업 전달 시 ..-masterq 를 이용하여 작업의 마스터 노드를 지정하고
-v DISPLAY 설정으로 GUI를 띄울 클라이언트를 지정한다.
클라이언트 머신에서는 masterq 로 지정된 서버로 ssh -X 혹은 xmanager와 같은
도구로 masterq 에 접속을 하여 x-forward 상태로 만들어 놓는다.
qsub 를 이용하여 작업을 전달 하면 된다.
8. NFS로 $SGE_ROOT/default 연결 시 권장 mount 방식
# vi /etc/exports
—————————————————————————
/engrid/ensge *(rw,no_root_squash)
# vi /etc/fstab
————————————————————————–
grid000:/engrid/ensge /engrid/ensge nfs rw,intr,soft,bg 1 0
9. PE 구성 시 CPU 할당 방법 종료
$fill_up : CPU 자원 할당 시 같은 노드에서 우선 할당 하도록 구성 할 때 ..
( 2core+2cpu = 4core 시스템 2대에 4개 프로세스를 이용한 작업 전달 시 1대 노드에서 4core 할당 )
$round_robin : 가용할 수 있는 노드에 균등하게 분배하여 할당함.
( 2core+2cpu = 4core 시스템 2대에 4개 프로세스를 이용한 작업 전달 시 1대 노드에 2core, 다른 1대 노드에 2core 할당)
10. 특정 작업의 대한 의존성 부여
(특정 작업이 종료하기 전에 작업 수행 안함.)
-hold_jid <jobid>
