[technique] DELL R720

[Fabien ADAM]

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.

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

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

> [..]
>
>> 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 plupard des gens).

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.

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

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

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