Насколько стабильным является s3fs для монтирования ведро Amazon S3 в качестве локального каталога в Linux? Является ли он рекомендованным/стабильным для условий высокой производительности?
Есть ли лучшие/похожие решения?
Обновление: Было бы лучше использовать EBS и смонтировать его через NFS ко всем другим AMI?
Здесь есть хорошая статья о s3fs, которая после прочтения я прибегал к EBS Share.
В нем подчеркивается несколько важных соображений при использовании s3fs, а именно связанных с присущими ему ограничениями S3:
Следовательно, это зависит от того, что вы храните, является ли s3fs допустимым вариантом. Если вы сохраняете, скажите, фотографии, где вы хотите написать весь файл или прочитать весь файл, никогда не изменяйте его пошаговое изменение, тогда его можно, хотя можно спросить, если вы это делаете, то почему бы просто не использовать S3 API напрямую?
Если вы говорите о данных об аппликациях (например, файлы базы данных, файлы журналов), где вы хотите сделать небольшое инкрементное изменение, тогда его определенная no-S3 Just не работает таким образом, вы не можете постепенно изменять файл.
В упомянутой выше статье говорится о аналогичном приложении - s3backer - которое затрагивает проблемы производительности, реализуя виртуальную файловую систему через S3. Это затрагивает проблемы производительности, но у него есть несколько собственных проблем:
Я прибегал к EBS Mounted Drived, совместно используемому экземпляром EC2. Но вы должны знать, что, хотя самый эффективный вариант имеет одну большую проблему У EBS Mounted NFS Share есть свои проблемы - единственная точка отказа; если аппарат, использующий общий объем EBS, отключается, вы теряете доступ ко всем машинам, которые обращаются к ресурсу.
Это риск, с которым я смог жить, и был вариантом, который я выбрал в конце. Надеюсь, это поможет.
Это старый вопрос, поэтому я расскажу о своем опыте за последний год с 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 Диска для S3, но без необходимости бороться с квотами и сборами, которые приходят с ней.