Home About BC DR HA Support Training Download
You are here: Home/ Documentation/ mtxia/ lvm/ Please Login or Register

-
Current Location
-

js
  Documentation
    mtxia
      lvm



-
 Mt Xia Inc.
-
BOOK:Advanced Shell Scripting



 Join our LinkedIn Group
AIX Advanced Technical Experts
Contract Opportunities

www.LinkedIn.com
-
 Train By Tweet
Training courses Tweet By Tweet
Various Subjects and Products
TrainByTweet.com


AIX Admin Methodology
Global Consolidation Project
All AIX admins should join
www.aixexpert.com
-

digg Digg this page
del.icio.us Post to del.icio.us
Slashdot Slashdot it!


AIX FREE DEMO UNIX
Automated AIX Deployment
Reduce your DC costs

www.siteox.com

LPAR Leasing
Lease an AIX / i5 LPAR
Reduce your costs

www.mtxia.com

Server Leasing
Lease a Server off-site
Reduce your costs

www.mtxia.com

Data Center Automation
Business Continuity and DR
Virtualization/Consolidation

www.mtxia.com

HMC Service
Hardware Management Console
Manage Remote AIX / i5 LPARs

www.siteox.com

Business Web Site Hosting
$3.99 / month includes Tools,
Shopping Cart, Site Builder

www.siteox.com

Disaster Recovery
Small Business Oriented
Off-Site Facilities

www.mtxia.com

IBM pSeries / iSeries
Reduce your Costs
Off-Site Server Hosting

www.mtxia.com

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):

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

Table 1: Volume Group Name Structure

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

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

Table 2: Example Volume Group Names

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):

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

Table 3: Logical Volume Name Structure

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:

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

Table 4: Example Logical Volume Names

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):

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

Table 5: Log Logical Volume Name Structure

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:

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

Table 6: Example Log Logical Volume Names

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):

/ + 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

Table 7: Directory Mount Point Name Structure

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

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

Table 8: Example Directory Mount Point Names


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.

-
LVM Configuration
-
 

Top Level
EWU Values
RG Naming Standards


AIX FREE DEMO UNIX
Automated AIX Deployment
Reduce your DC costs

www.siteox.com

LPAR Leasing
Lease an AIX / i5 LPAR
Reduce your costs

www.mtxia.com

Server Leasing
Lease a Server off-site
Reduce your costs

www.mtxia.com

Data Center Automation
Business Continuity and DR
Virtualization/Consolidation

www.mtxia.com

HMC Service
Hardware Management Console
Manage Remote AIX / i5 LPARs

www.siteox.com

Business Web Site Hosting
$3.99 / month includes Tools,
Shopping Cart, Site Builder

www.siteox.com

Disaster Recovery
Small Business Oriented
Off-Site Facilities

www.mtxia.com

IBM pSeries / iSeries
Reduce your Costs
Off-Site Server Hosting

www.mtxia.com