Existe-il une solution de HSM/Tiered storage sous Debian ?

karine a écrit :

Voici ma problématique:
J'ai un volume de données bureautique en très forte augmentation chaque année. Ce volume est stocké sur des serveurs Debian très haute performance.
Pour limitER cette explosion de la consommation, je mesure via un script la taille de certains répertoires stratégiques chaque mois.

* Un utilisateur, c'est comme un clébard: il faut le dresser correctement ;)
stocker tout et n'importe quoi ne sert à rien, sinon à avoir des difficultés à
retrouver le bon document le moment venu.
C'est à toi de faire un audit et de poser les bonnes questions pour obtenir les
bonnes réponses et faire baisser l'encombrement des partoches (et tu seras ptêt
surprise...)

* Il existe différents softs de gestion documentaire qui permettent la ventilation
intelligente des docs (v. google pour ça), l'affichage de digests, la compression,
l'indexation textuelle, etc

* Pour la partie à archiver, perso pour faire simple je ferais un tri régulier
à partir de 'atime' (access time) et, au-delà d'un certain temps (à déterminer
par ton audit), un autre script basculerait les fichiers en question sur svr2.

À l'évidence ton PB est à reprendre à la racine avant toute manip ou restructuration:
la plupart des gens qui n'ont pas été brieffés se contentant de tout sauvegarder
sans se poser de questions.

--
Emacs, n.:
A slow-moving parody of a text editor.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org

Bonjour et merci pour cette réponse ... inattendu.

Le Saturday 09 January 2010 21:23:29, vous avez écrit :

karine a écrit :
> Voici ma problématique:
> J'ai un volume de données bureautique en très forte augmentat ion chaque
> année. Ce volume est stocké sur des serveurs Debian très haute
> performance. Pour limitER cette explosion de la consommation, je mesure
> via un script la taille de certains répertoires stratégiques chaque mois.

* Un utilisateur, c'est comme un clébard: il faut le dresser correct ement
;) stocker tout et n'importe quoi ne sert à rien, sinon à avoir des
difficultés à retrouver le bon document le moment venu.
C'est à toi de faire un audit et de poser les bonnes questions pour
obtenir les bonnes réponses et faire baisser l'encombrement des part oches
(et tu seras ptêt surprise...)

Tout à fait d'accord avec toi. Après deux ans de fonctionnement j 'ai dressé un bilan accablant.
Précédement, nous utilisions un autre système "Netware". Cel ui-ci permettait de définir une "hard-limit" au niveau d'un réper toire. Pendant 8 ans, le
volume de donnée n'a augmenté que de 2Go par an et par site en mo yenne. Cette gestion ne demandait que très peu de temps de gestion. En effet, un
service ayant saturé son répertoire ne plantait pas les autres et procédait lui-même à son propre déblocage en purgeant les données inutles. Si après
purge il ne s'en sortait pas, Il nous contactait pour que nous procédi ons ensemble à de l'archivage. Bref, méthode qui s'est rév élé extrêment
efficace car nous n'étions que très rarement sollicité tout en atteignant un résultat pertinent. (Voire définition de l'effic ience ... ma
philosophie !!)

Depuis Samba 3 il y a deux ans, les vannes sont ouvertes. J'ai scripté un rapport mensuel pour me dresser une analyse des évolutions par r épertoire +
alarme suivant une taille limite ou une évolution (%) trop importante par rapport au mois précédent. Ensuite je dédie au moins 2 j ours par mois pour
faire la chasse au gaspillage. L'essentiel étant de la relance par mai l. Et oui, les utilisateurs ne sont plus bloqués ... ma demande est ne ttement
moins contraingnante et dissuasive qu'avec des quotas "hard-limit" !. Bref, d'un point de vue coût TCO ça n'a rien à voir. Là ou n ous traitions cette
tâche en temps masqué, aujourd'hui c'est devenu un temps non nà ©gligeable de travail et les disques sont pleins (+ 30Go par an par site en moyenne !)

