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


Archive»


 
 

네이버 IT 용어 사전을 보면

 

다른 기종의 스토리지들을 하나의 단일 풀로 통합하는 기술. 스토리지 가상화는 단순히 물리적 디스크 어레이논리적 볼륨으로 사상(寫像)시키는 것을 의미하며, 디스크의 가상화는 물론 다른 기종 관리와 백업, 복구의 단순화와 자동화, 구성의 단순화 등을 제공하는 스토리지 통합 관리 솔루션이다. 스토리지 용량이 충분한지 수시로 확인할 수 있고, 예비 스토리지 자원의 준비 비용을 절감할 수 있어 관리의 효율성을 높이고 소유 총비용(TCO) 절감 등의 효과를 얻을 수 있다.


출처 : http://terms.naver.com/item.nhn?dirId=205&docId=26198

여러개의 Storage를 묶어서, 하나의 논리 Storage로 묶어 주는 기술로, 다수 벤더에 의해서 제공되는 SAN들을 묶거나, ISCSI,FC/HBA SAN과 같은 여러 Topology의 SAN을 하나의 논리 Storage로 묶어준다.
이 묶인 공간을 논리적으로 다시 분할하여 사용할 수 도 있다.
여러 공간에 나뉘어져서 생기는 Fragmentation을 최소화할 수 있고, 여러 복잡한 하드웨어 타입, 벤더들에 대해서 논리적으로 동일한 관리 인터페이스를 제공한다.

흐음.. 근데.. Private Cloud 설계에도 필요할까요?
P4500이 Storage Virtualization이 되는 걸로 알고 있긴 한데....

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

MPLS는 MultiProtocol Label Switching의 약자로
Layer 3에서 IP를 보고 라우팅을 하는 것이 아니라 패킷에 라벨을 붙여서 라벨을 기반으로 라우팅을 하는 기법으로 Layer 2 기반으로 라우팅을 수행한다.
그래서 IP 프로토콜뿐만 아니라, ATM이나 Frame Relay와 같이 프로토콜 종류에 상관 없이 라우팅이 가능하고, 무엇 보다 빠르다.
단 MPLS를 지원하는 라우터가 비싸다.
MPLS는 VPN등에 사용되는데..
IaaS 클라우드 구성에서, Server Rack간의 고속 라우팅을 하는데 사용하면 좋을 것 같다는..
돈이 문제지만
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요


Auto Scale Out을 고민할 일이 있어서.. Amazon EC2를 봤는데..
역시나..
EC2는 기본적으로 IaaS이기 때문에, CPU나 어느 조건 이상이 되면 Config 된데로, Scale out이 되는데, AMI 이미지 똑같은 것을 하나 더 띄우고, Load Balancer에서 연결해주는 형태..

즉, 일반적인 웹서버나 클러스터가 안되어 있는 Tomcat등은 그럭저럭 먹힐거 같은데..
WebLogic,JBoss 등은 어렵다는 이야기, 결국 API로 WLS등 모니터링해서 Scale out할 수 있게 해주고, AMI 이미지도 Instance별로 별도 고려가 되야 하는 형태..

Scale out은 아무래도 PaaS가 유리한듯..

그리고, DB Auto Scale out 이야기 하시는분들 있는데, 일반적인 RDB에서는 안되거든요? Oracle에서 2 Machine 이상 도는거 보셨어요? (RAC기준). RDB에서 Scale out할려면, Sharding 아키텍쳐로 설계가 되도 쉽지 않고, 오로지 CDC를 이용한 Query Off Loading 방식만 가능한데, 이 경우에도 WAS에서 Connection Pool이 Scaled out된 DB Instance를 볼 수 있어야 합니다. 물론, HBase와 같은 Column DB는 당연히 Scale out이 고려된 솔루션이니까는 가능합니다만....

WAS와 DB Scale Out 아키텍쳐 정리해야 하는데.. 귀찮다..ㅜㅡ
맥주나 한잔하고 자야 쓰겄습니다.
요즘 집중력 저하야... 딘따..
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요


