У меня есть веб-приложение, которое обслуживает двоичные файлы (изображения и т. Д.). Наше приложение работает на Amazon EC2. Изначально мы собирались использовать Amazon S3 для хранения и обслуживания этих файлов это больше не вариант.
Нам нужно передать эти файлы HTTPS используя CNAME. Очевидно, это невозможно с Amazon S3 по многим техническим причинам. Amazon предлагает Эластичное блочное хранилище (EBS) которые позволяют монтировать блок размером до 1 ТБ в один пример. У нас будет несколько экземпляров, обращающихся к этим данным параллельно.
Я думал об использовании распределенной файловой системы вроде МогилеFS/GluserFS/[вставить-еще-здесь] с участием Эластичное блочное хранилище (EBS).
Итак, мой вопрос: Что в настоящее время делают другие для создания масштабируемой (несколько 100 ТБ) системы хранения файлов на Amazon EC2 без использования Amazon S3 это избыточно? Резервное копирование данных будет продолжаться Amazon S3 но все операции чтения будут выполняться вне файловой системы.
Заранее спасибо. Если кому-то нужны разъяснения по чему-либо, не стесняйтесь спрашивать.
В Азук (ранее связанный домен неактивен / припаркован) мы не используем Amazon EC2, но мы используем GlusterFS (1.4.0qa92) для обслуживания всего контента, такого как PDF-файлы, пользовательские файлы, эскизы, а также для автономного анализа данных. IMHO не должно возникнуть проблем с развертыванием той же архитектуры в облаке Amazon - мы уже активно используем виртуализацию (в частности, OpenVZ). Единственное потенциальное ограничение - это установка GFS через предохранитель (виртуализация может запретить это), но, НАСКОЛЬКО, это возможно на Amazon.
Итак, я рекомендую Gluster и извините, что не могу помочь конкретно с Amazon :)
Ужасно старый вопрос, который внезапно снова всплыл на первой полосе ... :-)
Итак, мой вопрос: что в настоящее время делают другие для создания масштабируемой (несколько 100 ТБ) системы хранения файлов через Amazon EC2 без использования Amazon S3, которая является избыточной?
Ничего, на AWS вы бы использовали S3 для хранилища больших двоичных объектов на 100 ТБ, все остальное было бы бессмысленным.
Нам нужно передать эти файлы по HTTPS, используя CNAME. Очевидно, что с Amazon S3 это невозможно по многим техническим причинам.
Верно, но можно и другими способами.
Поскольку вам нужен доступ HTTPS к вашему собственному доменному имени, вы должны настроить пару серверов HTTPS (или прокси) на узлах EC2, которые будут действовать как шлюзы шифрования / дешифрования SSL между Интернетом и S3.
Я никогда не работал с Сервер трафика Apache (ранее Инктоми), но похоже, что он отлично подходит для этого. В противном случае для обработки SSL можно было бы использовать nginx или Apache вместе с 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>
В настоящее время я работаю над созданием реплицированной кластерной файловой системы на основе Gluster 3.1 и EBS с доступом через клиент FUSE.
Если у вас есть значительные вложения в веб-приложение, в которое встроено множество файловых вызовов, и вы хотите перейти на доступ с нескольких серверов приложений с балансировкой нагрузки и создать масштабируемое реплицированное хранилище без перезаписи всего кода доступа к файлам, похоже, что это в значительной степени ваш единственный простой вариант.
Я не завершил проект, поэтому у меня мало отзывов о готовом результате. Есть простой учебник Вот
я знаю это Acquia запускает Gluster на EBS с EC2. Так что технически это работает.