Desligamento do VMware ESXi acionado pelo APC UPS conectado via USB

Estou enviando vários servidores ESXi 5.1 para escritórios remotos, onde eles serão alimentados via APC UPS.

Gostaria que o no-break desencadeasse um desligamento do servidor conectado - eu confiaria na configuração do ESXi para cuidar do desligamento / suspensão das VMs hospedadas nele.

Percebo que a APC tem uma solução documentada usando o PowerChute Network Shutdown , mas isso envolve a configuração de um servidor extra por escritório e requer placas de rede em cada no-break. Geralmente, usamos UPS sem uma placa de rede (por exemplo, Back-UPS Pro) - eles vêm com um conector USB e estão prontamente disponíveis nos locais onde estão nossos escritórios.

Como conectar um no-break a um host ESXi via USB, para que o ESXi detecte uma queda de energia e aja de acordo? Alguém já conseguiu fazer isso.

De acordo com a APC, isso não é possível e você precisa desligar a Powerchute Network. Tentamos isso várias vezes com USB e não encontramos solução.

O VMWare tem informações aqui sobre o uso da solução aprovada pela APC.

Também pensaria que o SmartUPS seria uma escolha melhor e você pode caber na placa de rede. Naturalmente mais dinheiro, mas se seus servidores são importantes, esse custo deve valer a pena. Também oferece mais monitoramento e alerta, o que pode ser útil em um site remoto. Você também precisa garantir um tempo de execução suficiente para que todas as VMs desliguem corretamente e depois o host

Sim é possivel. Aqui estão os detalhes da minha configuração semelhante.

Configuração de hardware: APC Smart-UPS 1500 conectado ao host ESXi 5.1 via USB. Uma máquina virtual Linux em execução neste host ESXi. O no-break está conectado a esta VM usando a opção de passagem ESXi USB.

Configuração do software: mestre NUT (Network UPS Tools) em execução na VM e escravo nativo do ESXi NUT em execução no host ESXi.

Lógica de desligamento: a VM está executando o driver usbhid-ups do UPS, responsável pela comunicação com o UPS via USB. O processo upsd se conecta ao no-break através do driver usbhid-ups e monitora o estado do no-break. O processo mestre upsmon em execução na mesma máquina se conecta ao upsd e inicia o desligamento. O host ESXi está executando a segunda instância do upsmon, que também se conecta à mesma upsd da VM via rede interna.

Na falta de energia, ocorre a seguinte sequência:

1. O UPS via usbhid-ups informa ao upsd sobre falha de energia.
2. (opcional, útil se você quiser desligar em alguns minutos em vez de bateria fraca), o upsmon na VM inicia o timer de 5 minutos com upschedched . O temporizador é interrompido se a energia for restaurada.
3. Quando o timer dispara ou quando o no-break relata bateria fraca, o upsmon eleva o sinalizador FSD (desligamento forçado) para upsd.
4. Em uma configuração NUT independente, o sinalizador FSD desligaria a máquina. Mas aqui o comando shutdown é substituído por um log simples como "Eu deveria encerrar agora, mas estou aguardando o host". E não faz nada.
5. O sinalizador FSD também é lido pelo ESXi upsmon, que inicia o desligamento do host ESXi.
6. O host ESXi encerra todas as máquinas virtuais uma a uma. O importante é que a VM que executa o upsd deve ser desligada por último (usando a configuração de sequência de inicialização / desligamento do ESXi).
7. Importante: esta VM deve ter as ferramentas vmware instaladas. Quando recebe o comando guest shutdown do host, o script vmware-tools shutdown está sendo iniciado. Este script verifica o sinalizador / etc / killpower . Se nenhum sinalizador, ele não faz nada (isso significa que o usuário desligou o Linux, não o evento UPS). Mas se o sinalizador existir (FSD ativo), esse script envia ao no-break o comando de desligamento atrasado (digamos, em 3 minutos).
8. Após executar o script vmware-tools, a VM convidada é encerrada.
9. O ESXi vê o último estado de desligamento da VM e fica inativo (leva cerca de 1 minuto, porque não há outras máquinas em execução no momento).
10. Nos 2 minutos restantes, o no-break corta a energia.
11. Quando a energia é restaurada, o ESXi inicia e liga todas as VMs. A máquina de monitoramento do no-break deve ser iniciada primeiro (a mesma configuração que para a ordem de desligamento).

Transferências:

O NUT para Linux pode ser instalado a partir do pacote.

O cliente NUT nativo para servidor ESXi pode ser baixado usando o último link nesta página: http://www.networkupstools.org/download.html

