?

Log in

sigizmundabol atom

> Recent Entries
> Archive
> Friends
> Profile

July 19th, 2012


12:19 pm - VMware Tools: пользовательские скрипты реакции на события Suspend VM/Resume VM

Иногда необходимо выполнить некоторые действия в гостевой ОС перед приостановкой и после возобновления работы виртуальной машины. Вообще говоря, есть действия по умолчанию, которые VMware Tools всегда выполняет в этих случаях. Так в Ubuntu в /etc/vmware-tools/ лежат 4 скрипта:

poweroff-vm-default
poweron-vm-default
resume-vm-default
suspend-vm-default

в начале каждого из которых стоит небольшой дисклаймер:

# DO NOT modify this file directly as it will be overwritten the next
# time the VMware Tools are installed.

Разработчик как бы намекает нам, что вставлять свои обработки прямо в эти скрипты - нехорошая идея. Однако, анализ скриптов показывает, что каждый из них по ходу пьесы ищет каталог ${powerOp}-default.d в /etc/vmware-tools/scripts/, где ${powerOp} = (poweroff-vm, poweron-vm, resume-vm, suspend-vm), и, если такой каталог найден, выполняет все лежащие в нем пользовательские скрипты в алфавитном порядке.

Т.е. стоит нам создать каталог suspend-vm-default.d в /etc/vmware-tools/scripts/ и положить туда свой скрипт, как он будет обязательно выполнен при саспенде виртуальной машины, да? Нет! К сожалению, при саспенде не выполняется даже сам suspend-vm-default, не говоря уже о каком-то там пользовательском творчестве. Такой баг! Ну, или фича.

Тем не менее, resume-vm-default работает как надо. Вернее, в моем случае - как не надо :P Дело в том, и тут мы плавно переходим к практике, что при возобновлении работы виртуалки он рестартует ее сеть. А у меня там, извините, всякие таблицы маршрутизации, заполняемые при загрузке системы. Все идет прахом, включая default gateway :P Вот для такого случая в /etc/vmware-tools/scripts/resume-vm-default.d/ у меня и лежит скрипт restore_rt, возвращающий все взад.

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

(Leave a comment)

May 29th, 2012


01:20 pm - Компас владельца серверного APC Smart-UPS

Это простая картинка помогает понять как настроить UPS так, чтобы работа системы UPS+сервер не требовала вмешательства ни при каких, даже самых экзотических по времени, случаях отключения/включения электропитания. Система лишь будет обходить стороны света по часовой стрелке, задерживаясь в некоторых из них, но никогда не падая) Изначально полагаем, что на дуге ]S..W..N] электропитание присутствует, но может внезапно исчезнуть, а на дуге ]N..E..S] - отсутствует, но может внезапно появиться.



Итак, "Раз, два… Меркурий во втором доме… луна ушла…" (c), поехали!

В норме, когда с питанием все в порядке, система находится в серверной точке (N), и сервер работает, напряженно обслуживая клиентов. Я не стал изображать этот период времени в виде какого-то протяженного сектора на картушке во-первых потому, что он не важен с точки зрения UPS-серверного взаимодействия, а во-вторых, как будет видно в дальнейшем, такого периода может и не быть. То же самое касается и южной точки (S), где UPS и сервер выключены.

При отключении электропитания система начинает свое движение на восток. Этот период обозначен желтым северо-восточным квадрантом. Его длительность задается параметром "After UPS has been on battery for (minutes)" в настройках "Power Failure" PCBE Console. Примечателен данный период тем, что если электропитание восстановится, система вернется на север и продолжит работу как ни в чем не бывало.

Восточная точка (E), таким образом, является точкой невозврата. В ней, при отсутствии питания, PowerChute Agent инициирует завершение работы сервера, и сервер будет выключен уже вне зависимости от появления напряжения в сети.

