Содержание


Сценарии varyonvg и varyoffvg

Comments

Иногда возникает необходимость подключения и отключения одной или нескольких групп томов (VG). Например, при обновлении IBM® AIX® с версии 6.1 до версии 7.1 возникает необходимость обновить Subsystem Device Driver Path Control Module (SDDPCM). Для обновления SDDPCM нужно отключить все группы томов приложений и баз данных, которые используют диски сети хранения данных (SAN), например IBM System Storage® SAN Volume Controller (SVC) или IBM System Storage DS8000®. Здесь предполагается, что корневая группа томов (rootvg) использует внутренний SCSI-диск. В данной статье представлены два сценария для подключения и отключения групп томов. Эти сценарии позволяют существенно сэкономить время монтирования и размонтирования файловых систем. Кроме того, в статье обсуждаются способы решения проблем при неудачном выполнении команд unmount, varyoffvg и varyonvg.

Команда varyonvg

Если вы знакомы с командами varyonvg и varyoffvg, можете сразу перейти к разделу Сценарий varyonvg.ksh. Команда varyonvg подключает группу томов и делает ее доступной для использования. Затем на ней можно создать файловые системы для ваших приложений. Ниже показано, как использовать эту команду для подключения групп томов.

=> varyonvg chrisvg

После подключения группы томов hdisk отображается как active при использовании следующей команды lspv:

=> lspv|grep chrisvg
hdisk7         00xyw6oi3b6f069b                   chrisvg         active
hdisk8         00xyz6oi3b6f05ed                   chrisvg         active
hdisk9         00xyz6oi3b6f038a                   chrisvg         active

Группы томов можно подключить в режиме только для чтения, используя параметр -r следующим образом:

=> varyonvg -r chrisvg

При указании этого параметра запрещаются следующие действия:

  • Операции записи в логические тома.
  • Обновления метаданных Logical Volume Manager (LVM).
  • Синхронизация устаревших разделов.

Если большинство дисков в группе томов недоступно, команда varyonvg может завершиться с ошибкой. При наличии в SAN неполадок, препятствующих доступу AIX к большинству SAN-дисков для группы томов, эта команда завершится аварийно. В этом случае AIX отображает список всех физических томов и их состояние. В такой ситуации для успешного подключения группы томов необходимо использовать параметр -f. Этот параметр подключает группу томов, а все диски, которые не могут перейти в активное состояние, переводятся в состояние "удален" (removed). Но для этого хотя бы один диск в группе томов должен быть доступен. Состояние дисков можно отобразить при помощи команды lsvg:

=> lsvg -p chrisvg 
chrisvg: 

PV_NAME              PV STATE           TOTAL PPs       FREE PPs    	 FREE DISTRIBUTION 
hdisk7               active                799             19            00..00..00..00..19
hdisk8               active                799             19            00..00..00..00..19
hdisk9               active                799             19            00..00..00..00..19

Ее выходные данные показывают, что в столбце PV STATE для всех дисков указано состояние active. Это означает, что все диски в этой группе томов доступны для использования.

Команда varyoffvg

Команда varyoffvg отключает группу томов и делает ее недоступной для использования. Ниже показано, как использовать эту команду для отключения группы томов.

=> varyoffvg chrisvg

После отключения VG hdisk больше не отображается как active при использовании команды lspv:

=> lspv|grep chrisvg 
hdisk7         00xyw6oi3b6f069b                    chrisvg         
hdisk8         00xyz6oi3b6f05ed                    chrisvg         
hdisk9         00xyz6oi3b6f038a                    chrisvg

Команда varyoffvg завершится неудачно, если в группе томов есть неразмонтированные файловые системы. Если команда umount для каких-либо файловых систем завершается неудачно, обратитесь за дополнительной информацией в раздел Проблемы при размонтировании файловых систем.

Дополнительная информация по LVM приведена в документе IBM Redbooks® AIX Logical Volume Manager от А до Я: введение и концепции.

