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


Archive»


 
 
요즘 오픈 소스 기반의 클라우드 솔루션을 보다 보니 트렌드가 많이 변했다고 느끼는데, 그중 하나가 Cross-Cloud-Management이다.

Microsoft의 경우 Concero라는 코드명으로 Private Cloud와 Azure 기반의 Public Cloud를 동시에 관리하는 기능을 제공하는데, 예를 들어 관리자가 Application을 만들고 Private Cloud로 Targetting하면 내부 클라우드에 배포 되고 Targetting을 미국 Azure로 하면 미국에 배포되는 모델이다.
즉 Private과 Public Cloud를 하나의 회사 클라우드로 통합 관리하는 모양이 되는데...
년초에 이 개념을 보고 차암 대단하다고 생각했는데..

이번에는 Right Scale이라는 솔루션을 봤는데. 이놈은 클라우드 위에서 Public Cloud간 또는 Public-Private Cloud간의 통합된 통제를 가능하게 한다.


RightScale은 Azure,Amazon,Rackspace등 주요 Public Cloud에 대한 중앙 관제를 제공하면서
Ecualyptus나 OpenStack으로 개발된 Private Cloud도 똑같이 중앙 관제가 가능하다. (Ecualyptus나 OpenStack은 Amazon EC2 호환이 되니까는 가능하다.) 즉 수평적,수직적인 클라우드 통합을 지원한다.

JClouds

아울러서 클라우드 개발 부분에서도 변화가 있는데, 재미있는 프레임웍중 하나가
jclouds.org
이다.
클라우드의 주요 기능등 예를 들어 S3,EBS 등을 Java API로 쌓아 놓은 것인데..
재미있는 점은 Amazon 뿐만 아니라 Azure,Ecualytus,Terramark 등 주요 클라우드 서비스들을 호출할 수 있도록 되어 있는데, Abstraction이 되어 있어서 비슷한 기능은 Provider만 바꾸면 되는 구조라는 것이다. 즉 Azure의 BlobStorage나 Amazone의 S3는 그 구조와 용도가 유사한데, JCloud에서는 이것을 하나의 인터페이스로 묶어서 클라우드 서비스 사업자 Depdency 없이 프로그래밍을 할 수 있도록 해준다.

참~~ 한국에서는 Azure나 Amazon 사용하지도 못하고, 그나마 KT가 이제 슬슬 클라우드 서비스 시작할려고 하는데, 벌써 바깥 세상은 한참 변하고 있네요.

 
  • Scale out unit provisioning
    • Bare metal provisioning
  • Reporting
  • Life cycle management
  • Charge back model
  • IO Segregation
  • Self Service Portal
  • Multitenancy
  • Fabric Management
  • Live Migration
  • Automated Patch (Customer requirement is required. 보안 패치를 8시간 내에 모든 서버에 제공한다던지..)
  • Resource Pool Management
    • Asset (VLAN,IP,MAC,LUN) management
  • Scale out unit design

 
가상화만 고민하는데,
대충 이넘들은 고민해야 할듯..



아키텍쳐는 간단, 결국 Workflow 설계랑 PI를 어떻게 할것인가가.. 문제.
ITIL이랑 접속 시키는 것도 필요하고.~~

Cloud Architecture

클라우드 컴퓨팅 & NoSQL/IaaS 클라우드 | 2011.02.24 04:20 | Posted by 조대협


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

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 기반 구성을 권장한다.

DB VM에 올릴 때 첫번째로 고려할 사항은 수직적 확장성이다. 수평적인 확장성은 DBMS 자체가 제공하는 클러스터 기능을 이용해야 한다. (MS SQL의 경우 수평 확장 불가, ORACLE의 경우 RAC를 이용하여 수평확장 가능). 만약에 DBMS 자체 클러스터링에 대한 확장이 불가능하다면 애플리케이션 단에서 Database Sharding등을 이용하여 확장을 하는 안을 고려할 수 있다.

수직적 확장의 경우 현재까지 Hyper-V가 최대 CPU 4 코어까지만 지원하기 때문에, 더 이상의 용량이 필요한 경우 분리된 Physical Machine을 사용하는 방법을 사용해야 한다.

 

DBMS VM에 올릴 경우 가상화에 대한 Cost로 인하여 성능이 떨어지는데, 그 중에서 성능에 가장 큰 영향을 미치는 것이 Disk에 대한 부분이다. DB VM에 배포할 때 Disk에 대해서 아래와 같이 3가지 옵션을 선택할 수 있다.

       Dynamic Size VHD : 가상 디스크의 사이즈를 동적으로 지정하여 Runtime에서 변경되도록 하는 옵션

       Fixed Size VHD : 가상 디스크의 사이즈를 정해놓고, 공유하는 방안

       Pass-through Disk : 물리적인 디스크를 직접 VM에 마운트 하는 방안

 

먼저 Fixed Size VHD Pass-through Disk (이하 PTD)의 성능 차이를 보면

 

Random IO의 경우 Read/Write 모두 큰 차이는 없고 Sequential Write 부분에서 Fixed Size Disk 가 성능이 떨어지는 것을 볼 수 있다.

일반적인 OLTP성의 트렌젝션 처리 성능을 비교해보면


 1.       Baseline: a native Windows Server 2008 environment with Hyper-V role disabled. The virtual network switch is not turned off.

2.       Root partition: a root partition in Windows Server 2008 with Hyper-V enabled.

3.       VM_PT: a guest virtual machine configured with pass-through disks, four logical processors, and 14 GB RAM.

4.       VM_VHD: guest virtual machine configured with fixed-VHD disks, four logical processors, and 14 GB RAM.

5.       Overhead is calculated by comparing with Baseline ((Baseline Batches/CPU – VM Batches/CPU)/ Baseline Batches/CPU)

