Можно использовать например ghettoUPSHostShutdown.pl, но можно использовать и PowerCLI.
Что для этого требуется:
- Иметь Windows хост (или ВМ), следящую за ИБП. Как вариант - повесить эту задачу на vCenter (если он физический).
- При пропадании питания вызвать скрипт, который погасит инфраструктуру.
- При восстановлении питания поднять инфраструктуру, а затем ВМ.
Итак, вариант 1. vCenter расположен на физической машине.
Get-VM | Where-Object {$_.PowerState -eq "PoweredOn" -and $_.Guest.State -eq "Running"} | Shutdown-VMGuest Start-Sleep -Seconds 300 Get-VM | Where-Object {$_.PowerState -eq "PoweredOn"} | Stop-VM -RunAsync Start-Sleep -Seconds 60 Get-VMHost | ForEach-Object { Set-VMHost -vmhost $_ -state maintenance Stop-VMHost -vmhost $_ -RunAsync }Вариант 2. vCenter расположен на виртуальной машине. В этом случае сначала выключаем vCenter, чтобы избежать потенциального влияния DRS. Например так:
Get-VM -Name "vCenter" | %{ if ($_.PowerState -eq "PoweredOn") { if ($_.Guest.State -eq "Running") { Shutdown-VMGuest } else { Stop-VM -RunAsync } } }Можно использовать cтандартные средства Windows:
shutdown /s /t 0 /m \\vcenterИ для каждого физического хоста вызываем такой скрипт:
Get-VM | Where-Object {$_.PowerState -eq "PoweredOn" -and $_.Guest.State -eq "Running"} | Shutdown-VMGuest Start-Sleep -Seconds 300 Get-VM | Where-Object {$_.PowerState -eq "PoweredOn"} | Stop-VM -RunAsync Start-Sleep -Seconds 60 Get-VMHost | Stop-VMHost -RunAsyncЕсть вариации на тему автоматического рестарта ВМ при восстановлении питания, однако на мой взгляд это может привести к проблемам, если не учитывать взаимные зависимости ВМ и отправить в массовый старт пару сотен виртуальных машин. С другой стороны, никто не мешает автоматически поднять только vCenter и инфраструктурные машины типа контроллеров домена и DNS (если нет физических), а затем вызвать ваш собственный скрипт для поднятия всех машин в нужном вам порядке и с нужными вам задержками.
В качестве UPS подразумеваются исключительно девайсы с сетевым интерфейсом?
ОтветитьУдалитьНасколько, по вашему мнению, такой вариант надежен как enterprise решение по сравнению с тем же ghettoUPSHostShutdown.pl и\или платному решению от APC? Спасибо.
ОтветитьУдалитьАндрей Вахитов, выше только скрипт, который запускается по сигналу бесперебойника. Каким образом получать сигнал, по сети ли, юсб или serial дело другое. Ясно одно - юсб пробросить в виртуальную среду возможности нет.
ОтветитьУдалитьАнонимный, моей целью в данном случае не была разработка сверхнадежного Enterprise решения, а лишь демострация как это можно сделать на PowerShell.
ОтветитьУдалитьО пробросе USB подробно тут: http://blog.vadmin.ru/2010/04/usb.html
+ по слухам через месяц-два проброс USB штатными средствами появится в vSphere 4.1
Anton,ок, а можно поинтересоваться с какими работающими решениями вы сталкивались? Неужели все используют ghettoUPSHostShutdown.pl?
ОтветитьУдалитьМне интересно почему эта тема так мало освещена и готовых решений практически нет.
Лично я вообще ни с чем не сталкивался, у нас стоят БОЛЬШИЕ упсы и ДГУ.
ОтветитьУдалитьТема навеяна обсуждением на форуме VMware: http://communities.vmware.com/thread/260468?tstart=0
а вот Microsoft Hyper-V умеет это делать стандартными средствами =)
ОтветитьУдалитьНу хоть один плюс у Hyper-V нашелся.
ОтветитьУдалитьКстати, Hyper-V или все таки SCVMM?
А вот интересный аспект данного вопроса (так до сих пор мной и не разрешенный): скрипт на PowerCLI затруднений не вызвал - написал именно такой, какой нужен был лично для меня. Проверил - работает. Чудесно. Написал пакетник, который вызывает PowerShell - PowerCLI - скрипт. Шмякнул руками по нему - прекрасно работает. Ну, ерунда осталась: берем монитор UPSника, настраиваем, указываем ему наш пакетник, который он должен запустить перед отключением. Пробуем - не работает. Клиническая картина: процесс PowerShell запустился, однако повис ничего не делая. Сначала думал, что дело в том, что он запускается под SYSTEM. Нашел cpau, пробовал с ним - то же самое: PowerShell под админом в процессах без признаков жизни...
ОтветитьУдалитьПришлось порыться в процессах, и обнаружилось (очевидная, в принципе, вещь, но сразу как-то не догнал...), что при ручном запуске пакетника процесс PowerShell является дочерним процесса explorer, и, как следствие, PowerShell в Security имеет группу NT AUTHORITY\интерактивные и наш PowerShell благополучно порождает всеразличные потоки. Если же пакетник запускается программой монитора UPS, то PowerShell является дочерним процесса services и, как следствие, в Security вместо NT AUTHORITY\интерактивные имеет NT AUTHORITY\служба. В результате процесс PowerShell висит в памяти и никаких потоков, естественно, не порождает. Разобраться-то я с этим разобрался, но вот что теперь делать - ума не приложу... Скрипт есть рабочий, выбрасывать жалко, как заставить сработать PowerShell под services - не знаю... В общем - чемодан без ручки...