5장-HPC 클러스터 소개 및 구축 방법
Introduction to
High Performance Computer Cluster
using Linux
목차 ?
1. Teragon HPC 운영체제 설치
1.1 NFS, Kick Start 설치 하기
1.2 PXE, NFS, Kick Start 설치 하기
2. Teragon HPC Network 설정하기
2.1 Network channel 이중화
2.2 Rsh, rlogin 설정
2.3 ssh 설정
2.4 Dutils 설정
2.5 NFS 설정
2.6 NIS 계정 통합 시스템
3. Teragon HPC 설정하기
3.1 Time Sync 설정
3.2 Compiler 설치 및 설정
3.3 Library 설치
3.4 병렬프로그램 설치 및 설정 ( MPICH, LAM-MPI )
3.5 분산 시스템 일괄 계정 관리
3.6 Open PBS 설치 및 관리 하기
3.7 HPC Management Tool 설치, 설정, 관리 (dutils2)
4. Encluster 2.0를 이용한 HPC System Monitoring
4.1 Encluster 2.0 설치, 설정
4.2 Encluster 2.0 관리
5. Teragon HPC Security 설정
5.1 Command, Directory Security
5.2 Service Security ( rsh, rlogin, ssh, nfs, ftp )
5.3 Network Security ( network filtering )
6. HPC Benchmark 성능 분석 하기
6.1 NAS Parallel Benchmark (NPB)
6.2 High Performance Linpack Benchmark (HPL)
6.3 Parallel add Benchmark ( 정수 연산 )
6.4 Stream Memory Benchmark
6.5 Bonnie++ Disk I/O Benchmark
6.6 Netpipe Network Benchmark ( TCP, MPI )
1. Teragon HPC 운영체제 설치 하기
1.1 NFS, Kick Start 설치 하기
Teragon NFS 윈격 설치 환경을 구축 하기 위해선 먼저 Master Node를 설치를 해야 한다.
Master Node 에 기본적인 관리 노드 구성에 맞게 패키지 구성을 완료한 뒤, 원격 설치
서비스를 하기 위해 기본적으로 NFS 서비스와 DHCP 서비스를 구동시킨다.
그런후 계산 노드들은 부팅 CD 나 부팅 디스켓으로 부팅 후 kick start 설치모드로
원격 설치 서버에 접속하여 설치 시 필요한 정보와 패키지를 다운받아 자동 설치 하
게 된다. 아래는 이와 같은 일련의 작업을 설명한 것이다.
– Linux 운영 체제 설치
Master Node의 Redhat Linux 운영체제 설치 시를 아래와 같은 Remote install 관련 Package를 포함해서 설치 해야 한다.
dhcp
dhcp-devel
anaconda-runtime
redhat-config-kickstart
rsh-server
그리고 기본적으로 설치가 되어지는 lam-mpi package는 package 구성 시 제거한다.
이밖에 package 는 기술부 1차 세미나를 참조 하여 설치 한다.
– Remote Install Service 설치
Master Node 에 원격 설치 서버를 만들기 위해 Redhat 배포판 CD 를 통합하여
원격 설치에 맞게 구성을 만들어 놓는다.
> 기본 디렉토리를 생성한다.
# mkdir -p /data/clunix/teragon
# mkdir /data/clunix/cd1
# mkdir /data/clunix/cd2
# mkdir /data/clunix/cd3
> cd1,cd2,cd3 디렉토리에 Redhat9.x CD 내용을 각각 복사한다
# mount -t iso9660 /dev/cdrom /mnt/cdrom
# cp -rf /mnt/cdrom/* /data/clunix/cd1
# cp -rf /mnt/cdrom/* /data/clunix/cd2
# cp -rf /mnt/cdrom/* /data/clunix/cd3
> Teragon Server 에 기본 설치되는 RPM Package List 정리하여 ‘kick’ 이란 file 로 보관한다.
> ‘kick’ file 저장위치는 /data/clunix/ 안에 둔다.
# rpm -qa > /data/clunix/kick
> redhat 원본CD 에서 Teragon 에 맞는 CD 구성을 만든다.
> addrpm.sh 스크립터를 $teracd 에 만든다.
# cd /data/clunix
[root@teragon01 clunix]# vi addrpm.sh
=============================================================================
#!/bin/sh
for file in `cat kick`
do
cp -f ./cd1/RedHat/RPMS/${file}* ./teragon/RedHat/RPMS/
cp -f ./cd2/RedHat/RPMS/${file}* ./teragon/RedHat/RPMS/
cp -f ./cd3/RedHat/RPMS/${file}* ./teragon/RedHat/RPMS/
done
=============================================================================
# chmod 700 addrpm.sh
> addrpm.sh 실행한다.
만일 배포판 전체 패키지를 통합할 경우 CD1 의 내용에 CD2, CD3 의 RedHat/RPMS 밑의
rpm package 들만을 CD1으로 복사하면 된다.
[root@teragon01 clunix]# ./addrpm.sh
이러면 실제 설치에 필요한 RPM 패키지가 하나의 폴더안에 집중하여 관리 할수 있다.
( 원격 설치 시 자동 One step 설치 방식으로 구성하여 설치 과정 중에 관리자가 계속
대기 하고 있다가 설치에 필요한 정보를 입력하는 수고를 생략하기 위한 것이다. )
기본적인 Redhat rpm package 가 하나로 통합을 시켰으면 이제 HPC에 필요한 추가
패키지를 rpm 으로 만들어 Redhat 배포판 디렉토리 구성의 RPM 디렉토리 안에 추가해
둔다.
dutils, rsh-enable, ecm-base, ecm-mon, ecmhpc-ui 등등의 패키지를 추가한다.
# cp dutil-1.2.1-2.i386.rpm /data/clunix/teragon/RPMS
# cp rsh-enable-0.1-1.i386.rpm /data/clunix/teragon/RPMS
# cp ecm-base-1.0.0-5.i386.rpm /data/clunix/teragon/RPMS
# cp ecm-mon-1.0.0-5.i386.rpm /data/clunix/teragon/RPMS
# cp ecmhpc-ui-1.0.0-5.i386.rpm /data/clunix/teragon/RPMS
> clunix 의 RPM List 를 다시 만들어 준다. anaconda-runtime 이 설치되어져 있어야 한다.
– 기본적인 RPM 구성 정보를 담는 파일을 변경된 구성의 정보로 업데이트 시켜 주어야 한다.
[root@teragon01 clunix]# /usr/lib/anaconda-runtime/genhdlist –withnumbers ?hdlist \\
teragon/RedHat/base/hdlist /data/clunix/teragon/
** 레드헷 전체 RPM 구성으로 이미지 서버 구축 시에는 위 내용 대신 CD1 에 있는 기본 hdlist
를 사용한다. 아님 설치 되지 않는 패키지가 발생할 수 있다.
– DHCP Server 설정
[root@teragon01 clunix]# vi /etc/dhcpd.conf
============================================================================
ddns-update-style interim;
ignore client-updates;
default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.100.255;
option routers 192.168.100.1;
option domain-name-servers 192.168.100.1;
option domain-name “teragon01”;
subnet 192.168.100.0 netmask 255.255.255.0 {
range 192.168.100.150 192.168.100.253;
}
===========================================================================
> dhcp 에 사용되는 dev 지정
[root@teragon01 clunix]# vi /etc/sysconfig/dhcpd
==========================================================================
DHCPDARGS=eth0
==========================================================================
> dhcpd deamon restart
[root@teragon01 clunix]# /etc/rc.d/init.d/dhcpd restart
– NFS Server 설정
[root@teragon01 clunix]# vi /etc/exports
==========================================================================
/data/clunix/teragon *(ro,no_root_squash)
==========================================================================
[root@teragon01 clunix]# /etc/rc.d/init.d/portmap restart
[root@teragon01 clunix]# /etc/rc.d/init.d/nfs restart
> nfs mount 테스트를 한다.
[root@teragon01 data]# mount -t nfs localhost:/data/clunix/teragon /tmp
[root@teragon01 data]# umount /tmp
*** nfs 서버 설정 후 mount 가 되지 않을 경우 다시 한번 portmap 과 nfs 관련 데몬이
정상적으로 작동하는지 확인 하고, iptables 가 적용되지 않는 지 확인 하도록 한다.
초기 OS 설치 시 firewall 설정이 되어지므로 설치 단계에서는 반드시 iptables 를
잠시 stop 하도록 한다.
[root@teragon01 data]# /etc/rc.d/init.d/iptables stop
– Kick Start 설정 파일 생성 하기
Kick Start 는 Redhat Linux 배포판 버전 설치를 일괄 설치가 가능하게 해주는 구축 방식이다.
Kick Start 에서 배포판 설치에 필요한 정보를 하나의 설정 파일로 만들고, 이 설정 파일을 이용
하여 설치 시 설치자에서 필요한 정보를 응답식으로 물어보지 않고 자동으로 설치 하도록 한다.
Kick start 설정은 Redhat Linux 배포판의 버전 마다 패키지 구성 Class Name 이 다르기 때문에
다른 버전의 배포판에서 제작한 설정 파일을 이용하여 만들 경우에 설치 된 배포판에서 직접 생성
하는 것이 좋다. 우선 Master Server 설치를 하였으니 이 서버에서 생성이 가능하다.
생성하는 방법으로는 여러 가지가 있는데 가장 쉬운 방법은 이미 수동으로 설치한 Master Server 의
/root 디렉토리 밑에 보면 anaconda-ks.cfg 파일이 있을 것이다. 이것이 Master Server 설치 시
설치자가 설치에 필요한 정보를 토대로 설정 파일을 만들어 놓은 것이다. 이 설정 파일을 이용하여
원격 설치에 맞게 수정하는 것이 제일 간편하다. 만일 계산용 서버의 운영체제 구성이 Master Server
와 상이하게 다른 경우는 Master Server 에서 redhat-config-kickstart 란 프로그램을 이용하여
임의적으로 생성할 수도 있다.
– redhat-config-kickstart를 이용하여 생성한 ks.cfg 파일
=============================================================================
#Generated by Kickstart Configurator
#System language
lang ko_KR.eucKR
#Language modules to install
langsupport –default=ko_KR.eucKR
#System keyboard
keyboard us
#System mouse
mouse generic3ps/2
#Sytem timezone
timezone Asia/Seoul
#Root password
rootpw –iscrypted $1$iv0/Mp/1$uoKRMOmtvv/DAVYEnnrGK.
#Use text mode install
text
#Install Red Hat Linux instead of upgrade
install
#Use NFS installation Media
nfs –server=192.168.10.254 –dir=/data/clunix/teragon
#System bootloader configuration
bootloader –useLilo –linear –location=mbr
#Clear the Master Boot Record
zerombr yes
#Partition clearing information
clearpart –all –initlabel
#Disk partitioning information
part /boot –fstype ext3 –size 200
part / –fstype ext3 –size 2000 –asprimary
part /usr –fstype ext3 –size 5000
part /usr/local –fstype ext3 –size 5000
part /var –fstype ext3 –size 2000
part swap –size 2000
part /home –fstype ext3 –size 1 –grow
#System authorization infomation
auth –useshadow –enablemd5
#Network information
#network –bootproto=static –ip=192.168.1.1 –netmask=255.255.255.0 –gateway=192.168.1.254 –nameserver=192.168.1.254 –device=eth0
#Firewall configuration
firewall –medium –trust=eth1 –ftp –ssh
#Do not configure XWindows
skipx
#Package install information
%packages –resolvedeps
@ X Window System
@ Editors
@ Engineering and Scientific
@ Graphical Internet
@ Text-based Internet
@ Graphics
@ Authoring and Publishing
@ Server Configuration Tools
@ DNS Name Server
@ Network Servers
@ Development Tools
@ Kernel Development
@ X Software Development
@ Administration Tools
@ System Tools
%post –interpreter /bin/bash
#### setting IP ADDR ############################
stringZ=`cat /proc/cmdline`
for service in $stringZ
do
if [ `expr match “$service” “ksip=”` -eq “5” ] ; then
IPADDR=${service:5}
fi
if [ `expr match “$service” “ksnm=”` -eq “5” ] ; then
NAME=${service:5}
fi
done
echo “DEVICE=eth1” > /etc/sysconfig/network-scripts/ifcfg-eth1
echo “BOOTPROTO=static” >> /etc/sysconfig/network-scripts/ifcfg-eth1
echo “IPADDR=${IPADDR}” >> /etc/sysconfig/network-scripts/ifcfg-eth1
echo “NETMASK=255.255.255.0” >> /etc/sysconfig/network-scripts/ifcfg-eth1
echo “ONBOOT=yes” >> /etc/sysconfig/network-scripts/ifcfg-eth1
echo “NETWORKING=yes” > /etc/sysconfig/network
echo “HOSTNAME=${NAME}” >> /etc/sysconfig/network
#################################################
##### setting services off ###################################
chkconfig kudzu off
chkconfig reconfig off
chkconfig ipchains off
chkconfig nfslock off
chkconfig nfs off
chkconfig keytable off
chkconfig apmd off
chkconfig rawdevices off
chkconfig sendmail off
chkconfig gpm off
chkconfig anacron off
chkconfig atd off
=============================================================================
이와 같이 만들어진 ks.cfg 파일을 /data/clunix/teragon 에 복사해 두고 dhcp, nfs, portmap 등의
서비스가 정상 가동하는지 확인 후 계산 노드 들을 네트워크 원격 설치 방식으로 설치 한다.
– 계산 서버 설치 하기
계산 서버의 전원을 켜고 배포판 부팅 CD나 Master 서버에서 만든 booting floppy disk를 이용하여
부팅을 시킨다. “Boot :” 와 같은 부팅 프롬프트가 나타나면, 프롬프트 상에 아래 내용을 입력해 준다.
boot : ks ks=nfs:[nfs_server_ip 혹은 호스트명]:/data/clunix/teragon/ks.cfg ksip=[설치서버의 기본 IP] ksnm=[설치서버의 호스트명]
그럼 자동으로 위의 ks.cfg 파일에서 설정한 구성으로 운영 체제가 설치 될것이다.
*** 계산 노드의 랜카드가 두장 이상일 경우 실제 nfs 로 통신할 랜카드를 선택 해야 한다.
실제 랜선이 연결된 Ethernet 측의 네트워크 장치를 사용하여 설치를 해야 한다.
1.2 PXE, NFS, Kick Start 설치 하기
– 기본 운영 체제 설치
PXE-ROM 이 있는 Lan Card 의 경우 PXE-protocol 을 이용하여 랜카드 자체에서 네트워크를 통해 부팅 이미지를 읽어 올 수가 있다.
이 기능을 이용하면 리눅스 설치 CD 와 같은 미디어 없이 네트워크를 통해 리눅스를 설치 하거나 하드디스크 없이 CPU, MEM 만 달려
있는 시스템을 부팅 이미지와 NFS 서버를 통해 시스템을 작동 시킬 수 있다. 이런 방식을 이용하여 Diskless-HPC를 구축 하기도 한다.
여기서는 설치에 관련된 내용만을 다루도록 한다.
Pxe를 이용한 리눅스 네트워크 설치 때 사용되는 기본 프로그램은 아래와 같다.
=============================================================================
redhat-config-netboot
tftp-server
dhcpd
nfs
위의 프로그램이 원격 설치 서버 시스템에 기본적으로 설치가 되어 있어야 한다.
설치는 간단히 배포 판에서 제공하는 RPM으로 설치 하면 된다.
rpm -Uvh redhat-config-netboot
rpm -Uvh tftp-server-x.x.x.rpm
rpm -Uvh tftp-x.x.x.rpm
그럼 /tftpboot 가 생성된다.
– TFTP 설정 하기
/etc/xinetd.d/tftp 의 disable = yes를 no 변경 해주고 xinetd 를 재 시작해 준다.
# vi /etc/xinit.d/tftp
=============================================================================
service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
per_source = 11
cps = 100 2
flags = IPv4
}
=============================================================================
# /etc/rc.d/init.d/xinetd restart
# chkconfig –level 3 xinetd on
# chkconfig –level 3 tftp on
– DHCP 설정 하기
PXE 네트워크 설치 방식에서 가장 유의해야 할 설정은 dhcp 설정이다.
위의 Nfs 네트워크 설치 방식 처럼 단순히 ip 만 활당해 주는 것이 아니라 네트워크를 통해
커널 이미지를 로딩하여 부팅을 해야 하기 때문에 다소 복잡하다.
# vi /etc/dhcpd.conf
=============================================================================
ddns-update-style interim;
ignore client-updates;
default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.100.255;
option routers 192.168.100.254;
option domain-name-servers 192.168.100.254;
option domain-name “node00.tergon.hpc”;
# 아래 추가
allow booting;
allow bootp;
class “pxeclients” {
match if substring (option vendor-class-identifier, 0, 9) = “PXEClient”;
next-server 192.168.100.254;
filename “linux-install/pxelinux.0”;
}
# 특정 Mac Address를 가지고 접속하는 클라이언트에서 특정 IP 부여
# 이는 tftp 설정에서 클라이언트 시스템 별로 별도의 부팅 이미지 및 ks 파일을
# 적용할수 있기 때문에 지정을 해주면 보다 자동화된 시스템 구축이 가능하다.
group {
next-server 192.168.100.254;
filename “linux-install/pxelinux.0”;
host node01 {
hardware ethernet 00:09:3d:10:8b:c6;
fixed-address 192.168.100.1;
}
host node02 {
hardware ethernet 00:09:3d:10:96:64;
fixed-address 192.168.100.2;
}
host node03 {
hardware ethernet 00:09:3d:10:98:3b;
fixed-address 192.168.100.3;
}
host node04 {
hardware ethernet 00:09:3d:10:93:ce;
fixed-address 192.168.100.4;
}
host node05 {
hardware ethernet 00:09:3d:10:98:02;
fixed-address 192.168.100.5;
}
host node06 {
hardware ethernet 00:09:3d:00:7a:6c;
fixed-address 192.168.100.6;
}
host node07 {
hardware ethernet 00:09:3d:10:93:d4;
fixed-address 192.168.100.7;
}
}
subnet 192.168.100.0 netmask 255.255.255.0 {
range 192.168.100.100 192.168.100.150;
}
=============================================================================
– PXE 설정하기
PXE 설정의 redhat-config-netboot란 명령을 이용하거나 수동으로 설정을 할 수 있다.
Redhat-config-netboot를 이용할 경우는 Master Server 운영체제 설치 시 X 관련 package를 포함하여야 한다.
이 문서에서는 pxe 관련 command를 이용한 수동 설정과 실제 설정 파일을 바로 수정하여 설정을 하는 방법에 대해 설명하도록 하겠다.
*** pxe utile 을 이용하여 설정 하는 방법
설치 OS 구분 추가 :
pxeos -a -i “설명” -p <install_protocol> -D 0 -s <server_name> \\
-L <net-location> <os-identifer>
예)
pxeos -a -i “Redhat ES3” -p NFS -D 0 -s 192.168.100.254 -L /home/clunix/teragon teragon
클라이언트 구분 추가 :
pxeboot -a -O <os-identifer> -r <ramdisk_size> <host>
예 )
pxeboot -a -O teragon -r 10000 192.168.100.1
클라이언트 환경은 /tftpboot/linux-install/pxelinux.cfg/ 밑에 생성이 된다.
각 접속될 클라이언트 별( 구분은 클라이언트 IP 로 한다 )로 부팅 이미지와 ks 파일을
지정할수 있게 설정 파일이 나누어진다. 지정된 클라이언트가 아닌 시스템에서 접속한
경우에는 default 에 지정된 부팅 이미지로 부팅을 하게 된다. 기본적인 설정은
부팅이미지와 ramdisk size 정도 지정되어져 있다. 만일 별도의 kickstart 파일을
이용하여 자동 설치를 원할 경우에는 아래와 같이 ks 관련 append 를 추가 해 주어야
한다. ks 관련 설정은 반드시 기존의 append 설정 뒤에 붙여서 사용하여야 한다.
/tftpboot/linux-install/pxelinux.cfg/default 를 열어보면..
default local
timeout 100
prompt 1
display msgs/boot.msg
F1 msgs/boot.msg
F2 msgs/general.msg
F3 msgs/expert.msg
F4 msgs/param.msg
F5 msgs/rescue.msg
F7 msgs/snake.msg
label local
localboot 1
label 0
localboot 1
label 1
kernel linux-install/teragon/vmlinuz
append initrd=linux-install/teragon/initrd.img ramdisk_size=10000 \\
ks=nfs:192.168.100.254:/home/clunix/teragon-pkg/ks.cfg ip=dhcp ksdevice=eth0
=============================================================================
특정 노드에 대한 자동 설정을 하고 쉽다면
/tftpboot/linux-install/pxelinux.cfg/C0A86401 와 같이 특정 호스트에서 접속할 경우
특정 부팅 이미지로 부팅을 시킬 수 있다.
# vi /tftpboot/linux-install/pxelinux.cfg/C0A86401
=============================================================================
default teragon
label teragon
kernel linux-install/teragon/vmlinuz
append initrd=linux-install/teragon/initrd.img console=tty0 ramdisk_size=10000 \\
ks=nfs:192.168.100.254:/home/clunix/teragon-pkg/ks.cfg ksip=192.168.200.1 ksnm=node01 ksdevice=eth0
=============================================================================
*** 설정 파일을 직접 수정하여 PXE 설정하는 방법
# mkdir /tftpboot/linux-install/teragon
# cp /home/clunix/teragon-pkg/images/pxeboot/vmlinuz /tftpboot/linux-install/teragon
# cp /home/clunix/teragon-pkg/images/pxeboot/initrd.img /tftpboot/linux-install/teragon
tftpboot/linux-install/pxeconfig.cfg/default 편집
=============================================================================
default local
timeout 100
prompt 1
display msgs/boot.msg
F1 msgs/boot.msg
F2 msgs/general.msg
F3 msgs/expert.msg
F4 msgs/param.msg
F5 msgs/rescue.msg
F7 msgs/snake.msg
LABEL local
localboot 1
LABEL node00
KERNEL teragon/vmlinuz
APPEND initrd=teragon/initrd.img ramdisk_size=10000 \\
ks=nfs:192.168.100.254:/home/clunix/teragon-pkg/ks.cfg ksdevice=eth0 \\
ksip=192.168.100.254 ksnm=node00
LABEL node01
KERNEL teragon/vmlinuz
APPEND initrd=teragon/initrd.img ramdisk_size=10000 \\
ks=nfs:192.168.100.254:/home/clunix/teragon-pkg/ks.cfg ksdevice=eth0 \\
ksip=192.168.100.1 ksnm=node01
=============================================================================
이제 클라이언트 시스템을 부팅하였을때 클라언트 시스템에 OS 가 설치된 환경이 아니면
자동으로 서버에 접속하여 서버의 부팅 이미지를 가져 오게 된다.
다른 부팅 매체 및 이미지가 존재 할 경우 PXE Network boot 관련 단축키 ( F12 ) 를 부르면
PXE로 접속하게 된다.
**** 2005년 1월 17일 Sun-FZ440 (Opteron System) 설치 당시 문제점 :
FZ440 시스템에 Redhat ES3-update 3 버전으로 설치를 하였다. PXE 접속하여 OS 설치까지는
무사히 잘 되었는데 설치 완료 후 리부팅 후 bootloader 를 불려 오지 못하는 문제 발생
kickstart file 수정등으로 재 시도를 해 보았지만.. 동일 증세 발견 ..
문제 원인은 Redhat ES3-update3 -amd 버전의 배포 CD 의 isolinux/ 밑의 부팅 관련 이미지
들의 문제임.
당초 CD1 으로 CDROM 부팅이 안되어서 CD1/images/boot.iso 파일의 이미지를 다시 풀어서
부팅이 가능한 문제가 있었는데 설치 이후 기본 부팅 이미지를 덮어 쓰는데 문제 있는
이미지를 덮어 쓰는 문제가 발생함.
어려움이 많았음
그리고 bootscripts 에 관련된 패키지가 설치가 안 되는 문제가 발생하였다.
이는 잘못된 정보로 hdlist 를 생성해서 발생한 문제다. 그냥 기본 CD1 에 있는 hdlist 로
패키지리스트를 구성하면 된다
**** ks config sample file ****
redhat-config-kickstart
=============================================================================
#Generated by Kickstart Configurator
#System language
lang en_US
#Language modules to install
langsupport ko_KR.eucKR –default=en_US
#System keyboard
keyboard us
#System mouse
mouse generic3ps/2
#Sytem timezone
timezone Asia/Seoul
#Root password
rootpw –iscrypted $1$I4KvFDeP$nz5hBVDYcdWgfmQgljUEG0
#Reboot after installation
reboot
#Install Red Hat Linux instead of upgrade
install
#Use NFS installation Media
nfs –server=192.168.100.254 –dir=/home/clunix/teragon-pkg
#System bootloader configuration
bootloader –location=mbr
#Clear the Master Boot Record
zerombr yes
#Partition clearing information
clearpart –all –initlabel
#Disk partitioning information
part /boot –fstype ext3 –size 200 –ondisk sda
part / –fstype ext3 –size 3000 –asprimary –ondisk sda
part /usr –fstype ext3 –size 10000 –ondisk sda
part /var –fstype ext3 –size 3000 –ondisk sda
part swap –size 4000 –ondisk sda
part /home –fstype ext3 –size 1 –grow –ondisk sda
#System authorization infomation
auth –useshadow –enablemd5
#Firewall configuration
firewall –enabled
#Do not configure XWindows
skipx
#Package install information
%packages –resolvedeps
@ X Window System
@ GNOME Desktop Environment
@ Editors
@ Engineering and Scientific
@ Graphical Internet
@ Text-based Internet
@ Server Configuration Tools
@ DNS Name Server
@ Network Servers
@ Development Tools
@ Kernel Development
@ X Software Development
@ GNOME Software Development
@ Administration Tools
@ System Tools
%post
=============================================================================
custom kick start file
=============================================================================
lang ko_KR.eucKR
langsupport –default=ko_KR.eucKR
keyboard us
mouse generic3ps/2
timezone Asia/Seoul
rootpw –iscrypted $1$nC947A.0$7k8ULqNdFZhOYDrnhz3ai1
text
install
nfs –server=192.168.100.254 –dir=/home/clunix/teragon-pkg
bootloader –location=mbr
zerombr yes
clearpart –all
part /boot –fstype ext3 –size 200 –ondisk sda
part / –fstype ext3 –size 3000 –ondisk sda –asprimary
part /usr –fstype ext3 –size 10000 –ondisk sda
part swap –size 4000 –ondisk sda
part /var –fstype ext3 –size 3000 –ondisk sda
part /home –fstype ext3 –size 100 –grow –ondisk sda
authconfig –enableshadow –enablemd5
#network –device eth0 –bootproto none
#network –device eth1 –bootproto none
firewall –enabled –trust=eth0
skipx
%packages
@ engineering-and-scientific
@ legacy-software-development
@ editors
@ system-tools
@ base-x
@ gnome-software-development
@ development-tools
@ text-internet
@ x-software-development
@ legacy-network-server
@ dns-server
@ gnome-desktop
@ admin-tools
@ compat-arch-development
@ authoring-and-publishing
@ korean-support
@ server-cfg
@ network-server
@ kernel-development
@ graphical-internet
@ compat-arch-support
krb5-server
rsh-server
-lam
kernel
kernel-smp
rsh-enable
dutil
%post –interpreter /bin/bash
#### setting IP ADDR ############################
stringZ=`cat /proc/cmdline`
for service in $stringZ
do
if [ `expr match “$service” “ksip=”` -eq “5” ] ; then
IPADDR=${service:5}
fi
if [ `expr match “$service” “ksnm=”` -eq “5” ] ; then
NAME=${service:5}
fi
done
echo “DEVICE=eth1” > /etc/sysconfig/network-scripts/ifcfg-eth1
echo “BOOTPROTO=static” >> /etc/sysconfig/network-scripts/ifcfg-eth1
echo “IPADDR=${IPADDR}” >> /etc/sysconfig/network-scripts/ifcfg-eth1
echo “NETMASK=255.255.255.0” >> /etc/sysconfig/network-scripts/ifcfg-eth1
echo “ONBOOT=yes” >> /etc/sysconfig/network-scripts/ifcfg-eth1
echo “NETWORKING=yes” > /etc/sysconfig/network
echo “HOSTNAME=${NAME}” >> /etc/sysconfig/network
#################################################
chkconfig gpm off
chkconfig kudzu off
chkconfig netfs off
chkconfig random off
chkconfig rawdevices off
chkconfig atd off
chkconfig audit off
chkconfig acpid off
chkconfig isdn off
chkconfig iptables off
chkconfig ip6tables off
chkconfig autofs off
chkconfig portmap off
chkconfig nfslock off
chkconfig mdmonitor off
chkconfig cups off
chkconfig rhnsd off
chkconfig hpoj off
chkconfig xfs off
chkconfig arptables_jf off
/root/rsh.enable
=============================================================================
2. Teragon HPC Network 설정 하기
2.1 Network channel 이중화
HPC 시스템에서 Network resource를 주로 사용하는 용도는 운영체제 부분과 계산 부분으로 나누어 진다.
즉 NFS 파일 서비스, 데이터 동기화, 서버 관리 작업 등에 사용되는 운영체제 관련 부분과 실제 MPI 계산에
이용되는 계산 부분이 있다. 만일 하나의 네트워크 인터페이스를 이용하여 시스템을 구성할 경우 계산 시
운영체제 부분에 해당하는 작업에 인해 계산 성능이 저하될 수 있기에 운영체제 부분과 계산 부분의 네트워크
대역을 분리하여 구성한다.
분리 방식은 /etc/hosts 구성에서 운영체제에서 이용되는 hostname 과 계산에 이용되는 hostname
을 분리하는 방법을 이용한다.
# vi /etc/hosts
=============================================================================
# using administration, file service
192.168.0.254 node00
192.168.0.1 node01
192.168.0.2 node02
.
.
.
# using math node – calculation, computation
192.168.10.254 real00
192.168.10.1 real01
192.168.10.2 real02
.
.
=============================================================================
nfs 설정 및 dua, dush등의 운영체제 관련 서비스에는 모두 nodeXX 형식의 hostname 을 사용하고
lammpi, mpich 등의 병렬 계산에 사용되는 hostname은 모두 realXX 형식으로 지정하여 실제 관리
및 파일 서비스에 이용되는 네트워크 채널과 계산에 이용되는 네트워크 채널을 분리하여 사용한다.
2.2 rsh, rlogin 설정 및 사용
rlogin, rsh 관련 서비스를 구동하기 위해서는 rsh, rsh-server 두 개의 패키지가 설치가 되어 있어야 한다.
rlogin, rsh 는 MPI 와 같은 병렬 프로그램이 프로세스간 통신을 할 때 사용되는 주요 프로토콜이다.
계산 뿐만 아니라 여러 대로 구성된 HPC 시스템에서 다수의 노드를 관리 하기 위해서는 rsh 와 같은 인증
방식이 필요하다. 하지만 UNIX 시절 보안에 많은 취약점이 나타난 적이 있었고, 관리자의 부주의로 인한
보안 상의 문제도 많이 제기 되어 사용을 다소 주저하는 경우도 많다. 하지만 설정 시 보안에 신경만 써
주면 염려와 같은 문제는 발생하지 않는다. 대부분의 문제는 프로그램 자체의 취약점이 아닌 관리자의
부주의로 인해 발생되는 문제 이다. Rsh, rlogin 보안에 대한 자세한 내용은 후반부의 HPC 보안 설정
부분에서 상세히 설명하도록 하겠다.
– rsh, rlogin 설정
** xinetd 데몬에서 rsh, rlogin 서비스를 사용할 수 있도록 설정을 변경한다.
# vi /etc/xinetd.d/rsh
—————————————————————————–
service shell
{
disable = no
socket_type = stream
wait = no
user = root
log_on_success += USERID
log_on_failure += USERID
server = /usr/sbin/in.rshd
}
—————————————————————————–
# vi /etc/xinetd.d/rlogin
—————————————————————————–
service login
{
disable = no
socket_type = stream
wait = no
user = root
log_on_success += USERID
log_on_failure += USERID
server = /usr/sbin/in.rlogind
}
—————————————————————————–
설정을 변경한 후 xinetd 데몬을 restart 한다.
# /etc/rc.d/init.d/xinetd restart
** 기본적으로 root 관리자 계정에서는 rsh, rlogin 사용이 금지 되어져 있다. 하지만 root 에서도
다수의 서버를 관리 하기 위해서 rsh, rlogin을 사용하는 경우가 있는데 이때는 아래 설정을 해준다.
# vi /etc/securetty
—————————————————————————-
.
..
…
rsh
rlogin
—————————————————————————-
** rsh, rlogin 서비스를 허용할 hosts 와 users 설정을 한다.
# vi /etc/hosts
—————————————————————————–
127.0.0.1 localhost
# 운영체제 네트워크 대역
192.168.10.254 master
192.168.10.1 node01
192.168.10.2 node02
192.168.10.3 node03
192.168.10.4 node04
192.168.10.5 node05
192.168.10.6 node06
.
# 계산 네트워크 대역
192.168.20.254 real00
192.168.20.1 real01
192.168.20.2 real02
192.168.20.3 real03
192.168.20.4 real04
192.168.20.5 real05
192.168.20.6 real06
—————————————————————————–
** 시스템의 모든 일반 유저 계정에서 rsh, rlogin을 사용하기 위해서는 아래 설정을 해준다.
# vi /etc/hosts.equiv
—————————————————————————–
master
node01
node02
node03
…..
real00
real01
real02
…..
—————————————————————————–
** 만일 특정 계정에서만 rsh, rlogin 서비스를 이용할 경우는 각 계정의 홈폴더에 .rhosts 란
파일을 만들고 아래 설정을 한다.
# vi $HOME/.rhosts
—————————————————————————–
master
node01
node02
node03
…..
Real00
Real01
Real02
……
—————————————————————————–
.rhosts 설정에서는 각 노드 간의 rsh 접속이 동일한 계정 사이에서만 기본적으로 이루어 진다.
만일 clunix 계정으로 root 의 권한으로 rsh 접속을 하기 위해서는 root 의 .rhosts 에 아래와 같이
해 주어야 한다.
# vi /root/.rhosts
—————————————————————————–
master
node01
node02
node03
node04
node05
node06
master clunix
node01 clunix
node02 clunix
node03 clunix
node04 clunix
node05 clunix
node06 clunix
—————————————————————————–
.rhosts 와 /etc/hosts.equiv 파일은 보안 상 중요한 파일임으로 반드시 퍼미션을 644 혹은 600으로 변경을 해주도록 한다.
# chmod 600 $HOME/.rhosts
# chmod /etc/hosts.equiv
– rsh 사용 방법
*** rsh 사용 방법
usage: rsh [ -l username ] host [command]
*** rsh를 이용한 접속 법
[root@client root]# rsh server
Last login: Fri Jul 26 15:34:43 from tech
You have new mail.
[root@server root]#
*** remote shell 사용법
[root@client root]# rsh server ps
??PID TTY??????????TIME CMD
????1 ?????????00:00:04 init
????2 ?????????00:00:00 keventd
????3 ?????????00:00:00 kapmd
????4 ?????????00:00:00 ksoftirqd_CPU0
????5 ?????????00:00:00 kswapd
????6 ?????????00:00:00 bdflush
????7 ?????????00:00:00 kupdated
????8 ?????????00:00:00 mdrecoveryd
?? 12 ?????????00:00:00 kjournald
?? 91 ?????????00:00:00 khubd
??247 ?????????00:00:00 kjournald
위의 “rsh server ps” 명령어는 client host 에서 server host로 접속하지 않고도
server host 의 process check 명령어 ps를 이용하는 예제 이다.
2.3 SSH 설정
Rsh 계열 프로토콜의 보안적인 문제에 대한 거부감에 rsh 사용을 거부 하는 경우도 많다.
이런 경우 보안적 측면에서의 안정성이 강한 SSH를 패스워드 인증 방식이 아닌 인증키를
이용한 인증 방식으로 구축 하면 된다. RSH 가 무조건 보안에 취약한 것은 아니지만..
사용자의 눈 높이에 맞추는 차원에서는 초기 구축 시 SSH를 이용하는 방식을 권장한다.
설정 방법은 아래와 같다.
ssh-keygen 으로 공개인증키를 생성하면 실제 시스템 패스워드를 이용하여 접속하는
것이 아니라 인증키 패스워드를 이용하여 접속이 가능하다.
인증키 생성시 패스워드를 공백으로 처리하면 전 노드를 ssh로 접속할 때 암호 없이
접속이 가능하다.
** node01 설정
[root@otn01 root]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): – 엔터
Enter passphrase (empty for no passphrase):
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
8f:c6:f2:05:69:f4:2f:f0:35:b1:57:ac:ac:2b:ea:df root@otn01
그럼 /root/.ssh/id_rsa.pub 파일이 생성된다. 이 파일의 내용을 보면 아래와 같다.
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA0lAeGFDgSDPMJNeydJiWSuT2XVc7YO+i1o\\
6qSStY67jVHqxkCkvMJbWkohT0cLDJB9NAqjpVUBc8U7l/g6uSe9VyV/Aq2kuvAWTwpajZ\\
9B1XomvCauA1kahv3xESziYhJjEfKBdSRiDmlcKTOFcpKP0Z2Akyx+83N2RbhaC+mAU= root@otn01
이 내용을 node01 에서 접속할 노드의 /root/.ssh/authorized_keys 파일안에 복사해
두면된다.
클러스터 시스템처럼 여러 노드가 존재할 경우는 일단 모든 노드에 ssh-keygen 를
이용하여 공개 인증키를 생성한 후 각 노드의 공개 인증키 내용을 순차적으로 하나
의 authorized_keys 로 생성하고 이 키를 전 노드에 /root/.ssh 밑에 동기화 시켜
주는 방식으로 구현하면 노드 간의 ssh 접속이 암호 없이 가능하게 된다.
2.4 Dutils 설치 및 설정
dua, dush 는 Encluster-HPC 의 다중 서버 관리 도구이다. 즉 여러 대의 서버에
file 및 작업 명령을 일괄적으로 처리하도록 해주는 프로그램이다.
dua, dush 를 정상적으로 사용하기 위해서는 앞에서 설명한 rsh, rlogin 서비스
설정이 완료되어 있어야 한다.
먼저 Master Node 에 dutil-1.2.1-1.noarch.rpm 를 설치 한다.
# rpm -Uvh dutil-1.2.1-1.noarch.rpm
실제 dua, dush 를 이용하여 일괄 관리 할 서버 리스트를 작성한다.
# vi /usr/clx/etc/nodelist
—————————————————————————–
master
node01
node02
node03
node04
node05
node06
—————————————————————————–
** dua : file 을 nodelist 에 포함된 모든 Node 에게 일괄적으로 sync 시키는 도구
** dush : nodelist 의 포함된 node 에게 일괄적으로 내려진 작업을 수행한다.
공통 옵션 설명 :
-l : /usr/clx/etc/nodelist 이외의 다른 nodelist 를 참조할 경우 -l 옵션으로 호출
할수 있다.
예) dua -l /etc/nodelist /root
-n : nodelist 에 포함된 모든 node 가 아닌 특정 node 에만 작업을 수행할 경우 사용됨
예) dua -n node03 /root
-p : 작업을 순차적으로 처리하는 것이 아닌 backgroud mode 로 동시에 작업이 수행된다
예) dush -p “/etc/rc.d/init.d/ecmctl restart”
-s : 노드간 수행 결과를 구분하기 위한 ###executing…” 이란 메세지가 나타나지 않고
수행 결과만을 출력해 주는 옵션이다.
-d : dua 에서 사용되는 옵션으로 디렉토리간의 완전한 sync 를 할때 사용된다.
즉 master 와 node02 의 디렉토리 내용을 완전히 sync 시킬때 사용되는 옵션으로
그냥 # dua /root 라 수행하면 master 의 /root 내용이 node02 의 /root 로 파일이
복제 되지만 # dua -d /root 라 수행하면 node02가 master 보다 더 많은 파일을
가지고 있다면 master 에 없는 파일은 모두 삭제해 버리고 완전 master 와 동일한
자료만을 가지게 된다.
2.5 NFS 설정
MPI 병렬 프로그램 사용 시 모든 계산 서버의 같은 PATH에 동일한 실행 파일이 존재 해야 한다.
이런 이유로 인해 노드 별 별도의 하드 디스크를 가지고 있는 경우 dua 와 같은 디스크 동기화
프로그램을 사용하거나 PVFS, GFS 같은 클러스터 파일 시스템을 사용한다. 이밖에 경제적,
관리적 이슈로 인해 NFS 와 같은 방식으로 특정 서버의 디스크를 공유하여 방법도 많이 사용한다.
여기서는 NFS 설정 방법과 효율적인 관리 방법에 대해 다루도록 한다.
– NFS 기본 설정
# vi /etc/exports
—————————————————————————–
# NFS 원격 설치 시 사용되는 경로
/data/clunix/teragon *(ro,soft,no_root_squash)
# 사용자 Data 보관에 이용되는 경로
/data/users *(rw,soft,no_root_squash)
—————————————————————————–
# exportfs -a
# /etc/rc.d/init.d/portmap restart
# /etc/rc.d/init.d/nfs restart
이것을 HPC에 적절한 Nfs 설정이 완료된다.
# mount -t nfs master:/data/clunix/teragon /mnt/teragon
# mount -t nfs master:/data/users /mnt/users
등의 잘 nfs mount 가 되는 지를 확인한다.
– nfs 설정 후 사용자에게 nfs 디스크를 할당 해 주는 방안..
홈 디렉토리 자체를 nfs 상에 만들면 nfs 에 문제가 있을 때 로그인이 될 수가 없다.
이를 피하기 위해서는 홈 디렉토리는 로컬 하드 상에 만들고 홈 디렉토리 밑에 data 파일
을 nfs 디스크 상에 링크 형태로 만들어 대용량 파일을 이곳에 보관하는 방식으로
설정한다.
먼저 /nfs 디렉토리의 퍼미션을 1777 로 하여 자신의 파일에만 제어 권한을 준다.
# chmod 1777 /nfs
# vi /etc/skel/.bashrc
—————————————————————-
userid=`whoami`
if [ ! -d /nfs/$userid/ ]
then
mkdir /nfs/$userid
ln -sf /nfs/$userid $HOME/data
chown -R $userid. /nfs/$userid
else
ln -sf /nfs/$userid $HOME/data
rm -f $HOME/data/$userid
fi
—————————————————————
위 스크립터에서 /nfs 는 실제 nfs 디렉토리라고 생각해야 한다.
[root@node00 root]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda3 10080520 148852 9419600 2% /
/dev/hda1 202220 14518 177262 8% /boot
none 514940 0 514940 0% /dev/shm
/dev/hda2 10080520 1547244 8021208 17% /usr
/dev/hda6 2016016 200712 1712892 11% /var
/dev/hda7 9775216 512684 9262532 6% /usr/local
/dev/hda8 43534780 32848 43501932 1% /home
/dev/sda5 234429320 32840 234396480 1% /data1
node00:/data1 234429320 32840 234396480 1% /nfs
와 같이..
사용자 계정을 만들고 처음 로그 인을 하면 nfs 상에 자신의 이름으로 디렉토리
를 만든다. 그런 후 자신의 홈 디렉토리 및에 data 란 파일로 링크를 건다.
만일 /nfs 파일 밑에 이미 자신의 이름과 동일한 디렉토리가 있으면 ..
그냥 자신의 퍼미션으로 퍼미션 변경만을 하게 된다.
– automount 를 이용하여 사용자에게 nfs 공간을 할당 하는 방안
automount 에는 am-utils ( amd ), autofs 두 가지의 패키지가 있다.
Redhat9 에서는 기본적으로 autofs 를 채택하고 있다.
간단한 설정에 대해 알아보자.
주요 설정 파일은 ..
/etc/auto.master
/etc/auto.misc
이 있다.
# vi /etc/auto.master
======================================================================
/home /etc/auto.user01 –timeout=5
# vi /etc/auto.user01
======================================================================
user01/data -fstype=nfs,rw,soft,bg master:/data/nfs/user01
# /etc/rc.d/init.d/portmap restart
# /etc/rc.d/init.d/autofs restart
/home/user01/data 로 이동하면 자동으로 master 의 /data/nfs/user01
로 nfs mount 가 된다.
automount 를 사용하게 되면 실제 사용자가 지정된 mount point 에 접근 시에만
자동으로 nfs mount 하고 일정 시간 사용을 하지 않으면 자동으로 umount 를 시
키기 때문에 nfs 서비스로 인한 resource 를 최대한 절약 할 수 있고, 여러명이
지속저으로 Nfs 를 사용할 경우 1개의 곳에서 lock 이 결려도 전체 서비스에 문
제가 생길 가능성이 있는데 automount 로 상당 부분 해소할 수 있다.
autofs-4.x 버전에서는 multiple hostname 기능이 지원한다.
이는 먼저 master 로 Connection 요청을 해서 정상적인 요청이 이루어 지지
않으면 slave 에 연결이 된다. Redhat9 에서는 기본적으로 autofs-3.x 임으로
autofs-4.x 로 업그레이드를 해야 한다.
http://www.kernel.org/pub/linux/daemons/autofs/
– NFS mount 상세 옵션 설명
NFS Clients 에서의 nfs.mountd option으로 soft,hard,timeo,rsize,wsize… 등등
많은 option 이 있는데 이중에서 가장 최적화된 옵션을 찾아 되는 것은 남겨진 숙제이다.
주요 옵션 설명이다.
rsize=n NFS 서버로부터 읽어들이는 바이트 수를 지정 한다. 기본값은
커널에 따라다른데 현재로서는1024 바이트이다.
wsize=n NFS 서버에 쓰기를 할 때 사용하는 바이트 수 를 정한다.
기본값은 커널에 따라다른데 현재 로서는 1024 바이트이다.
timeo=n RPC 타임아웃이 생기고 나서 첫번째 재전송 요 구를 보낼 때 사용되는 시간으로서
1/10 초 단 위이다. 기본값은 7 * 1/10 초이다. 첫번째 타 임 아웃이 생기고 나서는
타임아웃 시간이 최대 치인 60 초에 이르거나 너무 많은 재전송 요구 가 벌어 질 때
까지 타임아웃 시간이 2 배로 변화 한다. 만약 파일 시스템이 hard ( hard 옵션을
참고 ) 마운트 되어있다면 각각의 타 임 아웃 시간은 2 배로 증가하고 재전송 시도
가 일어날 때도 2 배로 증가한다.
최대 타임아웃 시간은 60 초이다. 네트웍 속도가 느리거나 서버 자체가 느리다든지
여러 개의 라우터와 게 이트웨이를 거칠 때는 마운트 당시 타임 아웃 시간을 늘려
주는 것이 좋다.
retrans=n 주 타임아웃을 발생시키는 부 타임아웃과 재전 송 횟수를 정한다. 기본값은 3 번의
타임아웃이다. 주 타임 아웃이 일어나면 화일 작업이 중지 되거나 콘솔 상에
“서버가 반응하지 않음 “server not responding””이라는 메시지가 출력 된다.
retry=n 백그라운드에서 진행 중인 NFS 마운트 작업 이 포기하기 전까지 실행할 횟수를정한다.
기본값 은 10000 번이다.
namlen=n NFS 서버가 RPC 마운트 프로토콜의 버전 2 를 지원하지 않을 때 원격 파일
시스템에서 지원 되는 파일 명의 길이를 명시한다.
POSIX pathconf 함 수 를 지원 하기 위해서 사용된다.
기본값은 255 개의 문자이다.
port=n NFS 서버와 연결할 수 있는 포트 번호를 정 한다. 만약 0 이라면( 기본값 ) 원격
호스트의 포트매퍼(portmapper) 에게 질의 하여 알아내도록 한다.
만약 포트매퍼에 NFS 데몬이 등록되어 있지 않은 경우에는 2049 라는 표준 NFS
포트 번호가 사용된다.
mountport=n mountd 포트 번호 지정하기.
mounthost=name mountd 를 실행 중인 호스트 명을 정한다.
mountprog=n 원격 호스트의 마운트 데몬과 접속하기 위해 사용할 수 있는 별도의 RPC
프로그램번호를 정 한다. 만약 여러 개의 NFS 서버를 운영하고 있을 때
사용한다. 기본값은 표준 RPC 마운트 데몬 프로그램 번호인 100005 이다.
bg 만약 첫 번째 NFS 마운트 시도가 타임아웃 걸리 면 백그라운드에서 실행을 계속
된다. 기본 값은 백그라운드로 실행하지 않고 그냥 포기한다.
fg 첫번째 NFS 마운트 시도에서 타임아웃이 걸 리 면 그 즉시 포기 해 버린다.
기본값이다.
soft NFS 화일 작업에서 주 타임아웃이 걸리면 프로 그램에게 I/O 에러를 보고한다.
기본값은 무한히 NFS 화일 작업을 재시도 하는 것이다.
hard NFS 화일 작업에서 주 타임아웃이 걸리면 콘솔 상에 “server not responding”,
“서버가 반응 하지 않음” 이라고 출력하고 무한히 재시도한다.
이것이 기본값이다.
intr 주 타임아웃이 생기고 하드 마운트 된 상태라면 화 일 작업을 중지하도록 시그널
을 보내도록 허용하고 EINTR 시그널을 보내다.
기본값은 화일 작업을 인터럽트 하지 않는 것이다.
tcp NFS 화 일 시스템을 기본값인 UDP 가 아니라 TCP 프로토콜을 사용하여
마운트 하도록 한다.
많은 NFS 서버들이 오로지 UDP 만을 지원한다.
udp NFS 화일 시스템을 UDP 프로토콜로 마운트 한다. 기본값.
2.6 NIS 계정 통합 시스템 설정
NIS 서버를 이용하여 통합 계정 인증 시스템을 만드는 대표적인 방법은 크게 정통적인 Sun 의
yellow page 에서 유래된 yp 와 ldap project 에서 나온 openldap 을 이용하는 방법이 있다.
openldap 의 경우에는 다른 application 과의 계정 연동 부분도 많이 지원 하고 있는 만큼 그
크기나 깊이가 아주 광범위 하다고 볼 수 있다.
여기서는 간단히 ypserv, ypbind 를 이용한 NIS로 통합 계정 인증 시스템을 구현하는 방법에
대해 알아보겠다.
– 서버,클라이언트 공통 설정 부분
일단 yp 관련 클라이언트 tool 이 설치 되어져 있어야 한다.
# rpm -Uvh ypbind-x.x.x.rpm
# rpm -Uvh yp-tools-x.x.x.rpm
# rpm -Uvh ypserv-x.x.x.rpm -> 계정 서버일 경우에 설치
/etc/host.conf 파일에 multi on 설정을 추가 한다.
# vi /etc/host.conf
——————————————————————–
order hosts,bind
multi on
——————————————————————–
NIS 도메인 이름을 결정한다. ( DNS 의 도메인 과 NIS 도메인은 다른 차원의 것이다. )
# nisdomainname < NISDOMAIN >
/etc/sysconfig/network 에 NISDOMAIN 내용을 추가 한다.
# vi /etc/sysconfig/network
——————————————————————–
NETWORKING=yes
HOSTNAME=test03
GATEWAY=192.168.123.254
NISDOMAIN=< NISDOMAIN >
——————————————————————–
– 서버 설정
그런후 NIS 시스템에서 shadow file 을 인식 할수 있게 설정을 변경한다.
/var/yp/Makefile 을 열어서 all: 로 문자열을 검색하면
# vi /var/yp/Makefile
——————————————————————–
.
.
all: passwd group hosts rpc services netid protocols mail \\
# publickey shadow netgrp networks ethers bootparams printcap \\
# amd.home auto.master auto.home auto.local passwd.adjunct \\
# timezone locale netmasks
나온다. 여기서 주석내용중의 shadow 를 주석 밖으로 빼내준다
all: passwd group hosts rpc services netid protocols mail shadow \\
# publickey netgrp networks ethers bootparams printcap \\
# amd.home auto.master auto.home auto.local passwd.adjunct \\
# timezone locale netmasks
———————————————————————
그런 후 ypserv 와 yppasswd 를 시작 해 준다. 기본적으로 yp 는 rpc 를 이용하는 서비스
임으로 portmap 을 먼저 실행하여야 한다.
# /etc/rc.d/init.d/portmap start
# /etc/rc.d/init.d/ypserv start
# /etc/rc.d/init.d/yppasswdd start
# chkconfig –level 345 portmap on
# chkconfig –level 345 ypserv on
# chkconfig –level 345 yppasswd on
계정 인증 서버의 계정 정보를 클라이언트 서버로 전달 가능한 Map 으로 만든다.
# make -C /var/yp
위 단계가 바로 인증 서버의 계정 정보를 다른 서버들과 공유 가능한 계정 정보로 만드는
작업니다. 그렇기에 인증 서버의 계정 정보의 변경이 있는 경우 반드시 위 과정을 실행해
야 클라이언트에서 변경된 계정 정보를 인식 할수 있다.
– 클라이언트 설정
클라이언트에서는 ypserver 의 계정 정보를 rpc 를 통해 사용하기 위해서 계정 서버의 정보
를 퀴리를 할수 있는 ypbind 같은 프로그램이 필요하다.
ypbind 설정은 /etc/yp.conf 를 수정하면 된다.
# vi /etc/yp.conf
————————————————————————–
ypserver < NISDOMAIN server for HOSTNAME >
domain < NISDOMAIN server for HOSTNAME >
————————————————————————–
그런 뒤 ypbind 를 실행한다. ypbind 역시 portmap 이 먼저 실행 되어야 한다.
# /etc/rc.d/init.d/portmap restart
# /etc/rc.d/init.d/ypbind restart
그런 후 /etc/passwd, /etc/group 설정에서 nis 로 계정을 인증 하겠다는 형식이 추가 되어야 한다.
/etc/passwd 파일의 제일 하단에 < +:*:0:0::: > 을 추가해 준다.
/etc/group 파일의 제일 하단에 < +:*:0:0: > 을 추가해 준다.
# vi /etc/nsswitch.conf
————————————————————————–
.
.
passwd: files
shadow: files
group: files
위 내용을 ..아래로 변경 ..
passwd: files nisplus nis
shadow: files nisplus nis
group: files nisplus nis
————————————————————————–
클라이언트 설정 완료 후 클라이언트 시스템은 리부팅을 해주어야 한다. nsswitch 설정 적용을
위해서~
이제 위 내용으로 계정 연동이 완료되어 진다. 즉 ypserv 에 계정을 생성하고 make -C /var/yp
로 생성 내용을 갱신 하면 ypserv 에 연동된 클라이언트 시스템으로 접속하여 새로 생성된 계정
으로 ssh 나 telnet 접속을 하면 성공하여야 한다.
정상적으로 동작하는 것을 확인 하는 방법으로는 yp-tools 에 있는 명령어를 이용하면된다.
# yptest
# ypcat passwd
위 명령을 사용하면 실제 ypserv 측의 계정 정보와 패스워드 정보들이 출력될것이다.
클라이언트 서버에서 ypserv 계정의 패스워드 변경을 할때는 yppasswd 명령을 사용한다.
# yppasswd < userid >
이로서 ypserv 를 이용한 계정 통합 인증 시스템에 대해 알아 보았다. yp 는 간단한 구성의 시스템
인증에 많이 사용되어진다. 복잡한 어플리케이션 인증 시스템으로는 yp 보다는 openldap 으로 구성
하는것이 효율적일것이다.
yp 로 구성하면 앞에서 설명했듯이 ypserv 에서의 계정 정보가 변경되면 반드시 /var/yp 의 map 을
재 갱신 시켜주어야 한다. 그렇기에 실시간으로 계정 정보를 인식하지는 못한다.
어플리케이션 인증 측면에서는 이해 할수 없겠지만 OS 차원에서의 계정 인증에서는 그렇게 문제가
되는 부분은 아니라고 생각한다. 계정 정보를 변경하고 갱신 명령만 한번 실행하면 수십대의시스템
의 계정을 한대의 서버에서 관리 할수 있기 때문에 상당히 효율적이라고 볼수 있다.
이런게 귀찮은 경우는 별도의 계정에 관련된 명령어 ( adduser, useradd, userdel, passwd )등을
yp 관련 명령어와 적용하여 scripts 를 만들거나 아님 cron 등에 짧은 주기로 등록해 두면 효과
적일거라 생각한다.
이런 관리적인 측면 말고 yp 나 ldap 같은 계정 인증 통합 시스템에서는 반드시 사용자의 홈 폴더가
로컬디스크 상에 있으면 안 되는 점이 있다. 즉 사용자 홈 폴더는 NFS 등으로 하나로 통합해야 하는
주의점이 있다. 즉 계정은 계정 서버를 통해 인증되어 접속을 가능하지만 홈폴더가 계정 서버 자체
에만 생성이 됨으로 현재 접속하는 서버에 홈 폴더가 없기에 문제가 발생할 수 있다. 이러한 부분
때문에 홈 폴더가 NFS 등으로 구성된 시스템에서는 yp를 이용한 NIS 서버를 사용하고 홈 폴더가
시스템 별로 분리된 시스템 구성에서는 3장에서 설명할 HPC Management Tool의 분산 시스템
일괄 계정 관리 프로그램을 이용하여 계정을 관리하면 될 것이다.
3. Teragon HPC 설정 하기
3.1 Time Sync 설정
클러스터 시스템에서는 노드 간의 시스템 시간이 일치해야 하는 경우가 있다. 즉 병렬 프로그램에서
프로세스의 시간을 기준으로 많은 프로그램을 하게 되는데 이가 일치 하지 않으면..프로세스간 통신
상에 문제가 발생할 수 있다. 그렇기에 HPC 시스템에서는 구성 시스템 모두가 같은 시간을 유지해
줘야 한다. Master 노드를 시간 서버로 정하고 나머지 계산 노드들이 Master 노드의 시간과 일치
하도록 해주는 설정이다.
– master node 에 time 서비스를 켠다.
“disable = yes”를 “disable = no” 로 변경해 준다.
# vi /etc/xinetd.d/time
=============================================================================
service time
{
disable = no
type = INTERNAL
id = time-stream
socket_type = stream
protocol = tcp
user = root
wait = no
}
=============================================================================
Xinetd 데몬을 재시작하여 설정을 적용시킨다.
# /etc/rc.d/init.d/xinetd restart
– master node 의 시간을 표준 시간으로 맞춘다.
# hwclock -w
# rdate -s time.bora.net
– read node 에서 master node 시간과 일치 시킨다.
# rdate -s master
– master node 에서 시간이 일치하는지 확인한다.
# dush date
– master node 에서 time sync scripts를 하나 만들고 cron에 매 시간 마다
한번 씩 실행 시켜 준다.
시스템 시간을 BIOS 표준 시간과 일치 시킨다. 그런 후 표준 원자 시간 서버에 시간을 맞춘다.
dush를 이용하여 전 계산 노드에서 master 노드의 시간과 일치 시킨다.
# vi /root/bin/timesync
=============================================================================
#!/bin/sh
hwclock -w
rdate -s time.bora.net
/usr/clx/sbin/dush rdate -s master_node
=============================================================================
Dush를 이용하여 전 노드의 data 정보를 Master 노드에서 출력하도록 한다.
# vi /root/bin/timeview
=============================================================================
#!/bin/sh
/usr/clx/sbin/dush ?s date
=============================================================================
# /root/bin/timeview
=============================================================================
[node00] Tue May 11 18:49:39 KST 2004
[node01] Tue May 11 18:49:39 KST 2004
[node02] Tue May 11 18:49:39 KST 2004
[node03] Tue May 11 18:49:39 KST 2004
[node04] Tue May 11 18:49:39 KST 2004
[node05] Tue May 11 18:49:39 KST 2004
Cron 에 등록하여 매 시간 마다 시간을 일치 시킨다.
# crontab -e
=============================================================================
0 * * * * /root/bin/timesync
=============================================================================
/etc/rc.d/inint.d/crond restart
3.2 Compiler 설치 및 설정
주요 병렬 프로그램은 fortran 이나 C 로 만들어진다. 리눅스에서는 기본적으로 Gnu C/FC를 지원 하지만
최대 성능을 위해 상용 컴파일러를 많이 사용한다. 대표적으로 사용하는 컴파일러로는 Intel Compiler 와
Portland Group Compiler 가 있다. 여기서도 이 두 가지 컴파일러를 설치 하는 방법에 대해 설명한다.
– intel fortran/c++ Compiler 설치
intel Compiler 설치 방법은 모두 동일하다. 주의할것은 .lic 파일을 설치 디렉토리
에 넣어두시고 install.sh을 실행하면 된다.
ftp://clunix@technet.clunix.com/Hpc/intel
# tar xvf l_fc_p_8\\[1\\].0.055.tar
# mv l_cpp_63460285.lic l_cc_p_8.0.055
# cd l_cc_p_8.0.055
# ./install.sh
// compiler 설치 경로 -> /usr/local/intel/fc
# vi /etc/profile.d/intel.sh
=============================================================================
#!/bin/sh
PATH=$PATH:/usr/local/intel/fc/bin
export PATH
=============================================================================
혹은 /usr/local/intel/fc/bin/ 및에 ifortvar.sh 파일이 존재한다.
이것을 /etc/profile.d/ 밑에 복사해 두면 편리하다.
icc의 경우에도 fortran과 설치 방법은 동일하다. 설치 경로만을 /usr/local/intel/cc 로 적용하면된다.
환경설정은 iccvar.sh 파일을 복사해 두면 된다.
– PGI Compiler 설치하기 (x86_64용)-(IA32도 동일)
ftp://clunix@technet.clunix.com/Hpc/pgi-amd64
ftp://www.pgroup.com
**** PGI 설치 전 주의 사항 ******
PGI 설치 전에 Kernel Upgrade 가 필요한 경우엔 반드시 Kernel Upgrade 이후
PGI를 설치 하도록 하여라. 아님 GLIBC Version 문제로 인해 문제 발생 할 수도
있다.
# cd /usr/local/src/pgi-amd64/
# tar xzvf linux86-64[1].tar.gz
# ./install
=============================================================================
End-User License
NOTICE: PLEASE READ THIS DOCUMENT CAREFULLY BEFORE DOWNLOADING,
COPYING OR USING THE SOFTWARE. THIS END-USER LICENSE AGREEMENT
(“ELA”) IS A LEGAL AGREEMENT BETWEEN YOU, THE LICENSEE (A SINGLE
PERSON, INSTITUTION, OR LEGAL ENTITY), AND STMicroelectronics, INC. A
DELAWARE CORPORATION WITH ITS PRINCIPAL PLACE OF BUSINESS AT 1310
ELECTRONICS DRIVE, CARROLTON, TX 75006 (“ST”) FOR THE SOFTWARE,
ASSOCIATED MEDIA, PRINTED MATERIAL, ELECTRONIC DOCUMENTATION OR ANY
PORTION THEREOF. BY INSTALLING AND USING THE SOFTWARE ACCOMPANYING
THIS ELA INDICATES YOUR ACCEPTANCE OF THESE TERMS AND
CONDITIONS. PLEASE NOTE THAT YOU MAY NOT USE, COPY, MODIFY OR TRANSFER
THE SOFTWARE OR DOCUMENTATION OR ANY COPY, EXCEPT AS EXPRESSLY
PROVIDED IN THIS ELA. IF YOU DO NOT AGREE TO THE TERMS AND CONDITIONS
.
.
Address:
The Portland Group Compiler Technology
STMicroelectronics
9150 SW Pioneer Court, Suite H
Wilsonville, OR 97070
USA
Do you accept these terms? [accept,decline]
-> accept 를 입력한다.
——————————-
This release of PGI software includes the ACML, which is a tuned
math library designed for high performance on AMD64 machines,
including Opteron(TM) and Athlon(TM) 64, and includes both 32-bit
and 64-bit library versions.
More information about the ACML can be found at the ACML web site:
http://www.developwithamd.com/acml
Install the ACML? [y/n]
-> y 를 입력한다.
——————————
following license.
LICENSE AGREEMENT
AMD CORE MATH LIBRARY
IMPORTANT: This is a legal agreement (“Agreement”) between you, either
as an individual or an entity, (the “USER”) and Advanced Micro Devices,
Inc. (“AMD”). By loading the software or any portion thereof
(“Software”), and any related documentation (“Documentation”), USER
agrees to all of the terms of this Agreement. Additionally, USER
remains subject to the original terms and conditions of any other
software license agreements entered into by USER and a third party.
USER is responsible for ensuring that use of the Software provided by
AMD is not in violation of any such agreement.
.
.
Do you accept these terms? [accept,decline]
-> accept 를 입력한다.
——————————
Please specify the directory path under which the software will be
installed. The default directory is /usr/pgi, but you may
install anywhere you wish, assuming you have permission to do so.
Installation directory? [/usr/pgi] /usr/local/pgi
-> 그냥 Enter 혹은 PGI를 설치할 경로를 입력한다.
————————————————–
Installing software into /usr/local/pgi (this may take some time).
#############################################
If you don’t already have permanent keys for this product/release, a
fifteen-day evaluation license can be created now.
Create an evaluation license? [y/n]
-> y 를 입력한다. ( evaluation license 생성할건지 물어봄..) -> 15일 사용가능
.
.
PGI Software: PGI Fortran/C/C++ compilers and tools for 32-bit x86
and 64-bit AMD64 processor-based computer systems.
Do you accept these terms? [accept,decline]
-> accept 를 입력한다.
——————————–
Creating temporary license.
Please enter your name: root -> root 를 입력한다.
Please enter your user name: root -> root 를 입력한다.
Please enter your E-mail address: root@localhost -> root를 입력한다.
You have entered the following information:
name root
user name root
E-mail address root@localhost
Do you wish to change anything? [yes/no]: -> no
The above information was saved to /usr/local/pgi/license.info.
Do you want the files in the install directory to be read-only? [y,n]
-> y 를 선택하면 됩니다.
—————————————————————–
# cd /usr/local/pgi 가셔서 정상적으로 설치가 완료되었는지를 확인함.
***** 라이센스 발급 주의 사항 **************************************
evaluation license 에서 정식 license upgrade 계획이 있을 경우에는 반드시
일반 User로 evaluation license information 을 만들도록 하라.
HPC 의 MPI 로 많이 사용되는 Lammpi 의 경우 root 로는 사용할수 없다.
만일 root 로 PGI 사용권한이 주어지면 root 계정에서 compile 을 하고 다시
일반 계정으로 lam 을 돌려야 하는 번거로움이 생긴다. 초기 계획에서 잘 고려
해서 결정하도록 하라.
********************************************************************
그런후 반드시 /etc/profile.d 밑에 다음 환경 설정을 넣어 둠.
# vi pgi.sh
=============================================================================
export PGI=/usr/local/pgi
export PATH=$PGI/linux86/5.1/bin:$PATH
export MANPATH=$MANPATH:$PGI/linux86/5.1/man
#export LM_LICENSE_FILE= $PGI/license.dat
=============================================================================
# cp pgi.sh /etc/profile.d
# source /etc/profile.d/pgi.sh
# pgf77 test.f
=============================================================================
NOTE: your evaluation license will expire in 14 days, 23.9 hours.
For a permanent license, please read the order acknowledgement
that you received. Connect to https://www.pgroup.com/License with
the username and password in the order acknowledgement.
Name: root
er: root
Email: root@localhost
Hostid: PGI=000C76E0827FB855DE54B8
PGFTN-F-0002-Unable to open source input file: test.f
=============================================================================
같이 메세지가 떨어지면 정상적으로 설치가 되어진것이다.
간단한 테스트를 해보기 위해서는 소스에서 제공하는 샘플 소스를 컴파일
해 볼수 있다.
# cd /usr/local/pgi/linux86/5.1/EXAMPLES/linpack/UNIX
# make
# ./linpkrd
=============================================================================
norm. resid resid machep x(1)-1 x(n)-1
1.89264926E+00 8.39915160E-14 2.22044605E-16 -6.22835117E-14 -4.16333634E-14
times are reported for matrices of order 100
sgefa sgesl total Kflops unit ratio
times for array with leading dimension of 201
0.00115 0.00004 0.00119 578917. 0.00345 0.02118
0.00114 0.00004 0.00118 582486. 0.00343 0.02105
0.00112 0.00004 0.00116 589944. 0.00339 0.02078
0.00117 0.00000 0.00117 585947. 0.00341 0.02093
times for array with leading dimension of 200
0.00113 0.00004 0.00117 587926. 0.00340 0.02086
0.00113 0.00004 0.00117 586895. 0.00341 0.02089
0.00113 0.00004 0.00117 587817. 0.00340 0.02086
0.00117 0.00000 0.00117 585409. 0.00342 0.02095
ROLLED DOUBLE PRECISION LINPACK PERFORMANCE 585409 KFLOPS
FORTRAN STOP
=============================================================================
그럼 이 시스템의 CPU Flops를 체크하는 linpack 체크를 할 수 있다.
3.3 계산용 Library 설치
기본적인 blas와 lapack 은 Redhat 에 기본 탑재 되어져 있는 것을 사용하면 된다.
# rpm -Uvh blas-x.x.x.rpm
# rpm -Uvh lapack-x.x.x.rpm
– ATLAS 설치 하기
ATLAS (Auto Tuning Linear Algebra Subprogram) 는 수치 연산에 사용되는 BLAS 라이브러리를
해당 시스템( CPU, Compiler ) 에 맞게 자동으로 Tuning 하여 최적의 라이브러리 환경을 만들어 주는
프로그램이다. 기본적으로 사용하는 blas 라이브러리에 비해 월등하기 때문에 Linpack Benchmarking
Test 를 할경우에도 위의 라이브러리를 Link 하여 사용한다.
ATLAS 를 설치 할때 고려해야 할것은 Compiler 이다. 실제 사용 컴파일러를 가지고 있는 경우는
상용 컴파일러를 이용하여 라이브러리를 만드는 것이 성능에 유리하다. 하지만 Compiler 별로
설치가 되는 경우와 그렇지 못한 경우가 있어 이는 각 시스템의 상황에 따라 적절히 고려 해야 한다.
여기서는 PGI 컴파일러와 Opteron 프로세서 환경에서 컴파일 하는 것에 대해 알아 보겠다.
먼저 최신 atlas를 다운 받는다.
http://math-atlas.sourceforge.net
[root@otn02 hpc]# tar xzvf atlas3.7.8.tar.gz
[root@otn02 hpc]# cd ATLAS/
[root@otn02 ATLAS]# make config CC=<ANSI C compiler>
( if you have other Compiler. Default is gcc Compiler )
# make config CC=pgcc
============================================================================
.
.
011
010
009
008
007
006
005
004
003
002
001
Enter number at top left of screen [0]: < enter >
=============================================================================
IMPORTANT
=============================================================================
Before going any further, check
http://math-atlas.sourceforge.net/errata.html
This is the ATLAS errata file, which keeps a running count of all known
ATLAS bugs and system problems, with associated workarounds or fixes.
IF YOU DO NOT CHECK THIS FILE, YOU MAY BE COMPILING A LIBRARY WITH KNOWN BUGS.
Have you scoped the errata file? [y]:
.
.
ATLAS can detect almost everything it needs to know, so choosing the default
or ‘Other/UNKNOWN’ will at worst simply extend the install time (if you tell
config the answer to something ATLAS can skip some tests).
Configure makes no changes to the state of things until all questions have
been asked and answered. Therefore, if you get confused and want to start
over, feel free to break out of this program (CTRL-C, CTRL-BREAK, etc)
and start again. Alternatively, if you make a mistake you can finish the
configure process, and then edit the created make include file by hand to fix
the mistake manually (the name and location of this file will be printed
out at the end of configure).
If you have problems during configure or installation, consult the file
‘ATLAS/README/TroubleShoot.txt’.
Are you ready to continue? [y]:
Probing to make operating system determination:
Operating system configured as Linux
Probing for architecture:
Select pointer width and ABI for x86-64 system:
1. 32 bit libraries
2. 64 bit libraries
Enter bit number [2]:
Architecture is set to HAMMER64
Probing for supported ISA extensions:
AltiVec: NO.
AltiVec: NO.
SSE3: NO.
SSE2: NO.
SSE1: NO.
3DNow2: NO.
3DNow1: NO.
ATLAS can provide SMP support for the Level 3 BLAS via Posix threads.
If you choose to build a threaded library, ATLAS will compile all
aspects of the library (including the serial components) with the
threaded compiler/link flags. Most machines can use the serial
library even when it is compiled with threaded options, but this
is not guaranteed to work, so if you want a true serial library,
answer no to threading below.
enable Posix threads support? [y]:
Number of CPUs: 2
Required cache flush detected as : 2097152 bytes
Looking for compilers (this may take a while):
/usr/bin/gcc : v3.2.3
F77 = /usr/bin/g77 -fomit-frame-pointer -O -m64
CC = /usr/bin/gcc -fomit-frame-pointer -O -mfpmath=387 -m64
MCC = /usr/bin/gcc -fomit-frame-pointer -O -mfpmath=387 -m64
FINDING tar, gzip, AND gunzip
tar : /bin/tar
gzip : /bin/gzip
gunzip : /bin/gunzip
ATLAS has default parameters for OS=’Linux’ and system=’HAMMER64′.
If you want to just trust these default values, you can use express setup,
drastically reducing the amount of questions you are required to answer
use express setup? [y]: n
–> 여기서 별도의 컴파일러를 사용하고 싶은 경우 n 을 선택하도록 한다.
그리고 해당 컴파일러와 flags 등을 입력하면 된다.
You need to choose a name which represents this architecture (eg. UltraSparc,
Dec21164, etc). Do not use a generic name (eg. solaris, linux), which might
apply to different hardware. This architecture name will be appended to the
name of the created make include file, and appear in all subdirectories, so
don’t make it longer than you like to type. The name should follow the rules
for file names (so don’t use punctuation and spaces, for instance).
Enter Architecture name (ARCH) [Linux_HAMMER64_2]:
The ATLAS install process is heavily file-based, and this can cause major
reliability problems when interacting with an overloaded or malfunctioning
remotely mounted filesystem. ATLAS therefore has a mechanism in place to
allow for a delay before a file is declared to not be there, so that
slow NFS (i.e., waiting for amd timout) problems can be overcome, or for
handling slightly differing clocks between server/client. This problem is
magnified if doing cross-compilation. In the question below, we ask how
much of a delay, in seconds, ATLAS should tolerate between file creation
and appearance. If you are installing on a local filesystem (eg. /tmp) or
a smooth-running NFS system, answer 0; for a moderately loaded NFS server, you
may want a value in the 10 second range, and for cross-compiling systems or
NFS servers experiencing errors, you may want to go as high as a couple
of minutes (120).
Enter File creation delay in seconds [0]:
Enter Top level ATLAS directory [/usr/local/src/hpc/ATLAS]:
Enter Directory to build libraries in [$(TOPdir)/lib/$(ARCH)]:
Enter Library name for ATLAS primitives [libatlas.a]:
Enter Library name for the C interface to BLAS [libcblas.a]:
Enter Library name for the Fortran77 interface to BLAS [libf77blas.a]:
Enter Library name for the C interface to BLAS [libptcblas.a]:
Enter Library name for the Fortran77 interface to BLAS [libptf77blas.a]:
I’m going to ask you for information about your Fortran 77 compiler. ATLAS
does not need Fortran77 to build, so if you don’t have a Fortran compiler,
the install can still be completed successfully. However, ATLAS built without
a Fortran compiler will not be callable from Fortran (i.e., the user should
use the C interface), and we will not be able to do full testing, since some of
the tester code is written in Fortran77.
Enter F77 Linker [$(F77)]: /usr/pgi/linux86-64/5.2/bin/pgf77
Enter F77 Link Flags [$(F77FLAGS)]: -fast -tp=k8-64
I am now going to ask for two C compilers, and their associated flags.
The first such set (CC & CCFLAGS) are used in compiling the non-generated
ATLAS code. This code is written in normal C, and responds well to high
levels of optimization. Typically, this is set to your default compiler,
and your highest levels of optimization.
The second set of C compilers (MCC & MMFLAGS) is used to compile the generated
ATLAS code. Generated codes are written at a very low-level (think of C used
as a kind of portable assembler). On many platforms, high levels of
optimization are detrimental, as the compiler tries to pipeline a perfectly
pipelined code, and succeeds in reducing performance substantially (this
occurs on DEC ALPHAs & Sun UltraSparcs, for instance). If the default does
not work for you, try a midrange optimization such as -O. The generated code
does not alias any output arguments, so aliasing optimizations should be OK.
Enter ANSI C compiler(CC) [/usr/bin/gcc]: /usr/local/pgi/linux86-64/5.2/bin/pgcc
Enter C Flags (CCFLAGS) [-fomit-frame-pointer -O -mfpmath=387 -m64]: -fast -tp=k8-64
Enter C Linker [$(CC)]: /usr/local/pgi/linux86-64/5.2/bin/pgcc
Enter C Link Flags [$(CCFLAGS)]: -fast -tp=k8-64
Enter Archiver [ar]:
Enter Archiver flags [r]:
Enter Ranlib [echo]:
Enter BLAS library []:
Enter General and system libs [-lpthread -lm]:
Finding F77 to C calling conventions (this may take a while):
Assertion system(ln) == 0 failed, line 884 of config.c
Unable to figure F2C data
Calculated F77/C interoperation conventions:
Unable to determine naming conventions
Unable to determine F77/C integer correspondence
Unable to determine F77/C string interoperation
Your architectural defaults do not include defaults for the
Level 1 BLAS. ATLAS now has the ability to tune the Level 1 BLAS to
your machine. However, this will add time to the install. If your
algorithm utilizes the Level 2 or Level 3 BLAS to any degree, the
the Level 1 BLAS will usually be a low order term, and thus only matter
for small problems. Therefore, if you don’t think you need good performance
from the Level 1 BLAS, you can answer “no” to the question below, and ATLAS
will skip the Level 1 tuning. ATLAS will still provide Level 1 BLAS, but
their performance may be much worse than if tuning were allowed.
Tune the Level 1 BLAS? [y]:
Creating ATLrun.sh
Creating subdirectories:
Checking for already existing subdirectories …….. no
Subdirectories successfully created.
Storing L1 cache size of 64KB.
Moving config logfiles ConfSummary.log and ConfDump.log to bin/Linux_HAMMER64_2/INSTALL_LOG/
Configuration completed successfully. You may want to examine the make include
file (Make.Linux_HAMMER64_2) for accuracy before starting the install with the command:
make install arch=Linux_HAMMER64_2
rm -f ./xconfig
=============================================================================
[root@otn02 ATLAS]# make install arch=Linux_HAMMER64_2
무사히 컴파일이 완료되면 정상적으로 현 시스템에 최적화된 blas 라이브러리를 사용할 수 있게 될 것 이다.
~ATLAS/lib/Linux_HAMMER64_2/ 및에 libatlas.a, libf77blas.a, libptcblas.a,
libstatlas.a, libcblas.a, liblapack.a, libpf77blas.a 와 같은 라이브러리가 있음 정상적으로 컴파일이 되어진 것 이다.
– ATLAS 최적화 하기
Cache edge Size 값이 있는데 Pentium 4 의 경우는 기본적으로 209K로 되어져 있다.
이것을 적절히 변경하면 성능을 향상 시킬 수 있는데 P4 에서는 384K 가 이상적인 성능을 보였다.
# vi ~ATLAS/include/<ARCH>/atlas_cacheedge.h
————————————————————————-
#ifndef ATLAS_CACHEEDGE_H
#define ATLAS_CACHEEDGE_H
#define CacheEdge 524288 -> 수정
#endif
————————————————————————-
# vi ~ATLAS/bin/l3blastst.c
————————————————————————-
line 79 줄쯤~
//#define USE_F77_BLAS -> 주석처리
#ifdef ATL_USEPTHREADS
#define USE_L3_PTHREADS
#endif
————————————————————————-
# ~/ATLAS/bin/<ARCH>/make xsl3blastst, xdl3blastst, xcl3blastst, xzl3blastst 실행
실제 ATLAS를 컴파일 하는 데는 오랜 시간과 인내가 필요하다. 거의 몇 시간은 자고 와야 할 것 이다.
플랫폼 별로 바이너리를 만들어 두는 것이 좋을 것이다.
3.4 병렬 프로그램 설치 및 설정 ( MPICH, LAM-MPI )
– lammpi 설치/설정하기
http://lammpi.org/download
# tar xzvf lam-7.0.5.tar.gz
# cd lam-7.0.5
# ./configure –prefix=/usr/local/lam
// intel compiler 적용시 //
# ./configure –prefix=/usr/local/lam –with-fc=ifc –with-cc=icc –with-cxx=icc
// 단 /etc/ld.so.config 에 intel 관련 라이브러리 경로를 적어줘야 함. 아님 configure
시 에러남.
만일 PGI 컴파일러 설치 시는 아래 configure를 참조 한다.
# ./configure –prefix=/usr/local/lam –with-fc=/usr/local/pgi/linux86-64/5.1/bin/pgf77 \\
–with-cc=/usr/local/pgi/linux86-64/5.1/bin/pgcc –with-CFLAGS=-DDEC_ALPHA
위는 AMD64bit Opteron 환경에서 적용한 것으로 32bit 환경에서는 마지막 –with-CFLAGS=-DDEC_ALPHA 옵션을 제거한다.
–with-cxx=pgCC (closs compile)를 추가할 필요가 있을 시는 추가하도록 한다.
lam-7.1.x 이상 부터는 configure 옵션의 변화가 있다.
–with-cc , –with-cxx 같은 옵션이 적용 되지 않는 문제가 있다. 그래서 실제
컴파일이 되어지는 Shell 의 환경 변수 부분에서 실제 CC, CXX, FC 등을 미리 지정
해 두고 컴파일 하여야 정상적으로 옵션을 적용 시킬 수 있다.
# CC=/usr/local/pgi/linux86-64/5.2/bin/pgcc
# CXX=/usr/local/pgi/linux86-64/5.2/bin/pgCC
# FC=/usr/local/pgi/linux86-64/5.2/bin/pgf90
# CFLAGS=-fast
# FFLAGS=-fast
# CXXFLAGS=-fast
# export CC CXX FC CFLAGS FFLAGS CXXFLAGS
# ./configure –prefix=/usr/local/lam
혹은 ..
./configure –prefix=/usr/local/lam CC=/usr/local/pgi/linux86-64/5.2/bin/pgcc CXX=/usr/local/pgi/linux86-64/5.2/bin/pgCC FC=/usr/local/pgi/linux86-64/5.2/bin/pgf90 CFLAGS=-fast FFLAGS=-fast
이 해준다.
intel complier 연동 시 ..
# CC=/usr/local/intel/cc/bin/icc
# CXX=/usr/local/intel/cc/bin/icc
# FC=/usr/local/intel/fc/bin/ifc
# export CC CXX FC
./configure –prefix=/usr/local/lam-intel CFLAGS=’-O3 -fast -unroll -axW -tpp7 -align’ FFLAGS=’-O3 -fast -unroll -axW -tpp7 -align’
lam-mpi 에서 intel compiler 와 연동하기 위해서는 Pentium 계열 프로세스를 사용하여야 한다.
# make
# make install
# vi /etc/bashrc
————————————————————-
LAMHOME=/usr/local/lam
PATH=$PATH:/usr/local/lam/bin
export LAMHOME PATH
————————————————————
lam-mpi 가 compiler 별로 여러 개 설치 될 경우에는 반드시 위 환경 설정을
해당 lam-mpi 에 맞추어 lam 실행 전에 적용을 시켜 주어야 한다.
만일 compiler 를 gcc, intel, pgi 를 모두 사용한다고 하면 lam-mpi 를
각 compiler 에 맞게 3번을 compiler 해 주어야 한다.
lam-mpi compiler 시…해당 연동 compiler 에 맞게..
# ./configure –prefix=/usr/local/lam-gcc
# make && make install
# ./configure –prefix=/usr/local/lam-intel
# make && make install
# ./configure –prefix=/usr/local/lam-pgi
# make && make install
와 같이 각각 재 컴파일을 해주어야 한다.
# vi /etc/lamhosts
————————————————————
real00
real01
real02
real03
real04
real05
.
.
————————————————————
Cpu 가 smp 인 경우에는 ..
# vi /etc/lamhost
————————————————————
real00 cpu=2
real01 cpu=2
real02 cpu=2
real03 cpu=2
real04 cpu=2
real05 cpu=2
.
.
————————————————————
lamd 을 실행한다. lamd 은 root 가 아닌 일반 계정에서 실행하여야 한다.
보안을 생각하면 lamd 의 퍼미션을 750 으로 주고 lamusers 란 그룹을 만들어서
hpcusers 란 그룹에 속한 유저만 실행 가능토록 한다.
$ lamboot -v -b /etc/lamhosts
// lamd 에 의해 계산에 참여한 노드 리스트
$ lamnodes
// lamd 중지
$ wipe -v -b /etc/lamhosts
$ mpicc -o ring ring.c
$ mpirun -np 8 ./ring
이런 식으로 테스트를 하면 된다.
만일 lamboot 수행 시 SSI boot modules 에러가 발생하면 configure 시 –with-boot= 에 사용된
프로토콜이 어떤 것인지 확인하고 해당 프로토콜 상의 통신이 이상이 없는지를 확인한다.
MPI 통신에 이용되는 프로토콜은 rsh 와 ssh 가 있다. 2장에서 설정한 부분이 정상적으로
작동하는 지를 확인한다.
MPI 프로그램의 경우 MPI 프로그램이 실행되는 모든 시스템에 설치가 되어 있어야 한다.
이는 하나의 시스템에 설치를 하고 dutils 에서 제공하는 dua 란 명령어를 이용하여 일괄적
으로 데이터 동기화를 시키면 될 것이다.
– mpich 설치 /설정하기
wget ftp://ftp.mcs.anl.gov/pub/mpi/mpich.tar.gz
# ./configure –prefix=/usr/local/mpich -cc=/usr/local/pgi/linux86/5.1/bin/pgcc \\
–fc=/usr/local/pgi/linux86/5.1/bin/pgf90 -c++=/usr/local/pgi/linux86/5.1/bin/pgCC \\
–with-device=ch_p4 –with-arch=LINUX -flinker=/usr/local/pgi/linux86/5.1/bin/pgf90
# make
# make install
# cd /usr/local/mpich/share
# vi machines.LINUX
——————————————————————–
# host_name:cpu_num
otn1:2
otn2:2
otn3:2
# cd /usr/local/mpich/examples
# /usr/local/mpich/bin/mpicc -o cpi cpi.c
# /usr/local/mpich/bin/mpirun -np 2 cpi
——————————————————————–
Process 0 on otn1
Process 1 on otn2
pi is approximately 3.1416009869231241, Error is 0.0000083333333309
wall clock time = 0.000000
mpich 역시 Compiler 별로 여러 개를 사용하고자 할 때는 버전 별로 prefix를 다르게 주어서 설치 하도록 하라..
# ./configure –prefix=/usr/local/mpich-gcc
# make && make install
# ./configure –prefix=/usr/local/mpich-intel
# make && make install
# ./configure –prefix=/usr/local/mpich-pgi
# make && make install
이와 같이 설치를 하면 사용 시 마다 해당 MPI 컴파일러의 환경 설정을 해야 하는 번거로움이 있다.
하지만 Teragon HPC Management Tool 에서 제공하는 MPIsel 이란 프로그램을 이용하면 쉽게
관리 할수 있다. 이는 나중에 자세히 설명하도록 하겠다.
3.5 분산 시스템 일괄 계정 관리
– HPC 계정 생성 방법
아래 스크립터는 dush를 이용하여 제작된 분산 시스템 일괄 계정 관리 스크립터들이다.
이 스크립터는 그냥 참고용으로 살펴 보길 바란다. Dutils2 에서 이 보다 향상된 일괄 계정
관리 기능을 제공함으로 실제 사용은 아래에 dutils2 에서 제공하는 duseradd, duserdel,
dpasswd 등을 이용하면 보안측면에서 더 안전한 일괄 계정 관리가 가능하다.
# vi /root/bin/huseradd
—————————————————————————–
#!/bin/sh
DUTIL=/usr/clx/sbin
DUTILNODE=/root/.nodelist
ADDUSER=/usr/sbin/adduser
CRTPASS=/root/bin/createpasswd
if [ $# -ne 2 ]
then
echo “Not enough input !! Input HPC User account and password to add !!”
echo “Please Enter HPC_user Password”
exit 1
else
cat /etc/passwd |grep $1:x:
cat /etc/passwd |grep $1:x: >file_chk1
s=`ls -l file_chk1 |awk ‘{x+=$5};END{print x}’`
if [ $s != “0” ]; then
echo “NO, Can’t create!! This account exists !”
echo “Please Enter another ID”
rm file_chk1
exit 1
else
rm file_chk1
$DUTIL/dush -l $DUTILNODE $ADDUSER $1
$DUTIL/dush -l $DUTILNODE $CRTPASS $1 $2
fi
fi
—————————————————————————–
# vi /root/bin/createpasswd
—————————————————————————–
#!/bin/sh
if [ $# -ne 2 ]
then
echo “Among password creation, error occurrence !!”
echo “Please Enter HPC_user Password”
exit 1
else
echo “$2″|passwd –stdin $1
fi
—————————————————————————–
huseradd 는 HPC 와 같은 여러 개의 시스템으로 구성된 시스템의 경우 ypbind, openldap 같은
NIS 시스템을 가지지 않고도 일괄적인 계정 관리가 가능한 명령어이다.
ypbind 나 openldap 방식으로 시스템을 구현할 경우 사용자의 HOME_DIR 이 반드시 NFS 상에
있어줘야 하는 제한이 있다. 위 방식은 각 시스템의 환경을 분산 환경 그대로 사용하면서
효과는 NIS 서버에서 계정을 통합한듯한 효과를 주게 된다.
아래와 같은 환경만 만들어져 있음 편리하게 일괄 계정 관리가 가능합니다.
huseradd 는 반드시 /root/bin 에 위치하여야 한다.
huseradd 는 관리노드(master,node00)에서만 사용하여야 한다.
createpasswd 는 모든 노드의 /root/bin 밑에 위치하여야 한다.
Dutils 이 반드시 설치 되어져 있어야 한다.
/root/.nodelist 에 dutils 사용 nodelist 를 만들어야 한다.
사용 방법은 다음과 같다.
# huseradd <hpc_id> <password>
– HPC 계정 삭제 방법
# vi /root/bin/huserdel
—————————————————————————–
#!/bin/sh
DUTIL=/usr/clx/sbin
DUTILNODE=/root/.nodelist
USERDEL=/usr/sbin/userdel
if [ $# -ne 1 ]
then
echo “Not enough input !! Input HPC User account to delete !!”
echo “Please Enter HPC_user”
exit 1
else
$DUTIL/dush -l $DUTILNODE $USERDEL -r $1
fi
—————————————————————————–
huserdel 역시 huseradd 와 같은 환경을 요구한다.
사용방법은 아래와 같다.
# huserdel <hpc_id>
– 패스워드 변경 방법
패스워드 변경은 createpasswd 를 이용하여 할수 있다. 하지만 이는 dutils 와 같이 사용해야 한다.
# dush createpasswd <hpc_id> <password>
3.6 Open PBS 설치 및 관리하기
PBS(Portable Batch System)는 배치 작업 및 컴퓨터 시스템 자원을 관리하는 패키지 입니다.
배치 작업이란 작업의 순서를 정해 놓고 일괄적으로 처리하는 작업을 말합니다.
PBS에서는 작업을 실행하기 위해 Batch 작업 및 Shell Scripts와 제어 속성등을 전달하기
되며 그 작업이 종료될때 까지 작업은 유지 되고 보존되어집니다. PBS는 단일 시스템에 설치
할수 있고 여러 시스템을 그룹으로 묶어 설치 할수도 있습니다.
– Open PBS 의 설치
다음 홈페이지에서 해당 프로그램을 다운 받는다.
http://www.openpbs.org
다운 받은 소스를 특정 디렉토리에 풀어 놓는다.
OpenPBS 는 바이너리와 소스 형태로 제공되어 진다. 레드헷 계엘에서는 쉽게 바이너리로
설치 하면 된다. 일단 소스로 설치 하는 방법에 대해 알아 보겠다.
Openpbs 는 Master 서버와 일반 계산 서버에 설치 되는 패키지가 각각 다른다.
소스로 설치 할때 역시 사용되는 configure 옵션이 다르기 때문에 이에 주의해야 한다.
아래는 서버 측 설치 옵션이다.
[root@otn03 openpbs]# tar xzvf OpenPBS_2_3_16.tar.gz
[root@otn03 openpbs]# cd OpenPBS_2_3_16
[root@otn03 OpenPBS_2_3_16]# ./configure –prefix=/usr/local/openpbs –enable-docs \\
–enable-server –enable-clients –enable-gui –set-tmpdir=/tmp \\
–set-server-home=/var/spool/openpbs –set-server-name-file=server_name \\
–set-default-server=HOSTNAME –enable-syslog –enable-shell-pipe
** –set-default-server에는 master 서버의 hostname 을 적여 주면 된다.
–enable-clients 는 xpbs 프로그램을 만들기 위해서는 tcl/tk 관련 프로그램이 필요하다.
없으면 에레가 발생한다.
아래는 일반 계산 서버의 설치 옵션이다.
[root@otn03 OpenPBS_2_3_16]# ./configure –prefix=/usr/local/openpbs –enable-docs \\
–enable-server –enable-clients –enable-gui –set-tmpdir=/tmp \\
–set-server-home=/var/spool/openpbs –set-server-name-file=server_name \\
–set-default-server=HOSTNAME –enable-syslog –enable-shell-pipe
** master 서버와 일반 서버와의 차이는 –enable-server 나 –enable-mon 이나의 차이다.
[root@otn03 OpenPBS_2_3_16]# make && make install
이제 바이너리 RPM 으로 설치 하는 방법에 대해 알아보자. 소스에 비해 휠씬 간단한
설치 과정을 제공한다.
Master 서버 측
[root@otn03 openpbs]# rpm -Uvh –nodeps openpbs-exechost-2.3pl2-1.i386.rpm -> 클라이언트 패키지
[root@otn03 openpbs]# rpm -Uvh –nodeps openpbs-2.3pl2-1.i386.rpm -> 서버 패키지
** Master 서버 측에서는 서버관련 패키지와 클라이언트 관련 패키지를 모두 설치 한다.
작업 서버 측
[root@otn01 openpbs]# rpm -Uvh –nodeps openpbs-exechost-2.3pl2-1.i386.rpm
PBS 서버 프로그램과 클라이이언트 프로그램 모두 설치가 되면 /etc/profile.d/ 밑에 PBS
관련 환경 설정 파일을 만들어 준다.
[root@otn03 root]# vi /etc/profile.d/pbs.sh
————————————————————————
PBS_HOME=/usr/spool/PBS
PBS_SERVER_HOME=/usr/spool/PBS
PATH=/usr/pbs/bin:/usr/pbs/sbin:$PATH
————————————————————————
[root@otn03 root]# source /etc/profile.d/pbs.sh
– Open PBS 설정 방법
설정 하기 전에 먼저 PBS 서버 프로그램을 실행 하여야 한다.
서버 측 설정
[root@otn03 openpbs]# /usr/pbs/sbin/pbs_server -t create
Incorrectly built binary which accesses errno or h_errno directly. Needs to be fixed.
PBS_Server otn03: Create mode and server database exists,
do you wish to continue y/(n)?y
[root@otn03 openpbs]# cd /usr/spool/PBS/server_priv
[root@otn03 server_priv]# vi nodes
———————————————————————-
otn03 np=2
otn02 np=2
otn01 np=2
———————————————————————-
otn01 은 /etc/hosts 에 지정된 클라이언트 서버의 hostname 이고 np=2 는 SMP 머신의 경우
Process 수를 의미한다. 만일 hostname:ts 와 같이 :ts 붙여 주면 관련 노드를 time shared
형태로 사용하겠다는 의미이다.
[root@otn03 PBS]# cd /usr/spool/PBS
[root@otn03 PBS]# echo “server_hostname” > server_name
** 서버 측 설정은 서버 관련 설정 이외의 아래의 클라이언트 설정 역시 해주어야 한다.
클라이언트 측 설정
모든 클라이언트 서버에 아래 설정을 동일하게 해준다.
[root@otn01 root]# cd /usr/spool/PBS/
[root@otn01 PBS]# echo “server_hostname” > default_server
[root@otn01 PBS]# echo “server_hostname” > server_name
[root@otn01 PBS]# echo “$clienthost server_hostname” > mon_priv/config
이제 PBS 데몬을 master 서버와 작업 서버에서 각각 실행한다.
[root@otn03 root]# /etc/rc.d/init.d/pbs restart
[root@otn01 root]# /etc/rc.d/init.d/pbs restart
PBS Server 에서 PBS server 를 초기화 한다.
[root@otn03 PBS]# qmgr < pbs_server.conf
Max open servers: 4
정상적인 작동이 가능한지 확인한다.
[root@otn03 PBS]# pbsnodes -a
—————————————————————————–
otn03
state = free
np = 2
ntype = cluster
otn02
state = free
np = 2
ntype = cluster
otn01
state = free
np = 2
ntype = cluster
—————————————————————————–
– PBS 서버 큐잉 설정 하기
PBS 서버 디렉토리에 보면 pbs_server.conf 란 파일이 있다. PBS 의 주요 설정 파일로 이곳에서
큐잉에 관련된 다양한 설정을 할 수 있다.
pbs_server.conf 의 기본 설정 내용은 다음과 같다.
[root@otn03 PBS]# vi /usr/spool/PBS/pbs_server.conf
—————————————————————————–
#
# Create queues and set their attributes.
#
#
# Create and define queue workq
#
create queue workq
set queue workq queue_type = Execution
set queue workq enabled = True
set queue workq started = True
#
# Set server attributes.
#
set server scheduling = True
set server default_queue = workq
set server log_events = 511
set server mail_from = adm
set server query_other_jobs = True
set server scheduler_iteration = 600
—————————————————————————–
설정 파일의 구성은 다음과 같다.
queue_type : execution 과 route 로 두가지가 있다. execution 은 실제 작업이 실행되는 큐
이고 route 는 다른 큐로 작업을 넘길 때 사용되는 큐이다.
enabled : 큐를 사용할건지를 정의함
started : 큐를 시작할건지를 정의함
mail_from : 작업이 종료되거나 실행이 중단된 경우 메일로 메세지를 보내는데 이때 사용되어지는
메일 주소를 적는다.
query_other_jobs : 다른 사용자의 job 상태를 조회할 수 있는 지를 정의
이제 자기 시스템에 맞게 queue 설정을 해 보도록 하자
# vi queue.conf
—————————————————————————–
# create and define queue verylong
create queue verylong
set queue verylong queue_type = Execution
set queue verylong Priority = 40
set queue verylong max_running = 10
set queue verylong resources_max.ncpus = 6
set queue verylong resources_min.ncpus = 1
set queue verylong resources_max.cput = 72:00:00
set queue verylong resources_min.cput = 12:00:01
set queue verylong resources_default.cput = 72:00:00
set queue verylong enabled = True
set queue verylong started = True
# create and define queue long
create queue long
set queue long queue_type = Execution
set queue long Priority = 60
set queue long max_running = 10
set queue long resources_max.ncpus = 6
set queue long resources_min.ncpus = 1
set queue long resources_max.cput = 12:00:00
set queue long resources_min.cput = 02:00:01
set queue long resources_default.cput = 22:00:00
set queue long enabled = True
set queue long started = True
# create and define queue medium
create queue medium
set queue medium queue_type = Execution
set queue medium Priority = 80
set queue medium max_running = 10
set queue medium resources_max.ncpus = 6
set queue medium resources_min.ncpus = 1
set queue medium resources_max.cput = 02:00:00
set queue medium resources_min.cput = 00:20:01
set queue medium resources_default.cput = 02:00:00
set queue medium enabled = True
set queue medium started = True
# create and define queue small
create queue small
set queue small queue_type = Execution
set queue small Priority = 100
set queue small max_running = 10
set queue small resources_max.ncpus = 6
set queue small resources_min.ncpus = 1
set queue small resources_max.cput = 00:20:00
set queue small resources_default.cput = 00:20:00
set queue small enabled = True
set queue small started = True
# create nad define queue default
create queue default
set queue default queue_type = Route
set queue default max_running =10
set queue default route_destinations = small
set queue default route_destinations += medium
set queue default route_destinations += long
set queue default route_destinations += verylong
set queue default enabled = True
set queue default started = True
# Set server attributes
set server scheduling = True
set server max_user_run = 6
set server acl_host_enable = True
set server acl_hosts = *
set server default_queue = default
set server log_events = 63
set server mail_from = alang@clunix.com
set server query_other_jobs = True
set server resources_default.cput = 01:00:00
set server resources_default.neednodes = 1
set server resources_default.nodect = 1
set server resources_default.nodes = 1
set server scheduler_iteration = 60
set server default_node = 1
—————————————————————————–
** 위 큐잉 설정 파일의 관리 정책 설명 **
위 설정 파일은 verylong, long, medium, small 이름의 작업 시간으로 길이 별로 정의 된
실행 큐와 default 와 같이 특정 작업을 작업 시간에 따라서 다른 실행 큐로 전달한는
라우터 타입의 큐로 구성되어진다.
위 설정 파일의 Job 관리 정책은 다음과 같다.
사용자가 작업을 실행하면 처음 20분 동안은 small 이란 queue 에서 작업이 우선적으로
실행된다.
작업 시간이 20분이 넘어가면 이 작업은 medium 이란 queue 로 자동으로 넘어가게 된다.
이곳에서 small 보다는 낮은 우선 순위로 작업이 진행 되게 된다.
작업이 2시간이 넘어가면 long queue 로, 12시간이 넘어가면 verylong queue 로 넘어가서
처리 하게 되는 것이다.
이 파일을 적용 시켜 보도록 하자
[root@otn03 PBS]# qmgr < queue.conf
초기 큐 설정 상태로 돌아가고 싶다면 기본 pbs_server.conf 설정을 적용하면 된다.
[root@otn03 PBS]# qmgr < pbs_server.conf
큐의 기본 설정 상태를 확인 하기 위해서는 qmgr 명령을 이용해서 확인이 가능하다.
이 명령의 자세한 부분은 아래 “PBS 관련 명령” 에서 다루도록 하겠다.
[root@otn03 root]# qmgr
—————————————————————————–
Max open servers: 4
Qmgr: list queue default
Queue default
queue_type = Route
total_jobs = 0
state_count = Transit:0 Queued:0 Held:0 Waiting:0 Running:0 Exiting:0
max_running = 10
resources_max.ncpus = 6
resources_min.ncpus = 1
route_destinations = small,medium,long,verylong
enabled = True
started = True
Qmgr: list queue small
Queue small
queue_type = Execution
Priority = 100
total_jobs = 2
state_count = Transit:0 Queued:1 Held:0 Waiting:0 Running:1 Exiting:0
max_running = 10
resources_max.cput = 00:20:00
resources_max.ncpus = 6
resources_min.ncpus = 1
resources_default.cput = 00:20:00
resources_assigned.ncpus = 6
resources_assigned.nodect = 1
enabled = True
started = True
—————————————————————————–
현재의 설정 상태를 txt 로 저장 하기 위해서는 qmgr 의 -c 옵션으로 처리 할 수 있다.
[root@otn03 PBS]# qmgr -c ‘print server’ > queue.txt
– PBS 를 이용하여 작업 관리 하기
위 과정에서 정상적인 설정이 완료 되었다면 이제 바로 PBS 상에서 작업을 실행 할수 있을 것
이다. PBS 상에서 Job 을 제어 관리하는 기본적인 방법에 대해 알아보자.
먼저 PBS 를 통해 job 처리는 qsub 란 명령어와 작업을 처리에 필요한 배치 스크립터를 만들어
야 한다. 즉 job process script 를 qsub 란 명령어를 통해 실행 하는 것이다.
만일 HPL 벤치마킹 작업을 일반적인 방법으로 실행 하기 위해서는
$ lamboot -v -b ~/lamhost
$ mpirun -np 6 $HPL_PATH/xhpl
$ wipe -v -b ~/lamhost
위와 같은 일련의 과정이 필요할 것이다.
PBS 상에서 작업을 실행하기 위해서는 위의 과정을 하나의 배치 파일로 만든다.
$ vi hpl.sh
—————————————————————————–
#!/bin/sh
cd $PBS_O_WORKDIR
lamboot -v -b $HOEE/lamhosts
mpirun -np 6 xhpl
wipe -v -b $HOME/lamhosts
—————————————————————————–
* PBS_O_WORKDIR 은 실제 qsub 명령어를 실행하는 디렉토리의 절대 경로 이다.
* 즉 작업 디렉토리라고 보면됨
아래와 같이 qsub 명령어를 이용해서 hpl.sh 실행한다.
[clunix@otn03 Linux_ATHLON_BLAS]$ qsub hpl.sh
—————————————————————————–
2.otn03
에러 없이 위와 같은 메세지가 출력하면 정상적으로 명령이 수행된것이다.
qstat 명령을 통해 작업 수행 상태를 확인해 보자
[clunix@otn03 Linux_ATHLON_BLAS]$ qstat
Job id Name User Time Use S Queue
—————- —————- —————- ——– – —–
2.otn03 hpl.sh clunix 00:00:00 R small
위와 같이 2.otn03 작업은 clunix(User) 란 사용자가 small(Queue) 이란 큐에서 Running(S)
상태로 동작한다는 것이다.
만일 작업을 여러개 실행 하면..큐 설정에서 지정된 max_running 수 만큼 작업을 running
하고 이 이후의 작업은 Q 상태로 작업 대기 상태에 있게 된다.
즉 PBS 에서 시스템의 자원 현황에 맞게 PBS 큐잉 설정을 해 두면 사용자들이 시스템의
리소스를 Over 해서 사용하지 않게 자동으로 관리를 해주게 된다.
몇개의 job 이 동시 running 이 되게 하는 것은 max_running, resources_max.ncpus 등에
의해 제어 된다.
set queue long max_running = 10
set queue long resources_max.ncpus = 6
즉 위와 같이 long 큐에 max_running = 10 이고 resources_max.ncpus = 6 일 경우
Job 수가 10을 넘거나 qsub 를 통해 사용되는 process 의 수가 6개가 넘을 경우 그 이후
의 job 은 모두 Queue 상태로 대기 하게 된다. 이 수치는 구축 시스템에 맞게 정의 하면
될것이다.
[clunix@otn03 Linux_ATHLON_BLAS]$ qstat
Job id Name User Time Use S Queue
—————- —————- —————- ——– – —–
2.otn03 hpl.sh clunix 00:00:00 R small
3.otn03 hpl.sh clunix 0 Q small
[clunix@otn03 Linux_ATHLON_BLAS]$ qstat -Q
Queue Max Tot Ena Str Que Run Hld Wat Trn Ext Type
—————- — — — — — — — — — — ———-
verylong 1 0 yes yes 0 0 0 0 0 0 Execution
long 1 0 yes yes 0 0 0 0 0 0 Execution
medium 1 0 yes yes 0 0 0 0 0 0 Execution
small 1 2 yes yes 1 1 0 0 0 0 Execution
default 1 0 yes yes 0 0 0 0 0 0 Route
작업이 완료되면 해당 Job id 번호의 출력 파일이 자동으로 생성 된다.
hpl.sh.e2
hpl.sh.e3
hpl.sh.o2
hpl.sh.o3
xxx.xx.ex 형식의 파일은 작업 중 발생한 에러 출력 파일이다.
xxx.xx.ox 형식의 파일은 작업 결과 출력 파일이다.
[clunix@otn03 Linux_ATHLON_BLAS]$ cat hpl.sh.e2
—————————————————————————–
n-1<22064> ssi:boot:base:linear: booting n0 (otn03)
n-1<22064> ssi:boot:base:linear: booting n1 (otn02)
n-1<22064> ssi:boot:base:linear: booting n2 (otn01)
n-1<22064> ssi:boot:base:linear: finished
n-1<22083> ssi:boot:base:linear: booting n0 (otn03)
n-1<22083> ssi:boot:base:linear: booting n1 (otn02)
n-1<22083> ssi:boot:base:linear: booting n2 (otn01)
n-1<22083> ssi:boot:base:linear: finished
[clunix@otn03 Linux_ATHLON_BLAS]$ cat hpl.sh.o2
—————————————————————————–
============================================================================
T/V N NB P Q Time Gflops
—————————————————————————-
WR10R2C4 20000 256 1 6 359.48 1.484e+01
—————————————————————————-
||Ax-b||_oo / ( eps * ||A||_1 * N ) = 0.0147722 …… PASSED
||Ax-b||_oo / ( eps * ||A||_1 * ||x||_1 ) = 0.0142974 …… PASSED
||Ax-b||_oo / ( eps * ||A||_oo * ||x||_oo ) = 0.0027248 …… PASSED
============================================================================
Finished 1 tests with the following results:
1 tests completed and passed residual checks,
0 tests completed and failed residual checks,
0 tests skipped because of illegal input values.
—————————————————————————-
End of Tests.
============================================================================
LAM 7.1.1/MPI 2 C++/ROMIO – Indiana University
그리고 /usr/spool/PBS/server_priv/accounting 디렉토리 밑에 보면 그날의 날짜
이름으로 사용자 별 작업 시간 및 리소스 사용 현황을 로그로 남기게 된다.
이 account log 를 이용해서 계산서 발급등을 할 수 있게 된다.
[root@otn03 accounting]# vi 20050316
—————————————————————————–
.
.
03/16/2005 10:38:49;E;3.otn03;user=clunix group=clunix jobname=hpl.sh queue=small
ctime=1110936611 qtime=1110936611 etime=1110936611 start=1110936762
exec_host=otn03/0 Resource_List.cput=00:20:00 Resource_List.ncpus=6 Resource_List.neednodes=1
Resource_List.nodect=1 Resource_List.nodes=1 session=22094 end=1110937129 Exit_status=0
resources_used.cput=00:00:00 resources_used.mem=3280kb resources_used.vmem=85784kb
resources_used.walltime=00:06:07
—————————————————————————–
– PBS 관련 명령
여기서는 PBS 에서 주로 사용되는 명령어에 대해 다루어 보도록 하겠다. 기본적인 작동에 필요한
명령어는 이미 위 단락에서 사용해 보았을 것이다.
** PBS 주요 명령어
qsub : 작업을 사용자가 큐에 제출함
qalter : batch 작업의 속성을 변경
qdel : 큐에 있는 작업을 삭제함
qhold : 작업에 스케줄 되어 실행 되지 않도록 함
qmove : 작업을 다른 큐로 이동함
qmsg : 실행 중인 작업의 기본 출력 다음에 임의의 메세지를 추가함
qrerun : 실행 중인 작업을 장제 종료하고, 다시 큐로 돌려보냄
** 주요 사용 방법
$ qsub <pbs_job_scripts>
$ qdel <job_id>
* job_id 는 qsub 실행시 출력되는 8.otn03 같은 형태의 메세지의 숫자에 해당하는 부분이다.
[clunix@otn03 Linux_ATHLON_BLAS]$ qstat
Job id Name User Time Use S Queue
—————- —————- —————- ——– – —–
8.otn03 hpl.sh clunix 00:00:00 R small
9.otn03 hpl.sh clunix 0 Q small
10.otn03 hpl.sh clunix 0 Q small
여기서 현재 큐에 대기중인 10.otn03 작업을 취소 해 보도록 하겠다.
[clunix@otn03 Linux_ATHLON_BLAS]$ qdel 10.otn03
[clunix@otn03 Linux_ATHLON_BLAS]$ qstat
Job id Name User Time Use S Queue
—————- —————- —————- ——– – —–
8.otn03 hpl.sh clunix 00:00:00 R small
9.otn03 hpl.sh clunix 0 Q small
* qhold <job_id>
qhold 는 특정 작업이 Queuing 상태에서 작업 대기 중에 있을때 대기 상태에서 앞의 작업이
처리되어 실행 상태로 전환 되면 자동으로 Running 상태로 들어가는대 이것을 Running 으로
들어가지 않고 계속 Holding 상태에 있게 하는 명령어다.
[clunix@otn03 Linux_ATHLON_BLAS]$ qstat
Job id Name User Time Use S Queue
—————- —————- —————- ——– – —–
9.otn03 hpl.sh clunix 00:00:00 R small
11.otn03 hpl.sh clunix 0 Q small
[clunix@otn03 Linux_ATHLON_BLAS]$ qhold 11.otn03
[clunix@otn03 Linux_ATHLON_BLAS]$ qstat
Job id Name User Time Use S Queue
—————- —————- —————- ——– – —–
9.otn03 hpl.sh clunix 00:00:00 R small
11.otn03 hpl.sh clunix 0 H small
이렇게 11 번 Job 이 Queuing 상태에서 holding 상태로 넘어 가게 되면 9번 job 이 처리가
끝나게 되어도 11 번 Job 은 진행 되지 않는다.
* qrls <job_id>
qrls 명령은 qhold 명령으로 인해 hold 된 job 을 다시 풀어 놓는 명령이다.
[clunix@otn03 Linux_ATHLON_BLAS]$ qrls 11
[clunix@otn03 Linux_ATHLON_BLAS]$ qstat
Job id Name User Time Use S Queue
—————- —————- —————- ——– – —–
9.otn03 hpl.sh clunix 00:00:00 R small
11.otn03 hpl.sh clunix 0 Q small
* qmsg [-E] [-O] <message_string> <job_id>
qmsg 는 Job 의 처리가 완료될 경우 생성되는 error 출력파일과 output 출력파일에 사용자의
임의의 메세지를 남기게 된다.
[clunix@otn03 Linux_ATHLON_BLAS]$ qmsg -E -O ‘Alang Job End’ 9
이와 같이 명령을 수행하면 9 번 job 이 완료된 후에 생성되는 출력파일에 Alang Job End
라는 메세지가 추가 되게 된다.
-E 옵션은 error 출력 파일에 사용자 메세지 추가
-O 옵션은 output 출력 파일에 사용자 메세지 추가
만일 아무런 옵션이 없을 경우는 표준 error 파일에 메세지가 추가 된다.
* qstat
현재 진행 중인 큐의 상태를 확인하는 명령어이다.
주요 옵션은
-Q : 큐의 상태 확인
-B : 서버의 상태 확인
-f : Job_queue 의 Detail 한 정보 확인
[clunix@otn03 Linux_ATHLON_BLAS]$ qstat
Job id Name User Time Use S Queue
—————- —————- —————- ——– – —–
11.otn03 hpl.sh clunix 00:00:00 R small
13.otn03 hpl.sh clunix 0 Q small
14.otn03 hpl.sh clunix 0 Q small
[clunix@otn03 Linux_ATHLON_BLAS]$ qstat -Q
Queue Max Tot Ena Str Que Run Hld Wat Trn Ext Type
—————- — — — — — — — — — — ———-
verylong 1 0 yes yes 0 0 0 0 0 0 Execution
long 1 0 yes yes 0 0 0 0 0 0 Execution
medium 1 0 yes yes 0 0 0 0 0 0 Execution
small 1 3 yes yes 2 1 0 0 0 0 Execution
default 1 0 yes yes 0 0 0 0 0 0 Route
[clunix@otn03 Linux_ATHLON_BLAS]$ qstat -B
Server Max Tot Que Run Hld Wat Trn Ext Status
—————- — — — — — — — — ———-
otn03 0 3 2 1 0 0 0 0 Active
[clunix@otn03 Linux_ATHLON_BLAS]$ qstat -f 14
—————————————————————————–
Job Id: 14.otn03
Job_Name = hpl.sh
Job_Owner = clunix@otn03
job_state = Q
queue = small
server = otn03
Checkpoint = u
ctime = Wed Mar 16 11:38:58 2005
Error_Path = otn03:/home/clunix/hpl/bin/Linux_ATHLON_BLAS/hpl.sh.e14
Hold_Types = n
Join_Path = n
Keep_Files = n
Mail_Points = a
mtime = Wed Mar 16 11:38:58 2005
Output_Path = otn03:/home/clunix/hpl/bin/Linux_ATHLON_BLAS/hpl.sh.o14
Priority = 0
qtime = Wed Mar 16 11:38:58 2005
Rerunable = True
Resource_List.cput = 00:20:00
Resource_List.ncpus = 6
Resource_List.nodect = 1
Resource_List.nodes = 1
Variable_List = PBS_O_HOME=/home/clunix,PBS_O_LANG=en_US.UTF-8,
PBS_O_LOGNAME=clunix,
PBS_O_PATH=/usr/local/pgi/linux86-64/5.2/bin:/usr/pbs/bin:/usr/pbs/sbin:/usr
/kerberos/bin:/opt/intel_fc_80/bin:/opt/intel_cc_80/bin:/usr/clx/sbin:/
bin:/usr/bin:/usr/local/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/local/lam-
gcc/bin:/home/clunix/bin,PBS_O_MAIL=/var/spool/mail/clunix,
PBS_O_SHELL=/bin/bash,PBS_O_HOST=otn03,
PBS_O_WORKDIR=/home/clunix/hpl/bin/Linux_ATHLON_BLAS,
PBS_O_QUEUE=default
comment = Not Running: Queue job limit has been reached.
etime = Wed Mar 16 11:38:58 2005
—————————————————————————–
– PBS 큐잉 관리 하기
PBS 의 큐의 관리를 위해서는 qmgr 명령어를 이용하여야 한다.
기본적인 queue 설정은 앞에서 설명한 바와 같이 pbs_server.conf 혹은 queue.conf 파일에
관리 정책에 맞게 설정을 하고 난 뒤 ..
# qmgr < queue.conf
와 같이 실행하면 일괄 설정이 되어진다.
하지만 설정의 상태 확인 및 일부 수정등을 위해서 qmgr shell 상에서 큐잉 시스템을 관리
하는 방법에 대해 알아보자
먼저 qmgr 을 실행한다.
[clunix@otn03 Linux_ATHLON_BLAS]$ qmgr
Max open servers: 4
Qmgr:
qmgr 명령 형식은 다음과 같다.
[ command ] [ object ] [ obj_name ] [ attribute ]
[ command ] 에는 다음과 같은 명령이 있다.
active(a) : 객체를 활성화 한다.
create(c) : 객체를 생성한다.
delete(d) : 객체를 삭제한다.
set(s) : 객체에 속성을 지정한다.
unset(u) : 객체의 속성을 제거 한다.
print : 객체의 설정 값을 출력한다.
list : 객체의 속성 값을 출력한다.
[ object ] 에는 다음과 같은 객체가 있다.
server
queue
node
[ name ] 은 실제 객체에 대한 이름이다. node 의 경우는 node_name 이 될것이고
queue 의 경우에는 앞서 큐잉 설정 파일에 create queue 로 생성한 queue 의 이름
이 될것이다.
[ attribute ] 는 실제 해당 객체의 세부 속성이다.
* 현재 서버의 속성을 확인해 보자
Qmgr: list server
—————————————————————————-
Server otn03
server_state = Active
scheduling = True
max_user_run = 6
total_jobs = 1
state_count = Transit:0 Queued:0 Held:0 Waiting:0 Running:1 Exiting:0
acl_host_enable = True
acl_hosts = *
default_queue = default
log_events = 63
mail_from = alang@clunix.com
query_other_jobs = True
resources_default.cput = 01:00:00
resources_default.nodect = 1
resources_default.nodes = 1
resources_assigned.ncpus = 6
resources_assigned.nodect = 1
scheduler_iteration = 60
default_node = 1
pbs_version = OpenPBS_2.3
* 현재 서버의 설정 값을 확인해 보자
Qmgr: print server
—————————————————————————
.
생략..
.
.
set queue default enabled = True
set queue default started = True
#
# Set server attributes.
#
set server scheduling = True
set server max_user_run = 6
set server acl_host_enable = True
set server acl_hosts = *
set server default_queue = default
set server log_events = 63
set server mail_from = alang@clunix.com
set server query_other_jobs = True
set server resources_default.cput = 01:00:00
set server resources_default.nodect = 1
set server resources_default.nodes = 1
set server scheduler_iteration = 60
set server default_node = 1
* queue 의 속성을 확인해 보자
Qmgr: list queue small
————————————————————————-
Queue small
queue_type = Execution
Priority = 100
total_jobs = 1
state_count = Transit:0 Queued:0 Held:0 Waiting:0 Running:1 Exiting:0
max_running = 1
resources_max.cput = 00:20:00
resources_max.ncpus = 6
resources_min.ncpus = 1
resources_default.cput = 00:20:00
resources_assigned.ncpus = 6
resources_assigned.nodect = 1
enabled = True
started = True
* small queue 의 resources_min.ncpus 값을 1 에서 2로 변경해 보자
Qmgr: set queue small resources_min.ncpus=2
Qmgr: list queue small
————————————————————————-
Queue small
queue_type = Execution
Priority = 100
total_jobs = 1
state_count = Transit:0 Queued:0 Held:0 Waiting:0 Running:1 Exiting:0
max_running = 1
resources_max.cput = 00:20:00
resources_max.ncpus = 6
resources_min.ncpus = 2
resources_default.cput = 00:20:00
resources_assigned.ncpus = 6
resources_assigned.nodect = 1
enabled = True
started = True
————————————————————————-
** list, print 를 제외한 다른 명령은 반드시 PBS 관리자 권한에서 사용하여야 한다.
초기 PBS 관리자는 root 이다. 시스템 관리자와 PBS 관리자가 서로 다른 경우 PBS
관리자를 root 에서 다른 계정으로 변경해 주어야 한다.
* PBS 관리자 변경 방법
Qmgr: set server managers=clunix@otn03
Qmgr: print server managers
#
# Set server attributes.
#
set server managers = clunix@otn03
– PBS 스크리트 제작
qsub 에 사용되는 스크립트에 제작 시 유용한 환경 변수 및 기본 제작에 유용한
방법에 대해 간단히 설명하겠다.
qsub 에 사용되는 스크립트 제작시 다음과 같은 환경 변수를 이용할 수 있다.
시스템에서 지원하는 환경변수에 PBS_O_ 라는 접두사를 붙여 읽어 들일 수가 있다.
즉 ..
* PBS_O_HOST : qsub 명령이 실행된 호스트 이름
* PBS_O_QUEUE : 작업이 처음 제출되었던 큐의 이름
* PBS_O_WORKDIR : qsub 명령이 실행된 디렉토리의 절대 경로
* PBS_JOBID : 작업 아이디
* PBS_JOBNAME : 작업 이름 ( qsub 로 실행하는 scripts 이름 )
* PBS_NODEFILE : 작업에 활당된 노드 목록이 저장된 파일의 이름
* PBS_QUEUE : 작업이 실행되고 있는 큐의 이름
위의 변수를 이용하여 보다 효율적인 실행 스크립터를 만들 수가 있다.
만일 아래와 같은 스크립터를 qsub 로 실행하였다고 하자.
[clunix@otn03 Linux_ATHLON_BLAS]$ vi mpi.sh
—————————————————————————–
#!/bin/sh
echo $PBS_O_HOST
echo $PBS_O_HOME
echo $PBS_O_QUEUE
echo $PBS_O_WORKDIR
echo $PBS_JOBID
echo $PBS_JOBNAME
echo $PBS_NODEFILE
echo $PBS_QUEUE
—————————————————————————–
[clunix@otn03 Linux_ATHLON_BLAS]$ qsub mpi.sh
32.otn03
[clunix@otn03 Linux_ATHLON_BLAS]$ vi mpi.sh.o32
—————————————————————————–
otn03
/home/clunix
default
/home/clunix/hpl/bin/Linux_ATHLON_BLAS
32.otn03
mpi.sh
/usr/spool/PBS/aux/32.otn03
small
—————————————————————————–
이밖에 스크립트 안에 PBS 의 추가 기능을 포함 할수가 있는데 대표적인 사용 방법은
아래와 같다.
[clunix@otn03 Linux_ATHLON_BLAS]$ vi hpl.sh
—————————————————————————–
#!/bin/sh
#PBS -j oe
#PBS -l nodes=3
#PBS -m ae
cd $PBS_O_WORKDIR
lamboot -v -b $PBS_NODEFILE
mpirun -np 6 xhpl
wipe -v -b $PBS_NODEFILE
—————————————————————————–
위의 스크립터에서 사용된 #PBS 정의 부분이 있다.
* #PBS -j oe : 표준 error 출력 파일과 표준 output 출력 파일을 하나로 합니다.
합쳐진 출력 파일은 output 파일로 통일 된다
* #PBS -l nodes=3 : PBS 에 사용되어지는 node 수를 정의 하는 곳이다. 만일 이 정의를
생략하게 되면 time shared 상태로 동작하게 된다.
* #PBS -m ae : PBS 의 작업이 종료되면 자동으로 PBS server managers 에 지정된 사용자
에게 작업에 소요된 시스템 정보를 메일로 보내 주게 딘다. a 의 경우는
경고가 발생 했을 경우에 메일을 보내는 것이고 e 의 경우는 정상 종료된
경우에도 메일을 보내도록 하는 것이다.
*** time-shared 란 ..
time-shared 란 용어는 프로세스 스케줄링에 주로 등장하는 용어로 여러개의 job 을 동시에
처리할때 CPU 를 시간 단위로 분활해서 사용하는 방식을 말한다.
즉 1, 2 의 두개의 Job 을 처리 할때 time-shared 방법으로 처리를 하면 두개의 job 을 동시
에 수행하는데 프로세스 사용 시간을 분활하여 1번 job 을 처리하다가 분할 시간이 되면..
2번 job 을 수행하고 또 시간이 되면 다시 1번 job 을 수행하는 방식을 의미 한다.
PBS queue 설정에 의해 예를 들어 보면 물리적인 CPU 수가 6이고 PBS 설정 상의
resources_max.ncpus = 12 일 경우 np 6 으로 mpirun 을 실행 하는 job 이 두개 일 경우
모두 running 상태로 작업이 실행 될 것이다. 이때 time-shared 방식에서는 Job 을 구분하여
해당 Job 에 활당된 CPU 요청 ( job 당 6개, 총 12개)을 시간 별로 조금씩 활당 하여
물리적으로 처리 가능한 6개의 CPU 로 12개의 CPU 작업을 동시에 진행하게 된다.
non-time-shared 방식에서는 두개의 job 이 동시에 running 이 되더라도 우선 첫번째 Job
에서 요청한 6개의 CPU 작업을 실제 6개의 CPU 가 모두 처리 하고 난 뒤에 두번째 Job 에
6개 CPU가 모두 작업에 활당되어지게 된다.
time-shared 방식은 실제 작업의 특성에 따라 효율적일수도 있고 그렇지 못할 수도 있다.
I/O 가 많은 작업의 경우 실제 Job 처리 중에 I/O 를 일으킬때 CPU 는 Idle 상태로 있기 때문
에 이 시간 동안 다른 작업을 진행 할 수 있게 된다. 하지만..오직 CPU 자원만 활용하는
job 의 경우는 실제 batch 방식의 작업이 더 효율적일 수 있다.
3.7 Teragon HPC Management Tool 설치, 설정, 관리 ( Dutils 2.0 )
Dutils 2.0은 dutils 1.0 의 보안적 취약점과 기능을 개선한 제품으로 다양한 분산 시스템을 관리하는
프로그램을 제공한다. 각 기능과 사용 방법을 아래에 자세히 설명한다.
– Dutils 2.0 설치 및 설정 하기
먼저 RPM Package 를 설치 한다.
# rpm -Uvh dutils-2.0.0.i386.rpm
그럼 /usr/local/dutils 이란 경로에 dutils 2.0 이 생성 될것이다.
dutils2.0 의 핵심 모듈은 dush2 란 프로그램이다. 일단 dush2를 초기화 하여
관리자 인증키를 생성 시켜 놓아야 dutils2.0 이 제공하는 모든 기능을 무난히
사용할 수 있을 것이다.
기본 설정은 /usr/local/dutils/etc/dutils.cfg 파일을 열어 DUTIL_ADM 에
관리자 리포트 메일 주소를 적어 주고 nodelist 파일에 클러스터 관리 노드
의 hostname 을 적어 준다.
dush2에 대한 자세한 기능 설명은 아래 dutils 2.0 사용하기에서 설명하겠다.
– Dutils 2.0 사용 하기
* timesync, timeview
: 클러스터 시스템의 전 노드를 표준 시간에 맞게 동기화를 시키는 명령
timesync 는 관리 노드에서 표준 시간을 맞추고, 계산 노드는 관리 노드와
시간을 동기화 시켜 주는 명령이다. 사용방법은 관리자 권한에서 timesync
명령을 수행하면 된다.
timeview 는 실제 클러스터 시스템의 현 시간을 확인하는 명령이다.
timeview 역시 그냥 timeview 란 명령을 입력하면 된다.
[root@otn03 bin]# timesync
* HPC system time synced ..
[root@otn03 bin]# timeview
—————————————————————–
[otn01] Tue Mar 22 13:42:57 KST 2005
[otn02] Tue Mar 22 13:42:57 KST 2005
[otn03] Tue Mar 22 13:42:57 KST 2005
* duseradd, duserdel, dpasswd
: 분산 시스템 계정 관리 방식에서 일괄적을 계정 생성, 삭제, 패스워드
변경등을 해주는 명령어
duseradd 는 분산 시스템의 계정을 일괄적으로 생성하는 명령어입니다.
duserdel 는 분산 시스템의 계정을 일괄적으로 삭제하는 명령어입니다.
dpasswd 는 분산 시스템의 계정의 패스워드를 일괄적으로 변경하는 명령어입니다.
사용방법은 다음과 같다.
# duseradd [account] [password]
[root@otn03 root]# duseradd test pass
————————————————————————–
[otn01] Changing password for user test.
[otn01] passwd: all authentication tokens updated successfully.
[otn02] Changing password for user test.
[otn02] passwd: all authentication tokens updated successfully.
[otn03] Changing password for user test.
[otn03] passwd: all authentication tokens updated successfully.
# dpasswd [account] [password]
[root@otn03 bin]# dpasswd test root///
————————————————————————-
[otn01] Changing password for user test.
[otn01] passwd: all authentication tokens updated successfully.
[otn02] Changing password for user test.
[otn02] passwd: all authentication tokens updated successfully.
[otn03] Changing password for user test.
[otn03] passwd: all authentication tokens updated successfully.
# duserdel [account]
[root@otn03 bin]# duserdel test
————————————————————————-
Do you delete home directory for this account? (yes/no)
* 사용자 홈디렉토리를 삭제할려면 yes, 보존할려면 no 를 입력
### executing in otn01
### executing in otn02
### executing in otn03
* dalive
: 클러스터 시스템의 서버 활성 상태 및 네트워크 상태 모니터링
dalive 는 클러스터 시스템 각각 서버의 활성 상태 및 네트워크 활성 상태를
한번에 모니터링 하는 것이다. 클러스터 구성 노드 수가 많은 경우 특정 노드
에 이상이 있을 경우 별도의 모니터링 툴이 없거나 있어도 웹 브라우저나 특정
프로그램 상에서 파악이 가능하면 콘솔이나 터미널 작업 시 즉각적으로 확인이
힘든 경우가 발생한다. 이때 간단히 command 기반에서 이를 확인할수 있다.
사용방법은 다음과 같다
# dalive [option] [ hostname ]
* option list
-n : 특정 노드에 대한 서버, 네트워크 상태 체크
-c : 활성 노드로 새로운 nodelist 생성
-d : 다운된 노드 리스트 출력
-h : 도움말
-r : 결과 리포트 작성
-m : 결과 리포트 메일 발송
null : nodelist 에 등록된 host 에 대한 서버, 네트워크 상태 체크
[root@otn03 bin]# ./dalive
——————————————————
hpc system alive state ..
otn01 is alive
otn02 is alive
otn03 is alive
——————————————————
[root@otn03 bin]# ./dalive -n otn01
——————————————————
otn01 is alive
——————————————————
[root@otn03 bin]# ./dalive -c
——————————————————
hpc system alive state ..
otn01 is alive
otn02 is alive
otn03 is alive
update new nodelist..
otn01
otn02
otn03
——————————————————
[root@otn03 bin]# ./dalive -d
——————————————————
deathed node list…
otn01
[root@otn03 bin]# dalive -r
——————————————————
creat report file 20050318-alive.txt to output..
[root@otn03 bin]# dalive -m
——————————————————
send to mail of output result
* dload (uptime)
: 클러스터 시스템의 전체 시스템 부하 및 활성 상태를 일괄적으로 모니터링
하는 명령
dload 사용 방법은 아래와 같다.
# dload [ option ]
* option
-r : 출력 결과 리포트 작성 하기
-m : 출력 결과 리포트 메일 발송하기
-h : 도움말
[root@otn03 bin]# dload
————————————————————————
* hpc system load average info
======================================================
hostname || date || uptime || load average
======================================================
[otn01] 15:15:40 20days, 0.00, 0.00, 0.00
[otn02] 15:09:27 23days, 0.00, 0.00, 0.00
[otn03] 15:15:01 28days, 0.00, 0.00, 0.00,
* dcpu (ps,head)
: 클러스터 시스템의 전체 CPU 사용량을 모니터링 – 대량 CPU 사용 프로세스
dcpu 는 클러스터 시스템의 프로세스별 CPU, MEM 사용량을 모니터링 하는 명령이다.
dcpu 는 시스템별로 CPU 사용량이 높은 10개의 프로세스에 대한 CPU, MEM 점유률을
보여 주며 특정 프로세스에 대한 모니터링도 가능하다.
dcpu 의 사용방법은 다음과 같다.
# dcpu [process_name]
* 특별히 모니터링 할 process 가 없는 경우엔 그냥 dcpu 라고 입력하면 됩니다.
그럼 각 서버별 CPU 상위 점유 프로세스를 출력한다.
* 특별히 모니터링 할 process 가 있는 경우엔 dcpu 뒤에 process 명을 적어준다.
[root@otn03 bin]# dcpu
======================================================================
Hostname || CPU || MEM || PROC
======================================================================
[otn01] 84.2 14.9 xhpl
[otn01] 77.7 15.8 xhpl
[otn01] 0.1 0.1 bin/esmd
[otn01] 0.1 0.0 bin/edbd -n eth0 -p 908 -d
[otn01] 0.0 0.5 emacs
[otn01] 0.0 0.1 /usr/clx/bin/egid -f /usr/clx/rc/http/conf/egid.conf
[otn01] 0.0 0.1 /usr/clx/bin/egid -f /usr/clx/rc/http/conf/egid.conf
[otn01] 0.0 0.1 /usr/clx/bin/egid -f /usr/clx/rc/http/conf/egid.conf
[otn01] 0.0 0.1 /usr/clx/bin/egid -f /usr/clx/rc/http/conf/egid.conf
[otn02] 82.7 16.4 xhpl
[otn02] 79.0 16.4 xhpl
[otn02] 1.0 0.0 bin/el4d
[otn02] 0.1 0.1 bin/edbd -n eth0 -p 908 -d
[otn02] 0.0 0.1 ssh otn03
[otn02] 0.0 0.0 xinetd -stayalive -pidfile /var/run/xinetd.pid
[otn02] 0.0 0.0 /usr/sbin/sshd
[otn02] 0.0 0.0 /usr/pbs/sbin/pbs_mom
[otn02] 0.0 0.0 /usr/local/lam-gcc/bin/lamd -H 192.168.123.167 -P 41831
[otn03] 94.7 15.0 xhpl
[otn03] 81.2 17.9 xhpl
[otn03] 0.0 0.1 vim dload
[otn03] 0.0 0.1 ssh -n otn03 cd /usr/local/dutils/bin; ps
[otn03] 0.0 0.0 xinetd -stayalive -pidfile /var/run/xinetd.pid
[otn03] 0.0 0.0 xfs -droppriv -daemon
[otn03] 0.0 0.0 /usr/sbin/sshd
[otn03] 0.0 0.0 /usr/sbin/named -u named
[otn03] 0.0 0.0 /usr/sbin/atd
[root@otn03 bin]# dcpu xhpl
======================================================================
Hostname || CPU || MEM || PROC
======================================================================
[otn01] 94.5 17.1 xhpl
[otn01] 91.8 16.2 xhpl
[otn02] 94.9 15.0 xhpl
[otn02] 86.0 16.6 xhpl
[otn03] 97.7 17.5 xhpl
[otn03] 93.8 16.4 xhpl
* dmem (free)
: 클러스터 시스템의 전체 MEM 사용량을 모니터링
dmem 은 클러스터 시스템의 전체 Memory 상태를 일괄적으로 모니터링 하는 명령이다.
dmem 의 사용방법은 다음과 같다.
Usage:
dload [option]
-r : create to output report
-m : mail to output report
-h : help message
[root@otn03 bin]# dmem
—————————————————————————–
* hpc system memory using info
=============================================================================
hostname || total || used || free || shared || buffers || cached
=============================================================================
[otn01] Mem: 1977 755 1221 0 199 103
[otn01] Swap: 2000 42 1957
[otn02] Mem: 1977 544 1433 0 126 97
[otn02] Swap: 2000 7 1992
[otn03] Mem: 1977 1959 17 0 20 1674
[otn03] Swap: 2000 9 1990
[root@otn03 bin]# dmem -r
—————————————————————————–
creat report file 20050321-dmem.txt to output..
[root@otn03 bin]# dmem -m
—————————————————————————–
send to mail of output result
* ddisk (df)
: 클러스터 시스템의 전체 디스크 사용량을 모니터링
ddisk 는 클러스터 시스템의 파티션별 디스크 사용량과 파일시스템 속성을 일괄적으로
모니터링 하는 명령이다.
사용방법은 다음과 같다.
Usage:
dload [option]
-r : create to output report
-m : mail to output report
-h : help message
[root@otn03 bin]# ddisk
—————————————————————————–
* hpc system disk using info
[otn01] Filesystem Type Size Used Avail Use% Mounted on
[otn01] /dev/sda2 ext3 2.9G 406M 2.4G 15% /
[otn01] /dev/sda1 ext3 198M 23M 165M 13% /boot
[otn01] /dev/sda7 ext3 18G 6.1G 11G 38% /home
[otn01] /dev/sda3 ext3 9.7G 4.7G 4.6G 51% /usr
[otn01] /dev/sda5 ext3 2.0G 90M 1.8G 5% /var
[otn02] Filesystem Type Size Used Avail Use% Mounted on
[otn02] /dev/sda2 ext3 2.9G 425M 2.4G 16% /
[otn02] /dev/sda1 ext3 198M 23M 165M 13% /boot
[otn02] /dev/sda7 ext3 18G 1.5G 15G 9% /home
[otn02] /dev/sda3 ext3 9.7G 4.6G 4.6G 51% /usr
[otn02] /dev/sda5 ext3 2.0G 89M 1.8G 5% /var
[otn03] Filesystem Type Size Used Avail Use% Mounted on
[otn03] /dev/sda2 ext3 2.9G 435M 2.4G 16% /
[otn03] /dev/sda1 ext3 198M 23M 165M 13% /boot
[otn03] /dev/sda7 ext3 18G 8.9G 7.4G 55% /home
[otn03] /dev/sda3 ext3 9.7G 3.2G 6.1G 35% /usr
[otn03] /dev/sda6 ext3 2.0G 244M 1.6G 14% /var
* dhalt, dreboot
: 클러스터 시스템 일괄 종료 및 재시작 명령
dhalt, dreboot 은 클러스터 시스템을 종료 혹은 리부팅 시키는 명령이다.
사용 방법은 다음과 같다.
Usage:
dhalt [hostname] [hostname] [hostname] ….
즉 dhalt 뒤에 종료를 원하는 시스템들의 hostname을 차례로 적어 주면 된다.
만일 hostname 을 별도로 정의 하지 않으면 dutils의 nodelist 에 정의된 모든
시스템에 종료된다. dreboot 역시 같다.
[root@otn03 bin]# dhalt
———————————————————————-
Halted otn01 System ..
Halted otn02 System ..
Halted otn03 System ..
Broadcast message from root (pts/0) (Mon Mar 21 20:07:21 2005):
The system is going down for system halt NOW!
[root@otn03 bin]# dreboot otn01 otn02
———————————————————————
Rebooted otn01 System ..
Rebooted otn02 System ..
* dsensor
: 클러스터 시스템의 전체 CPU 온도 및 Cooling Fan 온도 모니터링
* dua2
: 클러스터 시스템의 데이터 일괄 동기화 명령
dua2 는 분산 다중 시스템의 데이터 일괄 동기화 명령입니다. dua 와의 차이점을 수행
프로토콜을 기존의 rsh 에서 ssh 로 변경을 한것이다. 사용방법은 dua 와 동일 하다.
* dush2
: 클러스터 시스템의 일괄 명령 수행 명령
dush2 는 분산 다중 시스템의 일괄 명령 수행 프로그램으로 관리 노드에서 dush2 를
통해 입력하는 명령을 클러스터 모든 시스템에 일괄 수행하도록 하는 프로그램이다.
기존의 dush 과 유사하나 몇가지 차이점이 있다.
기존의 dush 는 rsh 를 이용한 방법이라 적절한 보안 조치가 없을 경우 보안에 취약점
을 내재 하고 있다. 하지만 dush2 는 ssh을 이용하여 보다 보안에 안전하다.
뿐만 아니라 dush 을 사용하기 위해서 rsh, rlogin 등의 운영체제 기반의 설정이 필요
한데 dush2 는 이런 부분을 자동화 해주는 기능을 내재 하고 있다.
dush2 는 관리자 전용으로 사용하며, Teragon HPC Management Tool의 핵심 모듈이다.
사용방법은 dush 와 동일하다. 단 초기 관리자 인증키를 받을 때 –init 이란 옵션을
이용하면 된다.
[root@otn03 bin]# ./dush2 –init
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): <Enter>
Enter passphrase (empty for no passphrase): <Enter>
Enter same passphrase again: <Enter>
root@otn01’s password:
-> 최초의 인증키 생성 시 관리자 인증을 확인한다. 이는 최초에 한번 이루어 지며
그 이후에는 dush2 를 이용하여 관리자 인증 없이 인증키로 여러 시스템을 동시
에 관리 할수 있다.
[root@otn03 bin]# ./dush2 -s uptime
[otn01] 23:14:49 up 19 days, 11:06, 2 users, load average: 0.01, 0.00, 0.00
[otn02] 23:08:43 up 23 days, 3:13, 4 users, load average: 0.00, 0.00, 0.00
[otn03] 23:14:13 up 27 days, 8:00, 3 users, load average: 0.00, 0.00, 0.00
* dsysinfo
: 클러스터 시스템의 전체 시스템 기본 정보 ( kernel, resource ) – report
* dnet
: 클러스터 시스템의 네트워크 사용량 모니터링
dnet은 클러스터 시스템 별 네트워크 트래픽을 일괄적으로 모니터링 하는 명령이다.
사용법은 다음과 같다.
Usage:
dnet [netdev] [netdev]
즉 dnet 명령 뒤에 트래픽 체크를 할 네트워크 장치명을 적어 주면 된다.
[root@otn03 bin]# dnet eth0 eth1
—————————————————————————–
** network bandwidth in eth0 device
[otn01] [ I N ] 20.76 Kb/s [ OUT ] 256 Bits/s
[otn02] [ I N ] 51.45 Kb/s [ OUT ] 750.03 Kb/s
[otn03] [ I N ] 0 Bits/s [ OUT ] 256 Bits/s
** network bandwidth in eth1 device
[otn01] [ I N ] 29.62 Kb/s [ OUT ] 14.10 Kb/s
[otn02] [ I N ] 795.41 Kb/s [ OUT ] 15.96 Kb/s
[otn03] [ I N ] 19.67 Kb/s [ OUT ] 3.68 Kb/s
* pbsaccout
: 사용자별 CPU, MEM 사용 현황 결과 보고서 작성 명령
– MPI Selector
MPI Selector 는 다양한 환경의 MPI Compiler 를 사용자 입장에서 효율적으로 모두 사용
하고자 할때 필요한 툴이다.
즉 mpi 의 경우 리눅스에서 대표적으로 lam-mpi 와 mpich 를 사용하는데 mpi 와 compiler
연동시 개발자가 사용하는 대표적인 컴파일러 하나만을 연동해서 설치를 하게 된다.
**** 여러개 설치는 가능하나 기본적인 MPI 환경 설정( PATH, LIB, INC ..)을 시스템
환경 변수로 설정하여 사용을 하기 때문에 MPI 중 하나를 설치 한후 다른 기종의 MPI
를 사용할려면 사용자 레벨에서 일일이 수동으로 환경 설정을 변경하여 사용하여야 한다.
MPI Selector 는 lam-mpi(gcc), lam-mpi(pgi), lam-mpi(intel), mpich(gcc), mpich(pgi)
mpich(intel) 중 원하는 MPI 환경을 사용하기 직전에 사용자가 임의로 선택해서 사용할
수 있다.
병렬 프로그램의 성격에 따라 MPI 종류별로 각각 성능의 차이가 있다. 사용자 입장에서
사용자의 어플리케이션에 최적의 MPI 환경을 손쉽게 찾을 수 있도록 되어져 있다.
사용 방법은 다음과 같다.
# mpisel < MPI > <Compiler>
여기서 < MPI > 에 해당하는 것으로 는 lam 과 mpich 가 있다.
<Compiler> 에 해당하는 것은 gcc, pgi, intel 이 있다.
즉 lam-mpi 에 pgi Compiler 가 연동된 MPI 환경에서 작업 하고 싶은 경우 아래와 같이
입력하면..
[root@otn03 bin]# ./mpisel lam pgi
lam-pgi development environment was applied.!!
otn03(lam-pgi) root # mpicc
pgcc-Warning-No files to process
위와 같이 pgi Compiler 와 연동된 MPI 를 사용할 수 있게 된다.
이 작업은 해당 쉘에서만 적용되어지며 logoff 후에는 다시 원래 환경 설정으로 돌아가
게 된다.
– NFS Auto Mountor
4. HPC System Monitering Tool 설치 하기
– ganglia Monitering 시스템 구축 하기
ganglia는 다음의 서로다른 기능을 하는 3가지 소프트웨어로 구성된다.
– ganglia Monitor Daemon (gmond)
모니터링하기를 원하는 모든 노드에 설치되어야 한다. 다른 호스트의 gmond 데몬에
멀티캐스트 메시지를 보내어 자신의 상태를 알리며, 다른 호스트의 정보를
수집하여 자신과 다른 노드의 시스템 상태를 XML형식으로 알려준다.
– ganglia Meta Daemon (gmetad)
gmond는 같은 네트웍상의 호스트에게만 호스트정보를 전달하기 때문에
WAN(Wide Area Network)에서는 멀티캐스팅이 되지 않는다. gmetad는 WAN에서
여러 gmond 데몬으로 부터 수집된 호스트 정보를 RRD(round-robin database)에
저장한다. gmetad는 ganglia Web Interface가 설치될 웹서버에만 동작하면 된다.
– ganglia Web Interface
웹 인터페이스 모듈은 PHP언어로 작성되어 있으며 PHP가 지원되는 웹서버상에서
동작한다. gmetad에 의해 수집되어 RRD에 저장된 시스템 정보를 비쥬얼하게
보여주는 역할을 한다.
아래 사이트에서 source 를 다운 받아면 위 3가지 내용이 모두 포함되어져 있다.
* Source Download
http://ganglia.sourceforge.net/downloads.php
Source : ganglia-3.0.1.tar.gz
ganglia를 설치 하기 전에 ganglia server module 에 해당하는 gmetad 가 설치 되는
서버에서는 rrdtool 이 먼저 설치가 되어져 있어야 한다.
gmetad 서버에 rrdtool 을 설치 한다. rrdtool 설치 시 혹 cgilib 설치를 요구하면
cgilib 도 설치 한다.
# tar xzvf cgilib-0.5.tar.tar
# cd cgilib-0.5
# make
make 를 실행하면 libcgi.a 와 cgi.h 파일이 생성된다. 이를 아래 경로로 복사한다.
# cp libcgi.a /usr/local/lib
# cp cgi.h /usr/local/include
그런 후 ld.so.conf 에 /usr/local/lib 경로가 포함되었는지 확인하고 포함되어 있지
않을 경우는 포함하고 ld 를 다시 적용한다.
# vi /etc/ld.so.conf
—————————————————————————–
/usr/local/lib
# ldconfig
cgilib 설치가 완료되면 rrdtool 을 설치 한다.
# tar xzvf rrdtool-1.2.10.tar.gz
# cd rrdtool-1.2.10
# ./configure –prefix=/usr/local
# make
# make install
# make site-perl-install
rrdtool 이 설치가 완료되면 ganglia 를 설치하도록 한다.
# tar xzvf ganglia-3.0.1.tar.gz
# cd ganglia-3.0.1
gmetad 서버에는 –with-gmetad 옵션을 반드시 포함하여 configure 를 해야한다.
ganglia 의 clienet modules 에 해당하는 gmond 는 기본으로 포함되어져 있다.
# ./configure –prefix=/usr –with-gmetad
# make
# make install
ganglia 설치가 완료되면 기본적인 환경 설정을 하도록 한다.
ganglia source directory 에 gmetad 와 gmond 를 제어하는 init scripts 가 포함
되어져 있다. 이를 /etc/rc.d/init.d 로 복사한다.
혹 configure 시 –prefix 를 주었다면 init scripts file 을 열어서 GMOND, GMETAD
변수의 경로를 맞추어 주도록 한다.
# cp gmond/gmond.init /etc/rc.d/init.d/gmond -> ganglia client
# cp gmetad/gmetad.init /etc/rc.d/init.d/gmetad -> ganglia server
gmetad 서버의 rrd data 가 생성될 디렉토리를 생성하고 권한을 nobody 로 준다.
rrd data 는 apache web service 에서 생성하기 때문에 apache daemon 의 owner
인 nobody 권한이 해당 디렉토리에 주어져야 한다.
# mkdir -p /var/lib/ganglia/rrds
# chmod 755 /var/lib/ganglia/rrds
# chown nobody.nobody /var/lib/ganglia/rrds
이제 gmond 와 gmetad 관련 설정파일을 생성한다.
gmond 의 설정 파일은 /usr/sbin/gmond 실행파일에 -t flag 를 사용하면 자동
생성이 된다.
# gmond -t > /etc/gmond.conf
gmetad 의 설정 파일인 gmetad.conf 는 ganglia source 에 포함되어져 있다.
# cp /path/ganglia_src/gmetad/gmetad.conf /etc
이제 실제 모니터링 화면인 웹페이지가 gmetad 서버에서 서비스가 되어야하는데
관련 web program 은 ganglia source 에 web 이란 디렉토리에 들어 있다.
이 디렉토리에 있는 php 관련 웹 프로그램 소스를 apache 의 httpd.conf 에서
정의 하는 DocumentRoot 경로로 옮겨 놓는다.
# mkdir /usr/local/apache/htdocs/ganglia
# cp -a web/* /usr/local/apache/htdocs/ganglia
ganglia web source 에서는 기본적으로 conf.php 파일의 일부 변수를 시스템 상황
에 맞게 수정하는 걸로 설정이 완료된다.
주요 설정 항목은 다음과 같다.
$gmetad_root = “/var/lib/ganglia” : rrd data 가 생성되는 경로
define(“RRDTOOL”, “/usr/local/bin/rrdtool”) : rrdtool 실행 파일 경로
이제 Ganglia 의 설치 및 설정이 완료되었다.
ganglia 데몬을 시작한다.
* ganglia server 측 ( gmetad )
# /etc/rc.d/init.d/gmetad start
# /etc/rc.d/init.d/gmond start
# chkconfig –add gmetad
# chkconfig –add gmond
* ganglia client 측 ( gmond )
# /etc/rc.d/init.d/gmond start
정상적으로 작동하는지 확인 한다.
# gstat -a
—————————————————————————–
CLUSTER INFORMATION
Name: hpc cluster
Hosts: 3
Gexec Hosts: 0
Dead Hosts: 0
Localtime: Wed Oct 12 11:36:15 2005
CLUSTER HOSTS
Hostname LOAD CPU Gexec
CPUs (Procs/Total) [ 1, 5, 15min] [ User, Nice, System, Idle]
n002.clunix.clx
4 ( 0/ 76) [ 0.00, 0.00, 0.00] [ 0.0, 0.0, 0.0, 100.0] OFF
n001.clunix.clx
4 ( 0/ 85) [ 0.00, 0.00, 0.00] [ 0.0, 0.0, 0.0, 100.0] OFF
n003.clunix.clx
1 ( 0/ 76) [ 0.00, 0.00, 0.00] [ 0.1, 0.0, 0.2, 98.4] OFF
이제 웹 브라우저에서 gmetad 서버로 접속한다. 그럼 ganglia 모니터링 페이지가
나타날 것이다.
– 다중 클러스터 모니터링 설정 하기
Routing, Subnet 이 다른 네트워크 환경의 클러스터나 서로 다른 성격의 클러스터를
그룹별로 나누어 별도의 그룹으로 모니터링 관리가 가능하다. 이는 IDC나 CPU 종류별로
클러스터 노드를 그룹화 하여 모니터링 하고자 할때 하나의 gmeted 서버에서 다른 그룹
의 정보를 취합하여 보여준다.
설정 방법은 다음과 같다.
A 클러스터 그룹 과 B클러스터 그룹에 각각 10대의 노드들이 포함되어 있다고 가정하고
A 클러스터 그룹에 gmetad 서버를 하나 지정하고 B클러스터 그룹에서도 gmetad 서버를
하나 지정하도록 한다.
두개의 클러스터 그룹의 모니터링 화면은 A클러스터 그룹의 gmetad 서버에서 통합관리
하고자 한다.
A 클러스터 그룹의 /etc/gmetad.conf
——————————————————————————–
data_source “oracle” localhost
추가 >> data_source “cluster” 192.168.123.91
# “cluster”는 B 클러스터 그룹명이고 “192.168.123.91” 은 B클러스터 그룹의 gmetad서버 IP
..
gridname “MyGrid”
# gridname 은 전체 클러스터의 Grid 명이다.
——————————————————————————–
B 클러스터 그룹의 /etc/gmetad.conf
——————————————————————————–
data_source “cluster” localhost
.
.
trusted_hosts 127.0.0.1 192.168.123.93
# 192.168.123.93 는 A 클러스터 그룹의 gmetad 서버 IP
——————————————————————————-
이제 A,B 클러스터 그룹의 gmetad 데몬을 restart 한다.
웹 모니터링 화면의 최상위 페이지로 가면 클러스터 모니터링 화면이 A,B로 나누어 보일것
이다.
– 같은 Subnet 에서 모니터링 그룹 나누기
ganglia는 gmetad 서버 데몬과 gmond 클라이언트 데몬이 UDP 패킷을 이용하여 broadcast
방식으로 클라이언트 정보를 서버에서 수집하여 모니터링 그래프를 생성하게 된다.
같은 subnet에서 별도에 설정이 없이 여러개의 gmetad 데몬이 구동되고 있으면 모든 서버
에서 gmond가 보내는 정보를 수집할 수 있게 된다. 이는 보안적인 측면이나 관리측면에서
매우 부적합한 요소이다.
즉 gmond 데몬이 자신이 보내는 정보를 특정 서버로만 보낼 수 있어야 한다.
그러기 위해서는 /etc/gmond.conf 를 수정해 주면 된다.
# vi /etc/gmond.conf
———————————————————————————–
.
/*
udp_send_channel {
mcast_join = 239.2.11.71
port = 8649
}
*/
-> 위 부분의 기본 target IP 를 정보 수신을 허용하는 gmetad 서버 IP 로 변경해준다.
udp_send_channel {
mcast_join = 192.168.123.63
port = 8649
}
/*
udp_recv_channel {
mcast_join = 239.2.11.71
port = 8649
bind = 239.2.11.71
}
*/
-> 위 부분 역시 기본 IP를 제거하고 bind 에 자기 자신의 IP를 입력하면 된다.
udp_recv_channel {
port = 8649
bind = 192.168.123.64
}
위 설정의 경우는 서로 다른 여러개의 subnet 환경에서 특정 서버들의 정보를 동시에
관리하고자 할때 사용되는 방식이다.
만일 하나의 subnet에서 하나의 gmetad 서버로 관리 하기 위해서는 아래 와 같이 설정하면 된다.
### gmetad 서버의 gmond.conf 설정 #########
udp_send_channel {
// mcast_join = 192.168.123.63
host = 192.168.123.63
port = 8649
}
udp_recv_channel {
port = 8649
bind = 192.168.123.63
}
####### 일반 클라이언트 서버의 gmond.conf 설정 #############
udp_send_channel {
// mcast_join = 192.168.123.63
host = 192.168.123.63 -> gmetad 서버 주소
port = 8649
}
udp_recv_channel {
port = 8649
// bind = 192.168.123.63 -> 이 설정은 gmetad 서버에서만 해준다. 여기서는 생략.
}
———————————————————————————
gmetad, gmond 데몬을 재시작한다.
5. Teragon HPC Security
5.1 Command, Directory Security
5.2 Service Security ( rsh, rlogin, ssh, nfs, ftp )
5.3 Network Security ( network filtering )
6. HPC Benchmark 성능 분석 하기
6.1 NAS Parallel Benchmark
NAS Parallel Benchmarks (NPB)는 NASA Ames Research Center 로 개발 됐으며, 병렬 컴퓨터의
다양한 성능 수치를 측정 할 수 있는 대표적인 측정 프로그램 중 하나이다.
관련 정보는 다음 사이트에서 확인할 수 있다.
http://www.nas.nasa.gov/Software/NPB
다운로드를 위해서는 간단한 신상정보를 적은 후 사이트 가입 후에 다운을 받을 수 있다.
NPB 는 각각 다른 5개의 Class 로 정의 되어져 있다. 5개의 Class 란 A, B, C, W(orkstation),
S(ample)이 있으며 그 차이점은 기본적으로 Problem size (Array size) 와 계산 반복 횟수
의 차이에 있다. 일반적으로 대형 컴퓨터의 성능 평가에는 Class B 가 적합한것으로 알려져
있다.
NPB 는 5개의 Paralle kernel benchmarks 와 3개의 CFD ( Computational Fluid Dynamics )
Application benchmarks 로 구성되어져 있고 각각의 Benchmark를 실행한 결과를 Graph
로 출력할 수 있다.
* EP ( The Embarrassingly Paralle Benchmark )
EP（The Embarrassingly Parallel）벤치마크는 병렬 계산에 적합하고, 지정된 Scheme에 따른다.
다수의 Gaussian pseudorandom numbers 이용하고，２ 차원의 통계 정보를 축적한 것이다．
이 문제는 Monte Carlo applications 을 이용한 응용 프로그램에 잘 보여진다．
이 문제를 풀 때에 전송을 대부분(거의) 필요로 하지 않는 이로부터 ，어느 의미에 있어
다음에 나오는 벤치마크는 시스템이 갖는 부동 소수점 연산의 최대 실효성능을 나타내는
것이라고 말할 수 있다.
* MG ( Multigrid Benchmark)
MG(Multigrid Benchmark) 벤치마크는 ３-D Possion PDE 을 간략화한 Multi Grid Method로
풀고 있다．Class B 는 Class A 와 동일한 크기의 격자를 사용하고 있지만 내부의 루프의
반복 수가 Class A 보다(부터) 커지고 있다．또한 MG의 경우 제곱개의 프로세서를 요구한다.
* CG ( Conjugate Gradient Benchmark )
CG（Conjugate Gradient）벤치마크는 노드간 통신성능에 크게 영향을 받는다.
따라서 전용 통신장치를 갖는 super computer에서도 프로세스 수의 증가에 따라 성능이
저하되는 특징이 보여진다. 또한 CG는 대규모적인 symmetric positive definite matrix의
고유의 최소근사치를 Conjugate gradient method를 이용하고 풀고 있다．kernel 은
비 구조적 격자를 이용한 어플리케이션으로 자주 보여 진다．
* FT ( 3-D FFT PDE benchmark )
FT（3-D FFT PDE）벤치마크는 3-D partial differential equation을 FFT 이용하고 풀고 있다．
many spectral methods의 핵심이 이 kernel을 형성한다. FT 벤치마크는 라이브러리 루틴의
사용이 인정되고 있는 점에서 약간 취지를 달리 하고 있다．
* LS ( Interger Sort benchmark )
IS（Integer Sort）벤치마크는 particle method codes을 사용한 에플리케이션에 있어 중요한
Sort를 평가한 것이다． 이 타입의 application은 물리적인 면에서 particle를 잇는 Cell에
할당하고，particle이 Cell로부터 흘러나오는지 아닌지를 본다. particle-in-cell Type의
에플리케이션과 비슷하다． Sort는 particle을 다시 한번 적절한 Cell에 할당한 때에 사용된다．
* LU ( Simulated CFD Application (LU) Benchmark )
LU 벤치마크는 LU factorization를 실제로는 행하지 않고，5×5의 블록을 갖는 상하 삼각
행렬 시스템을 SSOR(Symmetric Successive Over-Relaxation)법으로 풀고 있다．
LU는 다른 프로그램과는 달리 대단히 작은 크기의 메시지를 대량으로 주고받는다는
특징이 있다. 따라서 하드웨어 성능보다는 오히려 MPI자체의 작은 크기의 메시지
통신성능에 민감하게 반응하게된다. LU의 경우 하드웨어 성능비교도구보다는 MPI의 작은
크기의 메시지 통신 성능을 비교하기에 좋은 방법이다
* SP ( Simulated CFD Application (SP ) Benchmark )
SP（Scalar Pentadiagonal）벤치마크는 X, Y, Z 방향으로 순차적으로 연립방정식을 푸는 것이다．
각 방향의 연립방정식을 풀 때 multi-partition기법을 사용하는데 이는 큰 크기의 메시지를
소량으로 주고받는다는 점에서 LU와는 대조적이라고 할 수 있다.
* BT ( Simulated CFD Application (BT) Benchmark )
BT（Block Tridiagonal）벤치마크는 SP와 유사한 구조를 갖는다
BT의 경우 프로세서의 수가 증가에 따라서 리눅스 클러스터에서의 병렬화 효율이
감소하는 경향이 있다.
– NPB 설치 하기
NPB Source 파일을 특정 위치에 풀어 놓는다.
NPB 에는 여러 시스템 형태 별로 측정 프로그램이 따로 있는데 여기서는 MPI 관련 측정 툴을
이용하도록 한다.
[root@otn03 clunix]# tar xzvf NPB3.2.tar.gz
[root@otn03 clunix]# cd NPB3.2/NPB3.2-MPI/
make 에 앞서 시스템 별로 make 환경 설정 파일을 변경을 해 주어야 한다. make 환경 설정
파일로 make.def 가 있는데 대표적인 sample 파일이 config 폴더 안에 있다.
이것을 이용하여 make.def 파일을 만들도록 한다.
참고로 NPB 는 MPI 와 Fortran77 을 사용하여 개발되어져 있다.
컴파일을 할 시스템의 MPI 환경에 맞게 make.def 파일의 CLINK, FLINK 와 같은 변수를 수정
한다.
[root@otn03 NPB3.2-MPI]# cd config/
[root@otn03 config]# cp make.def.template make.def
[root@otn03 config]# vi make.def
—————————————————————————–
.
.
#—————————————————————————
# This is the fortran compiler used for MPI programs
#—————————————————————————
MPIF77 = /usr/local/lam-gcc/bin/mpif77
# This links MPI fortran programs; usually the same as ${MPIF77}
FLINK = $(MPIF77)
.
.
#—————————————————————————
# These macros are passed to the linker to help link with MPI correctly
#—————————————————————————
FMPI_LIB = -L/usr/local/lam-gcc/lib -lmpi
#—————————————————————————
# These macros are passed to the compiler to help find ‘mpif.h’
#—————————————————————————
FMPI_INC = -I/usr/local/lam-gcc/include
.
.
.
#—————————————————————————
# This is the C compiler used for MPI programs
#—————————————————————————
MPICC = /usr/local/lam-gcc/bin/mpicc
# This links MPI C programs; usually the same as ${MPICC}
CLINK = $(MPICC)
#—————————————————————————
# These macros are passed to the linker to help link with MPI correctly
#—————————————————————————
CMPI_LIB = -L/usr/local/lam-gcc/lib -lmpi
#—————————————————————————
# These macros are passed to the compiler to help find ‘mpi.h’
#—————————————————————————
CMPI_INC = -I/usr/local/lam-gcc/include
.
.
—————————————————————————–
위와 같이 환경에 맞게 make.def 파일을 수정한 후 NPB-MPI Top 디렉토리에서
make 를 하면 된다.
NPB는 클래스, 벤치마크툴, CPU 개수 마다 다르게 실행 파일이 만들어 지므로 make
시 해당 실행 파일에 대한 정보를 적어 주어야 한다.
[root@otn03 NPB3.2-MPI]# make LU NPROCS=2 CLASS=S
LU 는 벤치마크 프로그램 이고 NPROCS 는 실행할 프로세스 수이다. CLASS 는 Problem size
에 해당한다.
[root@otn03 NPB3.2-MPI]# make LU NPROCS=4 CLASS=S
위와 같이 Process 2개 와 4개의 해당하는 실행 파일을 만들어 보자
*** 주의 점
이때 NPROCS 정의 시 특정 프로세스 수를 입력하면 에러가 발생하는 경우가 있다.
NPB 는 8종류의 대상 문제가 정의 되어 있고 문제의 특성에 의해 실행 가능한 프로세스
수가 제한되어 있다.
CT, FT, MG, LU, IS 의 프로세스 수는 2의 승수(1, 2, 4, 8, 16 .. ) 로 확장되어 지며,
SP, BT 의 프로세스 수는 n 의 2승 ( 1, 4, 9, 16, .. ) 로 확정되어 진다.
벤치마크 종류 별, 문제 크기별, 프로세스 수별로 각각 컴파일을 하는것이 상당히 비
효율적이기에 이것을 한번에 컴파일을 할수가 있다.
config 밑에 보면 suite.def 파일을 만들어 놓고 다음과 같은 형태로 컴파일 해당 변수
를 적어 주어 필요한 실행 파일을 일괄적으로 컴파일이 가능 하다.
[root@otn03 config]# vi suite.def
—————————————————————————–
# config/suite.def
# benchmark_name class process_number
ft S 2
mg S 2
sp S 2
lu S 2
bt S 2
is S 2
ep S 2
cg S 2
dt S 2
ft S 4
mg S 4
sp S 4
lu S 4
bt S 4
is S 4
ep S 4
cg S 4
dt S 4
—————————————————————————–
위와 같이 정의 한 후 make suite 로 suite.def 에 정의 된 실행 파일을 일괄적으로 만들 수 있다.
[root@otn03 config]# cd ..
[root@otn03 NPB3.2-MPI]# make suite
위와 같이 컴파일하였을 경우 컴파일 된 실행 파일의 NPB-MPI Top 디렉토리 밑의 bin 에 생성
되게 된다.
– NPB 실행 하기
[root@otn03 NPB3.2-MPI]# cd bin
생성된 실행 파일을 클러스터 각 노드에 동기화를 시켜준 후 mpirun 을 실행하여 보자
[clunix@otn03 bin]$ dua *
[clunix@otn03 bin]$ mpirun -np 4 lu.S.4
—————————————————————————–
NAS Parallel Benchmarks 3.2 — LU Benchmark
Size: 12x 12x 12
Iterations: 50
Number of processes: 4
Time step 1
Time step 20
Time step 40
Time step 50
.
.LU Benchmark Completed.
Class = S
Size = 12x 12x 12
Iterations = 50
Time in seconds = 0.14
Total processes = 4
Compiled procs = 4
Mop/s total = 727.58
Mop/s/process = 181.89
Operation type = floating point
Verification = SUCCESSFUL
Version = 3.2
Compile date = 16 Mar 2005
—————————————————————————–
위에 출력값에서 Mop/s total , Mop/s/process, Time in seconds 등으로 성능 향상을 정도
를 확인 할 수 있을 것이다.
6.2 HPL을 이용한 Linpack Test Benchmark
HPL(High-performance Linpack Benchmark)은 대용량 메모리 시스템을 벤치 마크 하는데 사용되는
벤치마크툴로 Top 500 Site 에서 사용하는 공식 프로그램으로 CPU 의 Flot 수를 측정하는 프로그램
이다. HPL 은 Blas 같은 라이브러리를 이용하여 Ax=B 형태의 주어진 연립 방정식의 해를 구함으로서
컴퓨터의 성능을 측정하는 것이다.
HPL 은 BLAS, CBLAS, ATLAS 와 같은 계산 라이브러리와 MPI 병렬 프로그램을 이용하므로 HPL 를
설치 하기 전에 반드시 위 라이브러리와 MPI 프로그램 ( mpich, lam-mpi ) 을 설치 하도록 한다.
관련 자료는 http://www.netlib.org/benchmark/hpl/ 에서 hpl.tgz 파일을 다운 받으면 된다.
또 libgoto 라이브러리를 사용하여 실행할때는 http://www.cs.utexas.edu/users/kgoto 에 가서
플랫폼에 맞는 libgoto_opt64p-r0.96-2.so, xerbla.c or xerbla.f 를 다운 받는다.
# gcc -c xerbla.c
xerbla.o 파일이 생성 될것이다.
아래 예제는 모두 Opteron System 을 기준으로 한것이다.
# tar xzvf hpl.tgz
# cd hpl
# cp setup/Make.Linux_ATHLON_CBLAS .
# vi Make.linux_ATHLON_CBLAS
—————————————————————————–
SHELL = /bin/sh
CD = cd
CP = cp
LN_S = ln -s
MKDIR = mkdir
RM = /bin/rm -f
TOUCH = touch
# 플래폼 아키텍처 명을 적어 준다. 즉 Make.XXXXXX 에서 XXXXXX 에 해당되는 명을 적어 준다.
ARCH = Linux_ATHLON_BLAS
# TOPdir 이 기본적으로는 $(HOME) 으로 잡혀 있다. 이것을 hpl 이 설치된 절대 경로로 변경해준다.
# TOPdir = $(HOME)/hpl
TOPdir = /home/clunix/hpl
INCdir = $(TOPdir)/include
BINdir = $(TOPdir)/bin/$(ARCH)
LIBdir = $(TOPdir)/lib/$(ARCH)
HPLlib = $(LIBdir)/libhpl.a
# 해당 MPI 프로그램 환경 정보를 적어준다.
# MPICH 의 경우에는 MPlib 가 libmpi.a 가 아닌 libmpich.a 이다. 주의 해야함.
# MPdir = /usr/local/mpi
# MPinc = -I$(MPdir)/include
# MPlib = $(MPdir)/lib/libmpich.a
MPdir = /usr/local/lam-gcc
MPinc = -I$(MPdir)/include
MPlib = $(MPdir)/lib/libmpi.a
# 사용할 BLAS 라이브러리 경로를 적어 준다.
# 여기서는 ATLAS 를 사용할 것이므로 ATLAS 가 설치된 PATH를 적어준다.
# LAdir = $(HOME)/netlib/ARCHIVES/Linux_ATHLON
# LAinc =
# LAlib = $(LAdir)/libcblas.a $(LAdir)/libatlas.a
LAdir = /usr/local/atlas-gcc/lib/Linux_HAMMER64SSE2_2/
LAinc =
LAlib = $(LAdir)/libcblas.a $(LAdir)/libatlas.a
# ATLAS 를 이용하지 않고 특정 BLAS를 이용하고자 할때는 다음과 같이 한다.
# LAdir = /engrid/enhpc/intel/mkl/8.0/lib/32
# LAlib = $(LAdir)/libmkl_p4p.so
# 위는 Intel MKL을 이용한 방법이다.
F2CDEFS =
HPL_INCLUDES = -I$(INCdir) -I$(INCdir)/$(ARCH) $(LAinc) $(MPinc)
HPL_LIBS = $(HPLlib) $(LAlib) $(MPlib)
HPL_OPTS = -DHPL_CALL_CBLAS
HPL_DEFS = $(F2CDEFS) $(HPL_OPTS) $(HPL_INCLUDES)
# 해당 Compiler 와 Linker 를 정의해 준다.
# CC = /usr/bin/gcc
CC = /usr/local/lam-gcc/bin/mpicc
CCNOOPT = $(HPL_DEFS)
CCFLAGS = $(HPL_DEFS) -fomit-frame-pointer -O3 -funroll-loops -W -Wall
#LINKER = /usr/bin/gcc
LINKER = /usr/local/lam-gcc/bin/mpicc
LINKFLAGS = $(CCFLAGS)
ARCHIVER = ar
ARFLAGS = r
RANLIB = echo
—————————————————————————–
**** Xeon Nocona System 에서 문제 크기를 2000 을 넘기면 MPI 가 죽는 문제가 발생
ATLAS 라이브러리를 Opteron 에서 컴파일한 라이브러리를 사용하였는데 이를 Nocona
에서 컴파일 한 라이브러리로 변경, HPL Makefile 의 C FLAGS 의 -W -Wall 를 빼고..
64bit 시스템을 정의 하는 -m64 를 포함하니 그 이상의 문제 사이즈를 처리 할 수 있었다.
**** HPL 테스트 하는 플랫폼 별로 ATLAS 라이브러리를 만들지 않으면 라이브러리에서 지원
하는 Memory Size 같은 부분에서 시스템 별로 최적화 될수 없다.
**** 컴파일 역시 -m64를 붙여서 64bit 시스템에 맞게 Compile 이 될수 있게 해야 한다.
그런 후 Make.top 와 Makefile 의 arch 부분도 위의 arch 부분과 동일하게 변경해 준다.
#
arch = Linux_ATHLON_CBLAS
#
컴파일을 한다.
# make build arch=Linux_ATHLON_CBLAS
만일 컴파일 중 Error 가 발생하면 Make 설정 부분을 다시 점검해 보라
컴파일이 무사히 끝나면 bin/Linux_ATHLON_CBLAS 안에 HPL.dat 와 xhpl 파일이 생성되어져 있을 것이다.
xhpl 실행 파일은 계산 노드 전 노드에 동일한 경로에 복사를 해둔다.
# dua xhpl
그런 후 HPL.dat 파일을 플랫폼에 맞게 수정하여 xhpl 를 실행 하면 linpack 수치를 구할 수 있다.
# default HPL.dat
# vi HPL.dat
—————————————————————————–
HPLinpack benchmark input file
Innovative Computing Laboratory, University of Tennessee
HPL.out output file name (if any)
6 device out (6=stdout,7=stderr,file)
4 # of problems sizes (N)
29 30 34 35 Ns
4 # of NBs
1 2 3 4 NBs
0 PMAP process mapping (0=Row-,1=Column-major)
1 # of process grids (P x Q)
2 1 4 Ps
2 4 1 Qs
16.0 threshold
3 # of panel fact
0 1 2 PFACTs (0=left, 1=Crout, 2=Right)
2 # of recursive stopping criterium
2 4 NBMINs (>= 1)
1 # of panels in recursion
2 NDIVs
3 # of recursive panel fact.
0 1 2 RFACTs (0=left, 1=Crout, 2=Right)
1 # of broadcast
0 BCASTs (0=1rg,1=1rM,2=2rg,3=2rM,4=Lng,5=LnM)
1 # of lookahead depth
0 DEPTHs (>=0)
2 SWAP (0=bin-exch,1=long,2=mix)
64 swapping threshold
0 L1 in (0=transposed,1=no-transposed) form
0 U in (0=transposed,1=no-transposed) form
1 Equilibration (0=no,1=yes)
8 memory alignment in double (> 0)
—————————————————————————–
# customizing HPL.dat
# vi HPL.dat
—————————————————————————–HPLinpack benchmark input file
Innovative Computing Laboratory, University of Tennessee
HPL.out output file name (if any)
6 device out (6=stdout,7=stderr,file)
1 # of problems sizes (N)
20000 Ns
1 # of NBs
104 NBs
0 PMAP process mapping (0=Row-,1=Column-major)
1 # of process grids (P x Q)
1 Ps
6 Qs
16.0 threshold
1 # of panel fact
1 PFACTs (0=left, 1=Crout, 2=Right)
1 # of recursive stopping criterium
4 NBMINs (>= 1)
1 # of panels in recursion
2 NDIVs
1 # of recursive panel fact.
2 RFACTs (0=left, 1=Crout, 2=Right)
1 # of broadcast
0 BCASTs (0=1rg,1=1rM,2=2rg,3=2rM,4=Lng,5=LnM)
1 # of lookahead depth
1 DEPTHs (>=0)
2 SWAP (0=bin-exch,1=long,2=mix)
64 swapping threshold
0 L1 in (0=transposed,1=no-transposed) form
0 U in (0=transposed,1=no-transposed) form
1 Equilibration (0=no,1=yes)
8 memory alignment in double (> 0)
—————————————————————————–
xhpl 실행파일을 실행 하기 위해서는 먼저 mpi 프로그램이 설치 되어져 있어야 한다.
이 문서에서의 설정은 lam-mpi 를 기준으로 작성되어져 있으니 lam-mpi 환경에서 구동하는 방법을 설명 하도록
하겠다.
lam-mpi 는 root 에서 실행 할수 없다. 그러므로 일반 계정에 lamboot 을 시키도록 한다.
$ cat lamhost
——————————————–
otn01 cpu=2
otn02 cpu=2
otn03 cpu=2
——————————————–
먼저 위 시스템은 opteron 244 ( 1.8G * 2) Process 의 3대 노드로 클러스터가 구성되어져 있다.
$ lamboot -v -b lamhost
LAM 7.1.1/MPI 2 C++/ROMIO – Indiana University
n-1<10965> ssi:boot:base:linear: booting n0 (otn03)
n-1<10965> ssi:boot:base:linear: booting n1 (otn02)
n-1<10965> ssi:boot:base:linear: booting n2 (otn01)
n-1<10965> ssi:boot:base:linear: finished
$ mpirun -np 6 xhpl > report
$ vi report
—————————————————————————–
============================================================================
HPLinpack 1.0a — High-Performance Linpack benchmark — January 20, 2004
Written by A. Petitet and R. Clint Whaley, Innovative Computing Labs., UTK
============================================================================
An explanation of the input/output parameters follows:
T/V : Wall time / encoded variant.
N : The order of the coefficient matrix A.
NB : The partitioning blocking factor.
P : The number of process rows.
Q : The number of process columns.
Time : Time in seconds to solve the linear system.
Gflops : Rate of execution for solving the linear system.
The following parameter values will be used:
N : 29 30 34 35
NB : 1 2 3 4
PMAP : Row-major process mapping
P : 2
Q : 2
PFACT : Left Crout Right
NBMIN : 2 4
NDIV : 2
RFACT : Left Crout Right
BCAST : 1ring
DEPTH : 0
SWAP : Mix (threshold = 64)
L1 : transposed form
U : transposed form
EQUIL : yes
ALIGN : 8 double precision words
—————————————————————————-
– The matrix A is randomly generated for each test.
– The following scaled residual checks will be computed:
1) ||Ax-b||_oo / ( eps * ||A||_1 * N )
2) ||Ax-b||_oo / ( eps * ||A||_1 * ||x||_1 )
3) ||Ax-b||_oo / ( eps * ||A||_oo * ||x||_oo )
– The relative machine precision (eps) is taken to be 1.110223e-16
– Computational tests pass if scaled residuals are less than 16.0
============================================================================
T/V N NB P Q Time Gflops
—————————————————————————-
WR00L2L2 29 1 2 2 0.04 4.506e-04
—————————————————————————-
||Ax-b||_oo / ( eps * ||A||_1 * N ) = 0.0674622 …… PASSED
||Ax-b||_oo / ( eps * ||A||_1 * ||x||_1 ) = 0.0519667 …… PASSED
||Ax-b||_oo / ( eps * ||A||_oo * ||x||_oo ) = 0.0174238 …… PASSED
============================================================================
T/V N NB P Q Time Gflops
—————————————————————————-
WR00L2L4 29 1 2 2 0.04 4.520e-04
—————————————————————————-
||Ax-b||_oo / ( eps * ||A||_1 * N ) = 0.0674622 …… PASSED
||Ax-b||_oo / ( eps * ||A||_1 * ||x||_1 ) = 0.0519667 …… PASSED
||Ax-b||_oo / ( eps * ||A||_oo * ||x||_oo ) = 0.0174238 …… PASSED
.
.
—————————————————————————–
위와 같은 형식의 데이터가 만들어 진다. 위 데이터 수치는 기본 HPL.dat 파일로 실행한것으로
전혀 Customizing 이 되어져 있지 않다. HPL.dat 파일을 자신의 플랫폼에 맞게 최적화 시켜야
한다. 먼저 최적화 HPL.dat 파일을 만든 이후 네트워크 환경 이나 라이브러리, Compiler 와
같은 것을 변경해 가면서 최고의 flops 수를 낼수있는 환경을 찾아 내면 된다.
최적화 HPL.dat 로 실행 했을 경우
—————————————————————————-
============================================================================
T/V N NB P Q Time Gflops
—————————————————————————-
WR10R2C4 25000 256 2 3 680.44 1.531e+01
—————————————————————————-
||Ax-b||_oo / ( eps * ||A||_1 * N ) = 0.0614958 …… PASSED
||Ax-b||_oo / ( eps * ||A||_1 * ||x||_1 ) = 0.0151841 …… PASSED
||Ax-b||_oo / ( eps * ||A||_oo * ||x||_oo ) = 0.0026148 …… PASSED
============================================================================
Finished 20 tests with the following results:
20 tests completed and passed residual checks,
0 tests completed and failed residual checks,
0 tests skipped because of illegal input values.
—————————————————————————-
End of Tests.
============================================================================
—————————————————————————-
100M Switch 환경에서 Opteron 6 CPU로 최고 7.5Gflops 까지 나온다. 이때 CPU 사용율이 전체적으로
70% 정도이다. 클러스터 최고의 환경이 완료되면 CPU 사용률이 100% 에 가깝게 나온다.
네트워크,메모리,라이브러리,컴파일러와 같은 환경을 변경해서 CPU 사용률이 100% 가깝게 나올때
측정한 flops 수가 가장 이상적인 수치일것이다. Gigabit 환경에서 CPU 평균 사용율 90% 와 최고
15Gflops 까지 나오는 것을 확인했다.
HPL.dat 튜닝은 http://www.netlib.org/benchmark/hpl/tuning.html 문서를 참고 하라.
6.3 Parall_add 를 이용한 간단한 정수 연산 Benchmark
parall_add 는 A=A+1 과 같은 계산 방식으로 사용자가 지정하는 num 값까지 순차적으로
+ 시키는 역활을 병렬화 한 것이다. 정수 연산의 성능을 측정할 수 있는 간단한 MPI
프로그램이다.
[clunix@otn03 clunix]$ vi parall_add.c
—————————————————————————–
/* This program is for MPI testing
1. This program add from 1 to input_number.
2. and report wall clock time and speedup.
*/
#include <mpi.h>
#include <stdio.h>
void notice()
{
printf(“\\n*****************************************************”);
printf(“\\n Notice !!”);
printf(“\\nIf input is not enough large,”);
printf(“\\n Parallel method is not efficient.”);
printf(“\\n\\nThis program will add from 1 to your input.”);
printf(“\\n*****************************************************”);
return;
}
int main(int argc, char **argv)
{
unsigned long int i;
int rank, size;
unsigned long int SerialSum, sum;
unsigned long int TDomain, SDomain;
unsigned long int start, end;
double stime1, stime2, ptime1, ptime2;
float speedup;
char temp[30];
MPI_Status status;
/* initialize MPI */
MPI_Init(&argc, &argv);
MPI_Comm_size(MPI_COMM_WORLD,&size);
MPI_Comm_rank(MPI_COMM_WORLD,&rank);
/* read input and distribute domain */
if(rank == 0)
{ notice();
printf(“\\nInput integer number : “);
fscanf(stdin,”%s”,&temp[0]);
TDomain=0;
TDomain=atoi(temp);
if(TDomain <= 0)
{ printf(“\\nInput Error!! TDomain=%lu”,TDomain);
return 1;
}
for(i=1; i<size; i++)
MPI_Send(&TDomain,1,MPI_UNSIGNED_LONG,i,0,MPI_COMM_WORLD);
}
else
MPI_Recv(&TDomain,1,MPI_UNSIGNED_LONG,0,0,MPI_COMM_WORLD,&status);
/* initialize variables */
sum=0;
SerialSum=0;
ptime1=MPI_Wtime();
SDomain=TDomain/size;
start=rank*SDomain+1;
if(rank != size-1)
end=start+SDomain-1;
else
end=TDomain;
/* compute sum of sub_domain */
for(i=start; i<=end; i++)
sum=sum+i;
/* compute sum of gloabl_domain */
i=sum;
MPI_Reduce(&i,&sum,1,MPI_UNSIGNED_LONG,MPI_SUM,0,MPI_COMM_WORLD);
/* compute wall clock time */
ptime2=MPI_Wtime();
ptime1=ptime2-ptime1;
/* compute sum by serial computing */
stime1=MPI_Wtime();
for(i=1; i<=TDomain; i++)
SerialSum=SerialSum+i;
/* compute wall clock time */
stime2=MPI_Wtime();
ptime1=ptime2-ptime1;
/* report result and speed up */
if(rank == 0)
{ printf(“\\n Parallel SUM = %lu, Wall clock time = %f”,sum,ptime2-ptime1);
printf(“\\n Serial Sum = %lu, Wall clcok time = %f”,SerialSum,stime2-stime1);
speedup=(stime2-stime1)/(ptime2-ptime1);
printf(“\\n SPEED UP = %f\\n”,speedup);
}
if(rank == 0) printf(“\\nGoodbye! : )\\n”,rank);
MPI_Finalize();
return 0;
}
—————————————————————————–
위 소스를 mpicc 로 컴파일 한다.
[clunix@otn03 clunix]$ mpicc -o parall_add parall_add.c
생성된 실행 파일을 계산 노드들의 동일한 위치에 복사한다.
[clunix@otn03 clunix]$ dua parall_add
[clunix@otn03 clunix]$ lamboot -v -b lamhosts
LAM 7.1.1/MPI 2 C++/ROMIO – Indiana University
n-1<31303> ssi:boot:base:linear: booting n0 (otn03)
n-1<31303> ssi:boot:base:linear: booting n1 (otn02)
n-1<31303> ssi:boot:base:linear: booting n2 (otn01)
n-1<31303> ssi:boot:base:linear: finished
[clunix@otn03 clunix]$ mpirun -np 6 parall_add
*****************************************************
Notice !!
If input is not enough large,
Parallel method is not efficient.
This program will add from 1 to your input.
*****************************************************
Input integer number : 10000000 -> 원하는 값을 적는다
그럼 아래와 같이 결과가 나온다.
Parallel SUM = 5000000050000000, Wall clock time = 0.075384
Serial Sum = 5000000050000000, Wall clcok time = 0.507924
SPEED UP = 6.737829
Goodbye! : )
즉 1대 노드로 계산 한거 보다 6.7 배의 성능 향상이 있다는는 것을 알수 있다.
CPU 아키텍처 별로 성능 차이가 난다. 실제 AMD 계열 프로세스 보다 Pentium 계열 프로세서
시스템에서 성능이 더 월등한것을 알수 있다. 하지만 이는 정수 연산에 해당되는 것이다.
실제 실수 연산 및 부동 소수점 연산등의 성능을 알 수 있는 linpack 테스트 등에서는
AMD 계열이 성능이 우수함을 확인 할수 있다
6.4 Stream 메모리 Benchmark
Stream Memory Benchmark 는 Memory 의 bandwidth 를 측정하는 도구 이다.
HPC 클러스터 시스템과 같은 계산용 시스템에서는 실제 메모리 성능이 전체 성능을 좌우 하게
된다. 현재 시스템에 장착된 메모리의 대역폭이 어느 정도 있지를 측정하는 도구이다.
상세 정보는 다음 사이트에서 확인 할수 있다.
http://www.cs.virginia.edu/stream
* 아래는 local system 의 single cpu에 해당되는 메모리 대역폭을 측정하는 방법이다.
DDR Memory
[root@otn03 hpc]# tar xzvf stream_memory.tgz
[root@otn03 hpc]# cd StreamMemory/Code/
[root@otn03 Code]# gcc -O stream.c -o stream
[root@otn03 Code]# ./stream
————————————————————-
This system uses 8 bytes per DOUBLE PRECISION word.
————————————————————-
Array size = 2000000, Offset = 0
Total memory required = 45.8 MB.
Each test is run 10 times, but only
the *best* time for each is used.
————————————————————-
Your clock granularity/precision appears to be 2 microseconds.
Each test below will take on the order of 13981 microseconds.
(= 6990 clock ticks)
Increase the size of the arrays if this shows that
you are not getting at least 20 clock ticks per test.
————————————————————-
WARNING — The above is only a rough guideline.
For best results, please be sure you know the
precision of your system timer.
————————————————————-
Function Rate (MB/s) Avg time Min time Max time
Copy: 1861.8853 0.0155 0.0172 0.0172
Scale: 1838.8761 0.0157 0.0174 0.0175
Add: 2066.1172 0.0209 0.0232 0.0233
Triad: 2045.4199 0.0211 0.0235 0.0235
————————————————————-
Solution Validates
————————————————————-
SDRAM 측정
————————————————————-
This system uses 8 bytes per DOUBLE PRECISION word.
————————————————————-
Array size = 2000000, Offset = 0
Total memory required = 45.8 MB.
Each test is run 10 times, but only
the *best* time for each is used.
————————————————————-
Your clock granularity appears to be less than one microsecond.
Each test below will take on the order of 62057 microseconds.
(= -2147483648 clock ticks)
Increase the size of the arrays if this shows that
you are not getting at least 20 clock ticks per test.
————————————————————-
WARNING — The above is only a rough guideline.
For best results, please be sure you know the
precision of your system timer.
————————————————————-
Function Rate (MB/s) Avg time Min time Max time
Copy: 320.1118 0.1065 0.1000 0.1890
Scale: 363.1081 0.1126 0.0881 0.2751
Add: 381.4946 0.1270 0.1258 0.1630
Triad: 351.4601 0.1414 0.1366 0.1793
————————————————————-
Solution Validates
————————————————————-
6.5 Bonnie++ 디스크 I/O Benchmark
Bonnie++ 는 하드디스크와 파일시스템의 성능을 측정하는 대표적인 벤치마크 툴로서
로컬 시스템에서 디스크 쓰기/읽기등을 시뮬레이션하여 디스크와 파일시스템의 성능
을 측정하게 된다. 이전의 HPC 클러스터 시스템은 계산 전용으로 사용되어 CPU 와
Mem 그리고 네트워크 자원을 주로 이용하였는데 요즘에는 다양한 어플리케이션이
병렬화 되고, 특정 어플리케이션에서는 엄정난 량의 데이터를 계산 과정에서 생성하
는 경우도 종종 있다. 즉 디스크 I/O 과 전체적인 성능에 중요한 역활을 하고 있기
에 구축 시스템의 디스크와 파일시스템의 성능 역시 측정해 볼 필요가 있다.
[root@otn03 bonnie++-1.93c]# ./configure –prefix=/usr/local/bonnie
[root@otn03 bonnie++-1.93c]# make && make install
[root@otn03 bonnie++-1.93c]# cd /usr/local/bonnie/sbin
[root@otn03 bonnie++-1.93c]# ./bonnie++ -u root -d /data2/tmp -c 10 -s 500 -r 400
** bonnie++ 에는 다양한 옵션이 있는데 여기서는 실제 사용에 꼭 필요한 옵션에 대해서
만 알아보도록 하겠다
-u : bonnie++ 를 실행할 유저 ( bonnie++ 은 root 에서만 사용이 가능 )
-d : bonnie++ 에서 시뮬레이션을 진행할 때 생성되는 임시 파일이 생기는 곳이다
-c : 동시 디스크 사용자
-s : 총 생성 디스크 용량
-r : 시뮬레이션때 사용되는 메모리량 ( 시스템의 실제 메모리 보다 크게 설정하면..
시스템에 문제 발생할수도 있음 – 실제 메모리와 비슷하거나 조금 작게 지정함 )
그럼 다음과 같은 형태의 출력값이 나온다.
—————————————————————————–
Using uid:0, gid:0.
Writing a byte at a time…done
Writing intelligently…done
Rewriting…done
Reading a byte at a time…done
Reading intelligently…done
start ’em…done…done…done…done…done…
Create files in sequential order…done.
Stat files in sequential order…done.
Delete files in sequential order…done.
Create files in random order…done.
Stat files in random order…done.
Delete files in random order…done.
Version 1.93c ——Sequential Output—— –Sequential Input- –Random-
Concurrency 10 -Per Chr- –Block– -Rewrite- -Per Chr- –Block– –Seeks–
Machine Size:chnk K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
alang 500M:1k 62 77 22891 52 13727 22 701 73 50382 29 +++++ +++
Latency 117ms 1176ms 949ms 32032us 30153us 46us
Version 1.93c ——Sequential Create—— ——–Random Create——–
alang -Create– –Read— -Delete– -Create– –Read— -Delete–
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 537 82 +++++ +++ 16909 47 623 92 +++++ +++ 21049 60
Latency 111ms 5793us 115ms 62022us 6945us 8536us
1.93c,1.93c,alang,10,/data2/tmp/test,500M,1k,62,77,22891,52,13727,22,701,73,50382,29,ㅑ
+++++,+++,16,,,,,537,82,+++++,+++,16909,47,623,92,+++++,+++,21049,60,117ms,1176ms,949ms,
32032us,30153us,46us,111ms,5793us,115ms,62022us,6945us,8536us
—————————————————————————–
위와 같은 출력값을 보아 파악하기 힘듬으로 깔끔한 html 형태나 txt 형태로 변환 시켜 주는
프로그램에 bonnie++ 에 포함되어져 있다. bin/ 밑에 보면 bon_csv2txt, bon_csv2html 명령이
그것이다.
./bonnie++ -u root -d /data2/tmp -c 10 -s 500:1024 -r 400 | ../bin/bon_csv2txt > diskbench.txt
./bonnie++ -u root -d /data2/tmp -c 10 -s 500:1024 -r 400 | ../bin/bon_csv2html > diskbench.html
와 같이 사용하면 된다.
이제 하드디스크 방식과 ( IDE, SATA, SCSI, SAN ) 파일시스템 방식 ( ext3, reierfs, xfs, jfs, nfs, )
의 시스템에서 어느 정도의 성능이 나오는지 판단 할 수 있을 것이다.
아래는 bonnie++ 출력값을 txt 로 변환한 것이다.
—————————————————————————–
Version 1.93c ——Sequential Output—— –Sequential Input- –Random-
-Per Chr- –Block– -Rewrite- -Per Chr- –Block– –Seeks–
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
alang 500M:1k 63 79 23631 54 13861 23 710 77 48775 23 +++++ +++
Latency 110ms 1446ms 640ms 15136us 33049us 47us
——Sequential Create—— ——–Random Create——–
-Create– –Read— -Delete– -Create– –Read— -Delete–
files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
alang 16 735 88 +++++ +++ 20194 67 758 90 +++++ +++ 20888 63
Latency 120ms 5752us 5985us 64043us 5766us 6040us
—————————————————————————–
실제 파일 쓰기를 진행 할때 작업 속도와 CPU 사용량을 알수 있다.
6.6 Netpipe 네트워크 성능 Benchmark
Netpipe(Network Protocol Independent Performaance Evaluator) 는 시스템 간의 네트워크 성능을
측정하는 벤치 마크 프로그램이다. TCP, MPI,PVM 등 다양한 통신 방식별로 네트워크 성능을 측정할
수 있는 툴이 있고..Myrinet, Infiniband, Fast Ethernet, SCI 등과 같은 다양한 디바이스별 네트
워크 성능 측정이 가능하다.
관련 벤치마크 툴의 다운로드는 다음 사이트에서 가능하다.
http://www.scl.ameslab.gov/netpipe
먼저 다운 받은 소스를 적당한 위치에서 푼다.
[root@otn02 hpc]# tar xzvf NetPIPE_3.6.2.tar.gz
[root@otn02 hpc]# cd NetPIPE_3.6.2
makefile 을 수정한다.
makefile 에는 각 측정 대상의 프로그램이 설치된 경로를 적도록 되어져 있다.
각각 해당하는 프로그램 패스를 적절히 적도록 한다.
여기서는 tcp 와 MPI 관련 네트워크 성능 측정을 하겠다.
[root@otn02 NetPIPE_3.6.2]# vi makefile
—————————————————————————–
CC = cc
CFLAGS = -O
SRC = ./src
# 해당 MPICC 의 PATH 를 적어 넣는다
MPICC = /usr/local/lam-gcc/bin/mpicc
.
.
MPI2CC = /usr/local/lam-gcc/bin/mpicc
MPI2_LIB = /usr/local/lam-gcc/lib
MPI2_INC = /usr/local/lam-gcc/include
.
.
—————————————————————————–
tcp 와 mpi 관련 측정 프로그램을 컴파일 한다.
[root@otn02 NetPIPE_3.6.2]# make tcp
[root@otn02 NetPIPE_3.6.2]# make mpi
테스트를 할 원격 시스템에 컴파일 된 실행 파일을 복사하던지 해당 시스템에서 동일하게
컴파일을 해준다.
*** TCP Network 성능 측정 방법 ***
[root@otn03 NetPIPE_3.6.2]# ./NPtcp ( remote system )
[root@otn02 NetPIPE_3.6.2]# ./NPtcp -h otn03 ( local system )
.
.
109: 2097149 bytes 3 times –> 894.64 Mbps in 17884.17 usec
110: 2097152 bytes 3 times –> 894.26 Mbps in 17891.80 usec
111: 2097155 bytes 3 times –> 894.32 Mbps in 17890.65 usec
112: 3145725 bytes 3 times –> 895.49 Mbps in 26800.99 usec
113: 3145728 bytes 3 times –> 895.52 Mbps in 26800.00 usec
114: 3145731 bytes 3 times –> 895.67 Mbps in 26795.67 usec
115: 4194301 bytes 3 times –> 896.17 Mbps in 35707.67 usec
116: 4194304 bytes 3 times –> 896.22 Mbps in 35705.69 usec
117: 4194307 bytes 3 times –> 896.20 Mbps in 35706.32 usec
118: 6291453 bytes 3 times –> 896.78 Mbps in 53524.85 usec
119: 6291456 bytes 3 times –> 896.78 Mbps in 53524.65 usec
120: 6291459 bytes 3 times –> 896.79 Mbps in 53524.18 usec
121: 8388605 bytes 3 times –> 896.97 Mbps in 71351.17 usec
122: 8388608 bytes 3 times –> 896.99 Mbps in 71349.50 usec
123: 8388611 bytes 3 times –> 897.01 Mbps in 71348.35 usec
이와 같이 결과가 출력된다. 만일 결과 출력 파일을 파일로 자동 저장 하고 싶을
경우는 local system 에서 -o 옵션 뒤에 저장 파일명을 적어 주면 된다.
[root@otn02 NetPIPE_3.6.2]# ./NPtcp -h otn03 -o net_report.txt
위 두 시스템의 간의 네트워크 성능 측정 결과는 다음과 같다.
Message Size : 838.8611 Mbyte
Net Bandwidth : 897.01 Mbps
Latency : 71348.35 usec
*** MPI 네트워크 성능 측정 방법 *****
먼저 lamboot 로 mpi 해당 node에 lamd 데몬을 실행한다.
[clunix@otn03 clunix]$ lamboot -v -b lamhosts
LAM 7.1.1/MPI 2 C++/ROMIO – Indiana University
n-1<31167> ssi:boot:base:linear: booting n0 (otn03)
n-1<31167> ssi:boot:base:linear: booting n1 (otn02)
** 두 시스템의 동일한 경로에 NPmpi 실행 파일이 존재해야 한다.
[clunix@otn03 clunix]$ mpirun -np 2 /usr/local/bin/NPmpi
0: otn03
1: otn02
Now starting the main loop
0: 1 bytes 2748 times –> 0.24 Mbps in 31.94 usec
1: 2 bytes 3130 times –> 0.47 Mbps in 32.15 usec
2: 3 bytes 3110 times –>
.
.
114: 3145731 bytes 3 times –> 893.14 Mbps in 26871.36 usec
115: 4194301 bytes 3 times –> 894.18 Mbps in 35786.83 usec
116: 4194304 bytes 3 times –> 894.05 Mbps in 35791.99 usec
117: 4194307 bytes 3 times –> 894.09 Mbps in 35790.80 usec
118: 6291453 bytes 3 times –> 895.49 Mbps in 53601.98 usec
119: 6291456 bytes 3 times –> 895.50 Mbps in 53601.50 usec
120: 6291459 bytes 3 times –> 895.53 Mbps in 53599.68 usec
121: 8388605 bytes 3 times –> 896.03 Mbps in 71425.84 usec
122: 8388608 bytes 3 times –> 896.04 Mbps in 71425.68 usec
123: 8388611 bytes 3 times –> 895.99 Mbps in 71429.13 usec
두 시스템의 MPI 네트워크 성능은 다음과 같다.
Message Size : 8388608 bytes
Net Bandwidth : 896.04 Mbps
Latency : 71425.68 usec
**** otn02, otn03 노드의 네트워크 환경은 Gigabit Ethernet 에 Gigabit Switch 환경이다.
**** Netpipe 성능 측정은 순수 네트워크 성능만을 측정한것으로 위 수치가 896.04 Mbps
의 성능이 나왔다고 해서 모든 네트워크 프로그램에서 위 성능이 나오는 것은 아니다.
실제 CPU, System I/O, Disk I/O 등등 여러가지 환경에 의해 실제 네트워크 성능이 결정된다.
본 설정은 순수 네트워크 장비의 성능을 측정하는 도구로 보면 된다.
************************************************************************************
이로써 1년 반에 걸친 클루닉스의 테라곤 HPC 의 기술 정리가 완료 되었습니다. 이 HPC 기술
문서는 그 동안 제가 행해온 클루닉스 기술부의 마지막 기술 세미나 자료로 리눅스 클러스터링에 대한
아랑 방식의 전반적 기술을 정리한 의미가 강한 문서입니다.
제가 사랑하는 우리 부서원들과 같이 공유하여 모두의 기술 발전에 도움이 되길 바랍니다.
********************************************** 아랑 *********************************