위의 테스트 결과와 같이 전혀 가상화를 하지 않은 상태 (Baseline) 대비 PTD를 사용했을 때와 Fixed Size VHD의 성능을 비교하면 10~20% 정도의 차이가 나는 것을 볼 수 있고, Fixed Size VHD PTD사이의 차이는 소량의 트렌젝션에서는 PHD가 약간 우세를 나타내며, 대량의 트렌젝션에서는 큰 차이가 없는 것으로 나타난다.


다음 자료는 하나의 MS SQL 인스턴스가 독립된 PTD를 사용하고, 다른 하나는 Fixed Size VHD를 사용하는데, 해당 디스크 볼륨이 다른 VM과 공유되는 상황에 대한 비교이다.

위의 표에서와 같이 Dramatic한 성능 차이는 나지 않는다.

 

결론적으로 PTD Fixed Size VHD 사이의 성능 차이는 미미하기 때문에 성능 최적화 측면에서는 PTD를 공간 활용면에서는 Fixed Size VHD를 사용한다.

 가상화에 올린 DB Physical 서버에 직접 올린 DBMS강의 성능 차이는 약 10~20% (가상화로 인한 오버헤드)정도로 판단하고 디자인에 참고해야 하며, 가상화에 올릴 시에는 최대 4개의 코어 까지만 지원하기 때문에 4 코어 이상의 성능이 필요한 경우 가상화 환경이 아닌 분리된 DBMS 하드웨어를 사용해야 한다.

(분석 리포트 출처: http://www.microsoft.com/hosting/dynamicdatacenter/Resources.html#SQLServer_)


장애 대응 단계별 하드웨어 설계 방안

클라우드를 구축하는데 비용상의 문제점은 SAN을 구축하는데 소요되는 비용이다. SAN Controller Switch에 많은 비용이 소요되는데, 서버별 사용 시나리오별로 SAN 사용 여부를 판단함으로써 전체 하드웨어 구축 비용을 절약할 수 있다.


소프트웨어를 이용한 장애 대응

Tuxedo와 같은 TP Monitor Tomcat과 같은 Web Application Server 등은 소프트웨어 자체적으로 Cluster 구축을 통해서 Fail Over를 지원하거나 장애가 났을 때 일시적으로 Transaction이 중단되는 것을 허용하는 경우가 많다. 이런 경우에는 SAN을 구성하지 않고 Server에 직접 연결된 DAS를 이용해서 서비스를 제공한다.

권장 시나리오 : Application Server VM, Oracle RAC를 지원하는 DB 시나리오

Live Migration을 이용한 서버 장애 대응


하드웨어 장애가 났을 때에도 무 정지 상태로 Migration이 가능하다. VM 이미지를 저장하기 위해서 SAN이 필요하다. 이 경우에는 소프트웨어가 제공하는 Fail Over Mechanism을 사용하지 않는다. DISK에 대한 FailOver RAID 구성을 통해서 지원을 하지만, SAN Controller 장애시에는 전사 장애로 발전한다.

참고 : Linux VM의 경우 Hyper-V에서 Live Migration 지원이 불가능하다.

권장 시나리오 : MS SQL

SAN Cluster 구축을 통한 장애 대응


바로 위의 시나리오의 SAN Controller 장애에 대응하기 위한 아키텍쳐로 SAN Controller를 이중화 하고, 앞단에 SAN Switch를 넣어서 SAN Controller에 대해서 장애 대응을 한다. 모든 서버 하드웨어 장애 시나리오에 대해서 대응이 가능하다.

권장 시나리오 : 무정지 시스템, 무정지 MS SQL


For hosting and telecom providers, Microsoft offers a set of WCF-based services that provide automation capabilities to provision, manage, or query multiple products and server technologies that are used in the operational data centers.

Managed hosting services are sets of services that leverage Microsoft® System Center Server Management Suite Enterprise products, including System Center Configuration Manager, System Center Operations Manager, System Center Data Protection Manager, and System Center Virtual Machine Manager. These services enable hosting providers to construct a managed hosting solution that offers various managed services, such as the following:

·         Windows Server® 2008

o   Physical machine provisioning and management

o   Hyper-V™–based virtual machine provisioning and management

o   Templates and image management

o   Internet Information Services 7.0 Web server and FTP7 provisioning and management

·         Microsoft SQL Server® 2005 and SQL Server 2008

o   Database server provisioning and management

o   Database content management

·         System Center Configuration Manager

o   Software updates

o   Software distribution

o   Asset tracking and reporting

o   Software metering

·         System Center Operations Manager

o   Server monitoring

o   Application monitoring

o   Network monitoring

o   Security auditing

·         System Center Data Protection Manager

o   File/folder-level backups and restores

o   Virtual server (.vhd)–level backups and restores

o   Physical server–level backups and restores

·         System Center Virtual Machine Manager

o   Virtualization environment management

o   Virtual machine placement

o   Snapshot management

o   Failovers (quick migrations)

당연히 윈도우즈 계열은 다 되고
http://www.microsoft.com/windowsserver2008/en/us/hyperv-supported-guest-os.aspx

Linux 계열도 지원하는데, 오늘 확인해보니, Linux도 VM당 최대 4 core까지 할당이 가능해졌음. (예전에는 1core 로 기억하는데)

Linux Distributions (VMs configured with 1, 2 or  4 virtual processor)

  • SUSE Linux Enterprise Server 10 with Service Pack 3 (x86 Edition or x64 Edition)
  • SUSE Linux Enterprise Server 11 (x86 Edition or x64 Edition)
  • Red Hat Enterprise Linux (RHEL) 5.2, 5.3 , 5.4 and 5.5 (x86 Edition or x64 Edition)