Загрузка файлов на ec2, сначала на ebs громкость, затем на s3

Question

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

Хорошо, извините за ужасный рисунок, но это казалось лучшим способом организовать мои мысли и передать их.Некоторое время я боролся с тем, как создать оптимальную, легко масштабируемую систему для выгрузки файлов в веб-приложение на AWS.

Загрузка напрямую в S3 будет работать, за исключением того факта, что файлы должны быть мгновенно доступны загрузчику для манипуляции, а затем после манипуляции они могут перейти на s3, где они будут обслуживаться во всех экземплярах.

Я поиграл с идеей создания SAN с чем-то вроде glusterfs, затем загружать прямо в это и обслуживать из этого.Я не исключаю этого, но из разных источников надежность этого решения может быть не идеальной (если у кого-то есть лучшее понимание этого, я хотел бы услышать).В любом случае я хотел сформулировать более «готовое» (в контексте AWS) решение.

Поэтому, чтобы подробнее остановиться на этой диаграмме, я хочу, чтобы файл был загружен в локальную файловую системуНапример, это происходит на том EBS.Место хранения файла не будет предоставлено общественности (т.е. / tmp / uploads /). К нему все равно можно получить доступ через операцию readfile () в PHP, чтобы пользователь мог видеть и манипулировать им сразу после загрузки.Как только пользователь закончит манипулирование файлом, в SQS может быть поставлено в очередь сообщение о его перемещении на s3.

Мой вопрос: как только я сохраню файл «локально» на экземпляре (который может быть любым экземпляром из-за балансировки нагрузки), как я могу записать, на каком экземпляре он (в БД), чтобыпоследующие запросы через PHP на чтение или перемещение файла найдут указанный файл.

Если кто-то, имеющий больше опыта в этом, обладает некоторой проницательностью, я был бы очень благодарен.Благодарю.

Answer 1

У меня есть предложение по другому дизайну, который может решить вашу проблему.

Почему бы не всегда сначала записать файл на S3?А затем скопируйте его в локальную файловую систему EBS на том узле, на котором вы находитесь, пока работаете над ним (я не совсем уверен, какие манипуляции вам нужны, но я надеюсь, что это не имеет значения).Когда вы закончите модифицировать файл, просто запишите его обратно на S3 и удалите его с локального тома EBS.

Таким образом, ни один из узлов в вашем кластере не должен знать, какие из других могут иметьфайл, потому что ответ всегда в S3.И, удалив файл локально, вы получите новую версию файла, если другой узел обновит его.

Еще одна вещь, которую вы могли бы рассмотреть, если слишком дорого каждый раз копировать файл из S3 (он слишком большой иливам не нравится латентность)Вы можете включить сходство сеансов в балансировщике нагрузки (AWS называет это липкие сеансы ).Это может быть обработано вашим собственным файлом cookie или ELB.Теперь последующие запросы от того же браузера поступают на тот же узел кластера.Просто сравните время изменения файла на локальном томе EBS с копией S3 и замените его, если оно более новое.Тогда вы сможете воспользоваться преимуществами локальной файловой системы EBS во время работы с файлом.

Конечно, есть куча вещей, которые я не понимаю в вашей системе.Извиняюсь за это.