[technique] DELL R720

Dim 27 Sep 12:37:46 CEST 2020

> Le 27 sept. 2020 à 11:22, Emmanuel Thierry <emmanuel.thierry at sekil.fr> a écrit :
> 
> Bonjour,

Bonjour,

> 
> Je viens apporter mon petit grain de sel également ! ;)
> 
> Le Dimanche, Septembre 27, 2020 09:40 CEST, Alexandre GUY via technique <technique at lists.tetaneutral.net> a écrit:
> 
>> 
>>> Le 26 sept. 2020 à 17:33, Sébastien Dinot via technique <technique at lists.tetaneutral.net> a écrit :
>>> 
>>> Bonjour Alexandre,
>> 
>> Bonjour Sébastien,
>> 
>>> 
>>> Alexandre GUY via technique 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.
>>> 
>>> Je n'ai aucun détail quant à ton besoin ou tes contraintes et ceux-ci
>>> expliquent peut-être ton choix, mais au lieu d'effectuer un backup via
>>> tar, as-tu songé à utiliser un outil dédié tel que BorgBackup (Borg pour
>>> les intimes) ?
>> 
>> J’ai écrit ce script de sauvegarde il y a … 24 ans.
>> 
> 
> "il y a ... 24 ans", quand les tailles de stockage étaient d'un degré de magnitude environ 1 000 à 1 000 000 de fois plus faibles que maintenant. :)
> 
> Je n’ai rien contre le KISS (ou pour être plus précis le "refaire les choses soi-même"), mais amha quand il y a des logiciels bien conçus et bien maintenus qui font le job c'est toujours une mauvaise idée de refaire les choses soi-même.

Soyons clair, ce que fait le script perl, c’est le boulot d’un shell script, c’est à dire j’appelle deux commandes Unix avec un pipe entre les deux.

Je n’ai pas l’impression de « refaire les choses par moi-même » :)

> 
> Moi aussi il y a 15 ans (je suis probablement plus jeune que toi), j'avais mes propres scripts de backup en mode KISS. Mais ensuite j'ai vu des alternatives utilisables pour tous mes besoins et à partir de ce moment là j'ai utilisé des softs de backup pour tous mes serveurs. C’est simple, efficace et j'ai la garantie que ça marchera sur le long-terme en tenant compte des évolutions technologiques (technologies de disques, protocoles de transfert, algorithmes de compression, etc).

C’est ton point de vue.

Pour ma part, quand un truc fonctionne, qu’il répond au besoin et qu’il a fait ses preuves, je n’ai pas de raison d’en changer.

Je vais faire court : j’ai assez fait d’admin système, et je n’ai ni le temps ni l’envie de revoir mes stratégies de backups.

> 
>> Il est écrit en perl, il doit faire une vingtaine de lignes, dans la règle du KISS : il lit un fichier qui contient les répertoires à sauvegarder (genre /home/user1, /var/log, /var/lib …), et lance séquenciellement un TGZ de ces répertoires. Chaque nuit il écrase les sauvegardes de la veille, ce qui me permet en cas de pertes de fichiers, de ne perdre que théoriquement que les dernières 24h (mais bon, pour être exact, puisque le cron met 7h à s’exécuter, je devrais plutôt dire entre 17 et 24h).
>> 
>> Il a fonctionné et continue de le faire fidèlement depuis 24 ans.
>> 
>> Je n’ai rien contre Borg Backup, c’est même un sacré logiciel bien puissant, mais par rapport à mon besoin, Borg est overkill.
> 
> Vu que chacun se fend de sa proposition, pour ma part j'utilise backupninja avec duplicity pour faire les backups. Pour le coup la configuration et le fonctionnement sont très simples. Ça chiffre et ça compresse tout seul, ça fait des sauvegardes incrémentales, et donc je n’ai pas de problèmes de performances sur ma VM (sauf peut-être tous les mois lorsque la sauvegarde complète doit être refaite).

Ah, et il se passe quoi quand une sauvegarde complète est faite : ta VM rame pendant plusieurs heures.

Encore une fois, je ne critique absolument pas le travail fait par les bénévoles ni la qualité, ni la robustesse du cluster ceph, je dis juste : les IO disques sont lents.

> Il souffre probablement parfois de sa simplicité, mais apparemment c'est ce que tu cherches.
> 
> Historiquement je l'utilisais avec un remote SSH, il y a quelques mois je l'ai reconfiguré pour envoyer vers un object-storage Online (compatible S3). D’où ce que je disais avant : cela suit les évolutions technologiques sans que j'ai à faire quoi que ce soit.

