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 구성에서 서버 쪽에 두 개 이상의 SAN용 NIC가 장착하여 , 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 기반 구성을 권장한다.
'클라우드 컴퓨팅 & NoSQL > IaaS 클라우드' 카테고리의 다른 글
클라우드 노드 설계 (0) | 2011.02.23 |
---|---|
Private Cloud 구축시 하드웨어 고려 사항 (1) | 2011.01.27 |
MS SQL 를 가상화할시(클라우드 적용시)에 고려사항(성능자료 포함) (0) | 2010.12.30 |
Private Cloud (프라이빗 클라우드)에서 장애 대응 설계 방안 (0) | 2010.12.30 |
Microsoft Private Cloud 솔루션 Dynamic Date Center 모듈별 기능 (0) | 2010.11.24 |