RRTR Performanceeinbruch bei Verschlüsselung -> Ist ein Faktor von 8.5 "normal" ?

  • Hallo,


    ich habe bei mir im lokalen Netz inzwischen zu Backupzwecken eine etwas betagte TS-459PRO+ in Bertrieb genommen. Das gute Stück läuft eigentlich sehr rund, allerdings wundere ich mich jetzt gerade über die immensen Performenceunterschiede bei einem RRTR Job mit aktivierter / nicht aktivierter Verschlüsselung. Und zwar bringt unverschlüsselt praktisch die volle GBe Leistung ( 111MB/s ) während "Sicherer Anschluss (SSL)" nur 13.5 MB/s liefert... Ich hatte übers Wochenende 2 RRTR Jobs parallel laufen, da gab es in zusammen ca 25MB/s... Die CPU war auch nicht voll ausgelastet. Im lokalen Netz kann ich mir die Verschlüsselung natürlich sparen, andererseits bin ich schon verblüfft, dass dies einen solchen Unterschied ausmacht. Zudem offenbar nicht die CPU der limitierende Faktor zu sein scheint. Klar ist der Atom in der 459 nicht der schnellste, aber er lief während der Backups auch nicht unter Vollast sondern eher so bei 30-40%. Transferratenbeschränkung ist natürlich abgeschaltet. Auch die 451, die das Backup durchführt scheint mir nicht am Anschlag zu laufen. Mich würde mal interessieren, ob sonst noch jemand solche Unterschiede ausmachen kann, wenn er mal den internen Test beim einrichten einer externen Verbindung durchführt für beide Fälle.

    Einmal editiert, zuletzt von nasferatu ()

  • nasferatu

    Hat den Titel des Themas von „RRTR Performanceeinbruch bei Verschlüsselung -> Welche Größenordnung ist "normal"“ zu „RRTR Performanceeinbruch bei Verschlüsselung -> Ist ein Faktor von 8.5 "normal" ?“ geändert.
  • Hi,


    ja, diese Unterschiede habe ich auch festgestellt, ohne Verschlüsselung läuft es richtig rund, mit dauern die Jobs ewig und drei Tage.

    Trotzdem habe ich bei allen RTRR Jobs die Verschlüsselung eingeschaltet. Das Protokoll RTRR oder FTP ist übrigens egal, die Performance läßt bei beiden drastisch nach wenn Verschlüsselung aktiviert ist.

    Am Schlimmsten ist es bei einem iSCSI LUN Backup: eine 2TB LUN ohne Verschlüsselung braucht ca. 24 -40h, mit Verschlüsselung wurden 5 oder 6 Tage berechnet, das habe ich abgebrochen und die Verschlüsselung deaktiviert.


    Gruss

  • ja, diese Unterschiede habe ich auch festgestellt, ohne Verschlüsselung läuft es richtig rund, mit dauern die Jobs ewig und drei Tage.

    Hmm, Deine Geräte sind ja leistungsmäßig auf einem ähnlichen Niveau wie bei mir... aber irgendwo muss doch da was extrem ineffizient programmiert sein oder eine interne CPU Drosselung greifen, um das NAS vielleicht nicht zu überlasten. Denn die CPU Lasten während des Backups fand ich jetzt mit Verschlüsselung auch nicht so ungewöhnlich.


    Das FTP ähnlich schlecht läuft ist natürlich auch ernüchternd...wahrscheinlich wird da mehr oder weniger dieselbe Cryptoengine genutzt.

    Einmal editiert, zuletzt von nasferatu ()

  • Ein Beispiel in Zahlen:


    Quell NAS: ein Celvin Q902 (TS 669 müsste das sein):

    Ziel NAS: TS 459


    Testverzeichnis mit ca. 11 GB Daten

    ohne Verschlüsselung per RTRR Dauer ca. 2'37" bis der Job durch war, der Test beim Job Einrichten zeigte einen möglichen Durchsatz von ca. 84Mb/s.

    mit Verschlüsselung per RTRR Dauer ca. 20' 24" bis der Job durch ist (Faktor 10!!!), der Test beim Einrichten zeigte ca. 8,5Mb/s.


    Ja, das ist unterirdisch programmiert!

    Die CPU Auslastung unterschied sich nicht allzu deutlich bei den beiden Jobs, was das also bremst... keine Ahnung :huh:.


    Gruss


    Nachtrag:

    Ich hatte mich dazu auch schon mal hier ausgelassen.

    Jetzt habe ich spasseshalber mal bei allen Jobs die Verschlüsselung deaktiviert, schon fliegen so zwischen 80 und 95MB/s über die Leitung.

    Ich lasse das jetzt so, sonst hatte ich max. 35-40MB/s wenn mehrere Jobs liefen, bei einem Job selten über 20 MB/s.


    Und noch eine Korrektur: bei der iSCSI LUN war es keine Verschlüsselung, sondern Kompression die das Backup ausbremste.

    2 Mal editiert, zuletzt von FSC830 ()

  • Also was immer es ist: jedenfalls sieht man den Unterschied bereits bei ausführen über den Test Button. Es kann also nur die Verschlüsselung sein. Wobei es scheinbar nicht die riesigen Auswirkungen auf die CPU Last hat, die man vielleicht erwarten würde...

  • Hmmm, ist dieses Mißverhältnis niemand außer FSC830 bisher aufgefallen ? Oder nutzt RRTR einfach in der Praxis keiner mit Verschlüsselung? Oder sind die größeren Kisten da wesentlich besser ? Würde mich jetzt ja doch mal interessieren...

  • Doch, ist mir schon aufgefallen und ich nutze nur RTRR (mit dem altem SM) ohne Verschlüsselung. Faktor 10, wie ihn FSC830 beschreibt, kommt mir bei aktiver Verschlüsselung bekannt vor.

    Bei der Prozessorlast ist kaum ein Unterschied bemerkbar und die "größeren" sind dabei auch nicht recht viel schneller. Habe daher die Verschlüsselung beim RTRR-Job wieder überall deaktiviert.


    Wenn die Daten wirklich "gefährdet" sind, würde ich sie, bereits vorab auf dem PC verschlüsselt, auf der NAS ablegen und dann wäre es auch egal, sie "unverschlüsselt" zu übertragen.

  • Wenn die Daten wirklich "gefährdet" sind, würde ich sie, bereits vorab auf dem PC verschlüsselt, auf der NAS ablegen und dann wäre es auch egal, sie "unverschlüsselt" zu übertragen.

    Gut, das ist natürlich ein Workaround. Aber letztlich ist das doch wirklich peinlich...zumal es ja noch nicht einmal ein Lastproblem zu sein scheint.

  • Gut, das ist natürlich ein Workaround. Aber letztlich ist das doch wirklich peinlich...zumal es ja noch nicht einmal ein Lastproblem zu sein scheint.

    Da geht es mir nicht um einen Workaround für die Performance, sondern um den Datenschutz an und für sich.


    Wenn ich Daten habe, die nur für mich bestimmt sind, will ich sie auch auf dem NAS verschlüsselt abgelegt haben. Eine verschlüsselte Übertragung alleine schützt noch immer nicht gegen einen "Datendiebstahl" auf der NAS.

    Verschlüssele ich generell die NAS, habe ich wieder die Unsicherheit bei einem Ausfall der NAS, komme ich dann wieder auf meine Daten, oder nicht?


    Verschlüssele ich bereits auf dem PC die Daten, ist sowohl die Originaldatei gesichert, das Backup auf der NAS und eventuelle Sicherungen auf dem 2. und 3. NAS ;)

  • Da geht es mir nicht um einen Workaround für die Performance, sondern um den Datenschutz an und für sich.

    Naja, das würde ich nur bedingt so sehen. Ich muss ja nicht alles verschlüsseln, aber ich hätte doch gerne im internen Netz verschlüsselte Punkt-zu-Punkt Verbindungen, damit nicht irgendjemand einfach durch mitlauschen Daten abgreifen kann. Oder diese gar verändert. Ist jetzt mehr theoretisch aber halte ich für grundsätzlich sinnvoll. Deswegen würde ich Transportverschlüsselung und lokale Verschlüsselung als 2 separate Anwendungsfälle betrachten.

  • Gebe dir ja Recht, die Schutzziele (CIA) können natürlich nur mit verschlüsselter Übertragung gewährleistet werden.

    Wenn ich aber bereits im INTRA-Net Angst vor Datenveränderung haben muss, habe ich schon ein viel größeres Problem. 8|


    Aber selbst wenn "jemand" mitlauscht und Daten verändern will (MITM-Angriff, daheim ???), dann würden meine verschlüsselten Daten korrupt sein und könnten nicht mehr entschlüsselt werden, mehr kann nicht passieren. Es kann weder der Inhalt verändert, noch gelesen werden.


    Und was findet der Angreifer bei der unverschlüsselten Übertragung verschlüsselter Daten raus?

    PC sichert auf NAS-A und NAS-A hat einen Backup-Job auf NAS-B, no na net, in einem Home-Intranet sind die Datenströme überschaubar und können auch ohne Sniffer leicht erraten werden, so groß wird die Infrastruktur nicht sein. :/


    Aber bevor wir hier Off-Topic gehen ;) belassen wir es bei den Vorlieben jedes Nutzers.


    Muss jeder für sich entscheiden, ober er den eher bequemen Weg gehen will und die ganze Absicherung einer einzelnen NAS überlässt, oder ob er selber eine Bedrohungsanalyse macht und geeignete Absicherungen überlegt.

    Eine klassische Fehlkonfiguration sehe ich hier immer wieder an den Anfragen im Forum, das NAS steht offen wie ein Scheunentor im INTERNET mit FTP, Cloud und Streaming, aber das Backup im Intranet soll bitte verschlüsselt übertragen werden (warum? weil das Böse schon längst auf dem NAS ist?) ...

  • Und was findet der Angreifer bei der unverschlüsselten Übertragung verschlüsselter Daten raus?

    Naja, als Abschluss, weil es dann wirklich OT wird, würde ich sagen, die Login Daten des RTRR Servers. Und da gibt es ja nur einen, der gleich das ganze Dateisystem sieht...was ich auch bei RSync nicht so dolle finde. Machen zwar alle so, aber ich finde eigentlich, auch dort sollte eine Nutzerverwaltung mit entsprechenden Rechten greifen...aber nu is schluss. Zumindest mit der Grundsatzdiskussion. Auf jeden Fall sollte die Transportverschlüsselung bei allen RRTR Varianten nicht solche Auswirkungen haben, das ist schon armselig.

    Einmal editiert, zuletzt von nasferatu ()