Насколько стабилен s3fs для монтирования корзины Amazon S3 в качестве локального каталога

Question

Насколько стабилен s3fs для монтирования корзины Amazon S3 в качестве локального каталога в Linux? Рекомендуется / стабильно для производственных сред с высокими требованиями?

Есть ли лучшие / похожие решения?

Обновление: было бы лучше использовать EBS и смонтировать его через NFS для всех других AMI?

Answer 1

Здесь есть хорошая статья о s3fs, которую я после прочтения прибегнул к EBS Share.

Он подчеркивает несколько важных соображений при использовании s3fs, а именно связанных с внутренними ограничениями S3:

• ни один файл не может быть больше 5 ГБ
• Вы не можете частично обновить файл, поэтому изменение одного байта приведет к повторной загрузке всего файла.
• работа со многими небольшими файлами очень эффективна (в конце концов, каждый является отдельным объектом S3), но большие файлы очень неэффективны
• Хотя S3 поддерживает частичную / чанкованную загрузку, s3fs не использует это, поэтому, если вы хотите прочитать только один байт файла объемом 1 ГБ, вам придется загрузить весь ГБ.

Поэтому от того, что вы храните, зависит, является ли s3fs выполнимым вариантом. Если вы храните, скажем, фотографии, где вы хотите записать весь файл или прочитать весь файл, никогда не изменяйте файл постепенно, тогда это хорошо, хотя можно спросить, если вы делаете это, то почему бы просто не использовать S3 API напрямую?

Если вы говорите о данных приложения (скажем, файлах базы данных, файлах журналов), в которых вы хотите внести небольшие инкрементные изменения, то это однозначно нет - S3 Just не работает таким образом, что вы не можете постепенно изменять файл.

В упомянутой выше статье рассказывается о похожем приложении - s3backer, которое решает проблемы с производительностью путем внедрения виртуальной файловой системы поверх S3. Это позволяет обойти проблемы с производительностью, но само по себе имеет несколько собственных проблем:

• Высокий риск повреждения данных из-за задержки записи
• слишком малые размеры блоков (например, по умолчанию 4K) могут привести к значительным дополнительным затратам (например, 130 долларов США за 50 ГБ при объеме хранения 4K блоков)
• слишком большие размеры блоков могут значительно увеличить стоимость передачи и хранения данных.
• использование памяти может быть чрезмерным: по умолчанию она кэширует 1000 блоков.
  С размером блока 4K по умолчанию это не проблема, но большинство пользователей
  вероятно, захочется увеличить размер блока.

Я прибегнул к EBS Mounting Drived с общим доступом из экземпляра EC2. Но вы должны знать, что, хотя наиболее эффективный вариант имеет одну большую проблему, у общего ресурса NFS, смонтированного на EBS, есть свои проблемы - единственная точка отказа; если машина, которая разделяет том EBS, выходит из строя, то вы теряете доступ ко всем машинам, которые получают доступ к общему ресурсу.

Это риск, с которым мне удалось смириться, и я выбрал этот вариант в конце. Надеюсь, это поможет.

Answer 2

Это старый вопрос, поэтому я поделюсь своим опытом за последний год с S3FS.

Изначально у него было много ошибок и утечек памяти (у меня была задача cron, чтобы перезапускать ее каждые 2 часа), но с последней версией 1.73 она была очень стабильной.

Лучшее в S3FS - у вас меньше забот и вы получаете некоторые преимущества в производительности бесплатно.

Большинство ваших запросов S3 будут PUT (~5%) и GET (~95%). Если вам не нужна постобработка (например, создание эскизов). Если вам не нужна постобработка, вам не нужно в первую очередь обращаться к своему веб-серверу и загружать его непосредственно на S3 (используя CORS).

Предположение, что вы попали на сервер, вероятно, означает, что вам нужно выполнить некоторую постобработку изображений. С S3 API вы будете загружать на сервер, а затем загружать на S3. Если пользователь хочет обрезать, вам нужно будет снова загрузить с S3, затем повторно загрузить на сервер, обрезать и затем загрузить на S3. Когда S3FS и локальное кэширование включены, эта оркестровка позаботится о вас и сохранит загрузку файлов из S3.

Что касается кеширования, если вы кешируете на временный диск в EC2, вы получаете преимущества в производительности, которые можно получить, и можете очищать кеш, не беспокоясь ни о чем. Если у вас нет свободного места на диске, у вас не должно быть оснований для очистки кеша. Это значительно упрощает такие операции перемещения, как поиск и фильтрация.

Единственное, чего мне хотелось бы, - это полной синхронизации с S3 (стиль RSync). Это сделало бы его корпоративной версией DropBox или Google Drive для S3, но без необходимости прибегать к квотам и сборам.