좋은진호의 여유만만

LAMP환경(Linux, Apache, MySQL, PHP) 구축과 튜닝에 대해 주로 컨설팅 하는 Percona라는 곳이 있다. 대표적인 블로그 중 하나가 'MySQL Performance Blog'이다. 이 업체에서 컨퍼런스 영상과 실행 화면 등을 제공하는 percona.tv 사이트를 얼마전 오픈했다.

이 사이트의 성격은 'BSD 관련의 동영상'을 유튜브 한 곳에 모아둔 'BSDConferences' 동영상과 비슷할 것 같다. (관련글 : 유튜브 BSDConferences에 모여진 동영상 )

현재 몇 개의 동영상이 올라와 있다.

• Emulate a More Granular Slow Query Log With Maatkit
• InnoDB recovery tutorial using innodb-tools 등

FreeBSD 7.0부터는 오픈솔라리스의 ZFS(Zettabyte File System)을 사용할 수 있다. ZFS는 파일시스템과 볼륨관리자가 통합되어 있는 장점을 최대한 살려 한두개의 과정만으로 파일시스템을 바로 사용할 수 있다. 또한 마치 찰흙을 붙였다 떼었다 하는 듯한 느낌으로 볼륨 관리의 유연성을 맛 볼 수 있다. 그러나 FreeBSD에서는 아직 실험적으로 동작중이며, IO 성능 또한 만족스럽지 못하다. 결국 FreeBSD에서 만큼은 미래를 위해 맛보기용 파일시스템로 즐기면 될 듯 싶다.

간단한 ZFS의 특징을 정리하면.

- 파일시스템 + 볼륨관리자가 통합되었다.

- 128비트 파일시스템이며, 디렉토리와 파일의 갯수에 제한이 없다.

- 미러링, 그리고 RAID기능에 해당하는 raidz를 지원한다.

- 물리적 disk를 쉽게 스토리지 풀에 추가할 수 있다.

- 상태 모니터링이 효과적이다. (iostat, status, history, get 등)

- 스냅샷 기능을 지원한다.

1. ZFS 풀과 파일시스템 생성 (zpool create, zfs create, zpool list, zfs list)

zpool create 명령만으로 쉽게 '스토리지 풀'을 생성했다. 이 명령 하나만으로 바로 파일시스템을 이용할 수가 있다. 매우 간단하지 않는가?

리눅스의 LVM과 비교해보자. LVM은 PV 생성 -> VG 생성 -> LV 생성의 3과정을 거쳐야 한다. 1) 디스크나 파티션을 LVM으로 사용하겠다고 선언하는 PV(Physical Volume) 생성(pvcreate) 과정. 2) 이후 PV를 하나의 큰 덩어리로 묶는 VG(Volume Group) 생성(vgcreate) 과정. 3) 필요한 만큼만 떼어 내어 실제 사용가능한 파일시스템으로 만드는 LV(Logical Volume) 생성 과정. 이와 비교하면 zfs는 정말 간단하다.

이제 하나의 풀에 여러 파일시스템을 만들어보자.

data 풀에 data/backup, data/log, data/photo 파일시스템을 생성했다. 그런데 마운트포인트가 모두 /data 아래로 생성되었는데, 다른 곳으로 할 수는 없을까? zfs set 명령 하나면 바로 변경 가능하다. 또는 생성할 때 -o mountmpoint=/backup 옵션으로 지정할 수 있다.

(※ zfs get all 또는 zfs get mountpoint로 속성 정보를 얻을 수 있다.)

위의 파티션을 보면 용량이 모두 31GB로 표시되었다. zfs의 각 파티션이 '스토리지 풀'의 최대 용량까지 함께 사용하기 때문이다. data/photo 파티션은 5G만 사용하라고 쿼터를 할당해보자. 이 쿼터는 허용치만큼 늘릴 수도 줄일 수도 있다. 리눅스의 LVM이 확장하는 것만 가능(lvextend)한 것과 비교하면 상당히 유연한 자세를 취하고 있다.

만약 다른 파티션에서 용량을 사용하게 되면 그 양만큼 다른 파티션은 사용할 공간이 줄게 된다. 아래를 보면 /data/log가 11G를 사용중이다. 그래서 다른 파티션은 31GB-11GB 뺀 용량이 전체 사이즈로 표현된다.

ZFS는 자체에 데이터 안정성을 높을 높이는 mirror와 RAID-Z 기능을 제공한다. mirror기능으로 풀을 만들어 보자.

디스크는 SAS 73GB짜리이다. ufs 또는 zfs로 1개의 파일시스템을 만들면 66GB가 나온다. 2개 디스크인데, 132GB가 아닌 66GB로 표시되는 것은 mirror로 생성되었음을 보여준다. mirror로 설정되어 있는지 확인하는 방법은 뒤에서 다시 얘기하겠다.

2. zfs는 당신이 한 일을 모두 알고 있다. (zfs history)

'data' 풀에 적용된 작업이 모두 나왔다.

