пятница, 14 сентября 2012 г.

Performance Tuning Guide

NetBackup – cheat sheet

http://www.scribd.com/doc/2675247/netbackup-cheat-sheet

Netbackup Cheat Sheet
Master Daemons | Media Daemons | Catalog | Log Files | Server | Volume | Media Tape/Robot Archive | Client
Master Server Daemons/Processes
Request daemonbprd
Schedulerbpsched (started with bprd)
Netbackup database managerbpdbm (started with bpsched)
Job Monitorbpjobd (started with bpdbm)
Media Server Daemons/Processes
Communications daemonbpcd
Backup and restore managerbpbrm (started with bpcd)
Tape Managerbptm (started with bpbrm)
Disk Managerbpdm (started with bpbrm)
Media Managerltid
Bar code readeravrd (started with ltid)
Remote device management/ controls volume databasevmd (started with ltid)
Roboticdaemon (one on each media server) talks to tldcdtldd (started with ltid)
Robotic control daemon talks to the robot directl via scsitldcd (started with ltid)
Catalogs
Master Server
Information about backed-up filesimage - /opt/openv/netbackup/db
Storage Unit, Global Configuration, Catalog backup configuration.config - /opt/openv/netbackup/db
Backup Policy informationclass - /opt/openv/netbackup/db
Job status informationjobs - /opt/openv/netbackup/db
Netbackup logs with error and status informationerror - /opt/openv/netbackup/db
Information on volumes, volume pools, scratch pool and volume groupsvolume - /opt/openv/volmgr/database
Media Server
Tracks assigned volumes (media that has data them)media - /opt/openv/netbackup/db
Information about devices managed by the media serverdevice - /opt/openv/volmgr/database
Log and Information Files
Netbackup and Patch versions/opt/openv/netbackup/bin/version
Media Version/opt/openv/volmgr/version
Patch Level history/opt/openv/netbackup/patch/patch.history
Buffer size/opt/openv/netbackup/db/config/SIZE_DATA_BUFFERS
Number of buffers/opt/openv/netbackup/db/config/NUMBER_DATA_BUFFERS
Network Buffer Size/opt/openv/netbackup/NET_BUFFER_SZ (default = 32)
Java GUI authorisation/opt/openv/java/auth.conf
Catalog type (binary or ASCII)/opt/openv/netbackup/db/config/cat_format.cfg
Netbackup and media manager parameter files/opt/openv/netbackup/bp.conf
/opt/openv/volmgr/vm.conf
Corrupt Database image files (5.0 and above)/opt/openv/netbackup/db.corrupt
Server Commands
Check license details/opt/openv/netbackup/bin/admincmd/get_license_key
Start Netbackupnetbackup start

/opt/openv/netbackup/bin/initbprd (master)
/opt/openv/volmgr/bin/vmd (media)
Stop Netbackup (does not disconnect GUI sessions)netbackup stop
/opt/openv/netbackup/bin/admincmd/bprdreq -terminate (master)
/opt/openv/netbackup/bin/bpdbm -terminate (master)
Stop Netbackup and kill all GUI sessions/opt/openv/netbackup/bin/goodies/bp.kill_all
Start the GUI/opt/openv/netbackup/bin/jnbSA
Scan for tape devicessgscan (solaris)
ioscan (HPUX)
Display all Netbackup processesbpps -a
lists servers errors
bperror -U -problems -hoursago <number of hours>
bperror -U -backstat -by_statcode -hoursago <number of hours>
display information on a error codebperror -statuscode <statuscode> [-recommendation]
Reread bp.conf file without stopping Netbackupbprdreq -rereadconfig
Check database consistencybpdbm -consistency 1
bpdbm -consistency 2
Check for the below lines:
Bad image header
Does not exist
Netbackup Recovery
Device catalog is intactbprecover -l -m <media ID> -d dlt (listing)
bprecover -r -m <media ID> -d dlt (recovering)
Device catalog is gone or corruptedbprecover -l -tpath <tape_path> (listing)
bprecover -r -tpath <tape_path> (recovering)
Disk backupsbprecover -l -dpath <disk_path> (listing)
bprecover -r -dpath <disk_path> (recovering)
Volume Commands
Tape Drive and Inventory Commands
List drive status, detail drive info and pending requestsvmoprcmd
List the tape drive statusvmoprcmd -d ds
List the pending requestsvmoprcmd -d pr
Control a tape devicevmoprcmd [-reset][-up][-down] <drive number>
List all changes in the robot(but do not update)vmupdate -recommend -rt tld -rn 0
vmcheckxxx -rt tld -rn 0 -recommend
Empty the robot and re-inventory (using barcodes)vmupdate -rt tld -rn <robot number> -rh <silo slave> -vh <host> -nostderr -use_barcode_rules -use_seed -empty_ie
Tape Media Commands
List all poolsvmpool -listall -bx
List tapes in poolvmquery -pn <pool name> -bx
List all tapes in the robotvmquery -rn 0 -bx |grep 'TLD' | sort +4
List cleaning tapesvmquery -mt dlt_clean -bx
List tape volume detailsvmquery -m <media ID>
Delete a volume from the catalogvmdelete -m <media ID>
Change a tapes expiry datevmchange -exp 12/31/06 23:59:58 -m <media ID>
Change a tape's media poolvmchange -p <pool number> -m <media ID>
Media commands
List the storage unitsbpstulist -U
Freeze or unfreeze mediabpmedia [-freeze][-unfreeze] -ev <media ID>
List media detailsbpmedialist -ev <media ID>
List media contentsbpmedialist -U mcontents -m <media ID>
List backup Image Informationbpimagelist -backupid <image ID>
Expire client imagesbpimage -cleanup -allclients
Expire a tapebpexpdate -d 0 -ev <media ID> -force
List all netbackups jobsbpdbjobs -report [-hoursago]
Move media from one media server to anotherbpmedia -movedb -newserver <media server> -oldserver <media server>
Tape/Robot commands
List tape drivestpconfig -d
List cleaning times on drivestpclean -L
clean a drivetpclean -C <drive number>
change a drives cleaning frequencytpclean -F <drive> <frequency>
set a drives cleaning time to zerotpclean -M <drive>
Move tapes within robot using robtestrobtest
commands that can be used are as follows:

s s       (show slots)
s d       (show drives)
s i       (show load port)
m s250 d5 (move tape from slot 250 into drive 5)
uload d5  (unload tape from drive 5)
m d5 s250 (move tape from drive 5 to slot 250)
m s250 i1 (mov tape from slot 250 to load port 1)
List load port tapesecho "s i q" | tldtest -r /dev/sg/c0t4l0
List all slot contentsecho "s s q" | tldtest -r /dev/sg/c0t4l0
List tape drive contentsecho "s d q" | tldtest -r /dev/sg/c0t4l0
Move a tape in s100 to drive 1echo "m s100 d1" | tldtest -r /dev/sg/c0t4l0
Move a tape to load port 1echo "m s100 i1" | tldtest -r /dev/sg/c0t4l0
Archiving Commands
list archive infobpcatlist -client all -before Jul 01 2006
bpcatlist -client all -before Aug 01 2006
archive and remove imagesbpcatlist -before Jul 01 2006 | bpcatarc | bpcatrm
restore archive filesbpcatlist -before Jul 01 2006 | bpcatres
Client commands
test client connectivitybpclntcmd [-ip <ip addres>]
bpclntcmd [-hn <hostname>]
bpclntcmd [-pn]
bpclntcmd [-sv]

среда, 12 сентября 2012 г.

vxvm:vxvol reports error when trying to start a volume.


Problem



vxvm:vxvol reports error when trying to start a volume.

Error



vxvm:vxvol: ERROR: Volume has no CLEAN or non-volatile ACTIVE plexes

Solution



Description:
=========
Starting a volume reports the error above. The vxprint output shows that the plexes for the volume are in "DISABLED RECOVER" state.


Solution:
=======
The following commands must be run on a plex to change the state of the plex to "CLEAN". The volume can then be started,  but a fsck may be required before mounting the file system.

# vxmend -o force off <plex>
# vxmend on <plex>
# vxmend fix clean <plex>
# vxvol start <volume>
# fsck -F vxfs /dev/vx/rdsk/<diskgroup>/<volume>
# mount -F vxfs /dev/vx/dsk/<diskgroup>/<volume> /mountpoint


Here is an example:
The disk group dg01 has 2 volumes, apps and home. Trying to start all the volumes reported the following error:

# vxvol -g dg01 startall
vxvm:vxvol: ERROR: Volume home has no CLEAN or non-volatile ACTIVE plexes

# vxprint -g dg01 -th     <== Showed the following
...
dg dg01 2 2 123000 1021305687.1295.obp1

dm appsdisk c0t1d0s2 sliced 11555 71112735 -
dm appsmirror c1t1d0s2 sliced 11555 71112735 -
dm homedisk c2t0d0s2 sliced 14135 35349424 -
dm homemirror c3t0d0s2 sliced 14135 35349424 -

v apps - ENABLED ACTIVE 70840320 SELECT - fsgen
pl apps-01 apps ENABLED ACTIVE 70841169 CONCAT - RW
sd appsdisk-01 apps-01 appsdisk 0 70841169 0 c0t1d0s2 ENA
pl apps-02 apps ENABLED ACTIVE 70841169 CONCAT - RW
sd appsmirror-01 apps-02 appsmirror 0 70841169 0 c1t1d0s2 ENA

v home - DISABLED ACTIVE 16896000 SELECT - fsgen
pl home-01 home DISABLED RECOVER 16897232 CONCAT - RW
sd homedisk-01 home-01 homedisk 0 16897232 0 c2t0d0 RLOC
pl home-02 home DISABLED RECOVER 16897232 CONCAT - RW
sd h omemirror-01 home-02 homemirror 0 16897232 0 c3t0d0 ENA

The following commands need to be run on one of the plexes before trying to start the volume 'home':
# vxmend -o force off home-01
# vxmend on home-01
# vxmend fix clean home-01

The volume will then start successfully using the cleaned plex (the second plex, 'home-02' will automatically resync using plex 'home-01'):

# vxvol start home

Note: 
It may be necessary to run fsck on the file system before mounting it:

# fsck -F vxfs /dev/vx/rdsk/<diskgroup>/<volume>
# mount -F vxfs /dev/vx/dsk/<diskgroup>/<volume> /mountpoint




Legacy ID



251695

http://www.symantec.com/docs/TECH22671

How to recover and start a Veritas Volume Manager logical volume where the volume is DISABLED ACTIVE and has a plex that is DISABLED RECOVER

http://unix-essentials.blogspot.com/2008/01/vxvm-fixing-disabled-active-volumes.html
How to recover and start a Veritas Volume Manager logical volume where the volume is DISABLED ACTIVE and has a plex that is DISABLED RECOVER

Details:


When a system encounters a problem with a volume or a plex, or if Veritas Volume Manager (VxVM) has any reason to believe that the data is not synchronized, VxVM changes the kernel state, KSTATE and state, STATE, of the volume and its plexes accordingly. The plex state can be stale, empty, nodevice, etc. A particular plex state does not necessarily mean that the data is good or bad. The plex state is representative of VxVM's perception of the data in a plex.

The output from the vxprint utility using the switches "-h" and "-t" (for more information about these switches and all applicable switches, see the man page for vxprint) displays information from records in VxVM disk group configurations, including the KSTATE and STATE of a volume and plex as indicated in columns 4 and 5 respectively in the table below. When viewing the configuration records of a VxVM disk group using the vxprint utility and the KSTATE and STATE fields display DISABLED ACTIVE for the volume and DISABLED RECOVER for the plex, recovery steps need to be followed to bring the volume back to an ENABLED ACTIVE state so it can be mounted and make the file system accessible again.

