During recovery, Ignite-UX C.7.x makes changes to the
new system I/O configuration to match the original system I/O configuration.
This is necessary because some aspects of a system configuration depend
on the unpredictable order of system I/O inventory.
The overall goal of this process is to make the system I/O configuration
appear as if the system simply rebooted at the time the recovery archive was created. This process is complex,
and Ignite-UX might be unable to fully restore the I/O configuration.
Ignite might not be able to restore aspects of the I/O configuration
due to hardware changes, limitations of system I/O software, and limitations
of Ignite-UX.
The system I/O configuration should be verified during and after
recovery so configuration adjustments can be made if needed.
One part of restoring the I/O configuration is the appropriate
matching of device special files (DSFs) and devices. There is one
approach used for legacy DSFs in HP-UX 11i
v3 and previous releases, and another approach used for HP-UX 11i
v3 persistent DSFs.
Legacy DSFs and Device Matching |
 |
Matching legacy DSFs and mass storage
devices is done based on hardware paths. Generally, legacy DSFs are
associated with a particular hardware path. During recovery, a device
is associated with its hardware path's DSF. (See Figure 7-1 for a
description of the legacy addressing model.)
Hardware configuration changes are handled by assuming a new
device is intended to replace the device originally at that hardware
path.
Note that some I/O protocols, such as SAS and USB, associate
legacy DSFs with specific devices using unique LUN IDs, and so behave like persistent DSF matching
described below.
SAS devices are a special case, since their legacy DSF/unique
LUN ID association can change as a result of I/O configuration changes.
If you change a SAS configuration (physically move a SAS device to
another bay or remove a SAS device) the hardware path associated with
that and other SAS devices can change during an installation or recovery.
In such a case, hardware paths are reassigned to SAS devices. Since
legacy DSFs are associated with a particular hardware path, a change
in a device's hardware path breaks the association between its
previous legacy DSF and its unique LUN ID. Note that the way SAS devices
are associated during recovery might change in future versions of
Ignite-UX to use the agile addressing approach
described below.
Only certain SAS configuration changes cause remapping of hardware
paths. For more information see the white paper, “Ignite-UX
and SAS Devices” available at Ignite-UX
Information Library.
Persistent DSFs and Device Matching |
|
Matching persistent DSFs and mass storage
devices is relatively complex due to agile addressing. Ignite-UX will attempt to simulate agile addressing during recovery,
while also dealing with hardware replacement. This matching is accomplished
using the methods described below:
WWID — Matching
is done based on the unique LUN ID of the device.
Most often, this is the device's WWID. This method matches a
device's original persistent DSF with
the same device in the recovered system configuration.
Device ID — (Future) Matching is done based on a user-definable identifier written
to the device. This method matches a device's original persistent DSF with the device that has the same device
ID in the recovered system configuration. This method allows user-provided
identification to control device matching. Note that some mass storage
devices do not support the device ID feature.
Physical Location — Matching is done based on device physical location. This method matches the original persistent DSF associated with a particular physical location (e.g. same enclosure
and bay) with the device at that location in the recovered system
configuration. This method is intended to handle replacement of devices.
Note that not all I/O protocols support physical location addressing.
Lunpath — Matching
is done based on lunpath hardware path. This
method matches the original persistent DSF associated
with a lunpath hardware path with the device at that lunpath hardware
path in the recovered system configuration. This method is intended
to handle replacement of devices. Some protocols such as fibre channel
have lunpath hardware paths and legacy hardware paths that are functionally different (use different hardware attributes).
Legacy hardware path — Matching is done based on the legacy hardware path. This method matches the original persistent DSF associated with a legacy hardware path with the device at that legacy
hardware path in the recovered system. This method matches devices
using the same approach used for typical legacy DSFs.
Not all methods are appropriate for all protocols. The following
are the ordered lists of persistent DSF-to-device matching methods
by protocol. The order in which these methods are applied is important.
Matching will be done in the order listed.
Table 7-2 Persistent DSF-to-Device Matching Methods by Protocol
|
| |
|
 | NOTE: There might be devices in the original system configuration
that can not be matched with devices in the new system configuration.
There might also be devices in the new system configuration that do
not match devices in the original configuration. In these cases, the
HP-UX operating system I/O drivers will assign legacy and persistent DSFs for the non-matching devices. |
|
| |
|
Printable version
