Freigaben und iSCSI Connections brechen bei Last ein

  • Morgen,


    ich werde Heute für ein zwei Stunden versuchen den Fehler nachstellen zu können bzw. zu lösen, allerdings gibt es ja vielleicht jemanden der das ähnliche hatte.


    Seit einiger Zeit habe ich das Problem dass bei etwas höherer Last, z.B. einem großen Kopiervorgang auf eine Freigabe, oder das entpacken von Daten auf einer Freigabe,
    die Freigabe selbst "verschwindet", sie ist teilweise Minutenlang nicht mehr aufrufbar. Teilweise werden dann sogar iSCSI Connections geschlossen und neu geöffnet, was blöd ist, weil ein paar VMware vSphere Server dahinter stehen.


    Aktuell weiß ich nicht wieso dieses Verhalten auftreten sollte. CPU Last ist bei oben genannten Fall auf höchstens 60%, Arbeitsspeicher hat nur 2-3 GB von 10 GB belegt und das Netzwerk langweilt sich. (2x 1 GBit Bonding für Freigaben und 10 GBit Glasfaser für iSCSI/Freigaben)
    Ich habe gestern Abend dann die Freigaben für die beiden 1 GBit Ports deaktiviert und alles über die 10 GBit Karte laufen lassen, es änderte nichts. Heute werde ich das mal anders herum probieren, ggfls. stimmt etwas am 10 Gigabit Netzwerk nicht ...
    Außerdem werde ich den SSD Cache mal komplett deaktivieren, obwohl der sich auch langweilt ... 1 TB Cache für ca. 2 TB Daten, 60% Cachebelegung.


    Hat sonst jemand eine Idee? So kann ich die QNAP nicht meine iSCSI LUNS bedienen lassen, falls dort mal höhere Last aufkommt knallen die ja raus ...


    Gruß

  • Das reicht schon wenn es eine einzige große ISO bzw. Archiv von z.B. einem Veeam Backup ist. Teilweise sogar ab 4 GB Einzeldateigröße.
    Im Normalfall kopiere ich über SMB immer nur einzelne Daten, dafür aber öfter größere. Ansonsten aber sequenziell.


    Gestern Abend z.B. habe ich etwas direkt aufs NAS herunter geladen, von einer VM die per iSCSI darauf läuft und nebenher noch über SMB ein Archiv entpackt.
    Da war dann recht schnell Ende, die Freigabe war nicht mehr aufrufbar und die VM kam ins stocken weil sich alle iSCSI Connections neugestartet haben.


    Witzigerweise ließ sich die Webverwaltung noch öffnen und bedienen, da war alles normal.

    2 Mal editiert, zuletzt von onlyReaver ()

  • Ich kann da nun nichts rauslesen das dazu passen würde ...


  • Ist denn in dem Zeitraum, welchen das Log abdeckt, der Fehler aufgetreten?
    Es macht natürlich nur Sinn in ein Log zu schauen, nachdem der Fehler auftrat.

  • Das stimmt wohl, aktuell lässt sich das aber nicht reproduzieren ... Vorführeffekt, wie immer.


    Ich werde den Log nochmal posten sobald dies wieder vorkam.

  • Das hatte ich auch mal probiert, das war nicht zufriedenstellend. Ist aber schon ein paar Jahre her.
    Ich habe keine Erfahrung mit vSphere, verwende Hyper-V, daher kenne ich die Einstellungsmöglichkeiten nicht.


    Man sollte auf jeden Fall beim Einbinden der LUN's die Host und Zieladressen explizit festlegen. Der MS Initiator jedenfalls springt sonst schon mal
    auf das andere verfügbare Netz, mglw hat das vmware besser gelöst.


    Dem zuständigen Adapter auf dem NAS eine IP in einem eigenen subnetz verpassen und die Adapter an den Servern darauf anpassen.
    Mittels Servicebindung auf dem NAS die Kommunikation auf das 10 Gb if beschränken.


    Du hast auf dem NAS mehrere IP's im selben subnetz, zwei if's auch noch gebündelt, bei hoher Last gibt's dann wohl ein port flapping und die Verbindung dübelt ab.
    Halte die Wege für LAN und iSCSI sauber getrennt, dann wird das schon tun. Auch für die Performance unerlässlich, besonders wenn in den vm's Netzwerkfreigaben
    auch auf Ressourcen auf iSCSI Zielen zeigen.

  • Danke, werd ich mal ausprobieren. Ich wollte eigentlich sowieso ISCSI als SAN aufbauen, also ein getrenntes Netz per VLAN (Bald auch physikalisch, weil 10G Switch reinkommt) mit anderem Subnetz.
    Und dann die Netzwerkfreigaben nur über das Teaming in dem normalen LAN.


    Habe aktuell einfach die beiden 1G Ports rausgezogen, bis jetzt war nichts passiert ... werde das dann bei Zeit umkonfigurieren. Ggf. wenn der neue Switch kommt.