From the below output, it can be seen that the KSTATE and STATE for the volume test is DISABLED ACTIVE and its plex test-01 is DISABLED RECOVER.

# vxprint -ht -g testdg

       
DG NAME NCONFIG   NLOG    MINORS   GROUP-ID   
DM NAME DEVICE    TYPE    PRIVLEN  PUBLEN   STATE 
RV NAME RLINK_CNT KSTATE  STATE    PRIMARY  DATAVOLS  SRL
RL NAME RVG       KSTATE  STATE    REM_HOST REM_DG    REM_RLNK
V  NAME RVG       KSTATE  STATE    LENGTH   USETYPE   PREFPLEX RDPOL
PL NAME VOLUME    KSTATE  STATE    LENGTH   LAYOUT    NCOL/WID MODE
SD NAME PLEX      DISK    DISKOFFS LENGTH   [COL/]OFF DEVICE   MODE
SV NAME PLEX      VOLNAME NVOLLAYR LENGTH   [COL/]OFF AM/NM    MODE
             

               
dg testdg default default 84000 970356463.1203.alu     
               
dm testdg01 c1t4d0s2 sliced 2179 8920560 -   
dm testdg02 c1t6d0s2 sliced 2179 8920560 -   
               
v test - DISABLED ACTIVE 17840128 fsgen - SELECT
pl test-01 test DISABLED RECOVER 17841120 CONCAT - RW
sd testdg01-01 test-01 testdg01 0 8920560 0 c1t4d0 ENA
sd testdg02-01 test-01 testdg02 0 8920560 8920560 c1t6d0 ENA




Follow these steps to change KSTATE and STATE of a plex that is DISABLED RECOVER to ENABLED ACTIVE so the volume can be recovered / started and the file system mounted:

1. Change the plex test-01 to the DISABLED STALE state:

vxmend -g  diskgroup fix stale <plex_name>


For example:

# vxmend -g testdg fix stale test-01


This output shows the plex test-01 as DISABLED STALE:

# vxprint -ht -g testdg

        
DG NAME NCONFIG   NLOG    MINORS   GROUP-ID   
DM NAME DEVICE    TYPE    PRIVLEN  PUBLEN   STATE 
RV NAME RLINK_CNT KSTATE  STATE    PRIMARY  DATAVOLS  SRL
RL NAME RVG       KSTATE  STATE    REM_HOST REM_DG    REM_RLNK
V  NAME RVG       KSTATE  STATE    LENGTH   USETYPE   PREFPLEX RDPOL
PL NAME VOLUME    KSTATE  STATE    LENGTH   LAYOUT    NCOL/WID MODE
SD NAME PLEX      DISK    DISKOFFS LENGTH   [COL/]OFF DEVICE   MODE
SV NAME PLEX      VOLNAME NVOLLAYR LENGTH   [COL/]OFF AM/NM    MODE
               
dg testdg default default 84000 970356463.1203.alu     
               
dm testdg01 c1t4d0s2 sliced 2179 8920560 -   
dm testdg02 c1t6d0s2 sliced 2179 8920560 -   
               
v test - DISABLED ACTIVE 17840128 fsgen - SELECT
pl test-01 test DISABLED STALE 17841120 CONCAT - RW
sd testdg01-01  test-01 testdg01 0 8920560 0 c1t4d0 ENA
sd testdg02-01  test-01 testdg02 0 8920560 8920560 c1t6d0 ENA



2. Change the plex test-01 to the DISABLED CLEAN state:

vxmend -g diskgroup fix clean <plex_name>


For example:

# vxmend -g testdg fix clean test-01


This output shows the plex test-01 as DISABLED CLEAN:

# vxprint -ht -g testdg

        
DG NAME NCONFIG   NLOG    MINORS   GROUP-ID   
DM NAME DEVICE    TYPE    PRIVLEN  PUBLEN   STATE 
RV NAME RLINK_CNT KSTATE  STATE    PRIMARY  DATAVOLS  SRL
RL NAME RVG       KSTATE  STATE    REM_HOST REM_DG    REM_RLNK
V  NAME RVG       KSTATE  STATE    LENGTH   USETYPE   PREFPLEX RDPOL
PL NAME VOLUME    KSTATE  STATE    LENGTH   LAYOUT    NCOL/WID MODE
SD NAME PLEX      DISK    DISKOFFS LENGTH   [COL/]OFF DEVICE   MODE
SV NAME PLEX      VOLNAME NVOLLAYR LENGTH   [COL/]OFF AM/NM    MODE
               
dg testdg default default 84000 970356463.1203.alu     
               
dm testdg01 c1t4d0s2 sliced 2179 8920560 -   
dm testdg02 c1t6d0s2 sliced 2179 8920560 -   
               
v test - DISABLED ACTIVE 17840128 fsgen - SELECT
pl test-01 test DISABLED CLEAN 17841120 CONCAT - RW
sd testdg01-01  test-01 testdg01 0 8920560 0 c1t4d0 ENA
sd testdg02-01  test-01 testdg02 0 8920560 8920560 c1t6d0 ENA



3. Start the volume test:

vxvol -g diskgroup start <volume>


For example:

# vxvol -g diskgroup start test


This output shows that the volume test and its plex test-01 are both ENABLED ACTIVE:

# vxprint -ht -g testdg
        
DG NAME NCONFIG   NLOG    MINORS   GROUP-ID   
DM NAME DEVICE    TYPE    PRIVLEN  PUBLEN   STATE 
RV NAME RLINK_CNT KSTATE  STATE    PRIMARY  DATAVOLS  SRL
RL NAME RVG       KSTATE  STATE    REM_HOST REM_DG    REM_RLNK
V  NAME RVG       KSTATE  STATE    LENGTH   USETYPE   PREFPLEX RDPOL
PL NAME VOLUME    KSTATE  STATE    LENGTH   LAYOUT    NCOL/WID MODE
SD NAME PLEX      DISK    DISKOFFS LENGTH   [COL/]OFF DEVICE   MODE
SV NAME PLEX      VOLNAME NVOLLAYR LENGTH   [COL/]OFF AM/NM    MODE
               
dg testdg default default 84000 970356463.1203.alu     
               
dm testdg01 c1t4d0s2 sliced 2179 8920560 -   
dm testdg02 c1t6d0s2 sliced 2179 8920560 -   
               
v test - ENABLED ACTIVE 17840128 fsgen - SELECT
pl test-01 test ENABLED ACTIVE 17841120 CONCAT - RW
sd testdg01-01  test-01 testdg01 0 8920560 0 c1t4d0 ENA
sd testdg02-01  test-01 testdg02 0 8920560 8920560 c1t6d0 ENA



4. Mount the volume to its associated mount point (refer to the /etc/vfstab file if the mount point location is not known) if the file system is a Veritas File System (VxFS) file system:

mount -F vxfs /dev/vx/dsk/diskgroup/volume /mount-point


For example:

# mount -F vxfs /dev/vx/dsk/testdg/test /testvol


Note: An error may be generated stating that the file system needs to be checked for consistency. If this occurs, run the VxFS specific fsck utility (/usr/lib/fs/vxfs/fsck) where the default is to replay the intent log, instead of performing a full structural file system check which is usually sufficient to set the file system to CLEAN and allow the volume to be mounted.


Veritas UNIX Essentials

7.1 Documentation

И снова о памяти в Linux - /proc/meminfo


И снова о памяти в Linux - /proc/meminfo

В продолжение поста о команде free, посмотрим на более полный источник об использовании памяти - специальную виртуальную файловую систему /proc, являющуюся общей точкой доступа к структурам данных ядра, а именно - на информацию /proc/meminfo. Вывод команды cat:
[andrey@server1 ~]$  cat /proc/meminfo
MemTotal:      1945312 kB
MemFree:         48980 kB
Buffers:          2248 kB
Cached:         171092 kB
SwapCached:        256 kB
Active:         622380 kB
Inactive:        32504 kB
HighTotal:     1048256 kB
HighFree:         3176 kB
LowTotal:       897056 kB
LowFree:         45804 kB
SwapTotal:     2048276 kB
SwapFree:      2047868 kB
Dirty:            2696 kB
Writeback:         400 kB
AnonPages:      481592 kB
Mapped:         137244 kB
Slab:            34244 kB
PageTables:       7276 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   2433156 kB
Committed_AS:  1277084 kB
VmallocTotal:   114680 kB
VmallocUsed:     14232 kB
VmallocChunk:    99948 kB

Пройдемся сверху вниз с некоторыми комментариями по части из этих значений.
MemTotal - Доступный объем оперативной памяти. Часть физически доступной памяти резервируется во время запуска системы ядром и не входит в указанный здесь объем:
[root@server1 ~]# grep Memory: /var/log/dmesg
Memory: 1941740k/1965760k available
(2097k kernel code, 22716k reserved,
 877k data, 228k init, 1048256k highmem)
MemFree - Какой объем памяти не используется и доступен для немедленного выделения процессам. Ядро Linux старается использовать доступную память максимально эффективно, и, по умолчанию, достаточно большой объем ОЗУ, потенциально доступный для приложений, может быть занят под кэш и буферы. Объем свободной памяти в несколько десятков мегабайт на машинах с гигабайтами оперативной памяти - вполне типичная картина для Linux. В 32-разрядной операционной системе MemFree=LowFree+HighFree. Buffers - область ОЗУ, занятая хранением данных, ожидающих записи на диск. Буфер позволяет приложениям продолжать выполнение своей задачи не дожидаясь момента когда данные будут физически записаны на диск. Обычно размер около 20Мб.
Cached - Объем занятый в ОЗУ под кэш чтения страниц с диска (файлы, директории, файлы блочных устройств, данные, относящиеся к механизму IPC, данные процессов уровня пользователя, сброшенных в область подкачки). Не включает в себя SwapCached.

SwapCached - Объем памяти, который однажды был помещен в область подкачки, но потом перенесен обратно в ОЗУ. Однако данные все еще присутствуют в swap, и при необходимости этот объем памяти может быть вновь освобожден без необходимости тратить ресурсы на "дорогие" операции ввода/вывода.

Active - Объем памяти, занятый в ОЗУ наиболее часто используемыми страницами памяти. Иными словами, эти страницы памяти активно используются процессами и будут освобождаться только в случае крайней необходимости.

Inactive - Объем памяти, занятый в ОЗУ не используемыми в настоящий момент страницами. Эти страницы считаются наиболее подходящими для выгрузки в swap и освобождения в случае необходимости.

High{Total,Free}, Low{Total,Free} - MemTotal=HighTotal+LowTotal. Вывод команды cat /proc/meminfo получен на 32-разрядной операционной системе. Модель использования памяти в 32-разрядном и 64-разрядном ядрах отличается. Ниже я привел рисунок, показывающий эти отличия:


