Bescheidene NFS-Performance als Grundlage für Virtualisierung?

[miccgn]

Hallo zusammen,

ich spiele in letzter Zeit verschiedene Setups zwischen FreeNAS, Proxmox, ESXi und diversen VMs durch.

Im Kern baue ich dabei die "Standard-Architektur":
- ein Host, bspw. ESXi, verwaltet verschiedene VMs
- darunter ist eine VM für einen Storage-Provider, hier FreeNAS, der wiederum NFS-Mounts bereitstellt
- die NFS-Mounts werden vom Host als Storage für weitere VMs verwendet.

Eine der gehosteten VMs verwaltet bei mir eine Nextcloud. Die Cloud-Daten liegen damit entweder innerhalb der VM und werden letztendlich im Rahmen der Disk, die im NFS liegt, auf FreeNAS durchgereicht - oder ich mache ein separaten NFS-Mount für die Cloud-Daten, so dass die Cloud-VM die Cloud-Daten direkt an FreeNAS durchreicht, während ihre eigentliche Disk via Host und NFS zu FreeNAS kommt.

In beiden Fällen habe ich eine echt bescheidene Schreibperformance, die im Bereich von 1-3 MB/s liegt. Die Lese-Performance ist bei rund 50 MB/s.
Grund ist, dass ja jedes einzelne Byte durch einen der beiden NFS-Mounts muss - teilweise mehrfach, da Nextcloud ja bei größeren Files erstmal Part-Files anlegt.
Hoste ich die Cloud hingegen in einem FreeNAS-Jail, kriege ich ein vielfaches an Performance beim Schreiben, das Lesen bleibt unverändert.

Ein bisschen NFS-Optimierung habe ich betrieben: selbstverständlich async, tcp und eine maximale wsize.

Jetzt frage ich mich: ist die bescheidene Performance von NFS nicht ein Problem für alle gehosteten VMs? Oder sind "normale" VMs, die nicht selber Fileserver sind, nicht so abhängig von der NFS-Leistung?

Fällt Euch noch eine Stelle ein, an der man drehen könnte, oder ist ein Jail auf FreeNAS für deratige Dinge wirklich der beste Ort, trotz der quasi doppelten Virtualisierung (ESXi -> FreeNAS -> Jail)?

(Es spielt dabei keine wesentliche Rolle, ob der Hypervisor ESXi oder Proxmox ist.)

 

[miccgn]

Ich habe noch etwas geforscht und herausgefunden, dass die reine NFS-Verbindung gar nicht so dramatisch langsam ist - mit einem dd erreiche ich Geschwindigkeiten zwischen 12 und 60 MB/s, je nach Dateigröße. Das hätte ich früher testen sollen.
Ich sollte also lieber nochmal etwas an den PHP- und Nextcloud-Settings spielen - vermutlich werden öfter als nötig einzelne Dateien übertragen.

 

[Stueckchen]

Wenn du NFS und Freenas als ZFS nutzt, machst du sync writes per default. Damit liegt du ohne Enterprise SSDs nur so bei sehr bescheiden Durchsatz bei random writes.

 

[asche77]

Deswegen auch Mal versuchen, die Daten per SMB zu teilen, dh einen SMB Share in FreeNAS anlegen und als externen Speicher in der nextcloud einbinden. Das sollte am performantesten sein.

 

[Trambahner]

Oder eine Optane 900P/905P als Slog-Device, wenn es NFS Sync-Writes sein sollen.
Geht bei mir durchaus mit 500MB/s innerhalb einer Windows-VM, die auf auf einem NFS-ZFS Share (Xigmanas @ ESXI 6.7U2) liegt. CDM-Score in etwa um 1000 rum für so ein Share.
Der Pool drunter besteht aus 3 Mirrorpärchen SM863 960GB (also 6 SSD). Nativ auf der Storage VM schreiben die sequentiell etwa 1,3-1,4 GB/s und lesen mit ~ 2-2,2 GB/s.
Die Partitions auf den SSDs sind dabei wenn ich mich richtig entsinne etwa 870GB groß, den Rest hab ich für Overprovisioning frei gelassen.

Läuft der SSD-Pool voll, wird mein nächster Pool vmtl. aus nem Mirror DC P4510 bestehen.

 

[besterino]

@Trambahner Was liegt denn bei Dir da drauf, dass der Pool droht vollzulaufen?

 

[miccgn]

Hallo zusammen,

