Netzwerkprobleme - Rechner bleiben "stehen"

M

Morfio

Well-Known Member
Hallo zusammen,

wir haben ein ganz komisches Problem. Unser Netzwerk besteht aus mehreren Servern sowie Clients. Es gibt drei Hauptserver, die via CARP "zusammengeschlossen" sind (ein Master, zwei Backups). Der Master hat die Aufgaben NIS, NFS, AFP, PostgreSQL und Synchronisation der Daten (zur Zeit noch via rsync) auf die anderen Server.

Etwas mehr als vierzig Clients sind an das NIS gebunden, davon um die 20 Macs (zw. Mountain Lion und Mavericks), 20 Ubuntu (12.04) und ein paar FreeBSD-Clients (10.1-RELEASE).

Die Ubuntu- sowie die FreeBSD-Maschinen haben ihr "Home" via NFS gemountet und greifen noch auf eine weitere Freigabe zu. Die Macs greifen via AFP zu. Ab und an wird mal ein wenig Samba gesprochen, aber eher selten. Des Weiteren führen die Macs regelmäßig TimeMachine-Backups durch.

Auf den Servern läuft FreeBSD 10.1-RELEASE mit Software-RAIDs, wobei die Festplatten an LSI-Controllern (9201-16i mit IT-Firmware 19.0) auf SuperMicro-Boards angeschlossen sind. Die Konstellation ist folgende:

3 x SSDs, partitioniert nach "Boot", "/" (UFS) und Swap und jeweils in einem GEOM_MIRROR (gmirror)
3 x SSDs, für ZFS Log und Cache
8 x HDDs, NL-SAS WD-RE mit 4TB zu einem zraid2 (GELI AES 256bit verschlüsselt, AESNI ist geladen und wird unterstützt)

Hier genauer:

Code: 
[18:16:36 thorsten@grobi ~]: gpart show -l
=>  34  250069613  da0  GPT  (119G)
  34  6  - free -  (3.0K)
  40  1024  1  (null)  (512K)
  1064  984  - free -  (492K)
  2048  41943040  2  swap2  (20G)
  41945088  208124559  3  system2  (99G)

=>  34  250069613  da1  GPT  (119G)
  34  6  - free -  (3.0K)
  40  1024  1  (null)  (512K)
  1064  984  - free -  (492K)
  2048  41943040  2  swap1  (20G)
  41945088  208124559  3  system1  (99G)

=>  34  250069613  da2  GPT  (119G)
  34  6  - free -  (3.0K)
  40  1024  1  (null)  (512K)
  1064  984  - free -  (492K)
  2048  41943040  2  swap0  (20G)
  41945088  208124559  3  system0  (99G)

=>  34  250069613  da3  GPT  (119G)
  34  125034496  1  cache0  (60G)
  125034530  125035117  2  log0  (60G)

=>  34  7814037101  da4  GPT  (3.6T)
  34  7814037101  1  storage1  (3.6T)

=>  34  7814037101  da5  GPT  (3.6T)
  34  7814037101  1  storage0  (3.6T)

=>  34  250069613  da6  GPT  (119G)
  34  125034496  1  cache2  (60G)
  125034530  125035117  2  log2  (60G)

=>  34  250069613  da7  GPT  (119G)
  34  125034496  1  cache1  (60G)
  125034530  125035117  2  log1  (60G)

=>  34  7814037101  da8  GPT  (3.6T)
  34  7814037101  1  storage5  (3.6T)

=>  34  7814037101  da9  GPT  (3.6T)
  34  7814037101  1  storage4  (3.6T)

=>  34  7814037101  da10  GPT  (3.6T)
  34  7814037101  1  storage3  (3.6T)

=>  34  7814037101  da11  GPT  (3.6T)
  34  7814037101  1  storage2  (3.6T)

=>  34  7814037101  da12  GPT  (3.6T)
  34  7814037101  1  storage7  (3.6T)

=>  34  7814037101  da13  GPT  (3.6T)
  34  7814037101  1  storage6  (3.6T)

