the only Linux forum

the only Linux forum

Posts 1-10 of 16
  • Jörg Lang
    Jörg Lang    Premium Member   Group moderator
    The company name is only visible to registered members.
    Linux Cluster mit DRBD hat Aussetzer
    Hallo,

    für eine CAD Anwendung wurde eine Hochverfügbarkeitslösung mit DRBD und Heartbeat aufgesetzt. Hier wird per Samba für die CAD Rechner eine Fileablage zur Verfügung gestellt.
    So weit so gut, alles funktioniert so wie es soll, Umschaltung usw. alles einwandfrei. Doch leider gibt es ab und an Aussetzer an der Netzwerkkarte. Lässt man Beispielsweise einen Dauerping auf den "aktiven" Server laufen, egal ob auf die virtuelle oder die reguläre IP Adresse, man bekommt sporadisch immer mal wieder einen Aussetzer.
    Im Log findet man dann solche Einträge:

    Apr 1 21:42:38 form4b kernel: [2939310.964169] 0000:0d:00.0: eth0: Detected Tx Unit Hang:
    Apr 1 21:42:38 form4b kernel: [2939310.964171] TDH <5b>
    Apr 1 21:42:38 form4b kernel: [2939310.964172] TDT <74>
    Apr 1 21:42:38 form4b kernel: [2939310.964172] next_to_use <74>
    Apr 1 21:42:38 form4b kernel: [2939310.964173] next_to_clean <57>
    Apr 1 21:42:38 form4b kernel: [2939310.964174] buffer_info[next_to_clean]:
    Apr 1 21:42:38 form4b kernel: [2939310.964175] time_stamp <2bcb6e7d>
    Apr 1 21:42:38 form4b kernel: [2939310.964175] next_to_watch <5b>
    Apr 1 21:42:38 form4b kernel: [2939310.964176] jiffies <2bcb6fe5>
    Apr 1 21:42:38 form4b kernel: [2939310.964177] next_to_watch.status <0>
    Apr 1 21:42:40 form4b kernel: [2939312.964168] 0000:0d:00.0: eth0: Detected Tx Unit Hang:
    Apr 1 21:42:40 form4b kernel: [2939312.964170] TDH <5b>
    Apr 1 21:42:40 form4b kernel: [2939312.964171] TDT <74>
    Apr 1 21:42:40 form4b kernel: [2939312.964171] next_to_use <74>
    Apr 1 21:42:40 form4b kernel: [2939312.964172] next_to_clean <57>
    Apr 1 21:42:40 form4b kernel: [2939312.964173] buffer_info[next_to_clean]:
    Apr 1 21:42:40 form4b kernel: [2939312.964174] time_stamp <2bcb6e7d>
    Apr 1 21:42:40 form4b kernel: [2939312.964174] next_to_watch <5b>
    Apr 1 21:42:40 form4b kernel: [2939312.964175] jiffies <2bcb71d9>
    Apr 1 21:42:40 form4b kernel: [2939312.964176] next_to_watch.status <0>
    Apr 1 21:42:42 form4b kernel: [2939314.964171] 0000:0d:00.0: eth0: Detected Tx Unit Hang:
    Apr 1 21:42:42 form4b kernel: [2939314.964172] TDH <5b>
    Apr 1 21:42:42 form4b kernel: [2939314.964173] TDT <74>
    Apr 1 21:42:42 form4b kernel: [2939314.964174] next_to_use <74>
    Apr 1 21:42:42 form4b kernel: [2939314.964174] next_to_clean <57>
    Apr 1 21:42:42 form4b kernel: [2939314.964175] buffer_info[next_to_clean]:
    Apr 1 21:42:42 form4b kernel: [2939314.964176] time_stamp <2bcb6e7d>
    Apr 1 21:42:42 form4b kernel: [2939314.964177] next_to_watch <5b>
    Apr 1 21:42:42 form4b kernel: [2939314.964177] jiffies <2bcb73cd>
    Apr 1 21:42:42 form4b kernel: [2939314.964178] next_to_watch.status <0>
    Apr 1 21:42:44 form4b kernel: [2939316.596015] usb 3-1: reset high speed USB device using ehci_hcd and address 2
    Apr 1 21:42:47 form4b kernel: [2939319.824011] drbd0: PingAck did not arrive in time.
    Apr 1 21:42:47 form4b kernel: [2939319.824019] drbd0: peer( Secondary -> Unknown ) conn( Connected -> NetworkFailure ) pdsk( UpToDate -> DUnknown ) Apr 1 21:42:47 form4b kernel: [2939319.824039] drbd0: asender terminated
    Apr 1 21:42:47 form4b kernel: [2939319.824041] drbd0: Terminating asender thread
    Apr 1 21:42:47 form4b kernel: [2939319.824055] drbd0: short read expecting header on sock: r=-512
    Apr 1 21:42:47 form4b kernel: [2939319.882687] drbd0: Creating new current UUID
    Apr 1 21:42:47 form4b kernel: [2939319.882702] drbd0: Writing meta data super block now.
    Apr 1 21:42:47 form4b kernel: [2939319.885112] 0000:0d:00.0: eth0: Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
    Apr 1 21:42:47 form4b kernel: [2939319.903788] drbd0: tl_clear()
    Apr 1 21:42:47 form4b kernel: [2939319.904807] drbd0: Connection closed
    Apr 1 21:42:47 form4b kernel: [2939319.904814] drbd0: conn( NetworkFailure -> Unconnected ) Apr 1 21:42:47 form4b kernel: [2939319.904820] drbd0: receiver terminated
    Apr 1 21:42:47 form4b kernel: [2939319.904823] drbd0: receiver (re)started
    Apr 1 21:42:47 form4b kernel: [2939319.904826] drbd0: conn( Unconnected -> WFConnection ) Apr 1 21:42:47 form4b kernel: [2939320.216022] drbd0: Handshake successful: Agreed network protocol version 88
    Apr 1 21:42:47 form4b kernel: [2939320.216029] drbd0: conn( WFConnection -> WFReportParams ) Apr 1 21:42:47 form4b kernel: [2939320.216040] drbd0: Starting asender thread (from drbd0_receiver [7286])
    Apr 1 21:42:47 form4b kernel: [2939320.216221] drbd0: data-integrity-alg: <not-used>
    Apr 1 21:42:47 form4b kernel: [2939320.256924] drbd0: peer( Unknown -> Secondary ) conn( WFReportParams -> WFBitMapS ) pdsk( DUnknown -> UpToDate ) Apr 1 21:42:47 form4b kernel: [2939320.256937] drbd0: Writing meta data super block now.
    Apr 1 21:42:48 form4b kernel: [2939320.943705] drbd0: conn( WFBitMapS -> SyncSource ) pdsk( UpToDate -> Inconsistent ) Apr 1 21:42:48 form4b kernel: [2939320.943717] drbd0: Began resync as SyncSource (will sync 5932 KB [1483 bits set]).
    Apr 1 21:42:48 form4b kernel: [2939320.943731] drbd0: Writing meta data super block now.
    Apr 1 21:42:49 form4b kernel: [2939321.755465] drbd0: Resync done (total 1 sec; paused 0 sec; 5932 K/sec)
    Apr 1 21:42:49 form4b kernel: [2939321.755473] drbd0: conn( SyncSource -> Connected ) pdsk( Inconsistent -> UpToDate ) Apr 1 21:42:49 form4b kernel: [2939321.796062] drbd0: Writing meta data super block now.

    Bitte jetzt nicht über den 1. April auslassen ;-)

    Mein Problem ist, bei einem normalen Filesystem fällt das nicht auf. Bei der CAD Anwendung wird aber irgendwie mit Offline Dateien zur Replikation gearbeitet und da gibts dann Probleme.

    Wer könnte mir hier Tipps oder Infos dazu geben?
    Meine Vermutung war schon, dass die netzwerkkarte vielleicht überlastet ist und sich dann verhaspelt? Weit hergeholt vielleicht aber bisher mein einzigster Ansatz.

    Grüsse und einen schönen Restsonntag
    Jörg
    • 05 Apr 2009, 5:06 pm
  • Alexander Pilger
    Alexander Pilger    Premium Member
    The company name is only visible to registered members.
    Re: Linux Cluster mit DRBD hat Aussetzer
    Hallo Jörg,

    es fehlt etwas Information, um Lösungen entwicklen zu können:

    Welche Distribution?
    Welcher Kernel?
    Welche Ethernetkarte mit welchen Treibern und Einstellungen?

    Viele Grüße

    /alex
    • 05 Apr 2009, 5:23 pm
  • Jörg Lang
    Jörg Lang    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^2: Linux Cluster mit DRBD hat Aussetzer
    Hallo Alex,

    es handelt sich um Ubuntu 8.10 mit dem aktuellen Kernel.
    Netzwerkkarten sind onboard. Chip muss ich schauen, bin morgen vor Ort.

    Welche Einstellungen meinst Du?

    Da ich morgen wie gesagt vor Ort sein werde, kann ich alle nötigen Angaben raussuchen. Leider habe ich keinen Fernzugriff auf das System.

    Grüsse Jörg
    • 05 Apr 2009, 5:43 pm
  • Alexander Pilger
    Alexander Pilger    Premium Member
    The company name is only visible to registered members.
    Re^3: Linux Cluster mit DRBD hat Aussetzer
    Hallo Jörg,

    Einstellung für die Karten in der /etc/modules.conf.

    Ich kenne die Fehlermeldung von e1000-Interfaces. Hier gibt es auch einige Bug-Reports:

    z.B. http://sourceforge.net/tracker/?func=detail&aid=2221905&...

    Die Beschreibung der Karten-Parameter findest z.B. Du unter:
    http://www.mjmwired.net/kernel/Documentation/networking/e100...

    Die aktuellesten Treiber findest Du unter:

    http://sourceforge.net/projects/e1000

    Ist alles zwar keine wirkliche Diagnose, aber vielleicht findest Du damit einen Hinweis.

    Viele Grüße

    /alex
    • 05 Apr 2009, 7:03 pm
  • Johannes Hubertz
    Johannes Hubertz    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re: Linux Cluster mit DRBD hat Aussetzer
    Hallo,
    vielleicht sollte man sich mal das Log der Switches ansehen, da steht auch schon mal was wichtiges drin, so es eins gibt. Stichworte: bpdu, vlan, arp-cache, arp-flooding, ethercap (mim), ...

    Frohes Schaffen
    JH
    • 05 Apr 2009, 8:14 pm
  • Jörg Lang
    Jörg Lang    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^2: Linux Cluster mit DRBD hat Aussetzer
    Hallo,

    vielleicht sollte man sich mal das Log der Switches ansehen, da steht auch schon mal was wichtiges drin, so es eins gibt. Stichworte: bpdu, vlan, arp-cache, arp-flooding, ethercap (mim), ...
    Am Switch kann es nicht liegen, da ich den Server bzw. beide (Fehler tritt jeweils beim aktiven Server auf) auf einen anderen Switch umgehängt hatte. Die fehler kamen trotzdem.
    Der zweite Switch ist ein komplett anderes Gerät.

    Grüsse Jörg
    • 05 Apr 2009, 9:34 pm
  • Post visible to registered members
  • Jörg Lang
    Jörg Lang    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^4: Linux Cluster mit DRBD hat Aussetzer
    Hallo,

    ja es tritt eigentlich nur auf, wenn jemand arbeitet. Und dann jeweils eben nur an dem Server, der als primary geschalten ist.

    Grüsse Jörg
    • 05 Apr 2009, 11:57 pm
  • Johannes Hubertz
    Johannes Hubertz    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^5: Linux Cluster mit DRBD hat Aussetzer
    Hallo zusammen,
    BS schrieb:
    würde ich mal schwer auf ein MTU Problem setzen.
    im ersten Post steht u.a.:
    Apr 1 21:42:38 form4b kernel: [2939310.964169] 0000:0d:00.0: eth0: Detected Tx Unit Hang:
    ...
    Apr 1 21:42:40 form4b kernel: [2939312.964168] 0000:0d:00.0: eth0: Detected Tx Unit Hang:
    ...
    Apr 1 21:42:42 form4b kernel: [2939314.964171] 0000:0d:00.0: eth0: Detected Tx Unit Hang:
    Die 2 Sekunden deuten mir auf ein Layer II Problem (MAC-Adressen, Arp) daher kam ich auf den Switch.

    Die Framegroesse (einstellbar mittelbar durch die MTU) ist Layer III, sollte keine TX-Timouts verursachen, sondern Retries auf TCP/UDP zur Folge haben. Muesste man auch im Log sehen oder spaetestens mit tcpdump, dass sollte bei allen solchen Fehlern sowieso mitlaufen, wenn jemand davorsitzt und auf fehler wartet.

    Nur weil ein anderer Switch die gleichen Fehler macht, heisst das noch nicht, dass nix im Log steht.

    BTW: Hat drbd eigene Interfaces oder geht das neben dem Nutzertraffic einher?

    Noch eine Frage: Nachschlag: Sind alle beteiligten Netzmasken an allen Geraeten richtig eingestellt?

    Frohes Schaffen
    JH

    EDIT: Netzmaskenfrage hinzuegefuegt
    This post was modified on 06 Apr 2009 at 07:57 am.
    • 06 Apr 2009, 07:54 am
  • Jörg Lang
    Jörg Lang    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^6: Linux Cluster mit DRBD hat Aussetzer
    Guten Morgen,

    Die 2 Sekunden deuten mir auf ein Layer II Problem (MAC-Adressen, Arp) daher kam ich auf den Switch.
    Nur weil ein anderer Switch die gleichen Fehler macht, heisst das noch nicht, dass nix im Log steht.
    Okay, da der zweite Switch mehr kann, gehe ich mal davon aus, man kann da ein Log einsehen.
    Ich muss jetzt gleich zu dem Kunden fahren, dann schaue ich mir das mal an und poste ggf. die Ergebnisse.

    Muesste man auch im Log sehen oder spaetestens mit tcpdump, dass sollte bei allen solchen Fehlern sowieso mitlaufen, wenn jemand davorsitzt und auf fehler wartet.
    Das werde ich dann ebenfalls mal mitlaufen lassen.

    BTW: Hat drbd eigene Interfaces oder geht das neben dem Nutzertraffic einher?
    Die Server haben zwei Netzwerkkarten, über die eine (eth1) sind sie untereinander direkt per cross over Kabel verbunden. Die andere Karte (eth0) dient als reguläre Karte im netz und darauf wird dann auch die virtuelle IP Adresse geschalten.

    Noch eine Frage: Nachschlag: Sind alle beteiligten Netzmasken an allen Geraeten richtig eingestellt?
    An den Servern und PCs auf jeden Fall. Der Switch, an dem die Server normal hängen muss resettet werden, da er nicht mehr ansprechbar ist. Darum auch das Umhängen auf den zweiten Switch.
    Könnte man evtl sogar vermuten, dass der Switch der sich aufgehängt hat bzw. nicht mehr ansprechbar ist, Müll ins Kabel bläst und daher die Fehler kommen?

    Frohes Schaffen
    Vielen dank, wünsche ich ebenso.

    Grüsse Jörg
    • 06 Apr 2009, 08:56 am