A LUN (logical unit number) object models a logical unit of addressable storage space that is created by a hardware provider and surfaced by a subsystem. Each LUN comprises at least one LUN plex, which is in turn composed of extents from one or more drives.
VDS supports five LUN types: simple, spanned, striped, mirrored, and striped with parity. Simple, spanned, and striped LUNs are non-fault tolerant; mirrored and parity LUNs are fault tolerant. The remainder of this section describes each of the VDS LUN types.
- A simple LUN is a non-fault tolerant LUN that is made up of a single contiguous drive extent from a single drive. The contiguous extent can comprise of a single range of blocks or multiple ranges of blocks linked together.
- A spanned LUN is a non-fault tolerant LUN that is made up of multiple discontiguous extents from multiple drives. Data is written linearly to each of the extents on the first drive until all of the first drive extents are filled, and then to each of the extents on the second drive, and so on. Spanned LUNs provide for efficient use of drive space in subsystems that comprise of drives of various sizes.
- A striped LUN is a non-fault tolerant LUN made up of multiple, interleaved, contiguous extents from multiple drives. Striped LUNs use a RAID-0 configuration, such that data is "striped" cyclically across the extents on the contributing drives. Striped LUNs work best with drives of the same size, model, and manufacturer.
- Mirrored LUNs are fault tolerant LUNs that provide for disaster recovery by duplicating the data to multiple LUN plexes. Each plex in a mirrored LUN contains a copy of the data that is stored on the original plex. Each of the plexes resides on a separate drive. All data that is written to a mirrored LUN is written simultaneously to each of its plexes. Should one of the contributing drives fail, the plex on that drive becomes unavailable, but the system continues to operate using the unaffected plex or plexes. A mirrored LUN can have any number of plexes.
- Striped with parity LUNs are fault-tolerant LUNs that provide for disaster recovery by striping parity data intermittently across three or more drives. Should one of the contributing drives fail, the lost data can be recreated from the remaining data and parity.
VDS supports four models by which applications can create LUNs: explicitly directed, partially directed, automagic, and vendor-specific. All hardware providers must support explicitly and partially directed LUN creation, and are strongly encouraged to support automagic LUN creation. (Vendor-specific LUN creation is outside the scope of this guide.)
Explicitly directed LUN creation enables the caller to specify all of the attributes of the LUN. Partially directed LUN creation enables the caller to specify only those attributes that are of particular interest, and then allows the provider to choose the rest. Automagic LUN creation involves enabling the caller to simply specify the LUN type and size along with a set of "automagic hints" (predefined preferences for LUN attributes), and then allowing the provider to create the LUN automatically.
VDS supports LUN unmasking for subsystems that offer this capability. All LUNs are surfaced to the computer on which the provider is running. LUN unmasking allows a caller to "unmask" selected LUNs to other computers on the network. If you unmask a LUN to a computer, the computer has access to the LUN. Computers for which a LUN is masked do not.
An unmasked LUN exposes both the IVdsLun and IVdsDisk interfaces to the local host. You can use IVdsDisk to add a LUN to a software-provider pack, create and remove volumes, assign drive letters, and so on. For more information about the operations performed on a disk, see the Disk Object.
After a LUN is unmasked to a target machine or masked from a target machine, the LUN's visibility on that machine may not change until a bus rescan is performed. The VDS application on the target machine initiates the bus rescan by calling IVdsService::Reenumerate. The initiating of the bus rescan is the responsibility of the VDS application, not the hardware provider.
Hardware providers that support multipath I/O (MPIO) can set load balancing policies on paths between a LUN and the local host. LUNs that support this capability expose the IVdsLunMpio interface to the local host.
Use the IVdsSubSystem::CreateLun method to create a new LUN object. You can query the LUNs that are surfaced by a specific subsystem by invoking the QueryLuns method, also exposed by IVdsSubSystem. A caller can get a pointer to a specific LUN by selecting the desired LUN object from the enumeration that is returned by QueryLuns. With a LUN object, you can set the LUN status; query for all active controllers, plexes, and automagic hints; extend and shrink the LUN; add and remove plexes; set masks; apply hints; and delete the LUN.
In addition to an object identifier, a name, and a serial number, LUN object properties include the LUN type, size, status, health, transition state, and flags; an unmasking list; and a rebuild priority setting.
The following table lists related interfaces, enumerations, and structures.
|Interfaces that are always exposed by this object||IVdsLun|
|Interfaces that are always exposed by this object in VDS 1.1 and 2.0 Fibre Channel providers only||IVdsLunControllerPorts|
|Interfaces that are always exposed by this object in VDS 1.1 and 2.0 iSCSI providers only||IVdsLunIscsi|
|Interfaces that may be exposed by this object*||
IVdsMaintenance, IVdsLunMpio, IVdsLunNaming, and IVdsLunNumber
Windows Server 2008, Windows Vista, and Windows Server 2003: The IVdsLunNumber interface is not supported.
|Associated enumerations||VDS_LUN_FLAG and VDS_LUN_STATUS, and VDS_LUN_TYPE|
|Associated structures||VDS_LUN_INFORMATION, VDS_LUN_PROP, and VDS_LUN_NOTIFICATION|