Fundas
Table of contents
1. Volume Manager Objects 1.1 Disks 1.2 Disk groups 1.3 Volume Manager disks 1.4 Subdisks 1.5 Plexes 1.6 Volumes 1.7 Volume Manger Objects & their Relationship 2. Kernels and Daemons 2.1 vxiod 2.2 vxconfigd 2.3 vxrelocd
Disks are referred in volume manager by two terms - device name and disk name . The device name specifies controller , target id and slice of the disk . Disk name is the common name given to the device name as an easy to remember name .
For example device name c2t3d0s2 represents controller number 2 , target id 3 , disk group 0 and slice 2 and disk01 may be its disk name . While device name is system dependent based on controller and disk id the disk name is user defined .
A disk group is a collection of volume manager disks grouped together to hold the data . All the configuration changes made to a disk group are applied to the disks in that disk group only.
Volume Manager objects cannot span disk groups i.e. all the operations on a particular disk group remains confined to that particular group .
Disk groups enable high availability as these can be shared by two or more hosts but can be accessed by only one host at a time. In two hosts and a shared storage situation one host can take over the ownership of the disk groups and drives in case other host fails.
Adding physical disks to the volume manager results in creation of public and private region in the disk by the volume manager .The public region is the disk space available for volume space and the private region stores the configuration information.
A Volume Manager disks are created from the public region of a physical disk that is under Volume Manager control. Each volume manager disk corresponds to one physical disk.
A volume manager disk is given a disk media name when it is added to a disk group which can be default or unique user defined..
Once a volume manager disk is assigned a disk media name, the disk is no longer referred to by its physical address of c#t#d#. The physical address of c#t#d# becomes known as the disk access record.
A subdisk is a subsection of a disk's public region and is the smallest unit of storage in Volume Manager.
A subdisk is defined by an offset and a length in sectors on a volume manager disk.
A volume manager disk can contain multiple subdisks but subdisks cannot overlap or share the same portions of a volume manager disk.
volume manager disk space that is not reserved or that is not part of a subdisk is free space. You can use free space to create new subdisks.
A subdisk is similar to a partition but with following differences :
The maximum number of partitions to a disk is eight.
There is no theoretical limit to number of subdisks that can be attached to a single plex, but it has been limited to a default value of 4096. If required, this default can be changed, using the vol_subdisk_num tunable parameter.
A plex is a structured or ordered collection of subdisks that represents one copy of the data in a volume. A plex consists of one or more subdisks located on one or more physical disks.
A plex is also called a mirror. The terms plex and mirror can be used interchangeably, even though a plex is only one copy of the data. The terms "mirrored" or "mirroring" imply two or more copies of data.
The length of a plex is determined by the last block that can be read or written on the last subdisk in the plex.
The default naming convention for plexes in a volume is volumename-##. The default plex name consists of the volume name, a hyphen, and a two-digit number
A volume is composed of one or more plexes not restricted by the physical size of the disk.
A volume can span across multiple disks.
Volume Manager uses the default naming convention vol## for volumes, where ## represents a two-digit number but can be user defined as per requirement.
Veritas Kernel modules and Daemons
VERITAS actually utilizes kernel modules, which are the backbone of the application. You can see some of the driver loads in /etc/system. You'll see several driver forceloads. This is important to note because on most systems you'll see "WARNING: Forceload of dev/XXX Failed!" messages at boot up. Don't worry about these, it just means that VERITAS is trying to load a driver for a piece of hardware you don't have.
VERITAS also has several daemons running all the time to keep watch over your volumes, and to ensure smooth operation. Generally will see 3 common daemons, which are:
- vxiod
- vxconfigd
- vxrelocd
vxiod is the VERITAS IO Manager, which manages reads and writes to volumes. The vxiod daemons are started at system boot time. There are typically several vxiod daemons running at all times. Rebooting after your initial installation starts the vxiod daemon.
The vxiod daemon is a kernel thread and is not visible through the ps command To find out whether the any vxiod daemons are running, run the vxiod command. If any vxiod daemons are running, the following message is displayed:
# vxiod 10 volume I/O daemons running
where 10 is the number of vxiod daemons currently running.
If no vxiod daemons are currently running, start some by entering this command:
# vxiod set 10
where 10 can be substituted by the desired number of vxiod daemons. It is recommended that at least one vxiod daemon exist for each CPU in the system.
The Volume Manager configuration daemon (vxconfigd) maintains Volume Manager disk and disk group configurations. The vxconfigd daemon communicates configuration changes to the kernel and modifies configuration information stored on disk. Startup scripts invoke the vxconfigd daemon during the boot procedure.
To determine whether the volume daemon is enabled
# vxdctl mode mode: enabled (if vxconfigd running and
If vxconfigd is running, but not enabled then you get the following output
# vxdctl mode mode: disabled
If the vxconfigd daemon is not running:
# vxdctl mode mode: not-running
To enable the volume daemon,
# vxdctl enable
To start the vxconfigd daemon, use the following command:
# vxconfigd
Once started, the vxconfigd daemon automatically becomes a background process.
The Vx Hot Swap Manager, which monitor VERITAS Volume Manager for failure events and reacts to disk failures with spares.
By default, vxrelocd sends mail to root with information about a detected failure and the status of any relocation and recovery attempts. To send mail to other users, add the user login name to the vxrelocd startup line in the startup script /etc/init.d/vxvm-recover and reboot the system.