Подтвердить что ты не робот

Блеск, Глустер или Могиле? для хранения видео, кодирования и потоковой передачи

Так много вариантов и так мало времени, чтобы проверить их все... Интересно, есть ли у кого-то опыт работы с распределенными файловыми системами для потоковой передачи и хранения/кодирования видео.

У меня есть много огромных видеофайлов (от 50 до 250 ГБ), которые мне нужно хранить где-нибудь, сможете их кодировать в mp4 и передавать их с нескольких серверов Adobe FMS. Единственный способ справиться с этим - с распределенной файловой системой, но теперь вопрос заключается в том, какой из них:

Мои исследования до сих пор говорят мне:

  • Lustre: зрелые проверенные решения, используемые многими крупными компаниями, лучше всего s > 10G файлами - это драйвер ядра.
  • Gluster: новый, менее зрелый, основанный на FUSE, который легко устанавливается, но может быть медленнее из-за накладных расходов FUSE. Лучше обрабатывать большое количество небольших файлов ~ 1 ГБ
  • MogileFS: похоже, только для небольших файлов ~ МБ, использует HTTP для доступа? возможное связывание FUSE в будущем.

До сих пор Ластер кажется победителем, но я хотел бы услышать реальный опыт для конкретного приложения, которое у меня есть.

Также Hadoop, Redhat GFS, Coda и Windows DFS звучат как опции, поэтому любые впечатления приветствуются. Если у кого-то есть контрольные показатели, поделитесь им.

После некоторого реального опыта это то, что я узнал:

  • Luster:
    • Производительность: Удивительно быстро! Я могу утверждать, что Luster может обслуживать множество потоков и на скорость кодирования не влияет доступ к файлам через Luster.
    • Совместимость POXIS: Очень хорошо!. Нет необходимости изменять приложения для использования блеска.
    • Репликация, балансировка нагрузки и сбой: очень плохо!. Для загрузки репликации балансируя нас и терпеть неудачу, нам нужно полагаться на другое программное обеспечение, такое как виртуальные IP-адреса и DRDB.
    • Установка: худшее!. Невозможно установить простым смертным. Требуется очень конкретную комбинацию ядра, патчи с блеском и настройки, чтобы заставить его работать. А также текущие пятна блеска обычно работают со старыми ядрами, которые несовместимы с новое оборудование/программное обеспечение.
  • MogileFS:
    • Производительность: подходит для небольших файлов, но не используется для файлов среднего и большого размера. Это в основном из-за накладных расходов HTTP, поскольку все файлы отправляются/получаются через HTTP-запросы, которые кодировать все данные в base64, добавляя 33% служебных данных для каждого файла.
    • Совместимость POXIX не существует. Все приложения должны быть изменены для использования mogilefs, что делает его бесполезным для потоковой передачи/кодирования, поскольку большинство потоковых серверов и инструменты кодирования не понимают протокол MogileFS.
    • Репликация и переход из строя из коробки и балансировка нагрузки могут быть реализованы в при одновременном доступе к нескольким трекеру.
    • Установка относительно проста, и готовые к использованию пакеты существуют в большинстве дистрибутивов. Единственная трудность, с которой я столкнулся, - установить базовый-подчиненный базы данных, чтобы устранить единственная точка отказа.
      • Gluster:
    • Производительность: очень плохо для потоковой передачи. Я не могу достичь более нескольких Мбит/с в 10 Гбит/с сеть. Клиенты и серверные процессоры стремительно растут. Для кодирования работает, потому что CPU насыщен перед сетью и вводом/выводом.
    • POXIS: Совместимость. Инструменты, которые я использую, могут обращаться к монтерам с помощью gluster как обычные папки в диск, но в некоторых случаях края начинают создавать проблемы. Проверьте списки почтовых рассылок и вы увидите, что есть много проблем.
    • Репликация, отказоустойчивость и балансировка нагрузки: лучшее! если они действительно работали. Глустер очень новый, и в нем много ошибок и проблем с производительностью.
    • Установка слишком проста. Командная строка управления удивительна и реплицируется, полосатые и распределенные тома между несколькими серверами не могут быть проще.

Окончательный вывод:

К сожалению, вывод: "Никакой серебряной пули".

В настоящее время у нас есть медиа файлы в Gluster3.2 в реплицированном томе для хранения и транскодирования. Пока у вас не так много серверов, избегайте георепликации и томов, все работает нормально.

Когда мы собираемся передать медиафайлы, мы скопируем их на том громкости, который реплицируется на второй уровень громкости через DR: DB. Затем сервер wowza считывает медиафайлы из тонов макета.

И, наконец, мы используем MogileFS для обслуживания эскизов на наших серверах веб-приложений.

4b9b3361

ОТВЕТЫ

Ответ 1

GlusterFS значительно улучшились до этой даты. Теперь они предоставляют "гранулированную блокировку" для больших файлов. См. Здесь: http://www.gluster.org/community/documentation/index.php/WhatsNew3.3 Также это довольно зависимые частоты кадров видео, которые вы тоже должны работать. Если вы не подойдете к ставкам 4K, Gluster может решить проблемы с хранением. Если есть огромный спрос на скорость, поэтому Infiniband может играть.

Ответ 2

Проверьте файловую систему Hadoop (HDFS). Основное внимание уделяется очень крупным файлам и параллельным вычислениям задач (с картой/сокращением), он имеет высокую задержку, но очень высокую пропускную способность. В настоящее время он используется на таких крупных объектах, как Facebook и amazon.com

Ответ 3

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

HTTP - хороший протокол для этого материала. У кого нет многофункционального и эффективного HTTP-клиента?

Ответ 4

Из названных систем наиболее подходящим является MoglieFS.

Но, возможно, вы можете получить любую специальную систему. Скажем, у вас есть 4 сервера AdobeFMS:

{video0.exmple.com,video1.exmple.com,video2.exmple.com,video3.exmple.com}.

Вы можете распространять все свои видео среди этих 4 серверов, используя простую схему, например

    /*
     *  pseudo code
     */

    $server_id = get_server_id(filename);
    ...
    ...
    int function get_server_id(filename) 
    { 
       return hash(filename) mod 4;
    }

после кодирования видео, ваше приложение будет

$server_id = get_server_id(file_name)
copy file_name to /mnt/$server_id/

клиенты будут обращаться к видео, используя что-то вроде http://videoN.example.com/filename.mp4, где N вычисляется из имени файла с помощью get_server_id().

Luster/Gluster действительно не то, что вы должны искать. Luster FS более зрелый, но разработчики просят вас обрабатывать файлы на таких FS, как "кеш", т.е. Они могут быть потеряны в любое время.

Luster/Gluster предназначены для использования в HPC, чтобы обеспечить быстрый доступ к огромному объему данных без единого сервера хранения, являющегося производительностью бутылочной горловины. Еще один момент для этих систем - это жалоба POSIX. В среде HPC/Research вы обычно не успеваете переписывать свои приложения, потому что вы установили новый классный и быстрый FS.

Ответ 5

Map-reduce не помогает в отношении записи/чтения 90/10! Постоянный размер файла - это хорошая вещь, а файлы небольшие. Таким образом, MogileFS звучит как хорошая альтернатива, так как ситуация с Luster/Gluster не подходит.