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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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