과거에는 다중 클러스터 및 스토리지 시스템을 생성·관리하기 위해 다수의 매니지먼트 툴을 사용해야만 했다. 하지만 레드햇 엔터프라이즈 리눅스5에 새로 추가된 웹 기반의 애플리케이션 콩가(Conga)는 각각의 스토리지 시스템 및 클러스터 노드에 설치하고 개별 관리해야 하는 불편함을 덜어준다. <편집자>

양승도 // 레드햇코리아 차장syang@redhat.com

리소스 활용과 장애 복구
대다수의 기업들은 IT 비용 절감을 위해 랩을 통합해 공간 및 전력 비용을 최소화하고 시스템 관리 프로세스를 자동화해 관리 비용을 줄이는 등의 방법을 시도한다. 또한 작은 서버들의 대수를 줄이고 블레이드 서버를 늘려 하드웨어 비용을 절감하고, 마침내는 가상 기계로의 교체를 생각하게 된다.
가상화는 미션 크리티컬한 애플리케이션을 비롯해 다수의 소프트웨어가 가상 기계 상에서 구동될 수 있도록 해줌으로써 개발자를 비롯해 CIO들에게 없어서는 안 될 기능이 됐다. 이렇듯 가상화는 비용 절감 및 성능 측면에서 완벽하지만, 만약 누군가 모든 가상 기계가 호스팅되고 있는 서버의 코드를 밟고 넘어져버렸다면 어떨까? 이 가상 기계 중에는 고객들과 직접 관련이 있는 애플리케이션을 지원하는 기계가 있을 수도 있고 기업의 인벤토리 컨트롤 시스템이 구동되고 있는 기계가 있을 수도 있는 일이다.
실제 서버 클러스터링에서와 마찬가지로 가상 기계 동작에 있어서도 페일오버는 빼놓을 수 없는 중요한 부분이지만 기존의 가상화에서는 이 부분에 대해 간과해 왔다.

다중 클러스터와 스토리지 시스템 관리 툴
과거에는 다중 클러스터 및 스토리지 시스템을 생성·관리하기 위해 다수의 매니지먼트 툴을 사용해야만 했다. 하지만 레드햇 엔터프라이즈 리눅스5에 새로 추가된 웹 기반의 애플리케이션 콩가는 각각의 스토리지 시스템 및 클러스터 노드에 설치하고 개별 관리해야 하는 불편함을 덜어준다.
콩가는 스토리지와 클러스터를 지원하기 위해 개발된 일종의 GUI 애플리케이션으로, 레드햇 클러스터(red-hat-cluster), 시스템 컨피그 클러스터(system-config-cluster), 디플로이 툴(deploy-tool), 시스템 컨피그 LVM(system-config-LVM) 들과 같은 툴들의 기능을 지니고 있다.
스토리지 클러스터 개발 담당 이사 케빈 앤더슨은 “콩가는 초기의 X/Gtk 관리 애플리케이션의 문제점을 해결해준다. 사용자들은 우리가 제공하는 인터페이스를 사용하는 도중에 종종 서버에 X나 Gtk 라이브러리 등을 설치하라는 메시지를 받게 된다. 콩가는 서버에서 동작하는 에이전트를 제공, 웹 인터페이스를 통해 관리함으로써 이러한 문제를 해결해준다”고 말했다.

콩가의 특징은 다음과 같다.
* 전체 클러스터 및 스토리지 관리 작업에서의 단일 웹 인터페이스
* 클러스터 데이터의 자동 디플로이 및 패키지 지원
* 기존 클러스터와의 쉬운 통합
* 클러스터의 상태(status)와 로그의 통합
* 사용자 제한을 통한 철저한 컨트롤

먼저 콩가의 구동 원리와 기본 기능을 살피보자.

아키텍처 개괄: Luci와 Ricci가 만났을 때
다음은 콩가의 아키텍처를 나타낸 다이어그램이다.
-이 아키텍처는 다음과 같은 구성요소로 이뤄져 있다. luci는 다중 클러스트 관리에 있어 중심 포인트 역할을 하는 애플리케이션 서버로 유저 정보와 노드 데이터베이스를 유지한다. Luci 서버에 ricci 인증을 마치고 나면 인증이 폐기되지 않는 이상 다시 인증을 받을 필요가 없어 하나의 luci 서버가 전체 클러스터에 관여한다.
-Ricci는 운영 중인 모든 서버에 설치되는 에이전트이다.
-웹 클라이언트는 파이어폭스와 같은 브라우저로 네트워크 상에서 구동된다.

웹 클라이언트가 luci 서버에 로그온 했을 때, 관리자는 웹 인터페이스를 통해 진행중인 노드 상에서 실행될 ricci 에이전트에 커맨드를 내릴 수 있다.

콩가 시작하기
엔터프라이즈 리눅스 5 패키지에 luci 설치 시 데이터베이스는 초기화되며 관리 계정이 설정된다. 이 작업은 luci_admin 커맨드 라인의 유틸리티를 통해 이뤄지며 일련의 작업을 끝낸 후 luci 서비스가 시작된다.
로그인 후 관리자 웹 인터페이스의 홈베이스 탭에서 클러스터, 스토리지 시스템, 유저 정보를 등록할 수 있으며 다른 탭 들은 클러스터 및 스토리지 시스템 상의 관리 작업을 지원해준다.

콩가와 클러스터: 기존 클러스터에 접근
먼저 기존의 클러스터를 실행한다. 이때 luci에서 기존의 클러스터, 혹은 접근 불가능한 노드가 있는 클러스터 관리에 실패했을 시 기존의 클러스터에 있는 모든 노드를 설치해야 한다.
웹 인터페이스에 있는 ‘홈베이스’ 탭에서 ‘기존 클러스터 등록’(Add an Existing Cluster)옵션을 선택하면 다음과 같은 화면이 나타난다. 클러스터의 노드명을 입력하면 luci는 해당 노드에 접속해 클러스터 정보를 검색한다.
‘확인’을 누르면 luci는 클러스터에 있는 노드를 확인하고 다음과 같은 화면이 나타난다. 처음 입력한 노드가 인증됐음을 알 수 있다.
패스워드를 입력해 폼을 완성한 후, 다른 노드를 위해 ‘클러스터 추가’를 누르면 luci의 데이터베이스에 클러스터가 추가 된 것을 볼 수 있다.
일부 클러스터 데몬이 구동되지 않는 등 클러스터 노드에 문제가 생길 시 해당 노드가 적색으로 표시된다.

콩가와 클러스터: 새 클러스터 생성
콩가를 이용해 새로운 클러스터 생성 시, 노드는 콩가로 관리돼 온 기존의 클러스터의 노드와 같은 조건을 충족시켜야 한다. 예를 들어 모든 노드는 ricci 에이전트 소프트웨어를 설치해야 하고, 접근 가능해야 하며 루트 패스워드를 통해 인증 받아야 한다. 하지만 접근 불가능한 클러스터에 몇 가지 노드를 설정하고 싶다면 일단 제외하고 클러스터를 생성한 후 접근 가능할 때 클러스터에 추가 할 수 있다.
클러스터 생성의 첫 단계는 클러스터 네임 설정 및 클러스터를 구성할 노드를 선택하는 것이다. 클러스터 탭에서 “새로운 클러스터 생성”을 선택해 필요 정보를 입력한다.

글로벌 클러스터 속성(Global Cluster Properties)
클러스터 생성 및 환경 설정은 cluster-specific 페이지에서 이뤄진다. 전체 클러스터 속성을 관리하는 인터페이스의 기능을 하는 이 페이지에서 클러스터 네임 아래의 네 가지 탭(General, Fence, Multicast, Quorum Partition)을 이용해 환경 설정을 할 수 있다. 이 탭들의 매개변수 구성방법은 다음과 같다.

1. General tab : 이 탭에는 클러스터 네임 및 설정 버전, 고급 클러스터 속성 등이 포함돼 있다.
ㆍCluster Name에서 네임은 변경할 수 없다. 새로운 클러스터 구성을 생성하고 새로운 네임을 지정하는 것 외에는 변경할 수 있는 방법이 없다.
ㆍConfiguration Version은 기본설정이 1로 돼있으며 이 숫자는 클러스터 설정을 변경할 시 마다 자동으로 증분된다.
ㆍ‘Show advanced cluster properties’에서는 고급 클러스터 속성을 확인할 수 있으며 각 속성에 대해 온라인 문의가 가능하다.

2. Fence tab : 이 탭에서는 Post-Fail Delay와 Post-Join Delay로 나뉘는 Fence Daemon Properties를 볼 수 있다.
ㆍPost-Fail Delay의 매개변수는 펜스 데몬이 노드 운영 실패 후 노드를 펜싱하는데 걸리는 시간이다. Post-Fail Delay 의 기본값은 0으로 클러스터 스위트와 네트워크 성능에 따라 변한다.
ㆍPost-Join Delay의 매개변수는 펜스 데몬이 노드가 펜스 도메인에 합류 된 후 노드를 펜싱하는데 걸리는 시간이다.

3. Multicast tab : 멀티캐스트 구성을 보여주는 탭으로 멀티캐스트 어드레스를 선택하고 수동으로 지정할 수 있다. 레드햇 클러스터 소프트웨어는 클러스터 노드 간의 클러스터 매니지먼트 커뮤니케이션을 위한 멀티캐스트 어드레스를 선택한다.(기본 셋팅은 ‘Let cluster choose the multicast address’이다.) 특정 멀티캐스트 어드레스를 사용하고자 할 때는 수동으로 지정하기를 선택해 텍스트박스에 어드레스를 입력할 수 있다.

4. Quorum Partition tab : 여기에는 ‘Do not use a Quorum Partition’이 기본으로 셋팅돼 있으며, ‘Use a Quorum Partition’을 선택해 쿼럼 디스크를 사용할 수 있다.

콩가와 스토리지 시스템
클러스터 관리 외에도 같은 웹 인터페이스를 이용해 스토리지 시스템도 관리할 수 있다. 사용자 계정을 설정해 일정 사용자만 특정 스토리지 시스템에 접근할 수 있도록 제한하는 한편, luci 관리자로서 스토리지 시스템 네임과 패스워드만 입력하면 새로운 스토리지 시스템을 추가할 수 있다. 다음의 화면과 같이 스토리지 시스템의 접근을 제한할 수 있다.
예를 들어 ‘jsmith’가 luci에 접속했을 때 이 사람은 스토리지 시스템 ‘tng3-3’에만 접근할 수 있는 식이다. 관리자로 접속했을 시에는 모든 스토리지 노드를 볼 수 있어 luci에서 관리되는 스토리지 시스템을 통해 디스크 파티션, 로지컬 볼륨 그룹, RAID 파일 시스템 등을 관리할 수 있다. 또한 웹 인터페이스를 통해 시스템 로그를 검색할 수 있다.
하나의 클러스터가 luci 서버에 추가되면 해당 클러스터의 모든 노드 또한 스토리지 시스템에 추가된다. 만약 스토리지 시스템에서 일부 클러스터 노드를 관리하고 싶지 않을 땐 luci에서 개별 스토리지 시스템을 삭제해도 클러스터 관리 기능은 유지된다. 또한 콩가에서 사용된 스토리지 시스템 계정과 패스워드는 기존 시스템이나 클러스터 계정의 계정과 패스워드에 추가된다. 콩가에서의 계정 및 패스워드 설정은 기존 시스템 계정에 영향을 미치지 않는다.

어드밴스드 플랫폼에서의 자동 페일오버와 가상 게스트의 복구
RHEL 5 어드밴스드 플랫폼이 가상 기계 환경에서 제공하는 페일 오버 기능은 다음과 같이 설명할 수 있다. 그림과 같이 세 개의 머신에 각 두 개씩의 엔터프라이즈 리눅스 게스트가 있다고 가정했을 때, 기존에는 서버다운 시 관리자가 조치를 취해야 했지만 어드밴스드 플랫폼은 다운된 서버를 자동 추적해 A와 B 게스트가 두 개의 서버에서 자동으로 실행되도록 구성돼 있다.
관리자가 왼쪽 머신의 문제를 해결하고 나면 두 개의 게스트는 원래의 시스템으로 돌아가 동작하게 되는데 이것이 제로 다운타임 장애 복구의 한 예로 볼 수 있다. 가상 게스트가 빠른 시간 안에 자동으로 동작될 뿐 아니라 구성을 리밸런싱 하는 동안 애플리케이션의 중단이 없다.
어드밴스드 플랫폼의 클러스터 파일 시스템인 GFS2는 블록 레벨을 제공하는 머신의 성능을 높여준다. /guest_roots GFS2 파일 시스템에는 구성요소를 비롯해 게스트 부트 이미지가 저장돼 있어 라이브 마이그레이션을 수행하는 것 외에도 모든 머신에서 게스트를 실행할 수 있게 한다. Et-virt05, et-virt06, and et-virt07는 guest1, guest2, and guest3를 가상호스팅 하는 실제 머신이다.