[18:16:39 thorsten@grobi ~]: gmirror status
  Name  Status  Components
  mirror/swap  COMPLETE  da0p2 (ACTIVE)
  da1p2 (ACTIVE)
  da2p2 (ACTIVE)
mirror/system  COMPLETE  da0p3 (ACTIVE)
  da1p3 (ACTIVE)
  da2p3 (ACTIVE)

  pool: server
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
   attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
   using 'zpool clear' or replace the device with 'zpool replace'.
  see: http://illumos.org/msg/ZFS-8000-9P
  scan: resilvered 897G in 35h47m with 0 errors on Thu Dec 18 23:50:43 2014
config:

   NAME  STATE  READ WRITE CKSUM
   server  ONLINE  0  0  0
    raidz2-0  ONLINE  0  0  0
    gpt/storage0.eli  ONLINE  0  0  0
    gpt/storage1.eli  ONLINE  0  0  0
    gpt/storage2.eli  ONLINE  0  0  0
    gpt/storage3.eli  ONLINE  0  0  0
    gpt/storage4.eli  ONLINE  0  0  0
    gpt/storage5.eli  ONLINE  0  0  0
    gpt/storage6.eli  ONLINE  0  0  0
    gpt/storage7.eli  ONLINE  0  0  0
   logs
    mirror-1  ONLINE  0  0  0
    gpt/log0.eli  ONLINE  0  0  0
    gpt/log1.eli  ONLINE  0  0  0
    gpt/log2.eli  ONLINE  0  0  0
   cache
    gpt/cache0.eli  ONLINE  0 9,24M  0
    gpt/cache1.eli  ONLINE  0 9,23M  0
    gpt/cache2.eli  ONLINE  0 9,23M  0

errors: No known data errors

Es sind zur Zeit zwei NICs via LACP an einem HP 1810-48-Switch angeschlossen (vorher waren es vier, wir haben aber testweise mal zwei entfernt):

Code: 
lagg0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
   options=403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO>
   ether 00:25:90:81:29:9a
   inet 192.168.0.3 netmask 0xffffff00 broadcast 192.168.0.255
   inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 vhid 1
   nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
   media: Ethernet autoselect
   status: active
   carp: MASTER vhid 1 advbase 1 advskew 100
   laggproto lacp lagghash l2,l3,l4
   laggport: igb1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
   laggport: igb0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>

Auf dem Server läuft das Schreiben und Lesen von Daten recht schnell (300 bis 450 Megabytes pro Sekunde). Es gibt jetzt zwei Probleme:

1) Kopiere ich per Netzwerk (NFS oder SSH) Daten auf den Server, bekomme ich nur zw. 30 und 45 MB pro Sekunde. Per iperf kommen aber immer so 800 bis 900 Mbit zusammen. Woran kann das liegen? Die Festplatten sind letztlich ja schnell genug und ich habe auch probiert, in tmpfs zu schreiben mit dem selben Problem.

2) Das wesentlich wichtigere Problem ist, dass laufend die Desktops (vereinzelt auch einzelne Programme) der Workstations "einfrieren". Das äußert sich so, dass sich oftmals die Maus noch bewegen lässt, aber die Arbeitsflächen nicht mehr gewechselt werden können und Programme nicht mehr reagieren oder neugezeichnet werden. Und das bei Ubuntu und FreeBSD. Bei den Macs kommt dann der Sat1-Ball. Nach 10 Sekunden bishin zu wenigen Minuten geht es dann weiter. Dieses Problem tritt etliche Male am Tag auf.

Woran könnte das liegen?

Wir haben bisher folgendes gemacht:

