iSCSI verbindung bricht unwiederherstellbar ab beim Kopieren zu Ordnerfreigaben

[Beinleuchter]

Hallo Leute, die ihr schon mit der DS und iSCSI gesammelt habt!

Fehler in absoluter Kurzform:
Kopieren großer Dateien (>2GB) zwischen einer DS-Ordnerfreigabe und einem DS-iSCSI-Target führt zu Abbruch der Target-Verbindung (ohne Möglichkeit jemals wieder zu verbinden).
Produktiver Betrieb nicht möglich

Ausführlich:
Ich habe hier eine DS3611xs mit DSM 3.2 (1955) und auf einer Diskgruppe (5 x 2TB-HDs im RAID6) mehrere LUNs definiert und Targets zugeordnet. Diese verbinde ich per iSCSI-Intitiator auf Windows-7-64bit-PCs.
Soweit, so gut - es funktioniert alles, wie ich mir es vorstelle!
Super Teil diese DS3611 - bis jetzt.

Nun hat meine DS auch noch 'ganz normale' Ordner-Freigaben (zugehöriges Volume auf der gleichen Diskgruppe, wie die LUNs).

Wenn ich nun zwischen so einer Freigabe und einem per iSCSI angebundenen Laufwerk kopiere, trennt sich innerhalb kürzester Zeit das Target von meinem iSCSI-Initiator.
Alleine das ist schon unangenehm und für einen produktiven Betrieb nicht verwendbar.
Aber es kommt noch schlimmer.
Ein Wiederverbinden ist nicht möglich, es kommt ein Popup mit "Fehler des Ziels".

In der DSM-Browseroberfläche steht das Target noch auf 'Service-Status' "192.168.47.11 verbunden".
Ein Neustart des iSCSI-Dienstes auf dem Client-PC oder gar ein ganzer PC-Neustart bringen nichts.
Ich komme nicht mehr an mein Target ran.

Wenn ich nun auf der DS das Target 'deaktiviere' wechselt der Service-Status auf "Verarbeite(Warten...)".

Und so bleibt er auch auf ewige Zeit.

Nun wird's noch besser:
Da ich mit diesem Zustand ja nicht leben kann, versuche ich die DS neu zu starten.
Egal ob über Browser-DSM oder Telnet, die DS fährt nicht runter und muss per Hammer beendet werden.
Pro abgebrochener iSCSI-Verbindung erscheint bei Befehlt 'top' ein Prozess [LIO_iblock] mit 25% CPU (also einem kompletten Core/Thread).

Kann mir irgendjemand helfen!?
Kennt ihr das Problem?
Kann das jemand nachvollziehen?

Danke!
Gruß vom Beinleuchter

 

[itari]

Wende dich doch direkt an den Synology-Support (link ist in meiner Signatur), denn das ist sicherlich ein Fehlverhalten, das es zu korrigieren gilt.

Itari

 

[Beinleuchter]

