Characteristic Solstice Disk suite Veritas Volume Manager

Availability Free with a server license, pay for Available from Sun or directly from
workstation. Sun seems to have an on Veritas (pricing may differ
again off again relationship about whether considerably. Also excellent
future development will continue to occur educational pricing. Free with storage
with this product, but it is currently array or A5000 (but cannot use
available for Solaris8 and will continue to striping outside array device)
be supported in that capacity. The current
word is that future development is on
again. Salt liberally. (Just to further
confuse things, SDS is free for Solaris 8
up to 8 CPUs, even for commercial).
Installation Relatively easy. You must do special Easy. Follow the onscreen prompts;
things to first achieve root disk, swap, and let it do its reboots.
other disk mirroring in exactly the right
order.
Upgrading Easy, remove patches, remove packages, Slightly more complex, but well
add new packages documented. There are several ways
to do it.
Replacing failed Very easy. Replace disk and Very easy. Replace disk and
root mirror resynchronize resynchronize
Replacing failed Relatively easy. Boot off mirror, replace easy to slightly complex depending on
primary root disk disk, resync, boot off primary. setup. Well documented. 11 steps or
fewer.
Replacing failed Trivial Trivial
data disk in
redundant (mirrored
or RAID5) volume
Extensibility / Traditionally, relatively easy but Trivial. No limitations will be
number EXTREMELY limited by usage of hard encountered by most people. Number
of volumes partition table on disk. Number of total of volumes is potentially limitless.
volumes on a typical system is very
limited because of this. If you have a lot of
disks, you can still create a lot of
metadevices. The default is 256 max, but
this can be increased by setting
nmd=XXXX in /kernel/drv/[Link] and
then rebooting. Schemes for managing
metadevice naming for large number of
deices are available, but clunky and
occasionally contrived. NOTE: SDS
4.2.1+ (avail Sol7) removes the reliance
upon disk VTOC for making
metadevices through 'soft partitions'.
Moving a volume Difficult unless special planning and Trivial. On redundant volumes can be
precautions have been taken with laying done on the fly.
out the proper partition and disk labels
beforehand. Somewhat hidden by GUI.
Growing a volume Volume can be extended in two different Volume can be extended in two
ways. It can be concatenated with another different ways. The columns of the
 region of space someplace else or, if there stripe can be extended for Raid0/5,
is contiguous space following ALL of the simple single-disk volumes can be
partitions of the original volume, the stripe grown directly, and in VxVM > 3.0, a
can be extended. Using concatenation you volume can be re-layed out (The
could grow a 4 disk stripe by 2 additional number of columns in a RAID-5 stripe
disks. (e.g. 4 disk stripe concatenated with can be reconfigured on the fly!).
a 2 disk stripe). Contiguous space is not required. In
VXVM < 3.0 if you are increasing the
size of a stripe, you must have space
on disks where is the original number
of disks in a stripe. You can't 'grow'
(but could relayout) a 4 disk stripe by
adding two more disks, but you could
with 4. Extremely flexible.
Shrinking a volume difficult. You must adjust all disk or soft trivial. vxresize can shrink filesystem
(only possible with partitions manually. and volume in one command..
VxFS filesystem!)
Relayout volume Requires dump/restore of data. Available on the fly for VxVM > 3.0
(change 4 disk
raid-5 volume to 5
disk volume
Logging in SDS a Meta-trans device may be used VxVM has RAID-5 logs and
which provides a log based addition on top mirror/drl logs, Logging, if used need
of a UFS filesystem. This transaction log, not be mirrored, and volume can
if used, should be mirrorred! (Loss of log continue operating if log fails. Having
results in a filesystem that may be 1 is highly recommended for crash
corrupted even beyond fsck repair.) Use of recovery. Logs are infinitessimally
a UFS+ logging filesystem instead of a small, typically 1 disk cylinder or so.
trans device is a better alternative. UFS+ The SDS logs are really more
logging is availabe in Sol7 and above. equivalent to a VxFS log at the
filesystem level, but it is worth
mentioning the additional capabilities
of VxVM in this regard. UFS+ with
logging can also be used on a VxVM
volume. There are many kinds of
purpose-specific logs for things like
fast mirror resync, volume replication,
database logging, etc.
Performance Your mileage may vary. SDS seems to excel at simple RAID-0 striping, but seems
to be only marginally faster than VxVM. VxVM also seems to gain back when
using large interleaves. For best results, benchmark YOUR data with YOUR app
and pay very close attention to your data size and your stripe unit/interleave size.
RAID5 on VxVM is almost always faster by 20-30%.
Links: archive1, archive2
Notifications (see SNMP traps are used for notification. You VxVM uses email for notifying you
also) must have something set to receive them. when a volume is being moved
Notifications are limited in scope. because of bad blocks using hot
relocation or sparing. The notification
is very good.
Sparing hot spare disks may be designated for a hot spare disks may be designated for
diskset, but must be done at the slice level. a diskgroup. Or, extra space on any
disk can be used for dynamic hot
relocation without the need for
 reserving a spare.
Terminology SDS diskset = VxVM diskgroup, SDS metadevice = VxVM volume, SDS Trans
device ~ VxVM log, VxVM has subdisks which are units of data (e.g. a column of
a stripe) that have no SDS equivalent. VxVM plexes are groupings of subdisks
(e.g. into a stripe) that have no real SDS equivalent. VxVM Volumes are
groupings of plexes. (e.g. the data plex and a log plex, or 2 plexes for a 0+1
volume)
GUI Most people prefer the VxVM GUI, though there are a few that prefer the (now 4
years old) SDS gui. SDS has been renamed SVM in Solaris9 and the GUI is
supposedly much improved. VxVM has gone through 3-4 GUI incarnations.
Disclaimer: I *never* use the GUI
command line usage metareplace, metaclear to delete, metainit vxassist is used for creation of all
for volumes, metadb for state databases, volume types, vxsd, vxvol, vxplex
etc operate on appropriate VxVM objects
(see terminology above). Generally,
there are many more vx specific
commands, but normal usage rarely
requires 20% of these except for
advanced configurations (special
initializations, using alternate pathing,
etc)
device database Kept in special, replicated, partitions you Kept in the private region on each
configuration copies must setup on disk and configure via disk. Disks can move about and the
metdb. /etc/opt/SUNWmd, and /etc/system machine can be reinstalled without
contain the boot/metadb information and having to worry about losing data in
description of the volumes. Lose these and volumes.
you have big problems. NOTE: in
Solaris9 SVM, configuration copies are
now kept on the metadisks themselves
with the data, like VxVM
Typical usage Simple mirroring of root disk, simple enterprise ready. Data mobility,
striping of disks where situation is scalability, and configuration are all
relatively stagnant (e.g. just a bunch of extensively addressed. Replacing
disks with RAID0 and no immediate failed encapsulated rootdisk is more
scaling or mobility concerns). Scales well complicated than it needs to be. See
in size of small number of volumes, but Sun best practices paper for a better
poorly in large number of smaller way. Other alternatives exist.
volumes.
Best features Simple/simplistic - root/swap mirroring extensible, error notifications are
and simple striping is no brainer, free or good, extremeley configurable,
nearly so. Easier to fix by hand (without relayout on the fly with VxVM > 3.0,
immediate support) when something goes nice integration with VxFS, best
fubar (vxvm is much more complex to scalability. Excellent edu pricing.
understand under the hood).
Worst features configuration syntax (meta*), expensive for enterprises and big
configuration information stored on host servers, root mirroring and primary
system (< Sol9). Metadb/slices -- a rootdisk failure for encapsulated
remnant from SunOS4 days! -- needs to be rootdisk is too complex (but well
completely redone; naming is inflexible documented) (should be fixed in
and limited. Number of hard metadevices VxVM 4.0), somewhat steep learning
has kernel hack workarounds, but is still curve for advanced usage. Recovery
very limiting. Required mirroring of trans from administrative SNAFUs
 logs is inconvenient, but mitigated by (involving restore and single user
using native UFS+ w/logging in Solaris7 mode) on a mirrored rootdisk can be
and above. Lack of drive level hotsparing troublesome.
is extremely inconvenient.
Tips keep backups of your of configuration in In VxVM regular usage of vxprint -ht
case of corruption. Regular usage of is useful for disaster recovery. There
metastat, metastat -p, and prtvtoc can help. are also several different disaster
recovery scripts here
Using VxVM for Many people do this. There are tradeoffs. One the one hand you have added
data and SDS simplicity in the management of your rootdisks by not having to deal with VxVM
for root mirroring encapsulation, which can ease recovery and upgrades. On the other hand, you now
have the added complexity of having to maintain a separate rootdg volume
someplace else, or use a simple slice (which, by the way, neither Sun nor Veritas
will support if there are problems). You also have the added complexity of
managing too completely separate storage/volume management products and their
associated nuances and patches. In the end it boils down to preference. There is no
right or wrong answer here, though some will say otherwise. ;) Veritas VxVM 4.0
removes the requirement for rootdg.