IaaS 구축용
- Hypervisor : XenServer, Oracle XenServer가 가격 대비 Support 가능
- Cloud Management : Cloud stack (cloud.com)
- Software ISCSI : Nexentar (고속 IO에는 적합하지 않음)

PaaS 구축용
- Storage : OpenStack
- Column DB : Cassandra
- Simple DB : MySQL or VoltDB

Hadoop은 아니라고 보고
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

 
  • 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

 


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 김정한 2011.11.29 12:19  댓글주소  수정/삭제  댓글쓰기

    좋은 글 감사합니다..^^


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

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 이장석 2011.03.02 11:16 신고  댓글주소  수정/삭제  댓글쓰기

    Private Cloud 구축시 하드웨어 고려사항에 대한 상세한 글이네요.
    글 잘 보았습니다.
    좋은 하루 되십시오.

  2. 김세희 2012.11.02 17:24  댓글주소  수정/삭제  댓글쓰기

    글 잘보았습니다. 정리에 많이 도움이 되었습니다.

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)
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

http://www.bing.com/videos/watch/video/dynamic-data-center-toolkit-demo/qmxnjffc?from=email
 
Private Cloud 구축 솔루션인 Dynamic DataCenter Demo

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

클라우드 서비스중 Private 클라우드의 경우 대부분 Hypervisor 기반의 가상화를 이용하여 하드웨어 자원을 공유하는 아키텍쳐를 일반적으로 사용하지만, Public 클라우드의 경우 Iaas 형태의 서비스를 제공한다 하더라도, 몇가지 공통적인 특정 서비스를 제공한다.

Public 클라우드에서 제공하는 공통적인 서비스 형태들은 다음과 같다.

 

Storage Service

Storage Service는 말 그대로 데이터를 저장하는 서비스이다. 데이터의 성격에 따라 몇 가지 상세 서비스로 나뉘어 진다.

적은 크기의 많은 수의 데이터 (Table Storage)

데이터의 수가 수천만,테라 단위의 많은 수를 가지고 있으며, 데이터의 복잡도나 각각 레코드의 크기는 크지 않을 경우, 큰 저장 용량과 빠른 검색 속도를 요구 한다. 사용자 profile,게시물 레코드등이 해당하는데, 기업내에 이런 데이터를 저장하기에는 디스크등의 저장소에 소요되는 비용이 너무 크고, 폭발적인 용량 증설이 있을 경우에 비즈니스에 대한 대응성이 늦다. 그래서 대부분의 Public Cloud 서비스에는 이러한 데이터 형태를 저장하는 별도의 저장 메커니즘을 제공하는데, MS Windows Azure Table Storage Amazon SDS가 대표적인 서비스이다.

이러한 데이터 저장 구조는 근래에 서비스 업체를 중심으로 하는 NoSQL 아키텍쳐와 관련이 깊은데, 실제로 페이스북이나 트위터의 경우 많은 데이터에 대한 저장 요구사항과 빠른 검색 및 접근 성능을 요구로 하고 있기 때문에, Cassandra와 같은 Column데이타 베이스를 이용하여 이와 같은 요건을 구현하고 있으며, 이러한 배경이 반역된 것이 위에 언급한 형태의 클라우드 데이터 서비스이다.

크기가 큰 데이터 (Blob Storage)

일반 데이터 파일, 사진,이미지,동영상과 같은 크기가 큰 데이터의 경우 복잡한 쿼리와 같은 연산은 필요로 하지 않지만 저장용량에 대한 비용 문제가 발생하고 특히 여러 국가를 대상으로 서비스 하는 시스템의 경우 데이터의 다운로드 속도가 문제가 된다.

 이런 형태의 데이터를 Blob 데이터라고 하고, Public Cloud에서는 크기가 큰 데이터를 저장하기 위한 서비스를 제공한다. Amazon S3, MS Windows Azure Blob Storage 서비스가 대표적인 예이며, 여러 국가(지역)간의 다운로드 성능을 향상 시키기 위해서 CDN (Contents Delivery Network)을 연계한 서비스를 제공하는 모델이 많다.

