pete.db 10 Geschrieben 17. Mai 2016 Melden Teilen Geschrieben 17. Mai 2016 Guten Tag Zusammen,Unsere USV versorgt eine Reihe von Serversystem und verschiedene andere Komponenten. Fällt der Strom aus, puffert die USV.Nach einem bestimmten Zeitraum sollen die Systeme sauber heruntergefahren werden. Soweit alles Standard.Ich möchte nun nicht auf jedem System einen USV Agent installieren. Dies ist bei einigen physikalischen Appliances auch gar nicht möglich.Daher würde ich das ganze gerne sktriptgesteuert über einen "Management Server" steuern.- Management Server hat den USV Agent installiert und kommuniziert direkt mit der USV (Strom da, Strom weg etc.)- Falls nach 30 Minuten die Stromversorgung nicht wieder da ist, führt der Server das "Shutdown-Datacenter-Sktipt" aus- "Shutdown-Datacenter-Sktipt" bekommt eine Serverliste übergeben und fährt die Systeme der Reihe nach in Abhängigkeit herunterFrage/Problem 1: Ich möchte, dass das Skript die VMs, physikalischen Server etc. in Abhängigkeit herunter fährt Beispiel: erst Webserver / dann DB Server / nur wenn der DB Server aus ist, Storage herunter fahren / ggf. Timeout nach 5 MinutenFrage/Problem 2: Aus dem Skript (voraussichtl. PowerShell) möchte ich per ssh oder telnet entfernte Systeme steuern Beispiel: ESXi oder Storage per SSH sauber herunterfahren.Ich möchte das ganze (noch) nicht über ein Monitoring (Icinga o.ä.) lösen.Und ich möchte, dass die Systeme wirklich in Abhängigkeit herunter gefahren werden und man nicht einfach zwischen erstem und zweitem Server zwei Minuten wartet.Nun meine konkreten Fragen:- ist Powershell hier das richtige?- würdet ihr auch so vorgehen?- habt ihr Erfahrung damit oder ggf. Beispiele parat?Ich finde bislang leider nur Beispiele, wo die Abhängigkeit zwischen den Servern nur durch "ich warte zwei Minuten bis ich den nächsten herunter fahre" abgebildet wird.Anscheinend ist das selbst bei VMware der Weg...ich finde das eher unsauber.Beste Grüßepete Zitieren Link zu diesem Kommentar
magheinz 110 Geschrieben 17. Mai 2016 Melden Teilen Geschrieben 17. Mai 2016 (bearbeitet) alles kein Problem, nur recht viel Arbeit. 1. du musst irgendwo hinterlegen in welcher Reihenfolge die VMs runtergefahren werden. Ich habe dafür in Vsphere die tags "frontend,middlewsre,backend,infrastruktur,monitoring" eingeführt 2.Shutdown dann per Powershell(vmware-commandlets) oder alternativ perl-api 3. Habt ihr ein Monitoring? Falls ja: nutze es. Icinga+Vmware-perl-sdk. 4. Physische appliances: Da wirds spannend: telnet, ssh, snmp, web,api. Was kann die appliance? Ich kann morgen mal mein script posten... edit: Wenn ich am Handy poste geht immer die Formatierung kaputt... bearbeitet 17. Mai 2016 von magheinz Zitieren Link zu diesem Kommentar
monstermania 53 Geschrieben 17. Mai 2016 Melden Teilen Geschrieben 17. Mai 2016 (bearbeitet) Moin, wir haben hier ein USV Shutdown für unsere VMWare HA Umgebung realisiert. Hier der Link zu unserer Lösung: http://vmware-forum.de/viewtopic.php?t=30529&start=0&postdays=0&postorder=asc&highlight=apc Haben unsere Serversysteme in Gruppen eingeteilt und steuern darüber den Shutdown. So ganz ohne Timeout-Funktionen wirst Du nicht auskommen, da es immer mal vorkommen kann, dass eine Maschine nicht herunterfährt. Da hilft dann nur ein "hartes" Ausschalten nach XXX Sekunden! Gruß Dirk bearbeitet 17. Mai 2016 von monstermania Zitieren Link zu diesem Kommentar
Dukel 455 Geschrieben 17. Mai 2016 Melden Teilen Geschrieben 17. Mai 2016 Ist die Reihenfolge beim Herunterfahren so wichtig? Wichtiger ist diese doch idR beim Hochfahren. Zitieren Link zu diesem Kommentar
pete.db 10 Geschrieben 17. Mai 2016 Autor Melden Teilen Geschrieben 17. Mai 2016 Hallo, vielen Dank schon mal. @magheinz: Das Skript von dir würde mich sehr interessieren. Monitoring existiert noch nicht. Die Appliances können SSH oder alternativ telnet. Das würde ich dann gerne per "SSH-Sessions" aus PS aufrufen @monstermania: Auch interessant. Das ganze in python könnte eine Alternative sein. Den Timeout falls ein Server hängt brauche ich. Da hast Du vollkommen recht. @Dukel: Ja, die Reihenfolge ist wichtig. Beispiele: Erst Webserver, dann Datenbank (keine Schreibzugriffe mehr auf DB) // erst VMs dann ESXi // erst ESXi dann Storage etc. Zitieren Link zu diesem Kommentar
NorbertFe 2.062 Geschrieben 17. Mai 2016 Melden Teilen Geschrieben 17. Mai 2016 (bearbeitet) Von apc gibt's ne vm appliance die afaik genau sowas regelt. ;) https://www.apc.com/de/de/tools/download/software_comp.cfm?sw_sku=SFPCNS40-V&ISOCountryCode=de bearbeitet 17. Mai 2016 von NorbertFe Zitieren Link zu diesem Kommentar
monstermania 53 Geschrieben 18. Mai 2016 Melden Teilen Geschrieben 18. Mai 2016 @Norbert Ja, wobei die Appliance auch genug Probleme machte, wie man immer mal wieder im VMWare-Forum lesen darf. Wir haben unsere Anforderungen seinerzeit nicht mit der APC Lösung (Appliance V3.1) hinbekommen. Demnächst stellen wir aber auf VMWare 6 um. Dann werden wir uns auch die Appliance nochmal ansehen. Wenn man eh schon eine Monitoring-Lösung im Unternehmen einsetzt ist es m.E. auch durchaus sinnvoll dass diese Lösung auch den Shutdown der Infrastruktur steuert. Zitieren Link zu diesem Kommentar
pete.db 10 Geschrieben 18. Mai 2016 Autor Melden Teilen Geschrieben 18. Mai 2016 @Norbert: Die Appliance sieht interessant aus. Leider macht sie bezüglich Abhängigkeiten nichts anderes als wenn ich den Shutdown Befehl direkt an einen ESX oder VCenter absetze. Abhängigkeiten kann ich auch hier nur an Zeitintervallen festmachen. So nach dem Motto ... nach zwei Minuten müsste Server 1 ja normalerweise aus sein, ... dann schalte ich jetzt einfach Server 2 aus. ICh möchte aber (kurz) prüfen, ob Server 1 wirklich aus ist bevor ich weiter mache. Das kann auch die Appliance so nicht. @monstermania: Ja, Shutdown über Monitoring initiieren, wäre am saubersten. Allerdings für meinen Fall zunächst ein Icinga im Unternehmen zu etablieren wäre zu umfangreich. Zitieren Link zu diesem Kommentar
monstermania 53 Geschrieben 18. Mai 2016 Melden Teilen Geschrieben 18. Mai 2016 @pete.db Grundsätzlich brauchst Du natürlich keine komplette Monitoringlösung. Sofern Du die USV per SNMP-Abfragen auswerten kannst, lässt sich so etwas auch per Scripting realisieren. Allerdings solltest Du nicht die Komplexität unterschätzen. Bei unserem 1. Versuch einen automatischen Shutdown auszulösen haben wir es exakt so versucht, wie Du Dir das vorstellst. 1. Es wurde eine Reihenfolge (Liste) für das herunterfahren definiert 2. Das Script fuhr VM für VM herunter Hat aber nur in der Theorie funktioniert. :rolleyes: Wir haben hier rund 40 VM am laufen. In der Praxis hat das Herunterfahren dann einfach viel zu lange gedauert! Wenn man nur knapp 60 Sekunden pro VM ansetzt, hat das Runterfahren schon ca. 40 Minuten benötigt. Da wären unsere USV's schon lange abgeschaltet zumal man ja nach einem Stromausfall nicht umgehend mit dem Shutdown startet, sondern die Anlage zunächst einige Minuten weiter laufen läßt! - Von daher haben wir Shutdowngruppen definiert und fahren alle VM's einer Gruppe gleichzeitig herunter. - Sind alle VM der Gruppe heruntergefahrn bevor ein Zeitlimit erreicht ist geht es mit der nächsten Gruppe weiter - Wird das Zeitlimit für die jeweilige Gruppe erreicht, werden alle noch laufenden VM 'hart' ausgeschaltet. Dann geht es mit der nächsten Gruppe weiter. - Zum Schluss dann die Hosts in den Wartungsmodus schalten und herunterfahren Mit dieser Methode haben wir beim letzten Stromausfall im Januar 2016 unsere komplette Anlage in rund 9 Minuten heruntergefahren. Aber auch nur, weil sich alle Server sauber herunterfahren ließen. Maximal könnte das bei uns auch 17 Minuten dauern, wenn in jeder Gruppe eine VM nicht sauber herunterfährt. Zitieren Link zu diesem Kommentar
PowerShellAdmin 169 Geschrieben 18. Mai 2016 Melden Teilen Geschrieben 18. Mai 2016 (bearbeitet) Habe hier eine Dell USV im Einsatz, auf einem Server läuft die USV Anwendung => Bei Ausfall nach N Minuten wir der Shutdown aufgerufen. Das Ganze ist eine mittelschöne Lösung - eher unschön... => Gerade mit den verschiedenen Credentials hatte ich meinen Spaß.. In dem Fall ein Batch File, welche eine PowerShell startet und die entsprechenden VMWare Module lädt. Dieser Shellskript startet dann im Adminkontext einen PS Shutdownskript. Letzteres startet dann die Hostshutdowns. Physikalische Systeme werden einfach via Shutdown ... /s /t herunter geschupst. Die VMWare Hosts werden via Jobs zeitgleich initialisiert - die Hypervisor fahren also parallel herunter. Die Jobs sind nochmal in eigene PowerShellSkripte ausgelagert. Der eigene Shutdown fährt sämtliche VMs auf den Host herunter - nach 3,5 Minuten wird dann der Host heruntergefahren. bearbeitet 18. Mai 2016 von PowerShellAdmin Zitieren Link zu diesem Kommentar
pete.db 10 Geschrieben 18. Mai 2016 Autor Melden Teilen Geschrieben 18. Mai 2016 Echt schön, dass hier so viel Feedback und Vorschläge kommen. Wie gesagt, auf Dauer möchte ich schon ein Monitorig etablieren, welches dann auch die Shutdowns etwas granularer steuert. Aber nun im ersten Schritt möchte ich einfach, dass falls die USV anläuft, unsere Server sauber in einer bestimmten Reihenfolge herunter gefahren werden. Bei uns wird auch die Software der USV eine batch starten, darin sollen dann verschiedene Skripte (wie gesagt, am liebsten PowerShell) verschiedene Systeme gruppiert herunter fahren. Vielleicht ist das Prüfen auf Status der Dienste wirklich etwas zu viel an dieser Stelle. Ich werde mich dann mal an diesem Weg versuchen: Batch ruft verschiedene PS Skripte auf, die wiederum Gruppen von Systemen herunterfahren (mal per PowerCLI, mal SSH, mal direkt shutdown...) Zitieren Link zu diesem Kommentar
magheinz 110 Geschrieben 18. Mai 2016 Melden Teilen Geschrieben 18. Mai 2016 (bearbeitet) So, anbei mein script.7 Das ist noch nicht ganz fertig, funktioniert aber. Der shutdown ist innerhalb der Gruppen(alle den gleichen TAG) parallelisiert. So können VM-Admins bestimmen wo sich ihre VM im shutdown einreiht. Ausserdem werden die tags gleich noch für die automatische Doku mit ausgewertet. Die hosts fahre ich im Moment nicht runter. Im Zweifelsfall sind die in 15Minuten neu aufgesetzt.(foreman mit kickstart-scipt) Wenn ich mal ein paar Minuten zeit habe packe ich das aber noch mit ins script. Alle appliances die wir haben sollten einen Stromausfall ohne Probleme überstehen. Der Storage, solange keine Schreibzugriffe stattfinden auch. Aber hier gilt das gleiche: Wenn Zeit dann machen. Der Plan ist das über den icinga anzutriggern, dann eventuell als perlscript. Ungefähr so: 1. Icinga sieht Stromausfall 2. Meldung an IT auf allen Kanälen(E-Mail, SMS, Telefonanruf etc) 3. IT fragt bei Haustechnik zurück: Was ist los, wie lange wird es voraussichtlich dauern usw? 4. IT entscheidet durch Nichtstun: shutdown wenn Batterielaufzeit unter x Minuten oder Stromausfall erst mal ignorieren durch Bestätigen des Alarms o.ä. Hintergrund ist: Alles was zwei Netzteile hat hängt mit einem Bein auf einer APC und mit dem anderen auf HausUSV+Diesel. Dadurch ist es eine Risikoabschätzung ob man mit einem Netzteil weiter laufen lässt oder lieber runterfährt was davon abhängt wie lange der Strom voraussichtlich weg ist. Eventuell muss man die Wartezeit zwischen shutdown der VM und dem harten ausschalten noch individueller gestalten. $starttime = Get-Date Add-PSSnapin VM* $DOMANIN="foo" $USERNAME="bar" $PASSWORD="1234567890" $VCENTER="1.2.3.4" # oder FQDN $Bereiche = 'intern','DA','DMZ','Testumgebung','Erkannte virtuelle Maschinen' #$Bereiche = 'DA' $ScriptBlock = { param($vm) $DOMANIN="foo" $USERNAME="bar" $PASSWORD="1234567890" $VCENTER="1.2.3.4" # oder FQDN Add-PSSnapin VM* $vserver = Connect-VIServer -Server "$VCENTER" -User "$DOMAIN\$USERNAME" -Password "$PASSWORD" -WarningAction SilentlyContinue $vm_name = $vm.Name $timestamp = Get-Date -Format yyyyMMdd-HHmmss $counter=0 $vvm = Get-VM($vm) "shutting-down "+$vvm.Name > c:\tmp\shutdown\$vm_name-$timestamp-$counter.txt $vvm | Shutdown-VMGuest #-WhatIf while (($vvm.PowerState -eq "PoweredOn") -and ($counter -lt 5)) { $vvm = Get-VM($vm) $vm_name = $vvm.Name $timestamp = Get-Date -Format yyyyMMdd-HHmmss "shutting-down $vm_name" > c:\tmp\shutdown\$vm_name-$timestamp-$counter.txt $counter++ Start-Sleep 120 } #wennn nicht runtergefahren: abschalten $vvm = Get-VM($vm) if ($vvm.PowerState -eq "PoweredOn") { $timestamp = Get-Date -Format yyyyMMdd-HHmmss "poweroff $vm_name" > c:\tmp\shutdown\$vm_name-$timestamp-poweroff.txt $vvm | Stop-VM # -WhatIf } Disconnect-VIServer -Server "$VCENTER" -Confirm:$false } function SetPowerTag($vm) { Get-TagAssignment $vm -Category "LastPowerState" | Remove-TagAssignment -Confirm:$false Switch ($vm.PowerState) { "PoweredOff" { $foo = $vm | New-TagAssignment -Tag "PoweredOff" } "PoweredOn" { $foo = $vm | New-TagAssignment -Tag "PoweredOn" } "Suspended" { $foo = $vm | New-TagAssignment -Tag "Suspended" } } } function VmRunning($vm_list) { foreach($vm in $vm_list) { $VMNAME = $vm $vvm = Get-VM("$VMNAME") if ($vvm.PowerState -eq "PoweredOn") { return $true } } return $false } function getBereich($vm) { $currentFolder = $vm.Folder $folder="/" While (($currentFolder.ParentId -ne $null) -and ($currentFolder.Parent.Name -ne "vm")) { $currentFolder = $currentFolder.Parent } return $currentFolder } $vserver = Connect-VIServer -Server "172.16.5.4" -User "$DOMAIN\$USERNAME" -Password "$PASSWORD" -WarningAction SilentlyContinue $vms = Get-VM $vms_frontend = @{} $vms_middleware = @{} $vms_backend = @{} $vms_monitoring = @{} $vms_management = @{} $vms_alle = @{} foreach ($vm in $vms) { $TAG = $vm | Get-TagAssignment -Category "AppLayer" $TAG_tag = $TAG.Tag SetPowerTag($vm) switch ($TAG.Tag) { "AppLayer/Frontend" { $vms_frontend.Add($vm.Name,$vm) } "AppLayer/Middleware" { $vms_middleware.Add($vm.Name,$vm) } "AppLayer/Backend" { $vms_backend.Add($vm.Name,$vm) } "AppLayer/Monitoring" { $vms_monitoring.Add($vm.Name,$vm) } "AppLayer/Management" { $vms_management.Add($vm.Name,$vm) } } } "-----------------------------------------------------------" foreach ($bereich in $Bereiche) { Write-Host "VMs from $bereich shutting down" $i=0 foreach ($applayer in $vms_frontend,$vms_backend,$vms_middleware,$vms_monitoring) { foreach($vm_name in $applayer.Keys) { if ((getBereich($applayer["$vm_name"])).Name -eq "$bereich") { "$bereich : " + ($applayer["$vm_name"]).Name $foo = Start-Job $ScriptBlock -ArgumentList $applayer["$vm_name"] } } Write-Host -NoNewline "VMs shutting down:" While (Get-Job -State "Running") { Write-Host -NoNewline "." Start-sleep 10 } } Write-Host "All VMs from $bereich down" } "-----------------------------------------------------------" #Get-Job |Receive-Job Remove-Job * Disconnect-VIServer -Server "$VCENTER" -Confirm:$false $stoptime=Get-Date $starttime $stoptime $stoptime-$starttime bearbeitet 18. Mai 2016 von magheinz Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 18. Mai 2016 Melden Teilen Geschrieben 18. Mai 2016 Falls man eine USV mit Generex-Management hat, kann man sich auch RCCMD anschauen: http://www.generex.de/content/view/17/51/lang,ge/ Gibt es auch für ESXI. Hier kann man ein passendes Shell-Script hinterlegen, dass alle laufenden VMs herunterfährt und dann den Host. Passende Shell-Scripte findet man im Netz. Zitieren Link zu diesem Kommentar
Smalltalk 3 Geschrieben 18. Mai 2016 Melden Teilen Geschrieben 18. Mai 2016 Moin, ich würde eher auf der anderen Seite der Überlegung anfangen - gibt es mehrere Serverräume oder unterschiedliche Einspeisungen vom EVU? In vielen Fällen geht man das Risiko eher ein dass die Systeme auf die Nase fallen, als anzufangen kontrolliert herunterzufahren. Aus dem einfachen Grund dass in den meisten Fällen bereits nach wenigen Minuten das Script startet und einmal ausgeführt - nicht mehr stoppt. Wenn dann jedoch wieder Spannung anliegt fährt mir dennoch die gesamte Struktur herunter. Da in fast allen Fällen die "normalen" Benutzer nicht mehr auf den Systemen arbeiten, verändern sich somit auch nicht mehr die Files und die Datenänderungsrate ist bei 0, somit auch der Verlust an Daten. Man kann jedoch im Stromausfall unwichtige Systeme abwerfen und im Hintergrund managebare Steckdosenleisten verbauen um physikalische Systeme danach wieder anzustarten. Gruß Michael Zitieren Link zu diesem Kommentar
magheinz 110 Geschrieben 18. Mai 2016 Melden Teilen Geschrieben 18. Mai 2016 Das automatische Wiederanlaufen lassen der Hardware halte ich für gefährlich. Im Dümmsten Fall basteln die Elektriker was und der Strom ist immer wieder für ein paar Sekunden da. Am Ende sind die Netzteile tot. Nach wie vielen Minuten das script startet muss man natürlich an die jeweilige Situation anpassen. Das ist auch von de Batterielaufzeit abhängig. Das gute ist: Man sollte das auch regelmässig testen und hat so einen shutdowntermin im Jahr den man gleich für Wartungsarbeiten nutzen kann. Das script einfach automatisch nach 5 Minuten losrennen zu lassen halte ich aber auch nicht für sinnvoll. Deswegen das Prozedere: 1. Icinga sieht Stromausfall 2. Meldung an IT auf allen Kanälen(E-Mail, SMS, Telefonanruf etc) 3. IT fragt bei Haustechnik zurück: Was ist los, wie lange wird es voraussichtlich dauern usw? 4. IT entscheidet durch Nichtstun: shutdown wenn Batterielaufzeit unter x Minuten oder Stromausfall erst mal ignorieren durch Bestätigen des Alarms o.ä. Dann kann man, wenn die Haustechnik sagt: Bagger, dauert 10Stunden eben kontrolliert alle oder ein paar Systeme in Sicherheit bringen oder eben auf Risiko gehen und sagen man lässt es auf den Diesel ankommen. Oft sagen die: "Strom ist in einer halben Stunde wieder da". Wenn man dann weiss wie lange die USVen durchhalten kann man ja je nach dem entscheiden. Wenn aber kein ITler erreichbar ist würde ich besser schlafen wenn alles runterfährt. Ich hab einmal die Aufräumarbeit machen dürfen als es Probleme in der USV gab (Kurzschluss in den Akkus mit Lichtbogen und allem drum und drann) und alles wegen Stromausfall von Jetzt auf Gleich dunkel wurde. Das würde ich gerne in Zukunft verhindern. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.