[technique] DELL R720

Alexandre GUY alex at euronode.com
Lun 28 Sep 19:39:57 CEST 2020


> 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 :)

> 
>> 
>> 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.

> 
> 
> 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.

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é.

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.

> 
> 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 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.

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 :)

> 
> Bonne semaine.
> Fabien
> 

Bonne soirée,

Alex.

>> 
>> Bon week-end,
>> 
>> Alex.
>> 
>>> _______________________________________________
>>> technique mailing list
>>> technique at lists.tetaneutral.net
>>> http://lists.tetaneutral.net/listinfo/technique
> 
> _______________________________________________
> technique mailing list
> technique at lists.tetaneutral.net
> http://lists.tetaneutral.net/listinfo/technique



Plus d'informations sur la liste de diffusion technique