클라우드 컴퓨팅 & NoSQL/IaaS 클라우드

Private Cloud 구축시 하드웨어 고려 사항

Terry Cho 2011. 1. 27. 22:17

Hardware Configuration Consideration Point II

Host Server architecture

Host Server Architecture VM 자체를 호스팅 하는 서버의 아키텍쳐를 정의한다. CPU,메모리,NIC Storage 연결 채널들이 고려 사항이 되며, Private Cloud에서 사용하는 Hypervisor의 종류와 VM의 성격 및 구성에 따라 달라지는데, 일반적으로 고려할 수 있는 Private Cloud 상의 공통 구성 사항에 대해서 검토해보면 다음과 같다.

NIC teaming

NIC teaming이란, 물리적인 다수의 NIC를 논리적인 하나의 NIC로 묶어서 대역폭을 늘리고, 물리적 NIC의 장애에 대비하는 아키텍쳐이다. Private Cloud에서는 물리적인 하드웨어 서버 하나에 여러개의 VM이 호스팅 되기 때문에, 경우에 따라서 NIC band width를 높이거나 또는 NIC 장애에 대응할 수 있는 기술이 요구 되기 때문에 NIC teaming 기술이 사용되는 경우가 많다.

NIC teaming은 하드웨어 벤더에서 제공하는 Driver를 통해서 구현되기 때문에 Private Cloud를 구축하는 Server를 선택할때, Hypervisor OS에 해당 서버의 NIC Teaming을 구성할 수 있는지 사전에 고려되어야 한다.

Standard Rack Mounted Server

서버의 타입 중 표준 19” Rack Mount 타입을 사용하는 서버로 일반적으로 2U,4U 정도의 크기를 가지고 있으며, 2 to 4 CPU 2 to 8 PCI-E or PCI-X slot, 그리고 4~6개의 RAID 지원 Disk bay를 가지고 있다. 확장이 용이하고 초기 도입 비용이 저렴하기 때문에 일반적인 Private Cloud 구성에 적절하다.


<그림 DELL Rack Mounted Server>

Blade Server

Blade 시스템은 blade chassis라는 Blade 시스템용 전용 컨테이너에 서버,네트워크 모듈,Storage 모듈 등을 Parts 식으로 삽입하여 운용하는 형태이다. 특히 Rack의 상면을 최적화할 수 있어서 상면 비용을 줄일 수 있는 장점을 가지고 있으나, Vendor 별로 제공하는 Blade 시스템에 대한 종속성을 가지고 있다.

<그림 HP Blade System >

Blade 기반으로 Private Cloud를 구성할 때 주의해야 할 점은 Private Cloud는 일반적인 Application이나 Database Server와는 달리 여러 VM이 동시에 IO (Network Disk)를 발생 시키기 때문에, 일반적인 서버 시스템에 비해서 IO에 대한 요구 사항이 높다. 이런 이유로 Blade chassis 안에 장착되는 네트워크 Switch에 대한 용량이 충분히 확보되어야 하고, 또한 SAN 구성시에 SAN Channel에 대한 대역폭도 충분히 확보되어야 한다.

여기에 더불어 Blade chassis가 외부 네트워크로 연결될 때 Rack Mounted Server의 경우 각 서버가 직접 외부 네트워크에 스위치를 통해서 연결될 수 있지만, Blade 시스템은 chassis를 통해서 서버의 트래픽이 외부 네트워크에 연결되기 때문에, chassis와 외부 네트워크의 연결점이 되는 chassis 내의 네트워크 스위치의 용량이 충분히 확보되어야 한다.

Large SMP Servers

Large SMP Server랑 일반적으로 8개 이상의 CPU 슬롯을 가지고 있는 대용량 서버를 정의한다. 물리적으로도 64개까지의 CPU N TB의 메모리를 지원하며, 하드웨어 파트셔닝이나, Hot-add of resource, hot spare component등 다양한 하드웨어 기능과 확장성을 제공한다.

Large SMP Server의 경우 수백개의 VM을 동시에 Hosting 할 수 있다.

 

<그림. HP Superdom Server>

많은 기능을 제공하는 만큼, 그만한 서버 운용 노하우를 가지고 있어야 하며, 또한 가격 또한 가장 비싸다. Rack Mounted Server의 경우 4 CPU Socket 서버의 경우 $30,000 내외이지만  32 CPU Socket의 서버의 경우 일반적으로 $500,000의 비용을 넘는다.

