VA7xxx의 리던던시 그룹에 대해 답변 주세요

[국호]

안녕 하세요 포럼에 답변 보다는 질문을 많이 하는데요.

정말 죄송 하고요.



제가 VA을 공부중인데. VA특성중 하나가 리던던시 그룹이 있다는것 입니다.



이 리던던시 그룹이 어떤 영향을 주는지요??

아시겠지만 va7100/7110은 리던던시 그룹이 한개 뿐입니다.



va7400/74100은 리던던시 그룹이 2개죠??



저번에 제가 cvsdm을 이용해서 va7400을 보았는데..



리던던시 그룹이 다음과 같았습니다.



리던던시 그룹1 사이즈가 좀 크더라구요. (홀수)

리던던시 그룹2 사이즈가 좀 작아요 (짝수)



이렇게 되어져 있더라구요. 혹시 RAID 구성을 서로 다르게 하기 위함인지요?? 아니면 리던던시그룹을 이중화 하여 data의 무결성을 좋게 하기 위함인가요?? (무결성은 말이좀 안되는듯 하네. 성능이라구 할까)



va는 autoraid변환이 되는데 리던던시 그룹을 1 -> 2로 만든것은 어떤 특수한 이유가 있어서(성능향상) 해놓은듯 한데요..??



리던던시 그룹을 명쾌하게 답변 주실 멋진분 안계신지요???



단순히 이중화라구 말씀 하지 마시구요..



부탁 드립니다. 좋은 답변 주면 10점 만점 드릴께요..



좋은 하루 되세요..

[Joseph]

예전에 엔지니어시절때 알게 된 내용입니다.



VA74XX에 대한 2그룹의 리던던시에 대해서 Raid구성을 서로 다르게 할 수 없습니다.

즉, 리던던시 A,B그룹 모두 동일한 Raid구성으로만 되죠..



그리고 A,B그룹 두개로 나눔으로서 I/O성능이 좋아지죠..



아래 ITRC문서를 참고하세요..



Lun을 여러개 만든다고 I/O성능이 좋아지는 것이 아니고 아래 문서처럼



해야 I/O성능이 좋아지죠...





-ITRC VA7XXX에 대한 성능개선 -

ISSUE: A large capacity LUN configuration may need HPUX tuning for optimal performance using Virtual Array (VA) products.



CAUSE: While especially in OLTP-environments where there are typically a large number of concurrent I/O-requests going on, having only a small number of very large LUNs may indeed lead to a performance problem. The root cause of this problem has never been on the VA-side. In other words: from the VA7400 or VA7410's perspective, the performance of 10 x 50 GB LUNs per redundancy groups is exactly the same as the performance of a single 500 GB LUN per redundancy group.



The reason for experiencing very severe throughput problems when using just the 2 x 500 GB LUNs is with HP-UX each disk device (more precisely each path to a LUN) has a default scsi queue depth of "8." This means that with just two giant LUNs there can only be a maximum of 16 outstanding I/O-requests to the VA at any time. While the VA may be able to process a lot more I/O requests in parallel, since it may be stuffed with 60 disks in the backend.



SOLUTION: The easiest solution to this problem does not necessarily consist in creating more and smaller LUNs. Use the "scsictl -m queue_depth= /dev/rdsk/..." command. This will increase the queue depth for giant LUNs in order to allow sufficient concurrency (for example, the amount of concurrency that will allow the use of the full performance of all disks in the array).



With HP-UX 11.0, each new activation of an LVM volume group (after a reboot or an MC/SG-package start) will reset the scsi queue depth to its default value of "8" (or whatever the kernel setting for "scsi_max_qdepth"). This means that in order to ensure the appropriate scsi queue depth setting for giant LUNs, a script will be required which automatically adjusts the queue depth for these LUNs at boot time or at MC/SG-package start. As this may be perceived as cumbersome, using several smaller LUNs with the default scsi queue depth might be more convenient with HP-UX 11.0. With HP-UX 11i, on the other hand, the scsi queue depth set with "scsictl -m ..." will survive de- activation or re-activation of volume groups (including reboots) which is why with HP-UX 11i. It is recommended to use the alternative of using a minimal number of large LUNs (at least one per RG, of course) and then increasing the queue depth for those large LUNs.

[Jongmin, Lee]

VA의 리던던시 그룹의 역할은 성능 향상을 위해서와 장애시 영향을 최소화하기 위함입니다.



디스크슬롯 0,1,3,...은 리던던시 그룹 1,

디스크슬롯 1,2,4,...는 리던던시 그룹 2로 정의되며,

각 리던던시그룹은 두개의 컨트롤러에 각각 ownership이 정의되어 있습니다.

보통의 어레이는 LUN을 구성하고 그 LUN에 컨트롤러의 ownershio을 정의하게 되는데, 이때 적절하게 분배하지 않으면 성능 감소의 원인이 될 수 있습니다.

그러나 리던던지 그룹2개에서 LUN을 만들면 자동으로 딱 반띵이 되게 되겠죠...악의적으로만 만들지 않는다면요.



또 disk장애시에 hotspare 디스크로 rebuilding작업이 일어나게 되는데, 이때 어느 하나의 리던던시그룹에서의 rebuilding작업은 다른 리던던시그룹에 영향을 미치지 않게 됩니다. 이또한 성능상의 잇점을 갖기위함이겠죠



참고로 하이레인지 스토리지일수록 이 리던던시그룹의 숫자가 많아지게 됩니다. XP계열은 disk 4개마다 하나의 리던던시그룹의 개념(좀 틀리지만)을 사용합니다. EMC symmetrix/DMX 계열도 마찬가진걸로 알고요



이상 허접답변이어씀다~^^



PS. 두게의 리던던시그룹의 크기가 틀린것은 disk갯수가 홀수개이기 때문일껍니다.