레거시 시스템의 클라우드 통합

Contents

프라이빗 클라우드를 도입할 경우 기존의 레거시 시스템을 어떻게 통합할 할 것인지를 고민해야 한다. 기존의 레거시 시스템과 독립적으로 클라우드 환경을 구축하거나 혹은 레거시를 모두 클라우드 환경으로 이전하는 방법이 있을 것인데, 전자의 경우는 시스템 통합 측면에서 그림이 예쁘지 않고 후자는 (소프트웨어적인 특성등으로)불가능하거나 기술적으로 어려울 수가 있다.

가장 좋은 그림은 기존의 레거시 시스템을 존중하면서, 클라우드 환경에 통합시키는 것이다. 데이터베이스라든지 공유스토리지등 클라우드에 올리기 힘든 시스템은 그대로 살리고, 클라우드 환경에서 이를 이용하고 통합관리할 수 있는 시스템을 구축하는 것이다.

따라서 (레거시 시스템을 포함한)프라이빗 클라우드는 아래의 요소들로 구성이 된다고 가정할 수 있다.

1. 클라우드 운영체제 : CloudStack, OpenStack 내가 사용해 본 것은 이정도.
2. 베어메탈 호스트 : (주로 성능상의 이유로 혹은 가상화 환경은 왠지 견고하지 않을 것 같다는 이유로)VM으로 올리기는 껄끄러운 서비스들이 있을 테다. 이들은 베어메탈 호스트에서 운용한다. 베어메탈 호스트도 클라우드 환경에 통합하는 걸 원칙으로 한다. 따라서 (마치 VM 처럼)자동으로 프로비저닝되고 상태관리가 가능해야 한다.
3. 레거시 시스템 : 데이터베이스, NAS, 스토리지등의 서비스들이다. VM 혹은 베어메탈 호스트에서 레거시 시스템 자원을 활용할 수 있도록 네트워크 구성이 돼야 한다.
4. 네트워크 통합 : L2, L3 장비 제어는 고려하지 않는다. 이들은 물리적인 환경과 너무 밀접하게 엮어있어서 소프트웨어적으로 추상화하기엔 너무 많은 이슈들이 있다. L4 장비 레벨에서의 NAT, Load balancing 서비스를 제어하는 것까지를 목표로 한다.

이들 구성요소를 클라우드 환경에 잘 버무려 넣는게 목적이다. 클라우드 도입전 인터넷 서비스를 하고 있었다면, DMZ 네트워크를 구성해서 WAS와 데이터베이스등의 시스템을 인터넷으로 부터 분리했을 것이다라는 걸 전제로 문서를 전개하고자 한다.

네트워크 구성은 다음과 같다고 가정한다.

1. DMZ에는 퍼블릭 네트워크로 연결된다. 웹서버와 같은 웹 애플리케이션이 위치한다.
2. Security Area는 퍼블릭 네트워크로 부터 보호해야 하는 데이터베이스, WAS, Storage server 등이 위치한다.
3. Management network가 있다. 관리를 위해서 사용한다. IPMI나 Cloustack API, 관리자 전용의 ssh, DHCP, PXE-BOOT등의 트래픽이 흐른다.

시스템은 2개 이상의 NIC을, Storage 트래픽을 분리하기를 원한다면 3개의 NIC을 가지고 있어야 할 것이다. 다음은 위의 구성을 단순화한 그림이다. 아래 그림을 바탕으로 설계를 확장해 나갈 수 있을 것이다.

각 POD는 lack에 대응한다. Lack 대신 POD라고 쓴 이유는 순전히 개인적인 이유로 클라우드 스택의 zone / pod 개념에 익숙하기 때문이다. POD에는 L2 swtich가 있을 것이고, 이 L2 switch는 다시 L3 switch로 연결될 것이다. L3 switch는 하나 이상의 L2 switch와 연결될 수 있는데, L3 switch 밑에 있는 POD과 모든 노드들은 L2 영역으로 묶이게 된다.

매니지먼트 네트워크를 구성할 때는 염두에 둬야 할 점이 하나 있다. VM을 올리기 위한 CNODE의 경우에는 매니지먼트 네트워크까지 연결해도 상관이 없겠지만, Baremetal NODE(이하 BNODE)의 경우에는 보안을 고려해야 한다. 매니지먼트 네트워크는 DMZ와 Security area모두에 연결돼 있으므로 일종의 백도어로 작동할 수 있기 때문이다. 하긴 베에머탈 노드를 매니지먼트 네트워크에 연결하는 경우도 흔치 않기도 하다.

다음과 같이 정리할 수 있다.

