Hello,
* Est-ce que le LACP est bien limité à un seul canal par session ? -> Oui mais tu peux garder ton "Port Channel" côté switch (pour éviter que la MAC change surtout et que ça flood), et mettre du RR côté client (du coup quand ça envoie les données ça utilise bien tous les liens). Fonctionne sans soucis on fait ça partout chez nous et on l'a même fait y'a 8ans sur du 8x1Gbps pour des raisons économiques à l'époque. Le seul inconvénient que je vois c'est qu'en cas de soucis sur un lien ça peut vite faire n'importe quoi, mais bon, sur un truc pas critique extrème ça passe facile. * Sauf que les 10 To que l'on a restauré ont pris 68h (de la première à la dernière écriture donc sans le délai nécessaire pour générer la liste des fichiers). Avec 117 Mo/s on arrivera logiquement à restaurer 28To en 68h. A l'inverse 10 To en 68h nous donne 40 Mo/s. -> On connait pas tes HDD (combien, type..) ni le type de fichiers, peut être eux qui limitent. En séquentiel, même des vieux HDD feront plus de 100Mo/s (R/W), des HDD récents approcheront les 300Mo/s (285Mo/s sur les 22To). Mais en random, ça devient vite plus compliqué hein. * Le MTU par défaut de 1500 n'est pas top. Est-ce la raison et surtout comment calculer la différence avec du jumbo frames ? -> tu peux mais par expérience tu ne gagneras rien. Je pense pour le point numéro 2, perf des HDD et type de transfert. Comme dit rsync c'est vite cancer surtout que les NAS (grand publics) ont des cpu peu puissants généralement (dans une logique de basse consommation et de prix). On Mon, 10 Jul 2023 at 11:09, Paul Rolland (ポール・ロラン) <rol+fr...@witbe.net> wrote: > Bonjour, > > On Mon, 10 Jul 2023 09:01:07 +0200 > l...@51514.fr wrote: > > > Si rsync, sa vitesse global va dépendre de la taille et du nombre de > > fichier. Un rsync avec quelques gros fichier ne va pas perdre beaucoup > > de temps en test, ouverture et lecture de fichier et la compression va > > être plus performante. A contrario, un rsync sur beaucoup de petit > > fichier va demander des test, ouverture de fichier en pagaille, c'est du > > Et selon les options donnees a rsync, le calcul du checksum pour faire un > controle en plus des attributs du fichier afin de savoir si il a ete > modifie. > Checksum sur 10To -> surement chaud cote CPU... > > De maniere generale, les NAS "recents" ont quasiment tous le necessaire > pour suivre a la fois le CPU, le reseau, la memoire, au moins en local > (mais avec un historique limite), et tu as peut-etre aussi un monitoring > SNMP externe. > Ca dit quoi sur tes deux NAS pendant la restauration ? > > Paul > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- *Cordialement / Best regards,Gwenaël OBERLINGER* -- Uptobox.com CTO / Vulnerator Phone: (+33) 6 29 65 35 52 https://twitter.com/starouille --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
