Encerramento correto do hipervisor VMWare ESXi ao atingir nível crítico de carga da bateria do UPS APC

Há muitos artigos sobre como configurar o PowerChute Business Edition e como se conectar ao VMWare a partir do PowerShell, mas não encontrei tudo isso em um só lugar, com descrições dos detalhes. E eles existem.

1. Introdução

Apesar de termos alguma relação com energia, problemas elétricos às vezes surgem. É aqui que um no-break (IBP) entra em cena, mas suas baterias, infelizmente, não são duráveis. O que fazer? Desligar!

Enquanto todos os servidores eram físicos, as coisas iam bem, o PowerChute Business Edition nos salvava. Gratuito, para 5 servidores, o que era mais do que suficiente. Em uma máquina, um agente, servidor e console foram instalados. Quando a hora se aproximava, o agente simplesmente executava um arquivo em lote que enviava shutdown.exe /s /m para os servidores vizinhos, e então desligava seu sistema operacional. Todos estavam vivos.
Depois, chegou a hora máquinas virtuais.

2. Dados e reflexões

Então, o que temos? Nada de mais – um servidor físico com Windows Server 2008 R2 e um hipervisor com várias máquinas virtuais, incluindo Windows Server 2019, Windows Server 2003 e CentOS. E ainda um no-break – APC Smart-UPS.

Sabíamos sobre o NUT, mas ainda não tivemos tempo para estudá-lo, usávamos apenas o que estava à mão, ou seja, o PowerChute Business Edition.

O hipervisor é capaz de desligar suas máquinas virtuais, só resta informá-lo que é hora. Existe uma ferramenta útil chamada VMWare.PowerCLI, que é uma extensão para o Windows PowerShell, que permite conectar-se ao hipervisor e informá-lo de tudo que precisa. Também há muitos artigos sobre a configuração do PowerCLI por aí.

3. Processo

Conectamos fisicamente o no-break ao porta COM do servidor 2008, felizmente ele estava disponível. Embora isso não seja essencial – poderia ser conectado via um conversor de interfaces (MOXA) a qualquer servidor Windows virtual. Todas as ações subsequentes são realizadas na máquina ao qual o no-break está conectado – Windows Server 2008, a menos que especificado de outra forma. Instalamos o agente PowerChute Business Edition nele. Aqui está o primeiro ponto delicado: o serviço do agente precisa ser executado não pelo sistema, mas por um usuário, caso contrário, o agente não consegue executar o arquivo cmd.

Em seguida, instalamos o .Net Framework 4.7. Isso requer reinicialização, mesmo que o framework não solicite explicitamente após a instalação, caso contrário, não prosseguirá. Depois, podem surgir atualizações, que também precisam ser instaladas.

Em seguida, instalamos o PowerShell 5.1. Isso também requer reinicialização, mesmo que não solicite.
Em seguida, a instalação do PowerCLI 11.5. Uma versão bastante recente, daí os requisitos anteriores. Pode-se fazer pela internet, existem muitos artigos sobre isso, mas já tínhamos baixado, então apenas copiamos todos os arquivos para a pasta Modules.

Verificado:

Get-Module -ListAvailable

Ok, vemos que foi instalado:

Import-Module VMWare.PowerCLI

Sim, o console do Powershell está, claro, executado como Administrador.

Configurações do Powershell.

• Permitir a execução de quaisquer scripts:

Set-ExecutionPolicy Unrestricted

• Ou permitir apenas ignorar os certificados de scripts:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 

• Permitir que o PowerCLI se conecte a servidores com certificados inválidos (expirados):

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

• Suprimir a mensagem de saída do PowerCLI sobre participar do programa de compartilhamento de experiências, caso contrário, haverá muita informação desnecessária no log:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

• Salvar as credenciais do usuário para acessar o host VMWare, para não expô-las explicitamente no script:

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

A verificação mostrará o que salvamos:

Get-VICredentialStoreItem

Também pode-se verificar a conexão: Connect-VIServer address.

O próprio script, por exemplo: conectou, desligou, por precaução desconectou-se, existem várias opções:

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

4. Default.cmd

Aquele arquivo de comando que é executado pelo agente APC. Está em “C:Program Files[(x86)]APCPowerChute Business Editionagentcmdfiles”, e dentro:

«C:Windowssystem32WindowsPowerShellv1.0powershell.exe» -File «C:…shutdown_hosts.ps1»
Parece que tudo foi configurado e verificado, até executamos o cmd - funciona corretamente, desliga.

Executamos da console do APC a verificação do arquivo de comando (tem um botão Test) - não funciona.

Aqui está aquele momento embaraçoso, quando todo o trabalho feito não levou a nada.

5. Catarsis

Vemos o gerenciador de tarefas, notamos - o cmd apareceu rapidamente, apareceu o powershell. Observamos com mais atenção – cmd *32 e, consequentemente, powershell *32. Entendemos que o serviço do agente APC é de 32 bits, e portanto, ele executa o console correspondente.

Executamos o powershell x86 como administrador, fazemos novamente a instalação e configuração do PowerCLI do ponto 3.

E mudamos a linha de chamada do powershell:

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

6. Final feliz!

Fonte: habr.com