danke für die Tipps! Das Thema "Sync" spielt aber keine Rolle, das ist selbstverständlich ausgeschaltet.
Ich erreiche mit einem dd if=/dev/zero of=/file/auf/dem/NFS/share Geschwindigkeiten von 42-48 MB/s. Bei einem dd, bei dem die Quelldatei in der VM liegt, also ebenfalls per NFS gelesen wird, komme ich entsprechend auf 22-24 MB/s.
Mit eingeschaltetem Sync bricht das schnell auf 3MB/s ein.

Derzeit nehme ich die defaults-Werte von NFS-Mount: rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,tcp,timeo=600,retrans=2,sec=sys,....
Unter Debian hat relatime/norelatime keine Wirkung, höhere Werte für size/wsize werden ignoriert.
=> mir fällt da nicht mehr viel ein, was ich an Parametern drehen könnte.

Ich habe mal verschiedene Netzwerkkarten durchprobiert und auch Multiqueueing - letzeres hatte eher einen leicht negativen Effekt, aber wir reden hier von 2-5%. Die Karte hatte keinen Einfluss, so dass ich jetzt bei virtio(paravirtualized) bleibe.

SMB hat in der Tat eine deutlich bessere Performance - allerdings auch nicht immer, und bricht natürlich spätestens dann ein, wenn eine Datei auf dem "externen Storage" gelöscht wird - dann kopiert Nextcloud sie ja in den "lokalen" Storage, liest also per SMB und schreibt per NFS.

Im großen und ganzen bin ich mit den NFS-Zeiten zufrieden. Schlimmer ist, dass davon aufm Nextcloud-Client nur 1-3 MB/s ankommen.
=> ich werde heute nochmal etwas an den Nextcloud- und PHP-Parametern spielen.

 

[wenzilinho]

Fällt Euch noch eine Stelle ein, an der man drehen könnte

Testest du das immernoch mit der WD Green? Wie ist sie durchgereicht? VMDK/RDM/Controller? Laufen noch andere VMs auf dem Pool?

 

[miccgn]

Nein, mittlerweile sind 2xWD RED (WD100EFAX) verbaut. Sie hängen am Mainboard-SATA, welcher wiederum in Proxmox* an die FreeNAS-VM durchgereicht wird. Beim Direktzugriff per SMB an FreeNAS oder beim Zugriff auf eine Nextcloud, die im FreeNAS-Jail liegt, gibt es auch nichts zu meckern.

*ich habe parallel auch noch ESXi auf einem Stick und spiele damit, die Performance ist dort in allen Fällen leicht besser, ich persönlich bevorzuge aber wg. Monitoring-Möglichkeiten (Fan-RPM, CPU-Temp etc.) Proxmox. Aber: auch da gibt sich das gleiche Bild: eine Transaktion, die auf der Proxmox-Plattform 2:30 dauert, dauert halt auf ESXi 2:15 - im FreeNAS-Jail sind es in beiden Fällen nur noch 0:25.

Es ist also offensichtlich, dass hier NFS und die Inter-VM-Kommunikation naheliegenderweise das Bottleneck ist. Was ja auch logisch erscheint. Es muss also mein Ziel sein, unnötige Dateitransaktionen in Nextcloud zu verhindern (chunking, Memcaching etc.)

Nextcloud im FreeNAS-Jail macht übrigens nicht so viel Spaß - ich mag zum einen die Doppelvirtualisierung nicht, zum anderen gibt es die eine oder andere Kleinigkeit im Plugin, die nerv.

Und es geht ja auch um eine grundsätzliche Frage: wie kann ich in einer derartigen Architektur (Hypervisor, Storage-VM, von dort NFS zu anderen VMs) datenintensive VMs sinnvoll betreiben?

 

[Luckysh0t]

Hast du denn auch mal eine andere Storage VM getestet ? z.B OmniOS. Ich weiß nur nicht wie dass unter Proxmox läuft.

 

[miccgn]

Hast du denn auch mal eine andere Storage VM getestet ? z.B OmniOS. Ich weiß nur nicht wie dass unter Proxmox läuft.

Nein. Das wäre auch eine Alternative, andererseits lese ich hier (und in anderen Foren) soviel über die Kombi "ESXi+FreeNAS+NFS-Storage für VMs", dass ich erstmal diese Kombi genauer untersuchen wollte. Entweder habe ich überzogene Erwartungen, oder es ist für andere nicht relevant schlimm, oder ich schaue mir halt genau den seltenen Schwachpunkt mit Nextcloud/PHP an.

 

[Stueckchen]

