Logical Volume Manager (LVM)

The following policies, guidelines, standards, and procedures describe the business continuity methodology used to maintain LVM storage definitions in large, multi-system, multi-datacenter AIX environments. In support of a business continuity environment, all application programs, files, and data should be located in non-rootvg volume groups, on external disks in the SAN environment. Maintenance, backups, fail-overs, system recovery, and disaster recovery procedures will be made easier, predictable, repeatable by adhering to this rule.

The supporting principles of business continuity provide the basis for standardized LVM storage structures. Those principles are:

• Policies - those things that shall be done
• Guidelines - those things that should be done or can be expected
• Standards - the structure, based on policies and guidelines
• Procedures - step-by-step instructions of how to implement the structure

Policies:

• The boot disk for each AIX system should be located on the SAN environment. Redundant mirrors may be located internally in each machine.
• All data and applications will be stored separately from the "rootvg" volume group. Additional volume groups will be configured for storage of data and applications as necessary.
• Each volume group shall have an enterprise wide unique name for the purpose of eliminating naming conflicts during manual, HACMP, or Disaster Recovery fail-overs.
• Each volume group volume shall have a cluster wide unique major number for the purpose of eliminating numbering conflicts during manual, HACMP, or Disaster Recovery fail-overs. If possible, make the major number unique enterprise wide.
• Each logical volume shall have an enterprise wide unique name for the purpose of eliminating naming conflicts during manual, HACMP, or Disaster Recovery fail-overs.
• Each volume group that contains file systems will require at least one JFS log. Each JFS Log logical volume shall have an enterprise wide unique name for the purpose of eliminating naming conflicts during manual, HACMP, or Disaster Recovery fail-overs.
• Each file system shall have an enterprise wide unique mount point directory for the purpose of eliminating directory conflicts during manual, HACMP, or Disaster Recovery fail-overs.

Guidelines:

• Each AIX system will host one or more resource groups.
• There should be a unique DNS entry based on each resource group name. These names shall be aliases pointing to IP names that are assigned to IP addresses.
• Application volume group, logical volume, JFS log logical volumes, and file system mount point names should be enterprise wide unique values based on the resource group name.
• Where possible create volume groups with an enterprise wide unique major number. At a bare minimum, the major number should be cluster wide unique.
• More than one JFS log may be configured for a volume group if necessary, dependent upon file system load.
• In order to ensure successful installation of an application into unique mount points, the application team must work closely with the system engineer.

Standards: Volume Group Name

• To assign enterprise wide unique volume group (VG) names, the system administrator must first define the resource group names. Once the resource group names have been defined, then a VG name may be defined based on the resource group name.
• In order to facilitate normal maintenance, disaster recovery and business continuity, it is recommended that each enterprise wide unique volume group name be assigned enterprise wide unique major number.
• A single AIX system may contain multiple resource groups, and typically there will be one VG defined per resource group. However, a resource group may contain several VG's, depending upon the requirements of the application.
• To define a VG name, obtain the 8 character resource group name. then add a 2 digit volume group sequence number that will uniquely identify the VG, followed by the characters "vg". The VG name will always end with the characters "vg".

The VG name shall consist of exactly 12 characters with the following structure (the first 8 characters consisting of the resource group name):

Table 1: Volume Group Name Structure

Application Code	+	Environment	+	Function	+	Company	+	RG Sequence ID	+	VG Sequence ID	+	"vg"
3 char	+	1 char	+	1 char	+	2 char	+	1 char	+	2 char	+	2 char

As an example, a resource group named "db2apmx0", may have multiple associated VG's:

Table 2: Example Volume Group Names

RG Name Component	VG Sequence Identifier	LV Identifier	VG Name
db2apmx0	00	vg	db2apmx000vg
db2apmx0	01	vg	db2apmx001vg
db2apmx0	02	vg	db2apmx002vg

Each VG also requires a server or cluster wide unique Major Number. A unique major number can be generated using the following algorithm:

VGNAME="db2apmx000vg"
MajorNbr=$( print "${VGNAME}" | sum -o | awk '{ print $1 }' )
print ${MajorNbr}

To reiterate, before creating a VG, first establish an enterprise wide unique resource group name, a VG name, and a major number. Then create the VG.

NOTE: If virtualization is being implemented, the VG name must be determined BEFORE storage is allocated on the VIO server for the client LPAR. This is so the VG name can be used on the VIO server as a component of defining the Virtual Target Device (VTD) name. The VTD name will consist of the VG name, minus the "vg" characters, plus a 3 digit number representing the hdisk number on the VIO server. This is described in a separate document.

Standards: Logical Volume Name

• To assign enterprise wide unique logical volume (LV) names, the system administrator must first define the resource group names. Once the resource group names have been defined, then a VG must be defined based on the RG name. After the VG has been created, LV's can be assigned. A VG will typically contain several LV's, and each LV will be named based on the resource group to which it is associated.
• To define a LV name, obtain the 8 character resource group name, then add a 4 digit logical volume sequence identifier that will uniquely identify the LV, followed by the characters "lv". The 4 digit LV sequence identifier will consist of alpha-numeric characters and must always be exactly 4 characters in length. The LV name will always end with the characters "lv".

The LV name shall consist of exactly 14 characters with the following structure (the first 8 characters consisting of the resource group name):

Table 3: Logical Volume Name Structure

