Stocker des images sur un autre domaine

11 réponses

Auteur	Message
PyRoFlo \| Modérateur Inscrit le : 09/05/2005	# Le 18/08/2008 à 03:45 Bonjour, Quelle méthode appliquez-vous pour stocker tous les fichiers statiques envoyés par vos visiteurs (images, petites vidéos...) via votre site www.example.com (serveur A) vers un espace dédié au stockage uniquement (serveur B) du style static.example.com ou carrément www.example-static.com peu importe ? Perso je vois 4 solutions : 1) Upload HTTP sur serveur A puis transfert FTP vers serveur B. L'inconvénient c'est que le temps de chargement du script d'upload devient plus long pour le visiteur. Mais au moins c'est du temps réel. 2) Uploader tout simplement le fichier directement sur serveur B. Cela implique l'installation d'un langage côté serveur, donc c'est moyen pour une machine dédié au stockage. 3) Faire un montage réseau genre NFS avec un VPN. Je trouve ça bien trop lourd. 4) Enfin, stocker les images en base de données sur serveur A le temps qu'un script en cron envoie par FTP le fichier correspondant sur serveur B. Bof bof mais au moins c'est plus rapide pour le visiteur et c'est presque du temps réel. Et vous, vous faites comment ? Ils en parlent chez OVH... Feu d'artifice Paris
mirage \| Vincent Modérateur Inscrit le : 04/05/2005	# Le 18/08/2008 à 08:21 PyRoFlo a dit : 1) Upload HTTP sur serveur A puis transfert FTP vers serveur B. L'inconvénient c'est que le temps de chargement du script d'upload devient plus long pour le visiteur. Mais au moins c'est du temps réel. Sur Pictaero c'est la méthode que j'utilise pour plusieurs raisons : - si le serveur de données tombe l'upload reste fonctionnel - pas envie d'installer un PHP sur le serveur de données pour les retraitements à faire sur les photos (watermark, redimensionnement, etc.) Sur la prochaine refonte, je pense changer de principe pour la deuxième solution. A priori, c'est ce que Dailymotion fait (à voir la tronche des URL d'envoi d'un formulaire de soumission) et ça me semble pas mal dans la mesure où ça me permettra de décharger la charge (minime, certes) de retraitement sur un serveur qui ne fait rien d'autre que du stockage et de l'Apache/lighttpd. Ca permettrait aussi d'enlever le serveur FTP, j'ai pas trop confiance en ces trucs là
nayluge \| Cyril Membre Inscrit le : 09/01/2008	# Le 18/08/2008 à 09:16 J'utilise actuellement la solution 4 pour conserver les données et pouvoir récupérer en cas de crash
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 18/08/2008 à 09:48 Perso ce serait upload HTTP sur le serveur principal, le script d'upload fait un "touch" d'un fichier spécifique, ce qui déclenche un cron (configuré toutes les minutes) qui fait ensuite un rsync vers la/les serveur(s) de stockage. L'inconvénient est le retard de quelques dizaines de secondes, mais il y a toujours moyen de configurer une image "temporaire". daevel : infogérance et conseil \|\| moi
Zalex14 \| Alexandre Modérateur Inscrit le : 09/05/2005	# Le 18/08/2008 à 09:51 4) pour moi, avec une seule synchro, la nuit. En attendant la synchro les nouvelles images sont chargées du serveur A, dès la date/heure de la synchro passées elles sont chargées de B. Dans la solution 1, si 10 utilisateurs postent des images en même temps, vous faites 10 connexions FTP ? Et si l'utilisateur supprime une image, vous faites aussi une connexion FTP pour la supprimer de B ? La solution n'est elle alors pas pire que le remède (sachant que ça arrive forcément aux heures de pointe, là où on a le plus besoin des ressources de son serveur). Mieux vaut s'attendre au prévisible que d'être surpris par l'inattendu.
krucial \| Jean Christophe Administrateur Inscrit le : 09/03/2005	# Le 18/08/2008 à 10:38 Moi je stocke l'image en bdd et un cron sur le serveur image traite les fichiers en attente toutes les minutes. Je stocke aussi en BDD les dermandes de suppression. Je pense que c'est le plus simple et que ca marche. Si le serveur image est mort, les demande sont en attente dans la BDD et seront executées des que celui ci sera de nouveau up. 1) Upload HTTP sur serveur A puis transfert FTP vers serveur B. L'inconvénient c'est que le temps de chargement du script d'upload devient plus long pour le visiteur. Mais au moins c'est du temps réel. --> Cela implique que tu controles si ton serveur B fonctionne bien avant de faire ton upload. 4) Enfin, stocker les images en base de données sur serveur A le temps qu'un script en cron envoie par FTP le fichier correspondant sur serveur B. Bof bof mais au moins c'est plus rapide pour le visiteur et c'est presque du temps réel. --> Pq ca serait pas le serveur B qui executerai la cron ? JC - Mes sites \| Affiliation devis travaux \| Cotes voitures anciennes
mirage \| Vincent Modérateur Inscrit le : 04/05/2005	# Le 18/08/2008 à 10:48 Zalex14 a dit : Dans la solution 1, si 10 utilisateurs postent des images en même temps, vous faites 10 connexions FTP ? Et si l'utilisateur supprime une image, vous faites aussi une connexion FTP pour la supprimer de B ? Dans mon cas, l'image est stockée temporairement sur A. Un cron se lance pour faire le traitement et envoyer le fichier. C'est finalement un mix entre la solution 1 et 4, sachant que c'est quasi instantané (sauf quand B tombe, bien sûr).
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 18/08/2008 à 11:43 Je vois que tout le monde externalise ses images J'utilise 2 techniques : 1 - envoi par ftp en temps réel vers B depuis A 2 - traitement cron journalier d'envoi vers B. Un flag dans la table des images indique si l'image est sur B ou seulement sur A Le principe est utile pour réduire la charge sur A et le nombre de slots apache utilisés. Reste tout de même un probleme que je n'ai pas résolu. Si B tombe (ce qui arrive puisque B est un mutu XXL ovh), les images sont inaccessibles. Rien de critique, il s'agit juste de vignettes en général. Vous avez prévu un miroir ? Si oui, comment est-ce géré ? Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
caaptusss \| Jérémy Membre Inscrit le : 25/09/2007	# Le 18/08/2008 à 11:51 Pour un miroir, rien de mieux qu'un Rsync en cron toutes les 12 ou 24h. FirstHeberg.com
Zalex14 \| Alexandre Modérateur Inscrit le : 09/05/2005	# Le 18/08/2008 à 12:16 devtribu a dit : Le principe est utile pour réduire la charge sur A et le nombre de slots apache utilisés. Reste tout de même un probleme que je n'ai pas résolu. Si B tombe (ce qui arrive puisque B est un mutu XXL ovh), les images sont inaccessibles. Rien de critique, il s'agit juste de vignettes en général. Vous avez prévu un miroir ? Si oui, comment est-ce géré ? Pour les images de mamiss : Toutes les images restent en local (A), une synchro complète est effectuée sur B la nuit, tous les x jours. Deux constantes : le chemin des images en local (A) et celui en distant (B). Dans les pages, lors de la création du chemin de l'image, si celle si a une date de dépot < (date du jour - fréquence de la synchro) alors le chemin utilisé est $chemin_distant sinon $chemin_local. En cas de panne de B : il me suffit de donner à $chemin_distant la valeur de $chemin_local. On même pouvoir le basculer automatiquement si B est HS ou trop lent. En gros j'ai 10% des images chargées en local (les récentes) et 90% en distant, avec la possibilité de repasser en local en quelques secondes en cas de pépins avec le serveur distant. Mieux vaut s'attendre au prévisible que d'être surpris par l'inattendu.
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 18/08/2008 à 12:29 Oui Zalex, j'ai aussi le meme principe : les images en double sur A et sur B avec un parametre dans la table param_generaux des chemins Mais ce que je voudrais c'est automatiser la transition en cas de panne. En fait, sur les mutu OVH, ca ne previent pas et ca dure rarement tres longtemps. Donc si je peux trouver un moyen simple et peu gourmand de détecter la panne, je bascule le param en mode "miroir" jusqu'au retour à la normale. J'imagine un cron qui va loader une url de controle sur B. Mais y a peut etre des modules linux qui sont plus efficaces ? Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
PyRoFlo \| Florent Modérateur Inscrit le : 09/05/2005	# Le 18/08/2008 à 12:49 Boola dit : Perso ce serait upload HTTP sur le serveur principal, le script d'upload fait un "touch" d'un fichier spécifique, ce qui déclenche un cron (configuré toutes les minutes) qui fait ensuite un rsync vers la/les serveur(s) de stockage. L'inconvénient est le retard de quelques dizaines de secondes, mais il y a toujours moyen de configurer une image "temporaire". J'aime le principe mais utiliser rsync implique avoir la main sur le serveur de stockage. Quand c'est un gros mutu comme fait devtribu ce n'est pas possible. krucial a dit : 4) Enfin, stocker les images en base de données sur serveur A le temps qu'un script en cron envoie par FTP le fichier correspondant sur serveur B. Bof bof mais au moins c'est plus rapide pour le visiteur et c'est presque du temps réel. --> Pq ca serait pas le serveur B qui executerai la cron ? Parce que ça m'embêterait d'installer quelque chose (PHP par exemple) pour si peu sur un serveur de stockage / backup. Je pencherais plus vers la solution de Zalex ou bien un mélange de 1) & 4) comme mirage. Feu d'artifice Paris