Alguns dos meus scripts e arquivos conf estão aqui (apenas as linhas alteradas são mostradas): http://pastebin.com/KkEeanK1

Notas:

É claro que há mais detalhes, e levou algum tempo para eu fazer isso funcionar como deveria. Mas agora ele funciona muito bem. Esse sistema contabiliza os casos em que você apenas encerra a VM de monitoramento de dentro (o script vmware-tools não é executado) ou se é um host ESXi iniciado pelo encerramento da VM (sem sinalizador / etc / killpower, portanto, nenhum UPS descarrega) ou se for um desligamento do ESXi (o mesmo). O único importante é ter essa VM executando o mais rápido possível após a inicialização do host e desligá-la por último (para que o tempo de inatividade do host seja previsível - como dito acima, são cerca de 1 minuto para mim e mais 2 minutos que reservo apenas por precaução).

O meu UPS monitorando a VM do Linux também é um servidor de compartilhamento Samba / NFS para armazenamento de backup, o servidor NAT / DHCP para VMs e alguns outros serviços leves. São necessários cerca de 22 MHz de compartilhamentos de CPU ESXi e cerca de 10 MB de RAM ativa quando ociosos. Devido ao uso da NUT, é possível alimentar mais dispositivos do mesmo no-break, se necessário, e todos eles podem ser desligados normalmente. Não é necessário PowerChute e / ou caro Placa de Monitor de Rede.

Super pergunta. Na verdade, é possível fazer isso muito bem - pelo menos em algumas configurações. Eu tentei a seguinte receita em vários hosts ESXi 5.5. Basicamente, a solução é assim:

1. Habilite o acesso SSH no seu host ESXi
2. Crie uma VM Linux - eu uso o Ubuntu. Você só precisa de uma configuração mínima - sem GUI nem nada.
3. Conecte seu dispositivo APC via USB ao host ESXi e passe-o para a VM do Linux.
   • Certifique-se de que o controlador USB adicionado à VM corresponda ao controlador USB físico real ao qual o dispositivo APC está conectado, ou seja, adicione apenas um controlador XHCI se o dispositivo físico for um dispositivo USB3. As incompatibilidades parecem causar problemas estranhos no driver de dispositivo USB do Linux.
   • Se as coisas não estão funcionando e você vê erros como ctrl urb status -62em dmesg, as chances são o controlador físico não corresponde a um em sua VM. Se eles combinam - bem, então é um problema. Eu tenho uma configuração com esse tipo de problema e nenhuma solução real para isso.
4. Instale apcupsdna VM do Linux - no Ubuntu, você pode fazer sudo apt-get install apcupsdpara instalar a versão mais recente. O projeto NUT também é bom, mas sou tradicionalista.
5. Instale o utilitário plink executando sudo apt-get install putty-tools
6. Conecte-se ao seu host ESXI fazendo plink root@<your ESXi host IP>. Você pode fechar a conexão imediatamente. O objetivo é salvar a chave do host para que o plink não a solicite novamente quando a executarmos por meio de um script
7. Edite /etc/apcupsd/apcupsd.confe altere os itens abaixo para que correspondam: UPSNAME < the name you'd like your UPS to have > UPSCABLE usb UPSTYPE usb # DEVICE DIRECTIVE should be blank for USB DEVICE verifique também se /etc/default/apcupsdháISCONFIGURED=yes
8. Edite /etc/apcupsd/apccontrole role para o doshutdowncaso. Faça com que fique assim: doshutdown) echo "UPS ${2} initiated Shutdown Sequence" | ${WALL} # Shut down indirectly by triggering the ESXi host to do the # shutdown via VMWare tools /usr/bin/plink root@< your ESXi host IP > -pw < your root pw > "/sbin/shutdown.sh && /sbin/poweroff" ;;
9. Reinicie o apcupsd usando sudo service apcupsd restarte veja se as coisas estão funcionando invocando apcaccess. Caso contrário, verifique os logs e o dmesg
10. Verifique se todas as VMs que precisam desligar bem em caso de falha de energia têm o VMWare Tools instalado. Verifique também se eles fazem parte da lista de inicialização / desligamento da VM (no vSphere Web Client, vá para vCenter -> <your host> -> Manage -> Settings -> VM Startup/Shutdown:). Certifique-se de que a ação de desligamento seja desligar o SO convidado.

Depois de executar essas coisas, o doshutdownscriptlet da etapa 8 é chamado em uma falha de energia. Por sua vez, invoca o script shutdown.sh no host ESXi, que sinaliza o pacote VMWare Tools em cada VM do host para fazer um desligamento limpo por meio do sistema operacional convidado. Na minha experiência, ele funciona melhor que o software PowerChute da APC.