복잡한 데이터 연산을 필요로 하는 데이터 (RDBS over Cloud)

다음으로 기업용 애플리케이션이나 복잡한 관계형 데이터를 가지고 있는 경우 쿼리와 관계 관리를 위한 RDBMS 기반의 데이터 서비스가 필요하다. 쉽게 생각하면 RDBMS를 클라우드에 올리고 서비스를 한다고 똑같이 생각하면 되고, 단 이 경우 여러 데이터베이스간의 트렌젝션을 연동하여 보장하는 분산 트렌젝션은 지원하지 않는 것이 보통이다. (클라우드 노드간의 Latency 문제 때문에 분산 트렌젝션 지원시 심각한 성능 저하를 유발한다.)

 Amazon에서 오픈소스인 MySQL을 기반으로한 RDS 서비스나, MS Windows Azure MS SQL을 기반으로한 MS SQL 서비스가 대표적인 사례이다.

가상 디스크 저장소 (Virtual Disk)

마지막으로 애플리케이션 차원에서 양이 많지 않고 애플리케이션 자체적으로 사용할 데이터 또는 Iaas OS에 마운트되는 디스크등을 지원하기 위해서 논리적으로 디스크를 생성하여 가상머신(OS VM)에 마운트하는 서비스를 제공한다.

대표적인 서비스로는 Amazon EBS Microsoft Azure Azure Drive 서비스 등이 있다.

Queue Service

Queue Service는 기존의 IBM MQ, Microsoft MSSQ, Java JMS와 같은 비동기 호출을 지원하는 메시지 큐이다.

클라우드는 특성상, 작업을 하는 Working Instance들이 존재하고, 이 여러 Working Instance간의 작업 배분 또는 작업 요청에 대한 Buffering등을 위해서 중간에 메시지큐가 필요한데 이러한 요구사항을 지원하기 위해서 Public Cloud에서는 Queue 서비스를 제공한다.

대표적인 서비스로는 Amazon SQS, Microsoft Azure Queue Storage 서비스등이 있다.

Data Grid Service

일반적인 엔터프라이즈 소프트웨어 아키텍쳐중에 근래에 발전된 아키텍쳐중 하나는 데이터 그리드라는 아키텍쳐이다. 일종의 거대한 메모리를 여러대의 물리적 서버에 걸쳐서 배포하여 이론적으로 무제한 사이즈의 메모리를 만들고 애플리케이션들이 이 메모리를 통해서 서로 데이터를 공유하거나 또는 데이터 베이스에 대한 2차 캐쉬로 사용하는 시나리오를 많이 사용한다.

실제로 FaceBook의 경우 MySQL 데이터 베이스 윗단에 memcached라는 데이터 그리드를 위치 시켜서 데이터 베이스의 쿼리 성능을 획기적으로 향상 시키는 아키텍쳐를 사용하고 있다.

특히 클라우드 서비스의 경우 각각의 서비스 컴포넌트가 분리되어 있고 그로 인해서 컴포넌트간의 네트워크 Latency가 존재하기 때문에 데이터 조회의 성능을 높이기 위한 캐쉬 서비스와, 여러 인스턴스간의 정보를 공유하기 위한 데이터 버스가 필요하다.

이를 지원하기 위해서 발전된 형태의 Public Cloud에서는 데이터 그리드 서비스를 제공한다.

o    캐쉬 서비스

캐쉬 서비스는 데이터를 저장소 (데이터베이스, 파일)등에 저장하기 전에 2차 캐쉬로 사용하는 형태로 특히 Private 클라우드에 데이터를 놓고 Public 클라우드를 통해서 서비스를 제공하는 경우 지역적 문제로 인한 네트워크 Latency가 심하기 때문에 성능 향상을 위해서 캐쉬 서비스가 필수적으로 요구 된다.

o    메모리 버스

