none
2008R2 SP1/ Kritisches Problem- Server wird unerwartet heruntergefahren nach SP1 Installation RRS feed

  • Frage

  • Einen schönen guten Tag,

    wir haben hier ein recht kritisches Problem nachdem wir am Wochenende ein Update auf das Server 2008 R2 SP1 durchgeführt haben.

    Umgebung: XenServer FeaturePack1, 1 Pool aus 3 Notes. Das Problem tritt auf zwei XenServern auf die auf verschiedener Hardware laufen.

    Wie schon erwähnt, am Wochenende wurde u.a. das SP1 für MS Server 2008 R2 installiert, seit diesem Zeitpunkt hängen sich die (bis jetzt zwei) Server nachts auf und sind NUR noch durch ping erreichbar. Remote Registry oder Remote-Dienste lassen sich nicht mehr abrufen.

    Ich vermute, dass er versucht sich herunterzufahren oder zu starten, aber dann hängen bleibt.

     

    Nun die Ereigniseinträge eines aktuellen Falles auf einem SQL Server:

    Seltsamer Eintrag obwohl niemand am Server war:
    Kernel-General; Ereignis ID12:

    Das Betriebssystem wurde zur Systemzeit ‎2011‎-‎08‎-‎18T07:37:03.359600000Z gestartet.

    Nachdem der Server hing, wurde er Zwangsneugestartet mit der (nachvollziehbaren) Meldung:
    Das System wurde zuvor am ‎18.‎08.‎2011 um 09:33:04 unerwartet heruntergefahren.

    Dazwischen: nichts..

    Mich irritiert dabei die Uhrzeit.

    Gleiches Phänomen auf dem Exchangeserver.
    Der einzige manuelle Eingriff fand um ca. 07:30 statt, da dort wieder der Server hing und wir ihn manuell neustarten mussten.

    Protokollname: System
    Quelle:        EventLog
    Datum:         18.08.2011 07:25:58
    Ereignis-ID:   6008
    Aufgabenkategorie:Keine
    Ebene:         Fehler
    Schlüsselwörter:Klassisch
    Benutzer:      Nicht zutreffend
    Computer:      exch01.awo-bielefeld.local
    Beschreibung:
    Das System wurde zuvor am ‎18.‎08.‎2011 um 06:52:56 unerwartet heruntergefahren.
    Ereignis-XML:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="EventLog" />
        <EventID Qualifiers="32768">6008</EventID>
        <Level>2</Level>
        <Task>0</Task>
        <Keywords>0x80000000000000</Keywords>
        <TimeCreated SystemTime="2011-08-18T05:25:58.000000000Z" />
     
    Es sind auch keine Tasks vorhanden und das Eventlog bleibt bis auf diese Meldungen leer.

    Die Ressourcen bleiben auch noch beständig laut XenCenter, weder Speicher noch CPU oder HDD sind stark belastet während dieser Zeit.

    Es wäre ein große Hilfe wenn jemand weiß woran es liegt, ich habe in den letzten Tagen von zwei Ähnlichen Fällen gelesen, aber eine Lösung schien es noch nicht zu geben?

     

    Vielen Dank im Voraus und mit freundlichen Grüßen,

     

    Daniel

    Donnerstag, 18. August 2011 13:51

Antworten

  • So, guten Morgen zusammen.

    Es wurden nochmal die XenTools installiert und seitdem ist Ruhe. Keine Einträge mehr im Ereignislog...
    Blöderweise habe ich noch zwei Dienste deaktiviert (u.a. Windows Updates) da mir die automatischen Neustarts seltsam vorkamen.
    Wir beobachten es mal weiter... aber es liegt relativ nahe dass die Treiber schuld waren.
    Weshalb man diese nun zwei Mal installieren musste... weiß man nicht ;-)

    Ich würde es noch etwas beobachten und dann nochmal später etwas dazu schreiben.

    Grüße und Danke

     

    Daniel

    Freitag, 26. August 2011 06:36

