 | ||
| Physical objects—physical disks | ||
|---|---|---|
| Prev | Understanding Veritas Volume Manager | Next |
A physical disk is the basic storage device (media) where the data is ultimately stored. You can access the data on a physical disk by using a device name to locate the disk.
Physical disk example shows how a physical disk and device name (devname) are illustrated in this document.
Physical disk example
Click the thumbnail above to view full-sized image.
In HP-UX 11i v3, disks may be identified either by their legacy device name, which takes the form c#t#d#, or by their persistent (or agile) device name, which takes the form disk##.
In a legacy device name, c# specifies the controller, t# specifies the target ID, and d# specifies the disk. For example, the device name c0t0d0 is the entire hard disk that is connected to controller number 0 in the system, with a target ID of 0, and physical disk number of 0. The equivalent persistent device name might be disk33.
In this document, legacy device names are generally shown as this format is the same as the default format that is used by the Dynamic Discovery Layer (DDL) and Dynamic Multipathing (DMP) features of VxVM.
VxVM writes identification information on physical disks under VxVM control (VM disks). VxVM disks can be identified even after physical disk disconnection or system outages. VxVM can then re-form disk groups and logical objects to provide failure detection and to speed system recovery.
VxVM accesses all disks as entire physical disks without partitions.
Performing I/O to disks is a relatively slow process because disks are physical devices that require time to move the heads to the correct position on the disk before reading or writing. If all of the read or write operations are done to individual disks, one at a time, the read-write time can become unmanageable. Performing these operations on multiple disks can help to reduce this problem.
A disk array is a collection of physical disks that VxVM can represent to the operating system as one or more virtual disks or volumes. The volumes created by VxVM look and act to the operating system like physical disks. Applications that interact with volumes should work in the same way as with physical disks.
How VxVM presents the disks in a disk array as volumes to the operating system illustrates how VxVM represents the disks in a disk array as several volumes to the operating system.
Data can be spread across several disks within an array to distribute or balance I/O operations across the disks. Using parallel I/O across multiple disks in this way improves I/O performance by increasing data transfer speed and overall throughput for the array.
How VxVM presents the disks in a disk array as volumes to the operating system
Click the thumbnail above to view full-sized image.
Some disk arrays provide multiple ports to access their disk devices. These ports, coupled with the host bus adaptor (HBA) controller and any data bus or I/O processor local to the array, make up multiple hardware paths to access the disk devices. Such disk arrays are called multipathed disk arrays. This type of disk array can be connected to host systems in many different configurations, (such as multiple ports connected to different controllers on a single host, chaining of the ports through a single controller on a host, or ports connected to different hosts simultaneously).
HP-UX 11i v3 provides its own native multipathing solution in addition to the Dynamic Multipathing (DMP) feature that is used by VxVM. These two multipathing solutions can coexist on the same system. For more information, see DMP coexistence with HP-UX native multipathing.
Device discovery is the term used to describe the process of discovering the disks that are attached to a host. This feature is important for DMP because it needs to support a growing number of disk arrays from a number of vendors. In conjunction with the ability to discover the devices attached to a host, the Device Discovery service enables you to add support dynamically for new disk arrays. This operation, which uses a facility called the Device Discovery Layer (DDL), is achieved without the need for a reboot.
This means that you can dynamically add a new disk array to a host, and run a command which scans the operating system's device tree for all the attached disk devices, and reconfigures DMP with the new device database. For more information, see Administering the Device Discovery Layer.
Enclosure-based naming provides an alternative to the disk device naming described in Physical objects—physical disks. This allows disk devices to be named for enclosures rather than for the controllers through which they are accessed. In a Storage Area Network (SAN) that uses Fibre Channel hubs or fabric switches, information about disk location provided by the operating system may not correctly indicate the physical location of the disks. For example, c#t#d# naming assigns controller-based device names to disks in separate enclosures that are connected to the same host controller. Enclosure-based naming allows VxVM to access enclosures as separate physical entities. By configuring redundant copies of your data on separate enclosures, you can safeguard against failure of one or more enclosures.
In a typical SAN environment, host controllers are connected to multiple enclosures in a daisy chain or through a Fibre Channel hub or fabric switch as illustrated in Example configuration for disk enclosures connected via a fibre channel hub or switch.
Example configuration for disk enclosures connected via a fibre channel hub or switch
Click the thumbnail above to view full-sized image.
In such a configuration, enclosure-based naming can be used to refer to each disk within an enclosure. For example, the device names for the disks in enclosure enc0 are named enc0_0, enc0_1, and so on. The main benefit of this scheme is that it allows you to quickly determine where a disk is physically located in a large SAN configuration.
Note In many advanced disk arrays, you can use hardware-based storage management to represent several physical disks as one logical disk device to the operating system. In such cases, VxVM also sees a single logical disk device rather than its component disks. For this reason, when reference is made to a disk within an enclosure, this disk may be either a physical or a logical device.
Another important benefit of enclosure-based naming is that it enables VxVM to avoid placing redundant copies of data in the same enclosure. This is a good thing to avoid as each enclosure can be considered to be a separate fault domain. For example, if a mirrored volume were configured only on the disks in enclosure enc1, the failure of the cable between the hub and the enclosure would make the entire volume unavailable.
If required, you can replace the default name that VxVM assigns to an enclosure with one that is more meaningful to your configuration. See Renaming an enclosure for details.
In High Availability (HA) configurations, redundant-loop access to storage can be implemented by connecting independent controllers on the host to separate hubs with independent paths to the enclosures as shown in Example HA configuration using multiple hubs or switches to provide redundant loop access.
Example HA configuration using multiple hubs or switches to provide redundant loop access
Click the thumbnail above to view full-sized image.
Such a configuration protects against the failure of one of the host controllers (c1 and c2), or of the cable between the host and one of the hubs. In this example, each disk is known by the same name to VxVM for all of the paths over which it can be accessed. For example, the disk device enc0_0 represents a single disk for which two different paths are known, such as c1t99d0 and c2t99d0.
Note The native multipathing feature of HP-UX 11i v3 similarly maps the various physical paths to a disk, and presents these as a single persistent device with a name of the form disk##. However, this mechanism is independent of that used by VxVM.
To take account of fault domains when configuring data redundancy, you can control how mirrored volumes are laid out across enclosures as described in Mirroring across targets, controllers or enclosures.
See Disk device naming in VxVM and Changing the disk-naming scheme for details of the standard and the enclosure-based naming schemes, and how to switch between them.