J'ai des problèmes avec NFS, et j'aimerais essayer d'utiliser tout simplement l'ancien TCP.

Je ne sais pas par où commencer, cependant.

Côté matériel, j'utilise un câble croisé Ethernet pour mettre en réseau deux netbooks.

Pour les mettre en réseau, je tape

$ sudo ifconfig eth0 192.168.1.1 up && ping -c 10 -s 10 192.168.1.2 && sudo /etc/init.d/nfs-kernel-server start

sur le premier netbook et

$ sudo ifconfig eth0 192.168.1.2 up
$ ping -c 10 -s 10 192.168.1.1
$ mount /mnt/network1

le deuxième

où /mnt/network1est spécifié dans / etc / fstab comme

192.168.1.1:/home /mnt/network1 nfs noauto,user,exec,soft,nfsvers=2 0 0

ainsi que dans /etc/exports(en utilisant la syntaxe de ce fichier), sur le premier netbook.

Ce qui précède fonctionne bien, mais les fichiers et les répertoires sont énormes. Les fichiers font en moyenne environ un demi-gigaoctet par morceau, et les répertoires ont tous entre 15 et 50 gigaoctets.

J'utilise rsyncpour les transférer, et la commande (on 192.168.1.2) est

$ rsync -avxS /mnt/network1 ~/somedir

Je ne sais pas s'il existe un moyen de modifier mes paramètres NFS pour mieux gérer les fichiers énormes, mais j'aimerais voir si l'exécution d'un rsyncdémon sur un ancien TCP ordinaire fonctionne mieux que rsyncsur NFS.

Donc, pour réitérer, comment puis-je configurer un réseau similaire avec TCP?

MISE À JOUR:

