Moin,
wenn man die folgenden Antworten, in dem verlinkten Thema betrachtet, ist das Thema doch eigentlich nicht wirklich mehr relevant :
Alternativ können Sie auch unseren RS 8000 mit SAS-Festplatten verwenden. Die SAS-Festplatten bieten hier eine bessere Performance, als sie manch ein Marktbegleiter mit SSDs anbietet. Der Vorteil liegt darin, dass wir einen recht großen Cache verwenden und zudem viele parallele Spindeln einsetzen.
Den Parameter "iops_size" nutzen wir nicht in unserer Konfiguration. Wir haben das Scheduling für IO-Operationen so erweitert, dass länger andauernde IO-Last nicht dazu führt, dass eine Herabstufung der Priorität derart große Auswirkungen hat, wie hier zum Teil geschildert.
Wenn du dauerhaft mehr Leistung benötigst oder Garantien in der Hinsicht erwatest, dann ist vermutlich sowas für dich angebracht.
Oder einfach eine Anfrage mit den genauen Anforderungen an netcup senden. Da wird sicherlich etwas möglich sein.
Aber VPS, Storage oder RS sind eben immer geteilte Ressourcen. 
Ich lasse hier einfach mal ein Schreib-Benchmark von RS 8000 G8SE SSD auf Storagespace (per NFS) fallen.
Ist der Storage Space ähnlich, langsamer oder schneller als der Festplattenzugriff des Storage Servers?
Ich hätte Zugriff auf einen S1000 G7 und wie du ja gesehen hast auf einen Storagespace.
Wenn du mir explizit sagen könntest, welchen Benchmark du haben möchtest (im Optimalfall mit Befehl), dann kann ich dir da gerne mal die Werte zukommen lassen.
Abgesehen davon glaube ich aber nicht, dass die IOPS dein Bottleneck werden. Ich sehe das eher beim Netzwerkinterface, durch welchen dein Traffic bei beiden Varianten fließt.
Ich bin mir recht sicher, dass du zumindest mit einem S1000 G7 mit Seafile wohl eher weniger glücklich werden wirst. Wir betreiben da eine Nextcloud drauf und naja... es ist erträglich, aber unsere Nextcloud Instanzen auf Root Servern (SAS) sind deutlich schneller.
Also wenn du zum Storageserver greifst, solltest du da mal mindestens eine Nummer größer skalieren.
Wenn du den Storageserver als rsync Destination von Remote aus nimmst, wirst du dich sicher per SSH verbinden und rsync tunnelt da durch - und auch hier sehe ich ein Bottleneck, denn die SSH Verbindung könnte da echt ein Performancekiller sein.
In der Hinsicht ist der Storagespace mit NFS die bessere Wahl.
Was widerum nicht ganz so performant sein könnte, ist, wenn du das Datenbackend des Seafile auf einen Storagespace legst. Aber das habe ich so noch nie probiert, da kann ich nichts dazu sagen. Kann gut gehen, muss aber nicht.
Also ich habe gerade mal auf einem S 1000 G7 ein fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randwrite
gemacht - bei nichtmal 20% war der Load1 schon wieder bei über 40 und die Kiste ist eingefroren...
Wir ziehen die Kiste zeitnah auf einen RS 8000 G8SE SAS um - das Ding ist einfach unerträglich. Vielleicht für irgendwas Backup oder Archiv mäßiges ala Deep Glacier, aber für Seafile (wir nutzen das Ding mit Nextcloud) - no way, probier es garnicht erst.
Vielleicht geht es mit den größeren dieser Kisten besser, aber die sind da eindeutig nicht dafür ausgelegt.
Wenn man viel Storage zu einem guten Preis will, ist man meines Erachtens immer noch mit einem RS mit SAS am besten beraten.
Neu erstellte Beiträge unterliegen der Moderation und werden erst sichtbar, wenn sie durch einen Moderator geprüft und freigeschaltet wurden.
Die letzte Antwort auf dieses Thema liegt mehr als 365 Tage zurück. Das Thema ist womöglich bereits veraltet. Bitte erstellen Sie ggf. ein neues Thema.