또한 여러 업무 또는 동일 업무라도 여러 서비스 인스턴스 (여러 VM)간의 데이터를 모으고 서로 공유 하기 위한 데이터 버스가 필요한데, Table Storage를 통해서 이러한 정보를 공유하는 시나리오도 있지만, 이보다는 데이터 그리드를 이용할 경우 보다 나은 성능을 보장할 수 있다. (일반적으로 데이터 그리드의 접근방식,데이터 구조는 Table Storage의 접근 방식과 데이터 구조와 거의 동일하다.)

 

대표적인 데이터그리드 서비스로는 Google AppEngine memcache 서비스, Microsoft Azure AppFabric Cache 서비스 등이 있다.

Scalability Support Service

클라우드 서비스의 가장 큰 목적 중의 하나가 하드웨어 자원의 탄력적인 사용이다. 자원의 사용량에 따라서 비용을 지불하는 모델인데, 현재 클라우드 서비스들은 이러한 요건을 만족하기 위해서 라이선스 정책상의 헛점을 가지고 있다. 대부분의 라이선스 정책이 CPU X clock에 메모리 얼마인 인스턴스 단위로 계약을 하고, 이 인스턴스당의 사용량에 대해서 과금을 하는 방식이다. 문제는 초기 계약 당시에 하나의 인스턴스만 계약을 하기 때문에, 용량이 하나의 인스턴스 이상으이 필요할 때 대응이 애매하다는 것이다. 쉽게 말하면 자동으로 인스턴스를 늘려줘야 하고, 늘려진 인스턴스에 자동으로 부하를 분산해줘야 한다. 이것이 클라우드상의 Scalability 문제인데, 이런 문제를 해결하기 위해서 제공 되는 서비스가 Auto Scaling 서비스이다. 일정 수준(SLA 이상)의 용량이 넘어가면 이를 감지해서 자동으로 인스턴스를 추가해주는 서비스이다.

