6
APC Powerchute Network Shutdown generell und im HA-Cluster
Hallo an alle,
ich hab irgendwie ein Verständnisproblem? mit der Einrichtung der APC Powerchute Network Shutdown Software.
Und laut der netten Dame beim APC "Support" soll das alles nicht gehen wie ich vorhabe.
Szenario: A
2 "normale" Server hängen an einer APC USV mit einer Management Karte.
Beide haben die Powerchute Network Software installiert und können mit der Karte kommunizieren.
Jetzt möchte ich, dass einer der beiden Server nach 5 Min Akku-Betrieb runterfährt.
Der andere Server wiederum darf erst nach 10 Min Akku-Betrieb runterfahren.
Nach meinem Verständnis gehe ich auf den ersten Server in die Konfiguration und stelle im Event "UPS on Battery" folgendes bei Shutdown ein:
Enable Shutdown
Delay 300 seconds
Beim 2. Server stelle ich ebenfalls beim Event "UPS on Battery" ein:
Enable Shutdown
Delay 600 seconds
Somit sollte nach meinem Verständnis der 1. Server nach 5 Min mit dem Herunterfahren anfangen und der 2. Server nach 10 Min.
Der Grund dafür ist, dass Server 1 auf Server 2 zugreift und somit vorher runterfahren muss.
Ist das so machbar?
Szenario B
1x Physikalischer DC
1x Physikalischer Backup-Server
2x Hyper-V Hosts im HA-Cluster
2x Datacore Server im Cluster
Der DC, Hyper-V Host A und Datacore A hängen an USV A mit Management Karte.
Der Backup-Server, Hyper-V Host B und Datacore B hängen an einer USV B mit Management Karte.
Im Grunde eine ähnliche Konfiguration (Bei Event UPS on Battery).
1. ) Nach 5 Min kann der Backup-Server herunterfahren
2. ) Die Hyper-V Hosts sollen nach 5 Min auf Akku mit dem Herunterfahren der VMs anfangen
Nach 10 Min sollte der Host runterfahren können
Wobei hier das Problem entsteht, dass ich keine Reihenfolge einstellen kann, welche VM wann runtergefahren wird (SQL Server sollte zum Schluss kommen)
Müsste man dann mit Scripten lösen soweit ich das verstanden habe?
3.) DC kann nach 15 Min runterfahren
3.) Datacore B soll nach 15 Min 4 Dienste beenden, 2 Min Delay, danach Herunterfahren (Command File vor Shutdown)
4.) Datacore A soll nach 20 Min 4 Dienste beenden, 2 Min Delay, danach Herunterfahren (Command File vor Shutdown)
Die Krönung wäre jetzt noch die Migration anstoßen zu können, allerdings müsste vorher irgendwie abgefragt werden, ob die andere USV Strom hat
Vielleicht kann mich einer Aufklären ob ich falsch liege...
ich hab irgendwie ein Verständnisproblem? mit der Einrichtung der APC Powerchute Network Shutdown Software.
Und laut der netten Dame beim APC "Support" soll das alles nicht gehen wie ich vorhabe.
Szenario: A
2 "normale" Server hängen an einer APC USV mit einer Management Karte.
Beide haben die Powerchute Network Software installiert und können mit der Karte kommunizieren.
Jetzt möchte ich, dass einer der beiden Server nach 5 Min Akku-Betrieb runterfährt.
Der andere Server wiederum darf erst nach 10 Min Akku-Betrieb runterfahren.
Nach meinem Verständnis gehe ich auf den ersten Server in die Konfiguration und stelle im Event "UPS on Battery" folgendes bei Shutdown ein:
Enable Shutdown
Delay 300 seconds
Beim 2. Server stelle ich ebenfalls beim Event "UPS on Battery" ein:
Enable Shutdown
Delay 600 seconds
Somit sollte nach meinem Verständnis der 1. Server nach 5 Min mit dem Herunterfahren anfangen und der 2. Server nach 10 Min.
Der Grund dafür ist, dass Server 1 auf Server 2 zugreift und somit vorher runterfahren muss.
Ist das so machbar?
Szenario B
1x Physikalischer DC
1x Physikalischer Backup-Server
2x Hyper-V Hosts im HA-Cluster
2x Datacore Server im Cluster
Der DC, Hyper-V Host A und Datacore A hängen an USV A mit Management Karte.
Der Backup-Server, Hyper-V Host B und Datacore B hängen an einer USV B mit Management Karte.
Im Grunde eine ähnliche Konfiguration (Bei Event UPS on Battery).
1. ) Nach 5 Min kann der Backup-Server herunterfahren
2. ) Die Hyper-V Hosts sollen nach 5 Min auf Akku mit dem Herunterfahren der VMs anfangen
Nach 10 Min sollte der Host runterfahren können
Wobei hier das Problem entsteht, dass ich keine Reihenfolge einstellen kann, welche VM wann runtergefahren wird (SQL Server sollte zum Schluss kommen)
Müsste man dann mit Scripten lösen soweit ich das verstanden habe?
3.) DC kann nach 15 Min runterfahren
3.) Datacore B soll nach 15 Min 4 Dienste beenden, 2 Min Delay, danach Herunterfahren (Command File vor Shutdown)
4.) Datacore A soll nach 20 Min 4 Dienste beenden, 2 Min Delay, danach Herunterfahren (Command File vor Shutdown)
Die Krönung wäre jetzt noch die Migration anstoßen zu können, allerdings müsste vorher irgendwie abgefragt werden, ob die andere USV Strom hat
Vielleicht kann mich einer Aufklären ob ich falsch liege...
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 469752
Url: https://administrator.de/contentid/469752
Ausgedruckt am: 25.11.2024 um 19:11 Uhr
6 Kommentare
Neuester Kommentar
Es gibt eine eigene VM von APC, in der Du das (alles) einstellen kannst.
Das wäre mir komplett neu und finde ich auch jetzt nirgendswo bei denen.
Das einzige was einigermaßen dazu passt ist das Applet für VMware, da ist es möglich die Priorisierung der VMs einzustellen.
Für Hyper-V scheint es sowas nicht zu geben.
Das einzige was einigermaßen dazu passt ist das Applet für VMware, da ist es möglich die Priorisierung der VMs einzustellen.
Für Hyper-V scheint es sowas nicht zu geben.
Zitat von @Futballshaedel:
Das wäre mir komplett neu und finde ich auch jetzt nirgendswo bei denen.
Das einzige was einigermaßen dazu passt ist das Applet für VMware, da ist es möglich die Priorisierung der VMs einzustellen.
Für Hyper-V scheint es sowas nicht zu geben.
Das wäre mir komplett neu und finde ich auch jetzt nirgendswo bei denen.
Das einzige was einigermaßen dazu passt ist das Applet für VMware, da ist es möglich die Priorisierung der VMs einzustellen.
Für Hyper-V scheint es sowas nicht zu geben.
Guten Abend
https://www.apc.com/de/de/tools/download/software_comp.cfm?sw_sku=SFPCNS ...
Gruß Mikro
Das ist die Software die ich auf allen Server installiert und eingerichtet habe, ist also keine eingeständige VM die mir mehr Möglichkeiten zur Steuerung gibt (als ich schon oben erwähnt habe) so wie es @Looser27 erwähnt hat.
Moin.
Der vierte Link auf der APC-Homepage, das ist die Appliance. (Also die eigenständige Management-VM).
Ich würde da allerdings nochmal genauer schauen, da mir die Version von 2015 heftig alt vorkommt.
Ich meine unsere Appliance in der Firma war/ist deutlich neueren Datums.
Gruß Nikolaus
Der vierte Link auf der APC-Homepage, das ist die Appliance. (Also die eigenständige Management-VM).
Ich würde da allerdings nochmal genauer schauen, da mir die Version von 2015 heftig alt vorkommt.
Ich meine unsere Appliance in der Firma war/ist deutlich neueren Datums.
Gruß Nikolaus
Hallo ichbindernikolaus,
den Link habe ich schon gesehen auch in der neueren Version, allerdings ist das die Virtual Appliance für VMWare.
Da wir nur Hyper-V Hosts haben fängt es schon damit an.
Ich habe rein interessehalber mal die neueste "VApp" mal runtergeladen und in eine VHDX konvertiert, allerdings startet das Linux nicht ordentlich durch.
https://www.apc.com/us/en/tools/download/software_comp.cfm?sw_sku=SFPCNS ...
Es scheint tatsächlich keine Virtuelle Appliance für den Hyper-V zu geben.
Das lässt mich immer mehr drauf schließen, dass ich die Software "PowerChute Network Shutdown v4.3 for Windows x64" auf jedem physikalischem Server installieren muss und nur darüber das ganze steuern kann (abgespeckt oder eher gesagt mit Scripten)
Folgendes scheint meiner Meinung nach eingestellt werden zu müssen:
Nach 5 Minuten auf Akku, ruft HV1 die Batch-Datei auf, die wiederum die Powershell öffnet.
Hier müsste ich noch kontrollieren, ob der Aufruf mit den passenden Rechten ausgeführt wird.
In dieser Powershell suche ich gezielt den derzeitigen Host der Cluster-VM, um die VM dann auf diesem Host runterzufahren.
Somit kann ich auch hier gezielt die VMs in einer bestimmten Reihenfolge runterfahren.
Hier muss ich noch die -Force Option hinzufügen, falls jemand vergessen hat sich abzumelden oder ein Speicher-Dialog offen ist.
Nach 10 Minuten auf Akku fährt sich HV1 selbst runter (könnte man eigentlich in die Powershell selbst einbauen).
Das ganze müsste man dann auf jedem Physikalischen Server einstellen und zeitlich Timen.
Ist halt leider nur zusammengebaut und birgt die Gefahr falls einer der Maschinen mukkt, dass der ganze Zeitplan vor die Hunde geht.
Generell scheint mir hier die Software von APC bei weitem besser für VMWare abgestimmt zu sein als für Hyper-V.
den Link habe ich schon gesehen auch in der neueren Version, allerdings ist das die Virtual Appliance für VMWare.
Da wir nur Hyper-V Hosts haben fängt es schon damit an.
Ich habe rein interessehalber mal die neueste "VApp" mal runtergeladen und in eine VHDX konvertiert, allerdings startet das Linux nicht ordentlich durch.
https://www.apc.com/us/en/tools/download/software_comp.cfm?sw_sku=SFPCNS ...
Es scheint tatsächlich keine Virtuelle Appliance für den Hyper-V zu geben.
Das lässt mich immer mehr drauf schließen, dass ich die Software "PowerChute Network Shutdown v4.3 for Windows x64" auf jedem physikalischem Server installieren muss und nur darüber das ganze steuern kann (abgespeckt oder eher gesagt mit Scripten)
Folgendes scheint meiner Meinung nach eingestellt werden zu müssen:
Nach 5 Minuten auf Akku, ruft HV1 die Batch-Datei auf, die wiederum die Powershell öffnet.
Hier müsste ich noch kontrollieren, ob der Aufruf mit den passenden Rechten ausgeführt wird.
In dieser Powershell suche ich gezielt den derzeitigen Host der Cluster-VM, um die VM dann auf diesem Host runterzufahren.
Somit kann ich auch hier gezielt die VMs in einer bestimmten Reihenfolge runterfahren.
Hier muss ich noch die -Force Option hinzufügen, falls jemand vergessen hat sich abzumelden oder ein Speicher-Dialog offen ist.
Nach 10 Minuten auf Akku fährt sich HV1 selbst runter (könnte man eigentlich in die Powershell selbst einbauen).
Das ganze müsste man dann auf jedem Physikalischen Server einstellen und zeitlich Timen.
Ist halt leider nur zusammengebaut und birgt die Gefahr falls einer der Maschinen mukkt, dass der ganze Zeitplan vor die Hunde geht.
Generell scheint mir hier die Software von APC bei weitem besser für VMWare abgestimmt zu sein als für Hyper-V.
