블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 
비용 대비해서, 클라우드의 물리 노드를 어떻게 설계할까가 고민이었는데...
오늘 이런 저런 이야기를 들어보고 사례를 보니.. 결론 은 생각보다 간단하다.

1. 블레이드 사용
공간이나, 전력면에서 블레이드가 유리하기 때문에 블레이드 사용
2. 10G NIC * 2
LAN으로 나가는 것은 10G 를 사용하되 Redundancy 구성을 위해서 2개 사용
VNIC는 관리,클러스터링,Fail Over(Live Migration),ISCSI,그리고 VM용으로 가상으로 나눠서 구성
3. FC * 2
Storage는 모라고 해도.. 결국 FC가 안정적. Redundancy 구성을 위해서 두개 사용

LAN과 SAN은 각각 2개 이상의 스위치로 이중화

비용 절감 방법은
1. Bulk Buy (Rack 단위)를 하는 방법
2. SAN 비용을 줄이기 위해서, IO Segragation을 해서 용도에 맞는 Storage Pool 분리
3. Resilency등을 이용해서, SW 클러스터링 FAILOVER 이용하여, redundancy에 소요되는 NIC를 줄이거나, SAN을 줄임. (WAS는 ISCSI 사용해도 되겄다..)

결국 기술적으로 이런거 저런거 줄일라고 해봐야... 제대로 된거 안쓰면 모 클라우드 꼴 나게된다는 결론.



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

 



Hardware Configuration Consideration Point

Private Cloud는 집적된 하드웨어 서버에 다수의 VM을 기동 시켜서 수많은 업무와 트래픽을 감당해내는 구조로 일반적인 애플리케이션 구동이나 DBMS를 위한 하드웨어 구성과는 다른 형태의 구성이 필요하다. 대용량의 IO와 대용량의 네트워크 트래픽을 지원할 수 있어야 하며, 장애에 대한 높은 대응 능력을 요구로 한다.

본 문서에서는 Private Cloud를 구축하는 데 있어서 고려 해야 하는 하드웨어에 대한 검토 사항에 대해서 설명 한다.

Storage Architecture

저장소 즉, 디스크는 Private Cloud에서 호스팅 되는 VM의 성능에 가장 큰 영향을 미치는 요인중의 하나로, 드라이버의 타입, 인터페이스,컨트롤러,캐시 프로토콜등 다양한 요인에 영향을 받으며, 성능 측정 단위는 IOPS (IO Per Second) Latency를 사용한다. 이 저장소에서 이 성능에 관련된 기술에 대해서 설명한다.

Storage Connectivity

디스크나 디스크 Array는 서버에 연결될 때 다음과 같이 3가지 방법을 이용해서 연결될 수 있다.

DAS (Direct Attached Storage)

일반적으로 생각하는 서버내의 Local 디스크를 생각하면 되고, 서버내의 SCSI,SAS,SATA와 같은 디스크 컨트롤러를 이용해서 연결된다. 물리적으로 디스크 array는 별도의 분리된 장비에 설치될 수 있지만, 마찬가지로 서버내의 내장된 디스크 컨트롤러를 이용한다.

DAS 연결 시에는 디스크 연결뿐만 아니라 일반적으로 장애에 대한 데이터 안정성 보장을 위해서 RAID 구성을 지원한다. DAS의 경우 일반적으로 하나의 Server 에만 연결되고, 여러 서버에 공유되서 사용될 수 없다.


<그림 DAS 구성 예 >

iSCSI SAN

iSCSI는 근래에 들어서 점점 많이 사용되는 아키텍쳐로 기존의 SCSI protocol TCP/IP 네트워크 위에 구현해놓은 것이다. 기존의 TCP/IP 인프라를 재활용하기 때문에, 네트워크 장비(스위치,허브등,인터페이스 카드)를 재활용할 수 있다는 장점을 가지고 있으며, Fiber Channel SAN에 비해서 상대적으로 저렴 하다는 장점을 가지고 있다. 그래서 Low~Middle 급의 Storage Array에 유용하게 사용될 수 있으며 DAS와는 다르게 동시에 여러 물리서버에 연결 되서 공유되어 사용될 수 있다.