대표적인 서비스로는 Amazon Auto Scaling 기능과 Windows Azure에서는 Monitoring API를 통해서 Instance를 늘려주는 기능을 추가해서 사용한다. (http://code.msdn.com/azurescale)

Virtual Machine Service

Iaas를 위한 가장 기본적인 서비스로, Hypervisor 기반의 하드웨어 자원을 가상화 하여 OS 별로 자원을 할당해주는 서비스이다. Amazon EC2 서비스와 Windows Azure VM Role 서비스가 대표적인 사례이다.

IDM(IDentity Management) Service

클라우드 서비스에 있어서 계정 통합 관리 및 권한 관리는 매우 중요한 이슈이다. 클라우드에 배포되는 여러가지 서비스에 대해서 통합된 계정 관리가 필요하고, 각 서비스에서 요구하는 사용자의 프로필의 스키마(항목)가 다르고 서비스마다 각각 관리가 되어야 하기 때문에 서비스 가입 및 해지 또는 정보 변경에 따라 각각 서비스가 관리하고 있는 사용자 프로파일이 동일하게 변경되어야 한다 (ID Provisioning).

여기에 더해서 만약 on premise 시스템과 연동을 할 경우 기업 내에 이미 계정 및 권한 관리 시스템이 운영되고 있기 때문에 클라우드에 구축된 시스템과 on premise 시스템간의 계정 통합 역시 새로운 이슈로 제기된다.

이런 계정 통합과 통합 권한 관리의 이슈를 해결하기 위해서 클라우드 시스템내에는 통합된 또는 통합 가능한 형태의 계정 권한 관리 시스템이 요구된다.

대표적인 서비스로는 Windows Azure AppFabric ACS 서비스가 있다.

Platform Service (.NET,LAMP etc)

다음으로는 애플리케이션 플랫폼을 배포 및 운영할 수 있는 형태의 서비스를 제공하느냐인데, 쉽게 생각하면, 자바나 .NET 기반의 애플리케이션만 배포하면 되느냐? 아니면 DB,Web Application Server등의 미들웨어도 배포해야 하는냐로 판단하면 된다. 개발된 애플리케이션만 배포하여 운영할 수 있는 인프라가 다 되어 있는 경우에는 Paas (Platform As a Service)이고, 애플리케이션 운영을 위해서 별도의 미들웨어 인스톨이 필요할 경우 미들웨어를 인스톨할 수 있는 인프라만 제공하는 경우이기 때문에 이런 형태는 Iaas(Infra as a service)라고 한다.

Microsoft Azure의 경우 .NET,PHP 등의 애플리케이션 플랫폼을 제공하는 Paas 형태이고, Amazon의 경우에는 가상화된 OS를 기본적으로 제공하고, 그 위에 애플리케이션 운영플랫폼은 별도로 설치해야 하기 때문에 Iaas 형태이다.

Google의 경우 Python JVM기반의 언어 (JRuby)등을 제공하는 Paas 형태이고, 위에서 설명했듯이 MS Azure Paas, Amazon Iaas 형태의 서비스를 제공한다.

Integration Service

클라우드의 요구사항 중 하나는 각각 개별로 배포된 클라우드 기반의 서비스간의 통합 또는 클라우드에 배포된 서비스와 on premise에 배포된 서비스간의 연동이다. 위에서도 IDM등의 시나리오를 통해서 특화된 연동 통합 시나리오에 대해서 언급했지만, 여기서는 좀 더 보편화된 통합 서비스 기능에 대해서 설명한다.

     Internet Service Bus

SOA 서비스에서 메인 계층 중의 하나가 Enterprise Service Bus (ESB)이다. ESB는 여러 다른 비즈니스 서비스간의 통합과 데이터 버스의 개념으로 사용되는 솔루션이다. 클라우드 아키텍쳐에서도 이와 유사한 형태의 데이터 버스와 통합 계층이 필요한데, 기존 ESB의 특징에 더해서 클라우드 아키텍쳐의 특징을 반영할 수 있는 Service Bus가 필요하다.

클라우드는 첫번째로 지역적으로 분산된 위치에 비즈니스 서비스들이 배포 되며, 두번째로 방화벽이나 NAT(네트워크 주소를 변경 시키는 장치)등을 경계로 한 on premise 서비스와 클라우드 내의 서비스를 통합해야 하는 요건을 가지고 있다. 그렇기 때문에 지역간의 라우팅을 담당하고 복잡한 네트워크 토폴로지 (주소 변환,방화벽)를 지원할 수 있는 구조의 Service Bus가 필요하고 이런 특성을 가지고 있는 Service Bus Internet Service Bus라고 제공한다. 이러한 Internet Service Bus는 애플리케이션 플랫폼에 종속적이기 때문에 (Reverse Proxy등의 기능을 제공해야 하기 때문에 프로그래밍 언어의 라이브러리 형태로 일부 모듈이 제공되어야 한다.) Iaas 형태의 클라우드에서는 제공하기 어렵고 애플리케이션 플랫폼을 제공하는 Paas 형태에서 제공하기가 용이하기 때문에 대표적인 Iaas 형태인 Amazon 클라우드에서는 제공하지 않고 있으며 Paas 를 지원하는 Microsoft Windows Azure AppFabric Service Bus가 대표적인 사례이다.

     Legacy Integration Service

다음으로 기업내의 Legacy System을 통합하기 위한 솔루션이 필요한데, 클라우드 이전의 on premise 시스템에서는 EAI (Enterprise Application Integration)이라는 아키텍쳐를 이용했다. EAI Legacy Package Application에 대해서 특정한 Technology를 이용한 통합을 제공하는데, (SAP ERP, Oracle CRM에 대한 Technology 아답터등을 제공하는 방식으로) 이러한 EAI 특성이 클라우드에도 배포되어 on premise에 배포된 Legacy Application이나 클라우드에 배포된 Package Application에 대해서 통합을 지원한다. 대표적인 예로는 Microsoft Azure AppFabric BizTalk 서비스가 있다.

Monitoring Service

마지막으로 Monitoring Service인데, 서비스 현황, 사용량 등을 Dash Board 형태로 표현함은 물론이고, Application의 성능과 건강도를 모니터링할 수 있는 APM (Application Performance Monitoring)등의 기능이 제공되어야 한다.


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 남정현 (rkttu.com) 2010.11.16 11:48 신고  댓글주소  수정/삭제  댓글쓰기

    올려주시는 글들을 매우 유용하게 읽고 있고, 여러모로 배우고 있습니다. 감사합니다. :-)

  2. jisqo 2010.12.06 16:26  댓글주소  수정/삭제  댓글쓰기

    잘읽었습니다~ 좋은 글 포스팅 감사합니다 ^^


