Monthly Archives: September 2010

Linux #5 : System File Protection

Linux는 Windows만큼이나 Security에 취약성을 보이지는 않는다고 하지만 그렇다고 해서 그냥 두고 볼 일은 아니죠. Security 침해를 방지하기 위한 최소한의 아니 될 수 있는 한 많은 부분에 대해서 강화를 해야 합니다. 그럼, 먼저 System File Protection 부분에서 Security를 강화 해 보도록 하죠.

System File Protection이라고 하면, Linux System 안에서 사용되고 있는 각 종 File 및 System Directory에 대한 Permission, Ownership, Attribute 등이 될 것 입니다.

1. Boot Loader

chmod 600 /boot/grub/grub.conf chmod 600 /boot/lilo.conf chattr +i /boot/grub/grub.conf

2. /tmp, /var/tmp에 1777 permission

chmod 777 /tmp /var/tmp chmod +t /tmp /var/tmp chgrp 0 /tmp

3. /, /usr, /var에 755 Permission

755이상의 Permission이 할당되어 있다면 문제의 여지가 많습니다.

chmod 755 / /usr /var

4. User Home Directory Permission

해당 User ID에 대해서만 User Read, Write, Execute만 부여하고 (700), Group, Other에 대해서는 어떠한 Permission도 부여하지 않는 것이 중요합니다.