iSCSI 인터페이스는 기존의 TCP 인프라를 사용하기 때문에, 기존 네트웍 장비를 사용할 수 있으나, Private Cloud의 공유 저장소로 사용하기 위해서는 10G 이상의 대역폭을 권장하며, 10G의 경우 iSCSI SAN에서는 SFP+ 형태의 물리 인터페이스를 지원하는 것이 일반적이기 때문에  10/100/1G에서 널리 사용하는 RJ-45 인터페이스와는 상이하기 때문에 물리 인터페이스에 대한 점검이 필요하고, 스위치와 물리 인터페이스가 상이할 경우 Transceiver를 사용하는 것을 고려해야 한다.


iSCSI 구성은 TCP를 지원하는 스위치가 필요한데, 스위치 선택시 고려해야 하는 사항은 10G 포트가 충분한지, 10G 포트의 물리적 인터페이스(SFP+,RJ-45)가 무엇인지, 그리고 스위치의 허용 용량은 얼마 인지가 중요하다. 스위치의 허용 용량이 기대 목표 용량에 못 미칠 경우 병목의 원인이 될 수 있다. 또한 iSCSI를 위한 스위치 구성은 일반적인 네트워크와 분리해서 구성하여 스위치의 부담을 덜어 주는 것이 좋다.

위의 스위치 구성은 RJ-45 20 포트와 SFP+ 4포트로 되어 있는 구성으로, 일반적으로 iSCSI SAN의 물리적 인터페이스가 SFP+임을 감안하면 최대 1 SAN + 3 Server 구성 (MPIO,Fail Over를 고려하지 않은 경우)만이 가능하며 확장시에는 RJ-45 SFP+로 변환해주는 Transceiver가 필요하게 되어 추가 비용이 발생한다.

 

위의 스위치 구성의 경우 SFP+ 포트가 20, RJ-45 포트가 4개로, 일반적인 iSCSI 구성에서 확장이 용이하다.

Fibre Channel SAN (HBA)

Fibre Channel Storage는 빠른 속도와 낮은 Latency를 보장하며 일반적으로 HBA (Host Bus Adapter)를 사용한다. HBA 기반의 SAN은 서버로 직접 연결하거나 HBA 스위치를 거쳐서 연결할 수 있으나 일반적으로 HBA 스위치를 중간에 넣는 구성을 선호한다.

 높은 성능 만큼이나 가장 높은 비용을 요구로 하기 때문에 중대형급 Storage에 사용된다.

권장 설정

Single Server로 구성하는 경우에는 DAS가 권장할만하며, 중규모에서는 가격대비 성능비로 iSCSI 10G 구성이, 그리고 대규모 또는 고성능이 요구되는 경우에는 HBA 구성을 사용하도록 한다.

iSCSI 구성시에는 일반적인 네트워크와 iSCSI SAN 네트워크를 물리적으로 분리하는 것을 권장한다. iSCSI HBA 구성시에는 SAN과 서버쪽의 NIC를 이중화하여 NIC 장애에 대비한다.

Storage Controller Architecture

iSCSI HBA 기반의 SAN의 경우 별도의 SAN Controller가 필요한데, Controller 선택시에 고려해야 할 사항은 다음과 같다.

Controller Type

Controller란 기본적으로 Disk Array를 위에서 언급한 인터페이스 (iSCSI,HBA)로 외부에 노출 시켜주고 내부의 Disk들을 관리하는 역할을 하는데, 이 관리역할을 하는 소프트웨어가 어떻게 구현되어 있느냐에 따라서 구분 지을 수 있다.

Windows Server Linux Server 같은 일반적인 서버 위에 소프트웨어를 이용하여 구성하는 소프트웨어 방식과, ASIC 칩과 같이 하드웨어 칩 안에 Controller 소프트웨어를 Embedding하는 두 가지 타입이 있으며, 성능 면에서는 하드웨어 방식이 뛰어나다.

MPIO (Multi path IO)

