[technique] DELL R720

[Fabien ADAM]

Salut,

Le 30/09/2020 à 00:37, Alexandre GUY a écrit :
> [..]
>> 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).

Attention, je n'ai pas dit que faire des sauvegardes c'était pour rien, 
j'ai simplement dit que d'écrire 20Go *identiques* chaque jour c'était 
inutile.

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

Tu as bien raison : c'est aussi pour cette raison que tous les logiciels 
de sauvegarde font une sauvegarde totale de temps en temps, et des 
incréments entre chaque total : le meilleur des 2 mondes en somme.

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

Je ne connais pas cette histoire, mais si tu as une source je suis preneur.
Une question qui me vient tout de suite : à quoi est du cette perte de 
0,7% ? Est-ce un défaut du stockage distribué, un panne matérielle 
majeure, ou plutôt une erreur humaine ? Suivant le cas, il est possible 
que ton argument ne tienne pas.

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

Cf ma remarque plus haut sur les sauvegardes complètes... mais pas tous 
les jours.

Mais sinon si on peut faire plus rapide que tar + gzip : si les IO sont 
bonnes (et tous les mails échangés n'ont jamais démontré le contraire), 
la compression ralenti énormément ta sauvegarde, en comparaison d'un tar 
sans le gzip. Un logiciel de sauvegarde pourrait éventuellement être 
plus malin que ton simple pipe pour optimiser les performances au niveau 
du CPU et du parallélisme des IO.

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

Oui.... sauf à ne pas utiliser gzip du tout.

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

Comme je disais, c'était pas forcément le meilleur exemple. Il n'empêche 
qu'il pourrait être tout à fait réaliste et nettement plus efficace, 
évidement à condition de ne pas tout faire pour qu'il soit non 
applicable (option nomtime). On peut l'améliorer légèrement en regardant 
la taille pour avoir une sécurité en plus, où même faire du temps réel 
avec inotify.

>
> 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 le répète : à aucun moment il n'a été prouvé que les problèmes que tu 
rencontres sont liés aux IO disques. Il faut arrêter d'affirmer des 
choses sans preuve.

> [..]
>> - 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 ?

On peut regarder, mais ça me semble inutile maintenant à la vue de la 
migration prochaine sur le Dell.

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

Oui, tout comme ça dépend de combien on met de VMs sur le Dell et ce 
qu'elles font : tout pareil en fait ;).

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

Tout comme un gros bug du contrôleur disque du serveur Dell... Ceph est 
utilisé au CERN... c'est probablement un logiciel assez robuste ;).

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

Le mieux pour savoir, c'est pas de "penser" mais de demander. Non la 
ressource CPU n'est pas si rare et précieuse pour une raison toute 
simple : les VM ne minent pas du bitcoin comme tu l'affirmes sans 
savoir, mais sont au contraire très "passives".

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

Ce sont des choses qui peuvent arriver oui. Vive les sauvegardes, on est 
d'accord ;)

>> Le 29 sept. 2020 à 23:14, Fabien ADAM <id2ndr at crocobox.org> a écrit :
>>
>>>>> 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.
> Surprise ce matin, le backup a mis cette nuit que 4h30 à s’exécuter (hier 4h51). Ah enfin des performances acceptables !

Je suis ravi que tu aies remonté cette information de toi même en toute 
transparence :)
Au final je tenais à te faire remarquer qu'on est passé de 10h à 5h... 
sans rien changer aux IO du cluster Ceph qui est donc "toujours aussi 
lent"...

>
> Apparement c’est bien le changement de ventilateur du processeur qui a corrigé le problème de g2 qui était là depuis plusieurs mois.
>
> Je viens de regarder vite fait par rapport à la durée de mes sauvegardes, je peux même vous dire que cela a commencé à déconner le 12 janvier 2020.
>
> C’est dommage que la supervision ai loupé ça.

C'est surtout dommage que tu nous aies pas dit comment avait évolué ton 
temps de sauvegarde dans le temps : on aurait pu savoir qu'un problème 
était apparu, et ainsi l'identifier et le corriger plus vite.

La supervision c'est pas magique... mais si t'as l'astuce avec 2 
commandes et un pipe au milieu pour que ça nous supervise tout pour les 
30 ans à venir, on est preneur ;)

>
> Je vais quand même surveiller l’évolution les jours à venir.
>
> Excellente journée à tous,
>
> Alex.

Bonne fin de soirée,
Et à la prochaine pour une bière !

PS : je voulais bien entendu dire "complétion", avec un "t" comme dans 
tonton Thierry ! Merci tTh :)