Newbie question about P4300 and FOM

[sailingbikeruk]

We have recently installed two P4300's in a single site cluster with failover manager running as a virtual appliance on VMware. At the weekend it was necessary to shutdown the ESX host that hosted the FOM so I first shutdown the FOM from within the SAN/iq software. After doing this all files on all volumes accessed through windows iscs initiator were either lost or corrupt ( I lost all exchange transaction logs and the edb files as well as one SQL database with its associated log file. I had to recover files from backup to get them back. The VM's were fine though and came back online without trouble. I am assuming that this only affected the NTFS volumes as the doesn't appear to be any evidence to the contrary. I have checked and both nodes are running as normal managers, with FOM this should make the quorum 2 so I thought for a short time this would be ok. I guess my questions are: 1) what would cause this corruption/loss of data? 2) why did the files "disappear" even though they hadn't been deleted 3) how can I ensure this doesn't happen again ( for instance if the FOM fails at some point). I am very concerned now as both exchange an SQL use this storage but I have lost confidence that it is as secure and redundant as I first thought. As the title suggests I am fairly new to HP Lefthand so any and all suggestions and advice greatly received.

[Dirk Trilsbeek]

if you really are running managers on both nodes, this should in fact never happen. But as this only affected the windows machines, maybe the configuration of the iSCSI initiator on the affected machines has something to do with it. Are you using HPs MPIO driver or the default Microsoft Initiator? I never used the HP MPIO driver, but if you did, did you add the FOM as a path to a volume?

[sailingbikeruk]

We are using the default is is initiator. There is only one vnic seen by windows multipathing/failover is handled by VMware port binding on the San vswitch. It could of course have been caused by something other than the left hand stuff it just seems strange that I lost everything and when I researched it I had files up to the point I turned off FOM even though they were corrupt.,it just seems strange that all the windows volumes were affected on two windows servers. The SQL database says it wasn't closed properly and I am struggling to rebuild it because it keeps looking for the log file (.ldf) on a folder that even file recovery software can't see (but was there prior to this event). It's all very strange.

[Dirk Trilsbeek]

Are you presenting the same lefthand volune to more than one windows system?

[David_Tocker]

Are you running the FOM on a seperate host? Best practice indicates this as a requirement. The FOM should NEVER be run off the p4000 itself for what should be obvious reasons. The FOM serves as a tie-breaker so should continue to run independantly even if the rest of the infrastructure is disabled/offline.

The FOM has very low requirements so can be run on even a VT capable laptop (if you think about it, a laptop has a battery so is not actually a bad choice)

[David_Tocker]

Also, keep in mind switching architecture,

You should be running seperate VLANs for the iSCSI traffic - and the ports in this VLAN should be running flow control - Jumbo frames are not necessary in most cases and are likely/possible to cause issues - especially if you are running with lower-end switches (this is probably why HP recommend the procurve 2910al switches for P4000)

If in doubt, drop the jumbo, keep the flow control.

STP can be an issue - make sure you have the equivalent of a 'portfast' command applied to each iSCSI port as you do not want to wait for STP negotiation.

I would recommend disabling STP on the ports of smaller architectures to keep it simple - if you can have dedicated switches for iSCSI even better,

I recommend using ALB vs LACP in most cases - much less issues, only a little less performace - and if your switches cannot support stacking/irf then you will really have no choice if you want redudancy. (interswitch LACP trunks is what this is all about)