Re: Gestion de très gros FS

[Daniel Caillibaud]

Le 02/05/17 à 18:49, Thierry Bugier Pineau  a écrit :
TBP> Ce n'est pas tordre le système de snapshot que de les garder longtemps ?

Plus avec btrfs justement, ou un snapshot est un subvolume presque comme un 
autre, sinon
qu'il partage des références avec un autre subvolume, c'est un de ses avantages 
sur lvm.

Ça permet de conserver un snapshot par semaine sur un an + les 7 derniers jours 
sans prendre
trop de place (avant je faisait ça avec du hardlink, mais ça prend quand même 
un bloc par
fichier par snapshot même si le fichier est identique partout).

Le pb que j'ai eu arrive est quand tu écris bcp sur un parent de nombreux 
snapshot (et que
chaque snapshot est gros).

Si tu écris sur un subvolume parent de personne ça pose apparemment bcp moins 
de pb.

-- 
Daniel

Il y a trois temps qui déplaisent souverainement aux jardiniers : 
le temps sec, le temps pluvieux et le temps en général.
Pierre Daninos

Re: Gestion de très gros FS

[Thierry Bugier Pineau]

Bonjour

Ce n'est pas tordre le système de snapshot que de les garder longtemps ?

Pour lvm les snapshots sont en copy on write. Apparemment btrfs ferait pareil 
vu la description du comportement.

Tout ce que j'ai lu dit que les snapshot sont des instantanés qui servent le 
temps d'un backup. Autrement dit : 
- on fige le FS sur le disque 
- on met à part les écritures (une sorte de tampon, et lvm ou le FS le gère 
selon le cas)
-jusqu'à ce que le FS figé soit pleinement exploité pour une tâche de 
sauvegarde.
- la tâche terminée, on détruit le snapshot en y incorporant les écritures 
précédemment mises à part (là encore lvm ou le FS gère cela)

On peut tout aussi bien historiser les sauvegardes et laisser le backup les 
gérer (backuppc par exemple mais guère pour un usage pro sur grosse quantités 
de données)