chmod 700 /home/*

여기서 중요한 건 1회성에 그치지 않도록 User가 생성될 때 자동으로 700을 부여 할 필요가 있는데 이는 아래와 같이 하면 됩니다. UMASK 022가 Default 일텐데, 077로 고쳐주세요.

# vi /etc/login.defs .. UMASK 077 ..

여기서 UMASK는 Permission을 다르게 표기하는데, 그냥 777 – 022 => 755 , 777 – 077 => 700 이렇게 생각하시면 되요.

5. 각종 System File에 각각의 Permission 및 Attribute 부여

/var 관련 부분

chmod 751 /var/log chmod 644 /var/log/messages chmod 660 /var/log/wtmp #Who is logged in now. Use who to view chmod 640 /var/log/lastlog #Who has logged in befor. Use last to view chmod 600 /var/spool/cron/root

/etc 관련 부분

chmod 600 /etc/crontab chmod 640 /etc/syslog.conf chmod 640 /etc/logrotate.conf chmod 600 /etc/ftpusers chmod 644 /etc/passwd chmod 400 /etc/shadow chmod 400 /etc/gshadow chmod 750 /etc/pam.d chmod 600 /etc/hosts.allow /etc/hosts.deny chmod 600 /etc/securetty #TTY interfaces that allow root logins chmod 700 /etc/security chmod 750 /etc/rc.d/init.d /etc/init.d chmod 751 /etc/sysconfig chmod 400 /etc/cron.allow /etc/cron.deny chmod 400 /etc/ssh chmod 400 /etc/sysctl.conf chmod 600 /etc/xinetd.conf /etc/inetd.conf chmod 600 /etc/login.defs chmod 644 /etc/services /var/run/syslogd.pid chmod -R g-w /etc

6. System Binary File에 Permission & Attribute 부여

chmod 4750 /bin/su chattr +i /bin/su chmod 750 /usr/sbin/useradd chmod 750 /usr/bin/top chmod 750 /sbin/fdisk chmod 750 /sbin/mfs* chmod 750 /sbin/fsck* chattr +i /usr/sbin/useradd chattr +i /usr/bin/top chattr +i /sbin/fdisk chattr +i /sbin/mkfs* chattr +i /sbin/fsck* chmod 100 /bin/ping /bin/ping6 chmod g-s /usr/bin/wall chmod g-s /usr/bin/write chmod u-s /usr/bin/rlogin chmod u-s /bin/umount chmod g-s /sbin/netreport chmod u-s /usr/bin/rsh

필요에 따라서 설정을 잘 조정 해야하니 주의하세요.

Linux #4 : Basic of Shell & Shell Scripting #1

Leave a reply

Shell은 Interface의 한 부분으로 Command Base의 User Interface라고 할 수 있습니다. 그 이유는 Keyboard를 통해 입력하여 Enter Key를 누르는 순간 동작 및 결과 값을 보여주기 때문이죠. 이는 Unix(Linux)의 기초라고도 할 수 있습니다.

Shell을 이용함에 있어 중요한 것 중 하나가 Stream인데, 이는 여러 Command를 조합하여 사용할 수 있는 걸 말하죠. Input -> Command -> Command -> Output과 같은 식으로 결과를 조작 할 수 있게 됩니다.

$ cat file1 file2 | grep "hello world" | sort -r | less 여기서는 cat, grep, sort, less라는 command가 사용되었죠.

위에서 command는 Input과 Output을 가지게 되는데 이걸 Standard Input, Standard Output으로 표현 합니다. 여기서 Standard가 붙은 이유는 변경 가능하기 때문이죠. 이 변경을 Redirect라고 합니다.

$ cat < file1 | grep "hello world" | sort -r > result_file 두 기호 "<"과 ">"로 Redirect를 행합니다. Standard Input은 file1, Standard Output은 result_file이 됩니다.

그럼, 일단 변수에 대해서 정의를 해보면, Shell 변수는 미리 선언 할 필요가 없고 처음 사용될 때 만들어지며, 대소문자를 구별하며 기본적으로 문자열로 저장하게 된다. 만약 계산이 필요하다면 수치로 변환되어 계산되고 이후 문자열로 저장되고, “$“을 붙여서 사용한다. 단, 변수에 값을 대응 할 시에는 “$“을 사용하지 않습니다.

변수를 미리 선언하는 경우 ex) float a, b; Shell 변수의 경우(값 대입시) ex) HOME="Hello World" Shell 변수의 경우(사용시) ex) echo $HOME

변수는 환경 변수, 인자 변수, 일반 변수로 구분된다.
환경 변수의 경우는 Shell 기동 후 기본적으로 Setting 되어 있는 변수입니다.

$0 : 실행 된 Shell Script Name $# : Scripts에 넘겨진 인자의 갯수 $$ : Shell Script의 Process ID

이고, 일반 변수를 export를 사용하여 환경 변수로 처리할 수 있습니다.

export HOME

인자 변수의 경우는 Shell Script에 인자를 넘겨 줄 때 그 인자들에 대한 정보를 가지는 변수입니다.

$1 ~ $nnn : 넘겨진 인자들 $* : 스크립트에 전달된 인자들을 모아놓은 문자열 $@ : $*과 동일함

그리고, 마지막으로 일반 변수인데 특별한 제약이 없고 대소문자 만 구별하면 됩니다.

#!/bin/sh echo "Test Script #1 : $0" echo "Process ID : $$" echo "Argument Count : $#" echo "Argument List(*) : $*" echo "Argument List(@) : $@" echo "Argument #1 : $1" echo "Argument #2 : $2"

위 Script를 아래와 같이 실행하면

$./Test_Script_#1 1_hello 2_world Test Script #1 : ./Test_Script_#1 Process ID : 12342 Argument Count : 2 Argument List(*) : 1_hello 2_world Argument List(@) : 1_hello 2_world Argument #1 : 1_hello Argument #2 : 2_world

의 결과값이 나오겠죠.

간단하게 순서대로 명령어만 실행되는 Script라면 Script라고 하긴 좀 그렇고, 조건문들을 다루어 봐야 합니다. 조건문은 Programing을 하셨다면 아시다시피 if, for, while, case 크게 다르진 않습니다. 한가지 재미있는 건 조건문을 끝낼 때 if는 fi, case는 esac같이 거꾸로 쓰는게 있다는 거 for나 while의 경우는 do로 시작해 done이죠.

if 구문 : 조건에서 이게 없으면 시체나 다름 없죠. 삶은 case와 같이 여러 갈래가 있기도 하지만, Yes or No 만큼 중요한 건 없습니다.(거의 일상 생활이나 다름 없죠)

CHK_EXT3=`cat /etc/fstab | grep -c "ext3"` if [ $CHK_EXT -eq 0 ];then echo "There is no ext3 filesystem." else echo `cat /etc/fstab | grep "ext3"` fi

여기서 “`(Back quote)“가 사용되고 있는데, “`[command line]`” Command Line을 실행한 결과 값을 변환 해 주는 겁니다. 그리고, 여기선 /etc/fstab에 ext3 filesystem이 있으면 grep으로 count하여 없으면 There is no ext3 filesystem 있으면 해당 line을 보여주는 겁니다. 또, 수식에 따른 조건 연산자(산술 연산자) -eq를 사용하였는데 각 연산자를 설명하면 아래와 같습니다.

-lt : 보다 작다 (Lesser Than) -le : 이하 (Less or Eaqual) -eq : 같다 (Eaqual) -ge : 이상 (Greater or Eaqual) -gt : 보다 크다 (Greater Than) -ne : 같지 않다 (Not Eaqual)

위에서는 A가 아니면 B(if ~ else문)인데, 아래와 같이 elif(if~elif문)를 쓰는 경우 조건을 더욱 확장 가능합니다.

# Source function library if [ -f /etc/rc.d/init.d/functions ]; then . /etc/rc.d/init.d/functions elif [ -f /etc/init.d/functions ]; then . /etc/init.d/functions elif [ -f /etc/rc.d/functions ]; then . /etc/rc.d/functions fi

여기선 if와 함께 file의 속성확인에 사용되는 연산자가 사용 되었는데, File 조건 연산자는 아래와 같습니다.

-d FILE : Directory로서 존재(Directory) -e FILE : File이 존재(Exist)하나 Directory일 수도 있음 -f FILE : File로서 존재(File) -r FILE : Readable file임 -s FILE : File is not empty (Size가 있음) -w FILE : Writable file이고, 또한 Directory안을 확인 가능 -x FILE : 실행가능(eXecute) -O FILE : 소유권이 있음(Owner) -G FILE : 그룹에 포함되어 있음(Group)

추가로 File의 시각확인을 위한

FILE1 -nt FILE2 : FILE1이 FILE2보다 새거임 (Newer Than) FILE1 -ot FILE2 : FILE1이 FILE2보다 오래됨 (Older Than)

추가로

if [ $ -d FILE1 $ -a $ -x FILE2 $ ];then -a : &&과 같이 둘 다 성립할 때만 조건 만족 if [ $ -d FILE1 $ -o $ -x FILE2 $ ];then -o : ||과 같이 둘 중에 하나만 성립해도 조건 만족

마지막으로 문자열 비교 연산자를 확인 해 보면,

[ String ] : String이 NULL이 아니면 조건 만족 [ String1 = String2 ] : 두 문자열이 같으면 조건 만족 [ String1 != String2 ] : 두 문자열이 다르면 조건 만족 [ -n String1 ] : String1이 NULL이 아니면 조건 만족 [ -z String2 ] : String1이 NULL이면 조건 만족

아래 예제를 참고 해 보세요.

CONTINUE="$INIT_CONTINUE" if [ -z "$CONTINUE" ];then cat <<EOF
$DATE_TIME [INFO] Continue.... EOF CONTINUE=`Prompt "[INFO] Press ('Any Key' for Continue): "` fi

Linux #3 : File & File System Management

1 Reply

Cheking Support Filesystem

$ cat /proc/filesystems nodev sysfs nodev rootfs nodev bdev nodev proc nodev cpuset nodev binfmt_misc nodev debugfs nodev securityfs nodev sockfs nodev usbfs nodev pipefs nodev futexfs nodev tmpfs nodev inotifyfs nodev eventpollfs nodev devpts ext2 nodev ramfs nodev hugetlbfs iso9660 nodev mqueue ext3 nodev rpc_pipefs nodev nfs nodev nfs4

nodev는 block device에 Mount 되어 있지 않다는 것을 표시합니다.

또한, 아래 Command를 통해서 실제 Kernel Module로서 준비되어 있는 filesystem 확인이 가능합니다. NTFS의 경우, FUSE(Filesystem in Userspa)를 이용하기 때문에 아래 Command로도 표시되지 않습니다.

$ modprobe -l -t kernel/fs /lib/modules/2.6.18-92.1.22.el5/kernel/fs/autofs4/autofs4.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/cachefiles/cachefiles.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/cifs/cifs.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/configfs/configfs.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/cramfs/cramfs.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/dlm/dlm.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/ecryptfs/ecryptfs.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/exportfs/exportfs.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/ext3/ext3.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/fat/fat.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/freevxfs/freevxfs.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/fscache/fscache.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/gfs2/gfs2.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/hfs/hfs.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/hfsplus/hfsplus.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/jbd/jbd.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/jffs2/jffs2.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/gfs2/locking/dlm/lock_dlm.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/gfs2/locking/nolock/lock_nolock.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/lockd/lockd.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/msdos/msdos.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nfs/nfs.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nfs_common/nfs_acl.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nfsd/nfsd.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp1250.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp1251.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp1255.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp737.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp775.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp850.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp852.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp855.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp857.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp860.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp861.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp862.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp863.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp864.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp865.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp866.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp869.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp874.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp932.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp936.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp949.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_cp950.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_euc-jp.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_iso8859-1.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_iso8859-13.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_iso8859-14.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_iso8859-15.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_iso8859-2.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_iso8859-3.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_iso8859-4.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_iso8859-5.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_iso8859-6.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_iso8859-7.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_iso8859-9.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_koi8-r.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_koi8-ru.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_koi8-u.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/nls/nls_utf8.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/squashfs/squashfs.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/udf/udf.ko /lib/modules/2.6.18-92.1.22.el5/kernel/fs/vfat/vfat.ko

FileSystem Benchmark : IOzone (http://www.iozone.org/)

source나 binary로 직접 설치가능하고, 일부 OS는 rpm version로도 설치 할 수 있다. 설치 후 아래와 같은 명령어로 측정이 가능하다.

$ iozone -i 1 -i 2 -Rab bmt.xls

각 Option들에 대한 설명을 덧붙이면,

Option	Detail
-a	자동 Test Mode
-b	출력 File의 이름을 지정
-i 숫자	Test 내용을 지정
0	write/rewrite
1	read/re-read
2	random-read/write
3	Read-backwards
4	Re-write-record
5	stride-read
6	fwrite/re-fwrite
7	fread/Re-fread
8	random mix
9	pwrite/Re-pwrite
10	pread/Re-pread
11	pwritev/Re-pwritev
12	preadv/Repreadv
-R	Excel로 결과를 출력

Checking i-Node Information

i-Node는 file의 소유권 및 Size, Access 권한, 작성일시, Data 영역으로의 Pointer등의 각종 정보가 기록되는 영역이다. UNIX계열의 OS는 file의 실제 영역을 Data와 i-Node로 구분하고 있다.

Linux에서 일반적으로 사용하는 ext2, ext3등은 file system 작성 시 i-Node size가 최대치로 결정되고 있다. i-Node가 100%가 되는 경우는 그다지 많지 않지만, 경우에 따라 실제 사용량이 적더라도 i-Node가 부족하게 되어 문제가 발생하는 경우가 가끔 있다.

$ df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/cciss/c0d0p2 10487712 241540 10246172 3% / /dev/cciss/c0d0p6 41779200 48899 41730301 1% /home /dev/cciss/c0d0p1 26104 39 26065 1% /boot tmpfs 505813 1 505812 1% /dev/shm

여기서 Inodes는 할당 가능한 i-Node 수, IUsed는 이미 할당된 i-Node수, IFree는 아직 할당되지 않은 i-Node수이다.

특정 file이나 directory의 i-Node 정보를 확인 할 때에는 “stat” command가 유리하다.

$ stat vpd.properties File: `vpd.properties' Size: 1557 Blocks: 8 IO Block: 4096 regular file Device: 6802h/26626d Inode: 68927 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2009-10-13 16:22:20.000000000 -0700 Modify: 2009-10-13 16:23:14.000000000 -0700 Change: 2009-10-13 16:23:14.000000000 -0700

Disk 사용량이 높은 Directory의 확인

du와 sort를 조합하면 가능하다.

$ du -S | sort -n 8 ./archive 8 ./cache 8 ./exports 8 ./lib_ext 8 ./tmp 20 ./lib_ext/xml 24 ./upgrade 76 ./images 80 ./lib_ext/graidle 236 ./lib_int 264 ./lib_ext/pclzip 356 . 608 ./lib_ext/fonts

File System Check Timing의 표시 및 변경

ext3의 경우 Mount/Unmount를 일정 횟수 이상 행하면, 자동적으로 e2fsck에 의한 file system check가 이루어 진다. Mount 횟수는 Super Block(file system의 관리정보를 기록하는 장소)의 Mount count에 보존되어 있고, check를 행하는 Timing은 Maximum mount count에 보존되어 Mount count = Maximum mount count일 경우 check를 행한다.

Mount count나 Maximum mount count의 현재 상태를 확인 할 경우 “tune2fs” command를 사용한다.

$ tune2fs -l /dev/cciss/c0d0p6 tune2fs 1.39 (29-May-2006) Filesystem volume name: /home Last mounted on: <not available> Filesystem UUID: e2b6586f-7c2c-419c-8728-47f6cb400cfc Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 41779200 Block count: 41758951 Reserved block count: 2087947 Free blocks: 32709952 Free inodes: 41754947 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 1014 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 32768 Inode blocks per group: 1024 Filesystem created: Wed Aug 5 14:03:26 2009 Last mount time: Mon Sep 28 15:21:23 2009 Last write time: Mon Sep 28 15:21:23 2009 Mount count: 6 <= Mount 횟수 Maximum mount count: -1 <= Check를 실시하는 Mount 횟수 Last checked: Wed Aug 5 14:03:26 2009 Check interval: 0 (<none>) Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Journal inode: 8 First orphan inode: 9961478 Default directory hash: tea Directory Hash Seed: 943c992f-8347-46dd-b47f-a26f4c9882c4 Journal backup: inode blocks

dumpe2fs -h [Device Name]으로도 동일한 결과를 얻을 수 있다. Check Timing을 변경할 시, tune2fs에 -c 횟수 Option을 넣는다.

$ tune2fs -c 10 /dev/cciss/c0d0p6

/etc/fstab에 기입되어 있는 숫자의 의미

System 기동시에 Mount되는 Device는 /etc/fstab에 설정된다.

$ more /etc/fstab LABEL=/ / ext3 defaults 1 1 LABEL=/home /home ext3 defaults 1 2 LABEL=/boot /boot ext3 defaults 1 2 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 LABEL=SW-cciss/c0d0p3 swap swap defaults 0 0 LABEL=SW-cciss/c0d0p5 swap swap defaults 0 0

첫번째 열은 Mount할 Block Device나 Label 등이, 두번째 열은 Mount Location, 세번째 열은 File system의 종류, 네번째 열은 Mount 시의 Option이된다.

다섯번째, 여섯번째는 숫자가 기입되어 있는데, 전자의 숫자는 File system을 dump할 필요가 있는지의 유무이고(0:Zero이거나 기술이 없는 경우 dump 불필요), 후자의 숫자는 System 기동시 fsck check를 행할 지의 유무로 0:Zero의 경우 check를 하지 않는다. root file system의 경우는 check를 할 경우 1로 설정, 그 외 file system의 경우는 2일경우 check를 행한다.

Tech #4 : VMware VSphere 4.1의 Network 구성

1 Reply

VMware VSphere 4.1에서는 Network의 자원 관리를 보다 적절하게 실현하기 위한 기능으로 “Network I/O Control”가 도입되었다고 한다. 또, NIC Teaming의 Load Balance Algorizm 으로 “Load Based Teamin”이라고 하는 신 Algorizm이 이용가능하게 되었다고 한다.

일단, 이전의 ESX(Classic)은 가상화을 행하는 “VMKernel”의 영역과 관리기능을 제공하는 “Service Console” 영역이었으나, Server의 처리 능력 향상에 비례하여, 가상 Machine의 집약 능력도 향상하는데 이는 보다 광대역의 Network 환경이 요구된 다는 걸 의미한다. 그걸 말해 주듯 이제 10Gbits Internet도 보급되기 시작했고, 10Gbits EtherNet의 Controller나 Switch를 포함하는 Blade Server도 등장하여 본격적인 궤도에 올랐다고 볼 수 있다.

10Gbis Ethernet의 사용을 전제로 System을 구축 할 경우 여러가지 Data 통신을 통합하는 시도도 많아 질 수 있고, 가상 Machine이 이용하는 Network를 포함한 관리 Network, iSCSI나 NFS 등의 Storge Network, vMotion이나 VMware FT가 이용하는 Data Transfer 등도 통합 해야 할 것이다. 통합을 위해서는 다른 Resource에 의해 대부분의 Performance가 점유되어 가상 Machine 전체가 Slow down 되는 경우를 피해야 하고, 그에 맞는 설계를 할 필요가 있다.

여기서, Network 자원 관리가 중요 해 지는데, Previous Version에서도 “Traffic Shaving”란 기능을 제공 했었고, 이건 가상 Port 또는 Port Group가 이용가능한 대역의 상한치를 지정하는 기능으로, 표준 가상 Switch에서는 Outbound Traffic, 분산가상 Switch에서는 Inbound, Outbound Traffic 가각의 Traffic에 대한 설정이 가능, 단 Traffic Shaving은 간단하게 이용가능한 상한치를 제어하는 기능 뿐으로 Unused 대역에 대한 다른 용도로의 전환은 불가능 하다. 아래 그림 처럼 Unused 영역이 있어도 상한치 이상을 사용 할 수 없다.

보다 이상적인 Network 자원 관리를 실현 하기 위하여 자원의 간섭이 있을 시, 미리 설정을 해 둔 비율로 Balance를 맞춰, 자원이 비어 있는 상황에서는 그 자원을 필요한 용도로 전환 하는 것이 가능 해야 한다. 아래의 그림과 같다.

CPU자원과 Memory 자원에 관해서도 위와 같은 자원 관리 구성이 Previous Version에 대해서도 제공 되었다. vSphere 4.1에서는 Network 자원에 관한 동일한 기능이 제공 되어 지는데, Network I/O Control이 그것이다.

Network I/O Control

vSphere 4.1의 new function “Network I/O Control”은 앞에서 설명 했던 것 처럼 유연한 Network 자원 관리를 실현하는 메카니즘이고, 현재 Enterprise Plus Edition에서 제공하고 있다. 또, 이 기능은 분산 가상 Switch 상에서 제공되는 기능이고, 표준 가상 Switch상에서는 이용 할 수 없다.

Network I/O Control에서 Network Traffic을 아래와 같이 6 class로 구분할 수 있다.

FT Traffic
iSCSI Traffic
vMotion Traffic
Management Traffic
NFS Traffic
Virtual Machine Traffic

User는 각각의 Class에 대해 “Limit” 혹은 “Share”라는 값을 설정 할 수 있고, “Limit”는 해당 Class가 사용 가능한 최대치이고, Mbps로 설정한다. “Share”는 “자원 간섭이 있을 시 Balance 값”으로 1 ~ 100의 정수값을 설정한다.

Network I/O control의 동작

Network I/O Control은 ESX로부터의 Outbound Traffic에 대해서만 유효하고, Inbound Traffic은 제어 대상이 아니다. 또, “Share 값의 계산은 최종적으로 각 ESX Host 단위” 도 주의 할 점이다. 분산 가상 Switch를 구성할 경우, 보통 각 ESX에 구성하는 Uplink의 수나 물리 Adapter의 대역등은 공통이지만, 그렇지 않은 경우는 주의가 필요하다. 1Gbps의 NIC으로만 구성되는 Host와 10Gbps의 NIC을 보유하는 Host가 같이 있는 경우는 Share 값의 계산 결과로 확보되는 대역이 Host에 따라 다른 경우가 있다.

“Limit”나 “Share”의 설정은 동시에 유효화가 가능하고, Share값 계산의 결과 획득 가능한 대역이 Limit에서 제한하고 있는 값보다 큰 경우 Limit의 값이 적용된다.

Load Based Teaming

LBT는 복수의 물리 NIC을 통합 가능한 대역의 확보와 이중화를 제공하는 “NIC Teamng”이 적용된다. 복수의 물리 NIC으로 Link을 구성함과 더불어 각 Traffic이 어떻게 물리 NIC을 결정하는 가의 알고리즘이 필요하게 된다. 해당 알고리즘은 아래와 같다.

Port ID Based
Default로 이용되는 알고리즘으로 Port ID란 가상 Switch내의 Port ID. 가상 NIC이 접속하고 있는 가상 Port별로 이용하는 물리 NIC이 결정 된다. 즉, 하나의 가상 NIC을 하나의 물리 NIC을 대응하는 방식이지만, 복수의 가상 Machine인 환경에선 부하 분산도 기대 할 수 있다.
Source MAC
Traffic의 Source측의 MAC Address, 말하자면 가상 NIC의 MAC Address 정보를 기초로 한 Hash값을 두고 물리 NIC을 결정하는 알고리즘. 하나의 가상 NIC이 최종적으로 하나의 물리 NIC을 댕응하는 점에서는 Port ID Based와 같다. 많은 경우 Port ID Based의 부하분산은 유효하지만, 운영하는 형태에 따라서는 물리 NIC의 사용률이 균일하지 않은 경우가 있다. 예를 들면 물리 NIC x 2로 Teaming된 가상 Switch에 20대의 가상 Machine이 접속되어 있는 상황을 가정하면 System 운영 특성 상 홀수번째의 가상 Machine이 Active로 동작하고, 짝수번째의 가상 Machine은 대기하고 있다면, 이 경우 부하분산 알고리즘으로 Port ID Based를 이용하면 결과적으로 한쪽의 물리 NIC에 Traffic이 집중되어 버린다. 이런 경우 Source MAC을 이용하여 양측의 물리NC이 균일하게 사용되도록 할 수 있다.
IP Hash
IP Hash는 각 Traffic의 Source IP Address, Destination IP Address들을 바탕으로 Hash값을 계산하고, 이용하는 물리 NIC을 결정한다. 복수의 Destniation이 있는 경우, 하나의 가상 NIC이 복수의 물리 NIC을 사용 할 때 유리하다. IP Hash를 사용할 때는 물리 Switch측에 IEEE 802.3ad Link Aggregation을 유효화 시킬 필요가 있다.
Load Based
물리 NIC의 대역 사용 상황에 따라, 동적인 가상 Port와 물리 NIC간의 관계를 변경 한다. 초기 배치는 Port ID Based와 같은 방식으로 구성되지만, 운영 중 부하의 쏠림이 발생할 것 같으면 자동적으로 이 Mapping 을 변경 한다. vSphere 4.1로 부터 제공되는 기능으로 분산가상 Swtch만 지원 한다.

Load Based Teaming의 동작

LBT를 선택하면, 물리 NIC의 부하상황에 맞춰 가상 Port와 물리 NIC의 Mapping을 자동적으로 변경하게 된다. 이 때의 판단 기준은 Default로는 “물리 NIC의 대역 사용률이 75%를 넘는 경우가 30초이상 지속적으로 발생 할 때” . Network Traffic은 순간적인 것, 지속적인 것이 있는데, 너무 과민하게 설정을 할 경우 오히려 역효과가 날 수 있다.

Network I/O Control, Load Based Teamin은 Enterprise Plus License가 필요하다. 쩝.. 슬픈 일이군..

Trend #1 : Early Warning Signs of IT Project Failure : The Dominant Dozen

Leave a reply

“Early Warning Signs of IT Project Failure : The dominant Dozen” 라는 논문이 있는데, 제목 그대로 실패하는
IT Project에 대해서는 12가지 징후가 있다고 한다. 따라서, 이런 문제가 있다면 미리 바로 잡을 필요가 있을 것이고
아래와 같다.

인재면에서의 Risk

Management 상층부로부터의 Support가 불충분
Project Manager의 역량이 부족
이해관계자에 따른 관여나 참여가 불충분
Project Team의 열의가 부족
Team Member의 지식이나 Skill이 부족
담당업무를 대상으로 하는 전문가의 Schedule 과다

Process면에서의 Risk

Project의 투자 대비 효과에 대한 검토가 결여 됨
요건이나 성공 기준에 관한 docuement가 존재하지 않음
변경 관리를 위한 Process가 결여 됨
Schedule 초안이나 관리 부족
이해관계자 간의 Communication이 원만하게 이루어 지지 않음
Resource가 보다 우선 순위가 높은 Project에 대해서만 할당 되어 있음

무언가 더 있을 거라고 생각 했는데, 위 12가지는 당연하게 지켜야 할 것들 같아 보인다. 사실 모든 Project를 함에 있어
지켜야 할 기준이 있고, 그걸 잘 지켜나간 다면 실패할 가능성도 적어지리라…

Tech #3 : What is the Virtualization Technology?

Leave a reply

(2007년 3월 1일)

“Server의 가상화”는 기업에 있어 이미 필수 기술이 되었다고 해도 과언이 아니다. 가상화에 있어 처리능력의 증강을 원한다면, 새로운 H/W를 구입할 필요는 없다. 그것은 말하자면, H/W구입비라고 하는 지출을 줄이는 것이기도 하고, Data Center의 Space와 전기 및 냉각에 드는 Cost를 절약하는 것이기도 하다. 물리적인 Server가 아닌 가상 Server를 선택하는 것은 기업에게 재무의 건전성을 부여하고, IT지출을 삭감하는 효과가 있다라고 하는 것이다. 여기에서 그런 Merit를 가진 가상화 Architecture 면으로부터 다시금 정리 해 보았다.

Nill Macarista
InforWorld Online 미국판

가상화의 기술, 가상화라는 Concept자체는 결코 새로운 것이 아니다. 실제, 이미 1970년대에 Main Frame Computer는 복수의 OS Instance를 동시에 실행하고 있었따. 그것이 가상화의 시작이 된다. 그 후, S/W와 H/W가 진화하여, 가상화는 더욱 가깝게 체감할 수 있는 기술이 되었다. 현재, 업계표준이 되어 있을 정도로 일반적인 Server에서도 가상화를 행하는 것이 가능하다.

지금, 시장에서는 proprietary로부터 Open Source까지, Data Center Manager가 선택하기 곤란할 정도로 많은 종류의 가상화 Solution이 넘쳐나고 있다. 여기서는 가상화에 대한 Approach 방법(Achitecture)에 있어 “완전 가상화” “모의 가상화” “OS Level의 가상화”의 3가지로 분류하고, 각각의 기술적인 특징을 소개한다.

※ Proprietary란,“전용의” “독자의” “독점적인” “소유권, 점유권이 있는” “비공개의”의 이미로, Computer관련용어로서는 Open의 Opposite word이다.
표준화가 진행된 PC (Client / Server System, Web System)에 따라 System을 “Open System”이라고 부를 때, Main Frame System과 같은 특정 Maker등에 따른 특정의 독자사양으로 구성된 Computer System을 “Proprietary System”이라고 한다.
또, Linux에 대표되는 Source Code가 공개된 S/W를 “Open Source Software” “Free Software”라고 부르는 것에 반해, Windows나 MAC OS와 같은 Software Maker가 Source Code(지적소유권)을 독점 소위 점유하고 있는 Soft는 “Proprietary Soft”라고 불린다.

완전 가상화 (Full Virtualization)
가상화 Solution 중에 가장 많이 보급된 것이 “Hipervisor”라고 불리우는 Architecture를 사용한 “완전 가상화”이다. 이것은 가상 Server와 H/W간에 추상적인 Layer(가상화 Layer를 실장한 전용 Kernel)을 배치하는 Architecture이다.
이 Approach를 채용하고 있는 상용제품으로는 “WMware”와 Micro Soft의 “Virtual PC”가 있고, Linux용 Open Source 제품으로는 “KVM (Kernel-based Virtual Machine)”가 있다.
Hipervivor는 CPU명령에 관여하여, H/W Controller와 주변기기로의 Access를 중개한다. 사실상, 어떤 OS라도 수정없이 가상 Server상에 Install할 수 있고, 그 Guest OS는 가상환경에 있다는 인식없이 가동한다. 더불어 이 Architecture의 결점은 Hipervivor에 의해 Processor에 큰 Overhead가 걸리는 것이다.
완전 가상화 환경에 있어 Hipervivor는 H/W상에서 직접 가동하고, Host OS(Kernel)로서 기능(다른 말로 하자면, Windows나 Linux 같은 일반 Host OS를 필요로하지 않음)한다. 그 Hipervivor가 관리하는 가상 Server상에서 Guest OS가 움직이는 셈이다.

모의 가상화 (Para Vritualization)
완전 가상화에서는 여러가지 가상 Server를 관리하고, 나아가 각각을 독립 가동시키고 있는 Hipervivor의 요구가 모든 Processor에 집약(그 때, Guest OS는 일절 가상화에는 관여하지 않음)된다.
이 부담을 경감시키기위한 수단의 한가지가 Guest OS에 관여 가상화 환경을 인식시키도록 함과 더불어 Hipervivor와 연계시키는 것이다. 이것이 “모의 가상화”라고 불리는 Approach이다.
이 모의 가상화 방식을 채용하고 있는 대표적인 제품이 Open Source “Xen”이다. Xen에서는 Kernel부분에 변경을 가함으로서 처음으로 Xen Hipervivor의 가상 Server상에서 Guest OS가 가동가능하게 된다. 이로 인해 BSD, Linux, Solaris와 같은 Open Source OS는 Support하지만, 수정을 할 수 없는 Windows등의 Proprietary System의 가상화에는 적합하지 않다.
모의 가상화의 우위성은 “Performance”에 있다. Hipervivor와 연계하는 모의 가상화 Server는 가상화되고 있지 않은 Server와 거의 동등한 성능을 발휘한다. Micro Soft와 VMware가 각각 자사제품을 보완하기 위해 모의 가상화기술에 힘을 쏟고 있는 상황을 보면, 그것이 충분히 매력적인 기술이라는 것을 알려주는 것이다.

OS Level의 가상화 (OS Level Virtualization)
OS Level의 가상화로는 문자그 의미대로 OS(Host OS)의 기능에 의해 가상화를 실현하는 Architecture가 있다. Hipervivor Layer는 존재하지 않고, Host OS가 스스로 H/W Resource를 분할 하거나, 각 Server를 독립 운영시키거나 한다. 모든 가상 Server가 동일 OS상에서 가동하는 점이, 다른 가상화 기술과의 큰 차이(그러나, 각 Instance는 고유의 Application과 User Account를 보유함)이다.
이 Architecture의 결점은 “유연성”이 결여되어 있는 것이지만, 그 반면 “Native Speed 향상이 가능하다”라는 이점도 있다. 또, 모든 가상 Server에 단일 표준의 OS가 적용되어지기 때문에, 다른 환경에 비해서 관리가 용이하다는 점도 Merit로 여겨진다.

CPU의 가상화 대응
Main Frame과는 다르게 PC의 H/W는 원래 가상화를 고려하여 설계되었다고 말 할 수 없다. 그로인해 최근까지 부하는 모든 S/W에 걸리지만, AMD와 Intel이 최신세대 Processor에서 처음으로 CPU Level에의 가상화를 Support하기 시작한 걸로 인해, 상황은 크게 바뀌려고 하고 있다.
더불어, AMD와 Intel의 Technology는 동일한 Merit를 가지고 있지만, 불행하게도 Code의 호환성은 없다.
그렇다하더라고, H/W Level의 가상화 Support로 인해, 가상 Server로부터 I/O Channel이나 H/W Resource로의 Access관리는 H/W측에서 행해지게 되고, Hipervivor가 부담해 오던 관리부하는 상당히 경감되었다. 또, OS(Windows를 포함)에 관여하지 않고도, 모의 가상화 환경으로 가동시킬 수 있게 되었다.
더욱이, CPU Level의 가상화 환경을 실현하기 위해서는 가상화 S/W를 다시 만들어야 하는 절차가 필요하다고 한다. 그러면서도, 이 기술이 가져다 주는 Merit는 그 부분을 고려하고도 남을 정도로 크기 때문에, 결국 이런 저런 종류의 가상화 S/W가 이 기술을 Support하게 될 것이다.

각각의 기술의 비교
지금까지 소개했던 가상화 방법 중 어느것을 채용할지는 각각의 기업(Data Center)이 놓여있는 상황에 따라 다를 것이다. 예로, 단일 OS Platform을 기반으로 하는 Server군의 경우에는 OS Level의 가상화로 통합하는 방법이 적합하다고 말 할 수 있다.
한편, 모의 가상화 방법을 채용하면 – 특히 가상화에 대응하는 Processor와의 연계가 완성되어 있는 경우에는 – 높은 성능을 유지하면서, 다른 종류의 Guest OS System 환경이 구축가능한 Merit를 흡수하는 것이 가능하다.
또, 완전 가상화는 3가지의 가상화 방법 중 성능면에서는 가장 떨어지지만, Guest OS간의 완전한 독립성을 유지할 수 있는 Merit를 가진다. 많은(종류의) Guest OS를 Support하고 싶을 때, 소위 S/W 품질보증이나 Test를 행하고 싶을 때에는 이 방법이 적합하다고 할 수 있다.
완전 가상화 Solution은 그 외에도 여러가지 특징이 있다. 예로, 가상 Server의 특정시점에서의 상태 정보를 취득하고, 보존해 두는 “Snapshot”기능을 이용하면, 여지껏 간단하게 장애복구 대책을 실시 할 수 있다. 또, 최근에 이 기능을 활요하여, 자사제품의 평가판을 Pre-Package화한 가상 Server Image로서 Download 제공하고 있는 S/W 기업도 증가하고 있다.
그렇다하더라도, 가상화 기술/Architecture를 막론하고, 가상 Server에는 물리 Server라는 지금까지와 같은, 계속적인 Support와 Maintenance를 필요로 한다. 이미, 기존의 IT환경으로부터 효율적인 Cost 효과에 우수한 가상화 환경으로의 이행을 간단하게 행하기 위한 Tool을 시작, 여러가지 가상 Server 용 관리제품이 시장에 투입되고 있기 때문에, 그것들을 활용하면서 보다 좋은 가상화 환경의 실현 해 나갈 수 있다.

※ 위 글은 아래의 링크의 기사를 번역한 글입니다. 다소 오역이 있을 수 있습니다.

http://www.computerworld.jp/topics/vt/59310-1.html

Tech #2 : What is the x64?

Leave a reply

그냥 지나치고 넘어 갈 수도 있는 CPU 관련 내용을 재 정리 해 봅니다.

우선, x64란?

32bit Architecture(IA-32)를 64bit로 확장시킨 Architecture, 또는 그것과 호환성이 있는 기술의 총칭.

Intel은 자사 Architecture를 “EM64T(Intel Extended Memory 64 Technology”라고 하고, AMD(Advanced Micro Devices, Inc.)는 “AMD64 ISA”라고 하고 있습니다. x64 대응 Processor를 개발하고 있는 건 위의 Intel과 AMD입니다.

x64의 설계는 기존 32bit Architecture의 진화의 연장선상에 있고, x64는 차세대 Computing으로의 벽을 부수고, 과거의 자산을 활용하는 방법을 제공하고 있습니다. 즉, x64는 새로운 64bit Solution을 도입가능하도록 함과 동시에 기존의 32bit Solution에 대한 지금까지의 투자를 보완하기 위한 개념에서 탄생된 새로운 형태의 Technology입니다.

64bit Technology가 필요한 이유

64bit 환경을 필요로 하고 있는 것은 고성능을 필요로하는 대용량 물리 Memory와 가상 Memory를 사용하는 Application. 32bit로 관리 가능한 Addressing Area는 근본적으로 4GB까지 제한되어 버리고, 또, 많은 32bit OS가 Address 가능한 영역도 2GB까지 제한하여 이이상의 Memory영역을 사용하고 싶은 Computing 기능의 강화를 필요로하는 User는 64bit 환경으로 전환해야만 할 필요성이 있죠. 그로 인해 기존 자산인 32bit 환경을 어떻게 해야 할지 하는 문제가 발생합니다.

AMD64와 EM64T의 64bit Technology에 의해 일부 또는 모든 Application의 Software, Hardware를 32bit에서 64bit로 서서히 전환 가능하게 되었습니다.

AMD와 AMD64

AMD는 오래전부터 Intel 호환 Processor 개발을 했던 America의 Maker. 회사의 기술 Level은 상당히 높았고, Original의 x86계 Processor 개발 Maker였던 Intel을 놀라게 할 정도의 존재 가치가 되어 가고 있습니다. 그 대표적인 기술이 AMD64 Platform. AMD64는 IA-32등에서 사용되었던 x86 명령 Set을 확장, 64bit Platform로, Intel의 EMT64에 앞서, 기존 x86 Solution과의 완전호환성을 가지면서, 64bit 성능을 제공하도록 설계되어 있습니다.

2003년 4월, Server 혹은 Workstation 용의 AMD Opteron Processor가 등장. 더불어 AMD는 처음으로 Windows 대응 Desktop/Mobile Processor인 AMD Athlon 64 Processor를 2003년 9월에 발표했습니다. 이 때 Code Name “Hammer”라고 했던 AMD64는 2005년엔 “AMD64 Platform”으로, “x86-64″라는 64bit 확장 기능에 대해서 “AMD64 ISA” (AMD 64 Inform Set Architecture)라고 하게 되었습니다.

Intel과 EM64T

Intel은 업계 최고의 America 최대의 Processor Maker. Intel은 차세대 Processor로서, Hi-end 64bit 전용 Processor인 Itanium/Itanium2를 개발하고 있었지만, Itanium2는 기존 32bit Architecture와는 Hardware Level의 호환성이 없었습니다.

그 때 Rival 기업인 AMD가 “기존 32bit Architecture에 64bit 기능을 추가한다”라는 새로운 전략을 내세웠기 때문에, 그것에 대항하기 위해 EM64T라는 AMD의 AMD64와 동등한 호환성의 높은 시술을 발표했습니다. 물론, Intel도 기존의 32bit Architecture에 64bit 확장기능을 추가하는 것을 전부터 연구하고 있었습니다. 그러나, 준비가 되기도 전에 AMD가 선수를 치는 형식이 되고, 결과적으로 Intel의 EM64T는 AMD보다 한발 늦게 시장에 투입되게 되었습니다.

2004년 2월, Intel은 Dual Processor Server/Workstation 용으로 Intel Xeon Processor 개발 Code Name “Nocona” 또는 “Potomac” (Xeon MP Processor 개발 Code Name), 그리고, Single Processor “Prescott” 위 3개의 IA-32 Processor에 Intel EM64T를 탑재한다고 발표했습니다.

EM64T의 기술은 Pentium4 또는 Xeon Processor (6xx Sequence의 Pentium4 Processor)부터 탑재되기 시작했습니다.

x64 기술의 Merit

기존 x86환경, 또는 64bit 전용의 환경보다 x86환경에서 잘 동작하는 Application 혹은 Case Study는 많이 있습니다. 64bit Native Code로 해도 이점이 없는 Application에 대해서는 변환작업이 필요없고, 그 대로 x64 환경에서도 성능을 Full로 발휘 가능합니다. 특히, Modeling Simulation, 통계, 재무분석, 화상, Video, 신호처리, 물리학, 의학연구, Telecom, 암호화, 압축등 수학적정산과 부동소수점연산기능을 필요로하는 Application에 유리합니다. 게다가,의사결정지원, 검색, 색인, Document, Contents관리, 음성인식등, 대용량 및 고성능의 Database기능을 필요로하는 Application을 비롯, Computer 지원 설계, 제조, Engineering(CAD, CAM, CAE), Digital 음악제작 혹은 Video 편집, Digital Contents 작성, Realtime Media Streaming Solution등의 Application에도 유리하게 적용됩니다.

Tech #1 : What is the 64bit?

Leave a reply

Processor PC의 세계는 4bit 시대로부터 시작하여, Z80에 대표되는 8bit, 8086과 MPU68000에 대표되는 16bit, i386과 Pentium에 대표되는 32bit로 발전되어 왔다. 그리고, 64bit 시대에 접어들어 “64bit화”가 진행되고 있다.

64bit란?

간단하게 말하자면, Bit(1또는 0인 Computer의 최소단위)의 수가 64개가 나열되어 있는 것. 이 64개의 1과 0을 조합하여 표현 가능한 수의 폭은 2⁶⁴이 됩니다. 각 bit수와 값을 Table 1로 정리하면.

Table 1 Bit수와 값의 범위
Bit수	값	값의 범위(Addressing의 범위)	Size
4bit	2⁴	0 ～ 16［0xF］	16byte
8bit	2⁸	-128 ～ +127 0 ～ 255［0xFF］	256byte
16bit	2¹⁶	-32768 ～ +32767 0 ～ 65535［0xFFFF］	64Kbyte
32bit	2³²	-2147483648 ～ 2147483647 0 ～ 4294967295［0xFFFFFFFF］	4Gbyte
64bit	2⁶⁴	-9223372036854775808 ～ 9223372036854775807 0 ～ 18446744073709551615［0xFFFFFFFFFFFFFFFF］	16Ebyte

이 값의 범위를 비교해 보면, 64bit라는 수가 엄청난 크기의 값이라는 걸 금방 알 수 있을 겁니다. 64bit에서 표현가능한 Address 범위는 16Ebyte나 됩니다. 참고로 Ebyte를 참고하기 위해 아래 표를 확인.

Table 2 값의 단위와 Binary 값
단위	값	Binary 값
Kilo(K)	1,000	1,024
Mega(M)	1,000,000	1,048,576
Giga(G)	1,000,000,000	1,073,741,824
Tera(T)	1,000,000,000,000	1,099,511,627,776
Peta(P)	1,000,000,000,000,000	1,125,899,906,842,624
Exa(E)	1,000,000,000,000,000,000	1,152,921,504,606,846,976

물리 Address와 가상 Address의 범위

위에서 64bi의 Address범위는 16EByte라고 설명했지만, 현재의 64bit 대응 Processor으로는 모든 Address범위를 다루지 못 합니다.

Itanium2 Processor로 대표되는 Intel IA-64 Architecture에서는 50bit가 물리 Address 범위입니다. 또, AMD Opteron등의 AMD64 Architecture에서는 40bit까지의 물리 Address와 48bit까지의 가상 Address가 Support되고 있습니다. 이 40bit라는 값은 1TByte까지의 물리 Address범위를 cover하고 있는 것이 됩니다.

또, 이 범위에 관해서는 Processor 혹은 OS 종류에 따라 달라지기 때문에 주의 할 필요가 있습니다. 실제의 64bit 대응 Processor에서 다룰 수 있는 물리 Address 범위는 Table 3에 있습니다.

Table 3 주요 64bit 대응 Processor의 물리 Address 범위
Processor	Architecture	물리Address	가상Address
Intel Itanium2	IA-64	50bit	64bit
Intel Itanium	IA-64	44bit	54bit
AMD Opteron	AMD64	40bit	48bit
AMD Athlon 64	AMD64	40bit	48bit

왜 64bit를 필요로하는가?

Computer 세대가 발전에 나가는 것에 맞춰, bit수도 증가해 왔습니다. 그럼, 왜 이와같이 bit수를 증가시켜야만 했을까요. 그것은 기술의 발달과 함께 처리해야하는 Data량이 증가하여, Computer에 실장되어 있는 Memory의 상한선에 다다르게 되었기 때문입니다.

이미 Memory는 32bit의 한계범위에 있는 4GByte(2³²Byte)에 도달 해 버렸습니다. 일반적인 32bit Computer에서 4GByte 이상의 Memory를 직접(물리적으로) Access 접근할 수 없습니다. 그러나, Hi-End의 x86 Multiple Processor System에서는 이미 이 4GByte의 폭을 넘어서 있습니다.

Intel Server용의 Xeon Processor (Nocona 혹은 일부의 Prescott Core)에서는 “Intel Extended Server Memory Architecture”라고 하는 확장 기능으로 36bit의 물리 Address 공간을 Support하고 있고, 최대 64GByte까지의 Memory 영역을 다룰 수 있습니다. 그러나, 이것은 물리 Address의 한계로의 근본적인 해결책은 아닙니다.

이런 문제를 해결하기 위해서, 64bit로 가기위한 준비의 필요성이 부각되고 있습니다.

64bit는 32bit의 배

64bit는 32bit의 배의 bit폭이므로, 처리속도 및 다룰 수 있는 Data양도 배가 된다고 기대하기 쉽지만, 그렇지 않습니다. 이런 잘못된 인식을 갖지 않도록 64bit에 대해서 정확하게 이해하고 있지않으면 안되지요.

Linux #2 : About Memory on Linux

Leave a reply

System에 장애가 발생 했을 시, 문제를 잘 파악하는게 중요한 Point가 되고,
장애의 원인을 정확하게 파악하고 있다면, 무엇을, 누가, 어떻게 해야 하는지가 명확 해 집니다.
그렇지 못하다면, 인적, 금전적 Resource가 낭비되는 건 당연하구요.

System 상에서 장애 원인을 파악하기 어려운 부분 중의 하나가 Memory인데, 이는 OS 관련 문제 중
20% ~ 30%를 차지하고 있을 정도죠. Memory Trouble은 어려 복잡한 문제가 혼합되어 일어나는데
그 문제는 Application, Middle-Ware, OS, Hardware와 관련되어 더욱더 해결하기 어려워지죠.

일단 Memory를 확인 하기 위한 Command부터 숙지 할 필요가 있을 듯 하네요.
대표적으로 free, vmstat, sar, top, ps가 되죠.

우선,

free : 간단하게 메모리를 파악할 수 있으나, 보기 애매한 부분이 있죠.
vmstat : Memory 상황 및 CPU 사용률도 같이 파악 할 수 있으나, Option이 다양하지 않아 특정
Period에 고부하가 발생 했을 시에는 적합하지 않을 수 있어요.
sar : 위 나열된 Command 중에 가장 취득정보가 많으나,  약간 부적절한 부분도 있어 Memory 감시
관점에서는 vmstat보다 좀 떨어집니다.
top : real time으로 볼수 있는 tool인데, 여러가지 기능이 있고 Log 기록도 가능하죠
( - b batch mode 시)
ps : top과 같이 real time으로 볼 수 있는 tool이고, 여러 Option이 있는데 습관에 따라 쓰는 것
만 쓰게 된다는 예를 들면 "ps ax", "ps aux", "ps -elf" 등이죠.

그럼, 실제 사용 시를 확인 해 볼까요?

# free total used free shared buffers cached Mem: 4046504 3453500 593004 0 111468 1755760 -/+ buffers/cache: 1586272 2460232 Swap: 4192912 1178400 3014512

각 부분의 의미를 간단하게 설명 하자면

[Mem] total : Total Physical Memory size
[Mem] used : Total Physical Memory size - Free memory size
[Mem] free : 현재 사용되고 있지 않은 여유 Memory
[Mem] shared : 항상 0이고, 현재 사용되고 있지 않음.
[Mem] buffers : File등의 Meta data를 Cache하고 있는 Physical Memory size
[Mem] cached : File의 Real Data를 Cache하고 있는 Physical Memory size
[-/+ buffers/cache] used- : buffers, cached를 포함하고 있지 않은 used size
[-/+ buffers/cache] free+ : buffers, cached를 포함한 free size
[Swap] total : Total Swap size
[Swap] used : Total Swap size - Free size
[Swap] free : 사용하고 있지 않은 Swap size

여기서 [Mem] Free는 “남아있는 Memory Size”가 아닌, 어떠한 용도로도 사용되고 있지 않은
Physical Memory Size라고 생각하면 되고, 이는 [Mem] Free가 적다 -> 남아 있는 Memory size가
적다 -> 이용가능한 Memory size가 부족하다와 같은 발생을 막기 위함입니다. 따라서, 단순하게
Physical Memory를 추가해도 언젠가는 [Mem] Free가 이전과 같아 지지요.

결론적으로 System 전체의 Memory 사용량의 감시는 [Mem] Free을 판단 기준으로 하는 것이 아니라, 사용가능한 Physical Memory Size로 계산 할 필요가 있죠.

System의 이용가능한 Memory size의 계산은 Linux의 Page Cache에 대해서 이해 할 필요가 있는데,
Linux는 HDD등의 Storage에 저장되어 있는 Data에 대해서 Read / Write 시에 확보 했던 Memory를
Page Cache라는 형태로 보존 합니다.

CPU는 Storage의 Data를 직접 Read 할 수 없어서 Storage Data는 우선 Memory에 Load를 합니다.
이렇게 Read한 Data를 Page Cache로서 재이용합니다. 일단 Load 해 두면 Page Cache는 Read/Write를 Storage에서 Read 해 올 필요가 없으므로 고속처리가 가능하죠.

Page Cache는 새로 Storage Data를 Read/Write로 인해 Memory를 추가 할 필요가 없는 한, Memory를 release 하지 않으므로, 일반적으로 System이 가동하고 있는 것 만으로도 [Mem] Free는 Page Cache로서 계속 활용되고 어느 정도까지 계속 줄어들게 되죠. 서버마다 다르긴 한데, 어떤 건 150MB까지 또 어떤건 202MB 제 경험상 동일한 Application이 계속 돌고 추가 되지 않는 한 항상 같은 Free Memory size를 유지하게 됩니다. 따라서, [Mem] Free가 50MB가 계속 유지된다고 해서 반드시 걱정 할 필요가 없는 거지요.

이 Page Cache는 사용중이 아닌 Storage와 Data Sync 되어 있으면 바로 Release 할 수 있고, Page Cache에 대한 Write가 있을 경우엔 일시적으로 Unsynchronized 상태가 되지만, Storage와의 Sync는 정기적으로 이루어지고 있어 시간이 지나면 Release 가능한 상태가 됩니다. 즉, Page Cache는 “System이 다른 용도로 재이용 가능한” Memory를 포함하고 있죠.

이용 가능한 Physical Memory Size를 free command를 통해 계산 하는 방법

free command에도 어느정도는 Page Cache를 의식하여 개량되어 있고, 그것이 used – 와 free +입니다.

Buffers와 Cached는 Page Cache이고, 정확하게는 Buffers는 Cached에 SwapCached를 추가한 것이 Page Cache의 Total이지만, free command에서는 SwapCached가 표현되지 않죠. 그림을 보면, Buffers와 Cached를 합친 것을 used에서 뺀(used-), free를 더한 (free+)로 보다 현실적인 Physical Memory size와 이용가능한 Physical Memory size를 출력하고 있죠. 따라서, 이 두 수치를 참고하면 됩니다.

그렇다고 해서, System이 이용가능한 Memory size를 파악하기엔 부족하죠. 앞에서, Page Cache를 다른 용도로 재이용하기에는 “Storage와 Sync하고 있음”이라는 조건이 있었죠. Buffers와 cached에는 당연히 “Storage와 Unsynchronized” Page Cache가 포함되어 있죠. 그래서, free+는 실제 이용가능한 Memory size보다 좀 더 부풀려져 있게 되고, 아래와 같이 표현 가능하죠.

free < 실제 사용가능한 Memory size < free+

Physical Memory Status 확인 방법

그럼, Storage와의 Sync 정보까지 포함한 Memory 사용상태 감시를 위해서는 Active와 Inactive를 감시하면 됩니다.

Active와 Inactive는 vmstat -a 나 cat /proc/meminfo를 통해 취득 가능하죠.

# vmstat -a procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b   swpd   free inact active   si   so    bi    bo   in   cs us sy id wa st 0 0 1178400 534328 805388 2502796    0    0   161   159    0    0 7 2 89 1 0

$ cat /proc/meminfo
MemTotal:      4046504 kB
MemFree:        424364 kB
Buffers:        117508 kB
Cached:        1845500 kB
SwapCached:     726764 kB
Active:        2610468 kB
Inactive:       803068 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:      4046504 kB
LowFree:        424364 kB
SwapTotal:     4192912 kB
SwapFree:      3014512 kB
Dirty:            9800 kB
Writeback:           0 kB
AnonPages:     1448396 kB
Mapped:          24508 kB
Slab:           152152 kB
PageTables:      27492 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   6216164 kB
Committed_AS: 4136824 kB
VmallocTotal: 34359738367 kB
VmallocUsed:    264576 kB
VmallocChunk: 34359473651 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

Active는 Page Cache나 Anonymous Page 중 최근 이용 했거나 아직 Storage와 Unsynchronized인 Release 할 수 없는 Page이고, Inactive는 Page Cache나 Anonymous Page 중 마지막으로 Access 된 이후 어느 정도 시간이 지나 Storage와의 Sync가 완료되어 바로 Release 할 수 있는 Page이죠. 따라서, /proc/meminfo의 MemFree와 Inactive를 더한 것이 정확한 이용 가능 Memory size가 됩니다.
아참 여기서 Anonymous Page란 주로 User Process가 이용하고 있는 Page로, ps 등으로 취득가능한 RSS로 표시되는 값입니다. 실제, Shared Memory가 Page Cache에 포함되어 있거나 해서, 정확하게 파악하는 것은 상당히 번거로운 일이죠.

실제 이용 가능한 Memory size ≒MemFree + Inactive

Additional information : Kernel Tuning to control the Page Cache

Page Cache가 항상 남아있어 이를 Release 하고 싶은 경우 drop_caches 를 사용하면 되죠. drop caches는 지금 사용되고 있지 않은 Storage와 Unsynchronized Page Cache나 Slab Cache를 MemFree로 Release 합니다.
즉, MemFree ≒ 이용 가능한 Memory가 되죠.

아참 여기서 Slab Cache란 Directory의 Meta Data 정보를 수용하는 dentry나 File의 Meta Data 정보를 수용하는 inode 구조체등을 Cache하고 있는 Kernel내의 Memory 영역입니다. 이는 Page Cache와 별도로 Kernel 안에 확보되어 있고, Storage와 Sync되어 있으면 Release도 언제든지 가능합니다.

아래는 사용방법 입니다.

1. Default 상태로 # echo 0 > /proc/sys/vm/drop_caches 2. Page Cache만 Release # echo 1 > /proc/sys/vm/drop_caches 3. Slab Cache를 Release # echo 2 > /proc/sys/vm/drop_caches 4. Page Cache와 Slab Cache를 Release # echo 3 > /proc/sys/vm/drop_caches

위 drop_caches에 설정 한 parameter는 지속되지 않으므로 필요에 따라 실행해야 합니다.

이 글은 아래 Link의 글을 참조하였습니다.
http://www.atmarkit.co.jp/flinux/rensai/tantei01/bangai01a.html

Network #1 : Load Balancing : DSR (Direct Server Return)

2 Replies

1. What is the DSR(Direct Server Return) Load Balancing?

The type of Load Balancing is typically SLB and DSR, the DSR is when client request, which is balanced through L4 switch, is returning, it doens’t pass through L4 switch again that means returning directly.

Using SLB is as below,

Internet → A → L3 Switch → B  → L4 Switch → C → Web Server → C → L4 Switch →
 B → L3 Switch → A → Internet

The point is the Client Request and Server Response pass through L4 switch.
Using DSR is returning directly from the server as below,

Internet → A → L3 Switch → B → L4 Switch → C → L2 Switch → D → Web Server 1 → D →
 L2 Switch → C → L3 Switch → Internet

2. How to configure the DSR(Direct Server Return) on Linux?

You need to add and configure the Loopback device with L4 for DSR.

/sbin/ifconfig lo:0 xxx.xxx.xxx.xxx netmask 255.255.255.255
# ifconfig eth0 Link encap:Ethernet HWaddr 00:50:56:92:5E:B9 inet addr:10.0.0.151 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: xxxx::xxxx:xxxx:xxxx:xxxx/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1216814699 errors:0 dropped:0 overruns:0 frame:0 TX packets:1098502538 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:286063316490 (266.4 GiB) TX bytes:580239909610 (540.3 GiB) Base address:0x2000 Memory:d8920000-d8940000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:420991723 errors:0 dropped:0 overruns:0 frame:0 TX packets:420991723 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:720576542847 (671.0 GiB) TX bytes:720576542847 (671.0 GiB)
lo:0 Link encap:Local Loopback inet addr:xxx.xxx.xxx.xxx Mask:255.255.255.255 UP LOOPBACK RUNNING MTU:16436 Metric:1

If you want to add a device for DSR and work permernatly, create the loopback device “ifcfg-lo:0”
if not then you will be creating one.
Excute the following command:

# cd /etc/sysconfig/network-scripts # vi ifcfg-lo:0 DEVICE=lo:0 IPADDR=xxx.xxx.xxx.xxx NETMASK=255.255.255.255 ONBOOT=yes NAME=loopback

Additionally it is necessary to disable invalid ARP replies(misbehaving)

“Linux ARP flux” problem. Linux answers ARP requests on wrong and unassociated interfaces per default. This leads to the following two problems:

ARP requests for the loopback alias address are answered on the HW interfaces (even if NOARP on lo0:1 is set).
If the machine is connected twice to the same switch (e.g. with eth0 and eth1) eth2 may answer ARP requests for the address on eth1 and vice versa in a race condition manner (confusing almost everthing).

This can be prevented by specific arp kernel settings. Take a look here for additional information about the nature of the problem (and other solutions): http://linux-ip.net/html/ether-arp.html#ether-arp-flux.

To fix that generally (and reboot safe) we recommend to include the following lines into /etc/sysctl.conf (2.6 kernel only):

net.ipv4.conf.all.arp_ignore=1 net.ipv4.conf.all.arp_announce=2

The following commands may be used to change the settings interactively during runtime:

# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore # echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

Unfortunately there seems to be no general and simple solution for for kernel 2.4. We recommend currently upgrading to 2.6 kernel in that case, this is probably the easiest way.

JK Archives Blog

For Game, Linux, System, IT, Security or Etc

Monthly Archives: September 2010

Linux #5 : System File Protection

Linux #4 : Basic of Shell & Shell Scripting #1

Linux #3 : File & File System Management

Tech #4 : VMware VSphere 4.1의 Network 구성

Trend #1 : Early Warning Signs of IT Project Failure : The Dominant Dozen

Tech #3 : What is the Virtualization Technology?

Tech #2 : What is the x64?

Tech #1 : What is the 64bit?

Linux #2 : About Memory on Linux

Network #1 : Load Balancing : DSR (Direct Server Return)