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
Post a Comment