Apagado elegante do hipervisor VMWare ESXi no nivel de batería crítico do UPS APC

Hai moitos artigos sobre como configurar PowerChute Business Edition e como conectarse a VMWare desde PowerShell, pero de algunha maneira non puiden atopar todo isto nun só lugar, cunha descrición dos puntos sutís. Pero existen.

1. Introdución

A pesar de que temos algunha conexión coa enerxía, ás veces xorden problemas coa electricidade. Aquí é onde entra en xogo o UPS, pero as súas baterías, por desgraza, non duran moito. Que facer? Apagar!

Aínda que todos os servidores eran físicos, as cousas ían ben, PowerChute Business Edition axudounos. Gratuíto, para 5 servidores, que foi bastante. Nunha máquina instaláronse un axente, un servidor e unha consola. Cando se achegaba o final, o axente simplemente executou un ficheiro de comandos que enviou shutdown.exe /s /m aos servidores veciños e, a continuación, apagou o seu sistema operativo. Todo o mundo está vivo.
Despois chegou o momento das máquinas virtuais.

2. Antecedentes e reflexións

Entón, que temos? Nada de nada: un servidor físico con Windows Server 2008 R2 e un hipervisor con varias máquinas virtuais, incluíndo Windows Server 2019, Windows Server 2003 e CentOS. E outro UPS: APC Smart-UPS.

Escoitamos falar de NUT, pero aínda non puxemos por estudalo; só usamos o que estaba a man, é dicir, PowerChute Business Edition.

O hipervisor pode apagar as súas máquinas virtuais por si mesmo; só queda dicirlle que é o momento. Hai unha cousa tan útil VMWare.PowerCLI, esta é unha extensión para Windows Powershell que che permite conectarte ao hipervisor e dicirlle todo o que necesitas. Tamén hai moitos artigos sobre a configuración de PowerCLI.

3. Proceso

O UPS estaba conectado fisicamente ao porto de comunicación do servidor de 2008, afortunadamente estaba alí. Aínda que isto non é importante, pode conectarse mediante un conversor de interfaces (MOXA) a calquera servidor virtual de Windows. Ademais, todas as accións realízanse na máquina á que está conectado o SAI, Windows Server 2008, a non ser que se indique expresamente o contrario. Instalouse nel o axente PowerChute Business Edition. Aquí está o primeiro punto sutil: o servizo de axente debe iniciarse non desde o sistema, senón desde o usuario, se non, o axente non poderá executar o ficheiro cmd.

A continuación instalamos .Net Framework 4.7. Aquí é necesario un reinicio, aínda que o marco non o solicite explícitamente despois da instalación, se non, non irá máis lonxe. Despois, aínda poden chegar as actualizacións, que tamén deben instalarse.

A continuación instalamos PowerShell 5.1. Tamén require un reinicio, aínda que non o pregunte.
A continuación, instale PowerCLI 11.5. Unha versión bastante recente, de aí os requisitos anteriores. Podes facelo a través de Internet, hai moitos artigos sobre isto, pero xa o descargamos, polo que acabamos de copiar todos os ficheiros na carpeta Módulos.

Comprobado:

Get-Module -ListAvailable

Ok, vemos que instalamos:

Import-Module VMWare.PowerCLI

Si, a consola Powershell, por suposto, lanzase como administrador.

Configuración de Powershell.

• Permitir a execución de calquera script:

Set-ExecutionPolicy Unrestricted

• Ou só pode permitir que se ignoren os certificados de script:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 

• Permitir que PowerCLI se conecte a servidores con certificados non válidos (caducados):

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

• Suprimir a saída da mensaxe de PowerCLI acerca de unirse ao programa de intercambio de experiencias, se non, haberá moita información innecesaria no rexistro:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

• Garda as credenciais do usuario para iniciar sesión no host VMWare para non mostralas explícitamente no script:

New-VICredentialStoreItem -Host address -User user -Password 'password'

Ao comprobar, mostrarase quen gardamos:

Get-VICredentialStoreItem

Tamén pode comprobar a conexión: enderezo Connect-VIServer.

O propio script, por exemplo: conectado, desactivado, desconectado por se acaso, son posibles as seguintes opcións:

    Connect-VIserver -Server $vmhost 
    Stop-VMHost $vmhost -force -Confirm:$false 
    Disconnect-VIserver $vmhost -Confirm:$false

4. Por defecto.cmd

O mesmo ficheiro por lotes que inicia o axente de APC. Atópase en "C:Arquivos de programas[(x86)]APCPowerChute Business Editionagentcmdfiles" e dentro:

"C:Windowssystem32WindowsPowerShellv1.0powershell.exe" -Ficheiro "C:...shutdown_hosts.ps1"
Parece que todo estaba configurado e comprobado, incluso lanzamos cmd: funciona correctamente, apágao.

Realizamos unha proba do ficheiro de comandos desde a consola APC (hai un botón de proba alí) - non funciona.

Aquí está, ese momento incómodo no que todo o traballo feito non levou a nada.

5. Catarse

Miramos o xestor de tarefas, vemos flashes de cmd, flashes de powershell. Vexamos máis de cerca: cmd *32 e, en consecuencia, powershell *32. Entendemos iso O servizo de axente de APC é de 32 bits, o que significa que executa a consola correspondente.

Lanzamos powershell x86 como administrador e instalamos e configuramos PowerCLI desde o paso 3 de novo.

Ben, imos cambiar a liña de chamada de Powershell:

"C:Windows<b>SysWOW64</b>WindowsPowerShellv1.0powershell.exe…

6. Final feliz!

Fonte: www.habr.com