요즘엔 클라우드 관련 일을 하느라 정신이 없습니다. 정리도 하는 겸 몇자 적어보렵니다.

클라우드라고 하면 요즘은 일종의 패션인 것 같다. 그리고 이 단어 자체가 의미하는 것으 뭐랄까 여러 가지가 있어서 가끔 이야기하다가 헷갈린다. DropBox, Evernote, Daum 클라우드 등.. 이런 서비스형 클라우드가 있는가 하면 Amazon Web Service, RackSpace, uCloud Server등 컴퓨팅 클라우드 최근에는 빅데이터 관련에도 클라우드라는 말을 사용한다.

저는 이중에 컴퓨팅 클라우드와 관련된 일을 하고 있습니다. aws와 같은 public computing cloud service를 어떻게 하면 잘 그리고 효율적으로 만들 수 있을까를 고민하고 있습니다. 그리고 당연히 private computing cloud service도 고민하고 있죠.

따라서 이제부터 말하는 클라우드는 컴퓨팅 클라우드가 되겠습니다.

그럼 클라우드는 왜 필요한가 하면, 대표적인 서비스인 aws의 예를 들면 아마존은 원래 전자상거래 사이트입니다. 그래서 트래픽이 특히 몰리는 추수감서절 같은 때를 대비하여 컴퓨팅 자원을 많이 확보해 놓습니다. 당연히 대목을 잡아야지요. 대목에는 미리 준비한 자원을 이용해서 장사를 잘 했습니다.

그런데 대목이 끝나고 보니까 많이 준비해놓은 컴퓨팅 자원이 놀기 시작합니다. 실상 컴퓨터(대부분의 서버도)를 모니터링 해보면 컴퓨팅 자원을 완전히 다 쓰고 있지 않고 놀고 있는 자원이 많다는 것을 알 수 있습니다. 이게 아마존 사장의 눈에 뜨인 겁니다. 노는 자원을 어떻게 할용해 볼까 고민고민하다가 눈에 띄인게 가상화 기술이고, 이를 이용해서 노는 컴퓨팅 자원을 일반인에게 팔아보자, 서비스해 보자라는 것에서 시작한 것이죠.

즉, 컴퓨팅 자원을 효율적으로 사용하여, 불필요하게 낭비되는 비용을 줄이자가 컴퓨텅 클라우드의 시작이고, 지금도 가장 중요한 컴퓨팅 클라우드의 핵심입니다. 이런 관점에서 아래의 개념들이 나오는 것이지요.

• 컴퓨팅 자원을 빌려쓰자: IP address, cpu, memory, disk, network….
• 쓰는 만끔 지불한다: 시간 요금제
• 사용이 끝나면 반납하자: 자원의 유연한 할당, elastic computing
• 급하게 필요할 때는 빨리 빌리자: fast provisioning

여기서 가상화 기술이 아주 중요하게 나옵니다. 가상화 기술은 클라우드와 상관없이 60년대 부터 발전한 기술입니다. 하지만 위의 모든 것들을 아주 쉽게 가능하게 해주는 기술이 가상화죠. 컴퓨팅 자원들을 가상화 하지 않는다면 위의 것을 하기 위해서 사람이 엄청 열심히 일해야겠죠? 실제로 클라우드 초기에 호스팅 업체들의 주장중 하나가 “우리도 요청하면 하루 안에 사용 가능한 컴퓨팅 리소스를 제공한다. 그래서 우리도 클라우드다”라고 했었지요. 하지만 이를 이루기 위해서는 수만은 엔지니어가 고생하는 모습을 쉽게 상상할 수 있습니다.

따라서 아래의 개념이 따라옵니다.

• 모든 것은 자동화된 시스템이 제공한다.

즉 클라우드에서는 사람이 하는 일이 없습니다. 물리적인 셋업과 기본적인 가상화 솔루션이 올라간 이후에는 사용자가 자원을 요청하면 모든 것이 솔루션에 의해서 자동으로 처리됩니다. 안그러면 클라우드가 아니죠~

