Drosselung des Festplattendurchsatzes bei Root-Servern bis zur Unbrauchbarkeit

  • Hallo zusammen,


    mir ist bei einem unserer Root-Server (S 8000 G7) aufgefallen, dass während des Backups die IOPs stark eingebrochen sind. Eine genaue Analyse hat gezeigt, dass die IOPs offenbar gedrosselt werden. Ich habe Verständnis dafür, dass die Server vor Überlast geschützt werden müssen. Keinerlei Verständnis habe ich jedoch dafür, auf welche Art und Weise dies geschieht und wie es kommuniziert wird.


    Der Support hat, von mir darauf angesprochen, zunächst abgestritten, dass überhaupt gedrosselt wird. Von der Technik kam dann die Aussage, dass es keine festen Limits gibt und es sein kann, dass bei längerer Auslastung ggf. limitiert wird.


    Dies habe ich zum Anlass genommen, ein paar Messungen durchzuführen.


    Messung auf S 8000 G7, wenige Tage alt.


    Beim linearen lesen mit 1 MB Blöcken (also keine Random-IO-Operationen) mit "dd if=/dev/sda of=/dev/null bs=1M" wird mit 200 MB/s gelesen. Dies erzeugt auf dem System 1600 IOPs. Das bedeutet eine I/O-Blockgröße von 128kb. Die IOPs scheinen auf allen S 8000 G7 auf 1600 limitiert zu sein.

    Nach ca. 10 Minuten werden die IOPs auf 200 gedrosselt. Durch die Blockgröße von 128k bedeutet das eine Transferrate von 25MB/s.

    Gedrosselt wird nicht nur, wenn die 1600 IOPs ausgelastet werden sondern sobald längere Zeit mit mehr als 200 IOPs bzw. mehr als 25MB/s gelesen werden. Das bedeutet, dass eine maximale Dauertransferrate von 25MB/s auf den Systemen nicht überschritten werden kann.


    Damit dauert es über 116 Stunden, ein Vollbackup eines S 8000 G7 durchzuführen.


    Für einen neu bestellten RS 4000 SAS G8SE a1 beträgt das initiale Limit 2000 IOPs / 250 MB/s, gedrosselt wird nach 10 Minuten I/O-Last auf 250 IOPs und 30 MB/s.


    Auf mehreren älteren S 8000 G7 unterliegt die I/O Rate erheblichen Schwankungen zwischen 40 und 1600 IOPs, war jedoch im Mittel dauerhaft geringer als die 200 IOPs, so das ich nicht verifizieren konnte, ob auf den alten Systemen auch schon gedrosselt wird. Ich vermute, das die entsprechenden Hostsysteme recht stark ausgelastet sind.


    Die reinen IOPs sind nicht das Problem (200 IOPs sind für SAS-Systeme sehr gut), jedoch ist die Transferrate, welche durch die 128k Blockgröße erzielt wird ein absolutes No-Go. Zum Vergleich: eine 2,5" Notebook-Platte (ST1000LM024) ließt sequentiell um die 115 MB/s bei 160 IOPs.



    Ich bin der Meinung, dass eine solche Drosselung eine erhebliche Beeinträchtigung des Produktes darstellt und mindestens als Bestandteil der Produktbeschreibung offen kommuniziert werden muss. So kann jeder selbst entscheiden, ob ein Storage-Server, der dauerhaft nur 25 MB/s lesen kann für seinen Anwendungszweck tauglich ist.


    Ich würde mich über ein klares Statement seitens Netcup bezüglich IOPs, Transferraten und Drosselung freuen.


    Viele Grüße,

    Michael.


    PS: auf einem einzelnen S 8000 G7 habe ich in der Spitze eine sequenzielle Transferrate von 340 MB/s bei ca. 680 IOPs gemessen, was eine I/O-Blockgröße von 512k hinweist. Das zeigt, dass eine sinnvolle Balance zwischen IOPs und Transferrate technisch zumindest möglich ist.


    PPS: Die Messungen auf den beiden neuen Systemen erfolgten aus dem Rescue-System heraus indem mit "dd if=/dev/sda of=/dev/null bs=1M" sequenzielle reads erzeugt und mit "iostat -x 1" die I/O-Statistiken ausgegeben wurden.

  • Guten Morgen,



    zunächst möchte ich klarstellen, dass Storage-Server bei in den SLA wie VPS, nicht wie Root-Server behandelt werden.


    Es gibt hier keine garantierte IO-Leistung. Wir haben ein System das IO-Last fair zwischen den Nutzern einer Cloud aufteilt. 200 IOPS ist bei der gebotenen Preis-Leistung unserer Meinung nach ein guter Wert, wenn Sie 8 TB am Stück schreiben möchten. Wenn Sie kleinere Dateien schreiben, können Sie dank großem Cache deutlich mehr IOPS erreichen.


    Für wirklich sehr gute Schreibraten, empfehlen wir unsere Root-Server mit SSD-Festplatten.



    Mit freundlichen Grüßen


    Felix Preuß

  • Hallo Herr Preuß,


    vielen Dank für das Feedback. Meine Kritik gilt jedoch nicht den 200 IOPs (die isoliert betrachtet sehr gut sind), sondern:


    * der Tatsache, dass aufgrund der I/O Blockgröße von 128k damit maximal 25MB/s Leserate möglich sind (ein Parameter, welcher sich unter KVM auch anpassen lässt)

    * der Tatsache, dass diese Drosselung nicht nur nicht kommuniziert sondern vom Support teils geleugnet wird

    * das keine konkreten Zahlen vorliegen, bei welcher Nutzung wie gedrosselt wird.


    Meine Messungen legen nahe, dass anhand von IOPs bei überschreiten von 200 IOPs gedrosselt wird. Damit sind ab Drosselung auch bei vielen kleinen Dateien und einem hostseitigen Cache nicht mehr IOPs möglich.


    Zitat


    zunächst möchte ich klarstellen, dass Storage-Server bei in den SLA wie VPS, nicht wie Root-Server behandelt werden


    Bei dem von mir geprüften Root-Server liegt die Rate auf die gedrosselt wird bei 250 IOPs und 30 MB/s.


    Zitat

    Für wirklich sehr gute Schreibraten, empfehlen wir unsere Root-Server mit SSD-Festplatten


    Diese setzen wir dafür auch ein, die hohen Lese-/Schreibraten der SSD-Systeme kann ich bestätigen. Ich erwarte auch keine "wirklich gute Schreibraten" für SAS-Systeme. Aber 25 MB/s fällt nicht einmal unter "brauchbare Leseraten".


    Zitat

    200 IOPS ist bei der gebotenen Preis-Leistung unserer Meinung nach ein guter Wert, wenn Sie 8 TB am Stück schreiben möchten

    Ich lese die 8 TB nur (externes Backup des Servers). 200 random-IOPs wären ein sehr guter Wert für festplattenbasierte Systeme. 200 IOPs bei linearen Lesen sind, wenn als "Abrechnungseinheit" 128k Blöcke gelten geradezu lächerlich (25 MB/s). Bei meinem Desktopsystem mit 2,5" Datenplatte kann ich mit "dd if=/dev/sdb of=/dev/null bs=128k" etwa 115 MB/s bei 900 IOPs lesen. Mit einer Blockgröße von 1 MB reichen für diesen Durchsatz 160 IOPs, was den tatsächlichen physikalischen Eigenschaften der HDD entspricht.


    Wir planen unsere IT-Infrastruktur sehr sorgfältig und haben die Produkteigenschaften sowie auch eigene I/O-Benchmarks von älteren und neuen Systemen in die Planung mit einbezogen (allerdings offenbar ohne dabei die Drosselung zu triggern). Eine verborgene Drossel welche erst bei produktiver Load zum Vorschein kommt, ist eine Art von Überraschung, auf die ich gern verzichten kann.


    Mit freundlichen Grüßen,

    Michael Wyraz.

  • Bei allem Verständnis für die Betonung des guten Preis-Leistungsverhältnisses, stimme ich zu, dass die Offenlegung von für Kunden bedeutsamen Produkteigenschaften essentiell für eine friktionsfreie Geschäftsbeziehung respektive eine gute Kundenbindung ist.


    Ich verstehe auch nicht, wie die Argumentation, die Gemeinkosten gering halten zu wollen, mit fehlender Aufklärung und daraus resultierenden Kulanzen, Sonderlösungen etc zusammenpassen soll. Ok, 20 Seiten Vertragstext und Spezifikationen will sicher niemand lesen, aber nicht völlig eindeutige Formulierungen wie die exemplarisch (produkt=2104) folgende halte ich ebenso für verzichtbar - zumal das bei netcup mittlerweile Standard ist, oder?:


    pasted-from-clipboard.png


    Aber Details, wie sie geomap nennt, wären sehr wohl schon vor der Bestellung interessant.

  • Mit den Rootservern bin ich schon vor Jahren aus genau dem Grund der für mich unbrauchbaren Festplattenperformance von SAS auf ausschließlich SSD Systeme umgestiegen. Lieber habe ich mir bei Platzmangel nen weiteren RS dazu geholt.

  • Ich kann das nicht nachvollziehen (RS 2000 Plus SAS G8). dd läuft seit über 15 Minuten:


    Code
    root@krapfen:/home/jeff# date && ps aux | grep "sudo dd"
    Fr 24. Mai 05:47:25 CEST 2019
    root     25094  0.0  0.0  49556  3768 pts/0    S+   05:31   0:00 sudo dd if=/dev/sda of=/dev/null bs=1M


    Im Schnitt hab ich immer noch 250 MB/s:



    EDIT: Auch nach 25 Minuten immer noch konstant 250 MB/s:



    Code
    338117525504 Bytes (338 GB, 315 GiB) kopiert, 1523,37 s, 222 MB/s

    Meine Minecraft-Plugins auf SpigotMC (Open Source): www.spigotmc.org/members/mfnalex.175238/#resources

    Discord: discord.jeff-media.com

  • Bei allem Verständnis für die Betonung des guten Preis-Leistungsverhältnisses, stimme ich zu, dass die Offenlegung von für Kunden bedeutsamen Produkteigenschaften essentiell für eine friktionsfreie Geschäftsbeziehung respektive eine gute Kundenbindung ist.

    […]

    Aber Details, wie sie geomap nennt, wären sehr wohl schon vor der Bestellung interessant.

    Ich würde in diesem Zusammenhang vorschlagen, diese Details sowohl auf https://www.netcup.de/vserver/vstorage.php auszuführen (man beachte das "v" in "vstorage.php", welches sich jedoch nicht in der Beschriftung des "Storage"-Reiters wiederfindet) als auch unter https://www.netcup.de/vserver/vergleich-root-server-vps.php explizit zu erwähnen, um Kunden eine bessere Einordnung der Storage-Angebote zu erlauben, welche sich nach obiger Erläuterung in Min­dest­ver­füg­bar­keit/Durch­satz­ga­ran­tie von VPS/Root-Servern unterscheiden ("Zwischending"). Bei dieser Gelegenheit könnte auch ein Hinweis auf eine mögliche Kombination mit einem "Service Level A+" (bis dato nur für Root-Server verfügbar) in die Tabelle mitaufgenommen werden.

    Eine konkrete Angabe der Kennzahlen – vergleicht man die Ergebnisse der obigen Durchsatztests von geomap und mfnalex, so ergibt sich hier ein Faktor 10 – ist IMHO wichtig, um die Nutzungsmöglichkeit von Storage-Angeboten für "Disaster Recovery" o.ä. in Verbindung mit größeren Datenmengen abschätzen/mit Al­ter­na­tiv­an­ge­bo­ten vergleichen zu können; analoge Angaben zum Netzwerkdurchsatz gibt es ja bereits auf den Produktseiten (auch diese Kenngröße würde ich gerne nochmals in der Vergleichstabelle sehen).

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Ich kann das nicht nachvollziehen (RS 2000 Plus SAS G8). dd läuft seit über 15 Minuten:

    Die Messungen habe ich auf 2 neu bestellten Servern durchgeführt. Es kann durchaus sein, dass ältere Systeme ungedrosselt sind.


    Solange Netcup keine offiziellen Aussagen macht, welche Systeme unter welchen Bedingungen wie gedrosselt werden, lässt sich da leider nur spekulieren.

  • Auf meinem VPS Eierpower 2 sind die Werte durchgehend miserabel (unter 35 MB/s).


    Da werd ich mich wohl an den support wenden müssen, sowas kannte ich von netcup noch nicht :/

    Meine Minecraft-Plugins auf SpigotMC (Open Source): www.spigotmc.org/members/mfnalex.175238/#resources

    Discord: discord.jeff-media.com

  • Das ist das Problem bei uns Menschen.

    Geiz ist Geil, würden die Preise der Server nicht so niedrig sein, dann würde die Leistung stimmen.

    Bzw. bei anderen Anbietern verzichtet man dann halt auf den Support oder schlechte Bezahlung der Mitarbeiter.

    Aber etwas mehr Transparenz hinsichtlich dessen von Netcup würde ich mir doch schon Wünschen.

  • Geiz ist Geil, würden die Preise der Server nicht so niedrig sein, dann würde die Leistung stimmen.

    Bei mir ist es zwar ein Angebotsserver, aber der kostet 16€ im Monat. Es dauert dort 1,25 Stunden um ein Borg Repository per rsync abzugleichen, bei dem sich nichts geändert hat. Ich werde bald versuchen das mal auf einer anderen Maschine zu testen, wie lange es dort dauert. Kann halt sein der VPS eignet sich nicht für das Offsite Backup von so viel Daten, dann muss ich den aber auch kündigen.

  • Geiz ist Geil, würden die Preise der Server nicht so niedrig sein, dann würde die Leistung stimmen.

    Bzw. bei anderen Anbietern verzichtet man dann halt auf den Support oder schlechte Bezahlung der Mitarbeiter.

    Diese pauschale Rundum-Kritik an Netcup finde ich unangebracht (bzgl. der Aussage im zweiten Satz ist das noch vorsichtig ausgedrückt) und im Sinne einer konstruktiven Offenlegung von bislang nicht kommunizierten/bekannten (geänderten?) Leistungseckdaten nicht unbedingt hilfreich. Je nach individuellem Anwendungsfall stimmte die Leistung für viele langjährige Kunden bislang offensichtlich.

    Wenn die obengenannten Leistungseckdaten bekannt sind bzgl. des Durchsatzes, könnte man dies zum Anlass nehmen, ein paar Anwendungsszenarien zu diskutieren, welche sich für angebotene Root-/Storage-/vServer empfehlen bzw. bereits angesprochene Themen in diesem Forum unter diesen Gesichtspunkt zu sammeln/verlinken.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Bei mir ist es zwar ein Angebotsserver, aber der kostet 16€ im Monat. Es dauert dort 1,25 Stunden um ein Borg Repository per rsync abzugleichen, bei dem sich nichts geändert hat.

    Ich habe einen "VPS 2000 G8 Plus" (Optane, 8 vCores, 16GB RAM) und spiegle meine Borg Repos (210 GB) täglich mit rclone (einmal direkt nach pCloud und einmal über SSH auf eine SSD am RaspPi zu Hause).

    Das dauert jeweils 1-3 Minuten.


    Ich hatte vorher einen VPS 16 Years und war mit dem auch nicht zufrieden (1 vCore war regelmässig der Bottleneck, und unerklärliche iowaits von bis zu 90 Sekunden).

    CentOS 7 / nginx / php-fpm / postfix / rspamd / clamav / dovecot / nextcloud running on RS 1000 SSDx4 G8 / VPS 500 G8 / VPS 2000 G8 Plus

  • Ich habe einen "VPS 2000 G8 Plus" (Optane, 8 vCores, 16GB RAM) und spiegle meine Borg Repos (210 GB) täglich mit rclone (einmal direkt nach pCloud und einmal über SSH auf eine SSD am RaspPi zu Hause).

    Das dauert jeweils 1-3 Minuten.


    Ich hatte vorher einen VPS 16 Years und war mit dem auch nicht zufrieden (1 vCore war regelmässig der Bottleneck, und unerklärliche iowaits von bis zu 90 Sekunden).

    Bei mir heißt der VPS Ibizza, der ist glaube ich zu dem 16 Years äquivalent. Ich gucke mal ob ich noch so einen 2000 G8 Plus frei habe, dann probiere ich es mit dem, ansonsten muss ich das woanders speichern.


    Ich würde nämlich auch annehmen, dass es in ein paar Minuten erledigt sein müsste. Länger dauert ein reguläres Borg Backup auch nicht.