Donc, après quelques bonnes heures à essayer de me sortir du bourbier de ma propre ignorance (ou, comme j'aime à y penser, de me relever par mes propres bottes), j'ai trouvé quelques faits utiles.

Mais tout d'abord, ce qui m'a conduit sur cette piste de lapin au lieu d'accepter simplement la meilleure réponse actuelle était ceci: ncest un programme incroyablement cool qui ne résout résolument pas pour moi. J'ai essayé les netcat-openbsdet netcat-traditionalpaquets sans que ce soit de la chance.

L'erreur que j'obtiens sur la machine réceptrice ( 192.168.1.2) est:

me@netbook:~$ nc -q 1 -l -p 32934 | tar xv
Can't grab 0.0.0.0:32934 with bind
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

route donne:

me@netbook:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         dir-615         0.0.0.0         UG    0      0        0 wlan0
link-local      *               255.255.0.0     U     1000   0        0 eth0
192.168.0.0     *               255.255.255.0   U     2      0        0 wlan0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

Mais, voici la bonne nouvelle: avoir les adresses IP statiques définies /etc/network/interfaces, ce que j'ai commencé à faire en essayant de nctravailler, corrigé tous mes problèmes NFS et ravivé mon amour pour NFS.

La configuration exacte que j'ai utilisée (avec 192.168.1.1pour le premier netbook, bien sûr) était:

auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0

Avec ces paramètres, les deux netbooks pourront se cingler directement après avoir été démarrés, sans même un ifup.

Quoi qu'il en soit, j'aimerais toujours vraiment voir ncen action, alors j'espère que quelqu'un m'aidera à déboguer ce processus.

La voie rapide

Le moyen le plus rapide de transférer des fichiers sur un réseau local n'est probablement pas rsync, sauf s'il y a peu de changements. rsync passe un peu de temps à faire des sommes de contrôle, à calculer les différences, etc. Si vous savez que vous allez transférer la plupart des données de toute façon, faites simplement quelque chose comme ça (remarque: il existe plusieurs implémentations de netcat; consultez le manuel pour les bonnes options. En particulier, les vôtres peuvent ne pas vouloir les -p):

user@dest:/target$ nc -q 1 -l -p 1234 | tar xv

user@source:/source$ tar cv . | nc -q 1 dest-ip 1234

Cela utilise netcat ( nc) pour envoyer tar sur une connexion TCP brute sur le port 1234. Il n'y a pas de cryptage, de vérification d'authenticité, etc., donc c'est très rapide. Si votre interconnexion fonctionne à gigabit ou moins, vous ancrerez le réseau; si c'est plus, vous piquerez le disque (sauf si vous avez une matrice de stockage ou un disque rapide). Les vdrapeaux à tar lui font imprimer les noms de fichiers au fur et à mesure (mode verbeux). Avec des fichiers volumineux, ce n'est pratiquement pas une surcharge. Si vous faisiez des tonnes de petits fichiers, vous désactiveriez cela. En outre, vous pouvez insérer quelque chose comme pvdans le pipeline pour obtenir un indicateur de progression:

user@dest:/target$ nc -q 1 -l -p 1234 | pv -pterb -s 100G | tar xv

Vous pouvez bien sûr aussi insérer d'autres choses, comme gzip -1(et ajouter l' zindicateur à l'extrémité de réception - l' zindicateur à l'extrémité d'envoi utiliserait un niveau de compression supérieur à 1, sauf si vous définissez la variable d'environnement GZIP, bien sûr). Bien que gzip soit probablement plus lent, à moins que vos données ne se compressent vraiment .

Si vous avez vraiment besoin de rsync

Si vous ne transférez vraiment qu'une petite partie des données modifiées, rsync peut être plus rapide. Vous voudrez peut-être aussi regarder l' option -W/ --whole-file, comme avec un réseau très rapide (comme une interconnexion) qui peut être plus rapide.

La façon la plus simple d'exécuter rsync est d'utiliser ssh. Vous voudrez expérimenter avec des chiffrements ssh pour voir lequel est le plus rapide, ce sera soit AES, ChaCha20 ou Blowfish (bien qu'il y ait des problèmes de sécurité avec la taille de bloc 64 bits de Blowfish), selon que votre puce a AES d'Intel -NI instructions (et votre OpenSSL les utilise). Sur un ssh suffisamment nouveau, rsync-over-ssh ressemble à ceci:

user@source:~$ rsync -e 'ssh -c aes128-gcm@openssh.com' -avP /source/ user@dest-ip:/target

Pour les anciens ssh / sshd, essayez aes128-ctrou aes128-cbcà la place de aes128-gcm@openssh.com.

ChaCha20 serait chacha20-poly1305@openssh.com(a également besoin d'un nouveau ssh / sshd) et Blowfish serait blowfish-cbc. OpenSSH ne permet pas de fonctionner sans chiffrement. Vous pouvez bien sûr utiliser les options rsync de votre choix à la place de -avP. Et bien sûr, vous pouvez aller dans l'autre sens et exécuter le rsync à partir de la machine de destination (tirer) au lieu de la machine source (pousser).

Rsync plus rapide

Si vous exécutez un démon rsync, vous pouvez vous débarrasser de la surcharge cryptographique. Tout d'abord, vous devez créer un fichier de configuration du démon ( /etc/rsyncd.conf), par exemple sur la machine source (lisez la page de manuel rsyncd.conf pour plus de détails):

[big-archive]
    path = /source
    read only = yes
    uid = someuser
    gid = somegroup

Ensuite, sur la machine de destination, vous exécuteriez:

user@dest:~$ rsync -avP source-ip::big-archive/ /target

Vous pouvez également faire cela dans l'autre sens (mais bien sûr, vous devrez définir la lecture seule sur non). Il existe des options d'authentification, etc., consultez la page de manuel pour plus de détails.

Comment? Ou TL; DR

La méthode la plus rapide que j'ai trouvée est une combinaison de tar, mbufferet ssh.

Par exemple:

tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"

Grâce à cela, j'ai obtenu des transferts de réseau local soutenus de plus de 950 Mb / s sur des liaisons 1Gb. Remplacez les chemins d'accès dans chaque commande tar pour convenir à ce que vous transférez.

Pourquoi? mbuffer!

Le plus gros goulot d'étranglement dans le transfert de fichiers volumineux sur un réseau est, de loin, les E / S disque. La réponse à cette question est mbufferou buffer. Ils sont largement similaires mais mbufferprésentent certains avantages. La taille de mémoire tampon par défaut est de 2 Mo pour mbufferet de 1 Mo pour buffer. Les tampons plus grands sont plus susceptibles de ne jamais être vides. Le choix d'une taille de bloc qui est le plus petit commun multiple de la taille de bloc native sur le système de fichiers cible et de destination donnera les meilleures performances.

La mise en mémoire tampon est la chose qui fait toute la différence! Utilisez-le si vous l'avez! Si vous ne l'avez pas, obtenez-le! Utiliser (m}?bufferplus n'importe quoi est mieux que tout seul. c'est presque littéralement une panacée pour les transferts de fichiers réseau lents.

Si vous transférez plusieurs fichiers, utilisez-les tarpour les regrouper en un seul flux de données. S'il s'agit d'un seul fichier, vous pouvez utiliser la catredirection d'E / S. La surcharge de tarvs catest statistiquement insignifiante, donc j'utilise toujours tar(ou zfs -sendlà où je peux) à moins que ce ne soit déjà une tarball . Aucun de ces éléments n'est garanti pour vous donner des métadonnées (et en particulier catne le fera pas). Si vous voulez des métadonnées, je vous laisse cela comme un exercice.

Enfin, l'utilisation sshd'un mécanisme de transport est à la fois sûre et très peu coûteuse. Encore une fois, les frais généraux de sshvs ncsont statistiquement insignifiants.

Vous n'avez même pas besoin d'utiliser TCP. AoE est une implémentation ATA sur Ethernet, étant la couche 2, il s'agit d'une approche à faible surcharge sans connaissance de la pile TCP / IP. Il vous fournira le transfert le plus rapide possible avec le moins de frais généraux. ***

https://en.wikipedia.org/wiki/ATA_over_Ethernet

*** si le réseau est le goulot d'étranglement, assurez-vous d'envoyer des données compressées.