SAN Config Best Practice and RSCN

[Neil Lowden]

I am looking for best practices and experience of adding an ESL library to an existing SAN comprised of exclusively OpenVMS Alpha and I64 host systems, EVAx000's and B-Series switches.

I heard it is unwise to directly connect an ESL to the same switches as the hosts/EVAs because the floods of RSCNs generated by the ESL when it experiences drive problems can have detrimental affects on the hosts/EVAs. Someone suggested zoning per-HBA can be applied in this scenario to isolate the ESL to selected hosts but I have never seen this as a documented practice.

Another suggestion was connecting the ESL to a new FC switch, nominating one host as a backup server, and connecting that host to the new switch, effectively forcing all ESL traffic thru the backup server. I can see possible advantages here in terms of offloading ESL traffic from the other hosts and that RSCN floods would be isolated but if RSCN floods are truly detrimental then the backup server would still be affected.

However, back to basics, are RSCN floods really a bad thing? What will happen to the hosts and EVA in an RSCN flood? Is there any established best practice in this scenario?

[Tim Nelson]

Here is my 2cents.

Logically it would be best practice to separate your disk ios from your backup/tape ios. Read via 1 hba and write down the other. Makes logical sense in the perfect world.

With that said. Depending on your io needs during the backup times it may not be neccessary to aquire the extra HBAs to do this. The systems and backups may just work find and they are in plenty of installations.

My experience with VMS showed a severe issue with backup even when using segragated HBAs, VMS seemed to read until buffer full, keep queueing up the reads while writing to the tape, then try and catch up. The tape would not keep rolling. In three years of messing with this I never was able to get VMS to keep the tape moving. This may have been due to the older HW I had that could not keep data flowing across the bus ?

If you have the money then do the logical thing and separate the disk ios from the tape ios, zone the switches as neccesary.

The big trick is to keep the tape drives moving.


Best of luck.

[krusty]

Neil,

Sounds like Tim has some good info about OVMS, which I will not claim to know much about. However, a workaround to the "keep the tape moving" issue is to use multithreading (or concurrency) where multiple hosts write to the tape at the same time. Multiple data streams from the multiple hosts boost the relative throughput to the tape drive. The main drawback is that restores will take longer, as data has to be pulling from the interleaved data on the tape.

Cheers,

Curt