- Server getauscht gegen Backup-Server - selbes Problem (die Hardware ist anders und etwas älter, aber es ist der gleiche LSI-Controller und die gleiche Plattenkonstellation drin

- BIOS + NIC-Firmwares auf aktuellen Stand gebracht

- Switch getauscht (gegen nicht LACP-fähigen aus Mangel, LACP abgeschaltet)

- Alle "unnötigen" Karten aus dem Server ausgebaut

- Von LWL-Switch-Verbindungen auf Kupferverbindungen gewechselt (die LWL-Module setzen wir gerade seit einem Monat ein)

- "Kuriose" Netzwerkgeräte (so Mini-Switches) aus dem Netzwerk entfernt

- Logs geprüft von Server und Clients. Es steht rein gar nichts drin

- ARC limitiert (auf 15GB bei einem Server mit 64G RAM)

Mir fällt nichts mehr ein. Hat vielleicht jemand von Euch noch eine Idee?

Viele Grüße

Morfio
 
Das klingt ja nach einem schwer zu diagnostizierendeb Problem

Ich bin nicht so der MAC-Profi, aber liegen dort auch die kompletten Profile im NFS?

Tritt das Problem bei allen Clients gleichzeitig auf?
Gibt es zu dem Zeitpunkt noch anderes auffälliges verhalten? (Nicht Pingbar z.B.?)
Wenn du auf den Clients auch einen Server-Dienst hast (z.B. ssh) hängt der dann auch oder betrifft das nur "X" Programme?

Hast du mal nen Networksniffer laufen lassen und geschaut ob zu dem Zeitpunkt wenn einer aussteigt etwas "merkwürdiges" Passiert?

Tritt das Problem auch auf wenn kein NFS/AFP gemountet ist?
 
ch bin nicht so der MAC-Profi, aber liegen dort auch die kompletten Profile im NFS?
Zum Vergrößern anklicken....

Nein, die Profile der Macs sind lokal. Wir hatten bisher immer Probleme bei den Mac-Workstations mit NFS-Homes. Ein großer Teil sind auch MacBooks, deren Profil wir nicht per NFS mounte könnten.

Tritt das Problem bei allen Clients gleichzeitig auf?
Zum Vergrößern anklicken....

Mal ja, mal nein. Bleibt der gesamte Desktop stehen, dann bei allen gleichzeitig. Reagiert über eine kurze Weile ein Programm alleine nicht, dann kann das ein paar betreffen, aber nicht alle.

Gibt es zu dem Zeitpunkt noch anderes auffälliges verhalten? (Nicht Pingbar z.B.?)
Zum Vergrößern anklicken....

Etwas auffälliges konnte ich bisher nicht feststellen. Da auch meine Workstation in der ganzen Sache so drinhängt, konnte ich auch noch nicht pingen. Ich werde mir morgen ein dediziertes Gerät hinstellen, womit ich das ausprobieren kann.

Wenn du auf den Clients auch einen Server-Dienst hast (z.B. ssh) hängt der dann auch oder betrifft das nur "X" Programme?
Zum Vergrößern anklicken....

Ich gehe dann meist auf die Konsole ([Strg]+[Fx]), kann mich in der Zeit aber nicht anmelden. Weiter habe ich noch nicht ausprobiert (mich morgens zum Beispiel erstmal auf der Konsole ebenfalls anmelden und im Fehlerfall ausprobieren - das werde ich jetzt noch tun).

Hast du mal nen Networksniffer laufen lassen und geschaut ob zu dem Zeitpunkt wenn einer aussteigt etwas "merkwürdiges" Passiert?
Zum Vergrößern anklicken....

Nein, mit Netzwerksniffern habe ich mich bisher noch nicht auseinandergesetzt. Ich werde das auf dem dedizierten Rechner jetzt einmal machen.

Tritt das Problem auch auf wenn kein NFS/AFP gemountet ist?
Zum Vergrößern anklicken....

Kann ich noch nicht sagen, bisher sind bei uns allen Laufwerke via NFS oder AFP gemountet. Muss ich noch ausprobieren.
 
Das wesentlich wichtigere Problem ist, dass laufend die Desktops (vereinzelt auch einzelne Programme) der Workstations "einfrieren". Das äußert sich so, dass sich oftmals die Maus noch bewegen lässt, aber die Arbeitsflächen nicht mehr gewechselt werden können und Programme nicht mehr reagieren oder neugezeichnet werden. Und das bei Ubuntu und FreeBSD. Bei den Macs kommt dann der Sat1-Ball. Nach 10 Sekunden bishin zu wenigen Minuten geht es dann weiter. Dieses Problem tritt etliche Male am Tag auf.
Zum Vergrößern anklicken....

Vorweg: Ferndiagnosen sind natürlich immer ein Herumstochern im Nebel. Dennoch, irgendwie klingt das nach einem massiven Netzwerkproblem. Genauer gesagt nach einem sporadischen Abreißen der Netzwerkverbindung, die dann erst nach den 10 Sekunden bis mehreren Minuten zurückkehrt. Das kann natürlich viele Ursachen haben, aber nach allem was du bisher gemacht hast, ist die Hardware wahrscheinlich auszuschließen. Ich würde auch erst einmal einen Ping-Test machen um zu sehen, ob es während des Aussetzer überhaupt Antworten gibt. Und wenn ja von wem. Interessant sind auch immer Duplikate, also mehrere Antworten auf einen Ping.

Dann zur weiteren Diagnose:
  • Das Verhalten riecht nach IP-Kollisionen. Das kann eine Kollision im klassischen Sinne sein, ein guter aber leider nicht perfekter Hinweis darauf sind bouncende ARPs in der dmesg. Im Stil von "192.168.0.1 moved from X to Y" und kurz darauf zurück in Gegenrichtung. Aber auch Dinge wie ein Host mit zwei Netzwerkkarten (technisch gesehen MAC-Adressen) im gleichen Subnetz.
  • (Rapid) Spanning Tree hin oder her, ist das Netz wirklich zyklenfrei? Wir wissen alle, dass trotz entsprechender Switches so manche Hardware ihre Probleme damit hat.
  • Zur Not den CARP-Verbund mal auflösen und es ohne probieren. CARP ist eine schöne Sache, es gibt allerdings durchaus Dienste, die sich damit beißen können. Das bekommt man aber normalerweise konfiguriert.
 
ist die Anzahl der NFS Serverprozesse ausreichend hoch? nfsstat -s und nfsstat -c ?
Zum Vergrößern anklicken....

Code: 
root@grobi:~ #  nfsstat -s

Server Info:
  Getattr  Setattr  Lookup  Readlink  Read  Write  Create  Remove
 29239469  38691  41519748  758  5354052  3583188  0  65565
  Rename  Link  Symlink  Mkdir  Rmdir  Readdir  RdirPlus  Access
  24844  379  96  1538  5391  77644  37225  17275808
  Mknod  Fsstat  Fsinfo  PathConf  Commit
  14  265874  88  52826  463233
Server Ret-Failed
  0
Server Faults
  0
Server Cache Stats:
  Inprog  Idem  Non-idem  Misses
  0  0  0  98084808
Server Write Gathering:
 WriteOps  WriteRPC  Opsaved
  3583188  3583188

Code: 
root@tgeppert:~ # nfsstat -c
Client Info:
Rpc Counts:
  Getattr  Setattr  Lookup  Readlink  Read  Write  Create  Remove
  89832  3319  309058  141  85570  306326  3906  1330
  Rename  Link  Symlink  Mkdir  Rmdir  Readdir  RdirPlus  Access
  1047  4  8  105  2040  12287  0  41069
  Mknod  Fsstat  Fsinfo  PathConf  Commit
  2  12937  3  1093  75168
Rpc Info:
 TimedOut  Invalid X Replies  Retries  Requests
  0  0  0  0  945285
Cache Info:
Attr Hits  Misses Lkup Hits  Misses BioR Hits  Misses BioW Hits  Misses
  7212814  89849  5485549  309056  1120498  67058  982341  300191
BioRLHits  Misses BioD Hits  Misses DirE Hits  Misses Accs Hits  Misses
  3946  141  11182  12270  11425  8  5846777  41120

Das Verhalten riecht nach IP-Kollisionen. Das kann eine Kollision im klassischen Sinne sein, ein guter aber leider nicht perfekter Hinweis darauf sind bouncende ARPs in der dmesg. Im Stil von "192.168.0.1 moved from X to Y" und kurz darauf zurück in Gegenrichtung.
Zum Vergrößern anklicken....

Danach hatte ich zuerst geguckt, das ist nicht der Fall.

Aber auch Dinge wie ein Host mit zwei Netzwerkkarten (technisch gesehen MAC-Adressen) im gleichen Subnetz.
Zum Vergrößern anklicken....

Ich habe mal in unserem Protokoll geguckt. Da fehlen zwar die Drucker-MACs, aber doppelte Computer-NIC-MACs haben wir nicht.

(Rapid) Spanning Tree hin oder her, ist das Netz wirklich zyklenfrei? Wir wissen alle, dass trotz entsprechender Switches so manche Hardware ihre Probleme damit hat.
Zum Vergrößern anklicken....

Davon habe ich keine Ahnung, muss ich mich einlesen.

Zur Not den CARP-Verbund mal auflösen und es ohne probieren. CARP ist eine schöne Sache, es gibt allerdings durchaus Dienste, die sich damit beißen können. Das bekommt man aber normalerweise konfiguriert.
Zum Vergrößern anklicken....

Das ist wohl eine der nächsten Dinge. Allerdings nutzen wir das seit zwei oder drei Jahren bereits. Was wir getan haben ist, auf Netatalk 3 zu wechseln, davor hatten wir immer Version 2.
 
Was ab und an im Log (messages) auftaucht, ist folgendes:
Code: 
Feb 19 08:31:38 grobi rpc.statd: Unsolicited notification from host $COMPUTER_HOSTNAME
 
Bei mir lag es an der MTU. Ich habe letztens Failover konfiguriert und die größte gemeinsame MTU aller Devices verwendet. Dann hatte ich Probleme dass NFS und SSH-Prozesse einfrieren und nicht einmal mehr die Timeouts greifen.

Jetzt sind alle MTUs auf 1500 genagelt und alles läuft. Leider heißt das halt auch beim GbE Verzicht auf Jumbo Frames.
 
Kamikaze schrieb:
Bei mir lag es an der MTU. Ich habe letztens Failover konfiguriert und die größte gemeinsame MTU aller Devices verwendet. Dann hatte ich Probleme dass NFS und SSH-Prozesse einfrieren und nicht einmal mehr die Timeouts greifen.

Jetzt sind alle MTUs auf 1500 genagelt und alles läuft. Leider heißt das halt auch beim GbE Verzicht auf Jumbo Frames.
Zum Vergrößern anklicken....
Ich habe gerade mal nachgesehen. Bei uns steht alles standardmäßig auf 1500.

https://lists.freebsd.org/pipermail/freebsd-fs/2012-March/014010.html ich nehme an das hast du auch gesehen?
Zum Vergrößern anklicken....

Ja, wir werden demnächst auch vollständig auf nfsv4 umsteigen.
 
Wir haben das Problem jetzt nach viel Hardwaretauscherei wohl lokalisiert. Es scheint am "Dateisystem" zu liegen.
Sobald wir auf unserem Server direkt (via SSH oder direkt am Server) ein Verzeichnis mit vielen Daten kopieren (cp -r /server/bla /server/gna), bleiben die Maschinen hier stehen und es lässt sich dateisystemtechnisch nichts mehr machen. Sobald man den Vorgang abbricht, läuft es weiter.

Wir haben keine Ahnung, woran das liegen könnte, haben aber mal mit dd folgende Werte ermittelt:

Auf gmirror auf SSDs mit UFS
Code: 
root@grobi:/tmp # dd if=/dev/zero of=test bs=10m count=400
400+0 records in
400+0 records out
4194304000 bytes transferred in 32.305125 secs (129834012 bytes/sec)

Dort sieht man, dass das schon langsam ist. Mit den gleichen Platten in meiner Workstation, ebenfalls mit
gmirror, erhalte ich folgende Werte:
Code: 
root@tgeppert:/tmp # dd if=/dev/zero of=test bs=10m count=400
400+0 records in
400+0 records out
4194304000 bytes transferred in 8.566819 secs (489598767 bytes/sec)
Da sieht man schon einen deutlichen Unterschied.

Auf ZFS auf dem Server (mit geli-Verschlüsselung):
Code: 
root@grobi:/server # dd if=/dev/zero of=test bs=10m count=400
400+0 records in
400+0 records out
4194304000 bytes transferred in 3.531009 secs (1187848586 bytes/sec)
Auch das sieht sehr gut aus. Sobald man aber via cp kopiert, sackt die Geschwindigkeit auf ein extrem niedriges Niveau ab.

Woran kann das liegen? Auf dem Server sind alle Festplatten am LSI 9201-16i mit IT-Firmware. Auf meiner Workstation hängen die Platten direkt auf dem Motherboard.

Viele Grüße

Morfio
 
Wenn du so "kleine" Dateien schreibst, spielt auch das Caching mit rein. Unter Linux gabs glaub ich für dd einen Parameter, der "direkt" auf die Platten schreibt - so könntest du das ausschließen und hättest vergleichbare Werte.

Gruß
Markus
 
Wir haben jetzt mal ein rsync mit --progress gemacht. Spannend ist, dass (auch bei großen Dateien) bleibt das Synchronisieren teilweise über 10 Sekunden stehen. In der Zeit reagiert die Maschine auch sehr träge. Nach der Wartezeit geht dann die Schreibgeschwindigkeit ganz gut in den Keller, erholt sich dann aber wieder, bis er wieder stehen bleibt. In der Zeit gibt es keine CPU-Auslastung.
 
Wir haben es jetzt mal auf etlichen Maschinen mit 10.1 ausprobiert. Überall bleiben die Maschinen "stehen".
 
Illuminatus schrieb:
https://forums.freebsd.org/threads/random-slow-disk-i-o-on-10-1-release.50392/#post-282210 - denkst du ein Abschalten von Stromsparmechanismen kommt in Frage?
Zum Vergrößern anklicken....
Wie die das im Forum beschrieben haben funktioniert bei uns nicht:

Code: 
root@tiffy:/server #  smartctl -g apm /dev/da0
smartctl 6.3 2014-07-26 r3976 [FreeBSD 10.1-RELEASE amd64] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

SCSI device successfully opened

Use 'smartctl -a' (or '-x') to print SMART (and more) information
 
Wenn es nur auf ZFS auftritt: Ich würde mal das TXG-Timeout heruntersetzen. Gerade bei vielen kleinen Änderungen sammelt ZFS erst einmal und schreibt erst aus, wenn der Transaktionsplan gefüllt ist. Wenn die Änderungen klein genug sind, dass sie er gefüllt wird, läuft er nach 5 Sekunden ins Timeout und erzwingt ein Ausschreiben. Sind die Platten nun aber zu langsam, hat er die letzte Runde Transaktionen noch nicht verarbeitet, wenn bereits das nächste Timeout greift. ZFS reagiert darauf, indem es den Zufluss neuer Änderungen drastisch begrenzt. Es zeigt sich als stark stotterndes System. Setzt man das Timeout herunter, verteilt sich die Last etwas besser. Das ist allerdings ein Work Around.

Dazu in der /boot/loader.conf:
Code: 
set vfs.zfs.txg.timeout=$sekunden
Standard-Einstellung ist 5 Sekunden. Man kann bis zu 1 Sekunden runtergehen. Wenn es das Problem verringert, hast du eine zu langsame Hardware.
 
Ich hatte mal ne WD Platte die nur 5MB/s unaligned writes schaffte sobald ihr Write Cache voll war. Falls das der Fall sein sollte ist die Lösung einfach, aber lästig. Du musst die Pools mit korrektem Alignment und ashift neu anlegen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben