Auteur Sujet: rsync entre 2 NAS (Lu 9492 fois)

PacOrly · « **le:** 25 août 2016 à 19:05:14 »

J’ai ajouté une couche LVM entre la couche RAID6 et la couche du système de fichier sur nas03 et nas04 pour pouvoir faire du SHR façon Synology et ainsi pouvoir, lors de changement de disque HS, installer des disques de plus grande capacité.

Il a donc fallu casser le système de fichier sur chaque machine.

nas04 étant la sauvegarde de nas03, après chaque modification sur une machine, j’ai fait un rsync pour récupérer les données.

Chaque rsync a duré 3 jours et demi.

Comme c’était les plus gros rsync que je n’ai jamais fait, je n’ai pas pu m’empêcher de faire une sauvegarde de la sortie standard dont voici les deux dernières lignes.

sent 12,160,912,947,455 bytes received 41,817 bytes 44,243,140.70 bytes/sec
total size is 12,157,944,559,384 speedup is 1.00

BadMax · « **Réponse #1 le:** 26 août 2016 à 09:44:17 »

Pas plus simple d'utiliser ZFS avec FreeBSD ?

Le send/receive sera en tout cas plus rapide grace à l'utilisation de mbuffer : 44Mo/s c'est la vitesse d'import sur mon backup à base de Sempron64 2600+.

PacOrly · « **Réponse #2 le:** 26 août 2016 à 17:46:22 »

Moi, c'est un Intel(R) Celeron(R) CPU E1400 @ 2.00GHz, 2 cores (acheté en 2008 ou 2009 de mémoire).
Le CPU doit être le point limitant car lors du rsync j'avais un CPU load averages entre 1,5 et 2.

Sinon pour ZFS, j'avais regardé, il y a quelques années, mais ce qui m'avait arrêté c'est qu'il faut de la RAM et ma carte mère est limitée à 2 Go, mais surtout comme la RAM est saturée par les caches, il faut de la RAM ECC sinon il y a de gros risques de corruption de données et ma carte mère ne supporte pas ce type de RAM.

BadMax · « **Réponse #3 le:** 26 août 2016 à 20:51:44 »

Citation de: PacOrly le 26 août 2016 à 17:46:22

Moi, c'est un Intel(R) Celeron(R) CPU E1400 @ 2.00GHz, 2 cores (acheté en 2008 ou 2009 de mémoire).
Le CPU doit être le point limitant car lors du rsync j'avais un CPU load averages entre 1,5 et 2.

Sinon pour ZFS, j'avais regardé, il y a quelques années, mais ce qui m'avait arrêté c'est qu'il faut de la RAM et ma carte mère est limitée à 2 Go, mais surtout comme la RAM est saturée par les caches, il faut de la RAM ECC sinon il y a de gros risques de corruption de données et ma carte mère ne supporte pas ce type de RAM.

La RAM il faut compter 1Go par To de volume (1 volume pouvant être composé de plusieurs disques). L'ECC est loin d'être obligatoire, j'ai tourné plusieurs années sans et il ne m'est jamais rien arrivé. Le risque de corruption est le même qu'avec n'importe quel autre système de fichiers. Avec ECC, tu bénéficies du contrôle des données effectué par ZFS.

Autre pré-requis : CPU 64 bits. C'est pour cela que je garde mon Sempron64 (1x Core à 1.6Ghz !).

vivien · « **Réponse #4 le:** 26 août 2016 à 21:13:38 »

Le load average n'indique pas une charge CPU mais une charge (cela peut être un charge CPU ou d'E/S comme un disque)

Dans le cas d'une sauvegarde, c'est le disque qui est utilisé à 100% et qui fait qu'il y a toujours un process qui tourne, donc load average de 1.

Il faudrait faire un "top" pendant un transfert pour voir ce que fais le CPU.

PacOrly · « **Réponse #5 le:** 26 août 2016 à 23:14:49 »

Citation de: BadMax le 26 août 2016 à 20:51:44

La RAM il faut compter 1Go par To de volume (1 volume pouvant être composé de plusieurs disques).

Merci pour ces précisions.

nas03, volume de 18To, RAM 2Go, pas dans l'épure.
nas04, volume de 28To, RAM 2Go, pas dans l'épure.

Sinon, effectivement, cela m'aurait bien tenté de migrer vers ce système de fichier.

PacOrly · « **Réponse #6 le:** 26 août 2016 à 23:29:14 »

Citation de: vivien le 26 août 2016 à 21:13:38

Dans le cas d'une sauvegarde, c'est le disque qui est utilisé à 100% et qui fait qu'il y a toujours un process qui tourne, donc load average de 1.

Avec un transfert de 44 Mo/s entre les deux machines, peut on penser avoir une saturation d'une grappe de 20 disques en RAID6 soft (mdadm)?

Je pensai que c'était plutôt le processeur gérant ces 20 disques qui devait saturer.

vivien · « **Réponse #7 le:** 27 août 2016 à 00:06:55 »

