Windows 2003 & Transparent Failover Mode ???

[Colin Pasfield]

Hi,

I have a Windows 2000 server connected to the SAN in Transparent Failover mode. When I upgrade the server to Windows 2003 I lose all connectivity to the SAN. The disk is not listed in Disk Administrator. However, the HSxDISK driver loads successfully and the HSG80 sees the connection as on line. (I even upgraded HBA drivers and the ACS Solution Software to V8.7)

I know HP don't support Windows 2003 in Transparent Failover mode (they want us to buy securepath and run in Multibus mode - a bit rude when Windows 2000 was supported and there's only one line in the ACS 8.7 release notes that mention the discontinued support). However, I also have several clean installed Windows 2003 servers which work correctly in Transparent Failover mode. One of these even works using the default Emulex/Microsoft LP8000 HBA driver and NO ACS Solution Software installed!

My question is - Has anyone successfully upgraded Windows 2000 servers to Windows 2003 and retained SAN connectivity in Transparent Failover mode?

How did you do it?

Thanks,
Colin Pasfield.

[Erwin van Londen]

Collin,

From a cost perspective running in transparent mode is allright but if your looking for redundancy and performance you should definitly turn to multibus. Besides that you're now stuck with a controller you paid for and your not even using it.

With regards to your question. Windows2003 uses a different driver model. Try reinstalling the HBA drivers from HP. Do NOT use the original Microsoft drivers because they mis a lot of tuning. These are the drivers that have to work with all storage subsystems wich means then lack functionality and performance optimisation for the specific HP storage subsystems.

P.S. If you do buy SecurePath you are able to do loadbalancing over both HBA's. Quite performance boost I must say. (As of version 4.0c)

Regards,
Erwin van Londen.
HP Master ASE SAN Architect.

[Colin Pasfield]

Thanks Erwin,

You're right about using Securepath and multibus mode for superior redundancy.

My immediate concern is managing Windows 2003 upgrades for at least a dozen servers connected to populated MA12000s via two pairs of HSG80s. I would need to do a massive amount of concurrent s/w & h/w aquisition and shuffling and reconfiguration to move to a Securepath/Multibus environment.

I was merely hoping to avoid this by maintaining the currently supported Transparent Failover environment. It would be very nice if I had a way to do so.

Your comments are much appreciated.

Thanks and Regards,
Colin Pasfield
NSW Dept of Education and Training

[Erwin van Londen]

Collin,

One last thing you might look at. I do'n't know if the default setting for extended LUN is ON (LUN id's bigger than 7) if you upgrade from W2k to W2k3. If you present LUNS with a lun id bigger than 7 maybe windows doesn't see the drives. Again I haven't tryed it so maybe if you could fool aarounf a bit with connection offsets it starts working again. On the other hand I can't imagine that MS roles back there policy of supporting more than 7 luns. (In W2k with extended lun support it's 64)

What SCSI version is the ACS running, 2 or 3 ?

Regards,
Erwin van Londen
HP Master ASE SAN Architect.

[Colin Pasfield]

Hi Erwin,

Thanks for the ideas.

The latest developments are we're currently negotiating SecurePath purchases and a migration to MultiBus mode. We have several other cabinets for VMS and True64 systems in MultiBus mode. We can use these to migrate Windows servers one at a time until we can reconfigure our Windows Transparent Failover MSA1200s. This will require some work but will benefit us in the long run.

For interests sake, we're using both HSG's anyway with offsets below and above 100.

Thanks for your help.

Regards,
Colin Pasfield
NSW Dept of Education and training.

[David Borojevic]

We have a pair of HSG80's also in transparent failover mode (single HBAs etc for cost savings etc). We have a mixture of Windows 2000 and 2003 (but none upgraded) and all works fine. Although LUNS with a signature written by a 2003 server are not happy when moved to a 2000 server (but that isn't relelvant here), the reverse seems OK.

We haven't upgraded any servers yet but given it works for fresh installs, it must be driver related?. Have you tried removing the driver and perhaps even the HBA and do it from scratch?

We have a need to upgrade some servers soonish, I am interested in the outcome. I might be able to expidite a test if your interested to compare notes.

Cheers
David Borojevic
Department of Education, Tas

[Uwe Zessin]

Hello,
if it is helpful, I have a Windows 2000 server that was set up a short time ago. It has the latest drivers and Secure Path V4.0C. I didn't do the base OS installation, but I also didn't do anything special during the driver and Secure Path installation either.

It is connected to an EVA, which looks like a HSG80 with SCSI_VERSION = SCSI-3 in MB_FAILOVER mode.

I have just created a small virtual disk and mapped it to LUN #9. After a 'rescan disks' the LUN came up right away.

[Colin Pasfield]

David,

I tested several upgrade scenarios none of which worked. I pretty much tried everything except actually removing the HBA. Me being me I documented the whole test procedure and will gladly email you the notes if you would like.

I've spoken to my local HP SAN guy about it all. He said he had some kind of joy by ensuring 1) SCSI-3 mode, 2) CCL Enabled, and 3) dummy D0 and D100 units created with access enabled for each connection. I haven't tried this but it might be good to keep in mind.

Let me know your email and I'll send the notes over.

Regards,
Colin Pasfield.
NSW Dept of Education and Training.

[Uwe Zessin]

Colin,
last time I checked with SCSI-3 the CCL is always enabled these days (it wasn't in early versions of ACS). The CCL will overlay unit D0 - I beleive the controller will give a warning when you set it to SCSI-3.

I vague recall some writing that there is no CCL on Port_2 of the controllers in TF-mode, but I am not sure and I don't have time to try it out.

[David Borojevic]

david.borojevic [no spam] at education.tas.gov.au.

I might be able to test but not for a couple of weeks. Our migration of exchange to 2003 project is in its early days and we are not sure whether any of the servers will be upgraded in situ as we have a hardware refresh also.

The bit in my previous post was wrong...
>Although LUNS with a signature written by a 2003 server are not happy when moved to a 2000 server (but that isn't relelvant here), the reverse seems OK.

The problem is with disks initially on 64 bit 2003 being published to 32 bit 2000 boxes. 64 bit 2003 to 32 bit 2003 box is OK but you have to convert to MBR and things are OK.

[scott haddow_1]

Hi Colin,

I'd be grateful if you could send me the test notes you mentioned. HSG80/W2K3/transparent failover is very badly documented.
haddow@hp.com

Scott

[Colin Pasfield]

Scott,

After some lengthy investigation by local HP, we have found that the lack of support (for Transparent Failover Mode on Windows 2003) is indeed due to technical reasons and not marketing reasons.

The summary from engineering was:

"W2003 cannot support tranparent failover mode using HSG80s. The W2003 SCSIport driver considers the two HGS80 controllers with different serial numbers as two different plug and play devices. If a controller fails, the plug and play will see that one controller has gone away, and a new one has appeared. It will mount the new controller with the disk drives attached behind it. However, any data that was queued up to be written or read from the original controller is lost. That's data loss and is unacceptable, thus tranparent failover mode cannot be supported with HSG80 controllers and W2003. W2000 did not do this (ie W2000 didnâ t care about the different serial numbers of the HSG80s when failover happened, so it really was transparent to W2000)"

So, basically this means any Windows 2000 storage in Transparent cabinets must be moved to Multibus cabinets when upgrading to Windows 2003 and Secure Path must be used.

This essentially renders my testing notes you've asked for as meaningless. Though I look back on the whole experience now with nostalgia.

Cheers,
Coli

[scott haddow_1]

Many thanks Colin - that has finally cracked the worst documented technical problem at HP!

Scott