Veritas Storage Foundation 5.0 for Oracle RAC Configuration Guide Extracts for HP Serviceguard Storage Management Suite, Second Edition, May 2008

Introducing Serviceguard Extension for RAC
Cluster Volume Manager
Chapter 1
19
Cluster Volume Manager
CVM is an extension of Veritas Volume Manager, the industry-standard storage
virtualization platform. CVM extends the concepts of VxVM across multiple nodes. Each
node recognizes the same logical volume layout, and more importantly, the same state of
all volume resources.
CVM supports performance-enhancing capabilities, such as striping, mirroring, and
mirror break-off (snapshot) for off-host backup. You can use standard VxVM commands
from one node in the cluster to manage all storage. All other nodes immediately
recognize any changes in disk group and volume configuration with no interaction.
CVM Architecture
CVM is designed with a “master and slave” architecture. One node in the cluster acts as
the configuration master for logical volume management, and all other nodes are slaves.
Any node can take over as master if the existing master fails. The CVM master exists on
a per-cluster basis and uses GAB and LLT to transport its configuration data.
Just as with VxVM, the Volume Manager configuration daemon, vxconfigd, maintains
the configuration of logical volumes. This daemon handles changes to the volumes by
updating the operating system at the kernel level. For example, if a mirror of a volume
fails, the mirror detaches from the volume and vxconfigd determines the proper course of
action, updates the new volume layout, and informs the kernel of a new volume layout.
CVM extends this behavior across multiple nodes and propagates volume changes to the
master vxconfigd. (You must perform operator-initiated changes on the master node.)
The vxconfigd process on the master pushes these changes out to slave vxconfigd
processes, each of which updates the local kernel.
CVM does not impose any write locking between nodes. Each node is free to update any
area of the storage. All data integrity is the responsibility of the upper application. From
an application perspective, standalone systems access logical volumes in the same way
as CVM systems.
CVM imposes a “Uniform Shared Storage” model. All nodes must connect to the same
disk sets for a given disk group. Any node unable to detect the entire set of physical disks
for a given disk group cannot import the group. If a node loses contact with a specific
disk, CVM excludes the node from participating in the use of that disk.
CVM Communication
CVM communication involves various GAB ports for different types of communication.
Port W
Most CVM communication uses port w for vxconfigd communications. During any
change in volume configuration, such as volume creation, plex attachment or
detachment, and volume resizing, vxconfigd on the master node uses port w to share this
information with slave nodes.
When all slaves use port w to acknowledge the new configuration as the next active
configuration, the master updates this record to the disk headers in the VxVM private
region for the disk group as the next configuration.