가상화라면 생각되는게 물리 서버(서버라고 하면 물리 기계 뿐만 아니라 서비스와 혼동하여 물리 서버 또는 호스트란 용어를 사용합니다.) 하나에 여러 논리적인 호스트를 동시에 실행하는 것이니 당연히 생각하기에도 혼자 모든 호스트의 자원을 사용할 때 보다 성능이 당연히 떨어집니다. 게임 좋아하시는 분들은 에뮬레이터 상상하시면 되겠네요. 그래서 가상화된 서버(Virtual Machine, VM, 물리 서버에서 호스팅되는 호스트) 일반적으로 성능이 좋지 않습니다. 또한 물리 서버의 제약하에서 움직이기 때문에 무한정 CPU, 메모리를 늘려 성능을 올릴 수 없습니다. 그래서 클라우드는 scale-out을 지향합니다.

• 작은 것들이 모여서 큰 일을 합니다: scale-out

구글이나 패이스북, 멀리 갈 것 없이 네이버, 다음처럼 대규모의 서비스를 하기 위해서 한대가 모든 것을 처리하지 않고 여러 서버들이 서로 힘을 합쳐서 처리하는 방식이죠. 십시일반으로 작은 VM들이 모여서 큰 규모의 처리를 합니다.

근데 또 생각해보면 작은 것들을 많이 모아서 하자니.. 미리 그 것들은 준비해 놓아야하고, 결국 요청이 없을 때는 이 가상머신이 또 노는 현상이 발생합니다. 이것은 클라우드의 효율적인 자원 활용에 맞지 않지요.

그래서 나오는 이야기들이 autoscaling입니다.

• 자원이 더 필요 할 때만 scale-out 하자: autoscaling
• 로드 밸런싱 좀 잘 해줘~: Elastic LB
• 언제 자원이 더 필요 할 지는 모니터링이 필요하다: Amazon CloudWatch

여기까지 클라우드에서 설정을 해 놓으면 사용자 트래픽이 없을때는 최소한의 VM만 유지하다가, 트래픽이 늘어나면 자동으로 VM을 늘려가면서 트래픽을 처리하는 것이죠. 이 모든 것이 관리자의 판단이 없이 미리 설정된 값에 따라서 자동으로 진행됩니다.

이런 관점에서 보면 전통적인 시스템 관리자 입장에서는 뭔가 이전과는 다른 현상들이 일어납니다. 관리하는 VM이 점점 많아지고, 게다가 이 VM이 모두 동작상태가 아닌 대기 상태일 수 있습니다. 이러다 보니 서버들 간에 패키지나 설정들의 통일성이 없어질 가능성이 높아집니다. 관리자 입장에서는 여간 곤혹스럽지 않을 수 없습니다.

그래서 나온 것이 서버의 형상관리가 필요한 것이죠.

• 서버들의 상태를 자동으로 동일하게 맞추자: chef, puppet

이러다 보니 서버 관리의 대부분을 자동화하는 툴이 하게 됩니다. 게다가 chef, puppet들은 개발자들이 사용하던 프로그래밍 방식을 사용하여 작업하게 됩니다. 기존 서버 관리자 입장에서는 전혀 하지 않던 개발을 운영을 위해 하게 됩니다.

• DevOps: 개발과 운영은 같은거다. 운영도 개발의 일부다. 운영자도 개발해!
• NoOps: 운영. 이제 필요없다.

실제로 클라우드를 관심있게 본 시스템 운영자들은 클라우드를 밥줄을 뺏어가는 녀석으로 인식하여 적대적으로 대하는 분도 봤고, 반대로 적극적으로 클라우드 업계로 뛰어든 분도 있습니다. ^^

