[HPC] SGE Qmaster 이중화 구현하기
SGE Qmaster 이중화 하기
작성자 : 서진우
작성일 : 2010년 10월 28일
SGE의 스케줄러 관리 노드를 이중화하는 대표적인 방법은 SGE 자체에서 제공하는
shadow master 기능을 이용하는 것이다. 하지만 shadow master를 구성하기 위해서는
몇가지 전체 조건이 있고, 이는 현실적인 상황에서 이중화를 하는데 제약이 있다.
일단 shadow master를 통한 이중화 방법에 대해 알아보자
shadow master 방식으로 이중화를 하기 위해서는 몇가지 조건이 있다.
1. spooldb 는 master 와 slave 에서 반드시 공유되어야 하고, read/write 권한이
모두 주어져야 한다.
2. shadow master 로 spooldb 를 구성할 경우 NFS 방식은 지원하지 않는다.
3. shadow master 로 spooldb 를 구성할때 Berkely DB Server 방식으로 구성해야한다.
Class(filedb) 방식으로 구성할 경우 db가 깨지는 문제가 발생한다.
4. spool DB server 는 qmaster 노드와 별도로 구성되어야 정상적인 이중화 구성이 가능하다.
위 전체 조건을 보면 SGE를 통해 스케줄러 관리 노드 이중화는 비싼 SAN Disk 방식에
Cluster File System을 사용해야 하고, 총 3대의 Server(qmaster, slave, spooldb)가 스케줄러 관리 서버 그룹으로 구성이 되어져야 한다.
현실적으로 스케줄러 구성에 위와 같이 많은 비용으로 구성하기 힘들 수 있다.
본 문서에서는 두대 서버와 NFS 로도 구성 가능한 스케줄러 이중화 환경에 대해 알아보도록 한다.
먼저 기본적인 shadow master 방식의 구성에 대해 간단히 소개한다.
1. Shadows master 구성하기
CFS 환경에 $SGE_ROOT가 존재한 상태에서 기본적인 SGE 구성을 완료한다.
shadowd 관련 환경 설정을 수행한다. setting.sh 파일에 포함하거나 별도의 설정파일을
만들어서 /etc/profile.d 밑에 옮겨 둔다.
# cat /etc/profile.d/sge_shadow.sh
—————————————————————————–
export SGE_DELAY_TIME=30
export SGE_CHECK_INTERVAL=30
export SGE_GET_ACTIVE_INTERVAL=30
—————————————————————————–
위 환경 설정은 qmaster 가 다운될 경우 shadow master 서버로 qmaster 서비스가 take over
되는 간격을 정의한 것이다. 기본일 경우 SGE_DELAY_TIME 이 600초로 10분 동안 HA 동작이
이루어 지지 않는다.
SpoolDB 서버에서 $SGE_ROOT/inst_sge -db 명령으로 해당 서버를 spooldb 서버로 구성한다.
qmaster 서버에서 $SGE_ROOT/inst_sge -sm 명령으로 shadow master 설정을 수행한다.
qmaster 서버에서 $SGE_ROOT/inst_sge -sm -host <slave_hostname> 으로 qmaster 가 다운될
경우 역할을 대신할 서버를 등록한다.
$SGE_ROOT/default/common/shadow_masters 파일에 master와 slave hostname 이 등록되어 있음을 확인한다.
# cat $SGE_ROOT/default/common/shadow_masters
————————————————————————-
master
slave
————————————————————————-
master와 slave서버에서 sge_shadowd 프로세스가 동작하는지 확인 한다.
만일 정상적으로 동작하지 않을 경우 아래 명령으로 shadowd 데몬을 실행한다.
# $SGE_ROOT/default/common/sgemaster -shadowd
2. 3d party HA 프로그램으로 SGE 이중화 하기 ..
NFS 파일 서버에 spooldb를 class 방식으로 구성하고, qmaster 서버와 slave 서버는 별도로 구성한다.
qmaster 에 장애 발생 시 안전하게 slave 로 fail over 시키는 과정에 대해 알아 보자
기본적으로 qmaster 에 장애가 발생할 경우 slave 에서 $SGE_ROOT/default/common/act_qmaster
파일에 기존 master hostname 을 slave hostname 으로 변경한 후 slave 에서 sgemaster
데몬을 시작하면 역할이 이전되다.
slave # cat $SGE_ROOT/default/common/act_qmaster
———————————————————————–
slave
———————————————————————–
slave # $SGE_ROOT/default/common/sgemaster start
하지만 master 노드의 장애 상태가 완전한 서버 다운이 아닌 일시적인 네트워크 장애나, 급작스런 부하 증가로 서버 Hang 상태로 머물어 있다 다시 원복되는 경우 두개의 서로 다른 qmaster 프로세스가 spooldb 에 접근함으로 spooldb 가 깨지게 되는 문제가 발생한다.
처음 master 에서 slave 로 서비스 이전까지는 문제가 없지만, slave 서버에서 qmaster 서비스를 재시작하거나 원래의 master 서버로 서비스를 복구 할 경우 spooldb 가 깨서 정상적으로 qmaster를 시작할 수 없다.
master # cat $SGE_ROOT/default/spool/qmaster/messages
————————————————————————–
.
error: trigger function of rule “default rule” in context “berkeleydb spooling” failed
————————————————————————–
이러한 문제를 방지하기 위해서 master 의 장애가 발생할 경우 slave 에서 장애 발생 시 spooldb 를 다른 디렉토리로 옮겨 두고, 복사된 새로운 spooldb 경로를 반영하여 qmaster 데몬을 실행해야 한다.
만일 spooldb 을 복사한 후 기존 spooldb를 삭제하고, 동일한 경로에 다시 복사해서 qmaster
데몬을 띄우게 되면, NFS 핸들링 문제로 sgeexecd 데몬을 재시작해야 정상적인 스케줄링 기능을 수행하여 서비스 복구 절차가 매우 복잡해 진다.
또한 원래 master의 회복 시점에 따라 spooldb 가 다시 깨지는 경우도 발생한다.
그러므로 slave 에서 qmaster 데몬을 동작하기 전에 기존의 master 서버의 spooldb 경로와 다른 경로에 spooldb을 옮겨두고, 변경된 경로의 spooldb path를 적용한 후 qmaster를 동작하면 이런 문제를 원천적으로 회피할 수 있다.
이제 아래 시나리오에 의해 master 에 장애 발생 후 slave 로 서비스 이전, 다시 원래 상태로 구성 복구등의 테스트를 수행하도록 한다.
a. Master 에 네트워크 장애 발생 (불확실한 장애 발생)
– 스케줄러 네트워크 채널을 단절 시키고, File 서비스 채널을 정상을 유지함.
b. slave 서버에서 기본 spool 디렉토리를 spool_tmp 로 qmaster를 qmaster_tmp 로 변경
slave # cp -a $SGE_ROOT/default/spool $SGE_ROOT/default/spool_tmp
c. $SGE_ROOT/default/common/bootstrap 파일에서 spooldb 경로를 변경함.
slave # vi $SGE_ROOT/default/common/bootstrap
————————————————————————
# Version: 6.2u3
#
admin_user clunix
default_domain none
ignore_fqdn true
spooling_method berkeleydb
spooling_lib libspoolb
spooling_params /engrid/ensge/default/spool_tmp/spooldb
binary_path /engrid/ensge/bin
qmaster_spool_dir /engrid/ensge/default/spool_tmp/qmaster
security_mode none
listener_threads 2
worker_threads 2
scheduler_threads 1
jvm_threads 0
————————————————————————–
d. $SGE_ROOT/default/common/act_qmaster 에 slave hostname 입력
slave # cat $SGE_ROOT/default/common/act_qmaster
————————————————————————–
slave
e. $SGE_ROOT/default/common/sgemaster 데몬 시작
slave $ $SGE_ROOT/default/common/sgemaster start
f. qstat -f 로 스케줄러 상태 확인
slave # qstat -f
queuename qtype resv/used/tot. load_avg arch states
———————————————————————————
all.q@gc001 BIP 0/0/8 0.29 lx24-amd64
———————————————————————————
all.q@gc002 BIP 0/0/8 -NA- lx24-amd64 adu
———————————————————————————
all.q@gc003 BIP 0/0/8 0.05 lx24-amd64
———————————————————————————
all.q@gc004 BIP 0/0/8 0.03 lx24-amd64
만일 execd 노드와의 정보가 정상적으로 수집되지 않으면 sgeexecd를 재 시작해준다.
이때 장애 이전에 동작 중인 작업이 존재할 경우 sgeexecd를 그냥 재시작하면 해당 작업이
모두 중지되거나, 관련 작업 정보가 삭제 된다.
이때는 sgeexecd softstop 으로 중지하고, start 하면 된다.
# $SGE_ROOT/default/common/sgeexecd softstop
# $SGE_ROOT/default/common/sgeexecd start
g. master의 네트워크 복구 후 이상 유무 확인
master 노드의 SGE 네트워크 채널을 다시 연결한다. 이제 master와 slave 에서 모두
qmaster 데몬이 동작되는 상태가 된다.
master # ps aux | grep sge
root 21300 0.0 0.0 53224 732 pts/1 S+ 15:18 0:00 grep sge
clunix 27373 0.0 0.0 97872 6656 ? Sl 13:28 0:04 /engrid/ensge/bin/lx24-amd64/sge_qmaster
clunix 29285 0.0 0.0 68688 2168 ? Sl 13:29 0:00 /engrid/ensge/bin/lx24-amd64/sge_execd
slave # ps aux | grep sge
root 4072 0.0 0.0 3568 184 pts/0 R+ 15:19 0:00 grep sge
clunix 8995 0.0 0.0 68700 2192 ? Sl 13:29 0:02 /engrid/ensge/bin/lx24-amd64/sge_execd
clunix 31845 0.0 0.0 95640 6504 ? Sl 15:13 0:00 /engrid/ensge/bin/lx24-amd64/sge_qmaster
하지만 slave의 qmaster 프로세스가 참조하는 spooldb 경로와 master 서버의 qmaster 프로세스가 참조하는 spooldb 경로가 서로 다르므로 두 프로세스간의 의존성이나 무결성 문제는 전혀 발생하지 않는다.
또한 qmaster 데몬이 두대의 서버에 동시에 띄워져 있지만, execd 서버가 qmaster로 인정하는 서버는 $SGE_ROOT/default/common/act_qmaster 에 정의된 서버이다.
즉 master 에 띄워진 qmaster 프로세스와 기존 spooldb는 master 서버에서 별개로 띄워져만
있는 상태가 된다.
이런 무의미한 상태로 일정 시간 있다보면, 스스로가 sge_qmaster 데몬을 죽여버린다
이로써 안정한 상태로 스케줄러 서비스의 fail over 가 이루어 진다.
h. 구성 원상 복구
이제 다시 원상 복구를 시켜보도록 하자.
원복은 매우 간단하다. slave 가 정상적으로 qmaster 역할을 수행하고 있음을 확인한 후
master 에서 sgemaster -migrate 명령으로 구성을 원래로 복구한다.
master # $SGE_ROOT/default/common/sgemaster -migrate
만일 변경된 spooldb 경로(spooldb_tmp)도 원래로 변경하기 위해서는 앞서 설명한
동일한 절차와 방법으로 변경하여 원상복구 하면 된다.
3. 이중화 자동 스크립트
# vi $SGE_ROOT/default/common/sgetakeover
————————————————————————————
#!/bin/sh
SGE_ROOT=”/engrid/ensge”
TMPNAME=`date +%Y%m%d%H%M%S`
ODLNAME=`cat $SGE_ROOT/default/common/bootstrap | grep spooling_params | awk ‘{print $2}’ | cut -f 5 -d /`
cp -a $SGE_ROOT/default/${ODLNAME} $SGE_ROOT/default/spool_${TMPNAME}
cat <<BOOTSTRAP> $SGE_ROOT/default/common/bootstrap
# Version: 6.2u3
#
admin_user clunix
default_domain none
ignore_fqdn true
spooling_method berkeleydb
spooling_lib libspoolb
spooling_params /engrid/ensge/default/spool_${TMPNAME}/spooldb
binary_path /engrid/ensge/bin
qmaster_spool_dir /engrid/ensge/default/spool_${TMPNAME}/qmaster
security_mode none
listener_threads 2
worker_threads 2
scheduler_threads 1
jvm_threads 0
BOOTSTRAP
echo `$SGE_ROOT/utilbin/lx24-amd64/gethostname -name` > $SGE_ROOT/default/common/act_qmaster
$SGE_ROOT/default/common/sgemaster start
ensh $SGE_ROOT/default/common/sgeexecd softstop
ensh $SGE_ROOT/default/common/sgeexecd start
——————————————————————————–
# vi $SGE_ROOT/default/common/sgetakeback
——————————————————————————–
#!/bin/sh
SGE_ROOT=”/engrid/ensge”
$SGE_ROOT/default/common/sgemaster -migrate
——————————————————————————–
# chmod 755 $SGE_ROOT/default/common/sgetakeover
# chmod 755 $SGE_ROOT/default/common/sgetakeback
slave 에서 master 의 장애를 감지할 경우 sgetakeover 스크립트를 자동 수행하면 된다.
원래 상태로 복구할때는 sgetakeback 스크립트를 수행하면 된다.
take back 시 sgetakeback 을 수행하면 sgemaster -migrate로 수행이 된다. 이는 master
와 slave 가 모두 정상적인 상황에서 이루어 질 수 있다. 만일 slave 서버에 이상이
있어 강제 원복을 시킬 경우엔 master 서버에서 sgetakeover 를 실행하면 된다.
사실 어느 서버에서나 sgetakeover를 수행하면 기존 qmaster 서버의 상태와 무관해게
강제로 자기 자신이 qmaster가 되어 지는 것이다.
Can you be more specific about the content of your article? After reading it, I still have some doubts. Hope you can help me.