Service servers

문서의 소개

이 문서는 web 서비스를 분산처리해서 구성하는 설계과정 및 세팅과정에 대한 내용을 담은 문서입니다. 본인은 근래에 서비스의 구축을 진행하면서 다음과같은 전제를 세웠습니다.

1. 서버의 파일시스템은 클러스터링 파일시스템이어야 한다.
2. 서버의 클러스터링 파일시스템은 네트워크가 분리되어 있어서 바깥쪽에서 직접적으로 클러스터링 파일시스템에 접근은 할 수 없어야 한다.
3. 서버 모니터링 시스템이 필요하다
4. 배너를 관리하고 클릭수 또는 방문자수를 모니터링 할수 있는 시스템이 필요하다
5. 이미지 서버는 로드밸런싱을 적용하도록 한다.
6. 네임서버는 국가별 IP 에 따라 접속하는 서버를 다르게 할 수 있어야 한다
7. 한곳의 IDC 에서 다른 idc 로 proxy 를 통해 http 트래픽을 분산할 수 있어야 한다.

이와같은 전제를 두고 다음과 같은 서버 구성을 마련해보게 되었습니다.

앞의 다이어그램에 근거해서 다음의 소프트웨어 구성을 준비하게 되었습니다.

1. clustered file system : lustre
2. gslb - global server load balancer : bind
3. http proxy : nginx
4. http image load balancer : lvs-keepalived
5. server monitoring system : zabbix
6. banner management system : revive

이러한 소프트웨어 구성을 기반으로 하나하나의 설치법을 알아보도록 하겠습니다.

Network File system : LUSTRE

clustered file system : lustre

lustre 는 현재 많은곳에서 사용되고있는 클러스터링 파일시스템으로서 한국에도 꽤나 문서들이 많습니다. lustre 의 유지 및 백업은 이 문서에서 논의할 내용이 아닙니다. 자세한 내용은 http://lustre.org 에서 확인해주시기 바랍니다.

lustre 를 구성할때의 전제사항

lustre 는 increment 만 가능한 파일시스템입니다. 이 얘기는 뭐냐하면 중간에 파일시스템을 담당하고 있는 node 중에 한 서버에 문제가 생긴다면 파일시스템의 동적축소가 불가능하다는 의미죠. 서버를 추가로 붙이는것은 가능하지만 서버를 삭제해서 재구성을 하는건 동적으로 안된다는 의미입니다. 그 경우는 비슷한 환경으로 구성된 다른 lustre 서버군에 항상 mirror 를 마련해둬야 한다는 의미인데요.. 지금의 경우는 테스트서버군을 구성하는것이기때문에 mirror 서버군을 구성할 필요는 없습니다. 하지만 테스트중에 서버가 문제가 생기면 안되기 때문에 각 서버의 하드디스크는 모두 raid 1 (mirror) 로 구성하는것을 전제로 하고 있습니다.

lustre 의 구성에 필요한 요소

lustre 는 내부에서 최소 3개정도의 요소를 필요로 합니다 물론 모두 한개의 서버에 구성할 수도 있고 더 많은 서버를 둘 수도 있습니다만.. 제가 이번의 테스트서버군 구축으로 얻고싶은건 "작동한다" 가 아니라 "어떻게 운영해야한다" 라는결과를 경험하고 싶었기때문에 3개정도로 구성했습니다. 3대의 구성내용은 다음과 같습니다.

• MDS and MGS
  • 전체 lustre 구성을 관리하는 서버입니다. 원래는 MDS 와 MGS 의 2개가 나눠진 구성으로 가야합니다만..... 지금의 경우는 굳이 그래야할 필요는 없어서 하나의 서버에 합쳐놓은 상태입니다. MDS 는 meta data server 라는 명칭이며 MGS 는 management server 를 의미합니다. client 에서 lustre storage 를 mount 할때는 이 MGS 서버의 IP 를 기준해서 진행해야 합니다.
• OST1
  • 데이터를 저장하는 저장소를 의미합니다. 지금은 2개만 사용중입니디만... 필요한 경우에는 병렬로 확장할 수 있습니다.
• OST2
  • OST1 과 같습니다. 수평적으로 확장되는 저장소 서버입니다.

lustre 서버군의 구성에는 centOS 6.6을 사용하였습니다. 일단 대부분의 lustre 가이드들이 centos 6.x 또는 그 이전의 내용을 기준으로 설명되어 있으며 lustre 자체가 안정성을 필요로 하기때문에 별다른 백업대응이 되어있지 않은 지금의 상황에서는 굳이 다른 무리수를 두고싶지 않았기 때문입니다. 하긴... 생각해보면 lustre 쪽도 centOS 7 에서 도입된 systemd 가 조금 부담스러웠지 않나.. 싶기도 합니다만...

다만 client 는 gentoo 로 구성하였습니다. 제가 워낙에 오래 사용한 Linux 이기도 합니다만... linux 3.11 부터 lustre module 이 포함되어 별도의 kernel patch 가 필요하지 않기도 하거니와 서비스 서버들이 gentoo 로 구성되었기 때문입니다.

각 서버들의 파일시스템 현황

서버들의 파일시스템은 다음과같이 세팅되어 있습니다.

1. MDS
   • /dev/sda1 :: /boot 부분입니다. 커널등 부팅에 필요한 파일들이 담겨있습니다.
   • /dev/sda2 :: / 부분입니다. OS 가 운영되는데 필요한 파일들이 담겨 있습니다.
   • /dev/sda3 :: MDS 에서 관리하는 정보들을 담은 파티션입니다.
2. OST1
   • /dev/sda1 :: /boot 부분입니다. 커널등 부팅에 필요한 파일들이 담겨있습니다.
   • /dev/sda2 :: / 부분입니다. OS 가 운영되는데 필요한 파일들이 담겨 있습니다.
   • /dev/sda3 :: lustre cluster 저장소에 추가되는 파티션입니다.
3. OST2
   • /dev/sda1 :: /boot 부분입니다. 커널등 부팅에 필요한 파일들이 담겨있습니다.
   • /dev/sda2 :: / 부분입니다. OS 가 운영되는데 필요한 파일들이 담겨 있습니다.
   • /dev/sda3 :: lustre cluster 저장소에 추가되는 파티션입니다.

파일시스템은 미리미리 게확을 짜놓지 않으면 나중에 고생하는 경우가 생깁니다. 물론 OST1 또는 OST2 에 별도의 하드디스크를 붙여서 저장소 영역으로 추가할 수도 있습니다만.. 그렇게 한다고해서 lustre 저장소군이 구성된 물리 network interface 의 bandwidth 를 보장받을 수는 없기때문에 자금이 넉넉하다면 서버 하나에 필요한 만큼의 하드 또는 저장장치만 할당하는게 좋을거라 생각합니다. 지금의 경우는 굳이 그런경우까지는 필요하지 않아서 간략하게 구성했습니다.

lustre 의 단계별 세팅

lustre 의 세팅순서는 간단하게 나열하면 다음과 같습니다.

1. centos 설치(파티셔닝 포함)
2. centos 에 필요한 프로그램 설치(MDS 와 OST 각각)
3. MDS 세팅
4. OST 세팅 및 MDS 에 추가
5. client 에서 lustre mount 해서 테스트하기

이 과정의 순서를 따라 간단하게 설명을 해보겠습니다. 다만 centOS 설치과정은 생략합니다. 프로그램 설치부터 알아보기로 하겠습니다.

일단 lustre 의 서버쪽에는 다음과같은 파일이 필요합니다. 미리 다운로드 받아놔주세요.

• e2fsprogs-1.42.12.wc1-7.el6.x86_64.rpm
• e2fsprogs-debuginfo-1.42.12.wc1-7.el6.x86_64.rpm
• e2fsprogs-devel-1.42.12.wc1-7.el6.x86_64.rpm
• e2fsprogs-libs-1.42.12.wc1-7.el6.x86_64.rpm
• e2fsprogs-static-1.42.12.wc1-7.el6.x86_64.rpm
• libcom_err-1.42.12.wc1-7.el6.x86_64.rpm
• libcom_err-devel-1.42.12.wc1-7.el6.x86_64.rpm
• libss-1.42.12.wc1-7.el6.x86_64.rpm
• libss-devel-1.42.12.wc1-7.el6.x86_64.rpm

이 파일들을 먼저 설치해 주시기 바랍니다. 설치는 파일들을 모아놓은 디렉토리에서 다음의 명령어로 진행하면 됩니다.

rpm -Uvh *

일단 e2fsprogs 관련된 파일들을 설치한 이후에 다음의 파일들을 준비해주세요.

