Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

Exchange 2016 Server unexpected reboots

Alles zum Thema vSphere 6.5, ESXi 6.5 und vCenter Server.

Moderatoren: irix, Dayworker

Member
Beiträge: 212
Registriert: 02.06.2007, 19:45

Exchange 2016 Server unexpected reboots

Beitragvon Mr.Schrotti » 30.03.2018, 16:50

Moin,

wir haben 3 Windows Server 2016 mit jeweils Exchange 2016 installiert.
Diese laufen zusammen mit rund 60 anderen Windows & Linux VMs auf unserem VMWare vSphere 6.5 Cluster (bestehend aus 4 Hosts und als Storage betreiben wir vSAN)

Nun haben mir NUR mit den 3 Exchange Servern das Problem das sie in der letzten zeit mind. einmal durch einen Fehler neugestartet sind.
Den MINIDUMP habe ich natürlich ausgewertet, daraus geht nur folgendes hervor:

Code: Alles auswählen

uptime: 37 days, 06:11:05
This was probably caused by the following module: memory_corruption.sys (memory_corruption)
Bugcheck code: 0x1A (0x3F, 0x3DC33, 0x175BDF2B, 0xD74ECC2F)
Error: MEMORY_MANAGEMENT


Wie gesagt auf allen 3 Servern das selbe, alle anderen laufen Problemlos... nun habe ich in die logs der VM geschaut, dort steht folgendes...
Das seltsame ist, stunden davor wurde nix geloggt....

Code: Alles auswählen

2018-03-28T15:08:37.462Z| vcpu-1| W115: WinBSOD: Synthetic MSR[0x40000100] 0x1a
2018-03-28T15:08:37.462Z| vcpu-1| W115:
2018-03-28T15:08:37.463Z| vcpu-1| W115: WinBSOD: Synthetic MSR[0x40000101] 0x3f
2018-03-28T15:08:37.463Z| vcpu-1| W115:
2018-03-28T15:08:37.463Z| vcpu-1| W115: WinBSOD: Synthetic MSR[0x40000102] 0xc43b4
2018-03-28T15:08:37.463Z| vcpu-1| W115:
2018-03-28T15:08:37.463Z| vcpu-1| W115: WinBSOD: Synthetic MSR[0x40000103] 0x8f46a43c
2018-03-28T15:08:37.463Z| vcpu-1| W115:
2018-03-28T15:08:37.463Z| vcpu-1| W115: WinBSOD: Synthetic MSR[0x40000104] 0xca1b4b54
2018-03-28T15:08:37.463Z| vcpu-1| W115:
2018-03-28T15:08:38.463Z| svga| I125: SVGA-ScreenMgr: Screen type changed to RegisterMode
2018-03-28T15:08:39.092Z| vcpu-1| I125: LSI: Invalid PageType [21] pageNo 0 Action 0
2018-03-28T15:08:48.865Z| vmx| I125: GuestRpcSendTimedOut: message to toolbox-dnd timed out.
2018-03-28T15:08:53.359Z| vmx| I125: GuestRpcSendTimedOut: message to toolbox timed out.
2018-03-28T15:08:58.470Z| vcpu-0| I125: Tools: Tools heartbeat timeout.
2018-03-28T15:08:58.470Z| vcpu-0| I125: Tools: Running status rpc handler: 1 => 0.
2018-03-28T15:08:58.470Z| vcpu-0| I125: Tools: Changing running status: 1 => 0.


Der letzte Logeintrag vor ist:

Code: Alles auswählen

2018-03-27T20:12:50.993Z| vcpu-0| I125: DISKLIB-CHAIN : DiskChainUpdateContentID: old=0x4e82769f, new=0x38e47977 (f38f288869cc38d8e3531f8238e47977)



Ich habe grade keine Idee wonach ich noch schauen kann um die Ursache zu beheben ... Noch jemand eine Idee für mich?

edit: angepasst, falsche uhrzeit geschaut daher falsche logs kopier ....


Gruß
Tobias

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: Exchange 2016 Server unexpected reboots

