fichiers EC2, Mettre en ligne sur premier à volume ebs puis de passer à s3

Question

http://farm8.staticflickr.com/7020/6702134377_cf70482470_z.jpg

OK désolé pour le terrible dessin, mais il semblait une meilleure façon d'organiser mes pensées et de les transmettre. J'ai lutté pendant un certain temps avec la façon de créer un système découplable facilement adaptable pour télécharger des fichiers sur une application web sur AWS.

Le téléchargement directement vers S3 fonctionnerait sauf pour le fait que les fichiers doivent être immédiatement accessibles au téléchargeur pour la manipulation puis une fois manipulés, ils peuvent aller à s3 où ils seront servis à toutes les instances. J'ai joué avec l'idée de créer un SAN avec quelque chose comme glusterfs, puis de le télécharger directement sur celui-ci et de servir à partir de cela. Je ne l'ai pas écarté, mais de diverses sources la fiabilité de cette solution pourrait être moins qu'idéale (si quelqu'un a un meilleur aperçu sur ce que j'aimerais entendre). En tout cas je voulais formuler une solution plus "out of the box" (dans le contexte d'AWS). Donc, pour développer ce diagramme, je veux que le fichier soit téléchargé sur le système de fichiers local de l'instance vers laquelle il va, qui est un volume EBS. L'emplacement de stockage du fichier ne serait pas diffusé au public (c'est-à-dire/tmp/uploads /) L'instance pouvait toujours accéder à l'instance via une opération readfile() en PHP afin que l'utilisateur puisse la voir et la manipuler immédiatement après le téléchargement. Une fois que l'utilisateur a fini de manipuler le fichier, un message pour le déplacer vers s3 pourrait être mis en file d'attente dans SQS. Ma question est alors une fois que j'ai sauvegarder le fichier "localement" sur l'instance (qui pourrait être n'importe quelle instance due à l'équilibreur de charge), comment puis-je enregistrer sur quelle instance il se trouve (dans la DB) grâce à PHP pour lire ou déplacer le fichier va trouver ledit fichier.

Si quelqu'un ayant plus d'expérience dans ce domaine a un aperçu, je serais très reconnaissant. Merci.

Answer 1

J'ai une suggestion pour un design différent qui pourrait résoudre votre problème.

Pourquoi ne pas toujours d'abord écrire le fichier sur S3? Ensuite, copiez-le dans le système de fichiers EBS local, quel que soit le nœud sur lequel vous travaillez pendant que vous y travaillez (je ne suis pas sûr des manipulations que vous devez faire, mais j'espère que cela n'a pas d'importance). Lorsque vous avez fini de modifier le fichier, il vous suffit de l'écrire dans S3 et de le supprimer du volume EBS local. De cette manière, aucun des nœuds de votre cluster n'a besoin de savoir lequel des autres nœuds pourrait avoir le fichier car la réponse est toujours S3. Et en supprimant le fichier localement, vous obtenez une nouvelle version du fichier si un autre nœud le met à jour.

Une autre chose que vous pourriez envisager si c'est trop cher de copier le fichier à partir de S3 à chaque fois (c'est trop grand, ou vous n'aimez pas la latence). Vous pouvez activer l'affinité de session dans l'équilibreur de charge (AWS l'appelle sessions collantes). Cela peut être géré par votre propre cookie ou par l'ELB. Les demandes suivantes provenant du même navigateur arrivent maintenant au même nœud de cluster. Vérifiez simplement l'heure de modification du fichier sur le volume EBS local par rapport à la copie S3 et remplacez-la si elle est plus récente. Ensuite, vous profitez du système de fichiers EBS local pendant le traitement du fichier.

Bien sûr, il y a un tas de choses que je ne comprends pas sur votre système. Toutes mes excuses pour cela.