ESXi6 stürzt ab, brauche Hilfe bei den Logs
Servus;
Ich bräuchte eure Hilfe beim Auslesen der Logs.
Erstmal zur Umgebung:
ESXi1 & ESXi2: IBM 3650 M4 (sind in einem Cluster zusammengefasst) [2x 2620V2; 128GB RAM]
ESXi3: Lenovo 3650 M5 (funktioniert bis jetzt ohne Probleme) [2x 2630V3; 128GB RAM]
1x Synology 815RP+ 4x 4TB WD RED PRO RAID10 als Datastore per iSCSI; da liegen alle Server drauf (wenn das QNAP fertig ist, wird das bisl entlastet)
1x QNAP 469U-RP, ist aber eh leer, und wird diese Woche noch komplett neu gemacht, auch iSCSI
Bei allen ist ESXi 6.0.0 drauf.
Das System läut seit der Erstinstallation tadellos.
Nun stürzt ungefähr einmal in der Woche einer der M4 ab.
Den abgestützten ESX kann ich allerdings pingen, ich kann auch per SSH zugreifen, jedoch nimmt er keine Befehle entgegen, sprich ein "Reboot" zb nimmt er nicht an.
Genauso wenn ich direkt per Tastatur per "F11" auf reboot gehe, passiert dies nie.
Wenn ich dann neustarte (Strom weg), lauft er wieder ganz normal.
Gemanaged wird das ganze über das vcenter das virtuell auf einen der ESX liegt.
Es wird auch VMWare Horizon genutzt, ein Pool mit 30 Win8, ein Pool mit Win10 die liegen auf den internen HDDs der Server
Meine Vermutung ist eigentlich dass eine VM Schuld an den abstürzen ist, ist das überhaupt möglich?
Was ist auf den M4 ESXi so drauf? Alles
Fast alle Server sind 2012R2.
-2x DC (DHCP, DNS)
-1x DC alt (Server 2008R2), kommt bald weg
-Fileserver
-Printserver
-Radiusserver
-2x so "Connectionsserver für Horizon für intern und extern
-3x Webserver (irgendwelche Linux)
-30 Win8
-20 Win10
-Backupserver mit Veeam (kommt auch bald weg)
-vcenter (2008R2)
-Sophos UTM (kommt bald weg und auf eigene Hardware)
-WDS
-WSUS
-Verwaltungsfileserver + SQL
Auf dem M5 ESXi
3x Multipoint 2012
1x Multipoint 2016
Der letzte Ausfall müsste am 03.02.2017 um 16:27 passiert sein.
Logs:
https://drive.google.com/drive/folders/0B05q-RBIl_KpNS1NLS0zUDlXRnc?usp= ...
Ich bräuchte eure Hilfe beim Auslesen der Logs.
Erstmal zur Umgebung:
ESXi1 & ESXi2: IBM 3650 M4 (sind in einem Cluster zusammengefasst) [2x 2620V2; 128GB RAM]
ESXi3: Lenovo 3650 M5 (funktioniert bis jetzt ohne Probleme) [2x 2630V3; 128GB RAM]
1x Synology 815RP+ 4x 4TB WD RED PRO RAID10 als Datastore per iSCSI; da liegen alle Server drauf (wenn das QNAP fertig ist, wird das bisl entlastet)
1x QNAP 469U-RP, ist aber eh leer, und wird diese Woche noch komplett neu gemacht, auch iSCSI
Bei allen ist ESXi 6.0.0 drauf.
Das System läut seit der Erstinstallation tadellos.
Nun stürzt ungefähr einmal in der Woche einer der M4 ab.
Den abgestützten ESX kann ich allerdings pingen, ich kann auch per SSH zugreifen, jedoch nimmt er keine Befehle entgegen, sprich ein "Reboot" zb nimmt er nicht an.
Genauso wenn ich direkt per Tastatur per "F11" auf reboot gehe, passiert dies nie.
Wenn ich dann neustarte (Strom weg), lauft er wieder ganz normal.
Gemanaged wird das ganze über das vcenter das virtuell auf einen der ESX liegt.
Es wird auch VMWare Horizon genutzt, ein Pool mit 30 Win8, ein Pool mit Win10 die liegen auf den internen HDDs der Server
Meine Vermutung ist eigentlich dass eine VM Schuld an den abstürzen ist, ist das überhaupt möglich?
Was ist auf den M4 ESXi so drauf? Alles
Fast alle Server sind 2012R2.
-2x DC (DHCP, DNS)
-1x DC alt (Server 2008R2), kommt bald weg
-Fileserver
-Printserver
-Radiusserver
-2x so "Connectionsserver für Horizon für intern und extern
-3x Webserver (irgendwelche Linux)
-30 Win8
-20 Win10
-Backupserver mit Veeam (kommt auch bald weg)
-vcenter (2008R2)
-Sophos UTM (kommt bald weg und auf eigene Hardware)
-WDS
-WSUS
-Verwaltungsfileserver + SQL
Auf dem M5 ESXi
3x Multipoint 2012
1x Multipoint 2016
Der letzte Ausfall müsste am 03.02.2017 um 16:27 passiert sein.
Logs:
https://drive.google.com/drive/folders/0B05q-RBIl_KpNS1NLS0zUDlXRnc?usp= ...
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 328578
Url: https://administrator.de/contentid/328578
Ausgedruckt am: 26.11.2024 um 04:11 Uhr
14 Kommentare
Neuester Kommentar
Moin,
da die 3650M4 ja alle seitens vmWare supportet sind und ihr ja zwangsläufig auch vmWare-Softwaresubscriptions habt:
Zieh zuerst mal auf allen Servern die Firmwares auf den aktuellen Stand.
Tipp: Bootable Media Creator und dann sicherlich als Maschine die 7915 für die M4
Denn spätestens, wenn du IBM/ vmWare ins Boot holen tätest, wird das deren erste Antwort sein...
da die 3650M4 ja alle seitens vmWare supportet sind und ihr ja zwangsläufig auch vmWare-Softwaresubscriptions habt:
Zieh zuerst mal auf allen Servern die Firmwares auf den aktuellen Stand.
Tipp: Bootable Media Creator und dann sicherlich als Maschine die 7915 für die M4
Denn spätestens, wenn du IBM/ vmWare ins Boot holen tätest, wird das deren erste Antwort sein...
Ja, das befürchte ich eigentlich dass die als erster sagen "bitte auf aktuellen Stand bringen".
Will ich aber derzeit noch vermeiden, hab eher schlechte Erfahrungen gemacht mit ESXi updaten.
Danke schonmal für den Tipp mit dem BMC.
Will ich aber derzeit noch vermeiden, hab eher schlechte Erfahrungen gemacht mit ESXi updaten.
Danke schonmal für den Tipp mit dem BMC.
Ach, das Updaten der IBM-Hardware ist easy going.
Das mache ich 2-3x im Jahr mithilfe der o.g. BMC
- ESXI in den Wartungsmodus
- ESXi neustarten und von DVD booten
- den Assistenten folgen
- Nach dem Update alles wieder starten und es läuft.
- Wartungsmodus beenden
Anschließend das ESXi - OS selbst noch updaten (bei uns allerdings aktuell noch Version 5.5 U3) und gut...
Nach dem Schema verfahre ich, seitdem ich mich mit vmWare beschäftige, in meinem Fall seit Version 4.1...
Und das hilft dir bei deinem aktuellen Problem wie weit? ;)
Wie meine Vorgänger schon sagten, Firmware auf allen Servern aktualisieren, IBM-RAIDs und -Konsistenzen prüfen, Synology-Firmware aktualisieren, Synology-RAID und -Konsistenz prüfen.
Ansonsten ist hoffentlich der IBM-Custom-ESXi installiert und nicht die VMWare Global-Installation.
Zudem schmipft der Log über die Datastore-Performance. Siehe obige Prüfungen.
Dass die Pools/Multipoints auf nem RAID0 liegen, war hoffentlich ein Scherz?
Hi,
mal so ins Blaue geschossen: In den Logs ist ja zu sehen, dass die Datastores immer mal sehr langsam reagieren bzw. hohe Latenzen haben. Leider führt ein Fehler bei der Datastoreverbindung bei VMware fast immer zu den von dir beschriebenen Symptomen (ping und ssh geht, sonst reagiert aber nix mehr). Ich würde daher an erste Stelle ein Performanceproblem des Storage als Ursache sehen. Alternativ könnte auch die Verwendung von ATS ein Problem sein, wenn dein Storage das nicht sauber unterstützt. So raten viele große Hersteller (z.B. IBM bei SVC oder V7000 FC SAN) noch immer dazu, ATS zu deaktivieren. Bei uns hat das Umstellen auf die korrekte Firmware/Treiber Kombination (HCL lesen!) und das deaktivieren von ATS eine Veränderung von fast täglichen Ausfällen zu einer stabilen Umgebung gebracht.
Edit: Ansonsten wenn ihr eine VMware Subscription habt: Nutzt sie! Sobald ein Host das nächste Mal hängt ein Prio1 Ticket aufmachen. Nach im Schnitt 7-9 Minuten habe ich einen fähigen Engineer am Ohr der direkt mit mir auf das Problem guckt.
mal so ins Blaue geschossen: In den Logs ist ja zu sehen, dass die Datastores immer mal sehr langsam reagieren bzw. hohe Latenzen haben. Leider führt ein Fehler bei der Datastoreverbindung bei VMware fast immer zu den von dir beschriebenen Symptomen (ping und ssh geht, sonst reagiert aber nix mehr). Ich würde daher an erste Stelle ein Performanceproblem des Storage als Ursache sehen. Alternativ könnte auch die Verwendung von ATS ein Problem sein, wenn dein Storage das nicht sauber unterstützt. So raten viele große Hersteller (z.B. IBM bei SVC oder V7000 FC SAN) noch immer dazu, ATS zu deaktivieren. Bei uns hat das Umstellen auf die korrekte Firmware/Treiber Kombination (HCL lesen!) und das deaktivieren von ATS eine Veränderung von fast täglichen Ausfällen zu einer stabilen Umgebung gebracht.
Edit: Ansonsten wenn ihr eine VMware Subscription habt: Nutzt sie! Sobald ein Host das nächste Mal hängt ein Prio1 Ticket aufmachen. Nach im Schnitt 7-9 Minuten habe ich einen fähigen Engineer am Ohr der direkt mit mir auf das Problem guckt.
"Warum" der Host nicht wieder zurückkommen, kann ich dir nicht sagen. Dass es aber so ist, kann ich bestätigen. Solange ich mit VMware arbeite, war es schon immer so, dass man einen Host mindestens durchbooten oder sogar hart ausschalten musste, wenn einmal der Storage kurz hing. Der einzige Fall, in dem das nicht (zwingend) passiert ist bei NFS Storage. Dieser kann manchmal wiederverbunden werden.
Aber nochmals die Empfehlung: Hole dir den VMware Support dazu sobald es hängt. Du wirst überrascht sein, wie professionell und hilfreich so ein Anruf und eine kurze Teamviewer Session mit einem Experten sein kann. Auch wenn ich durchaus sehr fit in VMware bin, wurde ich im letzten Monat in 5 von 6 Tickets absolut überzeugt.
Aber nochmals die Empfehlung: Hole dir den VMware Support dazu sobald es hängt. Du wirst überrascht sein, wie professionell und hilfreich so ein Anruf und eine kurze Teamviewer Session mit einem Experten sein kann. Auch wenn ich durchaus sehr fit in VMware bin, wurde ich im letzten Monat in 5 von 6 Tickets absolut überzeugt.