Se você gosta de monitorar coisas de suas VMs, pode configurar instâncias de escravo apcupsd nelas que se conectam à UPS principal controlam a VM Linux. Seus arquivos escravos apcupsd.conf devem ter uma entrada como esta:
UPSTYPE net < your UPS control VM IP >:3551
Entradas como UPSCABLEe outras não importam neste caso. Isso funciona com a versão do Windows apcupsd(disponível aqui ) também. Você pode usar o incluído apctray.exepara verificar o status atual das coisas.

Isso praticamente cobre tudo, eu acho.

Você pode considerar o uso da funcionalidade de passagem do dispositivo USB para um convidado executando o PowerChute ou outro software capaz de monitorar a saúde do no-break e capaz de acionar um desligamento no host ESXi (por exemplo, apcupsd ). O ESXi oficialmente suporta apenas um número muito limitado de dispositivos USB para passagem , mas as pessoas já estão conectando e passando por diferentes classes de dispositivos há um tempo já com sucesso variável, mas o APC UPS USB parece funcionar de acordo com esta explicação passo a passo para uma VM do Windows ou este para uma VM do CentOS Linux .

Dê uma olhada no vSphere Management Assistant (vMA) aqui Nós o usamos no meu escritório para fazer o que você está tentando, no entanto, com o Smart-UPS conectado via USB em vez de Back-UPS.

Embora seja possível (provavelmente / geralmente), não acho que o desligamento automático de um computador com energia da bateria seja uma boa idéia. Se você fizer isso, para as intenções e propósitos mais práticos, provavelmente economize o dinheiro de um no-break com bateria e deixe a perda de energia desligar sua máquina. (É certo que um desligamento limpo é sempre preferível a uma perda de energia, mas você parece estar perdendo o tempo de bateria com mais de alguns minutos se desligar automaticamente tudo quando perder o fornecimento de energia. )

A maneira como sempre lidei com isso é ter o monitoramento alertando as SAs quando a energia diminuir, para que elas possam usar sua substância cinzenta para decidir quando (ou mesmo se) desligar os servidores. Se houver uma breve interrupção, pode não ser uma boa ideia desligar os servidores ou você pode deixar alguns servidores em funcionamento o maior tempo possível e desligá-los antes que a bateria esteja prestes a acabar. Realmente me parece uma tarefa de tomada de decisão mais adequada para um ser humano do que uma regra simples.

Nos velhos tempos das instalações baremetais , o APC PowerChute Plus era uma parte essencial do meu processo de instalação. Usando o simples cabo de sinalização serial e seu binário exclusivo da Red Hat , foi fácil configurar regras para administrar um servidor conectado localmente. Notificações básicas por email para eventos da bateria UPC, eventos de energia da linha e ações de desligamento estavam disponíveis:

POWERCHUTE MAIL MESSAGE
Message from PowerChute@Bonanza:

UPS on battery: Blackout 000.0 V. 

e

POWERCHUTE MAIL MESSAGE
Message from PowerChute@Bonanza:

Normal power restored: UPS on line.  

ou

POWERCHUTE MAIL MESSAGE
Message from PowerChute@Bonanza:

Shutdown started.  

Além de uma interface razoável para ver o que estava acontecendo ...

Esse software acabou sendo comercializado (ou foi enterrado no site da APC). Havia algumas abordagens de código aberto para fornecer algo semelhante. Mas tudo isso se torna complicado com hosts VMWare ESXi únicos.

Parece que isso é algo que o VMWare deveria ter incorporado ao hipervisor de base. É básico e pode oferecer um nível decente de proteção para os usuários. Os remédios mais comuns que vejo agora são a passagem do USB para uma VM dedicada, uma abordagem de daemon de rede ou fazer o que faço; não configurando nenhum desligamento automático ou da bateria ...

É verdade que eu normalmente uso um no-break que pode suportar a carga do sistema por uma hora ou mais, mas interrupções prolongadas acontecem. Talvez uma alternativa seja coletar algumas placas de interface de rede de baixo custo ou recondicionadas e planejar comprar dispositivos SmartUPS no mínimo ...

Confira o seguinte link . Não é a solução mais elegante, mas uma solução muito prática e direta. Existem possíveis inconvenientes em termos de segurança (dependendo do seu design de rede específico, dos convidados carregados nos hosts e dos usuários de acesso que eles têm, mas você pode fazer essa ligação.

Usei a solução MrMajestyk e apenas alterei o acesso ssh via plink com acesso ssh sem senha usando a chave pública rsa. A chave rsa gerada na VM apcupsd deve ser incluída em / etc / ssh / keys-root / allowed_keys do host vmware.