Le 2 mai 2017 17:46:40 GMT+02:00, Daniel Caillibaud  a 
écrit :
>Le 21/03/17 à 11:42, Pierre Malard  a écrit :
>PM> J’ai lu que BtrFS semblait se présenter comme le « successeur » de
>ext4 et proposait un
>PM> redimensionnement à chaud en complément du gestionnaire de volumes
>logiques de Linux. Il
>PM> permettrait également l’agrégat de préifériques et la gestion de «
>snapshots
>PM> » (https://fr.wikipedia.org/wiki/Btrfs). Avez-vous une expérience
>dans ce domaine et est-ce
>PM> que cela répondrait à notre besoin de gros volumes extensibles ?
>
>J'arrive longtemps après la question, au cas où ça serve à d'autres…
>
>Je n'ai pas d'expérience de btrfs sur de tels volumes, mais sur 3~4To
>de datas avec bcp de
>snapshots, il faut faire attention à l'ordre des snaphots pour garder
>une "filiation la plus
>linéaire possible".
>
>C'était pour du backup, je faisais
>- rsync de pleins de vm dans last (un subvolume)
>- delete Monday && snapshot de last sur Monday le lundi
>- … idem les autres jours, avec en plus le dimanche un
>- delete week_XX && snapshot de last sur week_XX
>
>mais de temps en temps, et de plus en plus souvent avec l'augmentation
>du nb de snapshots, le
>delete faisait complètement exploser le système, à retardement (lorsque
>btrfs nettoie ses
>metadatas, un peu plus tard, si le rsync démarre avant que tout soit
>nettoyé).
>
>L'explosion se traduisait par un système qui fige, avec ou sans oomkill
>tous azimuts. 
>
>Un expert btrfs m'a confirmé avoir déjà vu la RAM exploser dans ce
>genre de cas, sans vraiment
>savoir pourquoi… (que le load explose parce que le fs devient très lent
>ça peut s'expliquer,
>mais pas qu'il consomme énormément de RAM).
>
>C'est visiblement lié au fait du nb de snapshots qui dépendaient du
>volume dans lequel
>j'écrivais, chaque écriture sur un fichier déclenchant une cascade
>d'opérations pour que tous
>les subvolumes retrouvent leurs petits (tous ses snapshots doivent se
>mettre à jour sur
>l'ancienne version du fichier, trouver lequel la détient, etc.)
>
>En modifiant la rotation pour faire
>mv Monday avirer
>mv last Monday
>snapshot Monday last
>rsync vers last
>
>ça va bcp mieux (chaque écriture ne déclenche qu'un seul copy on write
>sur le dernier snapshot
>sans que les autres n'aient à faire qqchose, la suppression d'un
>subvolume n'entraînant de
>modif que chez son unique "fils").
>
>Tout ça pour dire que btrfs reste chatouilleux et peut partir en vrille
>(machine HS mais pas
>perdu d'octet), même si la gestion des snapshots reste un avantage très
>appréciable.
>
>Et je n'ai pas encore osé passer au btrfs send/receive pour
>synchroniser deux volumes, mais
>chez d'autres ça marche vraiment très bien (10~100 × plus rapide que
>rsync suivant le nb de
>fichiers, le volume et la BP dispo).
>
>-- 
>Daniel
>
>On devrait construire les villes a la campagne
>car l'air y est plus pur !
>Alphonse Allais

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: Gestion de très gros FS

[Daniel Caillibaud]

Le 21/03/17 à 11:42, Pierre Malard  a écrit :
PM> J’ai lu que BtrFS semblait se présenter comme le « successeur » de ext4 et 
proposait un
PM> redimensionnement à chaud en complément du gestionnaire de volumes logiques 
de Linux. Il
PM> permettrait également l’agrégat de préifériques et la gestion de « snapshots
PM> » (https://fr.wikipedia.org/wiki/Btrfs). Avez-vous une expérience dans ce 
domaine et est-ce
PM> que cela répondrait à notre besoin de gros volumes extensibles ?

J'arrive longtemps après la question, au cas où ça serve à d'autres…

Je n'ai pas d'expérience de btrfs sur de tels volumes, mais sur 3~4To de datas 
avec bcp de
snapshots, il faut faire attention à l'ordre des snaphots pour garder une 
"filiation la plus
linéaire possible".

C'était pour du backup, je faisais
- rsync de pleins de vm dans last (un subvolume)
- delete Monday && snapshot de last sur Monday le lundi
- … idem les autres jours, avec en plus le dimanche un
- delete week_XX && snapshot de last sur week_XX

mais de temps en temps, et de plus en plus souvent avec l'augmentation du nb de 
snapshots, le
delete faisait complètement exploser le système, à retardement (lorsque btrfs 
nettoie ses
metadatas, un peu plus tard, si le rsync démarre avant que tout soit nettoyé).

L'explosion se traduisait par un système qui fige, avec ou sans oomkill tous 
azimuts. 

Un expert btrfs m'a confirmé avoir déjà vu la RAM exploser dans ce genre de 
cas, sans vraiment
savoir pourquoi… (que le load explose parce que le fs devient très lent ça peut 
s'expliquer,
mais pas qu'il consomme énormément de RAM).

C'est visiblement lié au fait du nb de snapshots qui dépendaient du volume dans 
lequel
j'écrivais, chaque écriture sur un fichier déclenchant une cascade d'opérations 
pour que tous
les subvolumes retrouvent leurs petits (tous ses snapshots doivent se mettre à 
jour sur
l'ancienne version du fichier, trouver lequel la détient, etc.)

En modifiant la rotation pour faire
mv Monday avirer
mv last Monday
snapshot Monday last
rsync vers last

ça va bcp mieux (chaque écriture ne déclenche qu'un seul copy on write sur le 
dernier snapshot
sans que les autres n'aient à faire qqchose, la suppression d'un subvolume 
n'entraînant de
modif que chez son unique "fils").

Tout ça pour dire que btrfs reste chatouilleux et peut partir en vrille 
(machine HS mais pas
perdu d'octet), même si la gestion des snapshots reste un avantage très 
appréciable.

Et je n'ai pas encore osé passer au btrfs send/receive pour synchroniser deux 
volumes, mais
chez d'autres ça marche vraiment très bien (10~100 × plus rapide que rsync 
suivant le nb de
fichiers, le volume et la BP dispo).

-- 
Daniel

On devrait construire les villes a la campagne
car l'air y est plus pur !
Alphonse Allais

Re: Gestion de très gros FS

[maderios]

On 03/23/2017 11:13 AM, Gabriel Moreau wrote:



Également, et depuis des années. Seul /boot est en ext3. Il devait y
avoir
une raison, dont je ne me rappelle pas !


Il faut / fallait que grub connaisse le système de fichier de /boot.


Il semble que grub supporte xfs depuis la version 0.97
http://xfs.org/index.php/XFS_FAQ#Q:_Does_GRUB_work_with_XFS.3F

--
Maderios

Re: Gestion de très gros FS

[Gabriel Moreau]

Également, et depuis des années. Seul /boot est en ext3. Il devait y avoir
une raison, dont je ne me rappelle pas !


Il faut / fallait que grub connaisse le système de fichier de /boot.

gaby
--
Gabriel Moreau - IR CNRShttp://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France
mailto:gabriel.mor...@legi.grenoble-inp.fr  tel:+33.476.825.015

Re: Gestion de très gros FS

[Haricophile]

Le Wed, 22 Mar 2017 17:46:04 +0100,
Jean-Michel OLTRA  a écrit :

> Également, et depuis des années. Seul /boot est en ext3. Il devait y
> avoir une raison, dont je ne me rappelle pas !

1) pour être certain de pouvoir booter sur quelque chose (ext2/3 c'est
dans grub et fiable depuis fort longtemps si le partitionnement est
ancien).
2) parce que le boot n'a aucun besoin d'être journalisé et d'avoir des
fonctions étendues. ext2 fait l'affaire.

-- 
haricoph...@aranha.fr 

Re: Gestion de très gros FS

[Gabriel Moreau]

Et pourquoi pas pour / ?


Parce que je laisse faire la distrib sur sa partition ;-)

gaby
--
Gabriel Moreau - IR CNRShttp://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France
mailto:gabriel.mor...@legi.grenoble-inp.fr  tel:+33.476.825.015

Re: Gestion de très gros FS

[Jean-Michel OLTRA]

Bonjour,


Le mercredi 22 mars 2017, Gabriel Moreau a écrit...


> > J'utilise xfs pour un stockage externe de taille modeste, ça marche
> > bien, même après un arrêt brutal. Comparé à ext4, que vaut xfs pour un
> > pc de production?

> C'est aussi bien. J'ai tous mes homes, mes tmp et mes data en XFS...

Également, et depuis des années. Seul /boot est en ext3. Il devait y avoir
une raison, dont je ne me rappelle pas !

-- 
jm

Re: Gestion de très gros FS

[maderios]

On 03/22/2017 04:56 PM, Gabriel Moreau wrote:



J'utilise xfs pour un stockage externe de taille modeste, ça marche
bien, même après un arrêt brutal. Comparé à ext4, que vaut xfs pour un
pc de production?


C'est aussi bien. J'ai tous mes homes, mes tmp et mes data en XFS...

gaby


Et pourquoi pas pour / ?

--
Maderios

Re: Gestion de très gros FS

[Gabriel Moreau]

J'utilise xfs pour un stockage externe de taille modeste, ça marche
bien, même après un arrêt brutal. Comparé à ext4, que vaut xfs pour un
pc de production?


C'est aussi bien. J'ai tous mes homes, mes tmp et mes data en XFS...

gaby
--
Gabriel Moreau - IR CNRShttp://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France
mailto:gabriel.mor...@legi.grenoble-inp.fr  tel:+33.476.825.015

Re: Gestion de très gros FS

[maderios]

On 03/21/2017 06:23 PM, Gabriel Moreau wrote:



Quelques partitions de 70 To et du XFS depuis des années (sur un DAS
Dell de plus de 190 To brut). Il fait le job tant qu'a rester dans le
système de fichiers non distribués.


Idem, 70To sur XFS marche très bien et résiste bien aux coupures
électrique non prévu...

A noter qu'il faut tester un xfs_check et xfs_repair au début avant la
mise en prod car ils sont gourmand en RAM. C'est con de faire un volume
de 200To et de ne pouvoir faire de check (même si on en fait très
rarement).

Coté performance, j'ai lu pas mal de retour d'expérience et pour le
moment, je reste sur XFS au vu de tout ce que j'ai vu. Cela semble
toujours un très bon système et en plus, il continue d'être activement
développé et maintenu.



Bonjour
J'utilise xfs pour un stockage externe de taille modeste, ça marche 
bien, même après un arrêt brutal. Comparé à ext4, que vaut xfs pour un 
pc de production?


--
Maderios

Re: Gestion de très gros FS

[Gabriel Moreau]

Quelques partitions de 70 To et du XFS depuis des années (sur un DAS
Dell de plus de 190 To brut). Il fait le job tant qu'a rester dans le
système de fichiers non distribués.


Idem, 70To sur XFS marche très bien et résiste bien aux coupures 
électrique non prévu...


A noter qu'il faut tester un xfs_check et xfs_repair au début avant la 
mise en prod car ils sont gourmand en RAM. C'est con de faire un volume 
de 200To et de ne pouvoir faire de check (même si on en fait très rarement).


Coté performance, j'ai lu pas mal de retour d'expérience et pour le 
moment, je reste sur XFS au vu de tout ce que j'ai vu. Cela semble 
toujours un très bon système et en plus, il continue d'être activement 
développé et maintenu.


gaby
--
Gabriel Moreau - IR CNRShttp://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France
mailto:gabriel.mor...@legi.grenoble-inp.fr  tel:+33.476.825.015

Re: Gestion de très gros FS

[MAS Jean-Louis]

Quelques partitions de 70 To et du XFS depuis des années (sur un DAS
Dell de plus de 190 To brut). Il fait le job tant qu'a rester dans le
système de fichiers non distribués.

On avait testé ZFS, mais les pertes de volumétrie étaient très
importantes, et sur les jeux de données utilisés les performances
n'étaient pas satisfaisantes.

Avoir des systèmes de fichiers distribués implique d'avoir un réseau
robuste et performant.

Je te conseillerais dans tous les cas de faire des tests de performance
avec les jeux de données que tu manipules au quotidien.

Cordialement

-- 
Jean Louis Mas

Re: Gestion de très gros FS

[didier gaumet]

> ça semble confirmer:
> - qu'il reste un écart entre théorique (1EB) et certifié (50GB) sur
> RHEL7

sur Ext4

Re: Gestion de très gros FS

[didier gaumet]

je ne suis pas familier avec de telles tailles de stockage et je ne vais
pas pouvoir te dire grand chose, mais dans le passé j'ai parfois entendu
dire que XFS et JFS étaient pas mal utilisés pour ça et encore récemment
j'ai entendu des administrateurs dire qu'ils gardaient Ext4 plutôt que
Btrfs dans l'immédiat, ce dernier n'étant pas encore assez marure.

Red Hat a récemment (janvier 2017) mis à jour sa doc sur les capacités
de stockage certifiées et théoriques de ses distributions par système de
fichier: https://access.redhat.com/solutions/1532

ça semble confirmer:
- qu'il reste un écart entre théorique (1EB) et certifié (50GB) sur
RHEL7, ce qui pourrait peut-être être expliqué par un noyau ancien (je
ne sais pas quel est la version du noyau sur RHEL7, mais RH a
typiquement une politique conservatrice à ce sujet) qui briderait Ext4
- que XFS serait un candidat potentiellement acceptable pour toi
(capacité certifiée 100TB)

d'autre part, tu pourrais peut-être envisager de migrer vers Jessie
voire vers Stretch, cela pourrait t'apporter des capacités supérieures à
50TB pour Ext4 et t'amener le support de Zfs dans le cas de Stretch.

mes 0,02€: ça fait pas lourd ;-)

Re: Gestion de très gros FS

[Felix Defrance]

Bonjour,

As tu regardé du côte du projet Ceph? Le Cern au LHC l'utilise par exemple.

Dans ma pratique, j'ai utilisé ce type de stockage distribué pour
héberger des VM sous Kvm.

Le stockage dans ce cas d'usage, est accessible via RDB. Mais depuis la
dernière version de ceph, il est possible d'accéder à ceph avec cephFS .
Voir ici:

  - http://docs.ceph.com/docs/master/cephfs/

Le file system utilisé sur les OSD (les volumes dans ceph), sont sous XFS.

Je ne connais pas exactement ton besoin, mais pour tes LVM , il y a
sûrement moyen d'utiliser RDB et pour l'export de fichier brut à la NFS,
y a cephFS.

Dernier point implicite, ceph est scalable, je crois que c'est le besoin
initial chez toi.

Félix.

Le 21/03/2017 à 11:42, Pierre Malard a écrit :
> Bonjour,
>
> J’ai repris un lourd dossier de l’administration de serveurs
> géographiques pour notre UMR. Ce projet n’a pas de buts lucratifs et
> est principalement ouvert à la recherche et aux collectivités.
> Le système repose sur un SAN Dell de 250 To pour l’instant (PowerVault
> MD3860f) raccordé à une lame Dell (PowerEdge R620) pour offrir un
> service NAS (NFS, FTP, SMB, …). Le serveur tourne sur Debian Wheezy et
> la gestion NAS est couverte par « openMediaVault ». Les systèmes de
> fichiers sont situés sur des volumes logiques (LVM) et formatés en
> Ext4 dont la limité de volume affichée en taille est de 1 Eio (1024
> Tio) (https://fr.wikipedia.org/wiki/Ext4).
> Nous avons des volumes de 50 To et j’ai eu besoin d’agrandir l’un de
> ceux-ci. Malheur à moi car autant il semble que les commandes de
> création de volume physique (pv…), de volumes logiques (lv…) et de
> création de système de fichiers fonctionne, autant la commande
> d’agrandissement du système de fichiers (« resize2fs ») ne fonctionne
> pas et me sort un « resize2fs: New size too large to be expressed in
> 32 bits » très désagréable.
> En cherchant, en suivant le post
> (http://permalink.gmane.org/gmane.comp.file-systems.ext4/19565), j’ai
> pu constater que mon fichier « /etc/mke2fs.conf » contenait bien la
> référence « auto_64-bit_support = 1 » qui semble limiter les
> commandes « e2fsprogs ». Mais selon le blog de Ronny
> Egners « 
> http://blog.ronnyegner-consulting.de/2011/08/18/ext4-and-the-16-tb-limit-now-solved/«
>  il est clairement écrit que l’agrandissement au delà des fatidiques
> 16 To est impossible.
>
> Tous ces échanges datant de 2013 et aucune modification n’ayant été
> apportée depuis sur nos distributions j’en déduis que le problème est
> peut être inhérent au système et difficilement solvable. Ayant besoin
> de cet espace, de beaucoup plus d’espace à l’avenir (on pense au Po),
> je me dis qu’il faudrait peut-être changer notre fusil d’épaule et
> rechercher des solutions de systèmes de fichiers autres; ou même de
> méta-systèmes de fichiers regroupant plusieurs FS. 
>
> J’ai lu que BtrFS semblait se présenter comme le « successeur » de
> ext4 et proposait un redimensionnement à chaud en complément du
> gestionnaire de volumes logiques de Linux. Il permettrait également
> l’agrégat de préifériques et la gestion de « snapshots »
> (https://fr.wikipedia.org/wiki/Btrfs). Avez-vous une expérience dans
> ce domaine et est-ce que cela répondrait à notre besoin de gros
> volumes extensibles ?
>
> J’ai également lu un truc sur le stockage distribué avec le projet
> « GlusterFS »
> (https://www.synergeek.fr/glusterfs-3-1-stockage-distribue-redondant-pour-linux,
>  
> http://www.supinfo.com/articles/single/171-mise-place-stockage-partage-avec-glusterfs,
>  https://fr.wikipedia.org/wiki/GlusterFS)
> qui pourrait nous permettre de distribuer notre stockage. Idem,
> avez-vous de l’expérience dans ce domaine ?
>
> Merci d'avance
>
> -- 
> Pierre Malard
>
>« /L'émancipation politique doit marcher de pair avec l'émancipation/
> /sociale ou les résultats sont désastreux /»
> Romain Gary - "Les racines du ciel"
>|\  _,,,---,,_
>/,`.-'`'-.  ;-;;,_
>   |,4-  ) )-,_. ,\ (  `'-'
>  '---''(_/--'  `-'\_)   πr
>
> perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  )
> )-,_. ,\ (  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_):
> 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
> - --> Ce message n’engage que son auteur <--
>

-- 
Félix Defrance
PGP: 0x0F04DC57



signature.asc
Description: OpenPGP digital signature