Si tu pouvais à l’occasion vérifier, je suis curieux...

Effectivement, ce ne sera as les disques, mais cela pourrait être les E/S ?

"Top" distingue bien les choses et si le CPU est en attente d'E/S, mettre un plus puissant ne change rien.

PacOrly · « **Réponse #8 le:** 27 août 2016 à 00:25:46 »

Les E/S sont faites par un Chipset Intel® G31.

16 disques par le port PCI Express 16x et 4 disques par les ports SATA de la carte mère.

Je regarderai aussi avec "top" à l'occasion.

PacOrly · « **Réponse #9 le:** 27 août 2016 à 12:09:51 »

rsync nas03 vers nas04 depuis 11H10.
Transfert à 380 Mb/s.

nas03
top - 12:00:21 up 5 days, 23:48, 2 users, load average: 1,16, 1,17, 1,12
Tasks: 112 total, 2 running, 110 sleeping, 0 stopped, 0 zombie
%Cpu(s): 33,3 us, 11,5 sy, 0,0 ni, 41,7 id, 6,7 wa, 0,0 hi, 6,9 si, 0,0 st
KiB Mem: 2048744 total, 1981448 used, 67296 free, 146424 buffers
KiB Swap: 9595900 total, 244 used, 9595656 free. 1485316 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26530 root 20 0 50080 8900 4616 R 64,2 0,4 33:58.57 ssh
26529 root 20 0 67912 4880 2644 S 31,2 0,2 16:53.86 rsync
29 root 20 0 0 0 0 S 1,0 0,0 0:51.50 kswapd0

nas04
top - 12:00:53 up 5 days, 23:29, 1 user, load average: 1,96, 2,05, 1,97
Tasks: 117 total, 4 running, 113 sleeping, 0 stopped, 0 zombie
%Cpu(s): 39,2 us, 23,1 sy, 0,0 ni, 22,1 id, 0,2 wa, 0,0 hi, 15,4 si, 0,0 st
KiB Mem: 2048744 total, 1969672 used, 79072 free, 153276 buffers
KiB Swap: 1633276 total, 44 used, 1633232 free. 1498544 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11138 root 20 0 99336 10376 5536 R 99,1 0,5 50:42.71 sshd
11144 root 20 0 67856 2716 1288 R 43,5 0,1 22:11.88 rsync
129 root 20 0 0 0 0 S 7,0 0,0 5:49.23 md0_raid6

nas04
top - 12:15:28 up 5 days, 23:44, 1 user, load average: 2,25, 2,13, 2,03
Tasks: 116 total, 3 running, 113 sleeping, 0 stopped, 0 zombie
%Cpu(s): 41,5 us, 15,4 sy, 0,0 ni, 26,6 id, 0,0 wa, 0,0 hi, 16,4 si, 0,0 st
KiB Mem: 2048744 total, 1967860 used, 80884 free, 154076 buffers
KiB Swap: 1633276 total, 44 used, 1633232 free. 1482916 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11138 root 20 0 99380 10624 5536 R 99,6 0,5 64:51.14 sshd
11144 root 20 0 67856 2716 1288 R 43,5 0,1 28:24.27 rsync
29 root 20 0 0 0 0 S 1,6 0,0 1:07.48 kswapd0

BadMax · « **Réponse #10 le:** 27 août 2016 à 13:24:52 »

Voilà. C'est ssh qui sature l'un des deux coeurs. J'ai le même problème sur mon Sempron64 de backup, c'est pour cela que j'utilise mbuffer pour les send/receive de ZFS.

Pour améliorer la vitesse de rsync, l'autre solution est de faire un montage NFS depuis la machine de backup et de faire un rsync depuis les volumes montés vers le volume local. C'est bien plus rapide sur de vieux CPU.

vivien · « **Réponse #11 le:** 27 août 2016 à 13:25:47 »

Détail des données de top : Les états du CPU sont affichés dans la zone de résumé. Ils sont toujours présentés sous forme de pourcentage du temps écoulé depuis le dernier rafraîchissement.

us -- Temps CPU utilisateur : Temps consacré par le CPU aux processus utilisateurs dont la politesse n'a pas été modifiée.

sy -- Temps CPU système : Temps consacré par le CPU au noyau et à ses processus.

ni -- Temps de politesse (« nice ») du CPU : Temps consacré par le CPU aux processus utilisateurs dont la politesse a changé.

id -- Temps CPU non sollicité (idle)

wa -- En attente d'entrées ou sorties (« iowait ») : Temps consacré par le CPU à attendre la fin des entrées ou sorties.

hi -- IRQ matériel : Temps consacré par le CPU aux sollicitations des interruptions matérielles.

si -- Interruptions logicielles : Temps consacré par le CPU aux sollicitations des interruptions logicielles.

st -- Temps volé : La quantité de temps CPU « volé » à la machine virtuelle par l'hyperviseur pour d'autres tâches (telles que la gestion d'une autre machine virtuelle).