또 다른 운영자 입장에서의 변화는, 이전까지는 물리 서버의 IP address는 그 물리 서버에 고정된 것으로 생각하고 작업을 해왔습니다. 그런데 클라우드 자체가 리소스를 빌려 쓰는 개념이다보니, VM에 할당된 public / private  ip address는 고정이 아니고 vm을 재시작, 정지, 이동(migration)하는 경우 변경될 수 있습니다.

클라우드에서 이에 대한 해법을 제시한 것이 다음과 같습니다.

• VM에 고정된 public ip를 달란 말이다: ElasticIP

IP는 고정해서 뭔가 기본적인 요구는 해결되는 것 같은데, 호스팅 서비스처럼 나만의 서브넷을 구성하고 싶은 경우 등 전통적인 호스팅을 사용했을 때 사용했던 방법들을 사용하고 싶은 사람들이 있습니다. 클라우드는 클라우드 답게라지만, 클라우드가 해법을 제공하지 못하는 것도 많으니깐요.

• 다 좋은데, 내 맘대로 하고 싶단 말이다. : Virtual Private Cloud

쓰다보니 어째 아마존의 서비스를 나열 한 것 같습니다. 맞습니다. 아마존이 가장 먼저 대중화 했고, 현재 가장 잘 나가고 있는 컴퓨팅 클라우드고 사실상의 표준이니까요. 저희도 열심히 고민고민 하면서 아마존 보다 더 좋은 구조를 내려고 했지만, 항상 결론은 아마존이 다 그렇게 한 이유가 있었고, 결국은 아마존 방식이 가장 효율적인 경우가 많았습니다. 현재는 아마존이 최강니깐요.

그리고 마지막으로 컴퓨팅 쪽은 가상화가 기술이 이제 성숙기에 접어든 상황이라 판단이 되는데, 아직 시작도 하지 못한 부분은 있습니다. 바로 라우터, 스위치로 대표되는 네트웍이죠

• 서버만 가상화냐? 네트웍도 가상화하자! : Network Virtualization

현재 SDN(Software-defined network)라는 커다란 흐름 밑에 OpenVSwitch로 소프트웨어 적으로 컨트럴 가능한 스위치를 구성하고, OpenFlow를 이용하여 네트웍 자원은 중앙 집중 관리가 가능하게 하는 방향인 것 같습니다. OpenVSwitch는 리눅스 커널 3.3에 들어가 있고, XenServer 6.x에도 지원이 들어간다고 합니다. 아직은 성숙화 되지 않았지만, 아마 올해 말에는 본격적으로 네트웍 가상화가 화두가 될 것으로 생각하고 저희도 이 쪽에 연구를 계속할 겁니다.

원래는 글을 풀어가면서 Xen, XenServer, CloudStack, OpenStack, OpenVSwitch, OpenFlow 등으로 이어가려고 했는데, 엉뚱하게 클라우드에 대한 기본적인 설명과 용어만 나열하다 끝나네요.

munin 대신 ganglia를 검토해보려고 ganglia를 설치하려는데 아래 메시지를 내뿜으며 설치가 제대로 안된다.

Adding group: ganglia.
Adding system user: ganglia.
useradd: group ganglia exists - if you want to add this user to that group, use -g.
dpkg: error processing gmetad (--configure):
 subprocess installed post-installation script returned error exit status 9
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Errors were encountered while processing:
 gmetad