Schon mal dran gedacht vll die Nextcloud einfach auf dem VM Host zu Virtualiseren und nicht in der Freenas VM?
Aktuell läuft das bei mir so sehr gut.

 

[Luckysh0t]

FreeNas ist halt aufgebläht mit Features ohne ende - die man als Storage VM einfach nicht braucht - wenn eh ein Hypervisor ausenrum läuft.
Und mit Nappit von Gea kann man das ganze per WebGUI konfigurieren.

 

[gea]

Prinzipiell kann man folgendes sehen.

1. Direkter Storagezugriff is natürlich schneller als gleicher Storage bei dem man einen Netzwerkstack wie NFS dazwischenschaltet. Schnelles NFS bedeutet neben Netzwerkoptimierungen wie Jumboframes, erhöhte Anzahl von tcp und NFS Buffern ein Deaktivieren von Sync (zu Lasten der Sicherheit) oder von atime.

Von der NFS Performance her gibt es wenig Unterschiede zwischen den Betriebssystemen, eventuell mit leichtem Vorteil für Solaris & Co (da wurde NFS wie ZFS eben entwickelt). Teilweise hat sogar SMB inzwischen Performancevorteile gegenüber NFS. Auch kann FC/iSCSI leichte Vorteile haben. Bei Virtualisierung ist ESXi + HBA Pass-through am schnellsten, zusammen mit den virtuellen vmxnet3 Netzwerktreibern und einem eventuellem Verringern der Latenz der VM. Möglichst viel RAM für ZFS ist unabdingbar wenn man nicht gerade Optane für Storage einsetzt.

Eine leichtgewichtige Storage VM ist ebenso performancefördernd. Also statt FreeNAS z.B. XigmaNAS wenn man auf BSD bleiben möchte oder noch resourcenschonender Oracle Solaris (Textedition) mit Original-ZFS oder der freie Solaris Fork OmniOS mit Open-ZFS und eventuellen special vdevs für mehr Performance.

 

[miccgn]

Schon mal dran gedacht vll die Nextcloud einfach auf dem VM Host zu Virtualiseren und nicht in der Freenas VM?
Aktuell läuft das bei mir so sehr gut.

Hallo,
aber darum geht es doch genau: die Cloud läuft in einer VM auf dem Host, und wird damit also komplett per NFS versorgt. Wenn ich sie direkt in der FreeNAS-VM laufen lasse (in einem Jail) ist es deutlich schneller. Nur nerven mich die Jails von FreeNAS schon jetzt - es ist halt klar auf Storage, nicht auf Virtualisierung ausgelegt.

Prinzipiell kann man folgendes sehen.

1. Direkter Storagezugriff is natürlich schneller als gleicher Storage bei dem man einen Netzwerkstack wie NFS dazwischenschaltet. Schnelles NFS bedeutet neben Netzwerkoptimierungen wie Jumboframes, erhöhte Anzahl von tcp und NFS Buffern ein Deaktivieren von Sync (zu Lasten der Sicherheit) oder von atime.

Von der NFS Performance her gibt es wenig Unterschiede zwischen den Betriebssystemen, eventuell mit leichtem Vorteil für Solaris & Co (da wurde NFS wie ZFS eben entwickelt). Teilweise hat sogar SMB inzwischen Performancevorteile gegenüber NFS. Auch kann FC/iSCSI leichte Vorteile haben. Bei Virtualisierung ist ESXi + HBA Pass-through am schnellsten, zusammen mit den virtuellen vmxnet3 Netzwerktreibern und einem eventuellem Verringern der Latenz der VM. Möglichst viel RAM für ZFS ist unabdingbar wenn man nicht gerade Optane für Storage einsetzt.

Danke, genau diese Feststellungen teile ich und kann sie allesamt (außer iSCSI, damit habe ich bislang nicht gearbeitet) nachvollziehen.

Eine leichtgewichtige Storage VM ist ebenso performancefördernd. Also statt FreeNAS z.B. XigmaNAS wenn man auf BSD bleiben möchte oder noch resourcenschonender Oracle Solaris (Textedition) mit Original-ZFS oder der freie Solaris Fork OmniOS mit Open-ZFS und eventuellen special vdevs für mehr Performance.

Die werde ich mir vermutlich nach und nach anschauen.