Beitragvon Dayworker » 30.03.2018, 18:53

Genau das ist das Problem mit gekürzten Logs. Wenn ich nämlich nach "WinBSOD: Synthetic MSR[0x40000103]" suche, lande ich unter anderem im VMTN-Thread WinBSOD Code decipher und dieser offenbart ein fehlschlagendes CPU-Microcodeupdate. Sieht für mich danach aus, daß die Win-Server bezüglich Meltdown & Spectre aktiv werden und die entsprechenden M$-Updates ausrollen.



[edit]
Falls ich damit Recht habe, hat "mbreidenbach" im Thread Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche bereit seinen Weg für Winserver2k12R2 beschrieben.

Member
Beiträge: 212
Registriert: 02.06.2007, 19:45

Re: Exchange 2016 Server unexpected reboots

Beitragvon Mr.Schrotti » 30.03.2018, 20:50

mhhh das war auch einer meiner gedanken ... aber von Microcode steht im log nix. Würde mich bei den Zeiten auch wundern, da wir Updates manuell einspielen und nicht automatisch installieren lassen....

Auffallend ist halt die Lücke in den logs, die sich übrigens auch in den Windows Logs wiederspiegelt.

Ich hab das log mal von 2 der betroffenen Server bei uns hochgeladen, ist leider zu groß für PasteBin oder für einen Anhang:
Server 1: https://cloud.bs.fraunhofer.de/index.ph ... adcDL5KcSf
Server 2: https://cloud.bs.fraunhofer.de/index.ph ... nYz4MWtTzF


Bei beiden treten die WinBSOD Fehler auf, bei Server 2 sogar mehrfach.

Experte
Beiträge: 1823
Registriert: 04.10.2011, 14:06

Re: Exchange 2016 Server unexpected reboots

Beitragvon JustMe » 31.03.2018, 10:53

Zuerst einmal: Solche (Text-)Log-Dateien lassen sich vortrefflich komprimieren. Dann klappt's auch mit dem hoch- (und runter-) laden besser. Z.B. mit Info-ZIP 3.0 verbleiben dann nur noch 3.637.722 Bytes statt 38.799.651 zu transferieren.

Dann:
Die Nummern in Klammern hinter "MSR" sind wohl nur Index-Nummern des Registers. Erst die Werte RECHTS der schliessenden Klammer werden interessant. Und da ist im VMTN-Artikel von einem Stop 0x9E zu lesen, waehrend hier (immer wieder, wie bereits angemerkt) ein Stop 0x1A auftritt.

Was mir persoenlich auffaellt ist, dass die VM-Abstuerze alle auf "vSphere-02" passieren. Kannst Du das mal mit den anderen evtl. vorliegenden Faellen verifizieren?

Wegen der indizierten Memory_Management Problematik wuerde ich deshalb vielleicht auch mal die HW-Logs dieses Hosts pruefen.

Dann bin ich etwas erstaunt, dass der abgebende Host 192.168.10.14 am 2017-10-26T08:38:33.782Z noch Build 6765664 hatte, aber um 15:48:52.255Z auf Build 7388607 lief. Habt Ihr da automatische Updates konfiguriert? Falls ja, und auch sonst: Warum laeuft der vSAN-Member vSphere-02 am 30.3. immer noch mit dem alten Build?

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: Exchange 2016 Server unexpected reboots

Beitragvon Dayworker » 31.03.2018, 13:14

Ich bin noch nicht wirklich dazu gekommen, mir die Logs umfassend anzusehen, aber zur Upload-Funktion muß ich ein paar Worte verlieren und daher:

Bild
Der Upload ist auf wenige Dateiformate, eine bestimmte Dateigrösse und ausserdem auf eine maximale Anzahl von Dateianhängen beschränkt. Die momentan konfigurierte, maximal zulässige Grösse ist in meiner Signatur ersichtlich und somit deutlich kleiner als das komprimierte Log-2.
Mir sind ehrlich gesagt externe Verlinkungen weiterhin lieber, als die Uploads hier im Forum, weil die Daten dann gefühlt weiter unter alleiniger Kontrolle des Uploaders bleiben und auch der Platzverbrauch bzw genauer der Freie Speicherplatz auf dem Server irrelevant ist. Falls man zudem auch noch an anderen Stellen nachfragt, spart man sich weitere Uploads und nicht nur ich habe vermutlich meine Uploads gerne alle an einer Stelle beisammen.

Member
Beiträge: 212
Registriert: 02.06.2007, 19:45

Re: Exchange 2016 Server unexpected reboots

Beitragvon Mr.Schrotti » 31.03.2018, 13:17

JustMe hat geschrieben:Dann:
Die Nummern in Klammern hinter "MSR" sind wohl nur Index-Nummern des Registers. Erst die Werte RECHTS der schliessenden Klammer werden interessant. Und da ist im VMTN-Artikel von einem Stop 0x9E zu lesen, waehrend hier (immer wieder, wie bereits angemerkt) ein Stop 0x1A auftritt.

Was mir persoenlich auffaellt ist, dass die VM-Abstuerze alle auf "vSphere-02" passieren. Kannst Du das mal mit den anderen evtl. vorliegenden Faellen verifizieren?

Alle 3 Exchange laufen auf vSphere-02 (unglücklich und sollte so eigentlich auch nicht sein)... Aber es laufen noch zahlreiche andere VMs auf diesem Host die keine Probleme machen.


Wegen der indizierten Memory_Management Problematik wuerde ich deshalb vielleicht auch mal die HW-Logs dieses Hosts pruefen.

Leider existieren von dem Datum keine VMkernel Logs mehr ....

JustMe hat geschrieben:Dann bin ich etwas erstaunt, dass der abgebende Host 192.168.10.14 am 2017-10-26T08:38:33.782Z noch Build 6765664 hatte, aber um 15:48:52.255Z auf Build 7388607 lief. Habt Ihr da automatische Updates konfiguriert? Falls ja, und auch sonst: Warum laeuft der vSAN-Member vSphere-02 am 30.3. immer noch mit dem alten Build?


Wir haben angefangen die Hosts zu patchen, dabei sind jedoch bei manchen Hosts Probleme mit dem UpdateManager aufgetreten. Dazu ist aktuell noch ein Fall bei VMware Offen... daher die unterschiedlichen Stände.

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: Exchange 2016 Server unexpected reboots

Beitragvon Dayworker » 31.03.2018, 13:46

Wenn ihr eh schon einen Case bei VMware offen habt, würde ich die Reboots auch dem Support vor die Füsse werfen und dabei erwähnen, daß bei Euch die Produktion stillsteht. Des weiteren dürfte es sehr hilfreich sein, alle unternommenen Schritte schriftlich zu dokumentieren.

Member
Beiträge: 212
Registriert: 02.06.2007, 19:45

Re: Exchange 2016 Server unexpected reboots

Beitragvon Mr.Schrotti » 31.03.2018, 14:24

joa ich bin zwar kein Fan vom VMware Support aber ich hab da bereits ein Case aufgemacht...
allerdings nicht als komplett crash da ich über die Ostertage nicht sicherstellen kann das ich immer telefonisch erreichbar bin ;)

Die Exchange Server haben wir die Woche wieder zusammengeflickt .... die haben durch die Fehler ziemlich gelitten und mochten ihre Datenbanken nicht mehr :x

Experte
Beiträge: 1823
Registriert: 04.10.2011, 14:06

Re: Exchange 2016 Server unexpected reboots

Beitragvon JustMe » 31.03.2018, 14:25

Sorry, kleiner Interpretationsfehler meinerseits: Der 192.168.10.14 hatte im Oktober letzten Jahres (!) noch die alte Version. Aber der "DAG-01" ist laut Log (auch?) am 26.03.2018 von diesem Host gekommen.

