Device Discovery

Enclosure-Based Naming

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 inFigure 1-3 “Example Configuration for Disk Enclosures Connected via a Fibre Channel Hub/Switch”

Figure 1-3 Example Configuration for Disk Enclosures Connected via a Fibre Channel Hub/Switch

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 Figure 1-4 “Example HA Configuration Using Multiple Hubs/Switches to Provide Redundant-Loop Access” 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.

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”.

Figure 1-4 Example HA Configuration Using Multiple Hubs/Switches to Provide Redundant-Loop Access

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.

Virtual Objects

Virtual objects in VxVM include the following:

The connection between physical objects and VxVM objects is made when you place a physical disk under VxVM control.

After installing VxVM on a host system, you must bring the contents of physical disks under VxVM control by collecting the VM disks into disk groups and allocating the disk group space to create logical volumes.

	NOTE: To bring the physical disk under VxVM control, the disk must not be under LVM control. For more information on how LVM and VM disks co-exist or how to convert LVM disks to VM disks, see the VERITAS Volume Manager Migration Guide

Bringing the contents of physical disks under VxVM control is accomplished only if VxVM takes control of the physical disks and the disk is not under control of another storage manager such as LVM.

VxVM creates virtual objects and makes logical connections between the objects. The virtual objects are then used by VxVM to do storage management tasks.

	NOTE: The vxprint command displays detailed information on existing VxVM objects. For additional information on the vxprint command, see “Displaying Volume Information ” and the vxprint(1M) manual page.

VM Disks

When you place a physical disk under VxVM control, a VM disk is assigned to the physical disk. A VM disk is under VxVM control and is usually in a disk group. Each VM disk corresponds to one physical disk. VxVM allocates storage from a contiguous area of VxVM disk space.

A VM disk typically includes a public region (allocated storage) and a private region where VxVM internal configuration information is stored.

Each VM disk has a unique disk media name (a virtual disk name). You can either define a disk name of up to 31 characters, or allow VxVM to assign a default name that typically takes the form disk##. Figure 1-5 “VM Disk Example” shows a VM disk with a media name of disk01 that is assigned to the physical disk devname.

Figure 1-5 VM Disk Example

Disk Groups

A disk group is a collection of VM disks that share a common configuration. A disk group configuration is a set of records with detailed information about related VxVM objects, their attributes, and their connections. The default disk group is rootdg (or root disk group). A disk group name can be up to 31 characters long.

	NOTE: Even though rootdg is the default disk group, it does not necessarily contain the root disk. In the current release, the root disk may be under VxVM or LVM control.

You can create additional disk groups as necessary. Disk groups allow you to group disks into logical collections. A disk group and its components can be moved as a unit from one host machine to another. The ability to move whole volumes and disks between disk groups, to split whole volumes and disks between disk groups, and to join disk groups is described in “Reorganizing the Contents of Disk Groups”.

Volumes are created within a disk group. A given volume must be configured from disks in the same disk group.

Subdisks

A subdisk is a set of contiguous disk blocks. A block is a unit of space on the disk. VxVM allocates disk space using subdisks. A VM disk can be divided into one or more subdisks. Each subdisk represents a specific portion of a VM disk, which is mapped to a specific region of a physical disk.

The default name for a VM disk is disk## (such as disk01) and the default name for a subdisk is disk##-##. In the figure, Figure 1-6 “Subdisk Example”, disk01-01 is the name of the first subdisk on the VM disk named disk01.

Figure 1-6 Subdisk Example

A VM disk can contain multiple subdisks, but subdisks cannot overlap or share the same portions of a VM disk. Figure 1-7 “Example of Three Subdisks Assigned to One VM Disk” shows a VM disk with three subdisks. The VM disk is assigned to one physical disk.

Figure 1-7 Example of Three Subdisks Assigned to One VM Disk

Any VM disk space that is not part of a subdisk is free space. You can use free space to create new subdisks.

VxVM release 3.0 or higher supports the concept of layered volumes in which subdisks can contain volumes. For more information, see “Layered Volumes”.

Plexes

VxVM uses subdisks to build virtual objects called plexes. A plex consists of one or more subdisks located on one or more physical disks. For example, see the plex vol01-01 shown in Figure 1-8 “Example of a Plex with Two Subdisks”

Figure 1-8 Example of a Plex with Two Subdisks

You can organize data on subdisks to form a plex by using the following methods:

• concatenation

• striping (RAID-0)

• mirroring (RAID-1)

• striping with parity (RAID-5)

Concatenation, striping (RAID-0), mirroring (RAID-1) and RAID-5 are described in “Volume Layouts in VxVM”.

Volumes

A volume is a virtual disk device that appears to applications, databases, and file systems like a physical disk device, but does not have the physical limitations of a physical disk device. A volume consists of one or more plexes, each holding a copy of the selected data in the volume. Due to its virtual nature, a volume is not restricted to a particular disk or a specific area of a disk. The configuration of a volume can be changed by using VxVM user interfaces. Configuration changes can be accomplished without causing disruption to applications or file systems that are using the volume. For example, a volume can be mirrored on separate disks or moved to use different disk storage.

	NOTE: VxVM uses the default naming conventions of vol## for volumes and vol##-## for plexes in a volume. For ease of administration, you can choose to select more meaningful names for the volumes that you create.

A volume may be created under the following constraints:

• Its name can contain up to 31 characters.

• It can consist of up to 32 plexes, each of which contains one or more subdisks.

• It must have at least one associated plex that has a complete copy of the data in the volume with at least one associated subdisk.

• All subdisks within a volume must belong to the same disk group.

See Figure 1-9 “Example of a Volume with One Plex”.

Figure 1-9 Example of a Volume with One Plex

Volume vol01 has the following characteristics:

• It contains one plex named vol01-01.

• The plex contains one subdisk named disk01-01.

• The subdisk disk01-01 is allocated from VM disk disk01.

A volume with two or more data plexes is “mirrored” and contains mirror images of the data. See Figure 1-10 “Example of a Volume with Two Plexes”

Figure 1-10 Example of a Volume with Two Plexes

Each plex contains an identical copy of the volume data. For more information, see “Mirroring (RAID-1)”.

Volume vol06 has the following characteristics:

• It contains two plexes named vol06-01 and vol06-02

• Each plex contains one subdisk

• Each subdisk is allocated from a different VM disk (disk01 and disk02)

Combining Virtual Objects in VxVM

VxVM virtual objects are combined to build volumes. The virtual objects contained in volumes are VM disks, disk groups, subdisks, and plexes. Volume Manager objects are organized as follows:

The figure, Figure 1-11 “Connection Between Objects in VxVM”, shows the connections between Volume Manager virtual objects and how they relate to physical disks. The disk group consists of two VM disks: disk01 has a volume with one plex and two subdisks, and disk02 has a volume with one plex and a single subdisk

Figure 1-11 Connection Between Objects in VxVM