Je te confirme qu'un audit et une TRES FOTRE SENSIBILISATION ont étà © réalisé... L'analyse des filesystems (visualisation graphique pour chercher les
gros fichiers, recherche par date ...etc). L'audit m'a pris plus d'une sema ine en cette fin d'année. C'est justement suite à cet audit que j 'ai
décidé de proposer à ma direction de retouver un fonctionnem ent de maitrise des espaces disques performant comme nous l'avions deux ans au paravant.

Je te rejoint donc sur ta préconisation, et c'est justement parce que les comportements des utilisateurs finaux ne repondent par à mes atten tes (et
j'ai autre chose à faire que de relancer tout le temps par mail et fai re l'archivage à leur place) que je recherche une solution capable de soulager
cette gestion et de renouer avec de la performance: quota + cette notion de stockage répartie qui est le sujet de mon mail.

* Il existe différents softs de gestion documentaire qui permettent la
ventilation intelligente des docs (v. google pour ça), l'affichage de
digests, la compression, l'indexation textuelle, etc

Peux-tu me donner des liens, c'est justement cela que je recherche, cette n otion de "ventliation intelligente". Peux-tu me donner des noms de paquets
debian ?
!! ;-) Pour la compression, je l'intégre effectivement dans mon é tude. merci.
L'affichage de digest, même avec google, je ne vois pas de quoi il s'a git. Peux-tu développer.

* Pour la partie à archiver, perso pour faire simple je ferais un tri
régulier à partir de 'atime' (access time) et, au-delà d'u n certain temps
(à déterminer par ton audit), un autre script basculerait les f ichiers en
question sur svr2.

!! ;-) Bien vu pour l'access time, je l'intègre également. Il fau t que je regarde si les sauvegardes n'actualisent pas cette donnée.

À l'évidence ton PB est à reprendre à la racine avant toute manip ou
restructuration:

Je suis à la racine ... je cherche justement les différentes opti ons sans en dénigrer l'une par rapport à l'autre. Ici, je recherc he des logiiels
Debian gérant cette notion de HSM ou de "ventilation intelligente" com me tu l'appel.

la plupart des gens qui n'ont pas été brieffés se
contentant de tout sauvegarder sans se poser de questions.

Tout à fait d'accord. Pour le moment (mais j'insiste je ne suis qu'à   l'étape d'assimilation de piste !), l'application de quota par r épertoire me
semble la solution qui permettra aux utilisateurs de se RE-poser ces fameus es questions comme dans le système précédent.

En tous cas merci de ta réponse même si à priori Debian ne p ropose rien concernant ma piste HSM. (je précise, merci de ne pas dà ©velopper la partie
quota, sur ce point j'ai suffisement d'information)

A ta dispo pour continuer la discussion.

Bonne soirée à tous.
Salokine.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org

Salokine Terata a écrit :
...

Depuis Samba 3 il y a deux ans, les vannes sont ouvertes. J'ai scripté un rapport mensuel pour me dresser une analyse des évolutions par répertoire +
alarme suivant une taille limite ou une évolution (%) trop importante par rapport au mois précédent. Ensuite je dédie au moins 2 jours par mois pour
faire la chasse au gaspillage. L'essentiel étant de la relance par mail. Et oui, les utilisateurs ne sont plus bloqués ... ma demande est nettement
moins contraingnante et dissuasive qu'avec des quotas "hard-limit" !. Bref, d'un point de vue coût TCO ça n'a rien à voir. Là ou nous traitions cette
tâche en temps masqué, aujourd'hui c'est devenu un temps non négligeable de travail et les disques sont pleins (+ 30Go par an par site en moyenne !)

Non, ça ne marche pas: c'est comme réclamé un impayé par fax... Par contre si tu
appelles le clients et que tu lui explique gentiment qu'il a 48H pour payer
sinon il se retrouve au tribunal, les sous rentrent bcp mieux.