클라우드 컴퓨팅의 최소 요구 조건

       Self Service : 클라우드에 배포된 리소스에 대한 사용과 설정 등을 서비스 제공자가 제공하는 인터페이스를 이용하여 사용자가 직접 조작

       Scalable /Elastic : 클라우드 내의 공유 자원 등을 이용하여 사용량(트렌젝션 증가)에 따라서 탄력적으로 리소스를 재 배분할 수 있어야 한다.

       Multi-tenant/Shared : 클라우드 내의 공유 리소스는 여러 조직이나 업무에 배분 되어 사용되며, 각각 배분된 리소스는 보안 적인 측면과 사용량 적인 측면등에 있어서 철저하게 분리된 형태로 제공되어야 한다.

       Usage based : 클라우드 서비스에 대한 사용 요금은, 사용량을 기준으로 제공되어야 한다.

클라우드 컴퓨팅의 배포 모델에 따른 분류

클라우드 컴퓨팅 플랫폼은 배포 장소와 서비스 사용 제공/사용 주체에 따라서 크게 아래와 같이 3가지 형태로 분리할 수 있다. 아래 Y 축은 배포 장소를 의미하고 아래 X축은 서비스 사용/제공 주체를 의미한다.


Private Cloud

서비스 사용자가 기업 내부의 비즈니스 시스템을 위해서 자체적으로 클라우드 플랫폼을 구축 하는 모델 (:on-premise)

§   클라우드 플랫폼이 회사 내부 또는 3’rd party 데이터 센터에 독립적으로 구축됨

§   Example

o    Rackspace Managed Private Cloud

o    데이터 센터에 Hosting Service + 가상화를 이용하는 경우

o    Hosting.com – Cloud Dedicated offering

o    Microsoft Data Center based implementation

Public Cloud

서비스 제공자가 클라우드 서비스를 제공하기 위한 플랫폼

§   전문 클라우드 사업자 (MS,Amazon)에 의해서 서비스가 제공되는 클라우드 플랫폼

§   클라우드 플랫폼은 서비스 사용자의 회사 외부에 (서비스 제공자)에 배포됨

§   모든 리소스는 다른 사용자와 공유됨

§   리소스 사용량에 따라 과금되는 형태

§   Example

o    Salesforce.com

o    Amazon EC2

o    Windows Azure, Microsoft Dynamics Online, Office365

o    Google App Engine

“Hosted Private Cloud”

서비스 사용자가 기업 내부의 비즈니스 시스템을 서비스 제공자의 Public 클라우드 플랫폼을 인프라로 사용하여 구축하는 모델

클라우드 컴퓨팅의 서비스 단계에 따른 분류

Infrastructure as a Service (Iaas)

IT 서비스를 제공하기 위한 주요 인프라 자원 (CPU 자원, 메모리, 디스크, 네트워크 환경)을 공유 자원 형태로 관리하고 이를 나눠서 제공하는 형태의 서비스로, 서비스 사용자는 이러한 인프라 위에 리소스를 할당 받아 OS와 미들웨어 (데이터 베이스, 웹서버)를 설치하여 서비스를 이용하는 형태이다.
주로 Microsoft Hyper-V, Citrix XenServer등과 같은 가상화를 이용하여 하드웨어 자원을 가상화하고, 이 가상화 기술을 통해서 자원을 배분한다
.
대표적인 Public Cloud 서비스로는 Amazon EC2,FastHosts,Rackspace,Go Daddy등이 있다.