또한 Private Cloud의 가상화를 담당하는 Hypervisor의 용량적인 한계가 있기 때문에 이를 고려해야 한다. 예를 들어 Windows server 2008 R2 Datacenter Edition의 경우 최대 64 CPU 2TB의 메모리를 지원한다. 즉 이보다 큰 용량의 서버의 경우 하드웨어 분할을 하지 않는 이상 용량이 낭비 될 수 있다는 것을 의미한다.

Large SMP Server Private Cloud에 적용하고자 할 때에는 매우 큰 용량의 Mission Critical 업무나 또는 회사 내부에 Large SMP Server에 대한 운영 노하우를 확보하고 있을 경우에만 권장한다.

GPU virtualization

근래에 들어서 고성능의 수치해석과, 3D Rendering에 대한 영역이 수퍼컴퓨터에서 GPU를 사용하는 클러스터 기반의 컴퓨팅 영역으로 넘어오고, 가상 데스크탑(VDI)에서도 GPU 가상화를 통한 3D 게임과 3D 기반의 애플리케이션 구동, 동영상 encoding/decoding의 요구가 확산됨에 따라 Private Cloud에서도 GPU가상화가 특수한 목적에서 요구사항으로 필요하게 되었다.

그러나 일반적인 Rack mounted server 의 경우 GPU를 장착할 수 있는 PCIe/x 슬롯의 수가 부족하기 때문에 하드웨어 구성상에 문제가 많았는데, 이런 문제를 해결하는 방안중의 하나로 PCI 슬롯을 확장해주는 PCI extension rack을 고려할 수 있다.

아래는 DELL C410x PCIe Extension을 이용한 구성으로 최대 16개의 PCI 슬롯을 확장할 수 있으며 Slot Nvidia 계열의 GPU를 장착할 수 있으며, PCIe Extension은 동시에 여러 개의 서버로 연결될 수 있다.


다음은 조금 더 저가 구성인데, Magma
에서 제공하는 PCI Expansion으로 13 slot에 대한 확장 케이스를 제공하며 가격은 2,000~3,000 USD 이며, 위에서 설명한 DELL의 구성과는 다르게 하나의 Host에만 연결할 수 있다.


<그림. Magma
19” Rack Type PCI Expansion System >

GPU 확장을 위한 PCI expansion을 사용할 경우에는 추가적으로 GPU 발열에 대한 해결 방안이 사전에 고려되어야 한다.

 

Network Architecture

근래에 들어, 일반적인 서버 단의 네트워크 대역폭이 1G bps를 사용하고 서버에 2개 이상의 1G NIC를 가지고 있기 때문에 네트워크 아키텍쳐에 대한 고려가 간과 되는 경우가 많다. 그러나 일반적인 환경이 아닌 가상화 환경에서는 집적도가 높기 때문에 네트워크 아키텍쳐가 매우 중요한 요소로 간주된다.

 네트워크 구성에 있어서 SAN iSCSI를 사용할 경우 SAN용 네트워크 대역폭은 물리적으로 나누는 것이 좋다. 또한 Management용 포트와 일반 LAN에 연결되어 Application에 대한 요청을 받는 포트 역시 분리하는 것이 좋으며, 일부 많은 VM Hosting 하는 Server Gigabit 이상의 대역폭을 요구하는 경우가 있기 때문에 2개 이상의 NIC를 서비스 용으로 제공하는 것이 좋다. (서버당 4개 포트 정도가 적정 1개 관리용 3개 서비스용) 그리고 서비스용 NIC는 필요에 따라 NIC Teaming을 이용하여 하나의 논리 NIC로 묶어 주는 것도 좋은 대안이 될 수 있다.

iSCSI 사용시에는 2개 이상의 NIC를 이용하여 MPIO를 구성하여 장애와 용량 확장하는 방안을 권장한다.

마지막으로 네트워크 스위치의 용량이 전체 네트워크 트래픽을 감당할 수 있는 용량인지가 확인 되어야 한다.

 

Reference

RAID Architecture http://www.acnc.com/04_01_10.html

RAID Performance Comparison http://blog.naver.com/jjanggu327?Redirect=Log&logNo=80120878813