Сценарий varyonvg.ksh

При выполнении сценария varyonvg.ksh команда lsvg отображает список групп томов. Отображаются все группы томов, за исключением rootvg. Затем этот сценарий предложит вам ввести данные. Можно указать одну или несколько групп томов и нажать клавишу Enter; если групп томов несколько, они должны быть разделены символом вертикальной черты (“|”). Я использую команду lsvgfs VG1 для поиска всех файловых систем на VG1 и их монтирования. После выполнения этого сценария для подключения групп томов необходимо запустить все приложения и базы данных, использующие эти группы томов. Возможно, придется обратиться в группу разработки приложений или к администратору базы данных и попросить их запустить свои приложения и базу данных после подключения групп томов. Ссылка на сценарий varyonvg.ksh:

При выполнении сценария ./varyonvg.ksh отобразится следующая информация:

The following is a list of current VGs: 
myVG1
myVG2
myVG3
myVG4
myVG5
You can specify one VG or a list of VGs to be varied on (separated by a pipe "|") as shown below.
            
VG1|VG2|VG3 

myVG1|myVG2|myVG3 
------------------------------------------------------------------------------------------------ 
varyonvg myVG1 successful 
mount /myVG1/FS1 successful 
mount /myVG1/FS2 successful 
------------------------------------------------------------------------------------------------ 
varyonvg myVG2 successful 
mount /myVG2/FS1 successful 
mount /myVG2/FS2 successful 
------------------------------------------------------------------------------------------------ 
varyonvg myVG3 successful 
mount /myVG3/FS1 successful 
mount /myVG3/FS2 successful 
------------------------------------------------------------------------------------------------

Возьмем две строки из приведенных выше выходных сообщений:

varyonvg myVG3 successful 
mount /myVG3/FS1 successful

Слово successful в строке сообщения varyonvg означает, что была успешно подключена группа томов myVG3. Слово successful в строке сообщения mount означает, что была успешно смонтирована файловая система /myVG3/FS1. Если бы сценарий varyonvg завершился неудачно, сообщение содержало бы вместо successful слово UNSUCCESSFUL заглавными буквами. При неудачном монтировании файловой системы сообщение содержало бы слово UNSUCCESSFUL вместо successful. Отметим, что /myVG3/FS1 – это имя файловой системы, которое обычно, в отличие от данного случая, не содержит имени группы томов (myVG3). Я сделал так, чтобы продемонстрировать, как сценарий сначала подключает каждую группу томов, а затем монтирует все ее файловые системы перед переходом к следующей группе томов. Если команды varyonvg или mount завершаются неудачно, необходимо определить причину проблемы, исправить ее и повторно выполнить сценарий. Сценарий можно перезапустить в любое время, и он будет подключать все группы томов, даже если они уже были подключены, и монтировать все файловые системы, даже если некоторые из них уже были смонтированы. В таком случае вы просто получите сообщение о том, что группа томов уже подключена или файловая система уже смонтирована.

Сценарий varyoff.ksh

При выполнении сценария varyoffvg.ksh команда lsvg -o отображает список VG. Отображаются только активные или подключенные группы томов, за исключением rootvg. Затем сценарий предложит вам ввести данные. Можно указать одну или несколько групп томов и нажать клавишу Enter; если групп томов несколько, они должны быть разделены символом вертикальной черты (“|”). Я использую команду lsvgfs VG1 для поиска всех файловых систем в группе томов VG1 и их размонтирования. Перед запуском данного сценария для отключения групп томов необходимо остановить все приложения и базы данных, использующие эти группы томов. Возможно, придется обратиться в группу разработки приложений или к администратору базы данных и попросить их остановить свои приложения и базу данных до размонтирования файловых систем и отключения групп томов. Сценарий приведен ниже.

Далее приведены результаты выполнения этого сценария:

=> ./varyoffvg.ksh
The following is a list of active VGs:
myVG1
myVG2
myVG3 
myVG4
myVG5
You can specify one VG or a list of VGs to be varied off (separated by a pipe "|") as shown below.
           