В 32-р архитектуре ядро Linux может напрямую адресовать только первый гигабайт физической памяти. На рисунке ZONE_NORMAL - это и есть область памяти объемом LowTotal:897056 kB. Число меньше гигабайта за счет зарезервированных ядром областей памяти. Из оставшегося объема нужно вычесть 1Мб, используемый BIOS и устройствами ввода/вывода, а также 16Mб ZONE_DMA для совместимости с ограничениями устройств на шине ISA. Память "выше" первого гигабайта - ZONE_HIGHMEM (HighTotal:1048256 kB). Доступ к ней осуществляется через отображение на первый гигабайт ОЗУ. Отображение "прозрачно" для приложений, но вызывает небольшую потерю производительности. ZONE_NORMAL используется для тех же нужд что и зона ZONE_HIGHMEM, плюс для собственных структур ядра. В 64-разрядных архитектурах зона ZONE_HIGHMEM всегда пуста.
Swap{Total, Free} - SwapTotal - это общий объем области подкачки (как в разделе подкачки, так и в swap-файлах, если они используются). Как и в случае с ОЗУ, ядро Linux старается использовать область подкачки максимально эффективно. Иногда факт использования части области подкачки еще не означает того, что память является "узким местом" производительности системы. Один из способов влиять на агрессивность использования swap - это парметр vm.swappiness. Чем больше процент swappiness, тем активнее будет выгрузка в swap. По умолчанию в RHEL5 это число 60%. Предпочтительно использовать более агрессивную политику выгрузки в область подкачки, когда вы, например, на рабочей станции большую часть времени работаете с одним большим пакетом ПО и редко переключаетесь на другие задачи. Пример из области серверов - машина с ограниченным ОЗУ, выполняющая какие-то пакетные задания (процессы, находящиеся долгое время в состоянии S). На серверах с большим объемом ОЗУ увеличения swappiness может свести все выгоды использования swap "на нет" из-за активного использования дисковой подсистемы и процессорного времени для поиска и сброса на диск неактивных страниц памяти.

Dirty - Измененные ("грязные") страницы, находящиеся в ОЗУ, но еще не сброшенные на диск. За процедуру записи на диск отвечает группа потоков ядра pdflush. В системе должно работать минимум два и максимум восемь потоков pdflush. Посмотреть текущее число потоков можно:
[root@server1 ~]# cat /proc/sys/vm/nr_pdflush_threads 
2
Дополнительные потоки создаются в зависимости от текущей нагрузки ввода/вывода. Команда sync и "магическая" комбинация Alt-SysRq-S сбрасывает все "грязные" страницы и буферы. Число, хранящееся в vm.dirty_background_ratio (по умолчанию 10%), задает какой процент от ОЗУ потоки pdflush должны сбрасывать на диск. Чем больше процент, тем реже происходит обращение к диску. Второй из важных параметров, влияющих на pdflush, это процент от объема ОЗУ, при котором стартует сам процесс сброса на диск - vm.dirty_ratio. Writeback - Страницы памяти, которые в настоящий момент сбрасываются на диск. AnonPages - Анонимные страницы - это, как правило, данные, используемые программами и не ассоциированные с каким-либо файлом. Наряду со страницами, объем которых указан в Inactive, это первые кандидаты на попадание в область подкачки. Анонимные страницы нередко используются несколькими процессами. Самый распространенный пример - fork() при создании нового процесса. Число анонимных страниц для конкретного процесса можно вычислить как разницу между размером резидентной части (resident) и разделяемыми страницами (share) в выводе /proc/PID/statm (информация о состоянии памяти в страницах). Например:
[root@server1 vm]# cat /proc/$(pidof sshd)/statm
1763 258 161 93 0 130 0
Получается что число анонимных страниц для sshd = 258 - 161 = 97 или 388Кб. Подробнее - man proc. Mapped - Общий объем памяти, привнесенный в виртуальное адресное пространство процессов при помощи mmap (например, библиотеки). Slab - объем памяти, занятый под различные структуры ядра небольшого объема, для которых не оптимально выделять по целой странице памяти. По умолчанию в 32-р системах размер страницы - 4Кб, и этот объем является квантом памяти при ее выделении. Подробнее информацию о slab-кэше можно посмотреть при помощи утилиты vmstat с ключем -m, утилиты slabtop или через /proc/slabinfo. PageTables - Объем памяти, зарезервированный под Таблицу Страниц. NFS_Unstable - Данный параметр относится к клиенту NFS v3+, реализованному в ядре Linux, и показывает, какой объем данных, отправленных клиентом серверу, еще не был записан на диск. Клиент должен кэшировать эти данные до поступления подтверждения от сервера.
CommitLimit - Объем памяти, который может быть выделен системой. Вычисляется на основе vm.overcommit_ratio (по умолчанию - 50%) и размера области подкачки. Формула имеет следующий вид CommitLimit = ( vm.overcommit_ratio * объем_ОЗУ) + область_подкачки. Этот лимит соблюдается только при "строгой" политике выделения памяти (vm.overcommit_memory=2). По умолчанию используется "эвристическая" политика (vm.overcommit_memory=0).

Committed_AS - Сколько памяти выделено всем процессам, даже если они эту память не используют в полном объеме. Иными словами, данный параметр показывает, сколько при текущей загрузке системы требуется ОЗУ, если процессы реально захотят использовать выделенную память для того, чтобы избежать core dump по причине отсутствия памяти (OOM). Дело в том что, когда процесс требует - ядро подтверждает выделение требуемого объема памяти (только если не используется "строгая" политика. В этом случае проверяем, не исчерпан ли CommitLimit) без выделения ОЗУ. Реально память выделяется постранично только лишь когда процесс пытается что-то записать в выделенную до этого память. Этот механизм называется overcommitment. Более подробно см. /usr/share/doc/kernel-doc-*/Documentation/vm/overcommit-accounting.

VmallocTotal - общее число виртуального пространства, доступного для vmalloc.

VmallocUsed - объем использованного пространства vmalloc.

VmallocChunk - наибольший свободный непрерывный блок внутри пространства vmalloc.

Резервирование и восстановление с помощью программы RMAN


Резервирование и восстановление с помощью программы RMAN

Владимир Пржиялковский,
координатор Евро-Азиатской Группы Пользователей Oracle,
преподаватель УКЦ Interface Ltd.

Введение

Программа RMAN появилась в версии 8 СУБД Oracle как единое для всех платформ средство организации резервного копирования и восстановления данных на физическом уровне. По отношению к традиционным базовым возможностям резервирования и восстановления в Oracle, у программы RMAN есть некоторые преимущества, делающие ее в некоторых ситуациях (например, при больших объемах данных) практически незаменимой. К сожалению, наличие этих преимуществ не лишает RMAN и ряда существенных недостатков: собственной системы понятий, собственного командного языка и интерфейса общения с администратором. И то, и другое, и третье выполнено в плохих традициях разработчиков Oracle – не вполне логично, запутано и непоследовательно, – что затрудняет освоение этой программы. Назначение этой статьи – помочь перешагнуть через эти недостатки ради выгод, которые можно извлечь из RMAN.

Возможности RMAN

Возможности RMAN включают следующее:
-выполнение полного резервирования и резервирования изменений
-выполнение холодного/горячего резервирования, причем во втором случае табличные пространства не переводятся в режим backup, что позволяет избежать дополнительной нагрузки на журнал
-обнаружение поврежденных блоков
-параллельное выполнения операций ввода/вывода
-автоматическое протоколирование операций копирования и восстановления
Уровни выполнения резервного копирования/восстановления с помощью RMAN:
  • база данных
  • табличные пространства
  • файлы табличных пространств
  • служебные файлы БД (контрольные, архивные)
Основные понятия
В число основных понятий RMAN входят следующие:
-Канал (channel). Серверный процесс, возникающий при установлении связи с устройством ввода/вывода (диск или магнитная лента) для записи или чтения файлов резервирования
-Целевая БД (target database). БД, для которой снимается резервная копия, или которая восстанавливается по ранее снятой копии
-Каталог (recovery catalog). Отдельная схема в БД (чаще в отдельной БД), которую можно заводить для хранения служебная информации о целевых базах, снятых копиях и процедурах восстановления. Альтернативой каталогу является индивидуальная работа с каждой целевой БД, когда служебная информация помещается в контрольный файл этой БД.
-Копия (RMAN backup). Резервная копия какого-нибудь элемента БД, получаемая командой RMAN backup.
-Резервный набор (backup set). Логически именует набор файлов, сформированных во время резервного копирования.
-Резервный файл (backup piece). Двоичный файл с резервной информацией.
Синтаксис командного языка RMAN в версии 9 имеет определенные отличия от версии 8, но все основные конструкции сохранены. Кроме этого, в RMAN для версии 9 допускается целый ряд упрощений записи команд.
Возможность работы с RMAN включена также в последние версии OEM без необходимости знания командного языка.
В тексте ниже для лаконичности предпочтение будет отдаваться синтаксису версии 9. Кроме этого для простоты рассматривается работа без каталога RMAN.

Пример копирования и восстановления базы данных

Простейший пример снятия резервной копии (холодное копирование – вся БД – работа без каталога) иллюстрируется следующей последовательностью команд (здесь команда CONNECT TARGET соединяет RMAN с СУБД версии 8):
RMAN NOCATALOG
RMAN> CONNECT TARGET internal/oracle
RMAN> SHUTDOWN IMMEDIATE
RMAN> STARTUP MOUNT
RMAN> RUN {
2> ALLOCATE CHANNEL d1 TYPE DISK;
3> BACKUP FULL FORMAT 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%U.bus'
4> DATABASE;
4> }
RMAN>
В каталоге D:\ORACLE\ORADATA\TEACHER\RMAN-BACKUP появился файл RMAN_ TEACHER _02DGA6F0_1_1.BUS (реальное имя может варьироваться). Теперь можно удалить файлы с табличными пространствами и выполнить восстановление:
RMAN> RUN {
2> ALLOCATE CHANNEL d1 TYPE DISK;
3> RESTORE DATABASE;
4> RECOVER DATABASE;
5> ALTER DATABASE OPEN;
6> }
База восстановлена и открыта.

Упрощения в версии 9

В версии RMAN для версии 9 описанное выше резервирование можно было бы выполнить так:
RMAN> BACKUP DATABASE FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%U.bus';
а восстановление так:
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN;
Здесь подразумевается использование неявного канала по умолчанию, так что объявлять его стало необязательно.
Кроме этого в версии 9 появилась команда CONFIGURE, с помощью которой (помимо прочего) можно связать с каналом направление и маску имени файлов для резервного набора:
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%U.bus';
В этом случае команда снятия резервной копии может выглядеть еще проще:
RMAN> BACKUP DATABASE;

Резервирование файлов базы данных

Горячее полное резервирование БД

Горячее резервирование
-может выполняться в состоянии СУБД OPEN
-может выполняться только при включенном режиме архивирования журналов
Если выполнено и то, и другое, сами действия по резервированию выглядят как обычно. Пример в синтаксисе версии 9.0:
RMAN> BACKUP DATABASE FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%t_%U.bus';

Полное резервирование табличного пространства

Пример в синтаксисе версии 9.0:
RMAN> BACKUP TABLESPACE system, users FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%t_%U.bus';

Полное резервирование отдельных файлов табличного пространства

Пример в синтаксисе версии 9.0:
RMAN> BACKUP DATAFILE 1, 2;
или
RMAN> BACKUP FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%t_%U.bus'
3> 'd:\oracle\oradata\teacher\system01.dbf’,
4> 'd:\oracle\oradata\teacher\users01.dbf’;

Резервирование временного табличного пространства

Если временное табличное пространство локально управляемо, оно автоматически не резервируется. Восстанавливать (воссоздавать) при необходимости его придется самостоятельно.

Резервирование контрольного файла

Обычное резервирование контрольного файла приходится выполнять отдельно. Пример явного резервирования в синтаксисе версии 9.0:
RMAN> BACKUP CURRENT CONTROLFILE;
В версии 9 можно, однако, перевести RMAN в режим, когда копии контрольного файла будут сниматься автоматически при всякой выдаче команд BACKUP или COPY:
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

Резервирование оперативных файлов журнала

Оперативные (онлайновые) файлы журнала автоматически не резервируются. Для сохранения либо следует их
а) копировать отдельно, либо
б) перед полным резервированием БД отправлять в архив.

Резервирование архивных копий журнала

Файлы архивных копий журнала резервируются всегда в отдельные от прочих файлы резервного набора и в общем случае их нужно резервировать отдельной командой. Пример в синтаксисе версии 9.0:
RMAN> BACKUP ARCHIVELOG ALL;
Пример того, как в версии 9.0 архивные файлы можно включить в состав резервного набора БД:
RMAN> BACKUP DATABASE FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%U.bus' PLUS ARCHIVELOG;

