[technique] DELL R720

Fabien ADAM id2ndr at crocobox.org
Mar 29 Sep 23:14:31 CEST 2020


Le 28/09/2020 à 19:39, Alexandre GUY a écrit :
>> Le 27 sept. 2020 à 23:35, Fabien ADAM via technique <technique at lists.tetaneutral.net> a écrit :
>>
>> Le 26/09/2020 à 15:44, Alexandre GUY a écrit :
>>> [..]
>>> Aujourd’hui le backup s’est terminé à 10h, il a donc mis « que » 7h, au lieu de 10h avant l’augmentation de la ram.
>> 30% de gain c’est sympa déjà :)
> A force de rajouter de la RAM, le filesystem va finir par y être, ce qui devrait rendre les sauvegardes encore plus rapides, lol :)

Après si tu veux on peut héberger un raspberrypi 1, avec un disque usb 
dédié dessus : t'auras éventuellement plus d'IO, mais ça m'étonnerait 
que ça marche aussi vite (y compris la sauvegarde).
Il me semble que 4Go de RAM sur une VM n'est pas forcément énorme, et 
semble manifestement bien plus adapté que 2Go pour ce que tu y fais 
tourner dedans.

>
>>> Le passage à 4Go de ram a amélioré le temps de sauvegarde, je n’ai pas pris de OOM killer, c’est cool … mais 7h ça continue d’être long, car pendant ce temps, la VM est un peu à la ramasse. Donc ça ne résout pas complètement les problèmes de lenteur pour accéder à pleins de petits fichiers.
>> Peut être qu’elle est moins à la ramasse que lorsqu'elle n'avait que 2Go de RAM, non ?
> Difficile à apprécier, mais je dirais quand même oui, j’ai l’impression que cela va un peu plus vite.

Nice :)

>
>>
>> J'ai lu tous les autres messages, et ta réponse systématique du fait que tu ne veuilles pas remettre en question ta procédure de sauvegarde d'un autre siècle. Je trouve ça un peu dommage surtout si en très peu d’effort ça pouvait t'amener un gain de 3x en vitesse, mais bon, c'est ton choix et je le respecte.
> Ben je l’ai pris sur moi car je n’ai pas voulu lancer un nième troll, mais je ne vois pas en quoi c’est d’un autre siècle. Je fais juste une grosse archive de mes données avec tar + gzip. Chaque jour. A l’époque où on achète des 4To pour moins de 100 balles, je ne vois pas en quoi une sauvegarde quotidienne de 20Go serait problématique.

On achète aussi des SSD à 100 balles, mais ce qui compte avec eux, c'est 
leur TBW, qui définit leur endurance. Écrire 20Go/jour pour rien, ça 
l'use prématurément pour rien, ce qui est dommage. Mais pour un disque 
mécanique le problème ne se pose pas en effet : ça entraine juste un 
ralentissement des autres traitements à côté (toujours pour rien).

>
> La seule solution pour réduire ce temps serait de faire des backups incrémentaux, mais pour avoir eu des mauvaises expériences, j’ai préféré oublier cette possibilité.

Peut être que ces mauvaises expériences datent aussi du siècle dernier ? 
En tout cas dans le domaine ça s'est beaucoup amélioré, et c'est devenu 
la base de tous les systèmes de sauvegardes aujourd'hui. C'est un peu 
comme utiliser un shell sans avoir de complexion quoi...

>
> Borg ou tout autre outil, aussi puissant et sophistiqué soit-il, ne pourra réaliser une sauvegarde complète en moins de temps que ne le met tar + gzip. Dans tous les cas, à un moment il faudra bien lire le contenu de ces fichiers pour les sauvegarder, et c’est justement là que se situe le ralentissement : les IO disques.

Ce qui précède est probablement faux :
- écrire sur disque entraîne des ralentissements de la lecture sur tout 
disque mécanique
- gzip ne sait pas utiliser plusieurs threads
- il y a des algorithmes plus malin, pouvant être beaucoup plus rapide, 
pour comparer les fichiers. Je donne un exemple (je dis pas que c'est le 
meilleur) : on peut simplement regarder la date de modification d'un 
fichier, et, si elle est identique à celle du fichier déjà présent dans 
la sauvegarde, considérer que c'est le même. En faisant ça, on peut 
aller infiniment plus vite pour faire la sauvegarde : il suffit de lire 
les dossiers pour avoir tous les attributs des fichiers, et on évite 
alors la lecture de miliers de fichiers. Peut être que ce simple algo 
serait utilisable dans ton cas, et tu passerais d'une sauvegarde de 7h, 
à une sauvegarde de 5 minutes grand max...

>
>> Je pense qu'il faut faire tourner le serveur Dell afin de :
>> 1. l’utiliser tout simplement (oui c'est dommage une machine qui dort, alors qu'elle a du potentiel)
> Clairement
>
>> 2. avoir une autre architecture, qui peut intéresser d’autres personnes dans l'asso pour différentes raisons (vive la diversité)
> Tout à fait
>
>> 3. avoir un point de comparaison : j’attends avec impatience la durée effective de tes sauvegardes sur cette autre solution, ainsi que la disponibilité du service pendant celles-ci
> Sur ce point là, cela va être difficilement comparable car le DELL n’aura pas la même charge que le cluster, ni le même usage. De plus, on va monter des disques rotatifs pour avoir du stockage et de la redondance x 3 en RAID1 logiciel. La sécurité des données avant tout.

- Je pense que l'endroit où se situe ta sauvegarde est sur les HDD du 
cluster Ceph
- Ceph fait un redondance x3 de tes données, en logiciel
- niveau charge, le Dell est prévu pour faire tourner des VM... comme le 
cluster Openstack (euh, libvirt)
... C'est assez similaire non ?
Et oui : on utilise Ceph pour cette raison même : la sécurité avant tout 
et ça a fait ses preuves ;)


>
> Je ne sais pas combien il y a de core sur cette machine, mais on va essayer de donner 2 ou 4 VCPU par VM. C’est surtout ça qui va faire la différence : rien à foutre si le cron de backup met 3h à s’exécuter si pendant ce temps la VM n’est pas à la ramasse et continue à être utilisable.
>
> Car je pense que mon problème est aussi là : sur ma VM actuelle, j’imagine comme tout le monde, je n’ai qu’un seul VCPU.

C'est possible ! Et si c'est le cas, il faut l'augmenter : ça ne devrait 
pas être un souci dans notre cluster.

>
> Pour l’anecdote, avant de dire une connerie, j’ai voulu vérifier sur ma VM : j’ai bien attendu 30 secondes avant d’obtenir un shell … ma VM doit être hébergée sur la même machine physique que les mineurs de bitcoin de TTNN :)

Sans le savoir, tu avais presque vu juste !
En fait ta VM est sur g2... et on a fait une intervention matérielle 
dessus aujourd'hui, parce qu'il y avait une surchauffe CPU. La 
conséquence, c'est que ça ralentissait le processeur pour éviter la 
surchauffe et la panne définitive. Maintenant que c'est résolu, la 
charge de la machine est de 1.5 actuellement, soit que dalle.
=> Tu devrais trouver ta VM bien plus rapide dorénavant !

Bonne soirée



Plus d'informations sur la liste de diffusion technique