Dann eine kleine Korrektur in der anderen Richtung: mit "HW-Logs" sind NICHT die vmkernel.logs gemient, sondern (H)ard(w)are Logs. ;-)
Das aber nur pro forma; ein echter Hinweis in dieser Richtung ist das "Memory Management" Problem im Windows des Gastes eigentlich nicht.

Drei Knoten einer Exchange DAG auf einem einzelnen Host, und dann auch noch ein vSAN darunter? Ihr muesst echt einen sehr guten Draht zu Eurer bevorzugten Gottheit unterhalten...

Oder die Group erstreckt sich noch auf etliche weitere Lokationen, und dann ware die Frage, wo ueberall genau die Abstuerze zu sehen sind bzw. waren.

Der Support von VMware wird hier vmtl. nur erst einmal auf die Best Practices verweisen :-)

PS: Und das ist die Bestaetigung des obig geschriebenen :-)

Member
Beiträge: 212
Registriert: 02.06.2007, 19:45

Re: Exchange 2016 Server unexpected reboots

Beitragvon Mr.Schrotti » 31.03.2018, 14:37

JustMe hat geschrieben:Sorry, kleiner Interpretationsfehler meinerseits: Der 192.168.10.14 hatte im Oktober letzten Jahres (!) noch die alte Version. Aber der "DAG-01" ist laut Log (auch?) am 26.03.2018 von diesem Host gekommen.

Dann eine kleine Korrektur in der anderen Richtung: mit "HW-Logs" sind NICHT die vmkernel.logs gemient, sondern (H)ard(w)are Logs. ;-)
Das aber nur pro forma; ein echter Hinweis in dieser Richtung ist das "Memory Management" Problem im Windows des Gastes eigentlich nicht.

Also die Hardware Logs sind sauber, da ist nix drin.

JustMe hat geschrieben:Drei Knoten einer Exchange DAG auf einem einzelnen Host, und dann auch noch ein vSAN darunter? Ihr muesst echt einen sehr guten Draht zu Eurer bevorzugten Gottheit unterhalten...

Oder die Group erstreckt sich noch auf etliche weitere Lokationen, und dann ware die Frage, wo ueberall genau die Abstuerze zu sehen sind bzw. waren.


Wir haben 2 Cluster, ein vSAN Cluster und dann noch ein Cluster mit iSCSI Storage.
Der Plan ist eigentlich das mind. ein DAG Knoten auch auf dem iSCSI Cluster laufen soll.
Da haben wir grade eine Storage Erweiterung bekommen damit ein Exchange dort noch ein Plätzchen bekommt ;)
Das aktuell alle Exchange auf einem Host laufen ist nicht beabsichtigt... da hat scheinbar jemand nicht aufgepasst :oops:

Das klingt so als wenn du von vSAN nicht so angetan bist :D

Experte
Beiträge: 1362
Registriert: 30.03.2009, 17:13

Re: Exchange 2016 Server unexpected reboots

Beitragvon UrsDerBär » 02.04.2018, 12:42

Mr.Schrotti hat geschrieben:Das klingt so als wenn du von vSAN nicht so angetan bist :D

Das dürfte weniger mit dem Produkt an sich sondern viel eher mit der eigentlich - sorry klingt hart - unsinnigen Ausrollung zu tun haben.

Exchange mit mehreren DAG's ist gemacht für eine Verteilung auf möglichst unabhängige Hardware mit gleichem Datenstand. vSAN macht - im weitesten Sinne - ungefähr das gleiche wenn auch auf eine andere Art und auf einer anderen Ebene. Damit es stimmig wäre, müsste pro DAG ein eigenes vSAN her.

Fazit: Du nimmst eine komplexe Technologie zur Auftrennung der Abhängigkeiten von gemeinsamer Hardware (DAG), führst den Kram auf Dateisystemebene mit einer zweiten sehr komplexen Technolgie wieder zusammen (vSAN) diese wiederum verteilt ihre Daten auf mehrere Hosts. Das ganze komplettierst Du mit einer weiteren komplexen Technologie - der Virtualisierung - auf dem gleichen Host.


Zurück zu „vSphere 6.5“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 15 Gäste