...

Je te rejoint donc sur ta préconisation, et c'est justement parce que les comportements des utilisateurs finaux ne repondent par à mes attentes (et
j'ai autre chose à faire que de relancer tout le temps par mail et faire l'archivage à leur place) que je recherche une solution capable de soulager
cette gestion et de renouer avec de la performance: quota + cette notion de stockage répartie qui est le sujet de mon mail.

* Il existe différents softs de gestion documentaire qui permettent la
ventilation intelligente des docs (v. google pour ça), l'affichage de
digests, la compression, l'indexation textuelle, etc

Peux-tu me donner des liens, c'est justement cela que je recherche, cette notion de "ventliation intelligente". Peux-tu me donner des noms de paquets
debian ?

Pas de packages Debian que je sache, mais Alfresco ressort parmi les plus cités

!! ;-) Pour la compression, je l'intégre effectivement dans mon étude. merci.
L'affichage de digest, même avec google, je ne vois pas de quoi il s'agit. Peux-tu développer.

Un peu la même chose que gogol fait: l'affichage d'un condensé du texte original
lors de la recherche (mais ça n'est pas un point bloquant.)

* Pour la partie à archiver, perso pour faire simple je ferais un tri
régulier à partir de 'atime' (access time) et, au-delà d'un certain temps
(à déterminer par ton audit), un autre script basculerait les fichiers en
question sur svr2.

!! ;-) Bien vu pour l'access time, je l'intègre également. Il faut que je regarde si les sauvegardes n'actualisent pas cette donnée.

Je me suis trompé: atime est effectivement modifié à _chaque_ accès (quel qu'il soit),
donc ton ami est plutôt mtime ou ctime (V. http://www.brandonhutchinson.com/ctime_atime_mtime.html )

À l'évidence ton PB est à reprendre à la racine avant toute manip ou
restructuration:

Je suis à la racine ... je cherche justement les différentes options sans en dénigrer l'une par rapport à l'autre. Ici, je recherche des logiiels
Debian gérant cette notion de HSM ou de "ventilation intelligente" comme tu l'appel.

Ben intelligente n'est pas vraiment le mot, disons plutôt 'orientée', CàD
découpée en workflows spécifiques à l'entreprise + éventuellement en cadences
si les projets sont exécutés par strates.
J'ai testé J-DOC, agréable et facile, mais je doute qu'en l'état actuel des
choses il soit exploitable (pas de visualisation online des docs, juste un
téléchargement; et une visibilité limite sur les Tgros dossiers.)

la plupart des gens qui n'ont pas été brieffés se
contentant de tout sauvegarder sans se poser de questions.

Tout à fait d'accord. Pour le moment (mais j'insiste je ne suis qu'à l'étape d'assimilation de piste !), l'application de quota par répertoire me
semble la solution qui permettra aux utilisateurs de se RE-poser ces fameuses questions comme dans le système précédent.

Oui, les quotas sont une manière simple (et surtout ne nécessitant aucune
surveillance appuyée) pour faire le ménage.
D'ailleurs il n'est pas normal que l'ancienne procédure ayant fait ses preuves,
elle n'ait pas été automatiquement reconduite sur la nouvelle configuration;
ça fait partie de tes attributions de créer une échelle de notation des procs
de travail, avec revue régulière et suivi des changements/ajouts/suppressions.

Je ne pense pas qu'il existe de solution toute faite, mais par exemple l'utilisation
d'Alfredo sur les 2 svrs, avec le même setup, devrait permettre aux utilisateurs
d'archiver facilement - avec un bémol: tu risques de déplacer le PB d'un serveur
vers l'autre, donc quotas partout.

Tu peux aussi imposer une normalisation des noms de fichiers et effacer ceux qui
n'y correspondent pas (ie: <n° dossier>_<date>_<nom normalisé du doc>).

--
Bell Labs Unix -- Reach out and grep someone.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org