A Guide to Success with the A5814A-003 SCSI-FC Router

ManualsBrandsHP ManualsSoftwareMPE/iX 7.0 Operating System

(or)

A bunch of stupid things I've done and seen that you should avoid

BY: Jim Hawkins -- MPE/iX Lab

April 21st, 2003

The A5814A-003 SCSI-

FC Router (a.k.a. "Router") is a unique piece of hardware. In our collective

experience in the MPE/iX Lab we have found it to be a very reliable, high performing, and

trustworthy part of the data center environment. That being said a A5814A-003 can cause you a

lot of pain if you don't carefully plan your approach. 99.999% of the time "a problem with

the Router" is caused by other components in the FC-

SAN or, most often, a lack of understanding

of the capabilities of the Router and of underlying FC-SAN principles.

This document is broken into sections which, at a high-level, provide all the information you

need. They are:

I) Rule #0: Routers don't handle change well.

II) Really Surprising Fact #1: Routers "talk" to other Routers, Avoid this!

III) Tip #1: FC Switch Zoning, your best friend.

IV) Tip #2: LUN Security, tricky and best avoided.

V) Really Surprising Fact #2: Windows systems can now STOMP on MPE/iX disks.

VI) Rule #1: Plan, Plan, Plan, then implement carefully.

VII) Examples, good and bad.

Exercising Good Judgment requires Experience.

Experience comes from exercising Bad Judgment.

Rule #0: Routers don't handle change well.

Any change to the FC environment visible to the Router will likely result in

a Router marking its device map invalid. This will prevent you from

accessing the device from MPE/iX which may result in System Hangs or Aborts.

If a System Hang or Abort isn't scary enough for you the ONLY way to reset

the Router Map is via a Double Power Cycle of the device while flipping

switches too small for adult human fingers (and hard to see to boot)!

Activities which can cause a Router to Invalidate its Map include but are not

limited to:

A) Connection of an FC Cable in the FC-SAN.

B) Adding/Removing another router (or powering up another router).

C) Adding/Removing a LUN to device PORT.

D) FC-Switch Zone changes.

E) Change in LUN Security settings.

Due to this sensitivity the WORST possible strategy is "plug some Routers and

see what happens" -- this is the path to Chaos or at least a headache. Close

behind in the "creating a big mess sweepstakes" is the "I'll just add a few

more LUNs to this Device Port or reZone this switch to add another Router"

strategy. Likely this will cause existing Routers connected to the Device

Port to stop working. Why is this?

Really Surprising Fact #1:

Routers "talk" to other Routers.

Summary of content (7 pages)

PAGE 1
A Guide to Success with the A5814A-003 SCSI-FC Router (or) A bunch of stupid things I've done and seen that you should avoid BY: Jim Hawkins -- MPE/iX Lab April 21st, 2003 The A5814A-003 SCSI-FC Router (a.k.a. "Router") is a unique piece of hardware. In our collective experience in the MPE/iX Lab we have found it to be a very reliable, high performing, and trustworthy part of the data center environment. That being said a A5814A-003 can cause you a lot of pain if you don't carefully plan your approach.
PAGE 2
Routers are cautious and like to form a consensus of how to "map" all the devices visible in the FC-SAN. If two Routers can communicate they WILL exchange maps. If the maps to not agree then what the Routers think is the "older" map will be invalidated. You will then be forced to MANUALLY reset the Router with the "invalid" map. If a Router can "see" a device port through any set of FC connections than it can and will communicate with any other Router that can "see" the port.
PAGE 3
The BEST option is to use Device Port settings, FC Switch Zoning and even LUN Security to prevent a "Windows" system from seeing your MPE/iX Disk Volumes. Any O.S. can cause this to happen but "Windows" systems tend to be the most aggressive. Your best protections are: A) Limit each Device Port to only one Type of O.S. B) Use FC Switch Zoning to limit the number of ports that are Zoned together. C) Where possible, LUN Security can help prevent problems.
PAGE 4
Switch and Storage firmware levels. L) Create all Storage Device LUNs and assign to Ports according to Plan. M) Create all FC Switch Zone according to Plan. N) Connect FC Cables from Switches to Devices according to Plan. Confirm good connections. You now have a "stable" environment that Routers are likely to be happy in. O) Connect Routers to System HBAs (Power OFF) according to Plan. P) Individually Turn Router Power On and Manually Rest Map.
PAGE 5
Notes: a) As you have two Routers and only one port you must use an FC Switch to multiplex these connections. b) To avoid "surprising fact #2" you MUST use "Zoning" on the Switch to isolate the HP e3000 Routers from the Windows System. c) Use "Single Initiator Zoning"; Zones: "Router1" (1,2), "Router2" (3,2), "Windows" Ports 7 and 8. .
PAGE 6
Notes: a) Zoning NOT use so (1,2,3,4,5,6,7,8) are all together. b) LUN Security cannot be used on ANY Device Port. c) Windows can easily write on all MPE LUNs (and vice versa) d) this is BAD don't do it!!! Good Example #4 Four HBA/Routers connected to XP48/512 or XP128/1024 with lots of ports: Notes: a) Zoning gives each Router exclusive access to one XP Port. b) LUN Security could be used c) A one Router, one Port configuration doesn't actually require a switch. . d) (This could be expensive). . .
PAGE 7
Notes: a) Zoning (1,2,3,4) (5,6,7,8) b) LUN Security can NOT be used as Routers (1,3,4) share maps (as do 5,6,7) c) Lots of Routers grouped together. d) Switch is "single point of failure" Great Example #6 Six HP e3000 HBA Routers connected to the XP48/512 or XP128/XP1024 with few ports (port consolidations) This technique uses a feature in the switch called "Single Initiator Zoning". The switch is configured so that each zone contains only the router's port and the storage port.