APC UPS'in kritik pil seviyesinde VMWare ESXi hipervizörünün sorunsuz kapatılması

PowerChute Business Edition'ın nasıl yapılandırılacağı ve PowerShell'den VMWare'e nasıl bağlanılacağı hakkında birçok makale var, ancak bir şekilde tüm bunları, ince noktaların açıklamasıyla birlikte tek bir yerde bulamadım. Ama varlar.

1. giriş

Her ne kadar enerjiyle bir bağlantımız olsa da bazen elektrikle ilgili sorunlar çıkabiliyor. İşte bu noktada UPS devreye giriyor ama ne yazık ki aküleri uzun süre dayanmıyor. Ne yapalım? Kapamak!

Tüm sunucular fiziksel olmasına rağmen işler iyi gidiyordu, PowerChute Business Edition bize yardımcı oldu. 5 sunucu için ücretsiz, ki bu oldukça yeterliydi. Bir makineye bir aracı, sunucu ve konsol kuruldu. Son yaklaşırken, aracı, komşu sunuculara kapatma.exe /s /m gönderen bir komut dosyasını yürüttü ve ardından işletim sistemini kapattı. Herkes hayatta.
Sonra sanal makinelerin zamanı geldi.

2. Arka plan ve yansımalar

Peki neyimiz var? Hiçbir şey yok; Windows Server 2008 R2'ye sahip bir fiziksel sunucu ve Windows Server 2019, Windows Server 2003 ve CentOS dahil çeşitli sanal makinelere sahip bir hipervizör. Ve başka bir UPS – APC Smart-UPS.

NUT'u duyduk, ancak henüz inceleme fırsatı bulamadık; yalnızca elimizde olanı, yani PowerChute Business Edition'ı kullandık.

Hipervizör sanal makinelerini kendisi kapatabilir; geriye kalan tek şey ona zamanının geldiğini söylemektir. VMWare.PowerCLI çok faydalı bir şey var, bu, hipervizöre bağlanmanıza ve ona ihtiyacınız olan her şeyi söylemenize olanak tanıyan bir Windows Powershell uzantısıdır. PowerCLI ayarları hakkında da birçok makale var.

3. Süreç

UPS fiziksel olarak 2008 sunucusunun com portuna bağlıydı, neyse ki oradaydı. Bu önemli olmasa da, bir arayüz dönüştürücü (MOXA) aracılığıyla herhangi bir sanal Windows sunucusuna bağlanmak mümkündü. Ayrıca, aksi açıkça belirtilmediği sürece, tüm eylemler UPS'in bağlı olduğu makinede (Windows Server 2008) gerçekleştirilir. PowerChute Business Edition aracısı üzerine yüklendi. İşte ilk ince nokta: Aracı hizmetinin sistemden değil kullanıcıdan başlatılması gerekir, aksi takdirde aracı cmd dosyasını çalıştıramayacaktır.

Daha sonra .Net Framework 4.7'yi kurduk. Burada yeniden başlatma gerekli, çerçeve kurulumdan sonra açıkça bunu istemese bile, aksi takdirde daha ileri gitmeyecektir. Daha sonra yine de yüklenmesi gereken güncellemeler gelebilir.

Daha sonra PowerShell 5.1'i kurduk. Ayrıca yeniden başlatma gerektirir, sormasa bile.
Ardından PowerCLI 11.5'i yükleyin. Oldukça yeni bir sürüm, dolayısıyla önceki gereksinimler. Bunu internet üzerinden yapabilirsiniz, bununla ilgili birçok makale var ama biz zaten indirdik, bu yüzden tüm dosyaları Modüller klasörüne kopyaladık.

Kontrol:

Get-Module -ListAvailable

Tamam, yüklediğimizi görüyoruz:

Import-Module VMWare.PowerCLI

Evet, Powershell konsolu elbette Yönetici olarak başlatıldı.

Powershell ayarları.

• Herhangi bir komut dosyasının yürütülmesine izin ver:

Set-ExecutionPolicy Unrestricted

• Veya yalnızca komut dosyası sertifikalarının yoksayılmasına izin verebilirsiniz:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 

• PowerCLI'nin geçersiz (süresi dolmuş) sertifikalara sahip sunuculara bağlanmasına izin verin:

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

• Deneyim değişim programına katılımla ilgili PowerCLI mesajının çıktısını bastırın, aksi takdirde günlükte birçok gereksiz bilgi olacaktır:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

• Komut dosyasında açıkça gösterilmemesi için VMWare ana bilgisayarında oturum açmak için kullanıcı kimlik bilgilerini kaydedin:

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

Kontrol etmek kimi kurtardığımızı gösterecektir:

Get-VICredentialStoreItem

Ayrıca bağlantıyı da kontrol edebilirsiniz: Connect-VIServer adresi.

Komut dosyasının kendisi, örneğin: bağlı, kapalı, bağlantısı kesilmiş her ihtimale karşı aşağıdaki seçenekler mümkündür:

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

4. Varsayılan.cmd

APC aracısı tarafından başlatılan aynı toplu iş dosyası. “C:Program Files[ (x86)]APCPowerChute Business Editionagentcmdfiles” içinde ve içinde bulunur:

"C:Windowssystem32WindowsPowerShellv1.0powershell.exe" -Dosya "C:...shutdown_hosts.ps1"
Görünüşe göre her şey yapılandırılmış ve kontrol edilmiş, hatta cmd'yi başlattık - doğru çalışıyor, kapatıyor.

APC konsolundan bir komut dosyası testi çalıştırıyoruz (orada bir Test düğmesi var) - çalışmıyor.

İşte, yapılan tüm çalışmaların hiçbir sonuç vermediği o tuhaf an.

5. Katarsis

Görev yöneticisine bakıyoruz, cmd flaşlarını, powershell flaşlarını görüyoruz. Daha yakından bakalım - cmd *32 ve buna göre powershell *32. Bunu anlıyoruz APC aracı hizmeti 32 bittir; bu, ilgili konsolu çalıştırdığı anlamına gelir.

Powershell x86'yı yönetici olarak başlatıyoruz ve PowerCLI'yi 3. adımdan itibaren tekrar kurup yapılandırıyoruz.

Peki, powershell çağrı hattını değiştirelim:

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

6. Mutlu son!

Kaynak: habr.com