Round Robin, not for production?

[SpaceHonkey]

Why not?

Also, should I be concerned about LUN thrashing using RR with an active/passive array? We've got 2 hbas/blade, 2 switches, 2 hbas/storage processor.

 

[AreEss]

Uh, because you will basically make the controller lose it's mind. When you pass traffic down the passive path, it has to go to active and the other goes to passive. Then you flip-flop it.

Either get a proper array controller or get proper drivers.

There are no other acceptable answers, workarounds, or hacks in a production environment.

 

[SpaceHonkey]

Seems the DS3400 turns off AVT when the host type is 'vmware' - have not noticed any issues yet...

 

[AreEss]

*perks* You said DS3400! I am intimately familiar with the DS3400. It's an LSI-based A/P low-end array. (The DS4200 "mid-range" has been replaced by the DS3400. HA! HAHAHAHAH! It's an $85,000 price difference at list. Guess which of the two is the faster array!)

Anyways. DS3400's an odd beastie, but easily handled. Presuming that you're on VMWare ESX 3.5 or later, the A/P handling is built into VMWare. (IBM/LSI use SNIA standard A/P signalling, unlike EMC and others.)
You should be monitoring it with Storage Manager on a machine. It'll only flag if it's off preferred path AND monitored with DS3k Storage Manager AND you're off preferred path for more than 5 minutes. Also RSM, if you have that support contract, of course. I highly recommend RSM, wonderful tool. But even if you can't, Storage Manager can alert you by email to any problems. Either way, you should be covered with ESX 3.5 - no multipath driver required. It does require AVT be off though, yes.

Do NOT go past the 6.70.35.00 firmware; there are MASSIVE problems with the 7.3x.xx family on ALL arrays. The DS4000-series has had every released version of the 7.3x.xx firmware revoked within a month due to bugs that have wiped out data, put controllers into permanent reboot loops, and a long list of other issues. I don't trust it on ANY DS3k/DS4k arrays, there have been too many problems and too much shared code.

 

[lopoetve]

Why not?

Also, should I be concerned about LUN thrashing using RR with an active/passive array? We've got 2 hbas/blade, 2 switches, 2 hbas/storage processor.

failover won't work, lun trespasses will lock up the array, ESX isn't designed to use RR safely yet, you won't be supported, and it'll break your shit

A/P arrays especially are not built for RR.

 

[lopoetve]

Seems the DS3400 turns off AVT when the host type is 'vmware' - have not noticed any issues yet...

avt isn't the issue - it's the entire array design. You need active/active, and even then, it's not yet reliable enough.

 

[SpaceHonkey]

I've got RR on now, no crashes or thrashing (since AVT is auto disabled), but it's definetly not balancing. I'm only getting 50MB write to a 5 disk RAID5 LUN, and it is only using one path, no balancing... (doing a sVmotion)

 

[lopoetve]

I've got RR on now, no crashes or thrashing (since AVT is auto disabled), but it's definetly not balancing. I'm only getting 50MB write to a 5 disk RAID5 LUN, and it is only using one path, no balancing... (doing a sVmotion)

When it bombs, good luck.

It doesn't work yet, and it's very unreliable on some arrays. Just balance the load manually and be happy

Oh, and protip people: Do NOT use the sVmotion plugin anymore. It's broken - I'm seeing something like a 60-70% failure rate these days...

 

[SpaceHonkey]

We'd appreciate sVmotion natively in VIC!

Another thing missing is that you can't easily find out how much storage a VM is using without manually adding it up - as in including snapshot sizes.

 

[lopoetve]

We'd appreciate sVmotion natively in VIC!

Another thing missing is that you can't easily find out how much storage a VM is using without manually adding it up - as in including snapshot sizes.

It's rumored to be coming.

Don't keep snapshots - they're only for patching and testing updates, not for production. That way the size used is the size of the VM... unless you're also thin provisioning