Apagado correcto del hipervisor VMWare ESXi con nivel crítico de carga de la batería del SAI APC

Hay muchos artículos sobre cómo configurar PowerChute Business Edition y cómo conectarse a VMWare desde PowerShell, pero no he encontrado todo eso en un solo lugar, con una descripción de los detalles finos. Y los hay.

1. Introducción

A pesar de que tenemos cierta relación con la energía, a veces surgen problemas con la electricidad. Aquí es donde entran los SAI, pero sus baterías, lamentablemente, no son duraderas. ¿Qué hacer? ¡Apagar!

Mientras todos los servidores eran físicos, las cosas iban bastante bien, PowerChute Business Edition nos salvaba. Gratis, para 5 servidores, lo que era suficiente. En una máquina se instaló el agente, el servidor y la consola. Al acercarse el final, el agente simplemente ejecutaba un archivo por lotes, en el que se enviaba shutdown.exe /s /m a los servidores vecinos, y luego apagaba su propio sistema operativo. Todos están bien.
Luego llegó el momento máquinas virtuales.

2. Datos de partida y reflexiones

Entonces, ¿qué tenemos? Poco: un servidor físico con Windows Server 2008 R2 y un hipervisor con varias máquinas virtuales, entre las cuales hay Windows Server 2019, Windows Server 2003 y CentOS. Y también un SAI – APC Smart-UPS.

Hemos oído hablar de NUT, pero hasta ahora no hemos tenido tiempo para estudiarlo, solo hemos utilizado lo que había a mano, es decir, PowerChute Business Edition.

El hipervisor puede apagar sus máquinas virtuales por sí mismo, solo queda informarle que es hora. Existe una herramienta útil llamada VMWare.PowerCLI, que es una extensión para Windows Powershell, que permite conectarse al hipervisor y comunicarse lo que sea necesario. También hay muchos artículos sobre la configuración de PowerCLI.

3. Proceso

El SAI fue físicamente conectado al puerto COM del servidor 2008, por suerte lo tenía. Aunque esto no es crítico, se podría conectar a cualquier servidor Windows virtual mediante un convertidor de interfaz (MOXA). A partir de aquí, todas las acciones se realizan en la máquina a la que está conectado el SAI: Windows Server 2008, a menos que se indique lo contrario. En ella se instaló el agente de PowerChute Business Edition. Aquí se encuentra el primer detalle sutil: el servicio del agente debe ejecutarse no como sistema, sino como un usuario, de lo contrario el agente no podrá ejecutar el archivo cmd.

Luego instalamos .Net Framework 4.7. Aquí se requiere un reinicio, incluso si el framework no lo solicita explícitamente después de la instalación, de lo contrario no avanzará. Después pueden llegar actualizaciones, también hay que instalarlas.

Luego instalamos PowerShell 5.1. También se requiere un reinicio, incluso si no lo solicita.
A continuación, se instala PowerCLI 11.5. Es una versión bastante nueva, por lo que los requisitos anteriores se aplican. Se puede hacer a través de Internet, hay muchos artículos sobre esto, pero ya lo habíamos descargado, así que simplemente copiamos todos los archivos en la carpeta Modules.

Verificado:

Get-Module -ListAvailable

Ok, vemos que se instaló:

Import-Module VMWare.PowerCLI

Sí, la consola de Powershell está ejecutándose como Administrador.

Configuraciones de Powershell.

• Permitir la ejecución de cualquier script:

Set-ExecutionPolicy Unrestricted

• O permitir solo ignorar los certificados de scripts:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 

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

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

• Suprimir el mensaje de PowerCLI sobre la participación en el programa de intercambio de experiencia, de lo contrario habrá muchos mensajes innecesarios en el registro:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

• Guardar las credenciales del usuario para iniciar sesión en el host de VMWare, para no mostrarlas explícitamente en el script:

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

La verificación mostrará a quién hemos guardado:

Get-VICredentialStoreItem

También se puede comprobar la conexión: Connect-VIServer address.

El script en sí, por ejemplo: nos conectamos, apagamos, por si acaso nos desconectamos, hay diferentes opciones:

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

4. Default.cmd

Ese archivo por lotes que se ejecuta mediante el agente APC. Se encuentra en “C:Program Files[(x86)]APCPowerChute Business Editionagentcmdfiles”, y dentro:

«C:Windowssystem32WindowsPowerShellv1.0powershell.exe» -File «C:…shutdown_hosts.ps1»
Parece que hemos configurado y verificado todo, incluso ejecutamos cmd - se está ejecutando correctamente, apaga.

Ejecutamos desde la consola APC la verificación del archivo por lotes (hay un botón de Prueba) - no funciona.

Aquí está, ese momento incómodo, cuando todo el trabajo realizado no sirvió para nada.

5. Catarsis

Miramos el administrador de tareas, vemos - cmd apareció brevemente, powershell apareció brevemente. Miramos más de cerca - cmd *32 y, por lo tanto, powershell *32. Entendemos que el servicio del agente APC es de 32 bits, por lo que está ejecutando la consola correspondiente.

Ejecutamos powershell x86 como administrador, realizamos una vez más la instalación y configuración de PowerCLI del punto 3.

Y cambiamos la línea de llamada a powershell:

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

6. ¡Final feliz!

Fuente: habr.com