Я работаю в небольшой телекомпании. Они генерируют 11 ТБ видео файлов в месяц.
Что мне делать?. Мне просто нужны обычные диски SATA, в RAID. Какое решение мне купить?
(Они используют много NAS-устройств Iomega)
Хммм
"Expanded ad-infinitum" меня пугает. Вам действительно нужна каждая секунда фильма онлайн сразу же? Можно ли рассмотреть многоуровневое хранилище? Быстрое хранение свежих / часто используемых вещей; медленнее хранилище большей емкости, чтобы все, что вам нужно, было под рукой, но не щелкает пальцами прямо там; и на последок лента или что-то подобное для архива старых данных?
Что касается актуальных вариантов, как выглядят ваши бюджеты? Я собираюсь предложить продукты из линейки Dell, потому что это то, с чем я больше всего знаком, но все поставщики серверов высшего уровня будут иметь свои собственные продукты в одних и тех же точках, но я не так знаком с ними, и вам нужен совет , не длинный список моделей приводов.
Мне нравится делл Equallogic диапазон устройств SAN, если вы хотите опубликовать эти данные на нескольких серверах, и у них есть несколько вариантов, которые могут предложить вам уровень быстрого хранения и более медленный уровень с большей емкостью, и, конечно же, вы можете купить ленточная библиотека любого размера от Dell и для архивного уровня.
Если вы хотите публиковать этот материал только через один сервер, рассмотрите вариант хранения с прямым подключением - банки дисков, которые можно подключить к серверу. Опять же из ассортимента Dell, о котором я знаю, вы бы говорили о PowerVault ассортимент
Как я сказал ранее, я не предлагаю вам покупать Dell, я не работаю на них и не шиллинг для них - просто мы используем много их оборудования, и я это хорошо знаю. Вы можете взглянуть на HP, Sun / Oracle, IBM, и все они будут иметь одинаковый ассортимент продуктов на одном уровне, и есть много компаний, которые также специализируются на хранении данных. Но позволяя использованию файлов расти, не управляя им, это рецепт катастрофы, imho.
Я знаю, что вам, вероятно, говорят, что им нужно, чтобы все было немедленно доступно, и что вам нужно делать это дешево, я понимаю давление. Но пытаться управлять такими данными без стратегии управления - значит просить луну на палке, и это просто не сработает.
Я работаю в вещательной компании, и мы будем генерировать МНОГО видео / аудио данных в месяц. Нашим решением было два Hitachi SAN, один быстрее (FC) и один медленнее (SATA) с большим количеством кеша (кэш 256 ГБ). Мы ожидаем, что он иссякнет через 3 года. Ага, HD-видео - это сука.
У нас есть система управления в разработке, которая будет иметь дело со всем жизненным циклом контента и перемещать его из более быстрого хранилища (онлайн) в более медленное хранилище (рядом с линией) и, наконец, для архивации на ленте (требуется много метаданных, чтобы быстро и легко найти содержимое в архиве позже). У нас есть (расширяемая) ленточная библиотека 1000 LTO 4 для архивирования.
Об этом следует помнить. Вам действительно просто нужен быстрый доступ / место для определенного времени вашего программирования. Скажем, последний месяц. Это будут сырые кадры, поступающие от новостных групп, записанные студийные программы, записи живых выступлений, а также сторонняя продукция (синдицированный материал, реклама и т. Д.). Это контент, который будет использоваться для воспроизведения и редактирования и для этого должен быть быстрым для доступа (например, SAN, подключенный к MAC, где выполняется редактирование).
После того, как материал выйдет в эфир, вы можете (и должны) переместить его в коллекцию / архив (не знаю правильного термина на английском языке), возможно, на ленту. Если определенные новости, шоу или программы понадобятся позже, повторно вставьте их в более быстрое хранилище для использования и удалите после того, как все будет сделано.
Надеюсь, мой личный опыт поможет.
Если вы ищете коммерческое решение, Isilon - одно из самых дешевых решений, которое должно легко удовлетворить ваши потребности. Их продукт - решение для кластеризации. Вы строите кластер хранения из 3+ узлов. В каждом узле есть несколько дисков, а отказоустойчивость настраивается таким образом, чтобы вы могли потерять узел и / или несколько дисков и при этом оставаться в рабочем состоянии. Вы просто расширяете, добавляя новый узел или внешний дисковый пакет к существующим узлам. Очень просто и легко работать.
После этого я бы смотрел на NetApp как на второе место. Они немного дороже, но их продукты предлагают больше функций и производительности, чем Isilon.
Я предполагаю, что это видеоданные, а это значит, что сжатие и дедупликация вам ничего не даст. Я также предполагаю, что вы решили, что крупные надежные коммерческие поставщики SAN / NAS слишком дороги. Если все должно быть в сети и в быстрой локальной сети (а не в облачной службе, на которую, я полагаю, вы смотрели):
Ваш самый экономичный вариант будет примерно таким 45-дисковое шасси SuperMicro нафаршировал диски на 3 ТБ. Это 135 ТБ в формате 4U и менее 1500 Вт. Вы можете продолжать покупать аналогичные по мере необходимости, добавляя их по мере необходимости к существующим интерфейсам файлового сервера. RAID 6 с использованием хороших аппаратных контроллеров LSI вместо программного обеспечения, если вы можете себе это позволить - прочтите «дыру для записи raid 5» и опасайтесь программного рейда четности.
По мере увеличения плотности хранения вы можете переносить данные из старых ящиков хранения в новые, сохраняя постоянную площадь вашего сервера в долгосрочной перспективе. Используйте ленточные или съемные диски SATA для внешнего хранилища, поскольку это единственный экономичный способ резервного копирования такого большого количества данных.
Вы будете покупать устройство на 135 ТБ (с дисками) примерно каждые шесть месяцев с учетом накладных расходов на RAID и файловую систему. Время от времени вам также понадобится дополнительный интерфейсный файловый сервер. И питание и охлаждение их всех 24/7, замена вышедших из строя дисков и внедрение собственного программного обеспечения для управления. Возможно, вы можете использовать OpenStack для создания собственного внутреннего облачного хранилища на этих ящиках или жить опасно и рисковать всем в некоторых кластерных файловых системах с открытым исходным кодом. Скорее всего, вам понадобится два или более штатных органа, управляющих всем этим.
Облако выглядит все лучше и лучше, не так ли? Если данные должны быть локальными и онлайн, я бы серьезно посмотрел на сокращение данных ... через месяц или около того, перекодируйте все ваши потоки (предположительно, трансляцию MPEG-2) в видео VBR H.264 с гораздо более низким битрейтом . X264 с '--crf 23' близок к прозрачному и вдвое или меньше битрейта большинства широковещательных потоков MPEG2. Когда мне сообщают о затратах, я подозреваю, что руководство просто будет жить с данными старше X дней, находящимися в автономном режиме на съемных дисках SATA или ленте.
Если у вас есть время, чтобы что-то настроить самостоятельно, ребята из Backblaze могут хорошо описать, как они создают свои модули хранения: http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-how-to-build-cheap-cloud-storage/
Проверьте GlusterFS: возможность расширения на многие петабайты, низкая стоимость гигабайта, консоль управления, блоки хранения, подобные устройствам, настраиваемый уровень репликации, настолько быстрая, насколько позволяет ваша сеть, открытый исходный код и т. д. Вся энчилада.