Продолжительность красного, юго-восточного периода определяется суммой значений "Operating System Delay" и "Operating System Duration" в настройках "Shutdown Sequence" PCBE Console. Это время отведенное на выполнение финальных командных файлов и завершение работы операционной системы. Естественно, эти значения должны быть выбраны с небольшим запасом.
Как отмечалось выше, электропитание может восстановиться во время завершения работы сервера. Это случай называется power race, и, чтобы обеспечить "проходимость" южной точки (S), т.е. избежать ситуации, когда UPS включен, а сервер - выключен, нужно соответствующим образом настроить и сервер и UPS.
В настройках BIOS сервера, в качестве состояния после восстановления питания, должно стоять значение "Power On" или "Always On". В PCBE Console настройка "Shutdown Type" должна быть установлена в значение "Shutdown and Off".

Если все настроено правильно, то при наличии электропитания в южной точке (S), UPS выключится, отключая от питания и сервер. Если по приходу в южную точку электропитание отсутствует, UPS выключится и будет ждать его восстановления. Так или иначе, сразу же или через некоторое время система двинется на запад.

В синем, юго-западном квадранте происходит подзарядка батарей и короткая задержка перед включением сервера. Ни того, ни другого может и не случиться если вы выставите параметры "Battery charges to" и "And the elapsed time is" в настройках "Power Failure" PCBE Console в нули. Однако делать этого я не рекомендую. Что касается задержки, то блок питания сервера только за счет разряжающихся конденсаторов может до пары десятков секунд поддерживать у BIOS уверенность в том, что питание еще не пропало. Как вы понимаете, в случае power race, ваша настройка "Power On" при таких обстоятельствах попросту не сработает.
К необходимому уровню заряда батарей перед включением сервера мы вернемся позже. Пока же замечу, что система не придет в западную точку (W) до тех пор пока и батареи не зарядятся до заданного уровня, и время задержки не истечет. Должны быть истинными оба условия. При этом отсчет задержки начинается вместе с началом подзаряда батарей.
Подобно поведению системы в северо восточном квадранте, при отключении электропитания во время подзарядки батарей и/или в течение интервала задержки, система возвращается в предыдущую точку (в данном случае - S).

Как и восточная точка, западная точка (W) является точкой невозврата. В ней происходит включение сервера и начинается загрузка операционной системы. Таким образом, если электропитание отключится в зеленом, северо-западном квадранте, то вернуться в безопасную точку S можно будет только пройдя три четверти круга (в наихудшем случае). Сервер будет загружаться на батареях до тех пор пока не загрузится PowerChute Agent и не определит, что электропитание отсутствует (точка N). Затем, на батареях же, система пройдет северо-восточный квадрант в течение "After UPS has been on battery for" минут. Затем, опять же на батареях, будет завершаться работа сервера на юго-востоке.
Надеюсь, теперь понятен смысл определенного уровня заряда батарей перед включением сервера? На разряженных батареях можно ведь и не дойти...

В заключение, небольшой пример расчета.

При текущей нагрузке мой UPS обещает поддерживать ее во включенном состоянии 19-20 минут за счет батарей.
Полная загрузка сервера, включая загрузку PowerChute Agent, занимает 9 минут. (СЗ)
Полное выключение сервера, включая задержку на выполнение командных файлов, 7 минут. (ЮВ)

Очевидно, что максимальное значение "After UPS has been on battery for" (СВ) не может быть больше 19 - 9 - 7 = 3 минут.
Также очевидно то, что при таких условиях батареи должны быть на 100% заряжены перед включением сервера.

(6 comments | Leave a comment)

May 12th, 2012


05:09 pm - ESXi 5.0 и Smart UPS на USB: корректное завершение работы

Писать о power race я начал не случайно. Это "жжж" неспроста (с). После виртуализации всего и вся, для меня настало время подумать о корректном завершении работы виртуальных машин и самого хоста ESXi по сигналу от UPS.

