INTRODUCTION TO VXVM

#############################
VERITAS VOLUME MANAGER (VXVM)
#############################
INTRODUCTION TO VXVM
© John Reed Avery, 2005/July/18
NOTE/WARNING: This document is offered without *any* guarantee of its accuracty
or appropriateness for your storage needs or anything else. Use and follow this
introduction AT YOUR OWN RISK! --John R Avery, 2005/Jul/18
Dear Reader, I have basically just thrown this document together as I've been
learning Veritas Volume Manager. I think you will find its descriptions reasonably
accurate and rather clear, though I offer no guarantees for anything about the
contents of this document. I expect eventually to fill out and polish up this
VxVM-intro but, for now, it is what it is. I hope you find it helpful. --John R
Avery, 2005/Jul/18
[ http://www.kevlo.com/~ebs/docs/installs/vx_lab/ ]
[ http://www.cuddletech.com/veritas/index.shtml ]
[ http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx/ ]
[email protected]
[ http://www.eng.auburn.edu/pub/mail-lists/ssastuff ]
[ http://docs.sun.com/app/docs/doc/801-7367 ]
[ http://docs.sun.com/app/docs/doc/805-2696 ]
<--[man pages / man-pages 1995]
<--[man pages / man-pages 1997]
===================================
What is VxVM? What does it do?
===================================
In a nutshell, Veritas Volume Manager (VxVM) is a suite of software that allows
one to control and manage one's disk-storage in a way that implements certain
levels of RAID (Redundant Array of Independent/Inexpensive Disks) technology, for
the sake of improved disk-I/O and/or increased HA (High Availability).
This begs the question, [.... more to come; still under construction ....]
=================
What is RAID?
=================
RAID (Redundant Array of Independent/Inexpensive Disks) technology is [....]
RAID-0
[.... for now, look it up elsewhere. there are gobs of RAID resources on the web
....]
RAID-1
[.... for now, look it up elsewhere. there are gobs of RAID resources on the web
....]
Page
1
of
5
RAID-5
[.... for now, look it up elsewhere. there are gobs of RAID resources on the web
....]
==================================
How does VxVM do what it does?
==================================
In a sense, the answer, to "How does VxVM do what it does?", is the topic of all
VxVM documentation everywhere. But, described in a superficial nutshell, it could
be said that VxVM uses "virtual objects" to allow data to be written across
multiple storage devices in a way that increases either disk-I/O or High
Availability (HA).
The way it does this is ─again, expressed in a nutshell─ through an inventive
combination of these "virtual objects", which are:
*
*
*
*
*
*
■
■
■
■
■
■
VM Disks
Disk Groups
Subdisks
Plexes
Volumes
Columns
Take multiple hard-disks.
Use VxVM to define these hard-disks as VM disks and combine these into one or
more disk groups.
Within a single disk group, divide each of the VM disks into a number of
subdisks, which are simple divisions of the physical space on the disk.
Take one or more subdisks (typically from different VM disks when using more
than one) and use them to construct plexes. (It is mostly at this level of
construction where the RAID levels are defined.)
Construct volumes each out of one or more plexes.
Use the volumes either to hold file systems or as raw devices for such things
as swap or database tables.
(Columns will be explained elsewhere.)
========================
VxVM Virtual Objects
========================
VxVM virtual objects include the following:
*
*
*
*
*
*
VM Disks
Subdisks
Plexes
Volumes
Disk Groups
Columns
VM Disk
VM Disks are simply the VxVM virtual or logical equivalent of a physical
hard-disk. In other words: when you place a single physical disk under VxVM
control, a single VM Disk is created to represent that physical disk.
A VM disk typically includes a public region and a private region. The
Page
2
of
5
public region [slice-4, per my training] on a physical disk is a region managed
by VxVM and contains available space that is used for allocating subdisks. The
private region [slice-3, per my training] contains VxVM internal configuration
information (the functional equivalent of SDS's Metastate Database).
Subdisk
Subdisks are the smallest unit of storage and the smallest building-block in
VxVM. Subdisks are subdivisions of the public region of a VM disk. "A subdisk
is a set of contiguous disk blocks" ─aka sectors─ which are units of space on
the disk, typically 512 Bytes each. Thus, subdisks are somewhat similar to
partitions or slices on a physical disk but, unlike actual partitions/slices, a
subdisk can never be used directly for building a file system, such as UFS.
Rather, subdisks are the building-blocks for plexes ─which, in turn, are the
building blocks for volumes, and it is on or within volumes that file systems
can be built.
(Throughout Avery's VxVM docs, the term sdname and sd_name and the commandline terms <sdname> and <sd_name> will typically be used to refer generically to
any VxVM-subdisk's uniquely identifying name.)
Plex
A plex is a collection of one or more subdisks. Subdisks are the direct
building-blocks for plexes; plexes are the direct building-blocks for volumes.
Apparently, the only reason, for building volumes directly out of plexes rather
than directly out of subdisks, is that Veritas regarded the concept of mirroring
as being so important that it wanted to provide a "VxVM object" --aka "virtual
object"-- that could easily be used to constitute multiple groups of subdisks,
each of which is a mirror of the others within a volume.
In other words and for example: If a volume were made simply of a series of
concatenated subdisks, that should be fine. We would say that the group of
subdisks constitutes the volume; they would have no identity, as a group, other
than as the components of the volume. But if you later decided that you wanted
this volume to be mirrored, you would need a second set of subdisks to be the
mirror of the first. Now you would need a separate virtual-object by which to
uniquely identify each of these two sets of subdisks and, thereby, to
distinguish them one from the other.
This is where the plex object comes in. Within a volume, each set of
subdisks, that *could* constitute one part of a mirrored volume, is identified
as a plex. If the volume has only one plex, there is no mirror; but if you want
a 2-way-mirrored device, each of the two halves, of that mirror, is a plex; if
you want a 3-way-mirrored device, each of the three thirds, of that mirror, is a
plex; etc. Note that VxVM does not presently support the mirroring of RAID-5
volumes, which means that a single set of RAID-5-configured subdisks could never
actually be a mirror within a mirrored volume; yet, we refer to that set of
subdisks as a "plex" anyway. Otherwise, the RAID configuration of the set of
subdisks does not matter: you can have a concatenated plex or a striped plex.
NOTE: The VxVM (3.5 & 4.0) User's Guides say that a plex is a mirror. This
is relatively correct but, if you are learning about VxVM from reading my
documentation, I prefer that you not think exactly in this way. Here's why: A
volume can consist of only one plex. If there is only one plex in the volume,
it is not possible for that plex to be a mirror, in the traditional sense,
because there is nothing for that supposed "mirror" to refect; with only one
plex, nothing is actually being "mirrored". Some people might say that this is
simply a "one-way mirror". They are entitled to their opinion; I think it's
nonsense.
(Throughout Avery's VxVM docs, the term plexname and plex_name and the
command-line terms <plexname> and <plex_name> will typically be used to refer
generically to any VxVM-subdisk's uniquely identifying name.)
Volume
A volume is sometimes referred to as a virtual disk.
Page
3
of
5
However, more
appropriate terms would be either virtual partition or virtual slice. This is
because, at least in a SunOS/Solaris environment, you don't use a hard-disk
directly to hold a file system or as a raw device for swap or database-tables.
Rather it is that disk's partition/slice that gets used in this way. Likewise,
it is the VxVM volume that is used to hold a file system or as a raw device for
swap or database-tables.
The significant difference, between a volume and a regular partition/slice,
is that the volume does not have the same physical limitations as the slice. A
volume can consist of disk-space from different parts of a single disk and/or
from different disks, including disks that are attached to the system through
different controllers.
Volumes are constructed from one or more plexes.
A volume, like a physical-disk partition/slice, can be used either as a raw
device, such as for database tables in some configurations, or to house a file
system, such as the UFS. (Although volumes have more hidden complexity
underneath their surface, they are one of the conceptually-simplest VxVM virtual
objects; hence, this relatively short description.)
(Throughout Avery's VxVM docs, the term volname and the command-line term
<volname> will typically be used to refer generically to any VxVM-volume's
uniquely identifying name.)
Disk Group
A Disk Group is a collection of VM Disks (therefore, it's also a collection
of physical disks) that, according to Veritas overview-description, "share a
common configuration". The significance of the disk group is that a volume must
consist of disk-space that all resides within a single disk-group. So, all the
VM disks and subdisks and plexes, that make up any one volume, must belong to
the same disk-group.
"The default disk group is [officially named] 'rootdg' (the root disk
group)." Contrary to the implication of the name "rootdg", a system's boot disk
need not be part of the rootdg. "You can create additional disk groups as
necessary."
The private region, of each and every VM disk within any disk group, contains
a copy of all the control-&-config data for that entire disk group. This is
referred to as the "disk group configuration".
(Throughout Avery's VxVM docs, the term dgname and dg_name and the commandline terms <dgname> and <dg_name> will typically be used to refer generically to
any VxVM-subdisk's uniquely identifying name.)
Column
A column is a special entity that doesn't typically get mentioned in an overview
of the VxVM virtual objects. This is probably because it is unique to actual RAID0 striping and RAID-5, and requires a depth of explanation that does not lend
itself to such an overview. So, no actual description of a column will be given
here. Look for the description in explanations of VxVM's implementation of RAID-0
striping and RAID-5, or in the glossary [possibly a separate document, if not near
the bottom of this one].
[I bother to say "RAID-0 striping" simply to acknowledge that not all RAID-0
involves actual striping.]
STORAGE LAYOUTS
Apparently, VxVM is capable only of the following Storage Layouts or rough
equivalents of RAID Levels:
* Concatenation and spanning [don't yet know what "spanning" is
but my guess is that it's a variation on concatenation]
* Striping (RAID 0)
* Mirroring (RAID 1)
* Mirroring plus Striping (RAID 1+0)
* Striping plus Mirroring (RAID 0+1)
Page
4
of
5
* RAID 5 (striping with parity)
************************************************************
************************************************************
Page
5
of
5