[technique] DELL R720

[Alexandre GUY]

> Le 1 oct. 2020 à 22:33, Fabien ADAM <id2ndr at crocobox.org> a écrit :
> 
> Salut,

Salut Fabien,

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

Ce n’est pas 20Go tout à fait identique, mais bon, passons …

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

Oui et non, car si tu as un problème avec les incréments, tu ne restaures qu’une sauvegarde totale qui a plusieurs jours. Peut-être une perte acceptable pour toi, mais pas pour moi car ma messagerie, c’est un composant essentiel de mon métier.

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

Lu il y a quelques années sur slashdot.org, je te laisse le soin de retrouver le post :) … tu te doutes bien que Amazon n’a pas communiqué dessus :)

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

Que cela vienne d’un défaut du stockage distribué, de panne matérielle ou d’une erreur humaine, dans tous les cas, les trois scénarios peuvent arrivez chez TTNN, non ?

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

Ok ce qui signifie l’acceptation de la perte de données de plusieurs jours si il y a un problème avec les incréments.

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

Sur ce point, tout à fait d’accord, si tu me confirmes que la place disque n’est pas un problème, je vire gzip et je ne laisse que tar, c’est encore mieux car on peut arriver à restaurer tous les fichiers d’un tar corrompu (fichiers qui ne sont pas sur l’endroit de la corruption, on est bien d’accord).

Déjà testé à la belle époque des sauvegardes sur bandes magnétiques :)

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

Idéalement pour être sur il faut calculer un hash du fichier, mais pour cela, on est bien d’accord, il faut le lire :)

La solution inotify est effectivement propre, encore faut-il avoir un logiciel de backup qui gère ça.

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

Met toi à ma place, à part les IO disques, qu’est ce qui pouvait expliquer ce ralentissement ?

De là à imaginer que cela pouvait venir du ventilateur d’un processeur …

Et dans mon affirmation, il y a les mauvais souvenirs passés où le crash d’un disque dur nécessitait une reconstruction qui prenait des plombes et qui rendait le cluster inutilisable. OK cela a changé, ce n’est plus le cas, mais j’ai pas mal souffert à l’époque des reconstructions.

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

Rien n’est encore fait : j’ai soumis l’idée au CA il y a quelques jours en précisant bien que j’avais une fenêtre de 3 ou 4 semaines où j’étais à Toulouse et où je pouvais m’en occuper, si leur réponse se fait trop attendre, le temps que les disques arrivent, que l’on trouve le bon créneau pour aller à TLS00 … si ça se trouve je serai déjà reparti sur des missions aux quatre coins de la France.

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

Attention, je ne suis pas en train de dire que Ceph n’est pas un bon produit et qu’il n’est pas fiable, j’ai juste souffert ces dernières années des reconstructions infernales, et ces derniers temps de OOM killers intempestifs, jusqu’à ce que je m’aperçoive que cela venait de mon pauvre petit cron de sauvegarde.

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

Il y a 3 semaines ma machine a rebooté sans raison apparente, j’ai voulu comprendre pourquoi, j’ai envoyé un mail sur la liste, personne n’a répondu.

Attention encore une fois, je ne suis pas en train de critiquer, je sais bien que l’asso est géré par des bénévoles (dont je fais parti en hébergeant des antennes) et que c’est du best effort sans aucune garantie.


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

Houla je sens que tu t’es un peu vexé parce que j’ai dit du mal du cluster, mais essaye de te mettre un peu à ma place, je suis sur g2 et on vient de s’apercevoir que cela fait plus de 9 mois que le processeur ne fonctionne pas à sa capacité nominale, donc cela fait 9 mois que ma VM ne fonctionne pas bien (lenteurs + OOM), alors que cela vient du hardware la machine sur laquelle je suis hébergé. Après, je suis d’accord, parler des mineurs de bitcoin, c’était un troll :)

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

Tu sais, j’ai bien des défauts, mais je sais reconnaitre quand je me trompe et je l’admet volontiers.

Aujourd’hui il a fini à 8h07. Je vais surveiller les jours à venir.

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

Mais après le changement du ventilateur processeur de g2 :)

Donc OK le problème ne vient pas des IO disques … mais est-ce que tu me concèdes que, vus les problèmes que j’avais (un cron qui fait un backup et qui met plusieurs heures à s’exécuter), la première chose à laquelle tu penses, c’est les IO disques ? Surtout après les problèmes que l’on avait par le passé lors des reconstructions ?

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

C’est surtout quand j’ai commencé à avoir des OOM Killers régulièrement que je m’en suis aperçu, sinon je vous l’aurais dit plus tôt :)

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

<troll detected> ! sacré Fabien ;)

Coté supervision, peut-être que superviser les VM n’est pas le plus important, et que l’on devrait se concentrer sur la supervision des machines physiques, et mettre en place des remontées d’alertes.

Là aussi, je ne critique pas le travail accompli, je dis juste que notre supervision pourrait être plus précise et surtout efficace : tout de suite, si on activait les remontées des erreurs de la supervision par mail, juste on ne les lirait pas car on prendrait 500 mails par jour.

Comme je disais à l’époque où je donnais des formations sur Nagios : « trop de notifications tue les notifications ».

Je veux bien donner un coup de main sur la config de Nagios pour mieux superviser le hardware des machines physiques (surveiller par ex la vitesse de rotation des ventilateurs, les status smart des disques, les charges processeurs et mémoires …), et surtout nous remonter des alertes pertinentes.

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

On va où maintenant que le bar de la Lune a fermé ?

Bonne journée,

Alex.

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