Opened 5 years ago
Closed 3 years ago
#4191 closed Defekt (erledigt)
NC: Sync-Client verursacht Konflikte bei Zugriff auf Fileserver
| Reported by: | Rüdiger Kupper | Owned by: | Rüdiger Kupper |
|---|---|---|---|
| Priority: | schnell erledigen | Milestone: | Nextcloud: Optimierungen |
| Component: | Webdienst: Kepler-Cloud | Severity: | beeinträchtigt den Unterricht vieler Lehrer |
| Keywords: | Cc: | bau |
Description (last modified by )
Unser nächstes Problem:
Die letztlich sinnvollste Zugangsart zur Kepler-Cloud ist der NC-Desktop-Sync-Client. Funktioniert online wie offline und ohne Netzwerkverzögerung.
Nur: Der Syncclient ist derzeit praktisch unbenutzbar, da beim Bearbeiten einer Datei nach kurzer Zeit Konflikte entstehen.
Dabei ist es immer so, dass der Client die geänderte Version hochlädt, beim nächsten Sync aber erst nochmal die Vorgängerversion vom Server geschickt bekommt.
Wenn man die Dateiattribute auf dem paedml anschaut (und auch auf dem cloud-Server, die sind identisch), dann erkennt man die Ursache: es dauert einige Zeit, bis die geänderte Version tatsächlich auf dem Fileserver geschrieben ist. Für den Sync-Client ist die Operation aber längst abgeschlossen. Ruft er die aktuelle Fileliste ab, solange die Änderungen nicht konsolidiert sind, erhält er vom Server die alte Version als aktuell, was dann zum Konflikt führt.
Change History (20)
comment:1 by , 5 years ago
comment:2 by , 5 years ago
Ich tippe auf NFS und zwar genauer die async Mount-Option, die wir verwenden. Die beschleunigt den Zugriff, indem sie dem NFS-Server erlaubt, Vollzug zu melden, bevor die Daten wirklich geschrieben sind.
In meinem Verständnis war das immer ein Schreib-Cache, der natürlich softwaremäßig mit dem Lese-Cache synchron gehalten wird. Liest man die Doku, dann ist dort aber nirgends von Synchronusation mit dem Lese-Cache die Rede. Da steht immer nur, dass der Server fue Operation als abgeschlossen signalisiert, bevor das wirklich der Fall ist.
Falls dad wirklich wörtlich so gemeint ist könnte es gut unsercProblem verursachen.
comment:4 by , 5 years ago
Mein Verständnis wäre auch so, dass wir async nicht wollen. Die Einbindung der Ordner über ssh würde ich mit einem Mount vergleichen. Da will man ja auch nicht das Volumen entfernen, bevor der Cache geschrieben wurde... .
Soweit ich weiß hat NC auch noch ein internes FileLocking, aber das bezieht sich vermutlich nur auf Dateien die in der Datenbank liegen!?
comment:5 by , 5 years ago
| Description: | modified (diff) |
|---|
comment:6 by , 5 years ago
| Status: | new → accepted |
|---|
Setzen der sync-Option im NFS-Mount auf proxmoxls2 hat leider keine Veränderung gebracht.
comment:8 by , 5 years ago
Die sync-Option async auf dem paedml ist gesetzt, da ansonsten unser Netzwerk nicht mehr funktioniert (Erinnerung an die Zeit nach den Sommerferien, als wir auf NFS umgestellt hatten).
comment:9 by , 5 years ago
Prüfen, ob überall die Zeit WIRKLICH richtig geht! Eben fiel mir auf, dass kein Konflikt auftritt, wenn die letze Speicherung länger zurück liegt!
comment:10 by , 5 years ago
Nachdem ich längere Zeit keine Gelegenheit hatte, weiter nach dem Problem zu schauen fiel mir auf, dass die Konflikte seltener geworden sind. Sie treten jetzt nicht mehr *jedes* Mail auf, sondern nur noch etwa jedes zweite bis dritte Mail (noch immer eindeutig zu oft). Doch irgend etwas ist besser geworden.
Die Diskussion hier
https://github.com/nextcloud/desktop/issues/2467
geht davon aus, dass extern angebundene Dateiserver das Problem verursachen. Bei uns wäre das das NFS, und leider berichtet ein Teilnehmer auch, dass bei ihm das gleiche mit GlusterFS auftritt.
Aber vielleicht hat der Tausch und das Entfernen überflüssiger Switche das Problem reduziert? Auf welchem Weg greift der proxmoxls2 denn auf den paedml zu, hat sich auf dem Weg etwas verändert?
follow-up: 13 comment:11 by , 5 years ago
ProxMoxLS2 ist nicht der, der auf paedml zugreift. Der Virtualisierer ist mit einem 10GE-Glasfaser-Trunk an den ciscoServerraum angebunden - über den Trunk laufen dann alle VLANs.
Die VM cloud.kg-fds.de benutzt dann die virtuellen Bridges des ProxMoxLS2, das sind quasi Switche, die in einem VLAN hängen:
- net0/eth0 vmbr30 192.168.150.7/24 das ist das externe NIC im Proxmox-Netz hinter den öffentlichen IPs
- net1/eth1 vmbr6 10.16.112.16/24 Zugang aus dem Lehrernetz möglich (aktuell ungenutzt)
- net2/eth2 vmbr7 10.32.1.4/12 Zugang aus dem Schülernetz möglich (aktuell ungenutzt)
Aktuell werden alle Zugriffe über den apache.kg-fds.de auf den NextCloud-Server geleitet (über eth0).
Du bindest das NFS ja über das Lehrernetz ein, also von 10.16.112.4. Der Weg ist:
- über eth1 an vmbr6 zu ProxMoxLS2
- über den Glasfasertrunk in VLAN6
- zu ProxmoxPaedml dort an vmbr6
- weiter zu eth0 des paedml
Was noch eine Verbesserung bringen dürfte, ist die Umstellung auf dem ProxMoxPaedml von einem 8x 1GB Etherchannel mit Trunk zu einem 10GE Glasfaser-Trunk. Dann hat man auf jeder Linie immer die vollen 10GE und muss sich nicht auf die Lastverteilung nach IEEE 802.3ad verlassen.
comment:12 by , 5 years ago
Ich verpasse gerade dem apache.kg-fds.de jeweils eine Adresse in Gastnetzwerk und MobileDevices, so dass dort der Umweg über den Router entfallen kann. Dann könne die Clients aus dem jeweiligen Netzwerk direkt auf den Server zugreifen.
comment:13 by , 5 years ago
Replying to bau:
ProxMoxLS2 ist nicht der, der auf paedml zugreift. Der Virtualisierer ist mit einem 10GE-Glasfaser-Trunk an den ciscoServerraum angebunden - über den Trunk laufen dann alle VLANs.
Die VM cloud.kg-fds.de benutzt dann die virtuellen Bridges des ProxMoxLS2, das sind quasi Switche, die in einem VLAN hängen:
- net0/eth0 vmbr30 192.168.150.7/24 das ist das externe NIC im Proxmox-Netz hinter den öffentlichen IPs
- net1/eth1 vmbr6 10.16.112.16/24 Zugang aus dem Lehrernetz möglich (aktuell ungenutzt)
- net2/eth2 vmbr7 10.32.1.4/12 Zugang aus dem Schülernetz möglich (aktuell ungenutzt)
Der NFS-Zugriff findet aber nicht im Container statt, sondern direkt auf dem proxmoxls2. Grund war wieder der unpriviligierte Container, der darf den NFS-Kernel-Dienst nicht verwenden. Daher ist das NFS direkt auf dem proxmoxls2 eingehängt. Die Homerverzeichnisse werden dann vom ProxMox an den Container weitergereicht. Daher stimmt das hier nicht ganz:
Du bindest das NFS ja über das Lehrernetz ein, also von 10.16.112.4. Der Weg ist:
- über eth1 an vmbr6 zu ProxMoxLS2
- über den Glasfasertrunk in VLAN6
- zu ProxmoxPaedml dort an vmbr6
- weiter zu eth0 des paedml
Der Weg von cloud.kg-fds.de zum proxmoxls2 geht über die ProxMox-Freigabe und dann von dort ins Netzwerk. Also eher so:
- über die ProxMox-Verzeichnisfreigabe an proxmoxls2
- über den Glasfasertrunk in VLAN6
- zu ProxmoxPaedml dort an vmbr6
- weiter zu eth0 des paedml
Ist das richtig?
Ob das irgendwas ändert, weiß ich nicht.
Auch hier kann man mal den priviligierten Container testen, auf dem könnte ich das NFS direkt einbinden. Aber ob das noch Sinn ergibt, oder schauen wir lieber, dass wir möglichst bal den Gluster-Server laufen haben? Bei dem weiß ich nicht, wie es da mit unpriviligiert aussieht. (Beim Nextcloud-Server bin ich eher zurückhaltend, ihn priviligiert laufen zu lassen …)
comment:14 by , 5 years ago
Gluster-Server laufen und sind im VLAN6, 62, 63 und 64 verfügbar. Die Route in das Gluster-Netzwerk (VLAN 18) läuft über die Standard-Routen in VLAN 6 (10.16.112.126), 62 (10.16.112.254), 63 (10.16.113.126) und 64 (10.16.113.254), Router ist jeweils der ciscoServerraum (auf dem gibt es die virtuellen NIC VLAN6, VLAN62, VLAN63 und VLAN64 mit den angegebenen Adressen, sowie die neue VNIC VLAN18 mit 10.3.0.254.
Damit sind aus dem Lehrernetz alle Gluster-Server erreichbar:
- 10.3.0.1 gluster1
- 10.3.0.2 gluster2
- 10.3.0.3 gluster3
- 10.3.0.4 gluster4
comment:15 by , 5 years ago
Für das Schülernetz muss ich die Routen erst noch basteln. Dazu muss ich zunächst die VNIC auf dem ciscoServerraum absichern, damit dort nur Pakete aus den Lehrersubnetzen auch in die Lehrersubnetze geroutet werden. Die ACL funktionieren eigentlich, blocken aber leider auch die Pakete zu BelWUE, das muss erst noch behoben werden, deshalb sind die ACL grade inaktiv und harren auf die Hilfe von BelWUE.
comment:16 by , 5 years ago
Replying to bau:
ProxMoxLS2 ist nicht der, der auf paedml zugreift. Der Virtualisierer ist mit einem 10GE-Glasfaser-Trunk an den ciscoServerraum angebunden - über den Trunk laufen dann alle VLANs.
Mit der momentanen Durchleitung des Hostverzeichnisses in den Container greift momentan doch der proxmoxls2 auf den paedml zu, oder?
comment:17 by , 5 years ago
Ja, der !ProxMoxLS2 greift über seine vmbr6 über die vmbr6 auf dem ProxMoxPaedml auf die eth0 (die an der vmbr6 hängt) des paedml zu.
comment:19 by , 4 years ago
Neue Erkenntnis: Sync-Konflikte treten häufiger auf, je tiefer die Datei in der Ordnerhierarchie liegt.
comment:20 by , 3 years ago
| Resolution: | → erledigt |
|---|---|
| Status: | accepted → closed |
Es ist kaum zu glauben. Das Problem scheint wirklich mit dem Update auf NC 27.1.2 behoben zu sein. Nach Jahren der Wartezeit.
Und das heißt: nein, es lag nicht an meiner Anbindung des Fileservers. Nicht an unseren übermäßig vielen Dateien auf dem Tauschserver. Nicht an unserer zugemüllten Datenbank. Es war wirklich ein Bug in der Nextcloud-Software.
Das Problem tritt nur in den Fileserver-Verzeichnissen auf. Im Toplevel-Verzeichnis passiert das nicht.
Damit ist klar, dass Datenbankzugriffe nicht das Problem sind (die config-Optionen habe ich auch schon mehrfach geprüft). Bleiben also SSH und NFS als Übeltäter.