• Management 망에는 SSH, Chef, Puppet, 모니터링 등의 트래픽이 흐른다.
• CNODE는 management 망에 연결된다.
• BNODE는 management 망에 연결되지 않는다. 다만 auto provisioning을 위해서 IPMI 포트로 연결해야 한다. IPMI 포트는 매니저먼트 망 사이에 위치한다.

베어메탈 노드 구성은 따로 다루도록 한다. 클라우드 운영자는 요구에 따라서 L4 장비를 컨트롤해서 NAT와 LB 서비스를 자유롭게 배치할 수 있어야 한다. 어떤 장비를 선택해야 할까 ? 모든 L4 장비는 NAT와 LB를 대동소이한 기능으로 서비스하기 때문에, 기능은 선택사항에서 제외해도 될 것이다. 가장 중요한 선택 기준은 클라우드 애플리케이션을 개발하기 위한 충분한 API를 지원하는지 이다.

아마도 Citrix의 "Netscaler"가 가장 무난한 선택일 것이다. Citrix는 클라우드스택을 개발하는 회사 답게, 클라우드스택 에서 Netscaler의 모든 기능을 제어할 수 있도록 API를 제공한다. 이 API를 이용해서 운영자(혹은 클라우드 개발자)는 네트워크 서비스 솔류션을 개발할 수 있다.

클라우드스택 매니지먼트 서버의 위치를 생각해 보자.

어떤 네트워크모드로 구성하느냐에 따라 달라진다. Basic network 모드로 구성할 거라면, L3 네트워크로 구성해야 할 것이고, Advanced network 모드로 구성할 거라면 L2 네트워크로 구성해야 할 것이다.

각각 네트워크에 대해서 모두 고민해 봐야 겠는데, 일단은 Advanced network 모드의 tagged valn 타입의 구성을 고민해 보려고 한다.

위치는 DMZ와 Security area 모두에 클라우드스택 매니지먼트 서버를 두는 방법을 생각할 수 있다. 서로 분리되는 네트워크라는 관점에서 보면 두개의 매니지먼트 서버를 두는게 합리적인 구조로 보일 수 있다. 하지만 관리 포인트가 많아진다는 문제점이 있다. 개발이 가능하다면, 클라우드스택 API를 이용하는 또다른 매니지먼트 서버를 두는 방법도 있다. JCloud, DeltaCloud등의 솔류션을 이용해서 클라우드 소프트웨어 관리 레이어를 하나 더 두는 방법을 생각할 수 있다.

각 area에 독립된 클라우드스택 매니지먼트 서버를 둔다면 다음과 같이 구성할 수 있을 것이다.

• API Management server : Cloudstack을 관리하는 서버다. 매니지먼트 망을 이용, 클라우드스택 API를 호출해서 클라우드를 관리한다.
• 매니지먼트 망 : 빨간색선으로 관리 트래픽이 흐른다.
• Zone : 클라우드스택의 zone이다. L3 switch가 하나의 zone이 되며, 스위치에 묶인 POD들은 같은 L2 네트워크로 묶인다. 각 POD에는 L2 switch가 놓인다. zone과 zone 혹은 다른 network area 사이의 통신은 L3 스위치를 거치므로 데이터 통신에 문제는 없다.

이렇게 구성하면, DMZ의 클라우드스택 zone에 web service를 두고, Security area에 WAS나 데이터베이스 서버를 두는 구성이 가능할 것이다.

위의 구성에서 어카운트 VM은 RVM(소프트에어 라우터)을 통해서 퍼블릭 네트워크로 나가게 되는데, RVM을 거치면서 성능이 떨어진다는 문제가 있다. RVM의 성능누수와 성능 한계는 실 서비스에서는 문제가 될 수 있는 수준이다.

두 가지 방법으로 문제 해결이 가능하다.

1. Basic network 모드로 구성 : Basic network 모드는 L3 네트워크 구성으로 VM이 직접 퍼블릭 네트워크에 연결된다. 따라서 RVM에 의한 성능저하가 없다. 문제는 Basic network 모드의 기능이 충분하지 않고, 검증역시 충분하지 않다는 점이다. 처음에 advanced network 모드에 주로 개발역량을 집중했기 때문이다. 클라우드스택3에서는 basic network 모드 개발에도 신경을 쓰는 모양인데, 본격적으로 사용하기에는 이른 감이 있다.
2. Multi nic 구성 : 클라우드스택을 이용해서 VM에 multi nic을 할당할 수 있다. 추가한 nic를 network area간 트래픽 통로로 사용하면, advanced network 모드로 1번과 동일한 효과를 누릴 수 있을 것이다. 멀티닉 구성에서는 관리자가 VM에 접속해서 route 설정을 변경해야 한다는 점은 부담일 수 있다. 운영체제 네트워크 설정을 관리자영역으로 본다면 별 문제 아닐 수 있는데, 이런 설정도 자동화가 된다면 좋을 것이다. chef client를 주기적으로 실행하는 방법으로 (적용하는데 시간이 걸리긴 하지만)설정 자동화가 가능하긴 하다.

