Celerra NS352/NS502g iSCSI performance in VMWare ESX

I wouldnt expect that much of a difference.

They both have the same class of data mover in terms of CPU and memory - however the NS350 uses a CX300 that is two classes below the CX700.

Are you sure you are comparing apples to apples ?

I mean:
- are the network and other settings the same ?
- is the disk layout similar in terms of the number of disks and the type ?

OK, I understand differences between CX backends.
In any case, network setups are the same but there is clearly a difference in disk layout: NS352 has only a box of disks while CX700 has an higher number.

thats probably the issue - with just 15 disks it isnt that easy to create a performance config. At least not with AVM - you would have to use manual volume management

run a /nas/tools/.whereisfs -all on both boxes and post the relevant details for the file systems you are comparing

Relevant filesystems are fs_iscsi*

Thanks


######################################################################
NS352
######################################################################
$ /nas/tools/.whereisfs -all
RG FS's
----- ------
CK200060800897-0000 [ 1] fs_destination (d7)
CK200060800897-0008 [ 4] fs_iscsi1 (d9) fs_iscsi2 (d9) fs_iscsi3 (d9) fs_pegaso (d9)


FS Resources (RGs: [total # of RG] {repeated for each RG} )
----- ------
fs_destination RGs: [ 1] CK200060800897-0000; LUNs: 0010 0011
fs_destination... WARNING! FS fs_destination uses more than 1 LUN from some of its RAID groups.

fs_iscsi1 RGs: [ 1] CK200060800897-0008; LUNs:
fs_iscsi1... WARNING! FS fs_iscsi1 uses more than 1 LUN from some of its RAID groups.

fs_iscsi2 RGs: [ 1] CK200060800897-0008; LUNs:

fs_iscsi3 RGs: [ 1] CK200060800897-0008; LUNs:
fs_iscsi3... WARNING! FS fs_iscsi3 uses more than 1 LUN from some of its RAID groups.

fs_pegaso RGs: [ 1] CK200060800897-0008; LUNs:

RAID Groups in use:
RG LUN (dVols) FS list
----- ------------- --------
CK200060800897-0000 0010 (d7 ) fs_destination
0011 (d8 ) fs_destination

CK200060800897-0008 0012 (d9 ) fs_iscsi1 fs_iscsi2 fs_iscsi3 fs_pegaso
0013 (d10 ) fs_iscsi1 fs_iscsi3



######################################################################
NS502g
######################################################################
$ /nas/tools/.whereisfs -all
RG FS's
----- ------
CK200060701863-0001 [ 1] fs_996 (d22)
CK200060701863-0109 [ 7] fs_006_new (d15) fs_004 (d14) fs_005 (d14) fs_000 (d15) fs_999 (d14) fs_998 (d15) fs_sorgenti (d15)
CK200060701863-0110 [ 8] fs_006_new (d17) fs_003 (d17) fs_004 (d17) fs_005 (d17) fs_001 (d17) fs_000 (d18) fs_998 (d17) fs_iscsi4 (d17)
CK200060701863-0111 [ 7] fs_005 (d19) fs_002 (d19) fs_001 (d19) fs_000 (d20) fs_999 (d19) fs_998 (d20) fs_iscsi4 (d19)
CK200060701863-0113 [ 6] fs_006_new (d23) fs_005 (d23) fs_iscsi4 (d23) fs_997_bk (d23) fs_007 (d26) fs_RBM (d26)
CK200060701863-0115 [ 5] fs_006_new (d25) fs_004 (d24) fs_iscsi5 (d24) fs_formaro (d25) fs_geox (d25)


FS Resources (RGs: [total # of RG] {repeated for each RG} )
----- ------
fs_000 RGs: [ 3] CK200060701863-0109; LUNs:
fs_000... CK200060701863-0110; LUNs:
fs_000... CK200060701863-0111; LUNs:

fs_001 RGs: [ 2] CK200060701863-0110; LUNs:
fs_001... CK200060701863-0111; LUNs:

fs_002 RGs: [ 1] CK200060701863-0111; LUNs:

fs_003 RGs: [ 1] CK200060701863-0110; LUNs:

fs_004 RGs: [ 3] CK200060701863-0109; LUNs: 001A
fs_004... CK200060701863-0110; LUNs:
fs_004... CK200060701863-0115; LUNs:
fs_004... WARNING! FS fs_004 uses more than 1 LUN from some of its RAID groups.

fs_005 RGs: [ 4] CK200060701863-0109; LUNs:
fs_005... CK200060701863-0110; LUNs:
fs_005... CK200060701863-0111; LUNs:
fs_005... CK200060701863-0113; LUNs:
fs_005... WARNING! FS fs_005 uses more than 1 LUN from some of its RAID groups.

fs_006_new RGs: [ 4] CK200060701863-0109; LUNs:
fs_006_new... CK200060701863-0110; LUNs:
fs_006_new... CK200060701863-0113; LUNs:
fs_006_new... CK200060701863-0115; LUNs:

fs_007 RGs: [ 1] CK200060701863-0113; LUNs:

fs_996 RGs: [ 1] CK200060701863-0001; LUNs: 0020

fs_997_bk RGs: [ 1] CK200060701863-0113; LUNs:

fs_998 RGs: [ 3] CK200060701863-0109; LUNs:
fs_998... CK200060701863-0110; LUNs:
fs_998... CK200060701863-0111; LUNs:

fs_999 RGs: [ 2] CK200060701863-0109; LUNs:
fs_999... CK200060701863-0111; LUNs:
fs_999... WARNING! FS fs_999 uses more than 1 LUN from some of its RAID groups.

fs_RBM RGs: [ 1] CK200060701863-0113; LUNs:

fs_formaro RGs: [ 1] CK200060701863-0115; LUNs:

fs_geox RGs: [ 1] CK200060701863-0115; LUNs:

fs_iscsi4 RGs: [ 3] CK200060701863-0110; LUNs:
fs_iscsi4... CK200060701863-0111; LUNs:
fs_iscsi4... CK200060701863-0113; LUNs:
fs_iscsi4... WARNING! FS fs_iscsi4 uses more than 1 LUN from some of its RAID groups.

fs_iscsi5 RGs: [ 1] CK200060701863-0115; LUNs:

fs_sorgenti RGs: [ 1] CK200060701863-0109; LUNs:

RAID Groups in use:
RG LUN (dVols) FS list
----- ------------- --------
CK200060701863-0001 0020 (d22 ) fs_996

CK200060701863-0109 0018 (d15 ) fs_006_new fs_000 fs_998 fs_sorgenti
0019 (d14 ) fs_004 fs_005 fs_999
001A (d16 ) fs_004

CK200060701863-0110 001B (d17 ) fs_006_new fs_003 fs_004 fs_005 fs_001 fs_998 fs_iscsi4
001C (d18 ) fs_004 fs_005 fs_000

CK200060701863-0111 001D (d19 ) fs_005 fs_002 fs_001 fs_999 fs_iscsi4
001E (d20 ) fs_000 fs_999 fs_998 fs_iscsi4

CK200060701863-0113 0021 (d23 ) fs_006_new fs_005 fs_iscsi4 fs_997_bk
0024 (d26 ) fs_007 fs_RBM

CK200060701863-0115 0023 (d25 ) fs_006_new fs_formaro fs_geox
0022 (d24 ) fs_004 fs_iscsi5

######################################################################

sorry for the late response - but that explains it.

I cant tell from the output how many disks are in each raidgroup but lets assume the defaults that on the NS352 you have a 4+1R5 and 8+1R5 and on the NS502G its all 4+1R5

If you look at for example fs_iscsi1 on the NS352 you'll see that it uses two LUNs (d9,d10), but they are on the same raidgroup which doesnt really help in terms of performance. Its either hitting 5 or 9 disks.

On the NS502 on the other hand fs_iscsi4 is using four LUNs (d17,19,20,23) on three different raidgroups. So that's probably 3x5=15 disks, maybe even on two or more backend FC loops.

To improve the NS352 I can see:

- if possible get one more DAE with 15 disks and reconfigure your file systems to use at least two LUNs and raidgroups - four would be better.

- if not you could at least put the file system on all 15 disks by using manual volume management and striping

- or if capacity isnt an issue and you cant get more disks you could try to use RAID1 and stripe across them - doesnt get more disks enagage but you would save on parity calculation and writes

When using MVM make sure you also stripe across LUNs owned SPs so that you get both engaged.

In general AVM does a good job to distribute file systems across disks, SPs and backend busses - but with only 15 disks it cant do much. It relies on having equal-sized LUNs that it can stripe together - but with just one DAE there just arent many.

Thanks to your explanation, all sounds more clear to me.
I will put Exchange on a filesystem on the NS502g/CX700 and verify if there are improvements, especially if Event Log alarms about latency times.
Next year, I will consider the buying of another DAE and more cache (if possible).

Thank you

depending on your environment using RAID1 for Exchange might be a very viable option.

Talk to your IP storage TC - we have done quite a number of Exchange ISCSI tests as part of the ESRS submissions and on smaller configs RAID1 helped to handle the same amount of users with less disks compared to RAID5.

We do have quite good config recommendations for various Exchange sizes

P.S. You're very welcome. Of course this was only a crude advice without analyzing various performance traces.

By the way, what's "IP STorage TC"?

sorry for the internal lingo - it means IP Storage Technology Consultant - basically your EMC Systems Engineer responsible for NAS, ISCSI and other IP Storage products