VxVm essentials part II - Virtual Objects

Virtual objects in VxVM

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.
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 Sun Microsystems Solaris Volume Manager software. VxVM creates virtual objects and makes logical connections between the objects. The virtual objects are then used by VxVM to do storage management tasks.


VxVm objects include the following


Disk Groups

A disk group is a collection of disks that share a common configuration, and which are managed by VxVM. A disk group configuration is a set of records with detailed information about related VxVM objects, their attributes, and their connections. A disk group name can be up to 31 characters long.
In releases prior to VxVM 4.0, the default disk group was rootdg (the root disk group). For VxVM to function, the rootdg disk group had to exist and it had to contain at least one disk. This requirement no longer exists, and VxVM can work without any disk groups configured (although you must set up at least one disk group before you can create any volumes of otherVxVM objects). You can create additional disk groups when you need them. 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. Volumes are created within a disk group. A given volume and its plexes and subdisks must be configured from disks in the same disk group.


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 at least one physical disk or disk partition. VxVM allocates storage from a contiguous area of VxVM disk space. A VM disk typically includes a public region (allocated storage) and a small 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 takes the form diskgroup##, where diskgroup is the name of the disk group to which the disk belongs.


Sub Disks

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 diskgroup## and the default name for a subdisk is diskgroup##-##, where diskgroup is the name of the disk group to which the disk belongs

eg -

sd disk01-01 disk01 <-- Subdisk named "disk01-01" made from "disk01"

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.


Plexes

VxVM uses subdisks to build virtual objects called plexes. A plex consists of one or more subdisks located on one or more physical disk;

pl myplex striped <-- Striped Plex named "myplex"
sd disk01-01 <-- Made using subdisk "disk01-01"
sd disk02-01 <-- and subdisk "disk02-01"

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)


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.



How VxVm objects fit together;

VxVM virtual objects are combined to build VOLUMES. The virtual objects contained in volumes are VMDISKS, DISK GROUPS, SUBDISKS, and PLEXES. Veritas Volume Manager objects are organized as follows:
■ VM DISKS are grouped into DISK GROUPS
■€ SUBDISKS (each representing a specific region of a disk) are combined to form PLEXES
■ VOLUMES are composed of one or more PLEXES


#-#-#-#-##-#-#-#-##-#-#-#-##-#-#-#-##-#-#-#-##-#-#-#-#

Cuddletech explain it brilliantly - http://www.cuddletech.com/veritas/vxcrashkourse/ar01s03.html

Disk: This is a normal physical disk with a SCSI id. (c0t0d0...)

VM Disk (dm): A disk that is put under Vx control.

Sub Disk (sd): A section of VM disk used to build plexes.

Plex (pl): A mirror.

Volume (v): A virtual disk, which can contain data.

Now, lets talk about these objects a bit. A disk is nothing new or magical. When we want to use a disk in VERITAS we need to turn it over to VERITAS control. A disk turned over to VERITAS control is then given a VERITAS name (like disk01). After doing this the disk is no longer available to the system for anything outside of use inside VERITAS. Also, when we turn disks over to VERITAS control we don't turn over a partition (c0t0d0s0), but the whole disk itself (c0t0d0). Now that we've got a VM Disk we then create a Sub Disk from the VM Disk. Think of a subdisk as a VERITAS partition. We could make one big subdisk from the VM Disk and use the whole disk, or we could create a bunch of smaller subdisks. You can divide VM Disks into subdisks however you like. From subdisks (one or more) we create what is called a plex. Plexes are confusing so let's talk about these in some length.

Say the following out loud: "A Plex is a Mirror. A Plex is a Mirror. A Plex is a Mirror." Maybe you should do that a couple times. You may feel silly, but plexes are a sort of cornerstone in VERITAS. A Volume is a container, in VERITAS. The volume is made up of one or more plexes. See the catch? A Plex is a mirror, yes, however you can make a volume with only one plex. Is a volume made with only one plex mirrored? No. We'll explain this more later, but for the time being keep it in your head. So, subdisks are grouped together into a plex. The interesting thing is that in VERITAS the plexes do all the work, so lets say you wanted to create a Striped volume. You would actually create a striped plex, and then attach that striped plex to a volume. The volume doesn't care, it's just a container. See the beauty here? Let's put all this stuff together and build an imaginary volume in VERITAS.

We're going to build a striped (RAID0) volume from 2 9G disks. We'll say that the first disk is c1t0d0, and the second is c1t1d0. First, we need to put them in VERITAS control, so we create VM disks. The VM disks are then named disk01, and disk02. Next, we'll create subdisks using these two disks. Let's use the whole disks and just create 2 subdisks, one for each VM disk. We'll call disk01's subdisk "disk01-01", and disk02's subdisk "disk02-01". Now, it's plex time! We're going to build a striped plex using our two subdisks, which we'll call "myplex". (Don't worry yet about how we create the plex, just get the concepts now.) So now we've got a plex, which contains the subdisks "disk01-01" and "disk02-01". Now, we create a volume named "myvol" using "myplex". And bingo! We've got a striped 18G volume ready to create a file system on! Maybe, if we used the short names mentioned earlier (with the list of objects) and make an outline it'd look something like this:

dm disk01 c1t0d0 <-- VM Disk named "disk01" made from "c1t0d0"
dm disk02 c1t1d0 <-- VM named "disk02" made from "c1t1d0"

sd disk01-01 disk01 <-- Subdisk named "disk01-01" made from "disk01"
sd disk02-01 disk02 <-- Subdisk named "disk02-01" made from "disk02"

pl myplex striped <-- Striped Plex named "myplex"
sd disk01-01 <-- Made using subdisk "disk01-01"
sd disk02-01 <-- and subdisk "disk02-01"

v myvol <-- Volume made from....
pl myplex striped <-- the striped plex named "myplex", made from...
sd disk01-01 <-- Subdisk "disk01-01", and...
sd disk02-01 <-- "disk02-01"
Look OK? Because if it does, take a look at this, real output from VERITAS, from a real volume I created on my test machine:

v myvol fsgen ENABLED 35356957 - ACTIVE - -
pl myplex myvol ENABLED 35357021 - ACTIVE - -
sd disk01-01 myplex ENABLED 17678493 0 - - -
sd disk02-01 myplex ENABLED 17678493 0 - - -
Does that make any sense? Any at all? I hope it does. And if it does, you're ready for VERITAS. We're going to explain more, much more, as we roll along, but at least understand that:

Volumes are made up of plexes.
Plexes are made up of subdisks.
Subdisks are made up of VM Disks.
VM Disks are made up of (real) Disks.

and,

Disks can be turned into VM Disks.
Vm Disks can be turned into Subdisks.
Subdisks can be grouped into Plexes.
Plexes can be grouped into a Volume.
Good. One more note about plexes before we move on. Here's the groovy thing about plexes. Because plexes are "mirrors", we can mirror the volume we built earlier simply by building another plex identical to the first one, using two more subdisks (which means we need 2 more vmdisks, etc,etc). Once we build the second plex, we attach it to the volume (myvol) and presto chango! We're mirrored! This is really kool... mirrors are something magical, they are a part of everything. If you have only one mirror you may see yourself, but you'll need a second mirror to see yourself holding the mirror. Hmmm?