14
Sporadischer Ausfall physischer und virtueller Server (VMWare 5.5) im Netzwerk (anpingbar aber sonst ohne Funktion)
Hallo Gemeinde,
seit ein paar Tagen haben wir in der Firma immer wieder das Problem, dass einige unserer VMWare Gast- Server einfach so "stehen" bleiben. Die Server sind zwar noch anpingbar, aber weder via RDP noch via VMWare Konsole reagieren diese auf Eingaben.
Auf den Hosts laufen weitere Maschinen, welche ganz normal reagieren. Wir haben 3 FSC Hosts in Verbindung mit einem FSC Storage mit Anschliuss via FibreChannel, auf denen wir bereits die aktuellste Version von ESXI/VMWare 5.5. eingespielt haben. Auch der VCenter 5.5 Server (weiterer phys. FSC Server) ist aktuell. Auf den Gast-Servern läuft Windows 2012 / Windows 2008 R2, auch hier sind die aktuellen Windows Updates drauf (auch ohne bleiben die Server hängen)...
Wir haben unsere Server - Switche 2 x HP-1910-48G im Verdacht, verstehen aber nicht, warum alle anderen (phys. und virtuellen) Server und andere Geräte, welche auch an diesen Switchen (ua. weitere Switche via LWL deren Funktion nicht beeinträchtigt ist) hängen weiter funktionieren. Bisher war es einmal so, dass auch 2 der 3 VM-Hosts und der phys. DC und VCenter Server nicht mehr via Management / RDP / Konsole erreichbar waren, hier hat dann ein Neustart des Management-Network bzw. des ganzen Servers geholfen.
Auch funktionieren die Server nach einem Neustart wieder einige Tage um dann ohne Vorwarnung wieder "stehen" zu bleiben. Alle Logs die man so anschauen kann, sowohl Windows als auch VM,Hardware und Switch Logs loggen keine Fehler mit. Laut FSC laufen die Server, nach Auswertung der Logs durch FSC ganz normal, nur das diese halt via Netz nicht mehr erreichbar sind und via Konsole nicht mehr reagieren.
Hat Jemand eine Idee was das sein könnte - ich habe nun schon einige Sachen (siehe unten) ausprobiert und mir gehen langsam die Ideen aus, was ich noch machen kann... Auch mein Dienstleister, welcher u.a. die Netzwerkkonfig. vorgenommen hat, hat keine sinnvolllen Ideen mehr. Mein letzter Gedanke ist eine Art Überlastung der Switche, denn wenn ich meine Datensicherung im vollem Umfang laufen lasse, geht das Ganze schneller und betrifft mehr als nur ein paar Server, welche dann nicht mehr reagieren und neu gestartet werden müssen...
Folgendes haben wir schon gemacht:
- einspielen der letzten VM Updates (ESXI und VCenter)
- einspielen letzte Firmware Updates HW (für einsenden der Logs an FSC Voraussetzung)
- einspielen aktuelle Windows Updates via WSUS
- Check der SAN Verbindung
- Check der Netzwerkverkabelung und Konfig an den Servern
- Check der Switchports auf Fehler / Fehlkonfig (hier gab es keine auch kein Konfigänderung)
- Check DNS / DHCP Konfig im AD
- Tausch der Switchports der ESXI-Hosts
Vielen Dank für euren Input...
Stoey20
seit ein paar Tagen haben wir in der Firma immer wieder das Problem, dass einige unserer VMWare Gast- Server einfach so "stehen" bleiben. Die Server sind zwar noch anpingbar, aber weder via RDP noch via VMWare Konsole reagieren diese auf Eingaben.
Auf den Hosts laufen weitere Maschinen, welche ganz normal reagieren. Wir haben 3 FSC Hosts in Verbindung mit einem FSC Storage mit Anschliuss via FibreChannel, auf denen wir bereits die aktuellste Version von ESXI/VMWare 5.5. eingespielt haben. Auch der VCenter 5.5 Server (weiterer phys. FSC Server) ist aktuell. Auf den Gast-Servern läuft Windows 2012 / Windows 2008 R2, auch hier sind die aktuellen Windows Updates drauf (auch ohne bleiben die Server hängen)...
Wir haben unsere Server - Switche 2 x HP-1910-48G im Verdacht, verstehen aber nicht, warum alle anderen (phys. und virtuellen) Server und andere Geräte, welche auch an diesen Switchen (ua. weitere Switche via LWL deren Funktion nicht beeinträchtigt ist) hängen weiter funktionieren. Bisher war es einmal so, dass auch 2 der 3 VM-Hosts und der phys. DC und VCenter Server nicht mehr via Management / RDP / Konsole erreichbar waren, hier hat dann ein Neustart des Management-Network bzw. des ganzen Servers geholfen.
Auch funktionieren die Server nach einem Neustart wieder einige Tage um dann ohne Vorwarnung wieder "stehen" zu bleiben. Alle Logs die man so anschauen kann, sowohl Windows als auch VM,Hardware und Switch Logs loggen keine Fehler mit. Laut FSC laufen die Server, nach Auswertung der Logs durch FSC ganz normal, nur das diese halt via Netz nicht mehr erreichbar sind und via Konsole nicht mehr reagieren.
Hat Jemand eine Idee was das sein könnte - ich habe nun schon einige Sachen (siehe unten) ausprobiert und mir gehen langsam die Ideen aus, was ich noch machen kann... Auch mein Dienstleister, welcher u.a. die Netzwerkkonfig. vorgenommen hat, hat keine sinnvolllen Ideen mehr. Mein letzter Gedanke ist eine Art Überlastung der Switche, denn wenn ich meine Datensicherung im vollem Umfang laufen lasse, geht das Ganze schneller und betrifft mehr als nur ein paar Server, welche dann nicht mehr reagieren und neu gestartet werden müssen...
Folgendes haben wir schon gemacht:
- einspielen der letzten VM Updates (ESXI und VCenter)
- einspielen letzte Firmware Updates HW (für einsenden der Logs an FSC Voraussetzung)
- einspielen aktuelle Windows Updates via WSUS
- Check der SAN Verbindung
- Check der Netzwerkverkabelung und Konfig an den Servern
- Check der Switchports auf Fehler / Fehlkonfig (hier gab es keine auch kein Konfigänderung)
- Check DNS / DHCP Konfig im AD
- Tausch der Switchports der ESXI-Hosts
Vielen Dank für euren Input...
Stoey20
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 390318
Url: https://administrator.de/forum/sporadischer-ausfall-physischer-und-virtueller-server-vmware-5-5-im-netzwerk-anpingbar-aber-sonst-ohne-390318.html
Ausgedruckt am: 14.04.2025 um 03:04 Uhr
14 Kommentare
Neuester Kommentar
Moin,
Gruß,
Dani
Auf den Hosts laufen weitere Maschinen, welche ganz normal reagieren. Wir haben 3 FSC Hosts in Verbindung mit einem FSC SAN, auf denen wir bereits die aktuellste Version von ESXI/VMWare 5.5.
VMWare Support Case wird schwierig mit der Version - EoL, EoS. Wir haben unsere Server - Switche 2 x HP-1910-48G im Verdacht, verstehen aber nicht, warum alle anderen (phys. und virtuellen) Server und andere Geräte, welche auch an diesen Switchen (ua. weitere Switche via LWL deren Funktion nicht beeinträchtigt ist) hängen weiter funktionieren.
Erklär uns im Detail was auf den beiden Switches hängt. Sag bitte nicht, dass über der Datenverkehr LAN und/oder SAN laufen. Was nutzt ihr im SAN (iSCSI oder NFS)?Gruß,
Dani
Hallo,
schreib auch mal, wie die VMs ins Netzwerk eingebunden werden. Hat jede ihr Kabel oder einen virtuellen Switch? Haben die vielleicht mehrere Netzwerkinterfaces? Wie ist das LAN vom SAN getrennt?
Jedenfalls - Eventlogs der Server checken, auf Fehler und auf „was die in der Zeit so treiben“ Und die Switche überprüfen: STP? QOS?“
Grüße
lcer
schreib auch mal, wie die VMs ins Netzwerk eingebunden werden. Hat jede ihr Kabel oder einen virtuellen Switch? Haben die vielleicht mehrere Netzwerkinterfaces? Wie ist das LAN vom SAN getrennt?
Jedenfalls - Eventlogs der Server checken, auf Fehler und auf „was die in der Zeit so treiben“ Und die Switche überprüfen: STP? QOS?“
Grüße
lcer
Hi,
in den Windows Event-Logs steht leider gar nichts zielführendes, bis zur Ausfallzeit loggen diese ganz normale Events, danach geht es mit dem Neustart weiter... Die Dinger frieren einfach ein...
Gruß Stoey20
in den Windows Event-Logs steht leider gar nichts zielführendes, bis zur Ausfallzeit loggen diese ganz normale Events, danach geht es mit dem Neustart weiter... Die Dinger frieren einfach ein...
Gruß Stoey20
Hi,
die ESXI-Hosts haben mehrere VSwitche, da auch unterschiedliche VLAns benutzt werden. Einmal einen VSwitch mit 2 phys. NICS für das Management (im VLAN99 - bein uns Management) dann einen VSwitch für das Backup in einem eigenen VLAN mit 2 NICS und 2 VSwitche für die Server mit 2 unterschiedlichen VLANs mit je 2 NIC. Alle NICS laufen im Active / Standby Modus auf VMWare Seite. Diese Konfig ist auf allen drei Hosts gleich, kommt von unserem Dienstleister und läuft in dem Laden schon seit 2013, bevor ich dort angefangen habe zu arbeiten.
Um die Last zu verteilen, sind die ESXI auf beiden Switchen verteilt, also ESXI1 und 2 auf Switch 1 und ESXI3 auf Switch 2 mit den aktiven NIC und die Standby NIC hängen jeweils auf dem anderen Switch mit identischer Konfig. Auf den Switchen hängen zusätzlich noch weitere phys. Server wie der C oder der Backup Server, sowie andere Switche via LWL.Beide Switche untereinander sind via LWL miteinander verbunden. Die beiden sind quasi das Backbone.
Das Thema SAN habe ich eben nochmal korrigiert, wir haben eine FSC DX80 via FibreChannel, welche direkt an die 3 ESXI Hosts angeschlossen ist, auch hier mit je 2 Contollern. Also kein SAN, wie erst geschrieben... SRY für die Verwirrung...
Auch an den Switchen sieht man vor nach und während der ganzen Problematik keine wirklichen Fehler. ich kann gerne auch die Auszüge posten,,wenn ich wieder in der Firma bin...
Gruß
Stoey20
die ESXI-Hosts haben mehrere VSwitche, da auch unterschiedliche VLAns benutzt werden. Einmal einen VSwitch mit 2 phys. NICS für das Management (im VLAN99 - bein uns Management) dann einen VSwitch für das Backup in einem eigenen VLAN mit 2 NICS und 2 VSwitche für die Server mit 2 unterschiedlichen VLANs mit je 2 NIC. Alle NICS laufen im Active / Standby Modus auf VMWare Seite. Diese Konfig ist auf allen drei Hosts gleich, kommt von unserem Dienstleister und läuft in dem Laden schon seit 2013, bevor ich dort angefangen habe zu arbeiten.
Um die Last zu verteilen, sind die ESXI auf beiden Switchen verteilt, also ESXI1 und 2 auf Switch 1 und ESXI3 auf Switch 2 mit den aktiven NIC und die Standby NIC hängen jeweils auf dem anderen Switch mit identischer Konfig. Auf den Switchen hängen zusätzlich noch weitere phys. Server wie der C oder der Backup Server, sowie andere Switche via LWL.Beide Switche untereinander sind via LWL miteinander verbunden. Die beiden sind quasi das Backbone.
Das Thema SAN habe ich eben nochmal korrigiert, wir haben eine FSC DX80 via FibreChannel, welche direkt an die 3 ESXI Hosts angeschlossen ist, auch hier mit je 2 Contollern. Also kein SAN, wie erst geschrieben... SRY für die Verwirrung...
Auch an den Switchen sieht man vor nach und während der ganzen Problematik keine wirklichen Fehler. ich kann gerne auch die Auszüge posten,,wenn ich wieder in der Firma bin...
Gruß
Stoey20
Hallo,
anpingbar während eines Neustarts? Prüf mal, wen Du da anpingst.
Ansonsten, bei der Konfigurationphase von Windows Updates kann es zu ziemlich langen „Black Screen“ Zeiten kommen. Stehen Updates aus?
Was passiert, wenn Du Dich per KVM verbindest? Keine Verbindung oder schwarzer Bildschirm?
Grüße
lcer
anpingbar während eines Neustarts? Prüf mal, wen Du da anpingst.
Ansonsten, bei der Konfigurationphase von Windows Updates kann es zu ziemlich langen „Black Screen“ Zeiten kommen. Stehen Updates aus?
Was passiert, wenn Du Dich per KVM verbindest? Keine Verbindung oder schwarzer Bildschirm?
Grüße
lcer
Hi,
natürlich kein Ping während des Neustarts... Wir haben versucht die Geräte generell auf deren noch vorhandene Funktion zu testen. Das erste ist ja dann immer ein Ping... Wenn man die Geräte neu startet, sieht man auch, dass der Ping entsprechend erst mit Zeitüberschreitung und dann mit Zielhost nicht erreichbar ins Leere läuft und dann wieder aufgenommen wird...
Via KVWm bzw. VMWare Konsole sieht man den Windows Screen Drücken Sie STRG+ALT+ENTF sowie die aktuelle Uhrzeit, das System reagiert aber auf keine Eingaben...
Windows Updates stehen aktuell nicht an, diese verteilen wir via WSUS und die aktuellen Udpates wurden alle dediziert installiert und danach ein Neustart gemacht...
Erst nach einem Neustart reagieren die Server wieder ganz normal, bis zum nächsten "stehen" bleiben.
Gruß
Stoey20
natürlich kein Ping während des Neustarts... Wir haben versucht die Geräte generell auf deren noch vorhandene Funktion zu testen. Das erste ist ja dann immer ein Ping... Wenn man die Geräte neu startet, sieht man auch, dass der Ping entsprechend erst mit Zeitüberschreitung und dann mit Zielhost nicht erreichbar ins Leere läuft und dann wieder aufgenommen wird...
Via KVWm bzw. VMWare Konsole sieht man den Windows Screen Drücken Sie STRG+ALT+ENTF sowie die aktuelle Uhrzeit, das System reagiert aber auf keine Eingaben...
Windows Updates stehen aktuell nicht an, diese verteilen wir via WSUS und die aktuellen Udpates wurden alle dediziert installiert und danach ein Neustart gemacht...
Erst nach einem Neustart reagieren die Server wieder ganz normal, bis zum nächsten "stehen" bleiben.
Gruß
Stoey20
Aktuelle Uhrzeit und pingbar = Windows läuft. Dann sollte auch was im Ereignisprotokoll zu finden sein.
Grüße
lcer
Grüße
lcer
Hi,
anbei mal die Logs eines der Server, Ausfall war am 21.10.2018 16:16. da hat er sich zuletzt bei unseren ESET RemoteAdmin Server gemeldet... Neustart war dann gegen 19 Uhr.
Nach dem Neustart um 19 Uhr steht dann auch das der Server um 16:16 unerwartet herunter gefahren wurde... Ich nehme an, weil er nichts weiter loggen konnte...
Gruß
Stoey20
anbei mal die Logs eines der Server, Ausfall war am 21.10.2018 16:16. da hat er sich zuletzt bei unseren ESET RemoteAdmin Server gemeldet... Neustart war dann gegen 19 Uhr.
Nach dem Neustart um 19 Uhr steht dann auch das der Server um 16:16 unerwartet herunter gefahren wurde... Ich nehme an, weil er nichts weiter loggen konnte...
Gruß
Stoey20
Hallo,
läuft auf den von Abstürzen betroffenen Servern die selbe AV-Software? Oder sonstige Software die alle gemeinsam haben, mal von OS und den üblichen Applikationen abgesehen?
Gruß
dark.cube
läuft auf den von Abstürzen betroffenen Servern die selbe AV-Software? Oder sonstige Software die alle gemeinsam haben, mal von OS und den üblichen Applikationen abgesehen?
Gruß
dark.cube
Hi,
ja auf allen läuft ein Virenscanner von ESET für Windows Server, testweise auf einem der Server in der aktuellsten Version, um auch das auszuschließen...
Gruß
Stoey20
ja auf allen läuft ein Virenscanner von ESET für Windows Server, testweise auf einem der Server in der aktuellsten Version, um auch das auszuschließen...
Gruß
Stoey20
Moin,
wenn die VM anpingbar ist, aber sonst nicht mehr "läuft" könnte das Problem auch vom Storage kommen. Was loggen denn die ESXi und/oder der vCenter zu dem Thema? Wie sehen die Disk-Latenzen aus?
Und was bisher auch noch nicht erwähnt wurde:
- Sind die VMWare Tools in den VMs aktuell?
- Haben die VMs noch eine e1000 vNIC konfiguriert? Wenn ja, umstellen auf vmxnet3
lg,
Slainte
wenn die VM anpingbar ist, aber sonst nicht mehr "läuft" könnte das Problem auch vom Storage kommen. Was loggen denn die ESXi und/oder der vCenter zu dem Thema? Wie sehen die Disk-Latenzen aus?
Und was bisher auch noch nicht erwähnt wurde:
- Sind die VMWare Tools in den VMs aktuell?
- Haben die VMs noch eine e1000 vNIC konfiguriert? Wenn ja, umstellen auf vmxnet3
lg,
Slainte
Hi,
der ESXI/VCenter loggt leider auch nichts mit, sagt der Dienstleister. Für den laufen die Maschinen, bis man diese via Konsole oder Gastbefehlen anspricht. Sonst sehen wir auch keine Fehler oder Hinweise im Log. Auch haben wir die Disk - Latenzen mit getriggert und auch hier ist noch den Loggings alles OK - (sagt auch FSC, diese haben die Logs im Rahmen eines HW Calls ausgewertet). Auf allen physischen Servern und dem Storage sind auch die Firmware der FibreChannel Adapter und das BIOS aktuell (letzter verfügbarer Herstellerstand) - verlangt der Hersteller ja im ersten Schritt eines Calls...
Ach ja während einige Maschinen ausfallen, sind andere auf dem gleichen Host sowie mit dem gleichen Datastore verfügbar. Die Datastores lassen sich auch alle browsen. Auch gibt der jew. ESXI-Host sonst keine Hinweise auf eine nicht verfügbare Source.
Wir haben die aktuellsten verfügbaren VMWare Tools installiert. Auch sind auf allen Maschinen die VMXNET3 Adapter konfiguriert. Wir haben diese sogar nach einem VMWare KB Artikel nach Installation der letzten Tool Version noch einmal komplett entfernt und neu hinzukonfiguriert... Waren ja eh ausgefallen, da kam es auf die 15 Minuten mehr Downtime nicht mehr an...
Gruß
Stoey20
der ESXI/VCenter loggt leider auch nichts mit, sagt der Dienstleister. Für den laufen die Maschinen, bis man diese via Konsole oder Gastbefehlen anspricht. Sonst sehen wir auch keine Fehler oder Hinweise im Log. Auch haben wir die Disk - Latenzen mit getriggert und auch hier ist noch den Loggings alles OK - (sagt auch FSC, diese haben die Logs im Rahmen eines HW Calls ausgewertet). Auf allen physischen Servern und dem Storage sind auch die Firmware der FibreChannel Adapter und das BIOS aktuell (letzter verfügbarer Herstellerstand) - verlangt der Hersteller ja im ersten Schritt eines Calls...
Ach ja während einige Maschinen ausfallen, sind andere auf dem gleichen Host sowie mit dem gleichen Datastore verfügbar. Die Datastores lassen sich auch alle browsen. Auch gibt der jew. ESXI-Host sonst keine Hinweise auf eine nicht verfügbare Source.
Wir haben die aktuellsten verfügbaren VMWare Tools installiert. Auch sind auf allen Maschinen die VMXNET3 Adapter konfiguriert. Wir haben diese sogar nach einem VMWare KB Artikel nach Installation der letzten Tool Version noch einmal komplett entfernt und neu hinzukonfiguriert... Waren ja eh ausgefallen, da kam es auf die 15 Minuten mehr Downtime nicht mehr an...
Gruß
Stoey20
