[technique] DELL R720

Dim 4 Oct 20:57:55 CEST 2020

> Le 3 oct. 2020 à 15:32, Fabien ADAM via technique <technique at lists.tetaneutral.net> a écrit :
> 
> Hello,

Hello,

> 
> Le 02/10/2020 à 11:14, Emmanuel Thierry a écrit :
>>> Le 1 oct. 2020 à 22:33, Fabien ADAM via technique <technique at lists.tetaneutral.net> a écrit :
>>>> 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 ne suis pas vraiment d’accord.
>> 
>> Le gzip est effectivement mono-thread, mais il ne passe pas 100% de son temps en compression, il passe une partie de son temps en compression et une partie de son temps en IO. Et c’est d’autant plus vrai sur des setups un peu faibles en IO. Un process gzip naïf (par exemple un tar.gz) perd nécessairement du temps.
>> 
>> Donc une solution de backup qui parallélise les compressions gzip prendra nécessairement moins de temps qu’un gzip/tar-gz naïf, et ce même sur un seul VCPU.
> 
> Tout dépend des quelle ressources est la plus abondante entre les IO, et le CPU (et dans une moindre mesure la RAM).
> Quand on a pas beaucoup d'IO, gzip sera avantageux.
> Quand on a pas beaucoup de CPU, ne pas utiliser la compression sera souvent plus avantageux.
> Quand on a pas beaucoup des 2 (et quand on a beaucoup des 2 aussi), gzip avec un niveau de compression choisi avec soin sera le plus avantageux.
> 
> 
> Le 02/10/2020 à 13:40, Alexandre GUY a écrit :
>> [..]
>>>> 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).
> 
> Je ne confirme rien : je ne sais même pas si les 20Go dont on parle correspondent à la taille compressée ou d'origine, ni l'espace disponible à l'endroit où la sauvegarde se trouve.
> 
>> [..]
>>>> 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 ?
> 
> C'est là qu'un peu d'admin sys sur ta VM aurait pu apporter des réponses. Du point de vue des bénévoles du cluster on a aucune métrique pour savoir ce qui se passe à l'intérieur de la VM.
> Cependant plusieurs bénévoles t'ont dit qu'ils ne constataient pas de ralentissement avec les autres VM, et que la tienne était un cas particulier. C’est donc là que tu aurais pu faire un peu d'admin sys pour récupérer en particulier le temps CPU passé en waiting d'IO.

La prochaine fois j’installerai munin sur ma VM.

> 
>> 
>> 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.
> 
> En réalité cela n'a pas (encore ?) changé. Il se trouve qu’on fait une reconstruction 1 fois tous les 6 mois environ (quand on change plusieurs disques en panne), donc le reste du temps ça va bien.

La dernière fois, vous avez changé 6 disques sur 57. Peux-tu me dire sur quelle période ces 6 disques dur ont grillé ?

A partir de combien de disques changés la reconstruction est-elle obligatoire ?

> 
>> 
>> [..]
>>> 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.
> 
> Y'a 0 disque dans le serveur ? Même s'il y en a juste 1, ça permet quand meme de l'installer et le mettre en ligne. On peut rajouter du disque à chaud dans un second temps.

Aucun disque sur le serveur.

A faire une install, autant en installer au moins deux au départ pour avoir quand même du RAID1.

> 
>> [..]
>> 
>>> 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.
> 
> Les VM ne sont pas supervisées, à part un simple ping. Cette supervision basique est nécessaire pour répondre au mieux aux membres qui n’utilisent ni ne vérifient leur VM en permanence (la plupart des gens).

OK

> 
> La supervision des machines physiques est relativement limitée, car jusque là on s'aperçoit très vite de l'ensemble des problèmes "binaires". Pour les problèmes plus diffus comme une baise de performance CPU, ça fait effectivement défaut aujourd’hui.

Je pense qu’il faudrait au moins superviser (avec notifications) sur les machines physiques :
- vitesses de rotation de tous les ventilateurs
- status SMART des disques durs
- capteurs de températures de la CM
- métriques système classique (CPU, RAM, IO)

> 
>> 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.
> 
> Le mail (bien que ça soit ton outil de travail) n'est pas la meilleure façon d'alerter les bénévoles de l'asso. Je te rejoins sur le fait que l'alerting ne doit être activé qu'une fois que la supervision est bien réglée, sous peine de recevoir des salves d'alertes inutiles en permanence.

Si la meilleure façon d’alerter les bénévoles est l’IRC, il y a moyen de faire un bot qui pousse les notifications Nagios sur l’IRC.

> 
>> 
>> Comme je disais à l’époque où je donnais des formations sur Nagios : « trop de notifications tue les notifications ».
> +1
> 
>> 
>> 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.
> 
> Pour participer à cet effort, le mieux est de discuter de manière plus interactive avec 1/des bénévole(s) intéressé(s) par le même sujet sur IRC ou Matrix.
> A TTN check_mk est installé, en plus de Prometheus/Grafana. Pour ma part j’utilise LibreNMS pour ma supervision.

Peu importe l’outil du moment où il fait le job.

A+
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 question !
> 
> A+
> _______________________________________________
> technique mailing list
> technique at lists.tetaneutral.net
> http://lists.tetaneutral.net/listinfo/technique