Zwischenzeitlich habe ich wieder etwas ausprobiert, und in FreeNAS die Zahl der parallelen nfsd kräftig hochgeschraubt: statt 4 werkeln nun 16, was entgegen der FreeNAS-Empfehlung "nicht mehr nfsd als CPU-Cores" ist. Prompt steigt die NFS-Performance (gemessen mit verschiedenen dd's) um 50-90%!

Auf meine Nextcloud-Performance hatte das aber bislang keinen messbaren Einfluss - hier sind halt zuviele Spieler im Boot.

Zwischenstand:
- die NFS-Strecke performt mittlerweile ganz gut (bei nem 64MB-File aus /dev/zero per dd bin ich bei 70-100 MB/s, bei nem Transfer aus NFS nach NFS bei rund 30-40 MB/s). Dafür riskiere ich, dass der FreeNAS-nfsd irgendwann zuviele Kontextwechsel hat, was aber bei der eingeschränkten Userzahl nur selten auftreten sollte.
- die Nextcloud-Performance vom Win-Client aus ist weiter deutlich bescheidener, wenn die Cloud in einer VM per NFS-Anbindung läuft und nicht in einem Jail/Container auf FreeNAS. Da haut offenbar rein, dass Nextcloud Dateien mehrfach anfasst und ggf. als chunks verarbeitet, was viele Reads/Writes zu bedeuten scheint.

Ich sollte daher vielleicht den Thread umbenennen in "Bescheidene Nextcloud-Performance"

Danke für die Tipps und Anregungen!

 

[gea]

Was wird eigentlich mit Nextcloud gemacht. Nur Internet sync and share oder viele User mit Collaberationstools wie Kalender oder Multiuser Textdokumente?

Wenn es nur um Internetzugang zu einem ZFS Filer geht, ist Amazon S3 kompatibler Storage z.B. mit minIO um eine Größenordnung schneller, einfacher und sicherer als NextClowd/Owncloud.

Das Programm minIO ist Opensource und besteht im Gegensatz zu dem Monster NextCloud nur aus einer Datei (minio server) ohne irgendwelche Abhängigkeiten. Gibts für Linux/Unix mit den verschiedensten Client Apps, angefangen von dem integrierten mini client und dem Web-Client bis zu Veeam, rclone oder aber https://proprivacy.com/cloud/comparison/amazon-s3-user-interface-tools.

In napp-it (Für Solaris, OmniOS, OI, nicht in der Linux Version) habe ich es als Share Eigenschaft eines Dateisystems integriert, wie NFS oder SMB, https://forums.servethehome.com/index.php?threads/amazon-s3-compatible-zfs-cloud-with-minio.27524/

 

[tolga9009]

Was spricht eigentlich dagegen, das ZFS direkt unter Proxmox zu verwalten und die Nextcloud in einem LXC Container (Linux Distro deiner Wahl, z.B. Ubuntu) laufen zu lassen?

 

[gea]

Meiner Ansicht nach

Ein leistungsfähiges Web Appliance Management vs CLI

illumos: manual page: zpool.8

illumos: manual page: zfs.8

Ich arbeite jetzt seit ca 12 Jahren intensiv mit ZFS, möchte oder besser kann aber die Vielfalt der ZFS Möglichkeiten nicht auf der Kommandozeile einsetzen. Sun hat mit ZFS und Solaris ja bereits 2005 fast alles erschlagen was Storage ausmacht inkl. Raid, Volume und Share Management.

 

[asche77]

SMB hat in der Tat eine deutlich bessere Performance - allerdings auch nicht immer, und bricht natürlich spätestens dann ein, wenn eine Datei auf dem "externen Storage" gelöscht wird - dann kopiert Nextcloud sie ja in den "lokalen" Storage, liest also per SMB und schreibt per NFS.

Verstehe ich nicht. Wieso sollte Nextcloud da etwas per NFS schreiben oder in den "lokalen" storage kopieren?

Du kannst doch ein externes SMB Share in Nextcloud als einziges(!) zu synchronisierendes storage einbinden.

 

[Digi-Quick]

2xWD RED (WD100EFAX)
Herzlichen Glückwunsch, du hast DM-SMR Platten

NAS/Homeserver und RAID - Anfängerfragen

Moin, Ich spiele mit den Gedanken mir ein NAS bzw. Homeserver zu basteln. Nachdem ich vor geraumer Zeit auf Mini-ITX umgestiegen bin und den PC immer mitnehme, steht mein Zweit-PC mit meinem ganzen Datenmüll nur noch rum und fängt Staub. Wenn ich mal an irgendwelche Daten ran muss, beginnt die...

www.hardwareluxx.de

 

[miccgn]

Hallo,

Was wird eigentlich mit Nextcloud gemacht. Nur Internet sync and share oder viele User mit Collaberationstools wie Kalender oder Multiuser Textdokumente?

Wenn es nur um Internetzugang zu einem ZFS Filer geht, ist Amazon S3 kompatibler Storage z.B. mit minIO um eine Größenordnung schneller, einfacher und sicherer als NextClowd/Owncloud.

Das Programm minIO ist Opensource und besteht im Gegensatz zu dem Monster NextCloud nur aus einer Datei (minio server) ohne irgendwelche Abhängigkeiten. Gibts für Linux/Unix mit den verschiedensten Client Apps, angefangen von dem integrierten mini client und dem Web-Client bis zu Veeam, rclone oder aber https://proprivacy.com/cloud/comparison/amazon-s3-user-interface-tools.

In napp-it (Für Solaris, OmniOS, OI, nicht in der Linux Version) habe ich es als Share Eigenschaft eines Dateisystems integriert, wie NFS oder SMB, https://forums.servethehome.com/index.php?threads/amazon-s3-compatible-zfs-cloud-with-minio.27524/

das klingt prinzipiell nicht falsch, aber vorerst werde ich mal beim vertrauten bleiben. Ob ich zukünftig daneben eine weitere Sache ausprobiere und irgendwann umsteige, ist ja etwas anders. Aber danke für die Anregung.

Was spricht eigentlich dagegen, das ZFS direkt unter Proxmox zu verwalten und die Nextcloud in einem LXC Container (Linux Distro deiner Wahl, z.B. Ubuntu) laufen zu lassen?

Ziemlich genau das, was @gea geschrieben hat. Natürlich kann ich mir in Proxmox einen ZPool einrichten, Samba und NFS installieren und konfigurieren, Crons für die Snapshots ergänzen, und dann schauen, wie ich das alles regelmäßig gesichert kriege. In FreeNAS konnte ich viele der typischen Probleme (Berechtigungen, Schattenkopien etc.) in wenigen Minuten lösen, kann die Konfiguration mit einem Klick lokal ziehen und genauso schnell in eine nackte Neuinstallation zurückspielen. Letztendlich halte ich mir damit sogar die Freiheit offen, jede Komponenten einzeln tauschen zu können: in weniger als einer halben Stunde bin ich von ESXi auf PM oder umgekehrt umgezogen, und wenn FreeNAS mir zu blöd wird, kann ich es durch eine andere Storage-Lösung ersetzen, die einfach nur dieselben Shares bereitstellen muss.
Und, nein, Webmin ist keine Alternative

Verstehe ich nicht. Wieso sollte Nextcloud da etwas per NFS schreiben oder in den "lokalen" storage kopieren?

Du kannst doch ein externes SMB Share in Nextcloud als einziges(!) zu synchronisierendes storage einbinden.

Wenn wir davon reden, dass ich das innerhalb des Nextcloud-GUI mit der "Externer Storage"-App mache, dann landen auf dem Share exakt nur die Dateien, die der Anwender in die Cloud packt. Die ganzen Hintergrunddateien (Trashbin, Schattenkopien) landen weiterhin im lokalen data-Verzeichnis. Und wenn das mit der gesamten VM auf einem NFS liegt, bedeutet "Löschen" nichts anderes als: "Datei im SMB entfernen und dafür in das lokale data/USER/files_trashbin/files-Verzeichnis kopieren" - oder anders "Datei von SMB lesen und mit NFS schreiben".

2xWD RED (WD100EFAX)
Herzlichen Glückwunsch, du hast DM-SMR Platten

http://[URL]https://www.hardwarelux...und-raid-anfängerfragen.1265627/post-27433218

[/URL]

Die Diskussionen in verschiedenen Foren habe ich mir vor Wochen gut angeschaut und gemerkt, wie uneinig man sich ist. Weder der von Dir gezeigte Link noch die im Reddit verlinkte Platter Database erwähnen übrigens die WD100EFAX als SMR, lediglich das Nachfolgemodell WD101EFAX. Und: selbst wenn, es hat nichts mit dem hier betrachteten Performance-Problem zu tun - auf dem SMB-Share kriege ich problemlos die GbE-typischen 112 MB/s.

Beitrag automatisch zusammengeführt: 11.04.2020

Jetzt habe ich aber das Wichtige vergessen: durch Einsatz eines Redis-Servers auf der Cloud-VM konnte ich die Performance bei "Viele kleine Dateien" gut steigern.
Vorher haben 4000 Dateien zu je 1,5 MB von Windows aus 40min gebraucht, jetzt bin ich bei 20.

Ebenso konnte ich etwas Performance bei "großen Dateien" (350 MB) rausholen, indem ich im Windows-Client das Chunking umgestellt habe. Dadurch werden größere Brocken übermittelt, es werden weniger "Part"-Dateien abgelegt, die hinterher wieder gelesen und zusammengefügt werden müssen.

Das bestätigt den Ansatz: dadurch, dass eben diese Part-Dateien und auch die MariaDB (die ja ohne Redis auch für das Locking verwendet wird) letztendlich per NFS ans Storage kommt, gibt es viele parallele Zugriffe, deren Reduktion das Ganze deutlich performanter machen.

 

[Digi-Quick]

Wenn wir davon reden, dass ich das innerhalb des Nextcloud-GUI mit der "Externer Storage"-App mache, dann landen auf dem Share exakt nur die Dateien, die der Anwender in die Cloud packt. Die ganzen Hintergrunddateien (Trashbin, Schattenkopien) landen weiterhin im lokalen data-Verzeichnis. Und wenn das mit der gesamten VM auf einem NFS liegt, bedeutet "Löschen" nichts anderes als: "Datei im SMB entfernen und dafür in das lokale data/USER/files_trashbin/files-Verzeichnis kopieren" - oder anders "Datei von SMB lesen und mit NFS schreiben".

Moment mal, Schattenkopien / Papierkorb kann ZFS doch selbst >> Snapshots

Im Zweifel gehört das User Verzeichnis (= Nutzdaten) auf einen separaten Mountpoint und hat eigentlich nichts in der VM zu suchen

Die Diskussionen in verschiedenen Foren habe ich mir vor Wochen gut angeschaut und gemerkt, wie uneinig man sich ist. Weder der von Dir gezeigte Link noch die im Reddit verlinkte Platter Database erwähnen übrigens die WD100EFAX als SMR, lediglich das Nachfolgemodell WD101EFAX. Und: selbst wenn, es hat nichts mit dem hier betrachteten Performance-Problem zu tun - auf dem SMB-Share kriege ich problemlos die GbE-typischen 112 MB/s.

OK den Unterschied habe ich nicht gesehen, hatte nur auf EFAX geachtet

 

[miccgn]

Moment mal, Schattenkopien / Papierkorb kann ZFS doch selbst >> Snapshots
Im Zweifel gehört das User Verzeichnis (= Nutzdaten) auf einen separaten Mountpoint und hat eigentlich nichts in der VM zu suchen

Exakt so mache ich es ja auch: FreeNAS stellt neben dem Storage für die VMs einen weiteren für "Cloud-Daten" bereit, per NFS. Und der ist innerhalb der VM auf das /data-Verzeichnis gemountet. Damit ich eben mit ZFS Snapshots machen kann.
Die Standardfunktionen zu Schattenkopien und Trashbin lassen sich in Nextcloud sicherlich auch irgendwie einschränken.

Was ich eigentlich nur sagen wollte: wenn ich innerhalb der Nextcloud-GUI ext. Storage anbinde, hat der automatisch auch einen lokalen Teil. Denkbar wäre also nur, den Mountpoint für das Data-Verzeichnis nicht per NFS, sondern per SMB bereitzustellen. Das kann ich nochmal schnell probieren. Ich befürchte aber, es wird wenig daran ändern, dass Nextcloud im Standard sehr festplattenlastig ist (Chunks, Locks etc.) Ich werde berichten!

OK den Unterschied habe ich nicht gesehen, hatte nur auf EFAX geachtet

Ja, die WD101EFAX habe ich auch abgelehnt - sie lagen sehr preisgünstig (MyBook) vor mir, aber mir schien der "Vorgänger" aus mehreren Gründen besser geeignet.

 

[gea]

das klingt prinzipiell nicht falsch, aber vorerst werde ich mal beim vertrauten bleiben. Ob ich zukünftig daneben eine weitere Sache ausprobiere und irgendwann umsteige, ist ja etwas anders. Aber danke für die Anregung.

Einfach mal minIO installieren und ein ZFS Dateisystem per simple storage S3 freigeben und per Browser (oder S3 Desktop Tool) darauf zugreifen. Ist von der Einfachheit und Performance eine Offenbarung für Internet sync and share. Gibts ja für alle Linux/ Unix Systeme aber natürlich ohne die Collaborations Features von Nextcloud/Owncloud. Nextcloud ist ja auch eher ein Frontend für Storage (NFS, SMB oder S3) mit Extras. Ohne die Extras gehts halt viel schneller und einfacher.

ps
Bei minIO gibts keinen Grund das zu virtualisieren. MinIO als Applikation ist ja nur eine Datei ohne Abhängigkeiten. Alle Parameter wie Name, Passwort, ip und port oder ZFS Dateisystem werden einfach per Umgebungswert oder Parameter beim Start von minIO mitgegeben.

Es gibt dann auch nicht die Pflicht die fast wöchentlich neu entdeckten Lücken von Nextcloud (wg Apache, PHP, SQL, Client Tools) zu schließen. Läuft einfach durch, Sicherheitslücken - eher selten wegen der fehlenden Abhängigkeiten. Und wenn dann eben eine neue Version der einzigen minIO Datei anstatt der x Hundert Dateien einer NextCloud Installation.

Das ist ja auch warum ich Solarish nutze. SMB und NFS ist Teil von ZFS und da integriert, kein Bedarf für Mega-Tools wie SAMBA. Auch FC/iSCSI ist Teil des Betriebssystems. MinIO ist da die ideale Ergänzung.

..wenn alles nur so einfach wäre..

 

[Stueckchen]

Darf ich nochmal Nachfragen, mountest du die Daten jetzt via OS (der VM) oder per NC GUI?

 

[miccgn]

Darf ich nochmal Nachfragen, mountest du die Daten jetzt via OS (der VM) oder per NC GUI?

Vorhin habe ich es per GUI gemacht - dann sind auf dem Share nur die Dateien, die auch der Anwender in der GUI sieht.
Jetzt probiere ich es malim OS, also das /data-Verzeichnis per SMB auslagern. Ich bastele noch und berichte später oder morgen!

 

[Shutterfly]

Ich habe nun den Beitrag nur überflogen und konnte nicht finden, ob man NC nur wegen dem Sync oder auch wegen Kalender oder Groupware aktiv nutzt.

Wenn es nur um das Sync geht: Ich könnte auch Seafile als Alternative in den Raum werfen. Liefert eine bessere Sync-Performance als NC, kann Delta-Updates und arbeitet ressourcen sparender als NC. Habe ich bei mir in einer VM laufen, welche die Daten per NFS extern lagert (bis auf die zugehörige MySQL-Datenbank, die wird regelmäßig gesichert). Einziger Nachteil: Man kann auf die Daten nicht direkt zugreifen, da Seafile ein eigenes Blockformat verwendet.

Damit könnte man all den unnötigen NC Ballast loswerden, wenn es wirklich nur um Dateien geht.

 

[miccgn]

Ich bin ein Depp....

Das Thema "Sync" spielt aber keine Rolle, das ist selbstverständlich ausgeschaltet.

Richtig ist: beim mounten hatte ich jeweils auf async geachtet. Und in der Tat gab es bei NFS einen spürbaren Unterschied zwischen einem Mount mit sync und einem mit async. Bei SMB hingegen irgendwie nicht - die Performance war immer unrealistisch niedrig (6,5 MB/s). Da ist es mir dann endlich aufgefallen: am ZFS-Dataset war "Sync=Always" eingeschaltet...... Ich bitte um Vergebung!

Ich habe anschließend nochmal einige Tests gemacht:

MB/s	ZFS=sync, SMB	ZFS=sync, NFS=sync	ZFS=sync, NFS=async	ZFS=async, SMB	ZFS=async, NFS=sync	ZFS=async, NFS=async
dd aus /dev/zero ins Share	6,5	6,5	38-80	164	108	390-420
dd aus Share ins Share	5,2	5,5	27-45	62-78	87-120	218-427

Ich muss zugeben, dass ich nicht ganz nachvollziehen kann, welche Bedeutung dann noch das Sync-Argument bei NFS hat - es führt ja zu einem messbaren Unterschied, wie man sehen kann.
Und: es macht nochmal einen recht deutlichen Unterschied, ob ich beim ZFS-Dataset "sync=standard" (also nach Clientwunsch) kombiniert mit "NFS=async" sage, oder ob ich "Sync=disabled" sage. Müsste das nicht eigentlich identisch sein?

Wie dem auch sei: das war nochmal eine ordentliche Handbremse.

Im Praxis-Test von Windows aus sieht das dann so aus:

min:sec	/data-Verzeichnis auf SMB-Share async	/data-Verzeichnis auf NFS-Share async	Nextcloud in einem FreeNAS-Jail
4000 Dateien zu 1,5 MB	15:00 - 16:00	12:30 - 16:45	16:30
1 Datei zu 350 MB	0:30	0:20 - 1:05	0:19
1 Datei zu 7 GB	11:30	24:00 - 26:00	5:30

Es zeigt sich, dass in den meisten Fällen NFS und SMB gleichauf sind. Lediglich bei einer sehr großen Datei war NFS haushoch unterlegen. Das ist aber vermutlich nicht der typische Anwendungsfall (es sollen große Teile der Windows-Workstations (Musik, Fotos, Dokumente etc.) gesynct werden). Interessanterweise gewinnt auch das nur bei der riesigen Datei.

Weiter interessant ist: bei den 4000 Dateien ist der Zuwachs ordentlich, aber nicht so stark, wie es der Vergleich der Messwerte oben hatte erwarten lassen - heute Nachmittag war ich ja bei ca. 20min für die Übertragung.

So, ich schäme mich jetzt nochmal eine Runde, dass ich an den Schalter am Dataset nicht gedacht habe, und freue mich, dass es jetzt halbwegs akzeptabel wirkt. Der Unterschied zwischen SMB und NFS scheint nicht dramatisch zu sein, und das Jail hat keinen großen Abstand mehr, der im Alltag relevant wäre.

Danke für Eure Tipps!

Beitrag automatisch zusammengeführt: 12.04.2020

Ich könnte auch Seafile als Alternative in den Raum werfen.
...
Einziger Nachteil: Man kann auf die Daten nicht direkt zugreifen, da Seafile ein eigenes Blockformat verwendet.

Die Dateien würde ich eigentlich schon ganz gerne in ZFS-Snapshots abbilden können.

 

[you]

Einfach mal minIO installieren und ein ZFS Dateisystem per simple storage S3 freigeben und per Browser (oder S3 Desktop Tool) darauf zugreifen. Ist von der Einfachheit und Performance eine Offenbarung für Internet sync and share. Gibts ja für alle Linux/ Unix Systeme aber natürlich ohne die Collaborations Features von Nextcloud/Owncloud. Nextcloud ist ja auch eher ein Frontend für Storage (NFS, SMB oder S3) mit Extras. Ohne die Extras gehts halt viel schneller und einfacher.

Ich mag die Einfachheit von minio im Zusammenhang mit napp-it. Komfortabler geht es nicht. Was ich aber noch nicht gefunden habe, ist die Möglichkeit, damit ein Real-Time-Sync zwischen verschiedenen Rechnern hinzubekommen. Ich nutze nextcloud als "Syncstation" zwischen meinen Rechnern. Wenn ich für minio einen passenden Client hätte, der das möglich macht ... dann ...

Frohe Ostern und immer schön gesund bleiben!

Beitrag automatisch zusammengeführt: 12.04.2020

Ich bin ein Depp....
... am ZFS-Dataset war "Sync=Always" eingeschaltet...... Ich bitte um Vergebung!

tststs ... also MIR ist sowas noch NIEMALSNICHT passiert

 

[gea]

Ich mag die Einfachheit von minio im Zusammenhang mit napp-it. Komfortabler geht es nicht. Was ich aber noch nicht gefunden habe, ist die Möglichkeit, damit ein Real-Time-Sync zwischen verschiedenen Rechnern hinzubekommen. Ich nutze nextcloud als "Syncstation" zwischen meinen Rechnern. Wenn ich für minio einen passenden Client hätte, der das möglich macht ... dann ...

Das einfachste Tool is rclone (rsync for cloud).
Das als geplanten Task (oder manuell als Desktop Icon) laufen lassen.

How to Install and Run Rclone as a Windows Service (2019/10/2016/8/2012/7/2008)

Automatically start the Rclone VoIP server in the background as a Windows Service when your computer boots, before anyone logs on. Keep it running 24x7.

www.coretechnologies.com

Oder eins der S3 Tools z.B.

5 Best Amazon S3 User interface tools | GUIs for Amazon simple storage

Amazon S3 is an incredibly useful Storage as a Service (SaaS) product, but it's not the most user friendly. Click here to learn more about third party UIs.

proprivacy.com

Googeln nach "s3 sync tools" findet noch mehr.

Ich würde einen sync aber manuell und kontrolliert anstoßen. Offene Dateien oder nicht exakt syncrone Zeiteinstellungen können sonst immer was ungewollten provozieren. Immerhin kommt man bei Problemen noch lokal per SMB auf das S3 Share und kann per Snap/ Windows vorherige Version noch was retten.