On ne se connait pas, je ne sais pas où tu trouves ce temps. Je crois que j’ai trop fait d’admin système pour ne plus vouloir y passer mes soirées et WE.

> 
> 
>> 
>>> J'utilise ce dernier sur toutes les machines que
>>> j'administre et il est presque sans défaut à mes yeux. Il fonctionne par
>>> déduplication et il compresse les données, ce qui le rend redoutablement
>>> efficace en terme de stockage.
>> 
>> Je ne pense pas que la dé-duplication me ferait gagner beaucoup de place, c’est beaucoup de petits et moyens fichiers, et que la compression soit beaucoup plus efficace que celle proposée par GZIP (ok je pourrais faire un BZIP2).
>> 
>> Je ne pense pas non plus qu’il serait plus rapide.
>> 
>>> Il chiffre les données à la source et la
>>> restauration d'une sauvegarde entière, d'un répertoire ou d'un simple
>>> fichier est triviale. Il est performant et je m'en sers pour sauvegarder
>>> des serveurs hébergeant des téra-octets de données (jusqu'à 16 To sur
>>> l'un d'entre eux).
>>> 
>>> https://borgbackup.readthedocs.io/ (plus utile à connaitre que le site
>>> de référence du projet : https://www.borgbackup.org/)
>>> 
>>> Borg peut faire des sauvegardes en local ou à distance, via SSH.
>> 
>> Que cela soit tar, gzip ou Borg, à un moment donné, il faut bien que cela fasse un malloc pour lire le fichier, donc si je replaçais mon petit script par Borg, on constaterai probablement le même comportement liés à des IO disques lents sur le cluster Ceph.
> 
> Un malloc ? Je ne vois pas le rapport avec le disque du coup.
> Tu voulais dire un mmap peut-être ?

C’était pour vulgariser, lol :)

> 
> Ça me gène que le débat tourne des IOs alors qu'il y aurait des choses à améliorer dans l'utilisation des disques dans la VM pour ne pas être impacté par les IOs. Je ne dis pas que l’accès aux disques est très performant, mais quand on manque d'une ressource on fait attention à l'usage de cette ressource.

Une application PHP / Mariadb un peu usine à gaz genre Moodle est difficilement utilisable sur le cluster, il faut attendre entre 5 à 10s entre chaque page (testé sur une autre VM).

> 
> Pour ma part je poserais d'autres questions :
> * En principe sur ta VM tu dois avoir un disque sur le cluster SSD et un disque sur le cluster HDD, car c'est apparemment le standard maintenant chez TTN. Tes données sont sur lequel des deux et ton répertoire temporaire pour le backup sont sur lequel des deux ?

Pour répondre à tes questions, il faut être un admin du cluster

> * Par ailleurs, je ne sais pas exactement où est le bottleneck du cluster Ceph, mais est-ce que ce ne serait pas une bonne idée de demander un volume supplémentaire et le dédier à tes backups pour que les accès disques de tes backups ne soient pas synchrones avec les acccès disques de tes data ?
> 
> Manu

Je pense que les autres bénévoles te le confirmeront : le problème aujourd’hui, c’est le manque de bénévoles pour s’occuper du cluster.

Puisque apparement tu as de bonnes idées et que tu connais bien l’admin système, tu es le bienvenu. 

A confirmer par le trésorier, si tu es chaud pour aller brancher une ou deux machines et les configurer pour consolider le cluster, ça doit être jouable.

Bon dimanche,

Alex.

> 
>> 
>>> Par
>>> contre, Borg ne sait pas pousser les sauvegardes dans un espace S3 ou
>>> autre « object storage ». Si tu as un besoin de ce genre, tu dois te
>>> tourner vers Restic qui a lui aussi bonne réputation, même s'il souffre
>>> de défauts rédhibitoires à mes yeux.
>>> 
>>> https://restic.net/
>>> 
>>> Sébastien
>> 
>> Je n’ai pas ce type de besoin.
>> 
>> Merci de ton retour
>> 
>> Alex.
>> 
>>> 
>>> --
>>> Sébastien Dinot, sebastien.dinot at free.fr
>>> http://www.palabritudes.net/
>>> Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
>>> _______________________________________________
>>> technique mailing list
>>> technique at lists.tetaneutral.net
>>> http://lists.tetaneutral.net/listinfo/technique
>> _______________________________________________
>> technique mailing list
>> technique at lists.tetaneutral.net
>> http://lists.tetaneutral.net/listinfo/technique