HBA 구성에서 서버 쪽에 두 개 이상의 SANNIC가 장착하여 , SAN으로의 네트워크 트래픽에 대한 부하 분산 및 NIC 장애시에 Fail Over가 가능하게 하며, 물리적으로 여러 개의 NIC가 장착되어 있더라도 논리적으로 하나의 NIC처럼 인식하도록 한다.

Redundant 구성

HBA 또는 iSCSI 구성시에, SAN Controller를 두 개 이상 설치하여 Controller에 대한 장애 대응이 가능하도록 한다.

Controller Architecture

TYPE

Architecture

Max Throughput

DAS

SATA (SATA II)

300MB/s

SCSI (U320)

320MB/s

SAS

375MB/s

iSCSI

iSCSI (Gigabit Ethernet)

125MB/s

iSCSI (10 Gigabit Ethernet)

1250MB/s

HBA

Fibre Channel (2 GFC)

212.5 MB/s

Fibre Channel (4 GFC)

425MB/s

Fibre Channel (8 GFC)

850MB/s

 

권장 설정

iSCSI 구성의 경우 Controller 이중화 구성, HBA 구성의 경우 HBA Controller 이중화 구성 권장

Controller Cache

SAN Controller는 내부적으로 Cache를 가지고 있는데, Cache Read 성능에 영향을 주기 때문에, 결정시 크고,빠른 Cache 메모리를 장착하고 있는 Controller를 선택하도록 한다.

Drive Types

서버나 Disk array에 장착되는 Hard disk는 전체 Storage Architecture의 성능에 지대한 영향을 준다. 주요 성능 Factor로는 Interface Type (SCSI,SAS,SATA etc) Disk Rotational Speed (7200,10k,15k RPM) 그리고 Latency Time이다. Factor들이 주로 IOPS Latency에 영향을 준다. 예를 들어 15K RPM driver 10K RPM drive보다 약 35% 높은 IOPS를 제공한다.

 가상화 환경에서 Guest OS에 대한 성능은 이 IOPS Latency Hard Disk maximum sustained throughput 보다 중요하다.

SCSI

SCSI 드라이브의 경우 근래에 들어서 SAS,SATA 그리고 Fibre Channel Disk로 교체되고 있기 때문에, 새롭게 서버를 도입하는 경우에는 권장하지 않으며, 만약 기존의 서버를 재활용할 경우에는 U320 SCSI 가 가장 높은 성능을 보장할 수 있다.

SATA

가장 저렴한 형태의 구성으로, 보통 1.5GB/s 3.0GB/s(SATA I and SATA II)를 제공한다. 일반적으로 7200 RPM & 4ms latency 또는 일부 모델의 경우 10kRPM & 2ms latency를 제공한다.

SAS

SATA Disk에 비해서는 비싸지만 그에 비해 많은 성능 향상을 제공한다. 일반적으로 10K,15K RPM 2~3ms latency를 제공한다.

Fibre Channel

SAS와 비슷한 성능적 특정 (10,15K RPM & 2~3ms latency)를 제공하지만, 다른 형태의 (Fibre Channel) 물리 인터페이스를 제공한다.


<그림. Fibre Channel Disk >

권장 설정

SAS Disk가 권장되며, 같은 용량의 경우 물리적으로 여러 개의 Disk로 나누는 것이 유리하다. 예를 들어 4TB를 구성할 때, 500GB * 8보다는 400 GB * 10 IO를 분산 시켜서 더 나은 성능을 발휘한다.

 

Disk Redundancy Architecture

다음은 Disk Array 상에 개별 Disk Node에 대한 장애를 대비해야 하는데, 이는 RAID 구성을 통해서 구현한다. Private Cloud 구현에 있어서, 개별 Disk Node에 대한 장애 대비책은 매우 중요한 사항이며, 특히 개별 Disk Node 장애시 서비스에 대한 정지 없이 Disk를 교체할 수 있는 구조를 제공해야 한다.

RAID 0

Stripping 구성으로, 하나의 데이터를 물리적으로 다른 디스크에 분산해서 저장하는 방식으로, read-write 성능이 좋고 디스크 용량을 100% 활용한다는 장점은 있으나, Disk가 하나라도 Fail 났을 때는 전체 데이터가 유실 될 수 있다.