Резервирование изменений (неполное резервирование)

Для резервирования изменений в Oracle используется традиционная многоуровневая модель с конкретным числом уровней копии 5 (от 0 до 4). Точкой отсчета для копирования изменений обязана стать снятая ранее полная копия БД уровня 0.
Пример резервирования блоков, изменившихся со времени резервирования на уровнях 3, 2, 1 и 0 (разностное, «дифференциального» резервирование) в синтаксисе версии 9:
RMAN> BACKUP INCREMENTAL LEVEL 3 DATABASE;
Пример резервирования блоков, изменившихся со времени последнего резервирования на уровнях 2, 1 и 0 (разностно-накопительное, «кумулятивное» резервирование) с пропуском табличных пространств, закрытых для записи (синтаксис версии 9):
RMAN> BACKUP INCREMENTAL LEVEL 3 CUMULATIVE DATABASE
2> SKIP READONLY;
Разностно-накопительное (кумулятивное) резервирование уровня N отличается от разностного (дифференциального) тем, что резервирует изменения произошедшие после выполнения резервирования всех уровней < N, в то время как просто разностное – изменения, произошедшие после резервирования уровней <= N.

Выдача справочной информации

Выполняется специальными командами LIST и REPORT, а также разновидностью команды RESTORE. Примеры приводятся ниже.
Выдача подробного списка всех снятых копий:
RMAN> LIST BACKUP;
Выдача списка резервных наборов, содержащих табличное пространство SYSTEM:
RMAN> LIST BACKUP OF TABLESPACE system;
Вариант выдачи того же самого, но в обобщенном виде (версия 9):
RMAN> LIST BACKUP OF TABLESPACE system SUMMARY;
Выдача информации о копиях, снятых с архивов журналов:
RMAN> LIST BACKUP OF ARCHIVELOG ALL;
Выдача резервных копий, оказавшихся устаревшими:
RMAN> REPORT OBSOLETE;
Выдача файлов с данными БД, для восстановления которых потребуются архивы журналов 2-х дневной давности и более:
RMAN> REPORT NEED BACKUP DAYS 2 DATABASE;
Те же сведения, но только для пространства SYSTEM:
RMAN> REPORT NEED BACKUP DAYS 2 TABLESPACE system;
Выдача информации о том, годны ли файлы резервного набора для восстановления:
RMAN> RUN {ALLOCATE CHANNEL d1 TYPE DISK;
2> RESTORE DATABASE VALIDATE; }

Удаление резервных копий

Выполняется командой DELETE. В простейшем варианте удаление устаревших копий может выглядеть так:
RMAN> DELETE OBSOLETE;
Обратите внимание, что RMAN удалил ненужные файлы резервных наборов. Вам не нужно автоматизировать удаление старых файлов, как раньше!
Файлы резервных наборов могут оказаться испорченными или поврежденными. Это можно отметить в справочнике (в контрольном файле или в каталоге RMAN) с помощью команды CROSSCHECK, в результате чего они будут помечены там как EXPIRED. Последующая команда DELETE EXPIRED удалит ставшие ненужными из-за этого файлы:
RMAN> CROSSCHECK BACKUP;

RMAN> DELETE EXPIRED BACKUP OF DATABASE;

RMAN> DELETE BACKUP OF DATABASE;
Более сложный пример удаления устаревших резервных копий:
RMAN> DELETE OBSOLETE RECOVERY WINDOW OF 14 DAYS;

Восстановление данных

-Для восстановления данных целевая БД должна находиться в состоянии NOMOUNT/ MOUNT/ OPEN в зависимости от характера восстановления, например
-
NOMOUNT: для восстановления контрольных файлов БД (фактически – СУБД)
-
MOUNT: для восстановления БД целиком или табличного пространства SYSTEM
-
OPEN: для восстановление табличных пространств, помимо SYSTEM (в этом случае перед процедурой восстановления само табличное пространство потребуется перевести в состояние OFFLINE).
-Восстановление файлов (с данными и служебных) выполняется в RMAN командой RESTORE.
-Восстановление данных выполняется либо в RMAN, либо в SQL*Plus командами RECOVER при условии наличия восстановленных файлов.

Восстановление до момента сбоя («последнего момента»)

Некоторые примеры восстановления:
RMAN> RECOVER DATABASE;
RMAN> RECOVER TABLESPACE users;
RMAN> RECOVER DATAFILE 'd:\oracle\oradata\teacher\users01.dbf’;
RMAN> RESTORE CONTROLFILE;
RMAN> RUN {
2> SET ARCHIVELOG DESTINATION TO ‘d:\oracle\oradata\archive’;
3> RESTORE ARCHIVELOG ALL; }
Восстановление пространств, закрытых на запись:
RMAN> SQL "ALTER TABLESPACE lookup_data OFFLINE";
RMAN> RECOVER TABLESPACE lookup_data;
RMAN> SQL "ALTER TABLESPACE lookup_data ONLINE";

Восстановление до указанного момента в прошлом

БД, работающую в режиме архивирования журнала, можно восстанавливать до определенного указанного момента с помощью фраз UNTIL {TIME … | SCN … | SEQUENCE … THREAD…}. Пример:
RMAN> RESTORE DATABASE; # восстановили файлы
RMAN> RECOVER DATABASE UNTIL SCN 375831; # восстановили БД
RMAN> ALTER DATABASE OPEN RESETLOGS; # сбросили журнал
Восстановление БД (вторая и третья строчки выше) можно выполнить и в SQL*Plus:
SQL > RECOVER DATABASE UNTIL CANCEL;
SQL> ALTER DATABASE OPEN RESETLOGS;
При таком восстановлении необходимо сбросить онлайновый журнал. После этого, как и при традиционном восстановлении со сбросом журналов (RESETLOGS), необходимо снять полную копию БД, так как с этого момента восстановление с более ранних резервных копий станет невозможным из-за того, что история журнальных записей прерывается.

Автоматизация задач

Автоматизировать выполнение задач с RMAN можно как внешними средствами (язык командной оболочки), так и внутренними. Внутренние средства RMAN допускают указание файла сценария при вызове этой программы, а также организацию хранимого сценария.
Пусть в файле listbackup.rcm находятся строки:
CONNECT TARGET /
LIST BACKUP;
EXIT
Тогда следующие два эквивалентные по результату обращения в ОС приведут ко входу в RMAN, выполнению этого сценария и выходу:
RMAN CMDFILE=listback.rcm NOCATALOG
RMAN @listback.rcm NOCATALOG
При использовании каталога RMAN возможно к тому же использование хранимого сценария:
RMAN> REPLACE SCRIPT reportobsolete { REPORT OBSOLETE; }
Пример обращения в хранимому в каталоге сценарию:
RMAN> RUN { EXECUTE SCRIPT reportobsolete; }

Linux и LVM (Logical Volume Manager)

Linux и LVM (Logical Volume Manager)

http://xgu.ru/wiki/LVM

Автор: Иван Песин
Автор: Игорь Чубин (автор дополнений)
В основу этой страницы положена работа «Повесть о Linux и LVM» Ивана Песина, которая, в свою очередь, написана на основе Linux LVM HOWTO. Она дополнена новыми ссылками и небольшими уточнениями, а также углублённым рассмотрением нескольких дополнительных вопросов.
Один из вопросов это использование kpartx из пакета multipath-tools для построения карты устройства (device map) и рекурсивного доступа к томам LVM (когда LVM развёрнут на разделах, созданных внутри логического тома LVM более низкого уровня). Это может быть полезно при использовании LVM совместно с системами виртуализации.
Второй вопрос — это использование постоянных снимков (persistent snapshot) для быстрого клонирования разделов. Эта возможность может быть полезна как при выполнении резервного копирования, так и при быстром создании виртуальных машин в системах виртуализации (вопрос создания снимков затрагивался и в повести, но здесь он рассмотрен более детально).
Третий вопрос — это сравнение LVM и файловой системой ZFS, набирающей в последнее время большую популярность. На первый взгляд такое сравнение может показаться странным, ведь ZFS -- это файловая система, а LVM -- система управления томами, то есть нечто, что находится на уровень ниже файловой системы. В действительности, сравнение вполне имеет право на существование, поскольку ZFS это не просто файловая система, а нечто большее. В ней присутствует уровень "storage pool", который берёт на себя те же задачи, что и LVM.

Введение

Цель статьи -- описать процесс установки и использования менеджера логических томов на Linux-системе. LVM (Logical Volume Manager), менеджер логических томов -- это система управления дисковым пространством, абстрагирующаяся от физических устройств. Она позволяет эффективно использовать и легко управлять дисковым пространством. LVM обладает хорошей масштабируемостью, уменьшает общую сложность системы. У логических томов, созданных с помощью LVM, можно легко изменить размер, а их названия могут нести большую смысловую нагрузку, в отличие от традиционных /dev/sda, /dev/hda ...
Реализации менеджеров логических томов существуют практически во всех UNIX-подобных операционных системах. Зачастую они сильно отличаются в реализации, но все они основаны на одинаковой идее и преследуют аналогичные цели. Одна из основных реализаций была выполнена Open Software Foundation (OSF) и сейчас входит в состав многих систем, например IBM AIX, DEC Tru64, HP/UX. Она же послужила и основой для Linux-реализации LVM.
Данная статья является переработкой и дополнением LVM-HOWTO.

Терминология

Поскольку система управления логическими томами использует собственную модель представления дискового пространства, нам необходимо определиться с терминами и взаимосвязями понятий. Рассмотрим схему, основанную на диаграмме Эрика Бегфорса (Erik Bеgfors), приведенную им в списке рассылки linux-lvm. Она демонстрирует взаимосвязь понятий системы LVM:
sda1     sda2     sdb     sdc       <-- PV
 |        |        |       |
 |        |        |       |
 +--------+- VG00 -+-------+        <-- VG
              |
 +-------+-------+---------+
 |       |       |         |
root    usr     home      var       <-- LV
 |       |       |         | 
ext3 reiserfs reiserfs    xfs       <-- Файловые системы
Обозначения и понятия:
  • PV, Physical volume, физический том. Обычно это раздел на диске или весь диск. В том числе, устройства программного и аппаратного RAID (которые уже могут включать в себя несколько физических дисков). Физические тома входят в состав группы томов.
  • VG, Volume group, группа томов. Это самый верхний уровень абстрактной модели, используемой системой LVM. С одной стороны группа томов состоит из физических томов, с другой -- из логических и представляет собой единую административную единицу.
  • LV, Logical volume, логический том. Раздел группы томов, эквивалентен разделу диска в не-LVM системе. Представляет собой блочное устройство и, как следствие, может содержать файловую систему.
  • PE, Physical extent, физический экстент. Каждый физический том делится на порции данных, называющиеся физическими экстентами. Их размеры те же, что и у логических экстентов.
  • LE, Logical extent, логический экстент. Каждый логический том делится на порции данных, называющиеся логическими экстентами. Размер логических экстентов не меняется в пределах группы томов.
