Existem muitos artigos por aí sobre como configurar o PowerChute Business Edition e como conectar-se ao VMWare a partir do PowerShell, mas de alguma forma não consegui encontrar tudo isso em um só lugar, com uma descrição dos pontos sutis. Mas eles existem.
1. Introdução
Apesar de termos alguma ligação com a energia, por vezes surgem problemas com a eletricidade. É aqui que o no-break entra em ação, mas suas baterias, infelizmente, não duram muito. O que fazer? Desligar!
Embora todos os servidores fossem físicos, as coisas estavam indo bem, o PowerChute Business Edition nos ajudou. Gratuito, para 5 servidores, o que foi suficiente. Um agente, servidor e console foram instalados em uma máquina. À medida que o fim se aproximava, o agente simplesmente executou um arquivo de comando que enviou shutdown.exe /s /m para servidores vizinhos e, em seguida, desligou seu sistema operacional. Todo mundo está vivo.
Então chegou a hora das máquinas virtuais.
2. Antecedentes e reflexões
O que temos então? Nada: 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 outro UPS – APC Smart-UPS.
Ouvimos falar do NUT, mas ainda não estudamos; usamos apenas o que estava em mãos, ou seja, o PowerChute Business Edition.
O hipervisor pode desligar ele mesmo suas máquinas virtuais; tudo o que resta é dizer que chegou a hora. Existe uma coisa tão útil VMWare.PowerCLI, esta é uma extensão para Windows Powershell que permite conectar-se ao hipervisor e contar tudo o que você precisa. Também existem muitos artigos sobre configurações do PowerCLI.
3. Processo
O UPS estava fisicamente conectado à porta de comunicação do servidor de 2008, felizmente estava lá. Embora isso não seja importante - foi possível conectar-se através de um conversor de interface (MOXA) a qualquer servidor virtual do Windows. Além disso, todas as ações são executadas na máquina à qual o UPS está conectado - Windows Server 2008, salvo indicação explícita em contrário. O agente PowerChute Business Edition foi instalado nele. Aqui está o primeiro ponto sutil: o serviço do agente não deve ser iniciado a partir do sistema, mas do usuário, caso contrário o agente não poderá executar o arquivo cmd.
Em seguida instalamos o .Net Framework 4.7. Uma reinicialização é necessária aqui, mesmo que a estrutura não o solicite explicitamente após a instalação, caso contrário, não irá mais longe. Depois, ainda podem vir atualizações, que também precisam ser instaladas.
Em seguida, instalamos o PowerShell 5.1. Também requer uma reinicialização, mesmo que ele não pergunte.
Em seguida, instale o PowerCLI 11.5. Uma versão bastante recente, daí os requisitos anteriores. Você pode fazer isso pela Internet, existem muitos artigos sobre isso, mas já baixamos, então apenas copiamos todos os arquivos para a pasta Módulos.
Verificado:
Get-Module -ListAvailableOk, vemos que instalamos:
Import-Module VMWare.PowerCLISim, o console Powershell é obviamente iniciado como Administrador.
Configurações do PowerShell.
- Permitir a execução de qualquer script:
Set-ExecutionPolicy Unrestricted- Ou você só pode permitir que os certificados de script sejam ignorados:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned - Permita que o PowerCLI se conecte a servidores com certificados inválidos (expirados):
Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false- Suprima a saída da mensagem PowerCLI sobre a adesão ao programa de troca de experiências, caso contrário, haverá muitas informações desnecessárias no log:
Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false- Salve as credenciais do usuário para fazer login no host VMWare para não mostrá-las explicitamente no script:
New-VICredentialStoreItem -Host address -User user -Password 'password'A verificação mostrará quem salvamos:
Get-VICredentialStoreItemVocê também pode verificar a conexão: Endereço Connect-VIServer.
O script em si, por exemplo: conectado, desligado, desconectado por precaução, as seguintes opções são possíveis:
Connect-VIserver -Server $vmhost
Stop-VMHost $vmhost -force -Confirm:$false
Disconnect-VIserver $vmhost -Confirm:$false
4. Padrão.cmd
O mesmo arquivo em lote iniciado pelo agente APC. Ele está localizado em “C:Arquivos de Programas[ (x86)]APCPowerChute Business Editionagentcmdfiles”, e dentro de:
"C:Windowssystem32WindowsPowerShellv1.0powershell.exe" -Arquivo "C:...shutdown_hosts.ps1"
Parece que tudo foi configurado e verificado, até lançamos o cmd - funciona corretamente, desliga.
Executamos um arquivo de comando test no console APC (há um botão Testar lá) - não funciona.
Aqui está, aquele momento estranho em que todo o trabalho realizado não levou a nada.
5. Catarse
Olhamos para o gerenciador de tarefas, vemos flashes de cmd, flashes de powershell. Vamos dar uma olhada mais de perto - cmd *32 e, consequentemente, powershell *32. Nós entendemos isso O serviço do agente APC é de 32 bits, o que significa que executa o console correspondente.
Iniciamos o PowerShell x86 como administrador e instalamos e configuramos o PowerCLI a partir da etapa 3 novamente.
Bem, vamos mudar a linha de chamada do PowerShell:
"C:Windows<b>SysWOW64</b>WindowsPowerShellv1.0powershell.exe…6. Final feliz!
Fonte: habr.com