HP EVA8100 config connected to IBM SVC

[Stuart.Coleshill]

Has anyone had expeience with this set up. I want to know if it's better to go with standard EVA practice and have all hard drives contained in a single disk group or whether I should go with SVC best practice and make up seperate disk groups to allow me to have 1 lun/vdisk per disk group.

The reason for this is that using a single disk group all Vdisks created on that group are written over every physical disk in the array.

When I present these EVA vdisks to the SVC as Mdisks to make an Mdisk group, vdisks created on the SVC Mdisk group are striped over every mdisk.

This means that each physical disk in the array could be used more than once by each SVC Vdisk and thus I suspect will reduce performance of the array.

I've not been able to find any best practice/ set up guide for the EVA8100 when connecting it to the IBM SVC.

Can anyone confirm if using seperate disk groups for each EVA Vdisk is a better option.

Ta, Stu

[IBaltay]

Hi,
from the EVA perspective its strength is in the perf rule the more disk in the DG the more performance. If you do it in a different way, you are reducing the EVA to the JBOD and no SVC can then help to scale the performance

[IBaltay]

maybe the chapter 7 integrating the SVC in a SAN with HP EVA gives us more information:
http://www.redbooks.ibm.com/abstracts/SG247275.html?Open

[Uwe Zessin]

The maximum size of a virtual disk is 2 TeraBytes. If you want only one vdisk per disk group, you can easily do that with two handful of 300GB disk drives. But: the EVA architecture (currently) limits the maximum number of disk groups to 16.

I'd be happy to sell you many EVA-8100 with many disk groups ;-)
but I am not so sure you will be happy.

[qiyongquan]

i want to know what's the IBM SVC ?

[Stuart.Coleshill]

Thanks for the suggestions so far, Iâ ll respond to them in one hit.

IBM SVC â SAN Volume Controller. It allows you to connect several different storage arrays to it and manage Vdisks on all of them from a single point. The hosts see the SVC as the storage array and have no concept of where their vdisks are actually stored. This has many benefits in terms of reducing down time and tiering you storage and applications.

We have 8 shelves and so Iâ d plan to make 14 disk groups with a single LUN on each. This would give me 14 * 1.9Tb LUNS and each physical HD is only used by one LUN. This (I believe) would work better when presented to the SVC as the 14 LUNS will be grouped into a single Mdisk group on the SVC and any SVC Vdisks would be striped over these 14 LUNS, hence effectively achieving the same result as a single disk group on the EVA when LUNS are presented directly to a host.

Unfortunatel the Red book doesnâ t give any recommendations on configuring the disks/LUNS on the EVA, it just goes through the LUN migration process and connecting the EVA to the SVC.

Anyway, thanks again, Stu

[IBaltay]

Hi,

...what is the advantage to divide the EVA backend into14 DG?
Could not be better simply to present the VDISKs from within 1 or 2 DGs to have nice backend distribution across as many physical disks as possible?

Then you can SVC stripe them like with LVM if needed.

One big VDISK does not give any good backend nor front end loadbalancing features

[IBaltay]

one additional comment:
the architecture of EVA is very different from e.g. the midrange DS storages because of the controller based virtualisation and leveling features...

[Stuart.Coleshill]

That is what I'm trying to find out. Which will be best for use behind SVC.

The SVC will still use all the physical disks whether I use 1 or 14 disk groups.

Remember that the vdisks created on the EVA are grouped by the SVC and the vdisk created in that group on the SVC is striped across all the EVA Vdisks and this is what gets presented to the host, not the vdisks created on the EVA.

[IBaltay]

the EVA best practices says the more disk in the DG the better performance. Your intention is to have relatively very small amount of physical disks in the DG. Thus you are reducing the performance of the EVA to MSA or even less...
If you SVC stripe them you are working with the relatively small cache and poorly virtualized disks. (thus you are redesigning the native architecture of EVA, you are going against it).

RESUME

SVC, as a good initiator and targer (needs to be for hosts) is something like LVM and LVM is nicely used on EVAs with big DGs and smaller VDISKS to reach the optimum front end load balancing in Unix/Linux...

[Uwe Zessin]

Another point I think which has not been covered is the handling of disk failures.

The EVA does not use dedicated spare disk drives - it includes the disk drive mechanices into the disk group and virtualizes their space as well. So data and 'protection space' (defined by the so-called 'protection level' - horrible name as it DOES NOT provide the RAID protection!) share the same set of disk drives. The idea is that the 'spare drives' can be used for user I/O as well.

The size is calculated as 0, 2 or 4 times the size of the largest disk drive in the disk group. Yes, it is per disk group!!