Давайте теперь соединим все эти понятия в общую картину. Пусть у нас имеется группа томов VG00 с размером физического экстента 4Мб. В эту группу мы добавляем два раздела, /dev/hda1 и /dev/hdb1. Эти разделы становятся физическими томами, например PV1 и PV2 (символьные имена присваивает администратор, так что они могут быть более осмысленными). Физические тома делятся на 4-х мегабайтные порции данных, т.к. это размер физического экстента. Диски имеют разный размер: PV1 получается размером в 99 экстентов, а PV2 -- размером в 248 экстентов. Теперь можно приступать к созданию логических томов, размером от 1 до 347 (248+99) экстентов. При создании логического тома, определяется отображение между логическими и физическими экстентами. Например, логический экстент 1 может отображаться в физический экстент 51 тома PV1. В этом случае, данные, записанные в первые 4Мб логического экстента 1, будут в действительности записаны в 51-й экстент тома PV1.
Администратор может выбрать алгоритм отображения логических экстентов в физические. На данный момент доступны два алгоритма:
1. Линейное отображение последовательно назначает набор физических экстентов области логического тома, т.е. LE 1 - 99 отображаются на PV1, а LE 100 - 347 -- на PV2.
2. "Расслоенное" (striped) отображение разделяет порции данных логических экстентов на определенное количество физических томов. То есть:
     1-я порция данных LE[1] -> PV1[1],
     2-я порция данных LE[1] -> PV2[1],
     3-я порция данных LE[1] -> PV3[1],
     4-я порция данных LE[1] -> PV1[2], и т.д.
Похожая схема используется в работе RAID нулевого уровня. В некоторых ситуациях этот алгоритм отображения позволяет увеличить производительность логического тома. Однако он имеет значительное ограничение: логический том с данным отображением не может быть расширен за пределы физических томов, на которых он изначально и создавался.
Великолепная возможность, предоставляемая системой LVM -- это "снапшоты". Они позволяют администратору создавать новые блочные устройства с точной копией логического тома, "замороженного" в какой-то момент времени. Обычно это используется в пакетных режимах. Например, при создании резервной копии системы. Однако при этом вам не будет нужно останавливать работающие задачи, меняющие данные на файловой системе. Когда необходимые процедуры будут выполнены, системный администратор может просто удалить устройство-"снапшот". Ниже мы рассмотрим работу с таким устройством.

Работа с LVM

Давайте теперь рассмотрим задачи, стоящие перед администратором LVM системы. Помните, что для работы с системой LVM ее нужно инициализировать командами:
%# vgscan
%# vgchange -ay
Первая команда сканирует диски на предмет наличия групп томов, вторая активирует все найденные группы томов. Аналогично для завершения всех работ, связанных с LVM, нужно выполнить деактивацию групп:
%# vgchange -an
Первые две строки нужно будет поместить в скрипты автозагрузки (если их там нет), а последнюю можно дописать в скрипт shutdown.

Инициализация дисков и разделов

Перед использованием диска или раздела в качестве физического тома необходимо его инициализировать:
Для целого диска:
%# pvcreate /dev/hdb
Эта команда создает в начале диска дескриптор группы томов.
Если вы получили ошибку инициализации диска с таблицей разделов -- проверьте, что работаете именно с нужным диском, и когда полностью будете уверены в том, что делаете, выполните следующие команды
%# dd if=/dev/zero of=/dev/diskname bs=1k count=1
%# blockdev --rereadpt /dev/diskname
Эти команды уничтожат таблицу разделов на целевом диске.
Для разделов:
Установите программой fdisk тип раздела в 0x8e.
%# pvcreate /dev/hdb1
Команда создаст в начале раздела /dev/hdb1 дескриптор группы томов.

Создание группы томов

Для создания группы томов используется команда 'vgcreate'
%# vgcreate vg00  /dev/hda1 /dev/hdb1 
Если вы используете devfs важно указывать полное имя в devfs, а не ссылку в каталоге /dev. Таким образом приведенная команда должна выглядеть в системе с devfs так:
# vgcreate vg00  /dev/ide/host0/bus0/target0/lun0/part1 /dev/ide/host0/bus0/target1/lun0/part1
Кроме того, вы можете задать размер экстента при помощи ключа "-s", если значение по умолчанию в 4Мб вас не устраивает. Можно, также, указать ограничения возможного количества физических и логических томов.








Активация группы томов

После перезагрузки системы или выполнения команды vgchange -an, ваши группы томов и логические тома находятся в неактивном состоянии. Для их активации необходимо выполнить команду
%# vgchange -a y vg00

Удаление группы томов

Убедитесь, что группа томов не содержит логических томов. Как это сделать, показано в следующих разделах.
Деактивируйте группу томов:
%# vgchange -a n vg00

Теперь можно удалить группу томов командой:
%# vgremove vg00

Добавление физических томов в группу томов

Для добавления предварительно инициализированного физического тома в существующую группу томов используется команда 'vgextend':
%# vgextend vg00 /dev/hdc1
                ^^^^^^^^^ новый физический том

Удаление физических томов из группы томов

Убедитесь, что физический том не используется никакими логическими томами. Для этого используйте команду 'pvdisplay':
%# pvdisplay /dev/hda1

--- Physical volume ---
   PV Name            /dev/hda1
   VG Name            vg00
   PV Size            1.95 GB / NOT usable 4 MB [LVM: 122 KB]
   PV#                1
   PV Status          available
   Allocatable        yes (but full)
   Cur LV             1
   PE Size (KByte)    4096
   Total PE           499
   Free PE            0
   Allocated PE       499
   PV UUID            Sd44tK-9IRw-SrMC-MOkn-76iP-iftz-OVSen7
Если же физический том используется, вам нужно будет перенести данные на другой физический том. Эта процедура будет описана в следующих разделах.
После этого можно использовать 'vgreduce' для удаления физических томов:
%# vgreduce vg00 /dev/hda1

Создание логического тома

Для того, чтобы создать логический том "lv00", размером 1500Мб, выполните команду:
 %# lvcreate -L1500 -n lv00 vg00
Без указания суффикса размеру раздела используется множитель «мегабайт» (в системе СИ равный 10⁶ байт), что и продемонстрировано в примере выше. Суффиксы в верхнем регистре (KMGTPE) соответствуют единицам в системе СИ (с основанием 10), например, G — гигабайт равен 10⁹ байт, а суффиксы в нижнем регистре (kmgtpe) соответствуют единицам в системе IEC (с основанием 2), например g — гибибайт равен 2³⁰ байт.
Для создания логического тома размером в 100 логических экстентов с расслоением по двум физическим томам и размером блока данных 4 KB:
 %# lvcreate -i2 -I4 -l100 -n lv01 vg00
Если вы хотите создать логический том, полностью занимающий группу томов, выполните команду vgdisplay, чтобы узнать полный размер группы томов, после чего используйте команду lvcreate.
 %# vgdisplay vg00 | grep "Total PE"
 Total PE        10230
 %# lvcreate -l 10230 vg00 -n lv02
Эти команды создают логический том lv02, полностью заполняющий группу томов. Тоже самое можно реализовать командой
 %# lvcreate -l100%FREE vg00 -n lv02

Удаление логических томов

Логический том должен быть размонтирован перед удалением:
%# umount /dev/vg00/home
%# lvremove /dev/vg00/home
lvremove -- do you really want to remove "/dev/vg00/home"? [y/n]:    y
lvremove -- doing automatic backup of volume group "vg00"
lvremove -- logical volume "/dev/vg00/home" successfully removed

Увеличение логических томов

Для увеличения логического тома вам нужно просто указать команде lvextend до какого размера вы хотите увеличить том:
%# lvextend -L12G /dev/vg00/home
lvextend -- extending logical volume "/dev/vg00/home" to 12 GB
lvextend -- doing automatic backup of volume group "vg00"
lvextend -- logical volume "/dev/vg00/home" successfully extended
В результате /dev/vg00/home увеличится до 13Гбайт.
%# lvextend -L+1G /dev/vg00/home
lvextend -- extending logical volume "/dev/vg00/home" to 13 GB
lvextend -- doing automatic backup of volume group "vg00"
lvextend -- logical volume "/dev/vg00/home" successfully extended
Эта команда увеличивает размер логического тома на 1Гб.
После того как вы увеличили логический том, необходимо соответственно увеличить размер файловой системы. Как это сделать зависит от типа используемой файловой системы.
По умолчанию большинство утилит изменения размера файловой системы увеличивают ее размер до размера соответствующего логического тома. Так что вам не нужно беспокоится об указании одинаковых размеров для всех команд.

ext2

Если вы не пропатчили ваше ядро патчем ext2online, вам будет необходимо размонтировать файловую систему перед изменением размера:
    %# umount /dev/vg00/home
    %# resize2fs /dev/vg00/home
    %# mount /dev/vg00/home /home
Если у вас нет пакета e2fsprogs 1.19 его можно загрузить с сайта ext2resize.sourceforge.net.
Для файловой системы ext2 есть и другой путь. В состав LVM входит утилита e2fsadm, которая выполняет и lvextend, и resize2fs (она также выполняет и уменьшение размера файловой системы, это описано в следующем разделе). Так что можно использовать одну команду:
    %# e2fsadm -L+1G /dev/vg00/home
что эквивалентно двум следующим:
    %# lvextend -L+1G /dev/vg00/home
    %# resize2fs /dev/vg00/home

xfs

Размер файловой системы XFS можно увеличить только в смонтированном состоянии. Кроме того, утилите в качестве параметра нужно передать точку монтирования, а не имя устройства:
    %# xfs_growfs /home

Уменьшение размера логического тома

Логические тома могут быть уменьшены в размере, точно также как и увеличены. Однако очень важно помнить, что нужно в первую очередь уменьшить размер файловой системы, и только после этого уменьшать размер логического тома. Если вы нарушите последовательность, вы можете потерять данные.

[править]ext2

При использовании файловой системы ext2, как уже указывалось ранее, можно использовать команду e2fsadm:
   # umount /home
   # e2fsadm -L-1G /dev/vg00/home
   # mount /home
Если вы хотите выполнить операцию по уменьшению логического тома вручную, вам нужно знать размер тома в блоках:
   # umount /home
   # resize2fs /dev/vg00/home 524288
   # lvreduce -L-1G /dev/vg00/home
   # mount /home

xfs

Уменьшить размер файловой системы XFS нельзя.
Примечание: обратите внимание на то, что для уменьшения размера файловых систем, необходимо их размонтировать. Это вносит определенные трудности, если вы желаете уменьшить размер корневой файловой системы. В этом случае можно применить следующий метод: загрузится с CD дистрибутива, поддерживающего LVM. Перейти в командный режим (обычно это делается нажатием клавиш Alt+F2) и выполнить команды сканирования и активации группы томов:
%# vgscan
%# vgchange -a y
Теперь вы имеете доступ к логическим томам и можете изменять их размеры:
%# resize_reiserfs -s-500M /dev/vg00/root
%# lvreduce -L-500M /dev/vg00/root
%# reboot

Перенос данных с физического тома

Для того, чтобы можно было удалить физический том из группы томов, необходимо освободить все занятые на нем физические экстенты. Это делается путем перераспределения занятых физических экстентов на другие физические тома. Следовательно, в группе томов должно быть достаточно свободных физических экстентов. Описание операции удаления физического тома приведено в разделе примеров.

Примеры

Настройка LVM на трех SCSI дисках

В первом примере мы настроим логический том из трех SCSI дисков. Устройства дисков: /dev/sda, /dev/sdb и /dev/sdc.
Перед добавлением в группу томов диски нужно инициализировать:
%# pvcreate /dev/sda
%# pvcreate /dev/sdb
%# pvcreate /dev/sdc
После выполнения этих команд в начале каждого диска создастся область дескрипторов группы томов.
Теперь создадим группу томов vg01, состоящую из этих дисков:
%# vgcreate vg01 /dev/sda /dev/sdb /dev/sdc
Проверим статус группы томов командой vgdisplay:
%# vgdisplay
--- Volume Group ---
VG Name            vg01
VG Access          read/write
VG Status          available/resizable
VG #               1
MAX LV             256
Cur LV             0
Open LV            0
MAX LV Size        255.99 GB
Max PV             256
Cur PV             3
Act PV             3
VG Size            1.45 GB
PE Size            4 MB
Total PE           372
Alloc PE / Size    0 / 0
Free PE / Size     372/ 1.45 GB
VG UUID            nP2PY5-5TOS-hLx0-FDu0-2a6N-f37x-0BME0Y
Обратите внимание на первые три строки и строку с общим размером группы томов. Она должна соответствовать сумме всех трех дисков. Если всё в порядке, можно переходить к следующей задаче.

