[technique] DELL R720

Mer 30 Sep 00:37:37 CEST 2020

> Le 29 sept. 2020 à 23:14, Fabien ADAM <id2ndr at crocobox.org> a écrit :
> 
> 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 :)

Salut Fabien,

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

Je ne vois pas trop le rapport avec ce que je disais, il faudra que tu m’expliques autour d’une bière.

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

Oui c’est sur que ce n’est pas de trop, mais je n’osais pas demander …

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

Merci à TTNN et à Matthieu qui a fait la manip !

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

Pour moi, faire des sauvegardes quotidiennes de mes données personnelles, ce n’est pas écrire 20Go/jour pour rien. Même si cela use les disques (lol).

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

Tu verras le jour où tu vas avoir un _vrai_ soucis avec tes backups « incrémentaux » :) … ce jour-là, tu penseras un grand coup à moi en te disant : « cet enfoiré d’Alex aurait réglé le problème avec un tar xzf » :)

Amazon, qui fait du stockage de type ceph depuis bien plus longtemps que nous, a perdu un jour 0.7% de leurs données. 0.7%, vous allez me dire, ce n’est pas beaucoup … il a donc fallu aux clients accepter d’avoir perdu 70Mo par Go … dommage pour les photos de vacances.

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

Hors sujet cher Fabien, lis bien ma question, je parle de réaliser une sauvegarde _complète_.

Au passage, si gzip était multi-threadé, je ne pense pas que cela changera beaucoup sur une VM avec un seul VCPU :)

Je sais bien qu’il existe des moyens plus futés pour optimiser des sauvegardes.

J’aime bien ton algo : « 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 »

Je ne partage pas la même définition du mot « sauve-garde ».

… et un jour, un jeune admin, croyant bien faire, rajouta l’option « nomtime » dans /etc/fstab …

Je constate surtout que je ne peux pas demander à une VM en 2020 de faire ce que faisait une machine physique il y a 30 ans. Je l’accepte, ça va, il n’y a pas de problème, je vais migrer sur le gros DELL et je vais arrêter de faire chier avec 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 pense que l’endroit où se situe ta sauvegarde est sur les HDD du cluster Ceph

Je n’en ai aucune idée, comment le savoir ?

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

Non pas vraiment, ça dépend de combien on met de VM dessus et ce qu’elles font, non ?

> Et oui : on utilise Ceph pour cette raison même : la sécurité avant tout et ça a fait ses preuves ;)
> 

Je n’ai rien contre Ceph, mais il faut aussi avoir conscience que tu n’es pas à l’abri d’un gros bug ceph qui te crashe toutes tes données. Ça peut aussi arriver.

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

Là aussi, je n’ai pas spécialement pensé à demander, je pensais que la ressource (le vrai core) était rare et précieuse sur le 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 !

Oui ça va j’ai pu me loguer dessus, mais j’ai une autre VM qui est reparti difficilement, merci encore une fois à Matthieu Herrb qui me l’a re-démarré on/off, elle a fini par booter, mariadb cassée, innodb grosse merdasse, données perdues, lol. Heureusement j’avais une sauvegarde, mais ça ne redémarre toujours pas, lol #2.

> 
> Bonne soirée

Bonne soirée Fabien,

Alex.