Auteur

Message

Inscrit le : 09/05/2005

# Le 18/08/2008 à 03:45

Bonjour,

Quelle méthode appliquez-vous pour stocker tous les fichiers statiques envoyés par vos visiteurs (images, petites vidéos...) via votre site www.example.com (serveur A) vers un espace dédié au stockage uniquement (serveur B) du style static.example.com ou carrément www.example-static.com peu importe ?

Perso je vois 4 solutions :

1) Upload HTTP sur serveur A puis transfert FTP vers serveur B.
L'inconvénient c'est que le temps de chargement du script d'upload devient plus long pour le visiteur. Mais au moins c'est du temps réel.

2) Uploader tout simplement le fichier directement sur serveur B. Cela implique l'installation d'un langage côté serveur, donc c'est moyen pour une machine dédié au stockage.

3) Faire un montage réseau genre NFS avec un VPN. Je trouve ça bien trop lourd.

4) Enfin, stocker les images en base de données sur serveur A le temps qu'un script en cron envoie par FTP le fichier correspondant sur serveur B. Bof bof mais au moins c'est plus rapide pour le visiteur et c'est presque du temps réel.

Et vous, vous faites comment ?

Ils en parlent chez OVH...

Feu d'artifice Paris

mirage | Vincent
Modérateur