3. 상태 살펴보기 (zpool iostat, zpool status)

IO 상태를 2초간격으로 살펴본 것이다. 리눅스나 FreeBSD에서 iostat를 해봤을 것이다. iostat는 디스크별로 IO를 보는 것이며, zpool iostat는 '스토리지 풀'별로 살펴보는 것이다. 'data' 풀의 ONLINE상태를 확인할 수 있다.

다음은 'backup'풀이 mfid1, mfid3 2개 disk를 사용하여 mirror되어 있는 것을 볼 수 있다.

4. ZFS 풀과 파일시스템 unmount & 지우기 (zpool destroy, zfs umount, zfs destroy)

파일시스템를 umount하기 위해서는 'zfs umount 파일시스템' 형태로 하며, 완전 제거는 'zfs destroy'로 한다. 파일시스템이 사용중이지 않으면 바로 unmount와 제거가 가능하다.

스토리지 풀 전체를 제거할 때도 마찬가지로 zpool destroy로 하면 된다.

5. FreeBSD에서는 ZFS를 서비스에 적용할 수 있을까? (성능 및 기타 사항)

ZFS는 최소 1GB이상의 메모리를 권장한다. 그러나 ZFS는 실제 많은 메모리를 사용하는 경우가 있다. 파일시스템 성능 체크를 하는 동안 panic: kmem_malloc(16305): kmem_map too small: 332353536 total allocated 같은 메시지를 뿌리면서 몇 번 다운되었다. i386 환경에서는 kmem address space(vm.kmem_size_max)의 최대값이 320M으로 되어 있다. 그러나 이 수치는 ZFS을 사용하기에는 낮은 수치이므로 기본값을 그대로 사용할 경우에는 커널 패닉이 발생할 수 있다고 한다. 그래서 나도 다운이 된 것이었다. vm.kmem_size는 read only값이므로 /boot/loader.conf 에 다음 2줄을 추가한다. 그리고 부팅을 하고, 필요시 이 수치는 더 늘리면 된다.

bonnie++로 Sequential Output/Input/Create, Random, Random Create의 성능 비교를 했다. ufs 파일시스템과 비교했을 때 각 항목별로 대략 2~5배 이하의 만족스럽지 못한 성능이 나왔다. zfs 기본 생성외에 mirror로 이뤄진 풀, raidz 로 이뤄진 풀도 낮은 수치인 것은 마찬가지였다.

그리고, 부팅 후 ZFS를 처음 create할 때는 다음과 같은 메시지가 나온다.

'WARNING' 부분이 보이는가? FreeBSD에서는 실험적인 상태이고, 성능 또한 상당히 낮으니, 편리함과 유연함을 높이 산다고 하더라고 서비스에 적용하기는 무리가 있다. 아직 FreeBSD에서는 재밌게 즐기면 된다. 즐기다 보면 미래에 적용해도 괜찮을 때가 오겠지...

6. 참고 자료

* ZFS 시작하기

  http://kr.sun.com/developers/solaris/techdocs/starting_zfs.html

* ZFS Tuning Guide

  http://wiki.freebsd.org/ZFSTuningGuide

* FreeBSD 7.1 달라진 것 몇가지 (2009.1.20, 글 좋은진호)

  http://coffeenix.net/bbs/viewtopic.php?t=3753

* FreeBSD 7.0 사용기 (2008.3.7, 글 좋은진호, ZFS 사용기 일부 포함)

  http://coffeenix.net/bbs/viewtopic.php?t=2892

2009/01/19 - [시스템이야기] - FreeBSD 7.1 달라진 것 몇가지
2008/03/07 - [시스템이야기] - FreeBSD 7.0 사용기
2008/04/18 - [IT이야기] - FreeBSD 7 관련 도서 2권

FreeBSD 7.1의 큰 변화는 첫째 기본 스케쥴러의 변경, 두번째 '트레이싱, 디버깅 그리고 모니터링의 강화'라고 할 수 있을 정도로 이부분의 발전이 돋보인다. 달라진 것을 간단히 적어본다.

1. SCHED_ULE 스케쥴러

GENERIC 커널에서 기본 스케줄러가 SCHED_4BSD 에서 SCHED_ULE 으로 변경되었다. 7.0에서는 커널 컴파일을 통해서 SCHED_ULE 로 변경할 수 있었다.


2. DTrace

   OpenSolaris의 DTrace가 드디어 FreeBSD에 포팅되었다.  DTrace 사용을 위해서는 커널 설정 파일에 다음을 추가한다.


   그리고, 모든 소스는 CTF 옵션을 포함된 상태로 리빌드되어야 한다.


DTrace사용을 위한 자세한 준비 과정은 http://www.freebsd.org/doc/en/books/handbook/book.html#DTRACE 에서

