Some Researches on HP-UX (with NetApp)

 

A Few Links

kb.netapp.com is a fantastic resource, unfortunately, if you Google stuff, it will never appear in the list of answers (because kb.netapp.com requires a login, so Google’s anonymous searches cannot scan it’s pages - at least that’s my guess.) The three links below all point to kb.netapp.com.

If, when you run “igroup show” the -
“HP-UX Host Bus Adapters (HBAs) will only appear as logged in if there is I/O activity on the path.”

To check if I/O is on the partner path:
lun stats -z (zero’s the statistics)
lun stats -o (displays extra statistics including whether I/O is from the partner path)
If host Multipathing (HP pvlink Multipathing, Veritas DMP) is not configured on the HP-UX host, it is possible you will see this.

If you have NetApp’s FC Host Utilities Kit (HUK) for HP-UX installed:
sanlun lun show
sanlun lun show -p

Some things to consider with a HP-UX SAN Migration

Credits: The below is mostly excellent advice given by awesome people who know something about HP-UX (not me)

If you’re migrating LUNs for HP-UX hosts, you need to be aware of whether they are currently using the Agile or Legacy naming standard (Legacy DSF.) The Agile naming scheme was introduced in HP-UX 11i v3 (read here HP-UX 11i v3 Mass Storage Device Naming) so anything older and it’s Legacy. The discussion below considers only the Legacy naming scheme.

If you’ve got a migration plan like the below (you could also consider a no-downtime online migration using LV mirroring):

1) Applications get shut down
2) HP-UX hosts get shut down
3) Final SnapMirror update
4) SnapMirror break
5) Re-serial mirrored LUNs with old serials (not totally necessary with HP-UX but we’ll do it anyway)
6) Map LUNs to igroups using same LUN ID as before
7) HP-UX hosts are patched into a new fabric
8) HP-UX hosts get powered up
9) Applications get restarted

With Legacy naming, at the highlighted step 7, your device ids are likely to change. This is because when HP-UX detects a path change, such as a new fabric, it will assign new legacy device file names to the disk devices when the ioscan command is run.

Before the Migration

Before migration you should document the:

ioscan –fnkC disk
bdf
vgdisplay -v
lvdisplay -v /dev/vgxx/lvxx  (for each logical volume)
ls -l /dev/*/group
sanlun lun show  (if the HUK is installed)
sanlun lun show -p (if the HUK is installed)

Note: You can also collect all the config data using NetApp’s nSANity tool.

What to Expect During the Migration

The “ioscan -fnkC disk” run on the HP-UX hosts will give you the FC_ID, as highlighted in an extract from an output below (basically the 3 entries after the first dot.)

8/8/1/0.118.23.19.0.14.2

Whether this will change or not, depends on how your Fabric Switches are configured. If your Fabric switches are the same make, have the same domain ID’s (Fabric A will have a different domain ID to Fabric B), and you’re using the same ports for connecting your HP-UX hosts too, then the FC_ID might just stay the same (don’t quote me on this). If not then your device file names will change from say (doesn’t actually matter what the FC_ID changes too, just that it changes):

Path 1:
/dev/rdsk/c4t0d1
/dev/rdsk/c4t0d2
/dev/rdsk/c4t0d3

Path 2:
/dev/rdsk/c6t0d1
/dev/rdsk/c6t0d2
/dev/rdsk/c6t0d3

To say:

Path 1:
/dev/rdsk/c7t0d1
/dev/rdsk/c7t0d2
/dev/rdsk/c7t0d3

Path 2:
/dev/rdsk/c8t0d1
/dev/rdsk/c8t0d2
/dev/rdsk/c8t0d3

Completing the Migration

And this is where you will need a Unix Administrator/Expert on hand who’s comfortable with with page 49 and section “5 Disruptive migration” of the following link:


Additional Reading:

Comments