Inscrit le : 04/05/2005

# Le 18/08/2008 à 08:21

PyRoFlo a dit :
1) Upload HTTP sur serveur A puis transfert FTP vers serveur B.
L'inconvénient c'est que le temps de chargement du script d'upload devient plus long pour le visiteur. Mais au moins c'est du temps réel.

Sur Pictaero c'est la méthode que j'utilise pour plusieurs raisons :
- si le serveur de données tombe l'upload reste fonctionnel
- pas envie d'installer un PHP sur le serveur de données pour les retraitements à faire sur les photos (watermark, redimensionnement, etc.)

Sur la prochaine refonte, je pense changer de principe pour la deuxième solution. A priori, c'est ce que Dailymotion fait (à voir la tronche des URL d'envoi d'un formulaire de soumission) et ça me semble pas mal dans la mesure où ça me permettra de décharger la charge (minime, certes) de retraitement sur un serveur qui ne fait rien d'autre que du stockage et de l'Apache/lighttpd. Ca permettrait aussi d'enlever le serveur FTP, j'ai pas trop confiance en ces trucs là

nayluge | Cyril
Membre

Inscrit le : 09/01/2008

# Le 18/08/2008 à 09:16

J'utilise actuellement la solution 4 pour conserver les données et pouvoir récupérer en cas de crash

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 18/08/2008 à 09:48