VG1|VG2|VG3 

myVG1|myVG2|myVG3 
------------------------------------------------------------------------------------------------ 
umount /myVG1/FS1 successful 
umount /myVG1/FS2 successful 
varyoffvg myVG1 successful 
------------------------------------------------------------------------------------------------ 
umount /myVG2/FS1 successful 
umount /myVG2/FS2 successful 
varyoffvg myVG2 successful 
------------------------------------------------------------------------------------------------ 
umount /myVG3/FS1 successful 
umount /myVG3/FS2 successful   
varyoffvg myVG3 successful 
------------------------------------------------------------------------------------------------

Возьмем две строки из приведенных выше выходных сообщени

umount /myVG3/FS1 successful 
varyoffvg myVG3 successful

Слово successful в строке сообщения umount означает, что была успешно размонтирована файловая система /myVG3/FS1. Слово successful в строке сообщения varyonvg означает, что группа томов была успешно отключена. Если бы umount завершилась неудачно, сообщение содержало бы вместо successful слово UNSUCCESSFUL заглавными буквами. Если бы varyoffvg завершилась неудачно, сообщение содержало бы вместо successful слово UNSUCCESSFUL. В этом случае необходимо определить причину неудачного размонтирования. Дополнительная информация приведена в разделе Проблемы при размонтировании файловых систем.

Проблемы при размонтировании файловых систем

Допустим, что команда umount для файловой системы /myVG3/FS1 завершилась неудачей. Обычно размонтирование завершается неудачно, если в данный момент файловая система используется одним или несколькими процессами. В этом случае необходимо определить владельца файловой системы и владельца процессов, ее использующих. После определения владельца процессов, использующих файловую систему, можно связаться с ним для остановки приложения или базы данных. Также можно снять (kill) процесс и затем размонтировать файловую систему. Для определения владельца файловой системы необходимо выполнить следующую команду:

=> ls -l /myVG3/FS1
-rwxr-xr-x    1 cnarcouz     staff     58594159 Jan  8 2014  /myVG3/FS1

Результат выполнения команды показывает, что идентификатором владельца файловой системы является cnarcouz.

Для получения полного имени пользователя можно использовать следующую команду:

=> grep cnarcouz /etc/passwd 
cnarcouz:!:999:222:Christopher Narcouzi:/home/cnarcouz:/bin/ksh

Результат выполнения этой команды показывает, что владельцем идентификатора cnarcouz и владельцем файловой системы /myVG3/FS1 является Christopher Narcouzi (то есть я).

Если бы идентификатор пользователя был tsm (IBM Tivoli® Storage Manager, TSM) или db2 (IBM DB2® database), то файловая система принадлежала бы TSM или DB2. Иногда имя файловой системы содержит tsm или db2, что дает подсказку о ее владельце. Мы определили владельца файловой системы, но нам все еще нужно узнать имя владельца процесса, использующего данную файловую систему.

Для поиска использующих файловую систему процессов и их владельцев необходимо выполнить команду fuser. Ниже приведен пример запуска и результаты выполнения команды fuser для каталога /home.

=> fuser -xuc /home
/home:  9834761c(daemon) 8635421c(root) 7346581c(root) 5689214(root) 3768915e(tsm)

Результат выполнения команды показывает, что каталог /home используют несколько процессов. Обратите внимание, что за номерами некоторых процессов следуют символы c и e. Эти символы говорят о том, как используется файл. Ниже приведено описание значения этих символов.

  • c – файл используется как текущий каталог.
  • e – файл используется как исполняемый объект программы.
  • r – файл используется как корневой каталог.
  • s – файл используется как общая библиотека (или другой загружаемый объект).

Выше был приведен пример команды fuser, но в нашем случае мы будем использовать следующую команду:

=> fuser -xuc /myVG3/FS1