페일오버의 예제 보기
스텝1: 클러스터 생성
콩가는 웹 기반 관리 인터페이스를 가지므로 클러스터 생성이 간편하다. 같은 서브넷에 있는 머신 상에서 콩가에 로그인 해 ‘새 클러스터 생성’ 페이지를 찾아 ‘공유 스토리지 사용’을 선택하면 패키지를 설치해 클러스터를 세운다. 이때 전체 네트워크에 루트 패스워드을 입력하게 된다.
승인하게 되면 머신은 재 시작함과 동시에 클러스터가 생성된다. 이제 게스트 구성과 부트 이미지 파일을 담고 있는 공유 파일시스템을 생성해 보자.

스텝2: 가상 게스트 관리를 위한 공유 공간 생성
Cluster Logical Volume Manager(CVLM)는 전체 머신의 볼륨 관리를 제공해 공유 파일 시스템 내 스토리지의 연산, 스트라이핑, 미러링, 확장이 가능하도록 한다.
먼저 스토리지 탭을 열어 머신을 선택한다. 여기에서는 et-virt05를 선택했다.
볼륨 그룹은 파일시스템의 생성을 위해 준비했던 공간의 로지컬 스토리지 구역이다. 로우 파티션 대신 볼륨 그룹을 사용함으로써 공간 확보가 필요할 때 볼륨 및 파일 시스템을 확장할 수 있게 된다.
볼륨 그룹 생성 후, CLVM은 리부트 되는 머신 세트상에 공용 네임을 제공하게 되며, 공유 공간으로 쓸 수 있는 100GB 상당의 볼륨 그룹이 생성된다. 특히 /dev/sdd2 and /dev/sdg2 배열에서 2개의 LUN을 이용해 볼륨을 생성할 수 있다. 디폴트로 4MB의 확장 사이즈를 사용할 수 있으며 volume group guest_vg라는 네임을 준다. 이것은 공유 스토리지 이기 때문에 클러스터 상태를 ‘true’로 지정한다. 이때 서버 타임은 ntp 서버와 같은 공유 소스에 맞춰주는 것이 가장 좋다.
‘New Logical Volume’을 선택해 세부 파일 시스템 설정을 시작해 보자. 로지컬 볼륨과 파일 시스템 간에는 일대일 상관 관계가 있으므로 GFS2를 파일 시스템으로 선택한다. 각 게스트의 루트 볼륨에는 6GB가 요구되며 파일시스템은 guest_roots로 지정해 로지컬 볼륨 네임 및 파일시스템 네임, 마운트 포인트에 같은 네임을 부여할 수 있다. 이제 fstab 엔트리가 생성돼 부팅 시 마운트 설정을 셋팅할 수 있다.

스텝 3: 가상 게스트를 공유 공간으로 옮기기
이제 생성된 게스트들을 공유 공간으로 이동 시킬 것이다. 가상 머신의 생성 보다는 구성요소에 알맞은 셋팅을 위한 가이드이다. 새로운 게스트를 생성하기 위한 가장 쉬운 방법은 Virt-manager를 이용해 디스크 이미지를 공유 공간에 두는 것으로 여기에서는 /guest_roots를 예를 들어보겠다. 사용 중인 시스템이 네트워크 환경이어야만 게스트로 연결되는 네트워크 브릿지를 생성할 수 있다.
게스트 구성 후 구성 파일은 /etc/xen에 생성되는데 여기에서는 /etc/xen/guest1이 그것이다. 이 파일을 공유 공간에 두기 위해서는 파일을 디스크 이미지 바로 옆 /guests_root로 카피하면 되는데 이 때 구성요소를 수정하기 위해서는 /etc/xen 구성 파일이 공유 공간에 재복사돼야 한다.