Perso ce serait upload HTTP sur le serveur principal, le script d'upload fait un "touch" d'un fichier spécifique, ce qui déclenche un cron (configuré toutes les minutes) qui fait ensuite un rsync vers la/les serveur(s) de stockage.
L'inconvénient est le retard de quelques dizaines de secondes, mais il y a toujours moyen de configurer une image "temporaire".

daevel : infogérance et conseil || moi

Zalex14 | Alexandre
Modérateur

Inscrit le : 09/05/2005

# Le 18/08/2008 à 09:51

4) pour moi, avec une seule synchro, la nuit.

En attendant la synchro les nouvelles images sont chargées du serveur A, dès la date/heure de la synchro passées elles sont chargées de B.

Dans la solution 1, si 10 utilisateurs postent des images en même temps, vous faites 10 connexions FTP ? Et si l'utilisateur supprime une image, vous faites aussi une connexion FTP pour la supprimer de B ?
La solution n'est elle alors pas pire que le remède (sachant que ça arrive forcément aux heures de pointe, là où on a le plus besoin des ressources de son serveur).

Mieux vaut s'attendre au prévisible que d'être surpris par l'inattendu.

krucial | Jean Christophe
Administrateur

Inscrit le : 09/03/2005

# Le 18/08/2008 à 10:38

Moi je stocke l'image en bdd et un cron sur le serveur image traite les fichiers en attente toutes les minutes. Je stocke aussi en BDD les dermandes de suppression. Je pense que c'est le plus simple et que ca marche. Si le serveur image est mort, les demande sont en attente dans la BDD et seront executées des que celui ci sera de nouveau up.

1) Upload HTTP sur serveur A puis transfert FTP vers serveur B.
L'inconvénient c'est que le temps de chargement du script d'upload devient plus long pour le visiteur. Mais au moins c'est du temps réel.
--> Cela implique que tu controles si ton serveur B fonctionne bien avant de faire ton upload.

4) Enfin, stocker les images en base de données sur serveur A le temps qu'un script en cron envoie par FTP le fichier correspondant sur serveur B. Bof bof mais au moins c'est plus rapide pour le visiteur et c'est presque du temps réel.
--> Pq ca serait pas le serveur B qui executerai la cron ?

JC - Mes sites | Affiliation devis travaux | Cotes voitures anciennes

mirage | Vincent
Modérateur

Inscrit le : 04/05/2005

# Le 18/08/2008 à 10:48

Zalex14 a dit :
Dans la solution 1, si 10 utilisateurs postent des images en même temps, vous faites 10 connexions FTP ? Et si l'utilisateur supprime une image, vous faites aussi une connexion FTP pour la supprimer de B ?

Dans mon cas, l'image est stockée temporairement sur A. Un cron se lance pour faire le traitement et envoyer le fichier. C'est finalement un mix entre la solution 1 et 4, sachant que c'est quasi instantané (sauf quand B tombe, bien sûr).

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 18/08/2008 à 11:43

Je vois que tout le monde externalise ses images
J'utilise 2 techniques :
1 - envoi par ftp en temps réel vers B depuis A
2 - traitement cron journalier d'envoi vers B. Un flag dans la table des images indique si l'image est sur B ou seulement sur A

