12
Windows Server friert bzw. hängt sich auf - keine Auffäligkeiten im Eventlog - Ursache ?
Hallo,
wir haben bei uns eine VMware Vsphere 5.5 Umgebung mit 3 Esxi Servern. Wir das Problem das sich immer wieder variabel VM's mit Windows Server Betriebssystem aufhängen bzw. einfrieren. Es hängt sich im Monat etwa 1 Maschine auf, die VM ist per Ping erreichbar allerdings kann weder RDP bzw. über die vSphere Konsole drauf zugegriffen werden. Es laufen scheinbar alle Dienste weiter, denn unsere Monitoring erkennt das Problem nicht. Im Eventlog ist nichts zufinden, der Log bricht zu dem Zeitpunkt ab wo sich die Maschine aufhängt/einfriert und geht nach dem Neustart weiter. Nach dem Herunterfahren der VM funktioniert sie wieder einwandfrei als wäre nichts gewesen.
Hat jemand ggf. gleiche Erfahrungen gemacht oder hat eine Idee was für eine Ursache das ganze hat ?
Wir hatten es in den letzten 3 Wochen nun 3 mal das sich unser ERP Server aufgehängt hat und dies immer am Abend/Nacht..
wir haben bei uns eine VMware Vsphere 5.5 Umgebung mit 3 Esxi Servern. Wir das Problem das sich immer wieder variabel VM's mit Windows Server Betriebssystem aufhängen bzw. einfrieren. Es hängt sich im Monat etwa 1 Maschine auf, die VM ist per Ping erreichbar allerdings kann weder RDP bzw. über die vSphere Konsole drauf zugegriffen werden. Es laufen scheinbar alle Dienste weiter, denn unsere Monitoring erkennt das Problem nicht. Im Eventlog ist nichts zufinden, der Log bricht zu dem Zeitpunkt ab wo sich die Maschine aufhängt/einfriert und geht nach dem Neustart weiter. Nach dem Herunterfahren der VM funktioniert sie wieder einwandfrei als wäre nichts gewesen.
Hat jemand ggf. gleiche Erfahrungen gemacht oder hat eine Idee was für eine Ursache das ganze hat ?
Wir hatten es in den letzten 3 Wochen nun 3 mal das sich unser ERP Server aufgehängt hat und dies immer am Abend/Nacht..
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: 336707
Url: https://administrator.de/contentid/336707
Ausgedruckt am: 09.11.2024 um 01:11 Uhr
12 Kommentare
Neuester Kommentar
Viel zu wenig Informationen, um dir helfen zu können :/
- Physische Hardware?
- Global oder Custom-ESXi-Installation?
- Hardwarechecks? RAID-Volumes konsistent, RAM in Ordnung?
- Environment? Wann und wie laufen eure Sicherungen, laufende Snapshots, Temperatur?
- ESXi Lizenz und Maintenance?
- Konstellation? Drei Server = HA, FT? Lassen sich die VM-Freezes auf einen Host beschränken?
- Physische Hardware?
- Global oder Custom-ESXi-Installation?
- Hardwarechecks? RAID-Volumes konsistent, RAM in Ordnung?
- Environment? Wann und wie laufen eure Sicherungen, laufende Snapshots, Temperatur?
- ESXi Lizenz und Maintenance?
- Konstellation? Drei Server = HA, FT? Lassen sich die VM-Freezes auf einen Host beschränken?
Vielen Dank für die Antwort.
- Die VM's laufen verteilt auf die 3 physischen ESXi Server sind 3 HP ProLiant DL380 Gen 9 Server. Unabhängig auf welchem Server die VM läuft hängt sie sich auf.
- Global
- Hardwarechecks via Icinga2(NSClient++) auf Festplatten, CPU, RAM, uptime, dienste wie z.b. Remotedesktop. die checks laufen alle wunderbar weiter ohne Fehler - fürs Monitoring läuft die Maschine ohne Probleme..
- Backups laufen über VEEAM für jede Maschine in einem bestimmten Zeitplan, zu 1 Zeit läuft nur 1 Backupjob, keine Überschneidung etc.
- Snapshots sind verschieden definiert für jede Maschine (ERP VM bspw. alle 4 Stunden Snapshots), Temp i.o, kein Overloading vom CPU
-Lizenz für VCenter Standard und zusätzlich 6 CPU Sockel Lizenzen für Vsphere 5 Enterprise
- Die VM's laufen verteilt auf die 3 physischen ESXi Server sind 3 HP ProLiant DL380 Gen 9 Server. Unabhängig auf welchem Server die VM läuft hängt sie sich auf.
- Global
- Hardwarechecks via Icinga2(NSClient++) auf Festplatten, CPU, RAM, uptime, dienste wie z.b. Remotedesktop. die checks laufen alle wunderbar weiter ohne Fehler - fürs Monitoring läuft die Maschine ohne Probleme..
- Backups laufen über VEEAM für jede Maschine in einem bestimmten Zeitplan, zu 1 Zeit läuft nur 1 Backupjob, keine Überschneidung etc.
- Snapshots sind verschieden definiert für jede Maschine (ERP VM bspw. alle 4 Stunden Snapshots), Temp i.o, kein Overloading vom CPU
-Lizenz für VCenter Standard und zusätzlich 6 CPU Sockel Lizenzen für Vsphere 5 Enterprise
Zitat von @Tigger90:
Vielen Dank für die Antwort.
- Die VM's laufen verteilt auf die 3 physischen ESXi Server sind 3 HP ProLiant DL380 Gen 9 Server. Unabhängig auf welchem Server die VM läuft > hängt sie sich auf.
Ok, Storage ist intern oder extern? Firmware auf allen drei Servern durchgepatcht? http://h17007.www1.hpe.com/us/en/enterprise/servers/products/service_pa ...Vielen Dank für die Antwort.
- Die VM's laufen verteilt auf die 3 physischen ESXi Server sind 3 HP ProLiant DL380 Gen 9 Server. Unabhängig auf welchem Server die VM läuft > hängt sie sich auf.
- Global
Mehr schlecht als recht, bzw. kein Best Practise, da sämtliche HP-spezifischen Hardware-Treiber (vor Allem die RAID-Controller-Treiber) und -Agents fehlen. Das sollte dringend geändert werden https://my.vmware.com/web/vmware/details?downloadGroup=OEM-ESXI55U3B-HPE ...- Backups laufen über VEEAM für jede Maschine in einem bestimmten Zeitplan, zu 1 Zeit läuft nur 1 Backupjob, keine Überschneidung etc.
Übereinstimmung des Zeitplans mit den Freezes?- Snapshots sind verschieden definiert für jede Maschine (ERP VM bspw. alle 4 Stunden Snapshots), Temp i.o, kein Overloading vom CPU
Ok, das heißt, ihr habt extra jemanden dafür angestellt, der alle 4 Stunden die ERP VM herunterfährt, den alten Snapshot löscht, einen neuen erstellt, die Maschine wieder hoch fährt und nach 4 Stunden dasselbe Spiel wieder von vorne fährt?-Lizenz für VCenter Standard und zusätzlich 6 CPU Sockel Lizenzen für Vsphere 5 Enterprise
Passt.Zitat von @chgorges:
intern, im 1 und 2 ESXI sind lokale Festplatten zu einem VSAN gebildet. Auf dem 3 ist ein Failover Manager installiert der für die Mehrheitsbildung benötigt wird falls einer der Storage Server ausfällt.Zitat von @Tigger90:
Vielen Dank für die Antwort.
- Die VM's laufen verteilt auf die 3 physischen ESXi Server sind 3 HP ProLiant DL380 Gen 9 Server. Unabhängig auf welchem Server die VM läuft > hängt sie sich auf.
Ok, Storage ist intern oder extern? Firmware auf allen drei Servern durchgepatcht?Vielen Dank für die Antwort.
- Die VM's laufen verteilt auf die 3 physischen ESXi Server sind 3 HP ProLiant DL380 Gen 9 Server. Unabhängig auf welchem Server die VM läuft > hängt sie sich auf.
- Global
- Backups laufen über VEEAM für jede Maschine in einem bestimmten Zeitplan, zu 1 Zeit läuft nur 1 Backupjob, keine Überschneidung etc.
- nein ist unabhängig davon.- Snapshots sind verschieden definiert für jede Maschine (ERP VM bspw. alle 4 Stunden Snapshots), Temp i.o, kein Overloading vom CPU
genau, nein natürlich nicht 
wird automatisch erstellt, gelöscht etc.-Lizenz für VCenter Standard und zusätzlich 6 CPU Sockel Lizenzen für Vsphere 5 Enterprise
Passt.
Sorry zitieren sollte ich nochmal üben
- Snapshots sind verschieden definiert für jede Maschine (ERP VM bspw. alle 4 Stunden Snapshots), Temp i.o, kein Overloading vom CPU
genau, nein natürlich nicht wird automatisch erstellt, gelöscht etc.
wird automatisch erstellt, gelöscht etc.Dann ist das hier ein Punkt, der die VMs schon nachhaltig geschädigt haben kann.
Wie werden die Snapshots erstellt? Werden die VMs von diesem Automatismus stillgelegt, wie es Veeam macht, oder mit dem Kopf durch Wand im laufenden Betrieb? Letzteres kann VMs irreparabel beschädigen und endet genau in diesem Phänomen.
Zumal das automatisierte Erstellen und Löschen von Snapshots als Ersatz für eine temporäre Sicherung (wenn ich das richtig deute) eine fatale Zweckentfremdung und nicht "Sinn der Sache" ist ;)
Zitat von @chgorges:
Dann ist das hier ein Punkt, der die VMs schon nachhaltig geschädigt haben kann.
Wie werden die Snapshots erstellt? Werden die VMs von diesem Automatismus stillgelegt, wie es Veeam macht, oder mit dem Kopf durch Wand im laufenden Betrieb? Letzteres kann VMs irreparabel beschädigen und endet genau in diesem Phänomen.
Zumal das automatisierte Erstellen und Löschen von Snapshots als Ersatz für eine temporäre Sicherung (wenn ich das richtig deute) eine fatale Zweckentfremdung und nicht "Sinn der Sache" ist ;)
- Snapshots sind verschieden definiert für jede Maschine (ERP VM bspw. alle 4 Stunden Snapshots), Temp i.o, kein Overloading vom CPU
genau, nein natürlich nicht wird automatisch erstellt, gelöscht etc.
wird automatisch erstellt, gelöscht etc.Dann ist das hier ein Punkt, der die VMs schon nachhaltig geschädigt haben kann.
Wie werden die Snapshots erstellt? Werden die VMs von diesem Automatismus stillgelegt, wie es Veeam macht, oder mit dem Kopf durch Wand im laufenden Betrieb? Letzteres kann VMs irreparabel beschädigen und endet genau in diesem Phänomen.
Zumal das automatisierte Erstellen und Löschen von Snapshots als Ersatz für eine temporäre Sicherung (wenn ich das richtig deute) eine fatale Zweckentfremdung und nicht "Sinn der Sache" ist ;)
Die Snapshots werden im laufenden Betrieb erstellt durch VEEAM und gesichert. Das bietet Veeam von Haus aus an und ich denke das dies auch andere Firmen so machen und dieses Problem nicht haben. Desweiteren ist ja zu beachten das sich die VM's unabhängig vom Backup/Snapshot aufhängen - sprich Sicherung um 20:00 läuft 20:05-10 abgeschlossen - VM hängt um 21:23 bspw.
Ok, dann war es vorhin etwas undeutlich, es hat sich für mich angelesen, dass ihr Veeam einsetzt und zusätzlich noch einen Automatismus/Skript laufen habt, der Snapshots erstellt.
Sind denn die VMWare-Tools auf den VMs installiert und aktuell? Verwendet ihr die VMXNET3-Netzwerkkarten?
Ansonsten bleiben dir nur noch die zwei oben genannten Punkte übrig, Firmware aktualisieren und ESXI-Installationen austauschen.
Wenn ihr danach immernoch Probleme habt, mit eurer Subscription den VMWare Support bemühen und mit denen die VMWare-Logs auseinander nehmen.
Sind denn die VMWare-Tools auf den VMs installiert und aktuell? Verwendet ihr die VMXNET3-Netzwerkkarten?
Ansonsten bleiben dir nur noch die zwei oben genannten Punkte übrig, Firmware aktualisieren und ESXI-Installationen austauschen.
Wenn ihr danach immernoch Probleme habt, mit eurer Subscription den VMWare Support bemühen und mit denen die VMWare-Logs auseinander nehmen.
Zitat von @chgorges:
Ok, dann war es vorhin etwas undeutlich, es hat sich für mich angelesen, dass ihr Veeam einsetzt und zusätzlich noch einen Automatismus/Skript laufen habt, der Snapshots erstellt.
Sind denn die VMWare-Tools auf den VMs installiert und aktuell? Verwendet ihr die VMXNET3-Netzwerkkarten?
Ja sind installiert und aktuell, ja wir nutzen die VMXNET3 Netzwerkkarten.
Ansonsten bleiben dir nur noch die zwei oben genannten Punkte übrig, Firmware aktualisieren und ESXI-Installationen austauschen.
Wenn ihr danach immernoch Probleme habt, mit eurer Subscription den VMWare Support bemühen und mit denen die VMWare-Logs auseinander nehmen.
Ok, dann war es vorhin etwas undeutlich, es hat sich für mich angelesen, dass ihr Veeam einsetzt und zusätzlich noch einen Automatismus/Skript laufen habt, der Snapshots erstellt.
Sind denn die VMWare-Tools auf den VMs installiert und aktuell? Verwendet ihr die VMXNET3-Netzwerkkarten?
Ja sind installiert und aktuell, ja wir nutzen die VMXNET3 Netzwerkkarten.
Ansonsten bleiben dir nur noch die zwei oben genannten Punkte übrig, Firmware aktualisieren und ESXI-Installationen austauschen.
Wenn ihr danach immernoch Probleme habt, mit eurer Subscription den VMWare Support bemühen und mit denen die VMWare-Logs auseinander nehmen.
Vielen Dank für die Hilfe !
hab auch esxi5.5 im einsatz.. veeam9 .. aber der macht keine Snapshots .. sondern VSS Sicherungen.
eventuell auch prüfen ob Anti-Virus (Agent) sich zerhakt / Zugriffsverletzungen..? Deadlock?
eventuell auch prüfen ob Anti-Virus (Agent) sich zerhakt / Zugriffsverletzungen..? Deadlock?
Ich würd mal das Windows Performance Toolkit installieren und ansonsten erstmal im Ereignisprotokoll des betreffenden Servers auf Auffälligkeiten scannen.
Das Performance Toolkot generiert pro Tag so um die 2 GB an Daten, die einem aber später helfen herauszufinden, woran es denn nun gelegen hat.
Ansonsten stochert man im Dunkeln, und wenn z.B. der "Windows Arbeitsstationsdienst" bzw. auf englisch "Workstation" nicht mehr läuft, dann schlagen jegliche Loginversuche fehl ohne daß ein Performanceproblem vorliegt.
Hab ich schon öfters mal gehabt.... Über RDP ist dann schlichtweg keine Anmeldung möglich, an der Konsole passiert dann nach einem ctrl+alt+del nichts mehr.
Das Performance Toolkot generiert pro Tag so um die 2 GB an Daten, die einem aber später helfen herauszufinden, woran es denn nun gelegen hat.
Ansonsten stochert man im Dunkeln, und wenn z.B. der "Windows Arbeitsstationsdienst" bzw. auf englisch "Workstation" nicht mehr läuft, dann schlagen jegliche Loginversuche fehl ohne daß ein Performanceproblem vorliegt.
Hab ich schon öfters mal gehabt.... Über RDP ist dann schlichtweg keine Anmeldung möglich, an der Konsole passiert dann nach einem ctrl+alt+del nichts mehr.
Sind das Windows 2008 R2 VMs?
Wir haben bei einigen Kunden (und einer eigenen VM) ein ähnliches Verhalten festgestellt. Allerdings waren die Systeme auch via Ping nicht mehr erreichbar. Letztendlich lag es an einen Windows Update, welches kann ich leider nicht exakt sagen, wurde aber kurz (1-3 Monate) vor dem erstmaligen auftreten installiert. Umgebung war in allen Fällen vSphere 5.5 mit 2008R2 VMs. Andere OS Versionen in der gleichen Umgebung waren nicht betroffen, auch nie mehrere Systeme gleichzeitig.
Wir haben bei einigen Kunden (und einer eigenen VM) ein ähnliches Verhalten festgestellt. Allerdings waren die Systeme auch via Ping nicht mehr erreichbar. Letztendlich lag es an einen Windows Update, welches kann ich leider nicht exakt sagen, wurde aber kurz (1-3 Monate) vor dem erstmaligen auftreten installiert. Umgebung war in allen Fällen vSphere 5.5 mit 2008R2 VMs. Andere OS Versionen in der gleichen Umgebung waren nicht betroffen, auch nie mehrere Systeme gleichzeitig.
