Назад | Перейти на главную страницу

Как хранить терабайты больших файлов со случайным доступом?

Допустим, у меня есть несколько тысяч больших файлов (1-800 МБ каждый), к которым все обращаются случайным образом, при этом к недавно загруженным файлам обращаются очень часто, и со временем время доступа уменьшается обратно пропорционально квадрату, но есть могут быть случайные всплески использования старых файлов.

Общая пропускная способность находится в диапазоне 2–4 Гбит.

Я ищу решение для самостоятельного размещения, а не предложения Amazon, так как они слишком дороги.

Я примерно имел в виду следующее:

Дорогой «главный» сервер с несколькими дисками SAS (или SSD) 15 000 об / мин, на которых будут размещаться новые файлы, только что загруженные на сайт. Как только скорость загрузки падает (или файл достигает определенного возраста), он перемещается на один из более дешевых архивных узлов.

РЕДАКТИРОВАТЬ: Файлы должны передаваться через HTTP широкому кругу пользователей. На серверах работает FC5. В основном нужен доступ для чтения, но запись также важна.

Прямо сейчас у меня есть простая установка двух серверов с максимальным объемом гигабита, и я схожу с ума по вводу-выводу. Коробка отформатирована блоками по 4К. Можно ли увеличить его, чтобы сказать .... 1024К имеет огромное влияние?

Все это важно:

1) много оперативной памяти

2) несколько сетевых карт и / или интерфейсов для уменьшения узких мест

3) обратный прокси-сервер, такой как Squid (см. Напр. http://www.visolve.com/squid/whitepapers/reverseproxy.php ) или лак

4) Настройка RAID для дисков (возможно, чередование или комбинация полос / зеркал)

5) выбор правильной файловой системы и, да, размера блока. Раньше XFS хорошо справлялась с большими объемами данных, теперь, вероятно, лучше ZFS.

Все это должно помочь. Сколько и что из этого необходимо реализовать, вы должны уметь рассчитать на основе ваших целевых требований (например, общая чистая пропускная способность, которую вы хотите использовать, полная пропускная способность одной карты, максимальная пропускная способность ваших дисков без рейдов и рейдов и т. Д.)

Если вы обслуживаете эти данные только локально, вы можете легко собрать один сервер с парой терабайт хранилища, используя готовые компоненты. Объединение пары гигабитных сетевых карт может обеспечить вам пропускную способность сети.

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

В противном случае вы могли бы посмотреть на реализации параллельных файловых систем; если вам нужен бесплатный, вы можете посмотреть Lustre (для Linux) или Hadoop (для нескольких платформ).

Вы предлагаете автоматическое многоуровневое хранилище. Это нетривиальное достижение. Некоторые поставщики высокопроизводительных систем хранения, такие как EMC, рекламируют решения для автоматизированного многоуровневого хранения, но они ориентированы на топовые корпоративные решения для локальных сетей и имеют соответствующую цену.

Вы захотите взглянуть на систему хранения ZFS от Sun, так как она рекламирует те возможности, которые вам нужны, и может быть ближе к цене.

http://blogs.oracle.com/studler/entry/zfs_and_the_hybrid_storage

Если вам не нужен вариант многоуровневого хранения своими руками (если бы мне пришлось, я бы, вероятно, использовал Задача управления файловой системой в windows 2008 r2) Я настоятельно рекомендую вам взглянуть на решение от Compellent. Вам не понадобятся никакие дополнительные узлы (как таковые) для более дешевого хранилища, так как у вас просто будет несколько быстрых дисков и несколько недорогих медленных дисков, смонтированных из san через выбранную вами ОС. Компеллент Набор функций OOB - это HSM на основе доступа. Это решение также обеспечивает масштабируемость. Прямо сейчас этот подход может быть дорогостоящим (и вы не представили никаких перспектив на будущее), но в долгосрочной перспективе он может быть более рентабельным, чем попытки управлять и поддерживать свое собственное решение.

Не понятно, на какой ОС вы работаете? Или если вы планируете автоматическое перемещение этих файлов или написать сценарий, который будет обрабатывать это за вас? Когда вы говорите, что доступ осуществляется через Интернет (HTTP) или какой-либо другой метод?

Я работал в социальной сети, в которой был «сейф» для файлов. По мере роста сайта мы сжигали около 200 ГБ в день в хранилище.

Мы отслеживали загруженные файлы с помощью веб-статистики, которая запускалась каждую ночь. Если файл был указан в списке верхних файлов, то сценарий обновит базу данных и установит для файла «высокий приоритет». Это сказало веб-приложению использовать URL-адрес с высоким приоритетом и скопировать, чтобы файл находился в системе быстрого хранения.

Это работало достаточно хорошо, пока они не смогли позволить себе масштабируемое решение SAN.

На самом деле не слышал достаточно подробностей, но зная, что я знаю, я бы посмотрел на базовый сервер 1U (или два для HA) с большим количеством оперативной памяти, на котором работает выбранная вами ОС / программное обеспечение для хранения, подключенный к Xiotech Emprise 5000. Предполагая, что вы можете разместить в памяти хороший рабочий набор, количество операций ввода-вывода в секунду, которые поступают на шпиндели, будет довольно широким случайным вводом-выводом, и это то, в чем лучше всего подходит коробка. Вероятно, вы могли бы сделать комбинацию из одного сервера (64 ГБ) / одного массива (2,4 ТБ) для касания менее 20 КБ.

Именно это мы и делаем с нашими серверами VoD, где мы используем множество некластеризованных серверов с большим объемом памяти в качестве кеша для локальных дисков, которые, в свою очередь, представляют собой несколько подключенных к SAS дисков размером 25 x 2,5 дюйма со скоростью вращения 15 оборотов в минуту, которые затем передаются на несколько Сетевые адаптеры 1 Гб или два 10 Гб. Мы потратили ДОЛГО время на то, чтобы правильно расположить разъем PCIe / SAS-HBA, а также настроить RAID-кластер, размер блока диска и т. Д.

Интересная проблема. Похоже, у вас есть куча пиратских фильмов: P

Помимо шуток, я думаю, ваше решение может стать хорошей отправной точкой. Это проблема, с которой вы хотите ознакомиться, прежде чем готовить решение, которое либо слишком дорогое, либо слишком ограниченно.

Я бы сделал что-то подобное:

  • (либо предположите, либо выполните тест производительности) узким местом, скорее всего, является то, что пользователи обращаются к разным частям одного и того же файла в одно и то же время - поскольку люди будут иметь разную скорость загрузки и будут входить в систему в разное время;
  • следовательно, для лучшей пропускной способности вы должны загружать наиболее запрашиваемые файлы в ОЗУ или в хранилище параллельного типа (т. е. реплицировать их на много-много дисков и распределять доступ пользователей по круговой схеме);
  • эрго, ты можешь захотеть иметь несколько фронтальных серверов с тонной оперативной памяти каждый, и резервный сервер с газиллионом дискового пространства.
  • разместите также обратный прокси-сервер или что-то в этом роде, чтобы распределить пользователей с перенаправлением на правильный сервер (т.е. сервер A содержит фильм №1- №20, сервер B содержит №21-40 и т. д.)
  • наконец, поместите управляющий узел для перемещения фильмов из внутреннего хранилища во внешний интерфейс в соответствии с частотой загрузки, временем года, днем ​​рождения знаменитости и т. д.

(если это сработает, могу ли я получить серверы, когда вы закончите с ними? У меня есть пара экспериментов с нейронными сетями, которые я хотел бы провести)