Ok, habe ich gemacht.
Die haben jetzt Neujahrsfest (über 'ne Woche - prima).

Könnte ja sein, dass das Problem jemanden bereits bekannt ist und evtl. Workarounds, Fixes etc. existieren.
Hat das schonmal jemand gehabt? Ist es nachvollziehbar?

Danke und Grüße
Beinleuchter

 

[itari]

Wenn sich hier keiner an der Diskussion beteiligt, dann ist das kein böser Wille, sondern liegt schlicht daran, dass es nicht viele Leute gibt, die eine DS3611 haben

Itari

 

[Beinleuchter]

Kein Problem
Mir ist schon klar, dass das ein spezielles Problem ist.
(Sonst hätte ich evtl. schon die Lösung gefunden )

Aber vielleicht ist es ein Softwareproblem, das ja auch bei anderen DSen nachvollzogen werden könnte.

Ich berichte, wenn ich Neues weiß

 

[Beinleuchter]

Weitere Erkenntnisse von Tests mit jeweils großen Datenmengen:

- Auf einem PC Kopieren von Daten auf einen freigegebenen DS-Ordner
- Auf einem anderen PC Kopieren von Daten in ein DS-iSCSI-LUN (in der gleichen Diskgruppe)
==> Absturz des LUNs

Derzeit setze ich ein neues LUN auf, das auf Blocklevel auf einem eigenen RAID1 liegt.
Mal sehen, ob sich das dann immer noch mit der Ordnerfreigabe des Diskgruppen-Volumes in die Haare kommt.

Bis nächste Woche
Gruß
Beinleuchter

 

[itari]

==> Absturz des LUNs

gibt es dazu Fehlermeldungen??? auf der DS aus der /var/log/messages und natürlich auch vom PC ...

Itari

 

[Beinleuchter]

Soderle, ich habe noch ein paar Tests gemacht. Hier die Zusammenfassung:

Ausgangslage:
A - Diskgruppe RAID6 mit 5x2TB mit einem Volume enthält Ordnerfreigabe und 3 iSCSI-LUNS
B - Ein iSCSI-LUN im Blockmodus direkt auf einem RAID1 mit 2x750GB

1. Datenübertragungen auf ein beliebiges LUN gehen halbwegs flott mit ca. 80MB/s
2. Parallele Datenübertragungen von 2 verschiedenen PCs auf 2 LUNs, die sogar auf verschiedenen Diskgruppen liegen verlangsamen auf ca. 20-30MB/s - ist schonmal Mist.
3. Von 2 PCs parallel auf ein LUN und auf eine Ordnerfreigabe ging erst recht langsam (ca. 10-20MB/s) und führte dann zum Disconnect von LUN UND(!) Freigabe - das ist dann totaler Mist.
Auf der DS hängt dann ein Prozess mit 25% CPU - restliches Verhalten siehe Anfangspost.

Ich werde nächste Woche noch eine Diskgruppe mit RAID10 einbauen (dann ist die DS aber voll) und mal damit testen.
Evtl. kommt die DS ja nicht mit RAID6 zurecht.

Dann schaue ich mir mal die Logs in '/var/log/messages', wie von 'itari' beschrieben an. Wie finde ich die?
Und zu guter Letzt hoffe ich auf Antwort vom Synolgoy-Support.

Bis jetzt ist die DS3611xs alles andere als ein 'Enterprise-Gerät'.
Ich hoffe aber das Beste!

Schönes Wochenende
Gruß
Beinleuchter

 

[itari]

Dann schaue ich mir mal die Logs in '/var/log/messages', wie von 'itari' beschrieben an. Wie finde ich die?

telnet oder ssh im DSM aktivieren und sich auf der Linus-Konsole anmelden.

Itari

 

[phph]

Hi!

ich habe ein ähnliches Problem. Bei mir ist das rs3411xs an ein xcp (xen server) über iscsi angeschlossen, dabei tritt folgendes Problem auf:
- wenn man viele Daten transferiert, z.B. mehrfache rsyncs, bonnie++ dann bricht der iscsi initiator im xen ab
- dann versucht der xen server sich in einer endlosschleife zum synology zu verbinden
- am synology ist eingestellt, dass max. eine verbindung erlaubt ist auf den iscsi target --> den xen kann sich nicht mehr verbinden

am synlogy tritt dann folgendes auf:
- LIO_iblock verursacht ca. 25% cpu auslastung
- die einzigen log messages sind mit bezug auf den xen der sich immer wieder verbinden will (sonst nichts):
Jan 31 00:21:01 kernel: [17337.933770] iSCSI - The number(1) of current sessions will exceed the maximum number(1).
Jan 31 00:21:01 kernel: [17337.941680] iSCSI - Login negotiation failed from [10.30.1.3]

Wenn man jetzt am xen abdreht, dass er sich weiter verbinden versucht, bleibt LIO_iblock trotzdem auf 25% cpu auslastung.

Viele Grüße,
Peter

 

[Beinleuchter]

Hi Peter (phph), das sieht genau nach meinem Problem aus.
Zumindest nach der gleichen Fehlerursache!

Lässt sich deine DS dann auch nicht mehr runterfahren!?

Ich habe bei Synology am letzten Donnerstag (26.01.2012) einen Request aufgemacht.
Er wurde am 30.01.2012 lapidar beantwortet, mit einem Link auf eine Anweisung, wie man in Windows einen iSCSI-Initiator einrichtet.

Das war natürlich nicht mein Problem.

Ich habe noch am 30.01.2012 zwei ausführliche, reproduzierbare Fehlerbeschreibungen an den Support zurückgeschickt.
Leider habe ich bis heute noch keine Rückantwort.
Dort (China!?) sollten mittlerweile zwei Arbeitstage ins Land gegangen sein.

Heh - wir haben da Produkte für "Großunternehmen" gekauft!


Nun habe ich nochmal einen Request aufgemacht, der die o.g. Fehlerbeschreibung und einen Referenzhinweis auf den ursprünglichen Request enthält.

Hat jemand im Forum Erfahrung mit der Qualität und den Reaktionszeiten des Synology-Supports?

@Peter: Hast Du auch einen Request aufgemacht?
Ich könnte Dir per PN meine Request-Nummern senden. Evtl. hilft das den Supportern udn baut auch vielleicht etwas Druck auf, wenn Du auf diese Requests verweist.

Halten wir uns gegenseitig auf dem Laufenden!

Gruß
Beinleuchter

 

[phph]

Hi!

ja, genau, man kann auch nicht mehr neu hochfahren, es bleibt beim shutdown einfach hängen.

Meine ticket ID ist #107095, ich habe den support request gestern aufgemacht aber noch keine Antwort erhalten. Sonst hab ich leider nie mit Synology zuvor zu tun gehabt, d.h. ich weiß leider nicht wie schnell eine Antwort kommt.

Bezüglich des Fehlers: ich habe um den initiator auszuschließen den gleichen test von einem vSphere 5 gemacht, genau in den gleichen Fällen hängt sich der eine iSCSI target im Synology auf. Interessant ist, dass genau ein target stirbt, die restlichen iSCSI targets bleiben vollständig erhalten.

Ich melde mich sobald ich mehr weiß!

-Peter

 

[Beinleuchter]

Hi, ich wollte nur mal vorsichtig nachfragen, ob der Support sich schon (qualifiziert) gemeldet hat!?

 

[Beinleuchter]

Gute Nachrichten!

Gute Nachrichten (zumindest aus meiner Sicht)!

Nach vielem hin-und-her hat der Synology-Support meine DS zweimal gepatcht.
Zuerst wurde das iSCSI Problem beseitigt.
Und dann noch ein Problem mit parallelen SMB-Verbindungen.
Ich hoffe, meine Kiste läuft jetzt stabil.
Ich werde nächste Woche in Echteinsatz gehen (gulp).

Im Synology-Download-Bereich habe ich Patches 1958 und 1960 entdeckt.
Evtl. sind das die Ergebnisse vom Patchen meiner DS.
http://ukdl.synology.com/download/DiskStation/DSM3.2/

Könnt ihr ja mal ausprobieren und berichten

Grüße!
Beinleuchter

 

[glowaq]

Wie läufts nun mit dem iSCSI? Ich habe gerade die Release 4.0 installiert. Ich teste gerade ob die stabil läuft ...

 

[Beinleuchter]

Servus,

also bei mir, mit dem gepatchten 3.2er DSM, läuft iSCSI jetzt seit ca. 2 Wochen problemlos im Echtbetrieb an 2 VMware-Servern.

Würde mich sehr interessieren, ob's in 4.0 auch noch geht.
Kann man eigentlich ohne Datenverlust hin und her wechseln!?

Danke und Grüße
Beinleuchter

 

[glowaq]

Was für datenraten hast du? Wenn ich zm storage kopiere komme ich (meistens) nicht über 5 MB/sec. Beim lesen habe ich so 20-25MB/sec. Sehr langsam, finde ich.

Ich habe übrigens öffters schon hin und her gewechselt (auf einen Testsystem!) da hatte ich nie datenverlust.

 

[Beinleuchter]

Nee, bei mir läuft's performant.
So ca. 80-100MB/s beim Lesen wie Schreiben.
Auch über ein paar 100GB hinweg.
Allerdings hat die Kiste eine i5-Prozessor.
Wird wahrscheinlich durch die Art des RAIDs und durch das noch nicht gekoppelte GBit-LAN begrenzt.

Ich glaube, ich warte mit 4.0 noch etwas
Hast Du schon mal größere Dateien (>30GB) kopiert und parallel auf 'ne Freigabe was kopiert?
(Ob der von mir ursprüngliche gemeldete Fehler auch in 4.0 draußen ist)

Danke und Grüße
Beinleuchter

 

[glowaq]

Ich nutze eine DS1010+ und kopiere gerade mehrere Terrabytes an Daten. Seit neustem kann man volumes größer al 2 TB erzeugen. Also habe ich bei der DS1010+ ein 5.7 TB iSCSI volume erzeugt und dadrauf ein 5.7TB vmware filesystem erzeugt. Da habe ich dann unter Win2008 (virtuell) je 2 TB hdds erzeugt und kopiere da seit tagen daten drauf. Bisher läuft es unter ESX 5 und 3 ESX-servern ohne crash. Aber seeehhhr langsam.

Die freigabenutze ich im moment nicht. Müsste ich später mal testen.

Die CPU-last (load) ist bei 90% auf der DS1010+ :-(

 

[glowaq]

So, das war's nun. Nach 1 Tag und 2 Stunden haben die ESX die verbindung zu dem synology iSCSI target verloren. Die DS1010+ läuft auf 100% CPU last und der speichermanager lässt sich nicht mehr aufrufen (Netzwerkfehler).
Beim systemzustand steht "GUT , Ihre DiskStation funktioniert einwandfrei". Reboot nicht mehr möglich, die box muss "hart" abgeschaltet werden.

Das ist nun seit ca. 2 jahren so und Synology sagt immer, dass es in der nächsten version gefixt wird.