Stockage de 3 millions de fichiers [AIX] - Stockage/Sauvegarde - Windows & Software
Marsh Posté le 21-07-2004 à 10:30:10
Whaou...
Alors deja il faudrait vraiment que tu vois bien la difference qu'il y a entre un vg, un fs et un repertoire Parce que sinon, ca part deja tres mal.
Ensuite il faudrait effectivement etre sur de la version exacte de l'OS (AIX 4.3.3 c'est vraiment vieux... si c'est un projet qui demare maintenant et qui doit rester 3 ans, je doute qu'AIX 4.3.3 soit un choix judicieux)
Autre chose, il existe plusieurs type de systeme de fichier sous AIX, le JFS, le JFS avec large file etc.
et ensuite ce systeme de fichier a de tres nombreux parametres qui vont determiner combien tu va pouvoir mettre de fichier dedans au maximum etc.
Et je parle meme pas avant tout cela du parametrage des VGs tout aussi important...
Bref, c'est une question compliquée, a laquelle on ne peux pas repondre sans avoir vraiment toutes les donnes du probleme. Il faut donc tout savoir, quelle va etre la taille de tes fichiers, comment se passeront les sauvegardes, quelle sera la taille maximum d'un systeme de fichier, quelles sont les contraintes d'administration en terme d'ajout de volumetrie etc...
Donc voila... develope, explique tout, et ensuite on poura essayer de trouver une methode adaptée.
EDIT : tu devrai peut etre comemnce par te documenter un peu...
y a ca qui me semble bien :
http://publib-b.boulder.ibm.com/Re [...] .html?Open
Lis bien le chapitre 5, il y a des notions qui sont expliques la dedans
dont tu va avoir besoin, notament le parametrage des nbpi. Et c'est le
genre de truc ou t'a pas droit a l'erreur, parce qu'une fois que c'est
fait, tu peut pas revenir en ariere sans etre oblige de tout effacer et de tout reconstruire avec sauvegarde/resto des donnes etc.
Marsh Posté le 21-07-2004 à 10:53:45
Concernant la diff FS/VG/Rep c'est bon j'ai pigé, in gars d'IBM m'a fait petit topo.
L'OS sera finalement un AIX 5.2 (5.3 par la suite).
Taille des fichiers: 10ko à 100ko (jpeg). On espère 30ko-40ko car multiplié par 3 millions ...
Aucune idée concernant les sauvegardes, c'est pas mon pb.
Marsh Posté le 21-07-2004 à 11:07:00
Yop, j'ai edite mon post Pour les sauvegardes, si c'est un peu tob probleme quand meme... Parce que si un jour on te dit que ce que tu as fait n'est pas sauvegardable... voila quoi
En faisant le calcul rapide 100ko * 3 millions, on trouve 300 Go en gros (si je me suis pas gouré). CA fait beaucoup... tu pourai mettre tout ca dans un seul systeme de fichier (la limite vraiment maxi, absolument indepassable est de 1 To pour un systeme de fichier, mais avec pas mal de contraintes). Bref, ca doit etre possible, mais c'est gros quand meme, faudrait peut etre mieux essayer de diviser un peu.
D'un autre coté, si y a 150 sites, faire 150 systemes de fichiers, ca fait trop aussi, ce serait plus administrable.
Ce qu'il faut voir aussi, c'est comment sont utilises les donnes ensuite... est ce qu'il y a vraiment besoin que tous les fichiers d'un site soit dans le meme repertoire ou pas, est ce qu'on peut diviser ca selon la date par exemple, et deplacer les fichiers qui ont plus de 6 mois ailleur (je dis n'importe quoi hein... c'est juste des idees comme ca...)
PS : pour AIX 5.2,ca me semble bcp plus raisonable
Marsh Posté le 21-07-2004 à 11:21:43
Non ce n'est pas mon pb car je dois apporter une solution d'architecture. L'exploitation et la maintenance de la machine c'est le metier d'autres personnes.
La taille des fichiers est effectivement un pb, on essaye d'obtenir des résultat lisibles pour des fichiers de 50ko environ (150dpi, jpeg quality 20%).
Concernant la division, j'ai proposé une idée dans le 1er post:
- 1rep/fs par site
- 1 sous rep par jour (1095j sur 3 ans) par site
- les fichiers pour 1 jour dans ce dernier rep.
Marsh Posté le 21-07-2004 à 11:38:43
Citation : Non ce n'est pas mon pb car je dois apporter une solution d'architecture. L'exploitation et la maintenance de la machine c'est le metier d'autres personnes |
?? C'est dingue quand meme ce que tu dis la...
C'est justement a l'architecture de concevoir une solution qui soit exploitable et maintenable etc... si tu concoit une solution qur tu trouve genial mais qui, en pratique, est inutilisable pour X raisons, c'est toi qui mal fait ton metier, et pas le gars de la maintenance a qui on va imposer l'architecture que tu as concue...
Vraiment je trouve ta reaction bizarre...
Un peu comme si tu disai "je vais faire un vg par site, et un fs par jour etc". C'est bien decoupe, c'est tres joli techniquement, mais c'est totalement inexploitable.
Bref, comme je le disai, 150 fs ca me semble vraiment trop. donc ca c'est pas une solution. A ta place j'envisagerai deux methodes, une avec un seul gros fs (et un decoupage en repertoire comme t'a fait) mais il faut bien verifie que tu poura mettre sufisament de fichiers dedans, et la il faut faire le calcul, en partant sans doute avec un nbpi de 32768. (mais tu risque d'etre limite en nombre d'inode si tu met des petits fichiers genre 20ko).
Et dexieme methodes, avec plusieurs fs, en archivant au fur et a mesure, en fonction de l'age des fichiers par exemple... un fs tous les 3 mois par exemple, ou tous les 6 mois... Sur trois ans, voir plus, ca reste parfaitement exploitable et tu garde des systemes de fichiers avec des tailles raisonables (inferieur a 256 Go, avec un nbpi de 16384 max)
Ensuite il faut peut etre aussi se poser des question en terme de perfs... savoir sur quel type de disque exactement ca va etre mis, quel niveau de raid etc. Je pense que c'est aussi ton boulot ca... parce que si ca fonctionne, mais que c'est tellement lent qu'il faut plusieurs minutes pour acceder a un fichier, je pense que ca pourait aussi vite devenir ton probleme
Marsh Posté le 21-07-2004 à 11:56:58
En fait je suis plutot spécialisé programmation mais il arrive qu'on me refile un peu de système. Actuellement c'est de trouver la meilleur façon de stocker ces fichiers en me renseignant auprès de personnes plus compétente que moi dans ce domaine (c'est pas dur).
Ces fichiers seront par la suite utilisé par une de mes applis.
J'ai donc rencontré un collègue prestataire IBM qui a bien son avis sur la question, mais qui attend la confirmation de spécialistes AIX. J'espère avoir une réponse aujourd'hui.
J'ai noté ton idée j'en débaterais avec lui.
La rapidité est en effet un facteur essentiel de la solution à retenir.
Si ça t'interresse je posterais la solution retenue.
Marsh Posté le 21-07-2004 à 12:01:42
Oki, je croyai que t'etai architecte a la base.
En tout cas, oui je veux bien que tu poste ce que vous ferez finalement.. et la conf des VG/FS etc.
Marsh Posté le 21-07-2004 à 13:13:28
J'aurais fait dans ce cas un piètre architecte !
Je te/vous tiens au courant.
Marsh Posté le 21-07-2004 à 13:45:38
Le "vous " était destiné à la communautée HFR qui pourrait être interessé par la réponse à défaut de pouvoir répondre à la question.
Marsh Posté le 20-07-2004 à 11:52:48
Je dois pouvoir stocker 3 millions de fichiers dans un envirronnement IBM Aix 4.3 (minimum).
Sachant que les facteurs discriminant sont:
- la date (le jour) du fichier
- la provenance (120-150 sites différents)
En moyenne il faut stocker 3M de fichier sur 3 ans pour 120 à 150 sites.
Ce qui fait une moyenne à la louche de 25 fichiers/jour/site.
Je pensais à:
/Site 1
|/Jour 1
||fichier 1
||...
||fichier n
|/Jour 2
|...
|/Jour n
Quelle est la limite de stokage au sein d'un filesystem/VG (je ne connais pas vraiement la différence) ?
Quel est la meilleure solution pour stocker tout ça afin tout en gardant une vitesse d'accès optimale ?
Faut-il utiliser des "volume group" au lieu de répertoire ?
Le regroupement de fichier en archive tar est-elle un meilleure idée ?