• kernel-2.6.32-431.20.3.el6_lustre.x86_64.rpm
• kernel-debuginfo-2.6.32-431.20.3.el6_lustre.x86_64.rpm
• kernel-debuginfo-common-x86_64-2.6.32-431.20.3.el6_lustre.x86_64.rpm
• kernel-devel-2.6.32-431.20.3.el6_lustre.x86_64.rpm
• kernel-firmware-2.6.32-431.20.3.el6_lustre.x86_64.rpm
• kernel-headers-2.6.32-431.20.3.el6_lustre.x86_64.rpm
• lustre-2.6.0-2.6.32_431.20.3.el6_lustre.x86_64.x86_64.rpm
• lustre-debuginfo-2.6.0-2.6.32_431.20.3.el6_lustre.x86_64.x86_64.rpm
• lustre-iokit-2.6.0-2.6.32_431.20.3.el6_lustre.x86_64.x86_64.rpm
• lustre-modules-2.6.0-2.6.32_431.20.3.el6_lustre.x86_64.x86_64.rpm
• lustre-osd-ldiskfs-2.6.0-2.6.32_431.20.3.el6_lustre.x86_64.x86_64.rpm
• lustre-tests-2.6.0-2.6.32_431.20.3.el6_lustre.x86_64.x86_64.rpm
• perf-2.6.32-431.20.3.el6_lustre.x86_64.rpm
• perf-debuginfo-2.6.32-431.20.3.el6_lustre.x86_64.rpm
• python-perf-2.6.32-431.20.3.el6_lustre.x86_64.rpm
• python-perf-debuginfo-2.6.32-431.20.3.el6_lustre.x86_64.rpm

파일들을 한곳에 모은다음 다시 설치를 진행해주시면 됩니다 물론 rpm 으로 설치겠죠? 인터넷이 연결되어있어야 모자른 파일들을 받아와서 설치할 수 있습니다. 이렇게 설치를 하면 일단 필요한 파일은 다 설치된겁니다. 위의 파일들은 MDS 및 OST 서버에 모두 설치되어야 합니다.

MDS 서버의 세팅

서버에 필요한 패키지들을 설치하고 나면 이제부터는 각 서버의 세팅에 들어가야 합니다. 일단 모든 서버들의 Index 가 되는 MDS 부터 세팅하기로 하겠습니다. MDS 서버에서 다음의 명령어를 실행해주시면 됩니다.

mkfs.lustre --mgs --mdt --fsname=lustre --index=0 /dev/sda3

위 명령어의 내용을 몇가지 살펴볼까요?

• lustre 라는 mount filesystem group 으로 MDS 를 생성합니다. 주의사항이 있는데 이 이름은 알파벳으로 8 글자가 한계입니다. 잘 생각해서 지정해야합니다. 나중에 변경도 안되니 주의해주시기 바랍니다.
• MDS 와 MGS 를 같은 서버에 세팅할것이기 때문에 "--mgs --mdt" 를 사용하도록 합니다.
• MDS 중 첫번째로 사용되는 Index 서버이기 때문에 index 값은 0 이 됩니다. 나중에 이중화등을 할때는 세팅값이 바뀔 수 있습니다만 일단은 0 으로 지정하면 됩니다.
• MDS 에서 lustre 스토리지를 관리하는 목적으로 사용될 저장공간은 /dev/sda3 으로 지정하였습니다.

이렇게 MDS 서버의 세팅은 간단하게 끝이납니다. 필요한경우(lustre 를 아예 다시 구성하려는 경우등)라면 --reformat 옵션을 사용할 수 있습니다.

포맷을 진행하면 다음과같은 메시지를 확인할 수 있습니다.

   Permanent disk data:
Target:     lustre:MDT0000
Index:      0
Lustre FS:  lustre
Mount type: ldiskfs
Flags:      0x65
              (MDT MGS first_time update )
Persistent mount opts: user_xattr,errors=remount-ro
Parameters:

device size = 373415MB
formatting backing filesystem ldiskfs on /dev/sda3
	target name  lustre:MDT0000
	4k blocks     95594240
	options        -J size=4096 -I 512 -i 2048 -q -O dirdata,uninit_bg,^extents,dir_nlink,quota,huge_file,flex_bg -E lazy_journal_init -F
mkfs_cmd = mke2fs -j -b 4096 -L lustre:MDT0000  -J size=4096 -I 512 -i 2048 -q -O dirdata,uninit_bg,^extents,dir_nlink,quota,huge_file,flex_bg -E lazy_journal_init -F /dev/sda3 95594240
Writing CONFIGS/mountdata

이렇게 해서 MDS 에서 필요한 파일시스템의 준비가 끝났습니다. 이제 만들어진 파일시스템을 MDS 서버 내에서 mount 해보도록 하곘습니다. 다음의 명령어를 실행해주세요.

mount -t lustre /dev/sda3 /mnt/mdt

물론 /mnt/mdt 라는 디렉토리는 미리 만들어져 있어야 할것입니다. 지금까지의 과정으로 MDS 서버의 준비작업은 모두 끝났습니다. 이제부터는 실제 데이터가 저장되는 OST 서버의 세팅을 알아보도록 하겠습니다.

OST 서버의 세팅

OST 서버는 lustre 에서 데이터가 실제 저장되는 media 를 의미하는 서버입니다. 이 서버는 수평적으로 확장되어 lustre storage group 에 편입될 수 있으며 이 작업은 매우 간단하게 이루어집니다. 지금부터 OST 서서버의 세팅을 알아보도록 하겠습니다.

OST 서버의 데이터저장 파일시스템을 초기화하려면 아래의 명령어를 진행하면 됩니다.

mkfs.lustre --ost --fsname=lustre --mgsnode=MDS서버의IP주소@tcp0 --index=0 /dev/sda3

물론 MDS 서버를 관리하기 위해서 /etc/hosts 등에 서버들의 ip 를 alias 시켜놓으면 보다 편하게 작업할 수 있습니다. 하지만 저는 테스트 서버군을 구축하는것이 목적이기때문에 그렇게까지 번거로운 작업은 진행하지 않았습니다. 이제 위의 명령어를 살펴보도록 하겠습니다.

• MDS 서버의 IP 주소는 앞에서 세팅한 서버의 IP 를 적어주면 됩니다. 뒤쪽에 붙어있는 tcp 는 lustre 에서 사용하는 프로토콜을 의미합니다
• OST의 index 는 중요합니다. OST 가 2개가 존재하는경우 index 값은 각자 0 과 1 이 되어야 합니다. 어떻게 지정되어도 무방하지만 중복될 수는 없습니다. 당신이 세팅하는 서버가 2개의 OST 서버중 두번째 서버라면 아래와 같이 하면 됩니다.
  • mkfs.lustre --ost --fsname=lustre --mgsnode=MDS서버의IP주소@tcp0 --index=1 /dev/sda3
• OST 가 속하게될 lustre gruop 의 이름을 지정하는것을 잊지 마세요. 동일해야합니다.

포맷이 끝나면 해당 파일시스템을 OST 서버내에 mount 해주는것 만으로 OST 서버의 저장공간은 lustre group 에 속하게 됩니다.

mount -t lustre /dev/sda3 /mnt/ost

당연하게도 /mnt/ost 디렉토리는 미리 생성이 되어있어야 할 것입니다.

세팅된 lustre 의 사용

이미 이 글의 앞에서 적었듯이 실제 lustre 를 활용하게될 서버는 gentoo 서버입니다. gentoo 서버를 lustre 의 client 로 사용하기 위해서는 몇가지 작업을 해주어야만 합니다. 일단 kernel 에 lustre 관련 부분이 추가되어있는지부터 살펴봐야 할 것입니다. 그리고 당신이 사용하는 linux 커널이 3.11 이상인지도 확인해야 할 것입니다. linux 커널내부에서 lustre 의 위치는 다음과 같습니다.

• kernel 의 menuconfig 에서 다음의 depth 를 확인한다
• Device Drivers
  • Staging drivers
    • Lustre file system client support

이걸 사용하고 있다면 일단 lustre 의 client kernel module 은 당신에게 이미 설치되어있다는 의미가 됩니다. lustre 는 linux 커널의 구조에서 filesystem 에 위치하지 않고 있다는 사실을 반드시 기억해주시기 바랍니다. 확인은 당신의 파일시스템에서 아래의 디렉토리를 확인하는것으로도 가능합니다.

/lib/modules/사용자의커널버전/kernel/drivers/staging/lustre/lustre

이 디렉토리가 존재한다면 당신의 시스템은 lustre 를 mount 해서 사용하기위한 최소한의 준비가 되어있다고 판단하셔도 좋습니다. 그 뒤에 일반적인 gentoo system 에는 대부분 있기는 하지만 간혹 가지고 있지 않은 시스템을 위해 다음의 명령어로 패키지를 하나 설치해주도록 합니다.

emerge e2fsprogs

gentoo 는 lustre 관련된 client 도구들을 설치할 수 있는 기본 패키지가 없기때문에 이제부터 git 에서 lustre 를 사용하기 위한 도구를 받아서 compile 하도록 하겠습니다. 다음의 명령으로 git 에서 lustre 의 소스코드를 받아오도록 합니다.

git clone git://git.whamcloud.com/fs/lustre-release.git

파일들이 다 받아졌다면 디렉토리 안쪽으로 이동해서 다음의 명령어를 실행합니다.

sh autogen.sh

이렇게 하면 당신의 client 시스템을 위한 소스코드가 준비가 되었다는 의미가 됩니다. 이제 configure 를 진행해서 도구드를 compile 하도록 합시다.

./configure --prefix=/usr --without-zfs --without-ldiskfs --disable-ldiskfs-build --with-linux=/usr/src/linux/ --disable-server --enable-client --enable-utils --enable-readline --enable-urandom --disable-modules

물론 이 다음에 make 명령어와 make install 명령어로 도구들을 당신의 client 시스템에 설치하면 당신의 시스템은 lustre 를 mount 해서 사용할 준비를 다 갖추게 됩니다.

이제 당신의 client 시스템에 lustre 를 mount 하기위한 디렉토리를 만들고 다음의 명령어로 lustre 를 mount 해서 사용해 보도록 하겠습니다.

mkdir /mnt/luster
mount -t lustre MDS서버의IP주소@tcp0:/lustre /mnt/luster

이 명령은 더이상 설명할 필요가 없을정도로 명백하고 단순합니다. 이제부터는 lustre 를 사용하기만 하면 됩니다. 단! 주의할점이 있습니다. 제일 처음으로 mount 된 lustre 는 df -h 등의 명령어가 작동되지 않습니다. 그럴때는 파일을 하나 복사하거나 다음과같은 간단한 방법으로 lustre 시스템에 df 명령어가 정상작동되게 할 수 있습니다.

touch /mnt/lustre/dummy

touch 명령어로 아무 파일이나 하나 생성해주면 이후 lustre 파일시스템은 보란듯이 모든 동작을 정상적으로 하게됩니다. 물론 이 작업은 단 한번만 필요로하며 재부팅등의 사유로 lustre 를 하나하나 다시 시작한다고 해도 다시는 해줄 필요가 없습니다. touch 명령어를 이용한 작업은 당신이 lustre 를 가장 처음 사용하는 경우에만 필요하다는 사실을 명심해주시기 바랍니다. 가끔 lustre 가 정상동작하지 않는다면 modprobe 등으로 lustre kernel module 을 로딩시켜주시기 바랍니다.

참고자료::lustre

• http://avicom.tistory.com/entry/lustre
• https://wiki.debian.org/Lustre
• http://blog.syszone.co.kr/2124
• http://lustrekr.tistory.com/17

도움주신분

• 서울시립대 류근모님

bind 를 이용한 지역단위 서버 트래픽 분산처리 : global server load balancer

개념

bind 가 어디에 쓰이는 물건인지는 이 문서를 읽는 수준의 사람이라면 대부분 알거라 생각합니다만.... 간단하게 말해서 Domain Name Server, 통칭 DNS 가 bind 의 역할입니다. DNS 는 사용자의 요청값에 따라 자신이 관리하고 있는 ip 정보를 반환해주는 역할을 합니다. 그때문에 DDOS 공격등에서 DNS 서버 자체가 대상이 되는경우도 허다합니다. (물론 이런걸로 뻗을정도의 서비스라면... 좀 더 많은 생각을 하고 구성해야 할겁니다만..... 제일 좋은건 DNS 서버의 앞쪽에 anti-DDOS zone 을 두는게 현명합니다) 자 각설하고.. 이 GSLB 의 개념은 간단합니다. DNS 서버에 질의를 하는 요청자를 선별해서 각 경우에 따라 다른 IP 정보를 반환하게 해주는거죠.

왜 이런 짓을 해야하는가?

이건 국제망에 대한 문제라고 봐야합니다. 지금 현재 한국에도 KT,SK,LG-DACOM 등의 망이 있습니다만 이 망들 사이의 대역폭은 언제나 균등하지 않습니다. 덕분에 각 망별로 상태가 좋은 구간이 있고 조금 안좋은 구간이 있기도 하죠. 이걸 그대로 국제망에 적용시켜보겠습니다. 한국-일본 사이의 망은 KT 가 좋습니다. 그리고 한국-중국 은 요즘의 경우 SK 가 좋은 상태를 보여주고 있죠. 또한 중국내의 통신사와 궁합 문제가 있기도 하구요. 이런식으로 각 나라마다 좋은 망이 각기 틀리기때문에 가장 좋은 서비스를 해주기 위해서는 같은 Domain 을 요청한다고 해도 상황에 따라 상태가 좋은 서버를 우선순위로 응답해주는것이 중요합니다. 이런 개념에서 만들어진게 바로 GSLB 입니다.

구현에 필요한 사전지식

bind 로 GSLB 를 구현하기 위해서는.. bind 자체의 geoip 를 사용하는 방법도 있습니다만.. 제가 여기서 구현한것은 조금 더 오래된 방법입니다. 전세계 ip 의 국가별 대역을 별도의 DB 처럼 구축해서 각 zone 별로 bind 가 반응하는 방법을 사용하려고 합니다. 이렇게 하라면 다음의 준비물이 필요할겁니다.

• 국가별 DB
• bind 설정 내부에서 구현되는 지역별 zone 파일 로딩설정

이정도의 개념을 가지고 이제부터 bind 로 만드는 GSLB 를 진행해보도록 하겠습니다.

각 국가별 IP 대역정보 확보하기

이 부분은 일단 이곳을 살펴보는것이 좋습니다.

• https://geti2p.net/en/docs/spec/geoip

여기서 전세계 IP 에 대한 정보를 다 받아볼 수 있구요 필요한 형태에서 어떤식으로 파일을 사용해야하는지까지 상세하게 설명되어 있습니다. 이 파일 포맷을 이용해서 bind 에서 사용하기 좋은 format 으로 변환하는 sheel script 를 소개합니다.

#!/bin/bash

[ -f GeoIPCountryCSV.zip ] || wget -T 5 -t 1 http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip

echo -n "Creating initial CBE (Country,Begin,End) CSV file..."
unzip -p GeoIPCountryCSV.zip GeoIPCountryWhois.csv | awk -F \" '{print $10","$6","$8}' > cbe0.csv
echo -ne "DONE\nSplitting CBE CSV file..."

lc0=0; lc1=$(wc -l cbe0.csv | awk '{print $1}')

while [ $lc0 -lt $lc1 ]
do
  lc0=$lc1; echo -ne "\n$lc0\t"
  awk -F , '{m = 2^32-2^int(log($3-$2+1)/log(2)); n = and(m,$3); if (n == and(m,$2)) print; else printf "%s,%u,%u\n%s,%u,%u\n",$1,$2,n-1,$1,n,$3}' cbe0.csv > cbe1.csv
  mv -f cbe1.csv cbe0.csv; lc1=$(wc -l cbe0.csv | awk '{print $1}')
  echo -ne "+$[$lc1-$lc0]\t"; [ $lc0 -lt $lc1 ] && echo -n "OK"
done

echo -ne "DONE\nGenerating BIND GeoIP.acl file..."

(for c in $(awk -F , '{print $1}' cbe0.csv | sort -u)
do
  echo "acl \"$c\" {"
  grep "^$c," cbe0.csv | awk -F , '{printf "\t%u.%u.%u.%u/%u;\n",$2/2^24%256,$2/2^16%256,$2/2^8%256,$2%256,32-int(log($3-$2+1)/log(2))}'
  echo -e "};\n"
done) > GeoIP.acl

rm -f cbe0.csv
echo "DONE"

exit 0

위의 스크립트를 이용하면 GeoIP.acl 이라는 bind 에서 사용하기 좋은 format 의 파일을 결과물로 얻을 수 있습니다. 이렇게 만들어진 acl 파일은 어떻게 사용해야 할까요?

bind 설정:acl 파일과 view 를 이용한 bind 의 설정

다들 아시다시피 bind 의 설정파일은 named.conf 입니다. 물론 배포판마다 위치는 조금씩 다를수도 있으니 그 부분은 각 배포판의 자료를 참고해주시기 바랍니다. 여기서는 설정되어야 할 named.conf 의 해당부분 예제를 먼저 소개하고 그것에 대한 설명을 하는것으로 진행하도록 하겠습니다.

• include "/etc/bind/GeoIP/GeoIP.acl";

view "native_korea" {
     match-clients { KR; };
     zone "abcd.net" {
          type master;
          file "pri/KR-abcd.net.zone";
          allow-query { any; };
          also-notify {8.8.8.8; 8.8.4.4;};
     };
     include "/etc/bind/named.conf.default-zones";
};

view "japan" {
     match-clients { JP; };
     zone "abcd.net" {
          type master;
          file "pri/JP-abcd.net.zone";
          allow-query { any; };
          also-notify {8.8.8.8; 8.8.4.4;};
     };
     include "/etc/bind/named.conf.default-zones";
};

view "foreign_korea" {
     match-clients { any; };
     recursion no;
     zone "abcd.net" {
          type master;
          file "pri/OTHER-abcd.net.zone";
          allow-query { any; };
     };
     include "/etc/bind/named.conf.default-zones";
};

물론 named.conf 의 다른 부분을 이 글을 읽으시는 분들이 알아서 잘 설정하실거라 믿습니다. 이제 각 part 를 알아보도록 하겠습니다.

일단 가장위에 있는 include 부분을 살펴보겠습니다. 이부분에서는 아까의 스크립트를 이용해 만들어진 GeoIP.acl 파일을 로딩하고 있습니다. 일단 이렇게 IP 관련된 테이블을 로딩해서 이후 작업에 필요한 부분을 미리 준비하는거죠. 이 acl 파일에 대해서는 아래부분을 설명하면서 좀 더 확실하게 알게될 거라고 생각합니다.

첫번째 "view" 부분을 보겠습니다. 다른 부분은 크게 신경쓸 필요는 없습니다만.. 일단 match-clients 라는 내용은 주의해서 봐야할겁니다 "KR" 이라는 문자열이 있죠? 이 문자열을 acl 파일 안쪽에서 찾아보겠습니다. 그렇죠.. KR 이라고 되어있는 부분은 acl 파일 안에서도 한곳밖에는 없습니다. 이 부분이 바로 한국에 해당되는 부분을 걸러서 조건을 시작하는 부분이 됩니다. view 에 붙은 "native_korea" 라는 부분은 신경쓰지 마세요 분류하기 위한 label 일 뿐입니다.

이렇게 분리된 조건은 "pri/KR-abcd.net.zone" 이라는 bind 의 zone 파일을 로드하고 있습니다. 이 zone 파일의 내용은 별도의 설명을 하지는 않겠습니다. 표준적인 bind zone 파일이니까요. 이렇게 경우에 따라 다른 zone 파일을 로딩해서 대응하게 할 수 있습니다.

두번째 "view" 부분도 동작원리는 같습니다. 다만 JP 가 들어가있으니.. 일본에서 오는 요청에는 좀 다른 응답을 하게 되어있겠죠? 물론 KR 의 경우처럼 로딩되는 zone 파일도 다릅니다.

중요한건 세번째 "view" 부분입니다. KR 과 JP 에서 처리하지않는 나머지 영역을 "any;" 로 처리해서 기타 지역에 대한 대응을 한꺼번에 처리하고 있습니다. 이 부분을 처리해주지 않으면 KR 과 JP 에 속하지 않은 지역에는 bind 가 응답을 하지 않음으로서 기타 지역에서는 접속차단의 효과를 노릴 수도 있겠습니다만... 그런걸 원하는게 아니라면 반드시 처리해주어야 합니다. 역시 별도의 zone 파일을 읽어들이고 있습니다.

마무리

이 방법은 사실 기술적인 부분이 절대적인것을 차지하지는 않습니다. 개념적인 부분을 가지고있다면 처리하는건 그리 어렵지는 않지요. 하지만 개념으로만 안다고해서 처음부터 이방법을 도입한다는것은 쉬운일만은 아닙니다. 이외에 bind 9 부터는 GEOIP 가 도입되었습니다. 이 부분은 다음의 주소를 참고해주시기 바랍니다. 물론 bind 에 geoip 관련 패키지(?)가 포함되어 있어야 하겠죠.

• https://kb.isc.org/article/AA-01149/0/Using-the-GeoIP-Features-in-BIND-9.10.html

참고자료::glsb

• https://geti2p.net/en/docs/spec/geoip
• https://kb.isc.org/article/AA-01149/0/Using-the-GeoIP-Features-in-BIND-9.10.html
• http://iz4blue.tistory.com/entry/GSLB-Bind-GeoIP

도움주신분

• 김정환(눈빛마음)님

http 를 proxy 처리해서 서버 네트워크의 유용함을 높인다 :: nginx

서론

실제로 bind 를 이용해서 여러모로 지역망에 대한 유용성을 높인다고 가정해 보겠습니다. 이 경우 모든 서버에 다 웹서버를 실제로 설치해서 운영할것인가에 대한 부분은 의문으로 남게됩니다. 왜냐하면 관리측면에서의 문제가 있기 때문이죠. 그렇기때문에 여기서는 2 곳의 IDC 에 서버를 배치하고 다음과같은 운영구성을 한다고 가정해보도록 하겠습니다.

• A IDC : 실제 서버들이 위치한곳. database 또는 web server 등
• B IDC : proxy 를 운영하는 곳. 이 IDC 와 상성이 좋은 지역만 B IDC에서 트래픽을 받은다음 A IDC 로 넘기고.... 다른지역은 A IDC 에서 바로 서비스한다.

이런정도의 운영계획을 가지고 있다고 할때 B IDC 에 nginx 를 이용한 proxy 를 구축하는것은 여러면에서 유리합니다. 게다가 nginx 는 realip 라는 module 을 가지고 있으므로 A IDC 의 서버구성에서 realip 관련된 후처리를 해준다면 사용자의 IP 를 이용한 모니터링까지 문제없이 처리할 수 있습니다.

구현

nginx 에 원래 들어가있는 기능을 이용하는 것이기 때문에 구현은 그리 어렵지 않습니다. 이 부분도 예제를 먼저 제시하고 설명을 진행하는 방식으로 하겠습니다.

upstream www.abcd.net {
        ip_hash;
        server 보내야할서버의IP(A-IDC):보내야할서버의PORT(A-IDC);
}


server {
        server_name abcd.net www.abcd.net;

        location ~* {
                proxy_pass http://www.abcd.net;
                proxy_http_version 1.1;
                proxy_set_header Connection "";
                proxy_set_header X-Real-IP       $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
}

보다시비 구성은 간단합니다. 특정 domain 으로 온 내용을 특정 IP 의 특정 port 로 보내버릴뿐이죠. 물론 이 과정에서 X-Real-IP 부분이 설정되어있지 않다면 사용자의 IP 를 A IDC까지 보낼 수 있는 방법이 없기때문에 이 부분을 설정해주는것은 매우 중요합니다. 이렇게 설정하면 A IDC 에서는 기존에 하던대로 처리만 해주면 그만입니다. 물론 realIP 에 대한 후처리는 이 문서의 대상이 아니기때문에 별도로 설명하지는 않도록 하곘습니다.

SSL 관련된 참고사항

ssl 관련된 내용은 별도로 취급해야 합니다. ssl 은 proxy 서버쪽에 인증서를 심고 사용자의 browser 와 proxy 사이를 ssl 로 인증하고 뒤쪽을 http 로 통신하는 방법이 있고, 사용자와 proxy 는 http 로 처리하고 proxy 와 뒤쪽의 서버 사이를 ssl 로 암호화 시키는 방법이 있습니다. 추후에 내용이 정리되면 추가로 정리하는것으로 하겠습니다. 참고한 URL 은 다음과 같습니다.

• http://serverfault.com/questions/583374/configure-nginx-as-reverse-proxy-with-upstream-ssl
• http://nginx.com/blog/nginx-ssl/

참고자료::upstream proxy

• http://nginx.org/en/docs/http/ngx_http_upstream_module.html
• http://nginx.org/en/docs/http/load_balancing.html
• http://www.yongbok.net/blog/nginx-reverse-proxy/
• https://opentutorials.org/module/384/4328

추가내용

20150519 현재 cookie 관련된 issue 가 있습니다. 테스트중인 상황입니다.

image 서버를 위한 load balancer : keepalived

서론

많은 분들이 HA 를 구성하기 위해서 여러가지 솔루션을 사용하고 있습니다. haproxy 등이 그중 하나인데요. 저는 linux 의 lvs 를 이용한 keepalived 를 사용하기로 했습니다. 일단 주변분중에 아는분이 이걸 이용해서 구성하고 계셨기때문이 제일 크겠죠.

사실 web site 의 트래픽.. 또는 일반적인 서비스 운영에 있어서 DDOS 공격이라도 당하지 않는한 가장 많은 외부 트래픽을 발생시키는건 바로 이미지입니다. 용량도 크거니와 cpu 는 안먹는 주제에 대역폭을 빨아먹는 일등공신이죠. 게다가 이미지서버가 한쪽에서 http session 을 차지하고 있으면 이만큼 골치아픈 존재도 없습니다. 그래서 제 경우는 image 서버를 위한 로드밸런싱을 테스트서버군에 도입하기로 마음먹었습니다.

서버의 구성은 이 문서의 제일 앞에서 보았던 서버구성도를 참고하시면 됩니다. lvs-keepalived 를 이용한 로드밸런서가 앞에 있고 nat 네트워크를 이용해서 뒤쪽의 서버가 httpd 로 구성되어 있죠. lvs 서버는 뒤쪽으로 넘겨주는 역할만을 하고 뒤쪽에 있는 2개의 httpd 서버가 실제 처리를 하는 역할이 됩니다. 물론 2개의 httpd 서버는 앞서 설명한 lustre 를 이용한 공유저장장소를 참조하게 됩니다.

요구사항

이 구성을 하기위해서는 lvs 서버에 몇가지 요구되는 부분이 있습니다. 이 문서를 읽는분은 미리 점검해주셔야 합니다.

• kernel 에 lvs 관련된 module 이 있어야 할것
• kernel 에 ip forward 관련된 module 이 있어야 할것
• keepalived 서버소프트웨어

저는 물론 서버를 gentoo linux 로 사용하기때문에 별다른 어려움없이 software 의 설치를 진행하였습니다. 다음의 명령어를 이용해서 서버소프트웨어를 설치하면 됩니다.

emerge keepalived

ipv6 의 use flag 는 굳이 사용하지 않아도 상관은 없습니다.

load balancer 의 설정 :: keepalived.conf

설정내용을 표시하고 필요한 부분을 알아봄으로서 사용자에게 필요한 설정을 살펴보겠습니다.

! Configuration File for keepalived

global_defs {
   notification_email {
     경고를받을이메일주소(ex:aaaa@gmail.com)
   }
   notification_email_from 경고를보내는이메일주소(ex:aaaa@abcd.com)
   smtp_server 메일서버의IP주소
   smtp_connect_timeout 30
   router_id LVS_IMG
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 관리용비밀번호
    }
    virtual_ipaddress {
        공용IP
        NAT에서LVS가운용하는IP
    }
}

virtual_server 공용IP 운영할PORT {
    delay_loop 6
    lb_algo rr
    lb_kind NAT
    nat_mask 255.255.255.0
    persistence_timeout 60
    protocol TCP

    # sorry_server 192.168.0.x 80

    real_server NAT뒤의서버1 운영할PORT1 {
        weight 1
        HTTP_GET {
            url {
              path /
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }

    real_server NAT뒤의서버2 운영할PORT2 {
        weight 1
        HTTP_GET {
            url {
              path /
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }

}

길기도 하지만 현재 운영되고있는 서버의 설정을 가져와봤습니다. 실제로 참고해야할 내용은 그리 많지 않습니다. 차근차근히 살펴보겠습니다.

제일 위쪽에 global_defs 부분이 있습니다. 이 부분은 keepliaved 가 운영되며 문제가 생겼을때에 경고메일을 보내는데에 대한 설정값을 정의하고 있습니다. 이 경우 SMTP 주소는 이 서버에서의 접근에 대해서는 public 으로 풀려있는것이 좋습니다. keepalived 는 smtp 에 대한 별도의 인증방법을 제공하지는 않습니다. keepalived 에 대한 별도의 관리시스템을 가지고있지 않다면 주의해서 세팅하는것이 좋지만 이 문서의 뒤에서는 zabbix 라는 서버관리 솔루션을 소개할것이기때문에 굳이 smtp 서버의 설정에 대해 여기서 다루지는 않습니다.

vrrp_instance 부분은 keepalived 에서 관리하는 instance 를 의미합니다. 내용을 간단하게 살펴보자면 다음과 같습니다.

• interface 에서는 eht0 을 정의하고 있습니다. 물론 lvs 가 작동하는 시스템에서 다른 이더넷카드를 통해 요청이 들어오는 경우라면 해당되는 카드의 이름을 적어주면 됩니다.
• priority 는 우선순위를 의미합니다. 100 은 기본값습니다.
• virtual_ipaddress 부분에서 가상 IP 를 관리하는 일종의 그룹을 정의합니다. vrrp 는 프로토콜 규격으로서 vrrp 를 이용하는 서버를 묶어서 HA 를 구성할 수 있게 해줍니다. lvs 자체의 HA 구성을 의미하는것이 되겠죠. 크게 신경쓸 필요는 없습니다. 위의 설정파일에 적혀있는대로 정의하시면 됩니다.

virtual_server 부분이 NAT 뒤쪽으로 관리되는 서버에 대한 내용을 정의하는 부분입니다. 필드가 의미하는 바는 다음과 같습니다.

• lb_algo : 로드 밸런싱의 알고리즘을 의미합니다. 정의된값은 라운드로빈(round robine) 입니다.
• lb_kind : 운영방식을 의미합니다. NAT 방식으로 운영할것이기 때문에 NAT 를 사용합니다.
• persistence_timeout : 종료대기값을 의미합니다. 너무 짧으면 web session 을 사용하는경우 session 이 전송중에 끊어질 수 있습니다.
• real_server : 실제 운영될 서버를 하나하나 정의해줍니다. 서버의 사양이 서로 다를수도 있기때문에 그런경우는 값을 조절해서 각 서버에 적당한 부하가 가도록 처리할 수 있습니다.
  • weight : 서버에 가해지는 부담의 정도를 의미합니다. 숫자가 높은쪽에 더 높은 비율로 접속을 보냅니다. 같은 숫자를 사용한다면 접속을 분산시킬대 같은 비율로 분산합니다. 비슷한 경우로 priority 라는 설정값도 사용할 수 있습니다.

이 real_server 는 keepalived 뒤쪽에 존재하며 관리되는 서버의 개수만큼 늘여서 사용하시면 됩니다. 서버의 사양이 높은경우에는 weight 값을 상대적으로 높여서 사용하시면 됩니다.

이렇게 설정한뒤에 keepalived 서버를 구동시키면 당신의 load balancer 설정은 끝이납니다. 하지만! 한가지 잊은게 있습니다. 바로 kernel 에서 ip forward 를 enable 시키는 일입니다. 다음의 명령어로 이것이 가능하게 할 수 있습니다.

echo 1 > /proc/sys/net/ipv4/ip_forward

정말로 keepalived 의 설정이 끝났습니다. 이제 동작테스트가 남았군요!

설정된 값의 동작 테스트

keepalived 가 정상적으로 동작하는지를 확인하는 방법은 매우 간단합니다. real_server 에서 관리되는 httpd 서버에 index.html 파일을 각각 내용이 다르게 생성해주시기 바랍니다. 그 후 keepalive 로 접속을 시도했을때 각각 다른 index.html 파일의 내용을 확인할 수 있다면 당신은 keepalived 의 설정에 성공한 것입니다. 이제 httpd 를 원하는대로 세팅해서 사용하시면 됩니다.

참고자료::keepalived

• http://www.keepalived.org/pdf/UserGuide.pdf
• http://blog.woosum.net/archives/802/
• http://dewnine.tumblr.com/post/92621509210/keepalived
• http://www.hugmi.com/?node=linux&detail=keepalived
• http://malsik2004.tistory.com/entry/VRRP-%EC%99%80-LVS%EB%A5%BC-%EC%9D%91%EC%9A%A9%ED%95%9C-keepalived-%EC%84%A4%EC%B9%98-%EB%B0%8F-%EC%84%A4%EC%A0%95
• http://iz4blue.tistory.com/entry/LVS-Linux-Virtual-Server-Keepalived

도움주신분

• 김정환(눈빛마음)님

서버모니터링시스템:zabbix

왜 zabbix인가?

사실 서버를 관리하는 도구는 여러가지가 많습니다. zabbix 의 도입을 검토하기전에 서버의 proc 과 df 등으로도 충분한 관리가 가능한데 굳이 이런 시스템을 써야하느냐는 의심도 솔직히 있었죠. 하지만 우연한 기회에 zabbix 로 서버를 관리하는 광경(?) 을 보고나서 한번쯤 배워두면 반드시 쓸만하겠다...라는 생각이 들기 시작했습니다. zabbix 에서 관리하는 cpu 의 load.. 그리고 process 의 모니터링 및 하드디스크의 용량관리만이 아니라 스크립트를 잘 짜면 패키지의 update 상황까지 살펴볼 수 있는걸 보고 "이거다" 싶었습니다. 아직도 잘 쓰지는 못하고 있습니다만.. 하지만 일단 설치를 해야 써볼수도 있는법. 여기서는 기본적인 개념과 설치법을 알아보고 어떤식으로 서버를 zabbix 에 넣는가 정도를 살펴보도록 하겠습니다.

zabbix 의 구성요소

zabbix 의 구성요소는 다음과 같습니다.

• zabbix agent : zabbix 가 모니터링 해야할 각 서버에 daemon 형태로 동작합니다. 이 문서에서 설정하는 방법은 서버에서 각 client 로 모니터링해야할 역할을 내려주는 방식으로서 agent 를 통해 모니터링 데이터를 받기때문에 agent 는 반드시 기억해주는것이 좋습니다.
• zabbix server : zabbix server 는 그 자체로 다른 client 들의 데이터를 받아서 모으는 역할을 하는 server daemon 과 zabbix 에서 모인 데이터를 모니터링 할 수 있게 해주는 web client 부분으로 나눌 수 있습니다. daemon 은 설치가 어렵지 않으나 web client 는 php 로 구성되어 있기때문에 설치시 별도의 주의가 필요합니다. 이 문서에서는 postgresql 을 통한 설치를 기반으로 합니다. 관련된 부분은 반드시 참고해주시고 postgresql 자체의 설치를 설명하는 문서는 아니므로 database 에 대한 보안은 문서를 읽는 사용자가 별도로 신경써주셔야 합니다.

이 문서는 제 취향에 따라 gentoo linux 에서의 설치를 기본으로 하고 있습니다. 때문에 모든 설명은 gentoo linux 기준으로 이루어집니다. 다른 플랫폼을 사용하시는 분은 상황에 맞게 설치하셔야 합니다.

zabbix agent 의 설치

gentoo linux 의 경우에는 몇개의 USE FLAG 를 조절하면 간단하게 설치할 수 있습니다. 다음과같은 명령어로 설치할 수 있습니다.

USE="agent snmp -postgres -oracle -server -mysql -frontend -sqlite -java" emerge -pv zabbix-2.2.8.ebuild

설치된 agent 는 일단 zabbix 서버가 설치될때까지 뒤로 미뤄놓도록 하겠습니다. 어차피 서버 daemon 이 작동되지 않으면 agent 는 접속할곳이 없어서 아무것도 하지 못하거든요. 그럼 이제부터 본 게임인 zabbix 서버설치를 진행해보도록 하겠습니다.

zabbix server 의 설치

gentoo linux 에서 zabbix server 를 설치하기 위해서는 다음과같은 명령어로 설치를 진행하면 됩니다.

USE="exif sysvipc gd sockets truetype fpm mhash pdo sharedmem zip xmlwriter bcmath xmlreader curl frontend agent snmp postgres server ssh frontend libxml2 -oracle -mysql -sqlite -java" emerge zabbix-2.2.8.ebuild

관련되어 필요한 모든 프로그램들이 설치가 될건데 물론 여기서는 nginx 를 기반으로 진행합니다. 이렇게 필요한것들이 설치된 이후부터는 설치된것들에 대한 설정을 잡아야 합니다. nginx 와 사용하기 위해서는 php-fpm 은 기본입니다. 이제 php-fpm 의 설정을 먼저 잡아보도록 하겠습니다.

php-fpm 의 설정

gentoo 에서는 여러개의 php 버전을 사용할 수 있습니다. 그래서 eselect 라는 툴로 관련된 php 버전등을 지정해줄 수 있죠. 혹시 모르니 돌다리를 두들겨보는 심정으로 짚어보겠습니다. 이 글을 읽는 당신의 gentoo 에 php 가 하나만 설치되어있다면 다음의 명령으로 당신의 php 세팅상태를 점검할 수 있습니다.

localhost ~ # eselect php list fpm
  [1]   php5.5 *

아.. php-fpm 환경은 php 5.5 로 잘 지정되어있군요. 다른 php 버전이 설치된것도 없으니 이제부터 php-fpm 의 설정파일을 살펴보도록 하겠습니다. 아래 파일의 맨 아래쪽에 다음과같은 내용을 넣어줍니다.

file:///etc/php/fpm-php5.5/php-fpm.conf

[zabbix]
user = nobody
group = nobody

listen = /var/run/zabbix.socket
listen.owner = nobody
listen.group = nobody

pm = dynamic
pm.max_children = 4
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 4
php_value[post_max_size] = 16M
php_value[max_execution_time] = 500
php_value[max_input_time] = 300

이유는 잘 모르겠습니다만.. 인터넷에서 찾은 권장사항입니다. 이걸로 zabbix 관련된 php-fpm 설정은 끝났습니다. 이제부터는 zabbix 를.. 제대로 "설치" 해보도록 하곘습니다.

zabbix web client 의 설치

gentoo 에서는 web progoram 들도 하나의 패키지로 간주해서 별도의 관리방법을 권장하고 있습니다. 유지보수라면 모르겠습니다만.... 새로 설치인데 알게 뭡니까 다음의 명령어를 이용해서 zabbix web program 을 설치해보도록 하겠습니다.

webapp-config -s nginx -I zabbix 2.2.8 -d zabbix

아.. 간단합니다. 물론 web server 는 nginx 로 설정을 해놓았죠. 이렇게 하는경우 zabbix 관련된 내용은 다음의 디렉토리로 설치됩니다.

/var/www/localhost/htdocs/zabbix

아.. 쉽죠? 역시 젠투는 쉬운것 같습니다. 알아서 다 해주는듯 합니다. 유지보수는 알바 아닌거죠. 일단 이런 방법으로 설치하면 나중에 client 를 제거하는경우에도 webapp-config 을 사용하면 됩니다.

이제 php 파일들이 들어갔고.. php-fpm 의 설정도 끝났으니 nginx 에서 이후 설정을 진행해야 할 때입니다.

zabbix 를 위한 nginx vhost 설정

경우에 따라 틀립니다만 저는 개인적으로 nginx 의 추가 설정파일을 별도의 파일로 빼고 그걸 nginx.conf 에 include 로 넣는 방법을 좋아합니다. 다음처럼 말이죠.

file:///etc/nginx/nginx.conf

include /etc/nginx/01_zabbix_vhost.conf;

네... 이렇게 설정파일을 별도로 빼놓고 관리하면 여러개의 설정을 보다 효울적으로 관리할 수 있습니다. 이제 zabbix 를 위한 nginx 설정을 살펴보도록 할까요?

server {
        listen 8080;
        access_log  /var/log/nginx/zabbix.log;
        error_log  /var/log/nginx/zabbix.error;
        root /var/www/localhost/htdocs/zabbix;
        index index.php index.html;
        client_max_body_size 10m;
        client_body_buffer_size 512k;

        location ~ \.php$ {
                fastcgi_pass unix:/var/run/zabbix.socket;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param SCRIPT_NAME $fastcgi_script_name;
        }

        location ~*  \.(jpg|jpeg|png|gif|css|js|ico)$ {
                expires max;
                log_not_found off;
        }

        location ~ /\.ht {
        deny all;
        }

        location ~ /\. {
        deny all;
        }
}

네 역시 별다른 내용은 없습니다. 특이한거라면.. 8080 port 로 접속을 받아내고 home directory 가 /var/www/localhost/htdocs/zabbix 여야 한다는점 뿐이군요. 이정도까지 했으면 이제 서버에서 잡아야 할 기본 설정은 다 잡았다고 생각하셔도 됩니다. 이제 일반적인 설정은 끝났습니다. 마지막으로 zabbix server daemon 에 대한 설정만이 남았습니다.

zabbix server daemon 의 설정

역시 그리 복잡하지 않습니다. 다음의 파일의 아래쪽에.. 내용을 참고해서 넣어주기만 하면 됩니다.

file:///etc/zabbix/zabbix_server.conf

ListenPort=10051
DBHost=localhost
DBName=zabbixdb
DBUser=zabbix
DBPassword=zabbix
StartPollers=10
CacheSize=128M
HistoryCacheSize=128M
TrendCacheSize=64M
HistoryTextCacheSize=128M
Timeout=30
ListenIP=0.0.0.0

사실 큰 의미는 없습니다. 어차피 postgresql 은 이것만 가지고는 안되거든요. 하지만 그래도 눈여겨볼것이 있습니다. database 관련된 기본값들이죠. 안쓰이는건 아니니까 미리 설정을 해두도록 하겠습니다. 설정이 끝났으면 다음의 순서대로 daemon 을 실행시켜 보도록 하겠습니다.

/etc/init.d/zabbix-server start
/etc/init.d/php-fpm start
/etc/init.d/nginx start

모두 ok 가 떨어진다면 일단은 성공입니다. 이제부터는 zabbix 의 프로그램 설치가 아니라.. "설정" 단계로 들어가야 합니다.

zabbix 시스템의 설정

위쪽에서 해킹등을 대비해서 zabbix 로 들어가는 경로를 8080 port 로 잡았습니다. 당신이 사용하는 웹브라우저를 이용해서 홈페이지를 열어주세요. 그러면 database 를 postgresql 을 선택한경우.. 손으로 sql 을 넣어주라는 메시지가 나옵니다................(야!)

자.. 이제부터 다시 삽질 시작입니다. 서버로 향하는 터미널을 여시고 어디에 있는 sql 파일을 써야하는지를 찾아봅시다. 바로 여기있군요!

/usr/share/zabbix/database/postgresql/images.sql
/usr/share/zabbix/database/postgresql/schema.sql
/usr/share/zabbix/database/postgresql/data.sql

이미 저는 당신이 postgresql 에 zabbix 에 필요한 database 를 생성했을거라고 가정하고 있습니다. 아직 하지 않았다면 얼른 해주세요 그리고 다음의 명령을 진행해주면 됩니다.

psql -U zabbix -W -d zabbixdb -f /usr/share/zabbix/database/postgresql/schema.sql 
psql -U zabbix -W -d zabbixdb -f /usr/share/zabbix/database/postgresql/images.sql 
psql -U zabbix -W -d zabbixdb -f /usr/share/zabbix/database/postgresql/data.sql

이렇게 sql 파일로 zabbix 에서 사용하는 기초 table 을 모두 생성한다음에 다시 zabbix 의 web page 를 열어보겠습니다. 아까와는 다른 화면이 나오는군요. 알려주는 순서대로 차근차근히 따라하다보면 zabbix web program 의 설정은 끝나게 됩니다.

zabbix agent 의 설정

지금까지 우리는 zabbix 의 server,web client 를 설치하고 설정했으며 agent 를 설치했습니다. 이제 서버로 데이터를 보내줄 agent 를 설정할 차례입니다. 아래의 파일을 살펴보도록 하겠습니다. 이번에는 필요한 부분들이 흩어져있으니 하나하나 짚어가 보도록 하지요.

/etc/zabbix/zabbix_agentd.conf

agentd.conf 라는것을 주의해주시기 바랍니다. 여기서는 agent daemon 을 설정하는 상황입니다. 주의해야할곳은 다음과 같습니다.

• Server=127.0.0.1
  • agentd 가 접속하는 서버를 지정하는 항목입니다. IP 가 localhost 군요. 네 맞습니다. zabbix server 에 설치된 agent 입니다.
• ServerActive=127.0.0.1
  • 아직 제가 내공이 없어 정확한 의미는 잘 모릅니다만.. 이번의 세팅에서는 Server 와 같은 값을 주었습니다.
• Hostname=Zabbix server
  • zabbix web client 에서 나중에 서버를 추가하고 관리할때 참고로 사용되는 이름입니다. 너무 이상한 이름을 줘서 식별하기 힘들게 지정하지는 않도록 합니다. 그리고 web 에서 다시 모니터링용 이름은 지정할 수 있기때문에 약어수준으로 작성해도 무방합니다.

zabbix agentd 의 설정은 이것으로 끝입니다. 설정이 다 되었다면 agent daemon 을 시작해보도록 하겠습니다.

/etc/init.d/zabbix-agentd start

말끔하게 시작되었다면 agentd 의 설정도 끝났다고 간주해도 괜찮습니다.

zabbix 에서 진행하는 서버 모니터링

지금까지 우리는 zabbix 서버와 web, 그리고 agentd 를 설정해서 agent 가 모니터링하는 데이터를 zabbix 서버로 전송하게 하는것까지는 성공했습니다. 지금부터 해야할일은 이렇게 서버로 전송된 데이터를 zabbix 시스템에 등록시키고 모니터링 항목을 지정해서 실제 모니터링이 가능한 상태로 만드는 일입니다. 지금부터는 문자로만 설명할 수 있는 부분이 아니기때문에 스크린샷과 함께 설명을 진행하도록 하겠습니다.

zabbix web 에 처음 접속하면 다음과 비슷한 화면을 볼 수 있을겁니다. 물론 저는 이미 세팅을 해놓은 상태라 초기상태의 zabbix 보다는 여러가지를 확인할 수 있겠습니다만.... 곧 여러분의 zabbix 도 비슷한 화면을 보실 수 있을거라 생각합니다.

서버를 zabbix 에 등록하기

zabbix 의 agent 를 server 에 연결을 시켰다고 해서 web 에서 볼 수 있는건 아닙니다. 이렇게 연결된 서버를 모니터링 시스템의 대상으로 등록하는 과정이 필요하죠. 여기서는 이 등록과정에 대해 단계별로 알아보도록 하겠습니다.

스크린샷에서 볼 수 있듯이 다음의 menu 로 들어가도록 합니다.

• Configuration > Hosts

물론 당신의 화면에는 아무것도 나타나있지 않을겁니다. 등록된 서버가 없을거니깐요. 화면 오른쪽 구성의 "Create host" 버튼을 눌러보겠습니다. 다음과 같은 화면을 확인하실 수 있을겁니다.

자.. 지금의 단계에서 중요한건 "HOSTS" 탭과 "Templates" 탭입니다. 일단 "HOSTS" 탭부터 살펴보기로 하겠습니다. 필드별로 따로 볼까요?

• Host name : agentd 의 설정파일에 등록한 이름입니다. 기억나시나요? "Hostname=Zabbix server" 부분 말이에요. 이건 식별자입니다. zabbix 시스템에서 agent 를 식별하는 식별자로서 사용되는거죠.
• Visible name : zabbix 시스템에서 "보여지는이름" 입니다. 비워놓으면 "Host name" 을 사용하게 됩니다.
• Groups : 전문적으로 쓰게된다면 몇가지가 더 있겠습니다만.. 기본적으로 "Linux Servers" 를 선택하시면 됩니다.

이제 "HOSTS" 탭에서 설정해야 할건 끝났습니다. 이제부터는 "Templates" 탭을 살펴보도록 하겠습니다. 스샷과 동일한 화면을 보고게신가요?

"Link new templates" 부분에서 당신이 원하는 템플릿을 검색해서 추가해주도록 합니다. "HOSTS" 탭에서는 zabbix 시스템에서 어떻게 agent 를 식별하고 취급할것인가를 설정한다면 "Templates" 탭에서는 당신이 관리하기 윈하는 agent 의 관리항목을 정하는 부분이라고 보시면 됩니다. zabbix server 를 보자면...

• Template App Zabbix Server
• Template OS Linux

이 2개정도의 항목을 추가해주시는게 추천할만한 기본값인듯 합니다. 이 이후에 "Save" 버튼을 눌러주면 당신의 zabbix 시스템에 원하는 agent 의 추가작업은 기본적으로 끝나게 됩니다. 참고로 등록된 서버는.. 실제 zabbix 시스템에서 취급하게되는 시점까지 조금의 시간이 필요합니다. 잘 되지 않을때는 최대 10분정도 기다려주시는것을 권장합니다.

추가한 서버를 모니터링하기

이제 추가한 서버에서 데이터가 제대로 들어오는지를 보기위해서 다음의 menu 로 접근합니다.

• Monitoring > Latest data

agent 에서 들어오는 데이터를 제대로 볼 수 있다면 일단 agent 와 server, 그리고 zabbix web client 가 모두 정상적으로 동작한다는 의미가 됩니다. 화면의 우측 상단을 봐주시기 바랍니다. Host 부분에 당신이 추가한 서버가 있는걸 볼 수 있습니다. 서버는 보이는데 스크린샷처럼 데이터가 뜨지 않는다면 아직 agent 를 통해서 모니터링을 위한 자료가 덜 확보된겁니다. 이 부분은 기다리면 해결되는 부분이니 안심하시기 바랍니다.

일단 뭐라도 설치를 했으니 한번 볼까요? 아래쪽을 스샷처럼 열어서 아무항목이나 "Graph" 를 클릭해봅니다. 그럼 다음과 비슷한 그래프를 보실 수 있을겁니다. 그래프 내용이 별로 없다구요? 당연하죠.. 누적인데.... 그래프가 뜨는게 확인되면 모니터링 시스템은 정상적으로 작동된다고 보셔도 됩니다.

이제 좀 더 멋진 모니터링을 진행해보도록 할까요? 다음의 menu 로 들어갑니다.

• Configuration > Screens

이 화면에서 우측 상단 구석의 "Create Screen" 버튼을 눌러줍니다. 스크린샷처럼 항목을 정할 수 있습니다. 생성할 스크린의 이름과 행,열 의 개수를 정할 수 있습니다. 원하는 값대로 입력하고 "Save" 버튼을 누릅니다. 그러면 뭔가가 비어있는 화면을 볼 수 있습니다. 그 화면에서 아주작은 "+" 을 눌러보세요. 그러면 다음과같은 화면을 볼 수 있습니다.

여기에서는 해당되는곳에 삽입할 그래프를 정하게 됩니다. 그래프의 타입과 그래프의 이름.. 그리고 크기등을 정할 수 있죠. 화면에 보이는것처럼 저는 eth0 의 네트워크 상태를 모니터링 하기로 했습니다. 이런식으로 원하는 그래프들을 다 세팅하면... 어디서 확인하면 될까요? 맞습니다.. 확인은 "Monitoring" 섹션에 있죠.

• Monitoring > Screens

당신이 세팅을 제대로 했다면 이와 비슷한 화면을 볼 수 있습니다. 이 화면에서처럼 여러개의 agent 서버중 원하는 서버의 원하는 모니터링값을 지정해서 이렇게 그래프로 볼 수 있죠. 이게 바로 zabbix 를 이용한 서버군의 모니터링입니다.

정리

이외에도 zabbix 에서는 필요한 조건으로 지정해서 email 로 보내준다던가, 서버의 모니터링 방법을 스크립트로 정의해서 지정하는 방법등이 있습니다만... 이런것들은 이 문서에서 다루는것이 아니기때문에 별도로 학습을 하시기 바랍니다. zabbix 를 이용한 모니터링은 다른 시스템에 비해 비교적 체계적이며 여러 방법을 제공해주기때문에 사용자에게 유용한 방법이 될거라 생각합니다.

참고자료::zabbix

• http://iz4blue.tistory.com/entry/zabbix
• https://www.zabbix.com/documentation/2.2/start
• https://www.zabbix.com/forum/showthread.php?t=40564

도움주신분

• 김정환(눈빛마음)님

광고배너 운영시스템이 필요하다:revive

서론

제가 운영하고 있는 사이트는 지금도 자체적으로 banner 관리기능을 가지고 있습니다. 다만 이렇게 만들어진 기능이 클릭수/노출수 등을 알 수가 없어서 어떻게 해야하나 고민하고 있던차에 revive 라는 솔루션을 알게되었습니다. revive 는 이렇게 단순히 배너에 대한 통계만을 관리하는것이 아니라 그 자체로 광고들을 관리하는 광고플랫폼으로서의 기능까지 합니다.

revive 를 위한 기본 소프트웨어

revive 는 zabbix 와는 다르게 postgresql 을 지원하지 않습니다. 그렇기 때문에 php 에서 사용할 수 있는 mariadb(mysql)가지 설치가 되어줘야 합니다. 물론 php 와 더불어 nginx 를 사용할것이기 때문에 php 는 zabbix 쪽에서 설명한것처럼 php-fpm 으로 동작해야 합니다.

일단 mariadb 를 설치하도록 합니다.

emerge mariadb

그리고 php 를 설치하도록 합니다. 물론 mariadb(mysql)을 지원할 수 있게 설치되어야 한다는건 당연하겠죠?

USE="exif sysvipc gd sockets truetype fpm mhash pdo sharedmem zip xmlwriter bcmath xmlreader curl frontend agent snmp mysql libmysqlclient -postgres server ssh frontend libxml2 -oracle -sqlite -java" emerge php

revive 는 gentoo 의 rule 에 맞추어 운영될것입니다. 다음의 사이트에서 소스를 받아 아래의 경로에 압축을 풀어줍니다. 물론 디렉토리가 없다면 만들어야겠죠. 이정도쯤 되었으면 저는 여러분이 미리 nginx 정도는 설치했을거라고 믿습니다.

• http://www.revive-adserver.com/

cd /var/www/localhost/revive/
tar xzvf revive-adserver-3.2.0.tar.gz

자 물론 php-fpm 이기때문에 nginx 의 설정은 잡아줘야겠죠? revive 는 zabbix 와는 다르게 굳이 php-fpm 을 위한 별도설정은 잡지 않아도 됩니다.

file:///etc/nginx/01_revibe_vhost.conf

server {
        listen 8080;
        access_log  /var/log/nginx/revive.log;
        error_log  /var/log/nginx/revive.error;
        root /var/www/localhost/revive/;
        index index.php index.html;
        client_max_body_size 5m;
        client_body_buffer_size 128k;

        location ~ \.php$ {
                fastcgi_pass unix:/var/run/revive.socket;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param SCRIPT_NAME $fastcgi_script_name;
        }

        location ~*  \.(jpg|jpeg|png|gif|css|js|ico)$ {
                expires max;
                log_not_found off;
        }

        location ~ /\.ht {
        deny all;
        }

        location ~ /\. {
        deny all;
        }
}

zabbix 때와 크게 다를바 없는 nginx 설정입니다. 다 끝나면 mariadb 를 초기화하고, revive 에서 사용하기 윈하는 데이터베이스를 생성한다음, mariadb, php-fpm, nginx 를 차례로 시작합니다. revive 설치된 서버의 web page 를 열고 지시한대로 진행을 하고나면! 당신은 다음과 같은 화면을 볼 수 있습니다.

중간에 revive 의 설정중에 site 의 domain 을 결정하는 부분이 있습니다. 이 부분은 공백으로 놔두지 마시고 운영하실 사이트에서 사용하게될 이름을 필히 입력해 주시는게 좋습니다. "ad.aaa.com" 등으로 특정 domain 의 하위 domain 을 할당하는것이 제일 좋은 방법이 될겁니다.

네. 이제 당신은 revive 를 사용할 준비가 되었습니다!

revive 의 기본세팅 및 사용법

revive 를 사용할때 주의해야할 부분이 있습니다. 아래 스크린샷을 참고해주세요.

네 구석에 표시한 부분을 참고해주세요.. login 한 계정을 ad mode 로 사용해야만 원하는 배너/광고 관리를 진행할 수 있습니다. 왜 이게 안되지? 라고 생각이 드신다면 반드시 이 권한 부분을 확인해 주시기 바랍니다. 이제 배너관리를 시작해보겠습니다.

revive 에서 배너에 대한 부분은 전부 "Inventory" 탭에 모여있습니다. 해당 화면의 좌측에 나타나는 menu 를 중요한것들만 간단하게 살펴보도록 하겠습니다.

• Advertisers : 광고주를 의미합니다. 광고주는 google 등의 광고회사가 될 수도 있고 내가 직접 떼오는 광고고객이 될 수도 있습니다.
• Campaigns : 광고활동등을 의미합니다. 예를들어 광고주가 "5월가정의달" 을 기준으로 광고를 시작한다고 했을때라면 "가정의달-켐페인" 이라고 인식하면 됩니다.
• Banners : 사이트에서 뿌려지게될 배너의 내용입니다.
• Websites : revive 의 banner 를 사용하게될 사이트에 대한 정보입니다.
• Zones : 사이트에 들어갈 광고 영역을 의미합니다.

이외의 menu 는 저도 잘 모르겠습니다...... 자세한 부분은 정식메뉴얼을 참고해주시기 바랍니다.

revive:광고주 등록하기

일단 모든 banner 등록은 광고주를 등록함으로서 시작됩니다. 당신이 상업적으로 이것을 쓰던..아니면 단순히 통계 및 이벤트용으로 쓰던간에 말이죠. 일단 화면에 보이는 부분에서 "Add new advertiser" 를 눌러서 새로운 광고주를 등록하도록 합니다.

광고주에 대한 여러가지 내용들을 입력할 수 있습니다. 크게 설명해야할 부분은 없으니 스크린샷에 보이는것처럼 정보를 입력하고 "Save Changes"를 눌러서 정보를 저장하도록 합시다. 전혀 어려운 부분이 아닙니다 :D

revive:캠페인 등록하기

"Add new campain" 을 눌러서 새 켐페인을 등록하도록 합니다. 물론 여러개의 광고주를 등록했다면 바로 윗부분에서 원하는 광고주를 먼저 선택하고 진행해야 한다는점을 명심해주시기 바랍니다. 뭔가 입력값이 많습니다만.... 이 글은 revive 의 자세한 사용법을 알려주는 것이 목적이 아니기때문에 다른 부분은 사용자가 직접 찾아서 고민해주시기 바랍니다. 필요한 값을 입력했다면 아래쪽의 "Save Changes" 버튼을 눌러서 캠페인을 등록하도록 합니다.

revive:배너 등록하기

배너는 특정 광고주가 진행하는 특정 캠페인에 종속적이 되어야 합니다. 이미 우리는 앞의 과정에서 광고주와 캠페인을 등록해보았습니다. 여기서는 배너를 등록해보도록 하겠습니다. 화면에 보이는 부분에서 "Add new banner" 부분을 클릭하도록 합니다. 배너는 몇가지 스타일을 선택할 수 있습니다. 배너를 html 로 입력할 수도 있고 이미지를 upload 해서 등록할 수도 있습니다. 필요한 정보를 입력해서 배너를 생성하도록 합니다. 여기서 주의해야할건 "Weight" 항목입니다. 이게 높을수록 같은 켐페인 내에서 지금의 배너가 노출되는 빈도가 높아집니다.

이제 "Save Changes" 버튼을 눌러서 배너를 등록하도록 합니다.

revive:관리할 사이트 등록하기

왼쪽의 "Websites" 항목에서 당신이 관리하는 웹사이트의 정보를 입력해서 배너를 관리해야하는 사이트를 등록합니다. 이것 자체만으로 큰 의미를 가지지는 못하지만 이후 zone 을 관리하는데에 있어 기초정보로 사용됩니다.

revive:zone 등록하기

지금까지 당신은 광고주,캠페인,배너를 등록했고 관리할 웹사이트 정보를 등록했습니다. 지금부터는 zone 을 만들어서 실제 배너를 표시할 수 있도록 모든 정보를 모으는 작업을 해야합니다. 이제부터 왼쪽의 "Zones" 항목을 통해 웹사이트에서 노출되어야할 zone 을 설정하도록 하겠습니다.

위의 스크린샷에서 "Add new zone" 을 눌러서 새로운 zone 을 생성하도록 하겠습니다. zone 은 website 에 귀속됩니다. 요구되는 항목을 기입해서 zone 을 등록하도록 합니다.

이경우 주의할것이 있습니다 banner 의 size 와 zone 의 size 는 동일해야 합니다. 고로 size 부분은 주의해서 기입해 주시기 바랍니다.

등록된 zone 의 목록에서 원하는 zone 을 하나 선택합니다. "Linked Banners" 탭에서 이 zone 과 연결할 광고주와 캠페인을 선택한다음 화살표 모양을 선택해서 zone 과 banner 를 연결하도록 합니다.

앞의 스크린샷처럼 추가한 내용을 적용하기 위해서는 'Zone Properties" 탭으로 이동해서 아래쪽에 있는 "Save Change" 버튼을 눌러줍니다. 그렇게하면 Zone 과 Banner 의 연결까지는 성공한게 됩니다. 자 그럼 이렇게 설정된 zone 을 어떻게 사이트에 연결해야 할까요? 그건 지금 화면에서 "Invocation Code" 탭을 살펴보면 됩니다. 사이트에 넣는 코드에 따라 "Bannercode" 부분이 바뀌게 됩니다.

이렇게 해당되는 Banner code 를 사이트에 넣어주기만 하면! Banner 는 당신의 사이트에서 동작하게 됩니다.

revive 마무리

지금까지 설명한 내용 외에도 revive 는 정말로 많은 제어를 할 수 있습니다. 지금은 local banner 만 사용하고 말았지만 보셨다시피 google 광고 또는 다른 회사의 광고들을 추가하는데도 전혀 어려움은 없습니다 (Banner 부분에서 html 타입의 banner 를 추가하면 되거든요). revive 를 통해서 보다 체계적인 배너관리를 하시는데 도움이 되시길 바랍니다.

문서의 마무리

지금까지 lustre, glsb, nginx upstream proxy, lvs, zabbix, revive 에 대한 기본적인 내용들을 알아보았습니다. 이 문서는 상기 소개된 서버 다이어그램에 맞춰서 작성된 문서이므로 경우에 따라 꽤나 달라지는 부분도 있을거라 생각합니다. 하지만 전체 문서를 부분부분 생각하고 발췌해서 쓰는것도 고려해서 작업한 문서이므로 설명되는 내용을 제대로 이해하신다면 유용한 문서가 될거라 생각합니다. 길었네요.. 이제 마무리를 해야겠습니다~