Решения для замены S3FS (S3 Fuse), позволяющие автоматически масштабируемым веб-серверам получать доступ к большим файлам по запросу

Мы исследовали эластичное файловое хранилище (EFS - довольно дорогое) и синхронизированное хранилище S3 на нескольких томах EBS (подверженных проблемам с синхронизацией), хотя у нас есть бесконечные проблемы с различными аспектами s3fs (S3 Fuse) в том масштабе, в котором мы его используем, наши приложения нужна функциональность.

Нам нужна адекватная производительность загрузки файлов для 5 (пяти) автоматически масштабируемых экземпляров EC2 с оптимизацией для памяти (веб-серверов LB) на VPC, которые используют идентичную структуру файловой системы с активами, которые управляются конечными пользователями и обслуживаются приложением.

Потенциальное решение, которое мы не исследовали, для использования нашей конфигурации CloudFront CDN для файлов, размер которых может достигать 2 ГБ в крайних случаях или до 600 файлов размером от 5 до 100 МБ на каждой странице, которые пользователи могут просматривать / редактировать. Это кажется проблематичным при масштабировании, так же, если не больше, чем S3FS (если это вообще жизнеспособный вариант).

Ориентируясь на экономическую эффективность, но при этом сохраняя высокую производительность:

  • EFS - жизнеспособный и экономичный вариант замены функциональности S3FS?

  • Контроль затрат на массовые объемы EBS вызывает озабоченность, хотя и не исключен как жизнеспособный вариант, но окупится ли производительность дополнительных затрат?

  • способен ли CloudFront справиться с такой нагрузкой, как описано?

  • есть ли лучший вариант, который мы упустили, и мы могли бы захотеть его изучить?


amazon-ec2 amazon-s3 amazon-cloudfront amazon-ebs s3fs
person K8sN0v1c3    schedule 19.06.2018    source источник
comment
Примечание: вместо S3FS вы можете исследовать AWS Storage Gateway - File Gateway. Он предоставляет монтируемый интерфейс S3.   -  person John Rotenstein    schedule 19.06.2018
comment
Не совсем понятно, как ваше приложение на самом деле использует S3 (файлы 5-100 мегабайт ... 600 на страницу ... для редактирования), но, казалось бы, очевидное решение - использовать S3 изначально и напрямую, а не через слой абстракции, например s3fs. Решение s3fs полезно - я сам использую его для своих серверов SFTP, и на самом деле вы можете найти некоторые полезные параметры конфигурации в моем ответе здесь об этом - но по сути это взлом, потому что S3 - это хранилище объектов, а не файловая система. Наилучшее использование S3 достигается при его использовании изначально через API / SDK.   -  person Michael - sqlbot    schedule 19.06.2018
comment
Спасибо @JohnRotenstein - это те предложения, которые я надеялся получить из этого вопроса. У вас есть дополнительная информация о том, как образец / гипотетическая конфигурация AWS Storage Gateway имитирует набор функций и функциональность s3fs? например, как подключить AWS Storage Gateway к EC2? Можно ли подключить одни и те же корзины S3 для AWS Storage Gateway - File Gateway к нескольким экземплярам EC2 одновременно? и т.д. и т.п. Похоже, что информации об этих деталях намного меньше, чем даже s3fs, но, возможно, Bing просто не указал правильный путь (пока)?   -  person K8sN0v1c3    schedule 19.06.2018
comment
@ Michael-sqlbot ваша ссылка на ответ очень-очень хорошая. Фактически, вы затронули параметры, которые я никогда раньше не видел для использования в S3 Fuse, хотя я уже более месяца жил в ОЧЕНЬ слабой документации для s3fs, пытаясь сохранить приложение, которое быстро растет в использовании. работает на очень проблемной смонтированной файловой системе s3fs. Я полностью согласен с тем, что s3fs - это хакер, который очень удобен и полезен во множестве различных случаев использования, это, конечно, не жизнеспособный вариант для высокой пропускной способности, многоуровневых пользовательских ACL и т. Д. Есть ли у вас опыт замены функциональности s3fs?   -  person K8sN0v1c3    schedule 19.06.2018

Ответы (1)


arrow_upward
0
arrow_downward

Совершенно очевидно, что лучшим вариантом использования будет Amazon EFS, поскольку он спроектирован как файловая система, которая может быть смонтирована на нескольких томах Amazon EC2 в нескольких зонах доступности.

Любое решение, использующее S3 для хранения, не является настоящей файловой системой, потому что оно просто «представляет» S3 как файловую систему, а это не так. Следовательно, будут некоторые накладные расходы и потенциальные проблемы.

Если ваша единственная проблема - цена, то, надеюсь, вы сочтете целесообразным производительность и беспроблемное использование. Любое другое решение связано с дополнительными скрытыми затратами на обслуживание дополнительной системы, где что-то может пойти не так. В долгосрочном плане система, которая работает и проста в обслуживании, часто оказывается наилучшей ценой.

Вы можете сами попробовать решения (например, файловый шлюз) и посмотреть, соответствует ли оно вашим потребностям.

person John Rotenstein    schedule 19.06.2018
comment
Это мое личное мнение об обстоятельствах = EFS - лучшее решение, которое легче всего поддерживать. Тем не менее, увеличение стоимости по сравнению с S3 в 10 раз по сравнению с ценой, может быть, в 2-3 раза выше общей производительности, является довольно сложной задачей. Нам нужен / мы хотим быстро получить доступ к файловой библиотеке любого размера для любого произвольного пользователя в любой момент с любого экземпляра / виртуальной машины EC2, не нарушая банк. EFS увеличивает существующие и будущие затраты в 10 раз больше, чем S3FS + AWS S3 для нас. У нас есть обходные пути, но мы ищем самые дешевые варианты, которые легче всего поддерживать (как типично!) - person K8sN0v1c3; 19.06.2018
comment
Вы всегда можете просто сделать сетевой ресурс от одного компьютера к другому, используя собственные возможности совместного использования ОС (например, Window SMB или Linux NFS). Это недорого! - person John Rotenstein; 20.06.2018
comment
Ха, теперь у вас есть бюджет, с которым я работаю! Это отличный момент, хотя и немного обременительный для ... э ... ресурсов, с которыми нам приходится работать. Но на самом деле это отличный аргумент для чего-то вроде GlusterFS, хотя проблема производительности может иметь значение для мультизональных установок. По-прежнему неплохая идея и полностью в пределах возможных решений. :) - person K8sN0v1c3; 20.06.2018