Alle Antworten

  • Hi Daniel,

    ein ähnliches Phänomen hatte ich schonmal mit VMware ESX. Ein ESX Server aus dem Cluster hat seine Verbindung zum zentralen Storage verloren und die virtuellen Server lebten quasi nur noch im RAM des ESX Servers - Anpingen der Server war dann noch möglich, aber alles weitere nicht, da hierzu wieder Daten von der Platte geladen werden mussten (was ja leider nicht mehr möglich war ohne Anbindung zum Storage).

    Evtl. verliert dein XenServer über Nacht kurzzeitig die verbindung zum Storage und die virtuellen Server sind damit quasi tot. Das würde dann aber immer alle VMs des XenServers betreffen, die auf dem Datastore im Storage liegen... Dazu kenne ich deine Infrastruktur nicht genau, um das beurteilen zu können. Es könnte halt nur den plötzlichen Tod der VMs erklären.


    Chris
    Donnerstag, 18. August 2011 14:38
  • Hallo,

    sollte das Problem nicht von der Virtualisierungumgebung ausgelöst werden,
    führ bitte folgende Schritte durch, um zu erkennen, welche Prozesse wie lange aktiv sind auf deinem System:

    Process Mointor starten

    (http://technet.microsoft.com/de-de/sysinternals/bb896645)

    File > Backing Files ...
    Hier den Pfad zum Logfile einstellen. Nach Möglichkeit nich lokal legen.

    Filter > Filter ..
    Operation = QueryFileInternalInformationFile

    Filter > Drop Filtered Events ...
    aktivieren

    Danach Process Monitor neu starten und laufen lassen.
    Dieses File kannst du dann auswerten und mit den Zeiten im Eventlog vergleichen.




    Donnerstag, 18. August 2011 15:42
  • Schönen guten Morgen ihr zwei,

     

    @Chris: diese Vermutung hatte ich auch - allerdings auch mit deinen Bedenken.
    Dieses Problem tritt nämlich auf zwei XenServern auf (von 3 in einem Pool) und auf den jeweiligen XenServern laufen noch andere Maschinen die nicht betroffen sind.
    Allerdings kommt noch hinzu dass ich schon einen ähnlichen Beitrag im www gefunden habe und dann würden auch die Ereignis-Logs (zwei davon siehe unten) wieder einen Sinn ergeben

    03:30am:
    wuaueng.dll (816) SUS20ClientDataStore: Eine Anforderung, in die Datei "C:\Windows\SoftwareDistribution\DataStore\Logs\edb.log" ab Offset 786944 (0x00000000000c0200) insgesamt 512 (0x00000200) Bytes zu schreiben, war erfolgreich, benötigte aber ungewöhnlich viel Zeit (121 Sekunden) von Seiten des Betriebssystems. Dieses Problem ist vermutlich durch fehlerhafte Hardware bedingt. Wenden Sie sich für weitere Unterstützung bei der Diagnose des Problems an Ihren Hardwarehersteller.

    03:30am:

    edgetransport (3020) Transportvorgang für Maildatenbank: Eine Anforderung für das Schreiben in die Datei "C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue\trn.log" bei Offset 3669504 (0x000000000037fe00) von 512 (0x00000200) Bytes war erfolgreich, aber die Bearbeitung durch das Betriebssystem dauerte sehr lange (34 Sekunden). Außerdem dauerte die Bearbeitung von 0 weiteren E/A-Anforderungen für diese Datei sehr lange, da die letzte Meldung zu diesem Problem vor 8803 Sekunden bereitgestellt wurde. Dieses Problem wurde wahrscheinlich durch fehlerhafte Hardware verursacht. Wenden Sie sich an den Hardwarehersteller, um Unterstützung bei der Problemdiagnose zu erhalten.

    Sprich: E/A Fehler.


    19.08.2011 06:01:46
    Das Betriebssystem wurde zur Systemzeit ‎2011‎-‎08‎-‎19 T 04:01:46  gestartet.

    Hier die nicht nachvollziehbare Uhrzeit 04:01Uhr.

    Wie gesagt, auf dem selben XenServer laufen noch mehr Server, die arbeiten durch... egakl ob Managementserver, oder TS... keine Ereignislogs in diesem Fall zu dieser Uhrzeit.

    @Matthias:


    Ich hatte gestern noch etwas gestartet: einen Task der alle 30 Minuten einen xcopy-Job ausführt und lokal eine txt-Datei ersetzt, recht simpel halt ;).
    Um 03:34Uhr wurde diese Datei das letzte Mal geändert.

    Den Proces Monitor hatte ich auch ausgeführt, das Logfile auf ein Netzlaufwerk gelegt und dort ist die letzte Änderungszeit 05:44Uhr.
    Das Logfile lässt sich nicht öffnen da corrupt.
    Ich muss aber erstmal fragen ob ein Kollege um 05:44 schon den Server neugestartet hat...

    Und JUST in diesem Augeblick ist der SQL Server hängengeblieben... anderer Xen. Es ist doch zum... dabei wollte ich den PM gerade darauf kopieren... aaahhh!



    Freitag, 19. August 2011 05:53
  • Hast du an deinen Xen-Servern noch irgendwelche Logs die auf ein solches Problem hindeuten?
    (am Storage?)

    Gibt es auf den virtuellen Geräte Minidumps?
    (C:\Windows\Minidump)

    Benutzt du auf den Servern irgendwelche VSS Writer?
    Sprich VSS für Backup, Schattenkopien etc?

     


    Freitag, 19. August 2011 06:42
  • Das Storage wird noch geprüft, das habe ich mir schon notiert.
    Das Minidump wurde zwar heute erstellt, allerdings ist der letzte Eintrag vor einem Monat geloggt.
    Diese Nacht wurde aber ein Memory Dump erstellt, dass lade ich gerade runter.

    Es wird für den Server das Widnows Backup verwendet, dieses habe ich schon auf eine andere Uhrzeit gelegt, ohne Erfolg. Das Backup läuft durch und der Server meckert nicht rum.
    Übriegns: es gibt keine ominöse 3rd party Software auf den Servern, nichtmal einen Virenschutz (da die eMails über ein gateway gehen). Gestern habe ich mal einen drüberlaufen lassen, auch ohne Befund.

    Freitag, 19. August 2011 07:23
  • Bitte Storge + Minidump auf jedenfall noch prüfen (wobei der Minidump wohl eher ein Folgefehler ist).

    Von Xen Seite aus also keine Fehler?

    Laufen die Server im abgesicherten Modus stabil?
    (abgesicherter Modus + Netzwerktreiber)

    Freitag, 19. August 2011 07:33
  • Danke nochmal.

    Minidump ist bis auf einen Eintrag aus letztem Monat leer, habe dennoch mal den SS angehangen.
    Storage wird noch geprüft.

    Was mich gerade irritiert:

    Ich habe heute früh gegen 06:30Uhr auf den SQL-Server geschaut, er lief.
    Um 07:45 habe ich nochmal geschaut, da lief er nicht mehr, pingbar, aber das wars auch.
    Also force-reboot.

    Chronologisch:

    Eintrag System Ereignisanzeige:

    04:22Uhr: Dienst "Anwendungserfahrung" befindet sich jetzt im Status "Beendet".
    04:24 Uhr Das Zeitlimit (120000 ms) wurde beim Verbindungsversuch mit dem Dienst Windows-Fehlerberichterstattungsdienst erreicht.
    06:05 Uhr: Dienst "Anwendungserfahrung" befindet sich jetzt im Status "Ausgeführt".
    07:55:28:  Das Betriebssystem wurde zur Systemzeit ‎2011‎-‎08‎-‎19 T 05:55:28.375200000Z gestartet.   <<<---?!
    07:55:48: Das System wurde zuvor am ‎19.‎08.‎2011 um 07:51:26 unerwartet heruntergefahren.

    Es schient so als wenn er um 05:55 schon irgendwas geloggt hat

    Einträge Anwendungen:


    04:56 Uhr: services (476) Versuch, aus Datei "C:\WINDOWS\Security\Database\secedit.sdb" bei Offset 8192 (0x0000000000002000) für 4096 (0x00001000) Bytes zu lesen, ist nach 1696 Sekunden mit Systemfehler 1117 (0x0000045d): "Die Anforderung konnte wegen eines E/A-Gerätefehlers nicht ausgeführt werden. " fehlgeschlagen. Fehler -1022 (0xfffffc02) bei Leseoperation. Wenn dieser Zustand andauert, ist die Datei möglicherweise beschädigt und muss aus einer vorherigen Sicherung wiederhergestellt werden.

    04.56: services (476) Versuch, aus Datei "C:\WINDOWS\Security\Database\secedit.sdb" bei Offset 12288 (0x0000000000003000) für 61440 (0x0000f000) Bytes zu lesen, ist nach 1696 Sekunden mit Systemfehler 1117 (0x0000045d): "Die Anforderung konnte wegen eines E/A-Gerätefehlers nicht ausgeführt werden. " fehlgeschlagen. Fehler -1022 (0xfffffc02) bei Leseoperation. Wenn dieser Zustand andauert, ist die Datei möglicherweise beschädigt und muss aus einer vorherigen Sicherung wiederhergestellt werden.

    07:26: Bei 3 E/A-Anforderung(en) von SQL Server wurden mehr als 15 Sekunden zum Abschließen des Vorgangs für die Datei [C:\allris_DB\allris2010_Log.LDF] in der [allris2010]-Datenbank benötigt (11). Das Dateihandle des Betriebssystems lautet 0x00000000000006AC. Der Offset des letzten langen E/A-Vorgangs lautet: 0x0000000a50c6000

    Das geht dann so weiter bis zum manuellen Reboot um 07:50 Uhr.

    Ähnliches Bild auch auf dem Exchange, auch viele E/A zwischendurch mit komischen Zeitangaben.
    Sieht mir fast nach Storage aus... oder Treibeaktualisierung der XenServer... oderoder oder...

     

    Ich überlege gerade ob das hier hefen könnte:

    http://support.microsoft.com/kb/982018/de

    Planänderung: Heute Abend wird der Xen geupdated und dann Treiber neu installiert. Spätestens morgen oder Sonntag wird man dann sehen was passiert (oder auch nicht ;-) )
    Freitag, 19. August 2011 08:19
  • würde auch sagen, dass es etwas mit dem Storage zu tun hat...

    Leider kenne ich mich mit Xen nicht aus - bei VMware kann man die Performancewerte für die Disk I/O und Warteschlange des Storage ganz gut monitoren. Exchange und SQL Sever sind ja bekannt dafür das Sie viel Disk I/O unter Last produzieren.

    Vielleicht hilft es ja auch etwas mit dem Permon von Windows mal die Disk I/O und Warteschlangenlänge des phy. Datenträgers zu monitoren.


    Chris
    Freitag, 19. August 2011 09:58
  • Guten Morgen, so Neuigkeiten: XenServer Update inkl XenTools brachte nicht den gewünschten Erfolg. Weiterhin ist der Server um Uhrzeit X nicht erreichbar und kann nur durch einen Reboot zur Arbeit gezwungen werden. Den ProcessMonitor habe ich laufen, allerdings ist das Problem dass die Logfiles corrupt sind. Dann habe ich zwar ein Logfile welches die letzte Änderung um bsp. 03:30 hatte, aber ich kann nicht drauf zugreifen. Weder wenn ich es lokal, noch auf einem share ablege. Noch Ideen? Der Server heute früh hatte auch kein Mini oder Memory Dump. Werde nun nochmal den PM laufe lassen aber habe wenig Hoffnung dass man etwas rausfindet.
    Sonntag, 21. August 2011 11:35
  • Hallo,

    ich vermute das Problem ebenfalls beim Storage bzw. Xen Hypervisor liegt.

    Hast von Xen Seite aus offiziellen Support?
    Wenn ja, würde ich diesen kontaktieren.

    Was war mit dem abgesicherten Modus?

    Was du noch probieren kannst / solltest:

    Läuft eine neue "leere" VM auf dem gleichem Storage fehlerfrei?
    Läuft eine geklone VM auf dem gleichem Storage fehlerfrei?

    Sonntag, 21. August 2011 12:06
  • Hallo Matthias,

    den abgesicherten Modus kann ich nidht kurzum testen, ich befürchte dann läuft eine SQL DB nicht mehr und die ist notwendig für die Pflege... da kann ich den Server auch jeden Morgen neustarten.
    Auf dem gleichen Storage laufen mehrere Maschinen fehlerfrei...

     

    und heute morgen konnte ich beobachten wie er sich verhält. Ich war per RDP drauf, dann wurde er langsamer, Anwendungen hingen, irgendwann war die Taskleiste weg und dann.. ging nichts mehr.

    Ereignislog:

    Das Betriebssystem wurde zur Systemzeit ‎2011‎-‎08‎-‎22T06:08:16.375200000Z gestartet. <<-- das wurde da aber nicht gestartet. Ich habe nun mal den Windows Updater Dienst deaktiviert.. nicht dass da irgendwas drüber kommt.


    Achso: da ich von dem ProcessMonitor recht angetan bin, kann ich damit irgenwas machen so dass die Logfiles nicht als corrupt angezeigt werden wenn der Server auf einmal "weg" ist?
    Montag, 22. August 2011 08:23
  • Zum Thema Logfile fällt mir spontan nur ein, dass Du es auf ein Share schreiben läßt und es mit einem Script regelmäßig mit einem anderen Dateinamen wegkopierst. Dann ist wohlmöglich das entscheidene Ende des Logfiles nicht komplett in der Sicherung enthalten, aber vielleicht sind trotzdem Tendenzen vor dem Ausfall zu erkennen...

    Also ich habe trotzdem immer noch das Storage im Verdacht.
    Vielleicht ist ja auch nicht das ganze Storage oder die Netzwerkverbindung zum Storage das Problem, sondern nur eine bestimmt LUN / Datastore in dem die VMs liegen.

    Kannst Du uns noch ein paar mehr Infos zur Xen-Infrastruktur und dem Storage geben?
    Vielleicht macht's auch Sinn das Problem parallel in einem Xen Forum zu posten...


    Chris
    Dienstag, 23. August 2011 08:45
  • So, guten Morgen zusammen.

    Es wurden nochmal die XenTools installiert und seitdem ist Ruhe. Keine Einträge mehr im Ereignislog...
    Blöderweise habe ich noch zwei Dienste deaktiviert (u.a. Windows Updates) da mir die automatischen Neustarts seltsam vorkamen.
    Wir beobachten es mal weiter... aber es liegt relativ nahe dass die Treiber schuld waren.
    Weshalb man diese nun zwei Mal installieren musste... weiß man nicht ;-)

    Ich würde es noch etwas beobachten und dann nochmal später etwas dazu schreiben.

    Grüße und Danke

     

    Daniel

    Freitag, 26. August 2011 06:36
  • Schön zu hören dass dein Problem nun gelöst ist!

    Gruß Matthias

    Freitag, 26. August 2011 08:30