Создание логического тома

После успешного создания группы томов, можно начать создавать логические тома в этой группе. Размер тома может быть любым, но, естественно, не более всего размера группы томов. В этом примере мы создадим один логический том размером 1 Гб. Мы не будем использовать "расслоение", поскольку при этом невозможно добавить диск в группу томов после создания логического тома, использующего данный алгоритм.
%# lvcreate -L1G -nusrlv vg01
lvcreate -- doing automatic backup of "vg01"
lvcreate -- logical volume "/dev/vg01/usrlv" successfully created

Создание файловой системы

Создадим на логическом томе файловую систему ext2:
%# mke2fs /dev/vg01/usrlv
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
131072 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
9 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376

Writing inode tables: done
Writing superblocks and filesystem accounting information: done



Тестирование файловой системы

Смонтируйте логический том и проверьте все ли в порядке:
%# mount /dev/vg01/usrlv /mnt
%# df
Filesystem       1k-blocks   Used Available Use% Mounted on
/dev/hda1          1311552 628824    616104  51% /
/dev/vg01/usrlv    1040132     20    987276   0% /mnt
Если вы все сделали правильно, у вас должен появиться логический том с файловой системой ext2, смонтированный в точке /mnt.

Создание логического тома с "расслоением"

Рассмотрим теперь вариант логического тома, использующего алгоритм "расслоения". Как уже указывалось выше, минусом этого решения является невозможность добавления дополнительного диска.
Процедура создания данного типа логического тома также требует инициализации устройств и добавления их в группу томов, как это уже было показано.
Для создания логического тома с "расслоением" на три физических тома с блоком данных 4Кб выполните команду:
%# lvcreate -i3 -I4 -L1G -nvarlv vg01
lvcreate -- rounding 1048576 KB to stripe boundary size 1056768 KB / 258 PE
lvcreate -- doing automatic backup of "vg01"
lvcreate -- logical volume "/dev/vg01/varlv"    successfully created
После чего можно создавать файловую систему на логическом томе.

Добавление нового диска

Рассмотрим систему со следующей конфигурацией:
%# pvscan
pvscan -- ACTIVE   PV "/dev/sda"  of VG "dev"   [1.95 GB / 0 free]
pvscan -- ACTIVE   PV "/dev/sdb"  of VG "sales" [1.95 GB / 0 free]
pvscan -- ACTIVE   PV "/dev/sdc"  of VG "ops"   [1.95 GB / 44 MB free]
pvscan -- ACTIVE   PV "/dev/sdd"  of VG "dev"   [1.95 GB / 0 free]
pvscan -- ACTIVE   PV "/dev/sde1" of VG "ops"   [996 MB / 52 MB free]
pvscan -- ACTIVE   PV "/dev/sde2" of VG "sales" [996 MB / 944 MB free]
pvscan -- ACTIVE   PV "/dev/sdf1" of VG "ops"   [996 MB / 0 free]
pvscan -- ACTIVE   PV "/dev/sdf2" of VG "dev"   [996 MB / 72 MB free]
pvscan -- total: 8 [11.72 GB] / in use: 8 [11.72 GB] / in no VG: 0 [0]

%# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/dev/cvs           1342492    516468    757828  41% /mnt/dev/cvs
/dev/dev/users         2064208   2060036      4172 100% /mnt/dev/users
/dev/dev/build         1548144   1023041    525103  66% /mnt/dev/build
/dev/ops/databases     2890692   2302417    588275  79% /mnt/ops/databases
/dev/sales/users       2064208    871214   1192994  42% /mnt/sales/users
/dev/ops/batch         1032088    897122    134966  86% /mnt/ops/batch
Как видно из листинга, группы томов "dev" и "ops" практически заполнены. В систему добавили новый диск /dev/sdg. Его необходимо разделить между группами "ops" и "dev", поэтому разобьем его на разделы:
%# fdisk /dev/sdg
Device contains neither a valid DOS partition table, nor Sun or SGI
disklabel Building a new DOS disklabel. Changes will remain in memory
only, until you decide to write them. After that, of course, the
previous content won't be recoverable.

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-1000, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-1000, default 1000): 500

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (501-1000, default 501): 
Using default value 501
Last cylinder or +size or +sizeM or +sizeK (501-1000, default 1000): 
Using default value 1000

Command (m for help): t
Partition number (1-4): 1
Hex code (type L to list codes): 8e
Changed system type of partition 1 to 8e (Unknown)

Command (m for help): t
Partition number (1-4): 2
Hex code (type L to list codes): 8e
Changed system type of partition 2 to 8e (Unknown)

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: If you have created or modified any DOS 6.x partitions,
please see the fdisk manual page for additional information.
Перед тем как добавить разделы в группу томов, их необходимо инициализировать:
%# pvcreate /dev/sdg1
pvcreate -- physical volume "/dev/sdg1" successfully created

# pvcreate /dev/sdg2
pvcreate -- physical volume "/dev/sdg2" successfully created
Теперь можно добавлять физические тома в группы томов:
%# vgextend ops /dev/sdg1
vgextend -- INFO: maximum logical volume size is 255.99 Gigabyte
vgextend -- doing automatic backup of volume group "ops"
vgextend -- volume group "ops" successfully extended

# vgextend dev /dev/sdg2
vgextend -- INFO: maximum logical volume size is 255.99 Gigabyte
vgextend -- doing automatic backup of volume group "dev"
vgextend -- volume group "dev" successfully extended

# pvscan
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- ACTIVE   PV "/dev/sda"  of VG "dev"   [1.95 GB / 0 free]
pvscan -- ACTIVE   PV "/dev/sdb"  of VG "sales" [1.95 GB / 0 free]
pvscan -- ACTIVE   PV "/dev/sdc"  of VG "ops"   [1.95 GB / 44 MB free]
pvscan -- ACTIVE   PV "/dev/sdd"  of VG "dev"   [1.95 GB / 0 free]
pvscan -- ACTIVE   PV "/dev/sde1" of VG "ops"   [996 MB / 52 MB free]
pvscan -- ACTIVE   PV "/dev/sde2" of VG "sales" [996 MB / 944 MB free]
pvscan -- ACTIVE   PV "/dev/sdf1" of VG "ops"   [996 MB / 0 free]
pvscan -- ACTIVE   PV "/dev/sdf2" of VG "dev"   [996 MB / 72 MB free]
pvscan -- ACTIVE   PV "/dev/sdg1" of VG "ops"   [996 MB / 996 MB free]
pvscan -- ACTIVE   PV "/dev/sdg2" of VG "dev"   [996 MB / 996 MB free]
pvscan -- total: 10 [13.67 GB] / in use: 10 [13.67 GB] / in no VG: 0 [0]
Наконец, увеличим размеры логических томов и расширим файловые системы до размеров логических томов:
%# umount /mnt/ops/batch
%# umount /mnt/dev/users

# export E2FSADM_RESIZE_CMD=ext2resize
# e2fsadm /dev/ops/batch -L+500M
e2fsck 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/ops/batch: 11/131072 files (0.0<!--  non-contiguous), 4127/262144 blocks
lvextend -- extending logical volume "/dev/ops/batch" to 1.49 GB
lvextend -- doing automatic backup of volume group "ops"
lvextend -- logical volume "/dev/ops/batch" successfully extended

ext2resize v1.1.15 - 2000/08/08 for EXT2FS 0.5b
e2fsadm -- ext2fs in logical volume "/dev/ops/batch" successfully extended to 1.49 GB


# e2fsadm /dev/dev/users -L+900M
e2fsck 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/dev/users: 12/262144 files (0.0% non-contiguous), 275245/524288 blocks
lvextend -- extending logical volume "/dev/dev/users" to 2.88 GB
lvextend -- doing automatic backup of volume group "dev"
lvextend -- logical volume "/dev/dev/users" successfully extended

ext2resize v1.1.15 - 2000/08/08 for EXT2FS 0.5b
e2fsadm -- ext2fs in logical volume "/dev/dev/users" successfully extended to 2.88 GB
Нам осталось смонтировать системы и посмотреть их размеры:
%# mount /dev/ops/batch
%# mount /dev/dev/users
%# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/dev/cvs           1342492    516468    757828  41% /mnt/dev/cvs
/dev/dev/users         2969360   2060036    909324  69% /mnt/dev/users
/dev/dev/build         1548144   1023041    525103  66% /mnt/dev/build
/dev/ops/databases     2890692   2302417    588275  79% /mnt/ops/databases
/dev/sales/users       2064208    871214   1192994  42% /mnt/sales/users
/dev/ops/batch         1535856    897122    638734  58% /mnt/ops/batch


Резервное копирование при помощи "снапшотов"

Развивая приведенный пример, предположим, что нам нужно выполнить резервирование базы данных. Для этой задачи мы будем использовать устройство-"снапшот".
Этот тип устройства представляет собой доступную только на чтение копию другого тома на момент выполнения процедуры "снапшот". Это дает возможность продолжать работу не заботясь о том, что данные могут измениться в момент резервного копирования. Следовательно, нам не нужно останавливать работу базы данных на время выполнения резервного копирования. Остановка нужна только на момент создания устройства-"снапшот", который значительно короче самого копирования.
В группе томов ops у нас осталось около 600Мб свободного места, его мы и задействуем для "снапшот"-устройства. Размер "снапшот"-устройства не регламентируется, но должен быть достаточен для сохранения всех изменений, которые могут произойти с томом, с которого он сделан, за время жизни снапшота. 600Мб должно хватить для наших целей:
%# lvcreate -L592M -s -n dbbackup /dev/ops/databases 
lvcreate -- WARNING: the snapshot must be disabled if it gets full
lvcreate -- INFO: using default snapshot chunk size of 64 KB for "/dev/ops/dbbackup"
lvcreate -- doing automatic backup of "ops"
lvcreate -- logical volume "/dev/ops/dbbackup" successfully create
Если вы делаете "снапшот" файловой системы XFS, нужно выполнить на смонтированной файловой системе команду xfs_freeze, и лишь после этого создавать "снапшот":
%# xfs_freeze -f /mnt/point; lvcreate -L592M -s -n dbbackup /dev/ops/databases; xfs_freeze -u /mnt/point
Icon-caution.gif
Если устройство-"снапшот" полностью заполняется, оно автоматически деактивируется. В этом случае "снапшот" не может более использоваться, потому крайне важно выделять достаточное пространство для него.
После того как мы создали "снапшот", его нужно смонтировать:
%# mkdir /mnt/ops/dbbackup
%# mount /dev/ops/dbbackup /mnt/ops/dbbackup
mount: block device /dev/ops/dbbackup is write-protected, mounting read-only
Если вы работаете с файловой системой XFS, вам будет нужно при монтировании указать опцию nouuid:
%# mount -o nouuid,ro /dev/ops/dbbackup /mnt/ops/dbbackup
Выполним резервное копирование раздела:

