У нас есть офис, в котором растет спрос на доступ к большим файлам из наших собственных каталогов Amazon S3. Возможность быстрого доступа к ним важна для нашего бизнеса, поэтому мы считаем, что пора начать хранить копии файлов на месте. Это не моя область знаний, поэтому я надеюсь на какой-нибудь совет.
«Нормального» кеша одного нам не хватит, так как мы хотим ускорить даже первый запрос любого заданного файла. Интерфейс командной строки AWS может синхронизировать локальный каталог с S3, поэтому одна из идей состоит в том, чтобы запускать его по расписанию в периоды низкого трафика, а затем настроить прокси-сервер для обработки этого каталога как своего кеша, если это возможно.
Другая идея - отправить запросы к кеширующему прокси из сценария, чтобы поддерживать кеш в тепле, по аналогичному расписанию.
Одно предостережение заключается в том, что активы S3 являются частными, поэтому мы подписываем их URL-адреса перед каждым запросом. Это означает, что прокси-сервер должен иметь возможность обслуживать локальную копию на основе URL-адреса. без учета любые параметры запроса. Например, оба этих URL-адреса должны разрешаться в один и тот же кешированный / зеркальный файл:
https://example.com/asset1.txt?signature=1
https://example.com/asset1.txt?signature=2
Размер кеша будет выражаться в однозначных терабайтах и обрабатывать трафик примерно для 300 активных пользователей.
Итак, наконец, мои вопросы:
Если вам нужно просто синхронизировать локальный репозиторий с облачным хранилищем объектов, я бы взглянул на Rclone или CloudBerry. Rclone имеет интерфейс командной строки для синхронизации каталогов и файлов между облаками. Он работает с наиболее популярными облачными хранилищами, такими как Azure, AWS (S3 и Glacier) и т. Д. https://rclone.org/
Также, если вы хотите сделать резервную копию всех данных в облаке, есть возможность делать резервные копии виртуальной ленточной библиотеки с дополнительной разгрузкой в облако. Поэтому, если вам нужно создать резервную копию существующей инфраструктуры, вы можете создавать резервные копии, защищенные от программ-вымогателей, с автоматической разгрузкой в облако. У него есть дедупликация и сжатие, но, насколько я знаю, прямо сейчас Starwind предоставляет это бесплатно. https://www.starwindsoftware.com/starwind-virtual-tape-library
Оба решения продуманы и надежны, нужно лишь выбрать нужный вариант. Надеюсь, это было полезно.
В зависимости от ваших требований AWS Storage Gateway может предоставить вам то, что вам нужно. Storage Gateway - это предложение AWS, которое развертывается в вашей локальной среде как виртуальная машина.
Есть два варианта Storage Gateway, которые сразу приходят на ум как потенциально подходящие:
Файловый шлюз представляет корзину S3 как монтирование NFS и включает прозрачное локальное кэширование.
Шлюз томов - кэшированные тома представляет собой цель iSCSI, а также включает локальное кэширование часто используемых данных.
У Storage Gateway есть некоторые недостатки:
Он НЕ предназначен для поддержки сценариев с несколькими мастерами., поэтому механизмы блокировки относятся к Storage Gateway (а не к базовому сегменту S3). Из этих двух сценариев с несколькими мастерами больше подходит Файловый шлюз, поскольку он поддерживает RefreshCache API вызов, который обновит метаданные в вашей локальной виртуальной машине с помощью объектов, которые были добавлены / удалены / заменены после того, как шлюз в последний раз перечислил содержимое корзины.
Volume Gateway не предоставляет доступ к базовому сегменту S3. Таким образом, в то время как File Gateway поддерживается ведром S3, управляемым заказчиком, Volume Gateway поддерживается ведром S3, управляемым AWS. Это означает, что для Volume Gateway вы не видите ведро S3 в своей учетной записи и не можете получить доступ к данным в нем как к обычному объекту S3. (Я не могу найти документацию, подтверждающую это, но я уверен на 95%, что это правильно)
Существуют и другие типы Storage Gateway, о которых вы можете прочитать как работает AWS Storage Gateway.
Если вы еще не используете Прямое соединение, то вы можете рассмотреть возможность использования его для доступа к сервисам AWS с высокой пропускной способностью и низкой задержкой. (Я предполагаю, что вы уже используете его, учитывая количество данных, которые вы упомянули)
Изменить 2018-05-21: Цены на шлюз хранилища Используя Storage Gateway, вы платите за базовое хранилище (размер данных + запросы) и передачу данных. Вот и все. Любое другое решение, использующее S3 для хранения, будет стоить вам столько же.