Symbios SCSI unter W2K-Server

[Chief Wiggum]

Moin!

Folgende Hardware:

Siemens Primergy 170, P3 700 MHz,

768 MB Ram

Symbios 895a-Controller U2W-SCSI

2 U2W-Seagate Barracudas als Software-Raid 1

W2K Server, SP 4, Treiber auch aktuell.

Problem:

Irgendwann Nachts, wenn der Server absoluten Leerlauf hat, meldet der Controller laut Ereignisprotokoll ein Timeout: Gerät hat innerhalb der Fehlerwartezeit nicht geantwortet. (EventID 9) Dann geht es relativ schnell Knall auf Fall:

Event Harddisk0 Schreibfehler bei Block ... (ohne Eventid)

Raidverbund wird zur gleichen Zeit aufgelöst. (EventID 500, Ereignissquelle LDM).

Server verabschiedet sich mit Bluescreen und Reboot.

Beim Reboot auf HD0 startet das System bis der SCSI-Treiber für den Symbios geladen wird (lässt sich im abgesicherten Modus sehen), dann erfolgt BSOD mit Inaccessible Boot Device. Keine Chance, dort irgendwas zum Leben wiederzuerwecken.

Jetzt kommt aber das seltsame. Nehme ich die HD1 (die zweite Platte aus dem Spiegel), stecke die an dem Backpanel auf ID0 als Bootplatte, dann bootet das System problemlos. HD0alt (mit zerschossenem System) als HD1 am Controller lässt sich problemlos wieder als zweite Platte in den Spiegel einbauen, bis dann irgendwann wieder der Fehler auftritt und beide Platten getauscht werden müssen.

Bei diesen Tauschaktionen haben wir schon niegelnagelneue SCSI-Platten eingebaut, die alten Platten ohne Fehlermeldung lowlevel-Formatiert und alles. Die Reboots sind nicht Plattenabhängig. Controller möchte ich auch ausschliessen, da der Server tagsüber (wenn eine Datenbankanwendung aktiv auf dem Server ist) problemlos läuft. Die Platten laufen auch beim Wiederaufbau des Software-Raids problemlos, steigen nicht aus. SCSI-Geräte werden auch immer problemlos erkannt. Absturz erfolgt halt nachts, auch lange nach der Datensicherung (die endet um 23:00 Uhr, die Abstürze sind in etwa zwischen 0:00 Uhr und 3:00 Uhr. Weitere zeitgesteuerte Jobs laufen nicht auf dem Server.

Wieso um Himmelswillen zerschiesst der Server (so wie ich das vermute) im Falle des Absturzes den Symbios-Scsi-Treiber? Nach dem Absturz bootet die Kiste bis zum Laden des Treibers und liefert dann zuverlässig einen BSOD. Die zweite Platte bootet in jedem Fall sauber auf ID0.

Bitte sachdienliche Lösungshinweise und keine Diskussion über Software-Spiegelung.

[Thombo]

Hast du das Software-Raid mit Windows NT Bordmitteln eingerichtet ?

Sind alle Energiesparoptionen im Windows undim BIOS deaktiviert ?

[Chief Wiggum]

Ja, Software-Raid läuft über W2K-Bordmittel.

Ja, Energiesparen ist sowohl im Bios wie in Windows deaktiviert.

[Thombo]

Ja, Software-Raid läuft über W2K-Bordmittel.

Ja, Energiesparen ist sowohl im Bios wie in Windows deaktiviert.

das komische ist, das es bei dem Raid1 nur die erste der beiden Platten erwischt... Das heisst das Windows keine Chance mehr hat, den Fehler (also den warscheinlich abgeschossenen SCSI-Treiber) mit der anderen Platte abzugleichen...

auch komisch ist, das das nur im Leerlauf passiert.

Hast du dich schonmal an den Support von Symbios gewendet?

Irgendwie hört sich das an, als wenn der da was verbockt. Evtl. mal eine neue Firmware auspielen. (So wie ich dich einschätze hast du das warscheinlich schon gemacht :-)

[Chief Wiggum]

Nein, Firmware ist noch nicht neu, da das letzte Firmwareflashen eines Controllers einen Raidcontroller ergab, der jetzt als Ausstellungsstück an der Wand hängt. Bin bei dem Thema ein wenig gebranntes Kind.

Support von Siemens ist schon eingeschaltet.

Mittlerweile ist auch wieder ein Kollege vor Ort und hofft, dass ServerView mehr auswirft als die Ereignisanzeige von Windows.

[Chief Wiggum]

Zwischenstand:

Scsi-Controller gegen Adaptec 2940 U2W getauscht, System wieder zum Laufen bekommen.

Gleicher Effekt, wieder Festplattenunabhängig.

Haben jetzt mal SCSI-Backpanel getauscht und warten ab.

Symbios-Controller Backpanel und weitere Platte mit dem gleichen System laufen jetzt als Kreuztest in einer baugleichen Maschine, die wir zum Glück vorrätig haben.

[Thombo]

Gibts schon was neues ?

Ich finde das ist nämlich ein "interessantes" Problem.