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


Archive»


 
 
Left Hand P4000 장비가 가상 스토리지 (Virtual Storage)를 통해서 Scale Out이 가능한것으로 알고 있는데. 그래서 저가격 대비 장점으로 파악했는데, 오늘 문서를 살펴보다가 흥미로운 부분이 있어서 메모 하나

P4000으로 VSA (Virtual SAN Appliance)를 구성할 경우 지원되지 않는 사항이다.
http://h10032.www1.hp.com/ctg/Manual/c01814597.pdf
==
지원되지 않는 구성
• 기존 P4000 SAN Solution 스토리지 위에서 VSA를 실행하는 것은 권장되지 않습니다.
• VSA의 가상 NIC는 Jumbo 프레임, 흐름 제어 설정 수정 또는 TCP 오프로드를 지원하지 않습
니다. 서버의 물리적 NIC를 이러한 기능으로 구성할 수 있습니다
.
• VSA의 가상 NIC는 이 시점에서 10Gb/s를 지원하지 않습니다. 서버의 물리적 NIC가 10Gb/s일
수 있습니다
.
• 2개의 가상 NIC 사이의 NIC 본딩은 지원되지 않습니다.
• 가상 하드 디스크 및 패스 스루 디스크의 추가 또는 제거는 지원되지 않습니다. Microsoft
Linux Integration Services 사용 설명서를 참조하십시오.

지원되지 않는 구성 및 모범 사례에 대한 자세한 내용은 HP StorageWorks P4000 SAN Solutions
사용 설명서를 참조하십시오.
==
Jumbo Frame 지원이 안되고, TCP 오프로드 지원이 안되니 IOPS가 급격하게 떨어질터이고,
10G를 지원안하니, 사실상 P4000으로 VSA 구성을 할경우 Hypervisor용 Storage로 사용할 경우 성능에 치명적일 수 있을 것 같다.
 서버 설계시에는 필히 확인해야 쓰겄다.
다음에는 NetApp 장비를 써보던가. NetApp 장비를 좀 교육 받아보던가 해야 쓰겄네...
혹시 위의 P4000 VSA에 대한 Hyper-V 제약 사항이 틀린점이 있으면 알려주세요.

4/11 추가 Comment
http://www.hyper-v.nu/blogs/hans/?tag=hp-lefthand
이 문서들 보면 또, Hyper-V랑 P4000 시리즈랑 잘 맞는 것 같기도하고... 좀 들여다 봐야되나.. -_-;



SAN 네트웍은 MTU를 1500이상 설정하는 Jumbo Frame을 고려할것.
TCP Handshaking을 생략하는 TCP Off Loading을 고려할것
디스크 포맷시, 프레임 사이즈를 64K 이상의 대형 프레임 사용을 고려하여, IO 성능을 높일것

IOMeter

클라우드 컴퓨팅 & NoSQL/분산컴퓨팅&클라우드 | 2011.03.30 00:35 | Posted by 조대협
IOPS 측정하는 도구가 있었군.
내일 iSCSI 구성한 것 성능 체크좀 해봐야겠다.

참고 자료



P. 10 of Iometer guide:
The Edit Access Specification dialog shows you how the disk will be accessed. The default is 2-Kilobyte random I/Os with a mix of 67% reads and 33% writes, which represents a typical database workload. You can leave it alone or change it. Press OK to close the dialog when you are through.
For maximum throughput (Megabytes per second), try changing the Transfer Request Size to 64K, the Percent Read/Write Distribution to 100% Read, and the Percent Random/Sequential Distribution to 100% Sequential.
For the maximum I/O rate (I/O operations per second), try changing the Transfer Request Size to 512 bytes, the Percent Read/Write Distribution to 100% Read, and the Percent Random/Sequential Distribution to 100% Sequential.

네이버 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이 되는 걸로 알고 있긴 한데....


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