3
SAN - SCSI Verbindungsabrisse
Hallo admins,
Ich habe leider ein technisches Problem und suche Rat da ich selbst das Problem nicht vollständig einschätzen kann.
Folgendes:
Ich habe zwei Server + SAN (T3+ StorEdge mit 2xRAID5 Arrays konfiguriert)
Zur Aufteilung wurde ein altes HP FC-HUB genommen.
Nun ist das komische Folgendes:
- Löschoperationen & Schreiboperationen & Dateiauflistung etc. dauern ewig lange
(z.b. 30sek für ca 100 Dateien mit einem Gesamtvolumen von 6Mbyte)
Wiederrum normal geht folgendes von statten:
Kopiervorgang einer großer Dumpfile z.b. Das geht mit anständigen 6-7Mbyte/s übers Netzwerk.
So total oft kommt es dann vor das, sich nach einem Befehl ewig lang nix tut. Und danach
Lese / Ausgabefehler (bei ls -l) steht. Ja die Partition ist unbrauchbar...
Komischerweise ist das komplette Device unter /dev spurlos verschwunden.
-> Logmessage:
Sep 25 16:59:50 mail kernel: sd 0:0:0:1: SCSI error: return code = 0x00010000
Sep 25 16:59:50 mail kernel: end_request: I/O error, dev sdb, sector 127
Sep 25 16:59:50 mail kernel: sd 0:0:0:1: SCSI error: return code = 0x00010000
Sep 25 16:59:50 mail kernel: end_request: I/O error, dev sdb, sector 49359
Sep 25 16:59:50 mail kernel: sd 0:0:0:1: SCSI error: return code = 0x00010000
Sep 25 16:59:50 mail kernel: end_request: I/O error, dev sdb, sector 48839
Sep 25 16:59:50 mail kernel: xfs_force_shutdown(sdb1,0x2) called from line 956 of file fs/xfs/xfs_log.c. Return address = 0xf8bc5710
Sep 25 16:59:50 mail kernel: lost page write due to I/O error on sdb1
Sep 25 16:59:50 mail kernel: xfs_force_shutdown(sdb1,0x1) called from line 424 of file fs/xfs/xfs_rw.c. Return address = 0xf8bc5710
Der SCSI return Code verträgt mir folglich dies:
return code = 0x00010000
DID_NO_CONNECT
iscsi layer returns this if replacement/recovery timeout seconds has
expired or if user asked to shutdown session.
Ok, lustigerweise ist das komplette SAN dann nichtmehr erreichbar, also auch nicht vom anderen Server!
Dort ist ebenso das komplette Device spurlos verschwunden.
Was hilft ist das ich SAN und beide Server komplett rebooten muss.
Dann gehts eben gerade so weiter.
Nun könnte es ja sein das jemand diesselben Phänome schonmal hatte.
Mein SAN gibt mir nur den Status alles in bester Ordnung zurück. Die Volumes sind gecheckt und völlig okay.
Es muss also der Fehlermeldung zu entnehmen an der Verbindung liegen.
Wie hoch ist die Warscheinlichkeit das was kaputt ist?
- Kann sogar das FC-Hub spinnen?
- Vermutet ihr das eine (übrigens Emulex LP7000 Karte) defekt ist und wenn die eine kaputt ist, die Auswirkung auf mein ganzes LWL-SAN Netzwerk haben kann, sprich die Verbindung zum anderen Server in Mitleidenschaft zieht?
- Kann sowas mit einem "defekten" LWL-Kabel passieren?
- Oder meint ihr, es könnte gar das ganze SAN ein Schaden haben
Bin über jede Hilfe dankbar
gruß Jens
Ich habe leider ein technisches Problem und suche Rat da ich selbst das Problem nicht vollständig einschätzen kann.
Folgendes:
Ich habe zwei Server + SAN (T3+ StorEdge mit 2xRAID5 Arrays konfiguriert)
Zur Aufteilung wurde ein altes HP FC-HUB genommen.
Nun ist das komische Folgendes:
- Löschoperationen & Schreiboperationen & Dateiauflistung etc. dauern ewig lange
(z.b. 30sek für ca 100 Dateien mit einem Gesamtvolumen von 6Mbyte)
Wiederrum normal geht folgendes von statten:
Kopiervorgang einer großer Dumpfile z.b. Das geht mit anständigen 6-7Mbyte/s übers Netzwerk.
So total oft kommt es dann vor das, sich nach einem Befehl ewig lang nix tut. Und danach
Lese / Ausgabefehler (bei ls -l) steht. Ja die Partition ist unbrauchbar...
Komischerweise ist das komplette Device unter /dev spurlos verschwunden.
-> Logmessage:
Sep 25 16:59:50 mail kernel: sd 0:0:0:1: SCSI error: return code = 0x00010000
Sep 25 16:59:50 mail kernel: end_request: I/O error, dev sdb, sector 127
Sep 25 16:59:50 mail kernel: sd 0:0:0:1: SCSI error: return code = 0x00010000
Sep 25 16:59:50 mail kernel: end_request: I/O error, dev sdb, sector 49359
Sep 25 16:59:50 mail kernel: sd 0:0:0:1: SCSI error: return code = 0x00010000
Sep 25 16:59:50 mail kernel: end_request: I/O error, dev sdb, sector 48839
Sep 25 16:59:50 mail kernel: xfs_force_shutdown(sdb1,0x2) called from line 956 of file fs/xfs/xfs_log.c. Return address = 0xf8bc5710
Sep 25 16:59:50 mail kernel: lost page write due to I/O error on sdb1
Sep 25 16:59:50 mail kernel: xfs_force_shutdown(sdb1,0x1) called from line 424 of file fs/xfs/xfs_rw.c. Return address = 0xf8bc5710
Der SCSI return Code verträgt mir folglich dies:
return code = 0x00010000
DID_NO_CONNECT
iscsi layer returns this if replacement/recovery timeout seconds has
expired or if user asked to shutdown session.
Ok, lustigerweise ist das komplette SAN dann nichtmehr erreichbar, also auch nicht vom anderen Server!
Dort ist ebenso das komplette Device spurlos verschwunden.
Was hilft ist das ich SAN und beide Server komplett rebooten muss.
Dann gehts eben gerade so weiter.
Nun könnte es ja sein das jemand diesselben Phänome schonmal hatte.
Mein SAN gibt mir nur den Status alles in bester Ordnung zurück. Die Volumes sind gecheckt und völlig okay.
Es muss also der Fehlermeldung zu entnehmen an der Verbindung liegen.
Wie hoch ist die Warscheinlichkeit das was kaputt ist?
- Kann sogar das FC-Hub spinnen?
- Vermutet ihr das eine (übrigens Emulex LP7000 Karte) defekt ist und wenn die eine kaputt ist, die Auswirkung auf mein ganzes LWL-SAN Netzwerk haben kann, sprich die Verbindung zum anderen Server in Mitleidenschaft zieht?
- Kann sowas mit einem "defekten" LWL-Kabel passieren?
- Oder meint ihr, es könnte gar das ganze SAN ein Schaden haben
Bin über jede Hilfe dankbar
gruß Jens
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 69571
Url: https://administrator.de/contentid/69571
Printed on: April 23, 2024 at 10:04 o'clock
3 Comments
Latest comment
Hallo,
ich muss gestehen, dass sich deine Beschreibung schon gruselig anhört. Soetwas möchte ich nicht erleben.
Da ich ein ähnliches Verhalten jedoch bisher noch nicht gehabt habe, würde mein Lösungsansatz der meiner Meinung nach einzig Mögliche sein: Komponenten reduzieren und Fehler suchen.
Es klingt so, als wäre das Problem reproduzierbar. Ich würde wenn möglich den FC-Hub aus der Geschichte rausnehmen, die Biegeradien der Kabel prüfen, wenn möglich gegen andere tauschen und beobachten. Wenn das Problem bei unterschiedlichen Server mit unterschiedlichen FCC-Adaptern und Kabeln auftritt und kein Hub/Switch dazwischen geschaltet ist, muss es mit der Storage-Einheit selber zu tun haben. Dann sollte man über den Hersteller bzw. Support Hilfestellung erhalten können.
Es tut mir leid, dass ich keine konkreteren Hinweise liefern kann, aber um die Arbeit kommt leider keiner drum herum. Ich hasse es auch nach dem Ausschlussprinzip arbeiten zu müssen - aber was will man da machen?
mfg, TZ
ich muss gestehen, dass sich deine Beschreibung schon gruselig anhört. Soetwas möchte ich nicht erleben.
Da ich ein ähnliches Verhalten jedoch bisher noch nicht gehabt habe, würde mein Lösungsansatz der meiner Meinung nach einzig Mögliche sein: Komponenten reduzieren und Fehler suchen.
Es klingt so, als wäre das Problem reproduzierbar. Ich würde wenn möglich den FC-Hub aus der Geschichte rausnehmen, die Biegeradien der Kabel prüfen, wenn möglich gegen andere tauschen und beobachten. Wenn das Problem bei unterschiedlichen Server mit unterschiedlichen FCC-Adaptern und Kabeln auftritt und kein Hub/Switch dazwischen geschaltet ist, muss es mit der Storage-Einheit selber zu tun haben. Dann sollte man über den Hersteller bzw. Support Hilfestellung erhalten können.
Es tut mir leid, dass ich keine konkreteren Hinweise liefern kann, aber um die Arbeit kommt leider keiner drum herum. Ich hasse es auch nach dem Ausschlussprinzip arbeiten zu müssen - aber was will man da machen?
mfg, TZ
Da haste du völlig recht ;)
Trotzdem danke für deine Antwort!
Ich dachte bevor ich mich komplett mit Ersatzteilen "eindecke" Frage ich ersteinmal.
Leider stehe ich nicht in umittelbarer Nähe beim SAN, ist in einem RZ und da komme ich erst nächstes Wochenende wieder vorbei. (Zum Glück ging das noch nicht vollständig produktiv)
Werde ich wohl Stück für Stück Komponenten tauschen.
Sobald ich was neues oder die Lösung habe, hinterlasse ich das natürlich hier
gruß Jens
Trotzdem danke für deine Antwort!
Ich dachte bevor ich mich komplett mit Ersatzteilen "eindecke" Frage ich ersteinmal.
Leider stehe ich nicht in umittelbarer Nähe beim SAN, ist in einem RZ und da komme ich erst nächstes Wochenende wieder vorbei. (Zum Glück ging das noch nicht vollständig produktiv)
Werde ich wohl Stück für Stück Komponenten tauschen.
Sobald ich was neues oder die Lösung habe, hinterlasse ich das natürlich hier
gruß Jens
Obwohl das schon ewig her ist.
Es war ein defekter GBIC, der sporadisch zickte.
Es war ein defekter GBIC, der sporadisch zickte.
