|
|
|
|
|
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. The physical disk device name varies with the computer system you use. Not all parameters are used on all systems. Typical device names are of the form c#t#d#s#, where c# specifies the controller, t# specifies the target ID, d# specifies the disk, and s# specifies the partition or slice.
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.
For example, device name c0t0d0s2 is the entire hard disk connected to controller number 0 in the system, with a target ID of 0, and physical disk number 0.
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.
Slice example shows how a physical disk can be divided into one or more slices, also known as partitions.
Slice example
Click the thumbnail above to view full-sized image.
The slice number is added at the end of the devname, and is denoted by s#. Note that slice s2 refers to an entire physical disk for non-EFI disks.
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 shows how VxVM represents the disks in a disk array as several volumes to the operating system.
How VxVM presents the disks in a disk array as volumes to the operating system
Click the thumbnail above to view full-sized image.
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.
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).
See "Administering Dynamic Multipathing" on page 137.
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.
See "How to administer the Device Discovery Layer" on page 90.
Enclosure-based naming provides an alternative to operating system-based device naming. 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#s# 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.
Example configuration for disk enclosures connected via a fibre channel hub or switch shows a typical SAN environment where host controllers are connected to multiple enclosures in a daisy chain or through a Fibre Channel hub or fabric 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.
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" on page 166.
Example HA configuration using multiple hubs or switches to provide redundant loop access shows a High Availability (HA) configuration where redundant-loop access to storage is implemented by connecting independent controllers on the host to separate hubs with independent paths to the enclosures.
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 to the operating system, such as c1t99d0 and c2t99d0.
See "Disk device naming in VxVM" on page 82.
See "Changing the disk-naming scheme" on page 118.
To take account of fault domains when configuring data redundancy, you can control how mirrored volumes are laid out across enclosures.
See "Mirroring across targets, controllers or enclosures" on page 265.