AIX: LVM Overview
LVM Theory
Physical Volume = PV is IBM speak for a disk (it could be worse some IBMers still refer to DASD! (Dyanical Access Storage Device which is a main frame term). They are:
- Named by AIX as hdisk0, hdisk1, hdisk2, ...
- Regardless of the underlying technology (SCSI, SSA sort of IBM's early SAN, SAN, RAID5 using the adapter)
- Disk and AIX automatic bad block reallocation
Volume Group = VG is IBM speak for a group of disks
Volume Group operations:
- Disk space always allocated within single VG
- All disks available in AIX or none - work as a group
- Can be exported to be attached to other AIX - allows High Availability HACMP
- First VG called rootvg
- AIX files
- Initial paging
- Usually only the first disk
- Or two, to allow mirroring of rootvg
- Often internal disks
- Recommend: Keep to a small number of disks
- Other VG created by the System Admin.
- Name typically related to their use
- Optionally ending in "vg"
- One or more disks
- Can later add a disk to a VG
- Can remove disk from VG - if empty
- Disks within VG cut into chunks called
- Physical Partitions (PP)
- Minimum allocation unit
- Typically, 8, 16 or 32 MB (older 2GB disks = 4 MB)
- Nothing smaller can be allocated
- Each VG fixed PP size.
- Volume group has total, free and used PPs *Disks do not need to be the same size or even the same technology
- It is a large piece of disk
- Can be used for lots of tasks like
- raw device or file system or paging space
- Created within single VG
- LV has many attributes like
mirrored or striped
particular part of disk
Sizes is in Physical Partitions - example: id PP = 16 MB and LV size of 64 PPs = GBPPs allocated by policies
- min or max spread across disks
- min=fill disk then move on, max=evenly spread
- disk placement centre, middle, edge
- mirrors via extra copies
- stripes via stripe width
- MWC (Mirrored write consistancy) and others
Logical Volumes Admin
- Can be grown in size
- Can be removed
- Can be moved to different disks within VG
- Can later have a filesystem created in it
- Attributes can be changed like: mirror added or removed or policy changed
How AIX/LVM sees the underlying disks
LVM in practice
The disks can be apprached from three different directions and from there you can see the relationship to the others.
As a reminder
- pv = physical volumes - real disk or LUN
- lv = logical volume
- vg volume group
To the this use the ls
- lspv
- lslv
- lsvg
In more detail
Lists volume group names: lsvg
- List VG details: lsvg
- List LVs within VG: lsvg -l
- List PV within VG: lsvg -p
- List PV details: lspv hdiskN
- List LVs within PV: lspv -l hdiskN
- List PP within PV: lspv -p hdiskN
- Lists LV names: lsvg -l
- List LV details: lslv
- List LVs within PV: lslv -l
- List PP within PV: lslv -p
- Show mirrored LV: lslv -m
When you create a Logical Volume with smitty you will see a panel like this:
smitty create logical partition
Add a Logical Volume
Logical volume NAME [scratch]
VOLUME GROUP name testvg
Number of LOGICAL PARTITIONS [64]
# PHYSICAL VOLUME names [hdisk1 hdisk2 hdisk3] +
Logical volume TYPE [jfs]
POSITION on physical volume middle +
RANGE of physical volumes minimum +
MAXIMUM NUMBER of PHYSICAL VOLUMES [] # to use for allocation
Number of COPIES of each logical partition 2 +
partition Mirror Write Consistency? yes +
Allocate each logical partition copy on a SEPARATE physical volume? yes +
RELOCATE the logical volume during reorganization? yes +
Logical volume LABEL []
MAXIMUM NUMBER of LOGICAL PARTITIONS [512]
# Enable BAD BLOCK relocation? yes +
SCHEDULING POLICY for reading/writing logical partition copies parallel +
Enable WRITE VERIFY? no +
Some of the terms used are described below:
Mirrors
On the disk placement
Mirror Scheduling Policy
Mirror Write Consistency
If you are terribly and extremely unlucky ... a crash could happen leaving the two mirrored copies of a block different.
Reading the block could give you the old or new block.
With a RDBMS, it does not mind disk is newer but must be consist when read.
MWC reminds LVM to "resilver" these recently written blocks in recovery - to make them the same.
Physical Partition (PP) Allocation
Logical Volumes striping
- From AIX 4.3.3 (not backward compatible) LVM support striping
- Often called fine striping (i.e. not PP level striping)
- Recommend 32K, 64K or 128K stripe width = 4 to 16 times I/O size most databases do 4K or 8K I/O
- Excellent for balancing serial and random I/O across disks
- Excellent read ahead serial I/O boost
- Find unused disks: lspv
- Add them to a VG or create a VG: smitty lvm + VG + Add VG
- Check unused space in VG: lsvg
- Create a LV: smitty lvm + LV + Add LV
- Create a Filesystem (JFS)smitty jfs + Add jfs + standard + which VG (see below)
This is needed to allow recovery of the change - if the system fails during the update.
Creating Stripes Tips:
- Stripes LV must contain a whole number of items, that is the number of PPs must divide evenly into the number of disks
- Or put another way: each disk have the same number of PPs
- Hint: use multiples of No. of disks to make this easier
There are three ways to create a mirror:
One Step = create LV with mirror
- These can be slow as you can have to wait until mirror complete before creating next lv
- again slow as you can have to wait for silvering #Create LV and later add mirror synchronise=no and then sychronise all mirrors together
- Use this when creating lots of lv because all mirrors can be created at the same time
- create lv's
- add mirrors sync=no
- syncvg -l to remove "stale" partitions = resilver
- resilvering hurts performance
- often forgotten when recommending mirror breaking for backup purposes
LVM Higher Level Management Commands
Disown disks ready to connect them to another system
- varyoffvg
- exportvg
- or smitty lvm
- cfgmgr – finds disks
- importvg hdiskN – any one of the disks
- varyonvg
– mounts file systems
migratelv (not striped)
- Use smit lvm
- Can migrate LV on a disk to another disk
- Can empty whole disk to remove it later or replac a fault disk
- Disks can be added and removed from a VG
- extendvg and reducevg
- Use smit lvm recommended
Small rootvg - 1 or 2 disks (for mksysb backup)
Mirror rootvg for AIX disk protection
- Add disk hdisk1
- chvg -Qn rootvg
- For hd1 to hd8 and hd9var copy the LV
- mklvcopy hd{1,2,3,4,5,6,7,8,9var} 2 hdisk1
- syncvg -v rootvg
- bosboot -a
- bootlist -m normal hdisk0 hdisk1
- Or
- mirrorvg -s rootvg
this second option is recommended
TIP: This command will show you formatted list of active Volume groups
for i in $(lsvg -o);do lsvg $i;done \ awk ' BEGIN { printf("%-10s\t%10s\t%10s\t%10s\t%10s\n","VG","Total(MB)","Free","USED","Disks") };/VOLUME GROUP:/ \ { printf("%-10s\t", $3) };/TOTAL PP/ { B=index($0,"(") + 1;E=index($0," megaby");D=E-B;printf("%10s\t", substr($0,B,D) );};/FREE PP/ \ { B=index($0,"(") + 1;E=index($0," megaby");D=E-B;printf("%10s\t", substr($0,B,D) );};/USED PP/ \ { B=index($0,"(") + 1;E=index($0," megaby");D=E-B;printf("%10s\t", substr($0,B,D) );};/ACTIVE PV/ { printf("%10s\t\n", $3) } '
Put other disks into other volume groups
- use min PP size ( 8MB or 16 MB)
- use 16 to 32 disks per volume group
- use different vg for data that might be moved elsewhere
- Avoid hot disks
- Spread data across disk with LVs or RAID5
- Mirrors add protection and performance
- Use striping whenever possible
- Think spindles not disk size reorgvg
- this will move physical partitions (PP) around in an attempt to get PPs in the right place migratepv
- this can be used to spread PPs across move disks
- also to remove all PPs from a suspect disk before replacement (due to errors being reported)
AVOIDING Disk Crashes
- Rule One: don't let this stop your system
- RAID5 or mirror everything
- Rule Two: monitor error logs
- Make sure you know when a disk failed
- Rule Three: call hardware support
- That is what they are for
- Rule Four: Don't meddle
- Only try, if you know what you are doing
- Rule Five: Read and practise
- Get the Redbooks and try it safely
Comments
Post a Comment