Эта команда отображает все процессы, использующие указанную файловую систему, вместе с идентификатором владельца каждого процесса. Если, к примеру, идентификатором пользователя является tsm, для ее остановки следует связаться с администратором TSM. Иногда владельцем может быть root, но это не обязательно истинный владелец, особенно если вам известно, что файловая система предназначена для приложений, а не является файловой системой для ОС, например /opt. Для выполнения некоторых приложений необходимы права root, поэтому они запускаются при помощи sudo. В этом случае в результатах выполнения команды fuser в качестве владельца будет отображаться пользователь root, но мы знаем, что это на самом деле не так, поскольку файловая система предназначена для приложений. В таком случае необходимо определить, кто является реальным владельцем процесса. Является ли данный процесс процессом приложения, процессом базы данных или пользовательским процессом? Допустим, к примеру, что одним из процессов, использующих файловую систему, является 9834576. Для определения реального владельца процесса необходимо выполнить следующую команду.

=> ps -ef | grep  9834576
root  9834576  3648729   0   Oct 15      -  6:21 /home/cnarcouz/myappl.ksh

Это означает, что файловая система используется выполняющимся процессом, который запустило приложение /home/cnarcouz/myappl.ksh. Теперь можно определить владельца этого процесса. Для определения идентификатора владельца можно выполнить следующую команду:

=> ls -l /home/cnarcouz/myappl.ksh
-rwxr-xr-x    1 cnarcouz     staff     58594159 Jan  8 2014  /home/cnarcouz/myappl.ksh

Результат выполнения команды показывает, что приложением /home/cnarcouz/myappl.ksh владеет пользователь с идентификатором cnarcouz.

Для определения имени пользователя с этим идентификатором можно выполнить следующую команду:

=> grep cnarcouz /etc/passwd 
cnarcouz:!:999:222:Christopher Narcouzi:/home/cnarcouz:/bin/ksh

Результат выполнения команды показывает, что пользователем с данным идентификатором является Christopher Narcouzi. Вам нужно связаться с ним, сообщить о том, что вы обновляете систему, и попросить разрешения снять процесс.

Иногда путь /home/cnarcouz/myappl.ksh может содержать имя приложения или базы данных, например TSM или DB2. В этом случае нужно связаться с администратором TSM или администратором DB2 и попросить их остановить TSM или DB2. Если файловую систему использует много процессов (как показано в результате выполнения команды fuser), для немедленного снятия всех процессов можно использовать следующую команду.

fuser -xuck /myVG3/FS1

Параметр k используется для немедленного снятия всех процессов, работающих с файловой системой /myVG3/FS1. Перед принятием такого решения убедитесь в том, что это не повлияет на что-либо еще. Прежде всего убедитесь, что вы имеете полномочия для немедленного снятия процессов. После выполнения данной команды можно посмотреть, все ли процессы сняты.

fuser -xuc /myVG3/FS1

Чтобы снять некоторые процессы, возможно, придется использовать kill -9, но помните о последствиях. При использовании kill -9 к TSM можно оставить базу данных TSM в противоречивом состоянии. В этом случае могут внезапно прекратить работу многие процессы резервного копирования TSM. Администратору TSM придется исправлять ситуацию. Я не люблю использовать kill -9 для процессов приложений и предпочитаю, чтобы группы сами останавливали свои приложения. Перед применением kill -9 к процессу приложения проинформируйте группу поддержки приложений о том, что эта команда может внезапно остановить их процессы в момент обновления базы данных, оставив ее в противоречивом состоянии, и спросите, смогут ли они исправить потенциальные проблемы. Получите от них разрешение на снятие процессов таким способом.

В конечном итоге лучшее, что можно сделать – всегда останавливать все приложения и базы данных, чтобы избежать возникновения проблем в ситуациях, когда некоторые файловые системы не размонтируются из-за использующих их процессов. Но если проблемы все же возникнут, вы уже знаете, как с ними справиться.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=AIX и UNIX
ArticleID=1014298
ArticleTitle=Сценарии varyonvg и varyoffvg
publish-date=01062015