MogileFS/GlusterFS/etc + Amazon EBS + Amazon EC2
У меня есть веб-приложение, которое обслуживает двоичные файлы (изображения и т. Д.). Наше приложение работает на Amazon EC2. Изначально мы собирались использовать Amazon S3 для хранения и обслуживания этих файлов, это больше не вариант.
Нам нужно передать эти файлы по HTTPS, используя CNAME. Это очевидно невозможно с Amazon S3 по многим техническим причинам. Amazon предлагает хранилище Elastic Block Storage (EBS), которое позволяет монтировать один блок размером до 1 ТБ. У нас будет несколько экземпляров, получающих доступ к этим данным параллельно.
Я думал об использовании распределенной файловой системы, такой как MogileFS / GluserFS / [insert-more-here] с Elastic Block Storage (EBS).
Итак, мой вопрос: что в настоящее время делают другие для создания масштабируемой (несколько 100 ТБ) системы хранения файлов через Amazon EC2 без использования Amazon S3, что является избыточным? Данные будут по-прежнему сохраняться в Amazon S3, но все операции чтения будут выполняться вне файловой системы.
Заранее спасибо. Если кому-то нужно что-то разъяснить, пожалуйста, не стесняйтесь спрашивать.
4 ответа
В Azouk (ранее связанный домен неактивен / припаркован) мы не используем Amazon EC2, но мы используем GlusterFS (1.4.0qa92) для обслуживания всего контента, такого как PDF-файлы, пользовательские файлы, эскизы, а также для автономного анализа данных. ИМХО, не должно быть проблем с развертыванием такой же архитектуры в облаке Amazon - мы уже активно используем виртуализацию (в частности, OpenVZ). Единственным потенциальным ограничением является монтирование GFS через предохранитель (виртуализация могла бы запретить это), но AFAIK это возможно на Amazon.
Итак, я рекомендую Gluster и извините, что не могу помочь конкретно с Amazon:)
Ужасно старый вопрос, который снова всплыл на главной странице...:-)
Итак, мой вопрос: что в настоящее время делают другие для создания масштабируемой (несколько 100 ТБ) системы хранения файлов через Amazon EC2 без использования Amazon S3, что является избыточным?
Ничего, на AWS вы бы использовали S3 для хранения больших двоичных объектов объемом 100 ТБ, все остальное было бы бессмысленным.
Нам нужно передать эти файлы по HTTPS, используя CNAME. Это очевидно невозможно с Amazon S3 по многим техническим причинам.
Правда, но это возможно другими способами.
Поскольку вам нужен HTTPS-доступ к вашему собственному доменному имени, вы должны настроить пару HTTPS-серверов (или прокси) на узлах EC2, которые будут действовать как шлюзы шифрования / дешифрования SSL между Интернетом и S3.
Я никогда не работал с Apache Traffic Server (ранее Inktomi), но, похоже, отлично подходит для этого. В противном случае nginx или Apache можно использовать для обработки SSL вместе с Squid или Varnish, если вы хотите кэшировать.
На высоком уровне запрос-ответ выглядит примерно так:
Internet request via https -->
(optional) Elastic Load Balancing -->
EC2 instance with SSL capable HTTP proxy (fx nginx) -->
plain unencrypted http to S3
Кроме того, вам понадобится детерминированный способ обработки перезаписи URL. Fx. https://secure.yourdomain.com/<id> переписан http://<bucket>.s3.amazonaws.com/<id>
Я знаю, что Acquia запускает Gluster на EBS с EC2. Так что технически это похоже на работу.
В настоящее время я работаю над созданием реплицированной кластерной файловой системы на основе Gluster 3.1 и EBS с доступом через клиент FUSE.
Если вы вкладываете значительные средства в веб-приложение, в которое встроено множество обращений к файлам, и вы хотите перейти на доступ с нескольких серверов приложений с балансировкой нагрузки и создать масштабируемое реплицируемое хранилище без перезаписи всего кода доступа к файлам, кажется, что это в значительной степени ваш единственный простой вариант.
Я еще не завершил проект, поэтому у меня не так много отзывов о готовом результате. Здесь есть простое руководство