E: Sub-process /usr/bin/dpkg returned an error code (1)`

https://bugs.launchpad.net/ubuntu/+source/ganglia/+bug/854866/comments/20 에 있는데로 하고 다시 설치하면 된다.

sudo useradd ganglia -g ganglia

음.. 우분투 실망일세~~

$ apt-get install yum rpm python-m2crypto
$ mkdir -p /tmp/centos/var/lib/rpm
$ rpm -root /tmp/centos -initdb

$HOME/.rpmdb 가 만들어지는데 그거는 마지막 삭제한다.

rpmfind.net에서 원하는 버전의 rpm 찾아서 다운로드

$ wget ftp://195.220.108.108/linux/centos/5.7/os/x86_64/CentOS/centos-release-5-7.el5.centos.x86_64.rpm
$ rpm -ivh -force-debian -nodeps -root /tmp/centos centos-release-5-7.el5.centos.x86_64.rpm
$ ln -s /tmp/centos/etc/pki /etc/pki
$ yum -installroot /tmp/centos install yum
$ mount -t proc foo /tmp/centos/proc
$ mount -t sysfs foo /tmp/centos/sys

$ chroot /tmp/centos /bin/bash -login
$ rm -rf /home/choe/.rpmdb # 위에서 initdb한것 지우기
$ rpm -initdb
$ echo nameserver 168.126.63.1 > /etc/resolv.conf
$ yum install yum
$ yum install vim-minimal less

참고: http://www.lucas-nussbaum.net/blog/?p=385

Naver Platform Day 2011을 훑어보다 정리합니다.

구체적으로 사용자 측면에서 클라우드 서비스의 장점

• 자본 비용과 운용, 유지의 부담 없이 저렴하게 고기능의 정보 처리 기능을 이용할 수 있다.
• 시스템 구축, 개발 기간이 단축되고 수요 변동에 유연하고 즉각적으로 대응할 수 있다.
• 네트워크를 통해 협업, 데이터 수집, 제어가 용이하다.
• 장비 분실 등에 따른 정보 유출 위험을 감소시킨다.
• 클라우드 기반의 지속성에 의해 사업의 연속성이 향상된다.
• 사용한 비용만 청구받고 지불하면 된다.

사업자 측면에서의 장점

• 가상화, 분산 처리 기술을 활용함으로써 다양한 정보 처리 수요에 대해 자원을 효율적으로 제공할 수 있다.
• 애플리케이션 표준화를 통해 소프트웨어 자원을 효율적으로 활용할 수 있다.
• 서비스 자동화 및 지속성을 통해 운용, 보수, 갱신을 합리화할 수 있다
• 다른 클라우드 서비스를 사업자 측에 결합해 저렴한 가격으로 다양한 서비스를 제공할 수 있다.
• 사용자의 수와 상관없이 서비스를 공급할 수 있는 분산, 가상화의 특징이 있다.

결국 합리화, 최적화, 비용 절감!

쓸데없이 자원 관리하는데 노력을 들이지 말고 클라우드에 맞기고, 남는 시간에 당신의 비지니스에 집중하라~

클라우드 호스팅과 클라우드 IaaS의 차이는

• on-demand self-service로 사용할 수 있느냐?
• 사용랑 기반으로 과금하느냐?

ssh 192.168.0.24 cat /dev/zero > /dev/null

Ubuntu 11.04 natty 서버가 있는데, 여기서 rsyslog가 CPU를 100% 먹는 증상이 발생한다. syslog에 아래 메시지가 지속적으로 쌓이면서 생기는 현상이다.

Cannot read proc file system: 1 - Operation not permitted.

특정 커널과 rsyslog의 특정 버전의 조합이면 이러한 문제가 발생한다고.. 결론은 커널을 업그레이드 하단거, 아니면 rsyslog를 업그레이드 하던가…

그런데 커널을 업그레이드하면 리부팅해야하고… 돌아가는 서비스는 중단할 수 없고.. 결국은 rsyslog를 downgrade하기로 했다.

조사해보니 natty에 있는 버전은 모두 같은 버전이라 maverick으로 가기로 했다. 그래서 sources.list를 아예 maverick으로 이동..

$ perl -p -i -e "s/natty/maverick/g" /etc/apt/sources.list
$ apt-get update

그리고 어떤 버전이 있는지 확인해보고..

$ apt-cache show rsyslog | grep Version
Version: 4.6.4-2ubuntu4
Version: 4.6.4-2ubuntu4.1
Version: 4.2.0-2ubuntu8

그 버전으로 다운그레이드한다.

$ apt-get install rsyslog=4.2.0-2ubuntu8

그리고 나중에 혹시나 자동으로 업그레이드 될 지 모르니 업그레이드 금지

$ echo 'rsyslog hold' | dpkg -set-selections

스크립트로 한방

#!/bin/bash
release=`lsb_release -c | awk '{print $2}'`
if [ "$release" != 'natty' ]; then
        echo 'rsyslog download only apply to natty!'
        exit
fi

if [ `grep -c 'natty' /etc/apt/sources.list` == 0 ]; then
        echo 'something wrong in sources.list'
        exit
fi

perl -p -i -e 's/natty/maverick/g' /etc/apt/sources.list
apt-get update
apt-get install -y --force-yes rsyslog=4.2.0-2ubuntu8
perl -p -i -e 's/maverick/natty/g' /etc/apt/sources.list
echo 'rsyslog hold' | dpkg --set-selections

munin을 돌리고 있는데, 뭔가 이상한게 보인다. 그래프가 중간중간 끊기는거다… 그래 점검하는 호스트가 좀 많기로서니… 좀 힘들어한다는 느낌이 들었다.

여기저기 둘러봤지만 .. 글쎄 확실한 해결책이 없다. 결국은 perl 소스를 조금 보기로했지..

ProcessManager.pm에서 accept를 기다리는 timeout이 아래처럼 10으로 되어있는데, 간딘히 360으로 해놨다. 우선 로그보니 timeout 메시지는 안나온다.

#accept_timeout  => 10,
accept_timeout  => 360,

$ chown root.wheel /bin/su
$ chmod 4750 /bin/su
$ chattr +i /bin/su

근데 말이다.. su 명령은 아예 막고, sudo만 사용하게 하는건 어떨까?

Just bookmark

http://it.toolbox.com/blogs/enterprise-solutions/conceptual-architecture-checklist-22364

keepalived를 설정하는데 receive an invalid ip number count associated with VRID! 라는 로그가 계속 나온다. 말그대로 VRID로 받은 패킷의 IP 갯수와 설정된 IP 갯수가 다르다는데, 엇뜬 이해하기가 힘들다.

고민해보니깐.. VRID가 중복된 것 아닐까? 이 네트웍에 다른 vrrp가 동작하는 것이 아닐까하고 VRID를 바꾸니까 동작한다.

금방 바꿔서 문제를 해결했지만, 이런 문제를 사전에 인지하려면 뭔가 방법이 필요했다. 현제 네트웍에서 사용중인 VRID를 모두 알 수 없을까??? 여기저기 자료를 찾아봤지만, 이런 문제에 대한 직접적인 해결 방법은 찾을 수 없었다.

그러다가 눈에 띈게 vrrp 프로토콜은 224.0.0.18로 boradcasting한다는 사실.  그리고 keepalived에서 vrrp는 기본 설정상 1초에 1번 vrrp advertising을 한다는 것.. 라서 해당 224.0.0.18와 통신하는 것을 패킷을 보면 vrid가 나오겠구나 생각하고 해봤는데..

$ sudo tcpdump -i eth0 host 224.0.0.18
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
19:17:30.574665 IP 192.168.0.199 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 1, prio 101, authtype simple, intvl 1s, length 28
19:17:30.574676 IP 192.168.0.199 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 1, prio 101, authtype simple, intvl 1s, length 28
19:17:30.574770 IP 192.168.0.199 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 2, prio 101, authtype simple, intvl 1s, length 24
19:17:30.574773 IP 192.168.0.199 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 2, prio 101, authtype simple, intvl 1s, length 24

다행이도 생각했던 것 처럼 나온다. 그래서 아래처럼 5초 동안 VRIP를 감사하면 현재 네트웍의 VRIP가 다 나오고 여기서 없는 것으로 피해가면 된다!!

sudo timeout 5 tcpdump -i eth0 host 224.0.0.18 2>&1 | grep vrid | awk '{print $9}' | sort | uniq