Нужно сказать, что вопрос этот не первый год будоражит умы. Решений - хороших и разных, не то что бы много, но они есть. Чаще конечно попадаются "разные", где вам предлагают развернуть vMA, настроить apcupsd и т.д. и т.п, но встречаются и православные shell-скрипты, работающие на стороне хоста. Последние выглядят как-то попроще, понароднее. Я и сам недавно изваял скрипт на стописят строк для корректного гашения виртуалок. Присмотрелся - ба! Дурная работа - такая дурная!

Тут вот ведь что выяснилось: некоторые, возможно, будут удивлены, но в каталоге /sbin хоста ESXi лежит файло poweroff, которое, не смотря на страшное название, работает совсем не так брутально как кажется. Вы не поверите, но /sbin/poweroff
корректно завершает работу всех запущенных виртуальных машин, причем, делает это в правильном порядке, определяемом настройками Virtual Machine Startup/Shutdown, и выключает хост.
Да, в интернете вы найдете, что /sbin/poweroff гасит хост и виртуалки жестко, попросту выключая питание. Но, по крайней мере у меня, в свежем лицензионном VMware vSphere 5 Essentials Bundle (VMKernel Release Build 623860) все происходит ровно так, как написано выше. Проверено електроникой. Особо недоверчивые могут перед /sbin/poweroff выполнить /sbin/shutdown.sh (присмотритесь к содержимому этого скрипта и скриптов, которые он вызывает).

Итак, для корректного завершения работы виртуальных машин и самого хоста достаточно установить куда-нибудь PuTTY и выполнить в командной строке:
C:\Program Files\PuTTY>plink root@host -pw password "nohup /sbin/poweroff &"
где host - имя или IP хоста ESXi, а password - соответственно, пароль рута.

Теперь рассмотрим практическую ситуацию. К хосту ESXi USB-шнурком подключен Smart UPS. С помощью USB-passthrough, он проброшен в одну из виртуальных машин хоста. На машине установлено соответствующее программное обеспечение. Ладно, не будем ходить вокруг да около, UPS - это APC Smart UPS 1500RM, программное обеспечение - APC PowerChute Business Edition 9.0.1, а виртуальная машина - Windows Server Standard 2003R2. Так будет еще нагляднее.

PowerChute позволяет перед завершением работы машины, на которую он установлен, запускать т.н. командные файлы. Делает он это своеобразно, к чему мы еще вернемся, а пока создадим один такой. В каталоге C:\Program Files\APC\PowerChute Business Edition\agent\cmdfiles заводим файл shutdownesxi.cmd со следующим содержимым:
@START "" "C:\Program Files\PuTTY\plink.exe" root@host -pw password "nohup /sbin/poweroff &"
PuTTY, понятно, установлен; смысл параметров host и password - тот же.