3. 몇가지 명령어의 옵션 추가

   1) top 명령에서 -P 옵션으로 CPU별 통게를 볼 수 있다. 리눅스 top에서 '1'를 눌러을 때와 같은 것으로 보면 되다.
      (이 옵션은 FreeBSD 6.4에서도 사용 가능)


   2) top 명령에서 -a 옵션으로 프로세스의 argument를 볼 수 있다.

  [ 옵션 사용전 ]

  [ top -a ]

   3) vmstat  -P 옵션으로 CPU별 통계를 볼 수 있다. (이 옵션은 FreeBSD 6.4에서도 사용 가능)


   4) traceroute 명령에서 -a옵션으로 AS number도 함께 볼 수 있다.

   5) arp 명령에서 reject와 blackhole 키워드를 지원한다.

   6) cp 명령에서 -a 옵션(archive mode)을 지원한다. -RpP 옵션과 동일. 리눅스의 GNU cp 옵션과 동일하다고 보면 된다.

4. /etc/sysctl.conf.local 설정 파일

   rc 스크립트(/etc/rc.d/sysctl)에서 /etc/sysctl.conf 로딩한 후에 /etc/sysctl.conf.local 설정도 로딩하도록 되어 있다.
   따라서 서버별 개벌 설정은 sysctl.conf를 수정하지 않고 /etc/sysctl.conf.local에 넣어도 된다.

5. truss 명령

   truss는 리눅스의 strace, 솔라리스의 truss처럼 프로세스의 시스템 콜을 추적한다. FreeBSD 6.x 버전에서는 truss를 사용하기 위해서 아래처럼 process 파일시스템을 /proc에 마운트 해줘야 했다. 그러나 FreeBSD 7.0부터 더이상 procfs 파일시스템에 의존하지 않기 때문에 mount_procfs 명령을 사용할 필요없이 시스템 콜을 추적할 수 있다.


   사용예) truss ls

   -f 옵션을 사용하면 fock되는 프로세스까지 추적할 수 있다.

6. 부트로더의 변경으로 USB에서 부팅할 수 있고, GPT 레벨 디스크에서 부팅할 수 있다.

* 2008/04/18 - [IT이야기] - FreeBSD 7 관련 도서 2권
* 2008/03/11 - FreeBSD 7.0과 Linux 간의 성능 비교
* 2008/03/07 - [시스템이야기] - FreeBSD 7.0 사용기
* 2008/02/28 - [시스템이야기] - FreeBSD 7.0 릴리즈

스팸 툴에서 사용하는 변수(매크로)가 그대로 노출되서 발송되는 경우가 있다. 2006년 하반기에 '스팸발송기가 깜빡한건가? (스팸메일의 변수들)'라는 제목으로 글을 쓴 적이 있다. 이번달에 또다시 이런 변수들이 섞여진 메일이 눈에 띄어(그 전에도 필터링되었을 것인데, 유독 이번달에 더 띈다.), 해당 변수들을 추가 정리하였다.

3. From: 예 (2008.12)

Return-Path: <JADA{%DIGIT%}{%DIGIT%}@hanmail.net>
... 생략 ...
From: JADA SESSOMS <JADA{%DIGIT%}{%DIGIT%}@hanmail.net>

4. From: 예 (2개, 2008.12)

From {%LFNAME%}{%LLNAME%}34@gmail.com  Fri Dec 19 05:23:02 2008
Return-Path: <{%LFNAME%}{%LLNAME%}34@gmail.com>
... 생략 ...
From: {$FROMNAME$} <{%LFNAME%}{%LLNAME%}34@gmail.com>

From: 이나 Return-Path: 헤더에서 %DIGIT% 에는 발송기가 임의의 숫자를 넣게 된다. %RND_DIGIT[1-3] 와 같은 형식도 있는데, 정규 표현식과 유사(정규표현식에서 {1,3}은 1~3자리를 의미)하게 사용해서 1자리에서 3자리까지 임의의 숫자가 들어가게 될 것이다. 결국 0~9자리의 숫자를 자유롭게 From주소에 넣을 수 있다는 얘기다.

Subject: 헤더중 %RND_DATE_TIME에는 정상 스팸(?)일 경우 '파일럿 항공자켓 겨울특전~Wed, 21 Dec 2005 07:54:32 -0400' 처럼 날짜가 들어가 있다.

과연 저런 유형의 변수를 사용하는 스팸툴은 어떤 것이 있을까.

인터넷 여러 기술문서에서 확인할 수 있으며, 'Inside the Spam Cartel: Trade Secrets from the Dark Side'(2004년)책에서도 확인할 수 있다. 스팸툴의 이름을 공개하지 않고, 2개 스팸툴 화면만 소개한다.

메일과 안티스팸을 주제로 치뤄지는 CEAS 2008 행사(Conference on Email and Anti-Spam)가 있다. 여기서 발표된 'A Survey of Modern Spam Tools'(글 Henry Stern) 문서는 스팸메일의 유형과 변수(매크로)에 대해서 상세히 분석되어 있다.

자세한 글은 커피닉스에 써둔 '스팸발송기가 깜빡한건가? (스팸메일의 변수들)'을 살펴보기 바란다.