스텝 4: 클러스터로 게스트 컨트롤 하기
이제 클러스터 관리 하에 게스트를 컨트롤 할 수 있게 되었다. 여기에는 게스트 OS를 시작하는 것에서부터 시스템 다운시의 재부팅 및 머신 장애 시 다른 노드로의 페일오버 등이 포함된다. 이 셋팅은 다음의 순서를 따른다; ‘Xen 사용하지 않음, 게스트 시작, 라이브 마이그레이션으로 전환, 클러스터 관리로 게스트 컨트롤 사용’의 순서를 따른다.
먼저 실제 머신 부팅 시 게스트를 시작하게 하는 Xen 스크립트를 사용하지 않도록 설정한다. 각 서버에 다음 명령을 실행한다.
하나의 머신에서 다른 머신으로의 라이브 마이그레이션이 이뤄지도록 한다. 각 머신을 /etc/xen/xend-config.sxp로 편집하고 두 개의 재배치 라인을 해제한 뒤 xend-relocation-server를 ‘yes’로 설정한다.
가상 게스트 관리를 클러스터에 둔다. 클러스터 관리는 웹 서비스나 데이터베이스 혹은 이 경우에서와 같이 가상 머신 서비스에 적용된다. 클러스터상에 있으므로 게스트 OS가 어디에서 어떻게 시작되는지 알아보자. 이 작업은 먼저 페일 오버 도메인을 설정하는 것으로 시작된다.
우선순위를 정할 필요가 없다. 하나의 머신만 지정하고 나면 나머지 머신들은 동등하게 동작되므로 “Prioritized”를 체크하거나 Priority 필드를 셋팅할 필요가 없는 것이다. 어느 머신에서나 게스트가 적용될 수 있도록 하기 때문에 도메인의 멤버에게만 페일 오버를 제한하지 않아도 된다. 여기에서는 세 개의 페일오버 도메인 구성을 ‘bias-et-virt05’, ‘bias-et-virt06’과 ‘bias-et-virt0’으로 지정했다.
다음은 가상 서비스 엔트리를 생성한다. 사용자가 원하는 자동실행 서비스와 페일 오버 도메인, 복구 정책 등의 공유 공간(/guest_roots)과 게스트 네임(guest1)을 입력한다.
‘Update Virtual Machine Service’를 클릭하면 클러스터 관리 상에 게스트가 생성된다. 실행 중이 아니더라도 바로 시작될 수 있다. 초록색으로 표시된 부분이 실행 중인 게스트이고 status에는 현재 동작 중인 실제 머신을 보여준다.

스텝 5: 페일 오버 및 복구 확인
이제 다양한 상황에서의 셋업과 시스템 응답을 확인해 볼 차례이다. 먼저 하나의 머신에 ‘xm destroy’ 명령을 실행해 게스트 크래쉬 상황을 시뮬레이션한 후 실제 머신 중 하나에 로그인 하여 게스트를 삭제해 볼 것이다.
이제 클러스터 중 하나의 머신을 재부팅해 실제 머신의 장애 상황을 시뮬레이션해 보자. 콩가는 게스트의 상황과 위치를 제공하게 되며, guest1이 et-virt05에서 실행 중임을 확인한다.
et-virt05에 로그인 후 리부팅 하면 복구가 시작된다. 이 때 et-virt05없이 guest1이 et-virt07에서 실행 중임을 볼 수 있을 것이다. et-virt05가 리부팅 된 후, 같은 화면에서 guest1이 et-virt05로 다시 마이그레이션 되는 작업을 선택할 수 있다.

명령어들
　[root@et-virt06 ~]# chkconfig xendomains off
　[root@et-virt06 ~]# service xendomains stop

　(xend-relocation-server yes)
　(xend-relocation-port 8002)

[root@et-virt06 ~]# xm list
Name......................................ID.Mem(MiB).VCPUs.State...Time(s)
Domain-0...................................0.....1505.....8.r-----...6972.4
guest2.....................................5......499.....1.-b----.....21.0
[root@et-virt06 ~]# xm destroy guest2
[root@et-virt06 ~]# xm list
Name......................................ID.Mem(MiB).VCPUs.State...Time(s)
Domain-0...................................0.....1505.....8.r-----...6975.7
[root@et-virt06 ~]# xm list
Name......................................ID.Mem(MiB).VCPUs.State...Time(s)
Domain-0...................................0.....1505.....8.r-----...6988.7
guest2.....................................6......499.....1.-b----.....17.7

데이터넷