멀티 닉을 이용한 구성

베어메탈 호스트를 클라우드 환경에 통합해야 하는 필요를 생각해 보자.

1. 성능문제로 VM대신 베어메탈 호스트에 서비스를 올리려 한다.
2. 애플리케이션 문제로 베어메탈 호스트에 서비스를 올려야만 한다.

웹 서버는 VM으로 올리고 데이터베이스 서버는 베어메탈로 구성해서 연결하는 경우도 있을 테고, 서비스의 모든 구성요소들을 베어메탈로 구성하는 경우도 생각해 볼 수 있다.

베어메탈 시스템도 POD 구성을 따를 것이다. 이 POD은 베어메탈 호스트만을 위한 POD으로 TOR(Top of rack)스위치와 베어메탈 호스트의 구성을 가진다.

네트워크 구성은 아래의 두 가지 타입이 있다.

1. L2 network로 구성한다. NAT로 퍼블릭 네트워크에 연결한다.
2. L3 network로 구성한다.

1 번의 경우 아래의 구성을 가질 것이다. BPOD는 Baremetal POD이다.

1. BPOD는 각각 L2 switch를 가진다.
2. BPOD는 L2 집선 switch에 연결된다. L2 network 구조에서 Baremetal zone은 L3 집선 스위치단위로 정의할 수 있다. Baremetal zone에 있는 모든 베어메탈 호스트는 하나의 L2 네트워크로 묶인다.
3. 베어메탈 호스트들은 사설 IP를 가진다.
4. L4 장비를 이용해서 NAT를 한다. L4 장비는 Network area에 대한 LB 서비스 용도로도 사용할 수 있다.

2번 구성은 L2 집선 스위치 대신 L3 Switch가 사용된다는 걸 제외하면, 1번과 동일한 구성을 가진다.

1. BPOD는 L3 switch를 가진다.
2. L3 네트워크 이므로 NAT 서비스가 필요없다. L4 장비는 Load Balancer로 사용된다.

굳이 NAT를 이용한 서비스(1번 방식)을 선택할 필요가 있느냐라는 물음이 있을 수 있다. 1번 방식을 선택했을 때 가질 수 있는 장점은 베어메탈 네트워크를 사설 네트워크로 구성해서 퍼블릭 네트워크로 부터 분리할 수 있다는 점 정도일 것이다. 음 딱히 장점이 없는 것 같다. 그냥 이런 구성도 가능하다 정도로 넘어가면 될 것 같다.

베어메탈 프로비저닝에 대한 문서는 PING을 살펴보기 바란다. 하지만 PING는 LVM, ext4를 지원하지 않으며 프로젝트도 거의 중단된 상태인것 같다. 그냥 PING과 같은 솔류션을 직접 만드는 걸 추천한다. Knoppix live cd를 이용하면, 프로비저닝 솔류션을 (비교적)쉽게 개발할 수 있을 것이다.

베어메탈 프로비저닝 방식은 크게 두 가지로 나눌 수 있다.

1. kickstart, Windows DS(windows deployment service)를 이용한 방법. 여기에 chef를 올려서 초기 운영체제 설정과 애플리케이션 설정까지 관리한다.
2. 운영체제 Image 복사. 클라우드스택에서 VM image 템플릿을 이용해서 VM을 생성하는 것과 동일한 방식. Image를 베어메탈에 복사한다는게 유일한 차이점이다. Chef가 설치된 운영체제 image를 만들어서, 설정관리까지 할 수 있다. PING가 사용하는 방식이다.

개인적으로 2번 방식을 선호한다. 1번 방식의 경우 리눅스 운영체제만을 프로비저닝 한다면 문제될게 없는데, 윈도우 운영체제까지 프로비저닝 할 경우 구현이 복잡해지기 때문이다. Kickstart와 DS를 클라우드환경에 함께 묶을 생각을 하면, 벌써부터 머리가 아프다. 베어메탈 프로비저닝 기능을 포함하는 클라우드 소프트웨어들도 2번 방식을 주로 사용한다. (운영체제가 리눅스만으로 구성된다면, 당연히 1번 방법이다.)

자 2번 방법을 사용하기로 했다. 운영체제 이미지를 자동으로 프로비저닝하기 위해서 리마스터링한 knoppix 라이브 cd를 사용할 것이다. 베어메탈 호스트를 IPMI 혹은 iLO를 이용해서 파워를 올리면, PXE-Boot를 knoppix 라이브 cd로 부팅할 것이다. 이제 ssh로 라이브 cd에 접속해서 운영체제 이미지를 (dd 등을 이용해서) 하드디스크에 복사하면 된다.