[Howto] Opensolaris 2009.06 & QNAP TS 110 - rsync

  • Hallo allerseits,


    nach längerer Suche (auch hier), sowie nach dem Durchlesen einiger recht belustigender Posts - wo z.B. der HW die Schuld (ich verwende auch besagt WD-Platte :thumb: ) an den zu geringen Datentransferraten beim rsync'en gegeben wurde (usw) - möchte ich nur kurz meine erste Erfahrung mit der TS 110 und Opensolaris 2009.06 hier posten.


    Am Anfang probierte ich es wie man sich's so denkt :roll: :


    1) SSH-Schlüssel (dsa o. rsa - hier dsa) als

    Code
    $su

    mit

    Code
    #ssh-keygen -t dsa

    am Solarisrechner erzeugen (liegt dann default unter

    Code
    /root/.ssh/id_dsa.pub

    )
    2) Den public in einer neuen Datei auf der QNAP unter

    Code
    /root/.ssh/authorized_keys

    abspeichern (pro Schlüssel eine neue Zeile) - somit kein Einloggen mehr notwendig ... (sollte man aber vorher einmal, dann kennt er den Key)
    3) In der QNAP irgendwo ein Verzeichnis anlegen, der Ordnung halber dort wo man dick Platz hat z.B. unter:

    Code
    /shares/HBA_DATA/xyz

    legt man dann das Zielverzeichnis (hier xyz) an. Schnell noch

    Code
    chmod 777 /shares/HDA_DATA/xyz

    und fertig (Bezgl. Sicherheit mach ich mir beim Testen anfangs mal keine Gedanken ...)
    4) ... so, nun denkt man sich, nett - nur mehr schnell am Solaris (Quelle) rsync aufrufen und fertig - also z.B.:

    Code
    rsync -auvz --delete /quellverzeichnis/ admin@[IP von QNAP]:/share/HDA_DATA/xyz/


    Tja, und ab da funktionierte auch alles, nur war es gähnend langsam. Mehr als 2,2 MByte/s waren einfach nicht drin. Egal wie man an den Parametern vom rsync schraubte, es war nichts zu machen. Nach kurzem Lesen - aha, QNAP verwendet rsync 3.x und OpenSolaris 2009.06 irgendeine 2.6.x Version - lt. "Expertenmeinungen" im Internet nicht ratsam. Gut, rsync 3.0.7 Sourcen direkt von http://rsync.samba.org/ftp/rsync/ besorgt, auf dem Solarishobel compiliert (aber nicht installiert), das entstandene rsync-binary nach /user/bin/rsync3 kopiert und gedacht es wird besser werden. Nix da, wieder nur 2,3 MByte/s. Ok, andere "Webvorschläge" betrachtet (SSH-Encryption runterdrehen, etc.) - nichts brachte etwas. Das Problem liegt auf der Hand: SSH produziert rund 75% load und rsync 25%. D.h. egal wie und was man rumdreht, zum (ver- und ) Entschlüsseln wird auf der QNAP einfach zuviel Prozessorleistung weggefressen (ist ja eigentlich nur ein Handy :D ). Welche Möglichkeit bestand noch - ja, nur die mit dem rsync-Daemon den die QNAP bereits mit sich führt.


    5) ... dann in der QNAP einfach mit

    Code
    vi /etc/rsyncd.conf

    am Ende sein Verzeichnis reinsetzen, also eine zusätzliche Freigabe erstellen (wie auch zuvor, Sicherheit mal hinten ran - wir testen) und den rsync-Daemon restarten.

    Code
    /etc/init.d/rsyncd.sh restart


    6) ... vermutlich schlecht war es trotzdem nicht die 3er Version des rsync-Clients am Solaris zu compilieren, denn nur mehr:

    Code
    rsync3 -vua --delete --progress --partial /quellverzeichnis/ rsync://admin@[IP von QNAP]/xyz/

    und siehe da, ~20MByte/s durchgehen, wie im Prospekt beschrieben :thumb: .


    Den Teil mit dem SSH-Schlüsselpaar hätte man sich natürlich dann sparen können, ebenso wie dem Nachgehen aller "Expertenmeinungen" :shock: im Internet.


    Falls wer anderer, noch bessere Lösungen parat hat (oder das Absichern dieser Variante besprechen will), dann rein da ...


    MfG

  • Nur um das klar zu stellen:


    Wenn du deinem Netz vertraust, ok, dann ist das eine Lösung.


    Ich traue grundsäztlich keinem Netzwerk, nicht mal meinem eigenen. Siehe div. Bugs der Fritz.Box und andere Router z.B. von Netgear die so weit offen waren und trozt info an den Hersteller z.T. bis heute nicht gefixt wurden, oder die Betreiber wissen nicht das ein Firmware-Patch dringen angebracht wäre.


    Daher: Wenn du dem Netz wie ich nicht traust, und du hast kein vlan für die Verbindung der beiden syncenden Stellen geschaffen: Diese Lösung Nix Gut! :tongue:


    Ansonsten, danke für das Tutorial, es schließt zumindest die Hardware Diskusion endgültig.