Zend FR

Ces serveurs tournent sous quoi ?

Si ce sont des systèmes UNIX, tu peux monter un répertoire distant par SSH.
Tu as ton serveur de stockage avec un accès SSH, sur le serveur de ton API, tu montes un répertoire distant, par exemple :

sshfs toto@le-serveur-distant.org:/repertoire/des/donnees /repertoire/locale

Ton API peut travailler dans "/repertoire/locale" comme si c'était un répertoire physique, sauf qu'aucune donnée n'est écrite sur le serveur de ton API.

Il existe aussi "finefs" écrit en PHP qui permet la réplication de données, mais je ne pense pas que ce soit adapté à ton cas car les données restent en locale.

Ensuite, tout dépend des contraintes que tu as. Par exemple, si tu n'as pas d'accès SSH, s'il est obligatoire que ce soit ton API qui envoie les données vers le serveur de stockage, etc. cela fou ma solution en l'air

Mais si t'en as plusieurs ? Ce qui arrivera sans doute.

Dans quel but exactement ?
1- Répartition de charge ?
2- Augmentation du stockage ?
3- Duplication de données en cas de crash ?

Parce que sinon les solutions diffères.
Par exemple, pour le 3, FineFS serait idéal.
Si c'est pour augmenter la taille du stockage, tu pourrai utiliser un seul serveur et y mettre une partition LVM, ce qui permet de redimensionner des partitions à chaud et sur plusieurs disques.
Pour la répartition de charge, je n'ai pas d'idée ^^

Je ne m'y connais pas vraiment, je te propose ce que j'ai pu lire via mes fluxs RSS, je n'ai jamais exploité ces solutions.

Je pense à l'augmentation du stockage. La duplication c'est encore autre chose

Si on prend un site comme facebook par ex. qui doit stocker des milliards de photos, que se passe-t'il au moment de l'upload ?

Je me demande si les photos sont uploadées sur un serveur puis ensuite déplacées ou si elles sont directement uploadées là où il faut. Dans tous les cas elles sont accessibles immédiatement après l'upload.

Dans le cas où elle sont déplacées par la suite, il faudrait que la routine qui les déplace accède à la base et mette à jour un champ contenant l'url du fichier.

Mais il existe sans doute des techniques réseau pour gérer tout ça, et autant j'adore l'archi et la prog, mais en réseau je suis un pauvre pégu (sauf truc de base sur linux quoi).


A+ benjamin.

Je pense que les serveurs de stockage reçoivent le fichier "final", c'est-à-dire après tout traitement (redimensionnement, etc.).
Ensuite, ton API peux décider où sera stocké le fichier. Dans ce cas, il faut garder une trace du chemin, et donc sans doute un champ dans ta BDD avec une information (img2, img2.ndd.com, etc. la plus pratique/cohérente pour toi).
L'API envoie ensuite ce fichier sur le bon serveur.

Si on prend le solution du montage SSH, tu pourrai avoir des répertoires img1, img2 (en correspondance de tes sous-domaines) en locale où tu monterai les répertoires distants des deux machines. Ton API n'a plus qu'à stocker le fichier dans l'un de ces deux répertoires et enregistrer le nom en BDD.
Ensuite, lors de l'affichage, ton API n'a plus qu'à indiquer le nom du sous-domaine de la BDD suivit du domaine ($nom.ndd.com/$fichier en résumé). Le navigateur va se connecter sur le serveur intéressé.

Par contre dans ce cas, tes serveurs de stockage deviennent des mini-serveurs web.
Si tu veux les garder strictement en tant que serveur de stockage et rien d'autre, alors c'est le serveur de ton API qui doit récupérer le fichier demandé et le restitué au client, chemin inverse de l'upload.

Dernière modification par Blount (03-02-2010 17:25:01)

Hum, il reste quand même un truc qui m'échappe

L'API ne peut pas (et ne doit pas) gérer l'upload, on est d'accord ? Il y a forcément un "front" entre l'API est l'utilisateur, que ce soient des controlleurs ou des webservices.

L'API ne peut pas non plus connaitre la disponibilités des serveurs, et ne devrait pas s'en soucier.

Ça voudrait dire que le script qui réceptionne le fichier, renvoie l'url, mais aussi l'uniqid de l'image.

En fait à part ce processus :
- upload via un script en dehors de l'api, par ex. upload.ndd.com
- le script renvoie en sorti : le serveur qui a reçu le fichier et l'id du fichier (par ex. img1 et 9b63a4cb.jpg)
- le front invoque l'API en lui passant les infos qu'il a reçu
- l'API après l'ajout dans la persistance envoie une requête à je ne sais pas qui avec l'uniqd du fichier temporaire et le nouveau nom du fichier calculé avec l'ID en BDD pour demander le déplacement du fichier.

Imaginons que tous les serveurs ne sont pas sur le même réseau hein

Comment éviter un double transfert, et où interviendrait "nfs" là dedans ?

Il y a vraiment un truc que j'arrive pas à voir.


A+ benjamin.

Ha, là je comprend mieux.

Donc, si j'ai bien pigé, peu importe où le fichier est uploadé c'est comme si c'était un seul et unique disque dur.

Du coup, je peux tout gérer au même endroit, puisque les copies sont gérées par le contrôleur et n'affecte pas les ressources du serveur d'application.

Donc pendant le dév. il faut faire comme si on avait une seule et unique machine, pas besoin de se poser la question.


Tout faux ?

Merci pour l'info !

A+ benjamin.

En fait, ce qui me turlupine le plus c'est que je suis une bite en réseau, nous n'avons pas encore planché sur ces problèmes là, au moment voulu nous ferons appels à des pro.

Mais en attendant quoi ? Je crée un dossier "store" au même niveau que mon application web, et je me pose pas la question ?


A+ benjamin.

Salut,

Vite faite en passant, intéressant : voilà comment facebook gère les photos.


A+ benjamin.