Le principe est utile pour réduire la charge sur A et le nombre de slots apache utilisés.
Reste tout de même un probleme que je n'ai pas résolu. Si B tombe (ce qui arrive puisque B est un mutu XXL ovh), les images sont inaccessibles. Rien de critique, il s'agit juste de vignettes en général.
Vous avez prévu un miroir ? Si oui, comment est-ce géré ?

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

caaptusss | Jérémy
Membre

Inscrit le : 25/09/2007

# Le 18/08/2008 à 11:51

Pour un miroir, rien de mieux qu'un Rsync en cron toutes les 12 ou 24h.

FirstHeberg.com

Zalex14 | Alexandre
Modérateur

Inscrit le : 09/05/2005

# Le 18/08/2008 à 12:16

devtribu a dit :

Le principe est utile pour réduire la charge sur A et le nombre de slots apache utilisés.
Reste tout de même un probleme que je n'ai pas résolu. Si B tombe (ce qui arrive puisque B est un mutu XXL ovh), les images sont inaccessibles. Rien de critique, il s'agit juste de vignettes en général.
Vous avez prévu un miroir ? Si oui, comment est-ce géré ?

Pour les images de mamiss :

Toutes les images restent en local (A), une synchro complète est effectuée sur B la nuit, tous les x jours.

Deux constantes :
le chemin des images en local (A) et celui en distant (B).

Dans les pages, lors de la création du chemin de l'image, si celle si a une date de dépot < (date du jour - fréquence de la synchro) alors le chemin utilisé est $chemin_distant sinon $chemin_local.

En cas de panne de B : il me suffit de donner à $chemin_distant la valeur de $chemin_local. On même pouvoir le basculer automatiquement si B est HS ou trop lent.

En gros j'ai 10% des images chargées en local (les récentes) et 90% en distant, avec la possibilité de repasser en local en quelques secondes en cas de pépins avec le serveur distant.

Mieux vaut s'attendre au prévisible que d'être surpris par l'inattendu.

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 18/08/2008 à 12:29

Oui Zalex, j'ai aussi le meme principe : les images en double sur A et sur B avec un parametre dans la table param_generaux des chemins

Mais ce que je voudrais c'est automatiser la transition en cas de panne. En fait, sur les mutu OVH, ca ne previent pas et ca dure rarement tres longtemps. Donc si je peux trouver un moyen simple et peu gourmand de détecter la panne, je bascule le param en mode "miroir" jusqu'au retour à la normale.
J'imagine un cron qui va loader une url de controle sur B.
Mais y a peut etre des modules linux qui sont plus efficaces ?

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

PyRoFlo | Florent
Modérateur

Inscrit le : 09/05/2005

# Le 18/08/2008 à 12:49

Boola dit :
Perso ce serait upload HTTP sur le serveur principal, le script d'upload fait un "touch" d'un fichier spécifique, ce qui déclenche un cron (configuré toutes les minutes) qui fait ensuite un rsync vers la/les serveur(s) de stockage.
L'inconvénient est le retard de quelques dizaines de secondes, mais il y a toujours moyen de configurer une image "temporaire".

J'aime le principe mais utiliser rsync implique avoir la main sur le serveur de stockage. Quand c'est un gros mutu comme fait devtribu ce n'est pas possible.

krucial a dit :
4) Enfin, stocker les images en base de données sur serveur A le temps qu'un script en cron envoie par FTP le fichier correspondant sur serveur B. Bof bof mais au moins c'est plus rapide pour le visiteur et c'est presque du temps réel.
--> Pq ca serait pas le serveur B qui executerai la cron ?

Parce que ça m'embêterait d'installer quelque chose (PHP par exemple) pour si peu sur un serveur de stockage / backup.

Je pencherais plus vers la solution de Zalex ou bien un mélange de 1) & 4) comme mirage.

Feu d'artifice Paris

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.