Platform as a Service (Paas)

Iaas OS를 인스톨 하기 위한 하드웨어 가상화 환경을 제공하는 것이라면, Paas Iaas에 한 계층을 올려서 소프트웨어를 개발 할 수 있는 플랫폼을 제공하는 환경을 의미한다.

특정 컴퓨터 언어(Java,.NET,Rails,PHP etc) 가 구동할 수 있는 미들웨어 및 데이터 베이스는 물론이고, OPEN API 형태로 미리 구현된 서비스 라이브러리를 제공함으로써 애플리케이션을 개발할 수 있도록 지원한다.

대표적인 예로는 Java Python 언어 기반의 서비스를 제공할 수 있는 Google AppEngine 서비스,, .NET 기반의 웹 애플리케이션이나 서버 사이드 애플리케이션을 개발 및 서비스할 수 있는 Windows Azure등이 대표적인 Paas 서비스로 볼 수 있다.

또한 Amazon PayPal을 이용한 OPEN API기반의 빌링 서비스,Google Map 서비스와 같은 OPEN API  플랫폼 역시 Paas의 일부로 분류할 수 있다.

Software as a Service (Saas)

클라우드 서비스의 추상화중 가장 상위 계층을 차지하는 분류로 소프트웨어 서비스를 제공하는 형태의 클라우드 서비스이다. 예전의 ASP (Application Service Provider-KT의 비즈메카, Cafe24의 쇼핑몰 호스팅)과 유사한 서비스 모델로, 이메일,CRM 등의 완성된 형태의 애플리케이션을 서비스 받는 형식으로, 사용자는 애플리케이션의 사용량에 따라서만 비용을 지불하고 그외의 부분 (아래 인프라나 하드웨어 사양, 플랫폼 사양)에 대해서는 관리를 하지도 비용을 지불하지도 않는다.

구글의 GMAIL,Apps 서비스, SalesForce.com CRM서비스 MS Office365 서비스들이 대표적인 예이다.

기타

근래에 들어 위의 3개 주요 분류 이외에도 특화된 서비스 모델을 중심으로 새로운 클라우드 서비스 분류가 나타나고 있는데, 대표적인 분류 내용을 꼽아보자면 다음과 같다.

o    Test platform as a service

대규모 부하 테스트 등은, 소프트웨어 개발 프로젝트의 중후반에 발생하며 많은 수의 하드웨어 장비와 대규모의 트래픽을 지원하는 네트워크망이 필요하다. 이러한 인프라를 비 연속적인 개발 프로젝트를 위해서 사내에 구매 및 구축이 어렵기 때문에 근래에 들어서는 이러한 대규모 부하 테스트를 위한 서비스를 클라우드를 통해서 제공되는 서비스가 있으며, Selenium in Amazon EC2등이 대표적인 사례이다.

o    Develop platform as a service

테스트 플랫폼과 마찬가지로, 소프트웨어 개발 프로젝트 과정에서는 개발 계와 이행을 위한 Staging 계 등의 다양한 개발 환경이 필요하며, 이러한 개발 환경에 대한 관리 와 하드웨어 및 소프트웨어 구매는 기업에 있어서 또 다른 부담으로 다가온다. 이러한 문제를 해결하기 위해서 소프트웨어 개발환경을 클라우드 형태로 구성해놓고, 프로젝트 기간에만 임대해서 사용하는 형태의 서비스가 있다.

대표적인 예로는 Microsoft SDC (Solution Development Center)의 개발 환경 모델이 있다.

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 강선미 2010.12.09 18:25  댓글주소  수정/삭제  댓글쓰기

    글 잘 읽었습니다. 클라우드 컴퓨팅에 대해 잘 정리하셨네요~

http://rinapc.com/164

  • OS 가상화

  • 하드웨어 가상화

  • Paravirtualization

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요