Чтобы PowerChute мог выполнить этот файл, нужно найти службу "APC PBE Agent" и разрешить ей взаимодействовать с рабочим столом (вкладка "Вход в систему" в свойствах службы). У меня на поиск такого простого (и, главное, очевидного) решения ушли часы, а вам эта инфа достается задаром(( Ок, проехали. Положим, все работает и PowerChute настроен на запуск shutdownesxi.cmd перед завершением работы системы. И вот, когда ну казалось бы уже все, уже пора кричать: "PROFIT!", выясняются некоторые моменты...

Хост не просыпается после power race... Та-дамм!!! А получается, по всей видимости, вот что: /sbin/poweroff гасит виртуальную машину, на которую установлен PowerChute, раньше чем PowerChute успевает сообщить о завершении работы системы UPS'у. Это догадка. Я не знаю наверняка, что там происходит между ними, но, если работу системы завершает не PowerChute Agent, а другой процесс, или даже пользователь с консоли, то UPS при power race не производит powerdown cycle, т.е. не отключает на короткое время нагрузку. Логично объяснить это тем, что он думает будто система продолжает работать.

Где же выход из этого исхода?(с) Очевидно, что необходимо дать агенту PowerChute самому завершить работу машины, к которой подключен UPS. Тут конечно же мне снова пришлось писать скрипт, но на этот раз не чрезмерный, а строк эдак в писят. Его нужно скачать отсюда, создать в корне datastore хоста ESXi каталог _UPS, положить скрипт туда и поставить на него права 0755. Соответственно, содержимое файла shutdownesxi.cmd, запускаемого PowerChute перед завершением работы, теперь будет выглядеть так:
@START "" "C:\Program Files\PuTTY\plink.exe" root@host -pw password "nohup ./vmfs/volumes/datastore1/_UPS/shutdownhost.sh &"

где datastore1 - имя вашего хранилища.

Коротко говоря, скрипт сначала ждет (но не более UPS_VM_SHUTDOWN_DURATION секунд) пока PowerChute Agent завершит работу виртуальной машины, к которой подключен UPS (UPS_VM_NAME), а затем выполняет все тот же /sbin/poweroff. Параметры UPS_VM_NAME (имя машины, как вы его видите в VMware vSphere Client) и UPS_VM_SHUTDOWN_DURATION нужно поправить под ваши нужды в теле самого скрипта. Своеобразие PowerChute при исполнении командных файлов пользователя заключается в том, что нет никакого способа задать "Operating System Delay" меньше одной минуты:



Логика там такова: сначала PowerChute выполняет командный файл в течение интервала "Command File Duration", а уже затем завершает работу операционной системы. Понятно, что по этой логике "Command File Duration" = "Operating System Delay", и если первое еще можно как-то там через Agent Web Interface снизить до секунд, то второе стоит колом и никаким регулировкам в сторону понижения ни через Agent Web Interface, ни через APC PowerChute Business Edition Console не поддается. Так что имейте ввиду, что UPS_VM_SHUTDOWN_DURATION - это та самая минута (Operating System Delay) + предельное время необходимое виртуальной машине, к которой подключен UPS, на завершение работы (т.е. этот параметр не может быть меньше Operating System Delay).

Это все, т.е. нет. Во-первых, раз уж в командном файле shutdownesxi.cmd в открытом виде лежит пароль рута хоста ESXi, то надо ограничить права на эту папку, чтобы никто - ничего. Второй момент в том, что раз уж /sbin/poweroff завершает работу виртуальных машин в порядке, определяемом настройками Virtual Machine Startup/Shutdown, логичным выглядит поставить UPS и PowerChute на машину, запускаемую при автостарте последней, т.к. Shutdown выполняется в обратном порядке, и такая настройка будет больше соответствовать логике скрипта.

(16 comments | Leave a comment)

April 16th, 2012


08:52 pm - Power Race


Ситуация, когда напряжение возвращается в сеть во время завершения работы компьютера по сигналу от UPS, называется "power race". Разные модели UPS отрабатывают ее по-разному. Если у вас сервер, который должен быть включен постоянно, то в зависимости от модели UPS он может как включиться опять, так остаться выключенным, даже не смотря на настройки Power state after failure: Power On в BIOS. Фактически, простой UPS так никогда и не отключает нагрузку (ведь напряжение вернулось), а значит, с точки зрения сервера, никакого Power failure не происходит и он, корректно завершив работу, так и остается выключенным. Продвинутые UPS напротив совершают полный shutdown/powerdown cycle, т.е. по истечении времени отведенного на завершение работы компьютера, кратковременно отключают нагрузку, не смотря на то, что напряжение вернулось. С точки зрения BIOS компьютера происходит Power failure и когда UPS опять подключает нагрузку, сервер включается. Вот две сравнимых по цене модели:

Первая, от именитого производителя, не включит ваш сервер при power race, а вторая - включит (не реклама). Видимо, следует обращать внимание на волшебное слово "Smart" в названии модели.

Что же делать, если ваш UPS isn't so Smart? Делать WoL уснувшего сервера с какого-то другого оборудования подключенного к умному UPS, либо не подключенного к UPS вообще.


(1 comment | Leave a comment)


> Go to Top
LiveJournal.com