RAID 1

Mirroring 구성으로 하나의 물리적인 Disk에 다른 하나의 Mirroring Disk를 배치하여 복제를 하는 방식이다. 전체 용량의 50% Mirroring에 사용되기 때문에, 공간 활용률이 떨어지고, 비용적으로 비싼 문제가 있다. 또한 한번 Write 시에 물리적으로 두 개의 Disk Write를 해야 하기 때문에 성능저하가 발생할 수 있는데, 이를 방지하기 위해서 Controller에서 Disk 마다 별도의 host adapter를 배치하여 Write시에 발생할 수 있는 병목을 방지한다.


RAID 5

Striping with parity 구성으로, Striping이란 하나의 데이터 블록을 물리적으로 하나의 Disk에 쓰는 것이 아니라 여러 Disk에 나눠서 쓰는 아키텍쳐이다. Parity란 데이터 복구를 위한 압축화된 저장 이미지로, 데이터 블록이 깨졌을 때 이 Parity 데이터를 이용하여 복구 연산을 수행한다.

RAID 5를 정리하면 데이터를 Striping 을 이용해 여러 물리 디스크에 분리 저장하고, 장애에 대해서는 Parity를 이용하여 복구 연산을 수행한다.

 데이터를 Striping하기 때문에 2개의 디스크가, 그리고 Parity를 저장해야 하기 때문에, 1개의 디스크가 즉 총 3개 이상의 디스크가 필요하다. 장점으로는 RAID 1처럼 전체를 Mirroring 하는 것이 아니기 때문에 공간 활용율이 뛰어나고, READ performance RAID 1에 비해서 높다. 반면에 Write performance RAID 1에 비해서 낮기 때문에, READ Transaction이 많은 업무(웹서버와 같은)에는 적합하나 Private Cloud의 저장 공간으로는 적절하지가 않다.

 또한 장애가 발생하였을 때 Parity 데이터를 기반으로 복구 연산을 수행하는데, 이 복구 연산의 복잡도가 매우 높기 때문에, Disk Fail시 복구 연산으로 인해서 전체 Disk IO 성능이 급격하게 떨어진다. (이런 문제를 보안하기 위해서 Parity 연산 전용 칩셋을 부착한 RAID 5 컨트롤러들이 있다.)


RAID 10 (RAID 1+0)

RAID 1+0 구성은 RAID 1처럼 Disk Mirroring한 후에 데이터를 Stripping해서 저장하는 구조이다. Mirroring을 위해서 하나의 논리 디스크는 Mirroring용 디스크를 포함해서 2개가 필요하고 Stripping을 위해서 2개 이상의 논리 디스크를 필요로 한다. 4개의 물리 디스크가 필요하다. RAID 1+0 구성은 다른 RAID 구성에 비해서 높은 read-write 성능을 제공한다.


RAID 구성 정리

RAID LEVEL

최소 디스크 수

장애 대응성

Random Read

Random Write

Sequential Read

Sequential Write

하드 용량 사용률

RAID 0

2

None

4

4

5

4

100%

RAID 1

2

4

3

3

2

3

50%

RAID 5

3

3

5

2

3.5

2.5

67~94%

RAID 10

4

4

5

4.5

5

5

50%

(5점 만점)

권장 구성

RAID 1은 서버에서 사용되는 System Volume에 적절하다. (OS,Application)

RAID 1 or RAID 1+0 구성은 시스템의 data Volume에 사용한다.

RAID 5  Private Cloud 구성상에서 Write Performance에 문제가 있을 수 있기 때문에 사용하지 않는다.

Storage Architecture 결론

앞서 정리한 Storage Hardware Architecture의 기술적인 특징 포인트를 그림으로 정리하면 다음과 같다.


소규모의 Single Server 기반의 Private Cloud를 구축할 경우에는 DAS Local Disk, 중규모의 저 비용 구조를 고려할 경우는 SAS + 하드웨어 기반 iSCSI (10G) 구성을 권장하고, 고성능이나 대규모 구성의 경우 HBA기반의 Fibre Channel 기반 구성을 권장한다.