%# tar -cf /dev/rmt0 /mnt/ops/dbbackup
tar: Removing leading `/' from member names
После выполнения необходимых процедур, нужно удалить устройство-"снапшот":
%# umount /mnt/ops/dbbackup
%# lvremove /dev/ops/dbbackup 
lvremove -- do you really want to remove "/dev/ops/dbbackup"? [y/n]: y
lvremove -- doing automatic backup of volume group "ops"
lvremove -- logical volume "/dev/ops/dbbackup" successfully removed
Icon-caution.gif
Запись данных на том, с которого сделан снимок, очень сильно замедлена по сравнению с обычной работой!
Элементарное сравнение производительности, наглядно демонстрирующее разницу между скоростью работы с томом, у которого нет снапшотов (смонтирован в /data/lv3/xxxx), и с томом, на котором есть снапшот (смонтирован в /data/lv4/qqqq).
%# dd if=/dev/zero of=/data/lv3/xxxx count=100 bs=1024k
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.827104 s, 127 MB/s

%# dd if=/dev/zero of=/data/lv4/qqqq count=100 bs=1024k
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 5.77779 s, 18.1 MB/s



Удаление диска из группы томов

Скажем, вы хотите освободить один диск из группы томов. Для этого необходимо выполнить процедуру переноса использующихся физических экстентов. Естественно, что на других физических томах должно быть достаточно свободных физических экстентов.
Выполните команду:
%# pvmove /dev/hdb
pvmove -- moving physical extents in active volume group "dev"
pvmove -- WARNING: moving of active logical volumes may cause data loss!
pvmove -- do you want to continue? [y/n] y
pvmove -- 249 extents of physical volume "/dev/hdb" successfully moved
Учтите, что операция переноса физических экстентов занимает много времени. Если вы хотите наблюдать за процессом переноса экстентов, укажите в команде ключ -v .
После окончания процедуры переноса, удалите физический том из группы томов:
%# vgreduce dev /dev/hdb
vgreduce -- doing automatic backup of volume group "dev"
vgreduce -- volume group "dev" successfully reduced by physical volume:
vgreduce -- /dev/hdb
Теперь данный диск может быть физически удален из системы или использован в других целях. Например, добавлен в другую группу томов.

Перенос группы томов на другую систему

Физический перенос группы томов на другую систему организовывается при помощи команд vgexport и vgimport.
Сперва необходимо размонтировать все логические тома группы томов и деактивировать группу:
%# unmount /mnt/design/users
%# vgchange -an design
vgchange -- volume group "design" successfully deactivated
После этого экспортируем группу томов. Процедура экспорта запрещает доступ к группе на данной системе и готовит ее к удалению:
%# vgexport design
vgexport -- volume group "design" sucessfully exported
Теперь можно выключить машину, отсоединить диски, составляющие группу томов и подключить их к новой системе. Остается импортировать группу томов на новой машине и смонтировать логические тома:
%# pvscan
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- inactive PV "/dev/sdb1"  is in EXPORTED VG "design" [996 MB / 996 MB free]
pvscan -- inactive PV "/dev/sdb2"  is in EXPORTED VG "design" [996 MB / 244 MB free]
pvscan -- total: 2 [1.95 GB] / in use: 2 [1.95 GB] / in no VG: 0 [0]
# vgimport design /dev/sdb1 /dev/sdb2
vgimport -- doing automatic backup of volume group "design"
vgimport -- volume group "design" successfully imported and activated

%# mkdir -p /mnt/design/users
%# mount /dev/design/users /mnt/design/users
Все! Группа томов готова к использованию на новой системе.

Конвертация корневой файловой системы в LVM

В данном примере имеется установленная система на двух разделах: корневом и /boot. Диск размером 2Гб разбит на разделы следующим образом:
/dev/hda1  /boot 
/dev/hda2  swap
/dev/hda3  /
Корневой раздел занимает все пространство, оставшееся после выделения swap и /boot разделов. Главное требование, предъявляемое к корневому разделу в нашем примере: он должен быть более чем на половину пуст. Это нужно, чтобы мы могли создать его копию. Если это не так, нужно будет использовать дополнительный диск. Процесс при этом останется тот же, но уменьшать корневой раздел будет не нужно.
Для изменения размера файловой системы мы будем использовать утилиту GNU parted.
Загрузитесь в однопользовательском режиме, это важно. Запустите программу parted для уменьшения размера корневого раздела. Ниже приведен пример диалога с утилитой parted:
# parted /dev/hda
(parted) p
.
.
.
Изменим размер раздела:
(parted) resize 3 145 999
Первое число -- это номер раздела (hda3), второе -- начало раздела hda3, не меняйте его. Последнее число -- это конец раздела. Укажите приблизительно половину текущего размера раздела.
Создадим новый раздел:
(parted) mkpart primary ext2 1000 1999
Этот раздел будет содержать LVM. Он должен начинаться после раздела hda3 и заканчиваться в конце диска.
Выйдите из утилиты parted:
(parted) q
Перезагрузите систему. Убедитесь, что ваше ядро содержит необходимые установки. Для поддержки LVM должны быть включены параметры CONFIG_BLK_DEV_RAM и CONFIG_BLK_DEV_INITRD.
Для созданного раздела необходимо изменить тип на LVM (8e). Поскольку parted не знает такого типа, воспользуемся утилитой fdisk:
%# fdisk /dev/hda
Command (m for help): t
Partition number (1-4): 4
Hex code (type L to list codes): 8e
Changed system type of partition 4 to 8e (Unknown)
Command (m for help): w
Инициализируем LVM, физический том; создаем группу томов и логический том для корневого раздела:
%# vgscan
%# pvcreate /dev/hda4
%# vgcreate vg /dev/hda4
%# lvcreate -L250M -n root vg
Создадим теперь файловую систему на логическом томе и перенесем туда содержимое корневого каталога:
%# mke2fs /dev/vg/root
%# mount /dev/vg/root /mnt/
%# find / -xdev | cpio -pvmd /mnt
Отредактируйте файл /mnt/etc/fstab на логическом томе соответствующем образом. Например, строку:
/dev/hda3       /    ext2       defaults 1 1
замените на:
/dev/vg/root    /    ext2       defaults 1 1
Создаем образ initrd, поддерживающий LVM:
%# lvmcreate_initrd
Logical Volume Manager 1.0.6 by Heinz Mauelshagen  25/10/2002
lvmcreate_initrd -- make LVM initial ram disk /boot/initrd-lvm-2.4.20-inp1-up-rootlvm.gz

lvmcreate_initrd -- finding required shared libraries
lvmcreate_initrd -- stripping shared libraries
lvmcreate_initrd -- calculating initrd filesystem parameters
lvmcreate_initrd -- calculating loopback file size
lvmcreate_initrd -- making loopback file (6491 kB)
lvmcreate_initrd -- making ram disk filesystem (19125 inodes)
lvmcreate_initrd -- mounting ram disk filesystem
lvmcreate_initrd -- creating new /etc/modules.conf
lvmcreate_initrd -- creating new modules.dep
lvmcreate_initrd -- copying device files to ram disk
lvmcreate_initrd -- copying initrd files to ram disk
lvmcreate_initrd -- copying shared libraries to ram disk
lvmcreate_initrd -- creating new /linuxrc
lvmcreate_initrd -- creating new /etc/fstab
lvmcreate_initrd -- ummounting ram disk
lvmcreate_initrd -- creating compressed initrd /boot/initrd-lvm-2.4.20-inp1-up-rootlvm.gz
Внимательно изучите вывод команды. Обратите внимание на имя нового образа и его размер. Отредактируйте файл /etc/lilo.conf. Он должен выглядеть приблизительно следующим образом:
image   = /boot/KERNEL_IMAGE_NAME
label   = lvm
root    = /dev/vg/root
initrd  = /boot/INITRD_IMAGE_NAME
ramdisk = 8192
KERNEL_IMAGE_NAME -- имя ядра, поддерживающего LVM. INITRD_IMAGE_NAME -- имя образа initrd, созданного командой lvmcreate_initrd. Возможно, вам будет нужно увеличить значение ramdisk, если у вас достаточно большая конфигурация LVM, но значения 8192 должно хватить в большинстве случаев. Значение по умолчанию параметра ramdisk равно 4096. Если сомневаетесь, проверьте вывод команды lvmcreate_initrd в строке lvmcreate_initrd -- making loopback file (6189 kB).
После этого файл lilo.conf нужно скопировать и на логический том:
%# cp /etc/lilo.conf /mnt/etc/
Выполните команду lilo:
%# lilo
Перезагрузитесь и выберите образ lvm. Для этого введите "lvm" в ответ на приглашение LILO. Система должна загрузится, а корневой раздел будет находиться на логическом томе.
После того как вы убедитесь, что все работает нормально, образ lvm нужно сделать загружаемым по умолчанию. Для этого укажите в конфигурационном файле LILO строку default=lvm, и выполните команду lilo.
Наконец, добавьте оставшийся старый корневой раздел в группу томов. Для этого измените тип раздела утилитой fdisk на 8е, и выполните команды:
%# pvcreate /dev/hda3
%# vgextend vg /dev/hda3








Организация корневой файловой системы в LVM для дистрибутива ALT Master 2.2

При установке данного дистрибутива оказалось невозможным разместить корневой раздел в системе LVM. Связано это с тем, как выяснилось позже, что в ядре, поставляемом с данным дистрибутивом, поддержка файловой системы ext2 организована в виде загружаемого модуля. Образ же initrd использует файловую систему romfs, поддержка которой вкомпилирована в ядро. При выполнении команды lvmcreate_initrd генерируется файл-образ initrd с системой ext2. Если после этого вы попытаетесь загрузиться, то получите примерно следующее:
Kernel panic: VFS: Unable to mount root fs on 3a:00
Первое, что вам нужно будет сделать -- это скомпилировать ядро со встроенной поддержкой файловой системы ext2, установить его и проверить. После этого снова выполните команду lvmcreate_initrd. Дальнейшие действия зависят от вашей конфигурации. Смонтируйте созданный образ:
%# gzip -d /boot/initrd-lvm-2.4.20-inp1-up-rootlvm.gz
%# mount -o loop /boot/initrd-lvm-2.4.20-inp1-up-rootlvm /mnt/initrd
И копируйте туда модули, необходимые для работы с вашими дисковыми накопителями и файловыми системами (если они не вкомпилированы в ядро). Так, для системы с RAID-контроллером ICP-Vortex и корневой файловой системой reiserfs нужны модули: gdth.o mod_scsi.o sd_mod.o reiserfs.o. Добавьте их загрузку в файл /mnt/initrd/linuxrc.
Обратите внимание на оставшееся свободное место на образе:
Filesystem Size Used Avail Use% Mounted on ... /boot/initrd-lvm-2.4.20-inp1-up-rootlvm
                     4.0M  3.9M  0.1M  100% /mnt/initrd
В файловой системе должно быть свободно еще 200-300Кб, в зависимости от вашей LVM-конфигурации. Если же у вас ситуация похожа на приведенную в листинге, будет необходимо создать новый образ, с большим размером файловой системы и повторить операции добавления модулей.
Наконец, отмонтируйте образ, сожмите его, запустите программу lilo и перезагрузитесь:
%# umount /mnt/initrd
%# gzip /boot/initrd-lvm-2.4.20-inp1-up-rootlvm
%# lilo
%# reboot



Заключение

Система управления логическими томами особенно полезна в работе с серверами, поскольку обеспечивает масштабируемость и удобное управление дисковым пространством. Она упрощает планирование дискового пространства и предотвращает проблемы, возникающие при неожиданно быстром росте занятого места в разделах. LVM не предназначен для обеспечения отказоустойчивости или высокой производительности. Потому он часто используется в сочетании с системами RAID.
Использованные источники:

Дополнительные вопросы по LVM

Дисковые разделы и LVM внутри LVM

LVM может находиться рекурсивно внутри логического тома LVM.
Например, пусть есть три логических тома: LV1LV2 и LV3. Один из которых, LV2 разбит на разделы, каждый из которых является физическим томом LVM, который в свою очередь объединены в группу томов, на которых созданы логические тома и так далее.
  LV1                LV2                LV3
 ...--++----------------------------+ +--....
      ||+-------------------------+ | |
      |||            LVM          | | |
      ||+-------------------------+ | |
 ...--++----------------------------+ +--.....
Такая ситуация очень легко может возникнуть при использовании виртуальных машин, например в том случае, если том LV2 выдан как диск виртуальной машине Xen или эмулятору QEMU.
Может возникнуть необходимость залезть внутрь системы томов, которые установлены внутрь логического тома. Например, это может произойти в случае, когда виртуальная машина (в результате сбоя или по какой-то другой причине), не загружается, а нужно добраться до её данных (напомним, что всё это при условии, что LVM используется не только снаружи, то есть в домене 0, но и внутри, то есть в домене U).
Решение, если говорить кратко, заключается в том, чтобы использовать kpartx из пакета multipath-tools, которая даёт возможность строить карты устройств (device maps) для разделов.
Далее процедура использования kpartx описывается подробно.
Блочное устройство, внутри которого находятся тома LVM может быть любым, в частности, это может быть том LVM, том EVMS, простой дисковый раздел или физическое устройство.
Убедитесь что пакет multipath-tools установлен:
%# apt-get install multipath-tools 
Посмотрите как выполнено разбинение на разделы:
dom0:~ # fdisk -l /dev/evms/san2/vm3
Disk /dev/evms/san2/vm3: 5368 MB, 5368708096 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

              Device Boot      Start         End      Blocks   Id  System
/dev/evms/san2/vm3p1   *           1           9       72261   83  Linux
/dev/evms/san2/vm3p2              10         652     5164897+   f  W95 Ext'd (LBA)
/dev/evms/san2/vm3p5              10          75      530113+  82  Linux swap / Solaris
/dev/evms/san2/vm3p6              76         493     3357553+  83  Linux
/dev/evms/san2/vm3p7             494         652     1277136   83  Linux
Создайте карту устройств для блочного устройства:
dom0:~ # kpartx -a /dev/evms/san2/vm3 
Карты находятся здесь:
%# ls -l /dev/mapper
total 0
lrwxrwxrwx 1 root root      16 Aug 26 16:28 control -> ../device-mapper
brw------- 1 root root 253,  1 Aug 26 16:28 mpath1
brw------- 1 root root 253,  0 Aug 26 16:28 mpath2
brw------- 1 root root 253, 13 Aug 29 08:55 san2|vm3p1
brw------- 1 root root 253, 14 Aug 29 08:55 san2|vm3p2
brw------- 1 root root 253, 15 Aug 29 08:55 san2|vm3p5
brw------- 1 root root 253, 16 Aug 29 08:55 san2|vm3p6
brw------- 1 root root 253, 17 Aug 29 08:55 san2|vm3p7
Имена выглядят несколько странно, но вообще это нормально.
Можно попробовать смонтировать раздел:
%# mount -o rw /dev/mapper/san2\|vm3p6 /mnt
В данном случае была смонтирована корневая файловая система виртуальной машины:
%# ls -l /mnt
total 96
dr-xr-xr-x  3 root root  4096 Aug 28 10:12 automount
drwxr-xr-x  2 root root  4096 Aug 25 16:51 bin
drwxr-xr-x  2 root root  4096 Aug 25 16:45 boot
drwxr-xr-x  5 root root  4096 Aug 25 16:45 dev
drwxr-xr-x 69 root root  8192 Aug 29 08:53 etc
drwxr-xr-x  2 root root  4096 May  4 01:43 home
drwxr-xr-x 11 root root  4096 Aug 25 17:10 lib
drwx------  2 root root 16384 Aug 25 16:45 lost+found
drwxr-xr-x  2 root root  4096 May  4 01:43 media
drwxr-xr-x  3 root root  4096 Aug 28 15:08 mnt
drwxr-xr-x  4 root root  4096 Aug 25 16:49 opt
drwxr-xr-x  2 root root  4096 Aug 25 16:45 proc
drwx------ 10 root root  4096 Aug 28 14:56 root
drwxr-xr-x  3 root root  8192 Aug 25 16:52 sbin
drwxr-xr-x  4 root root  4096 Aug 25 16:45 srv
-rw-r--r--  1 root root     0 Aug 29 08:53 success
drwxr-xr-x  3 root root  4096 Aug 25 16:45 sys
drwxrwxrwt  6 root root  4096 Aug 29 08:49 tmp
drwxr-xr-x 12 root root  4096 Aug 25 16:50 usr
drwxr-xr-x  3 root root  4096 Aug 25 16:54 var
Аналогичным образом монтируем остальные разделы:
%# mount -o rw /dev/mapper/san2\|vm3p1 /mnt/boot
%# mount -o rw /dev/mapper/san2\|vm3p7 /mnt/var
С разделами можно работать как обычно.
По завершению работы нужно
  • размонтировать разделы;
  • удалить карты устройств.
Note-icon.gif
Размонтировать разделы и удалить карту устройств особенно важно, если эти разделы принадлежат какой-либо виртуальной машине, которую вы собираетесь запускать.
%# umount /mnt/var
%# umount /mnt/boot
%# umount /mnt
%# kpartx -d /dev/evms/san2/vm3 

%# ls -l /dev/mapper
total 0
lrwxrwxrwx 1 root root     16 Aug 26 16:28 control > ../device-mapper
brw------- 1 root root 253, 1 Aug 26 16:28 mpath1
brw------- 1 root root 253, 0 Aug 26 16:28 mpath2

При условии что разделы находятся не на блочном устройстве, а в обычно файле, сначала нужно воспользоваться программой losetup.
В данном примере loop0 это первое свободное loopback-устройство, но возможно, что оно будет занято, и тогда вместо loop0 нужно будет использовать loopX с более выскоим номерм X:
%# cd /etc/xen/images
%# losetup /dev/loop0 /xen/images/vm1.img 
%# losetup -a
/dev/loop0: [6806]:318859 (vm1.img)

%# fdisk -l /dev/loop0 
Disk /dev/loop0: 1638 MB, 1638400000 bytes 
255 heads, 63 sectors/track, 199 cylinders 
Units = cylinders of 16065 * 512 = 8225280 bytes 
      Device Boot      Start         End      Blocks   Id  System 
/dev/loop0p1   *           1           9       72261   83  Linux 
/dev/loop0p2              10         199     1526175    5  Extended 
/dev/loop0p5              10          26      136521   82  Linux swap / Solaris 
/dev/loop0p6              27         151     1004031   83  Linux 
/dev/loop0p7             152         199      385528+  83  Linux 

%# kpartx -a /dev/loop0 
%# ls -l /dev/mapper/ 
total 0 
lrwxrwxrwx 1 root root      16 Sep 12 15:38 control -> ../device-mapper 
brw------- 1 root root 253, 15 Sep 30 13:19 loop0p1 
brw------- 1 root root 253, 16 Sep 30 13:19 loop0p2 
brw------- 1 root root 253, 17 Sep 30 13:19 loop0p5 
brw------- 1 root root 253, 18 Sep 30 13:19 loop0p6 
brw------- 1 root root 253, 19 Sep 30 13:19 loop0p7 
Можно монтировать, копировать, восстанавливать, форматировать эти разделы, короче, делать с ними всё, что делается с обычными дисковыми разделами.
%# mount /dev/mapper/loop0p6 /mnt
%# mount /dev/mapper/loop0p1 /mnt/boot
%# mount /dev/mapper/loop0p7 /mnt/var
%# mount 
-snip-
/dev/mapper/loop0p6 on /mnt type ext3 (rw) 
/dev/mapper/loop0p1 on /mnt/boot type ext2 (rw) 
/dev/mapper/loop0p7 on /mnt/var type ext3 (rw) 
Другое решение:
%# lomount -diskimage vm1.img -partition 1  /mnt
%# mount 
-snip-
/xen/images/vm1.img on /mnt type ext2 (rw,loop=/dev/loop0,offset=32256) 
С одной стороны при таком подходе:
  • не нужно вручную подключать loopback-устройства;
  • не нужно использовать kpartx;
Но с другой стороны:
  • это решение позволяет смонтировать только простые разделы, размещённые внутри тома LVM.
Если внутри логического тома выполнено другое разбиение, такой подход не поможет.
Если внутри тома находится расширенный раздел, подход работает, но требует дополнительных манипуляций:
%# fdisk -l -u /xen/images/vm1.img 
You must set cylinders. 
You can do this from the extra functions menu. 
Disk vm1.img: 0 MB, 0 bytes 
255 heads, 63 sectors/track, 0 cylinders, total 0 sectors 
Units = sectors of 1 * 512 = 512 bytes 
  Device Boot      Start         End      Blocks   Id  System 
vm1.img1   *          63      144584       72261   83  Linux 
vm1.img2          144585     3196934     1526175    5  Extended 
vm1.img5          144648      417689      136521   83  Linux 
vm1.img6          417753     2425814     1004031   83  Linux 
vm1.img7         2425878     3196934      385528+  83  Linux 
Найти начало интересующего раздела можно путём умножения значения поля Start (показанного fdiks) на 512.
417753*512=213889536
Если мы хотим смонтировать корневой раздел:
%# mount -o loop,offset=213889536 /xen/images/vm1.img /mnt
%# mount 
-snip-
/xen/images/vm1.img on /mnt type ext3 (rw,loop=/dev/loop0,offset=213889536)


Создание зашифрованных томов LVM

Пример создания зашифрованного тома:
%# cryptsetup -y -s 256 -c aes-cbc-essiv:sha256 luksFormat /dev/hda3
%# cryptsetup luksOpen /dev/hda3 lukspace
%# pvcreate /dev/mapper/lukspace
%# vgcreate vg /dev/mapper/lukspace
%# lvcreate -L10G -n root vg
%# lvcreate -l 100%FREE -n myspace vg


Список команд для работы с LVM

lvchange
Изменить атрибуты логического тома
lvcreate
Создать логический том
lvdisplay
Показать информацию о логическом томе
lvextend
Добавить места в логический том
lvmchange
(команда устарела, её лучше не использовать)
lvmdiskscan
Показать список устройств, которые могут быть использованы как физический том
lvmsadc
Собрать данные об активности использования LVM
lvmsar
Создать отчёт об активности использования LVM
lvreduce
Уменьшить размер логического тома
lvremove
Удалить логический том из системы
lvrename
Переименовать логический том
lvresize
Изменить размер логического тома
lvs
Показать информацию о логическом томе
lvscan
Показать список логических томов во всех группах томов
pvchange
Изменить атрибуты физического тома
pvcreate
Инициализировать физический том для использования в LVM
pvdata
Показать информацию (из метаданных на диске) о физическом томе
pvdisplay
Показать информацию о физическом томе
pvmove
Переместить эстенты с одного физического тома на другой
pvremove
Удалить метку LVM с физического тома
pvresize
Изменить размер физического тома, использующегося в группе томов
pvs
Показать информацию о физическом томе
pvscan
Показать список всех физических томов
vgcfgbackup
Сделать резервную копию конфигурации группы томов
vgcfgrestore
Восстановить из резервной копии конфигурацию группы томов
vgchange
Изменить атрибуты группы томов
vgck
Проверить целостность группы томов
vgconvert
Изменить формат метаданных группы томов
vgcreate
Создать группу томов
vgdisplay
Показать информацию о группе томов
vgexport
Разрегистрировать группу томов в системе
vgextend
Добавить физический том в группу томов
vgimport
Зарегистрировать эскпортированную группу томов в системе
vgmerge
Объединить группы томов
vgmknodes
Создать файлы устройств для групп томов в каталоге /dev/
vgreduce
Удалить физический том из группы томов
vgremove
Удалить группу томов
vgrename
Переименовать группу томов
vgs
Показать информацию о группах томов
vgscan
Выполнить поиск групп томов
vgsplit
Переместить физический том в новую группу томов