Application Code	+	Environment	+	Function	+	Company	+	RG Sequence ID	+	LV Sequence ID	+	"lv"
3 char	+	1 char	+	1 char	+	2 char	+	1 char	+	4 char	+	2 char

As an example, a resource group named "db2apmx0", may have a volume group named "db2apmx00vg". This volume group may have multiple LV's associated with it:

Table 4: Example Logical Volume Names

RG Name Component	LV Sequence Identifier	LV Identifier	LV Name
db2apmx0	db20	lv	db2apmx0db20lv
db2apmx0	db21	lv	db2apmx0db21lv
db2apmx0	db22	lv	db2apmx0db22lv

JFS file systems will require a logical volume for the JFS log. This must also have an enterprise wide unique name.

Standards: JFS Log Logical Volume Name

• To assign enterprise wide unique JFS Log LV names, the system administrator must first define the resource group names. Once the resource group names have been defined, then a VG must be defined based on the RG name. After the VG has been created, JFS Log LV's can be assigned. A VG will typically contain one JFS Log LV's, however multiple JFS Log LV's can exist.
• To define a JFS Log LV name, obtain the 8 character resource group name, then add the 4 digit logical volume sequence identifier that will uniquely identify the JFS Log LV, followed by the characters "lv". The 4 digit JFS Log LV sequence identifier will consist of the characters "jfs" followed by a single digit to uniquely identify the JFS Log LV. The JFS Log LV name will always end with the characters "lv".

The JFS Log LV name shall consist of exactly 14 characters with the following structure (the first 8 characters consisting of the resource group name):

Table 5: Log Logical Volume Name Structure

Application Code	+	Environment	+	Function	+	Company	+	RG Sequence ID	+	"jfs"	+	JFS Sequence ID	+	"lv"
3 char	+	1 char	+	1 char	+	2 char	+	1 char	+	3 char	+	1 char	+	2 char

As an example, a resource group named "db2apmx0", may have a volume group named "db2apmx00vg". This volume group may have multiple JFS Log LV's associated with it:

Table 6: Example Log Logical Volume Names

RG Name Component	JFS Log LV Sequence ID	JFS Log LV ID	JFS Log LV Name
db2apmx0	jfs0	lv	db2apmx0jfs0lv
db2apmx0	jfs1	lv	db2apmx0jfs1lv
db2apmx0	jfs2	lv	db2apmx0jfs2lv

JFS file systems will require a logical volume for the JFS log. This must also have an enterprise wide unique name.

Standards: File System Directory Mount Points

• To assign enterprise wide unique LV names, the system administrator must first define the resource groups, Volume Groups and Logical Volumes. Once these have been defined, the file system mount point directory names can be assigned. Typically a file system mount point is required for each logical volume, therefore the mount point can usually be based on the logical volume name, or at a minimum the resource group name.
• To define a file system mount point directory name, obtain the 8 character resource group name, then depending upon the applications file system requirements, use the RG name as the mount point, or add sub-directories to make it enterprise wide unique.

The file system directory mount point name shall consist of at least 8 characters but may be of a variable length (the first 8 characters consisting of the resource group name):

Table 7: Directory Mount Point Name Structure

/	+	Application Code	+	Environment	+	Function	+	Company	+	RG Sequence ID	+	LV Sequence ID or Directory Structure
1 char	+	3 char	+	1 char	+	1 char	+	2 char	+	1 char	+	4 char or more

As an example, a resource group named "db2apmx0", may have multiple file systems associated with it:

Table 8: Example Directory Mount Point Names

RG Name Component	Optional Logical Volume Sequence ID	Optional Sub-Directories	file system Mount Point
db2apmx0		db2_08_01/bin	/db2apmx0/db2_08_01/bin
db2apmx0		db2_08_01/data	/db2apmx0/db2_08_01/data
db2apmx1	mq01		/db2apmx1mq01
db2apmx1	mq02		/db2apmx1mq02
db2apmx1	mq03		/db2apmx1mq03

Procedures:

The procedures associated with implementing the standards described here require strict attention to detail when creating volume groups, logical volumes and file systems. The system administrator must plan the implementation and define a "resource group" to associate with the naming structures. For example, the steps in defining a new file system are as follows:

1. Define an enterprise wide unique resource group name.
2. Define an enterprise wide unique volume group name.
3. Define a cluster wide unique (enterprise wide unique if possible) major number for the new volume group.
4. Define an enterprise wide unique JFS log logical volume name.
5. Define an enterprise wide unique logical volume name.
6. Define an enterprise wide unique mount point directory name.
7. Create the volume group using the enterprise wide unique name and major number.
8. Create the JFS log logical volume using the enterprise wide unique name.
9. Create the logical volume using the enterprise wide unique name.
10. Create the file system on the logical volume using the enterprise wide unique mount point directory and JFS log.

System design and implementation in a business continuity environment should be regarded as a "non-standard" design. Normally a "standard" implementation does not account for the ability to perform fail-overs from any AIX system to any other AIX system, as is described here. When installing applications in this "business continuity" environment recognize that the application vendor will almost always provide "standard" installation instructions, not "business continuity" installation instructions. For the system and application administrators, there is a learning curve associated with moving from a "standard" environment to a "business continuity" environment because the "standard" installation instructions for applications must usually be modified to fit this enhanced environment.

The procedures for each application to be installed in the "business continuity" environment will be specific to each environment and will likely be different from the documentation provided by the application vendor. It will be the job of the system and application administrators to create a procedure to fit the environment.