Раскритикуйте архитектуру доставки видео контента?

Question

[Hocok_B_KapMaHe]

Добрый день,
Есть схема доставки видео (по протоколу HLS) которую я хочу использовать в своем проекте.

Я был в ней полностью уверен, пока некоторые не заставили меня в ней засомневатся (хотя я думаю зря, но хочу услышать мнение остальных)

Смысл ее в следующем:
У нас есть видео, мы его кодируем в 3 качества:
* 720p (до 4Мбит\сек, - макс. размер сегмента около 6 МБ)
* 360p (до 1 Мбит\сек, - макс. размер сегмента 1,5 МБ)
* 240p (до 500Kbit\сек., - макс. размер сегмента 0,6 Мб)

После этого разбиваем на кусочки длительностью по 10 сек. (рекомендация apple) и размазываем по всем серверам:

Сегменты равномерно распределены по нодам, т.е.:
* сегменты с 0 секунды по 10 секунду в 3х качествах хранятся на первом ноде
* сегменты с 10 секунды по 20 секунду в 3х качествах хранятся на втором ноде
* сегменты с 20 секунды по 30 секунду в 3х качествах хранятся на третьем ноде

и т.д.

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

Кроме того у каждого нода есть свой дубликат, который хранит полную копию своего нода.
Т.е. очень похоже на RAID 51

Когда клиент приходит посмотреть видео, он попадает на первый нод, выкачивает (если позволяет скорость сети = его + нода) самый большой сегмент (hd качество), затем запрос потупает на второй нод, оттуда берется сегмент, потом с третьего и т.д.

В случае "проседания" сети на ноде, он отдает сегменты в низком битрейте.

Дубликат нода также может отдавать сегменты. (есть балансировка между нодом и дубликатом, т.е. на них поступает равное кол-во запросов)

Преимущества:
Нет проблемы горячих видео, т.к. оно размазано по всем серверам.
Можно горизонтально добавлять ноды до бесконечности

На всякий пожарный приложу картинку

Какие на ваш взгляд недостатки у данной схемы?

Спасибо

Answer 1

[Валентин]

Раскритиковать так раскритиковать) Почему так не сделали до тебя.

1. При выпадении пары нод вы получаете глюк по ВСЕМУ имеющемуся контенту.
2. При работе с CDN тебе надо будет либо переходить на классическую систему с одним сервером (мб с резервом), либо тащить все созданные тобой ноды в другую точку мира. Тебе ведь захочется быть ближе к клиенту?
3. Каждые 10 сек будут создаваться новое TCP-соединение с другим сервером, будет (ли?) закрываться старое, keepalive ты уже не сделаешь, в udp-передавать стремно. В результате будешь получать микросекундные задержки при переключении кусочка.
4. Заливка и хранение контента - отдельная песня. Придется хранить весь контент на всех серверах. И синхронизировать их через торенты.
5. Представь - высоконагруженные железки, каждый момент обращение к абсолютно произвольному сегменту памяти. В случае хранения на одной железке, доступ к контенту был более предсказуем в рамках одной машины

Идея прикольна, но уже есть более интересные реализации для этих целей - распределенные файловые системы (если все оборудование находится относительно близко) или CDN (если далеко)

Comments

[Hocok_B_KapMaHe]

1. Согласен. Но есть raid массивы. Их иногда постигает таже участь. Вероятность выхода сразу одной пары есть, но не настолько велика. На эту тему до сих пор идут дебаты.

2. Да на счет CDN будет класическая схема. И в данном случае, такая архитектура будет выступать в роли стореджа. Но есть преимущество, можно один файл, тянуть паралельно со многих нод, как это например делают распределенные файловые системы.

3. keep alive нету. Старое соединение закрыватся будет. Сервер уже написан собственноручно =)

4. Да, заливку, конвертацию не описывал(с этим я думаю разберусь). А rsync уже не модно?

5. Ну это дело вкуса. Хочу хардкор

Да кстати, если уж заговорили о распределенных фс может подскажете фс которая бы могла работать с одной сетевой картой и не требовала lan сети между нодами?

И спасибо за конструктив )

[Валентин]

@Hocok_B_KapMaHe: я больше по CDN-ам)
1) В raid-массивах нет точки отказа в сетевой инфраструктуре)
2) Классическая схема - понятие весьма относительное, каждый производитель решений дает свое, плюс кто-то из контентообладателей делатет свое. И все равно, получается, на каждой площадке CDN-а надо будет держать все серверы.
3) Сделайте накладки на задержки. Или UDP
4) Дело не во вкусе, а на сколько хватить винтов. SSD пока все-таки дороговаты, а HDD медленны.
5) rsync нормально, но вы будете хранить весь контент на всех железках

[sh84]

Не очень понял что за магия кроится за
>> В случае "проседания" сети на ноде, он отдает сегменты в низком битрейте."
это стандартная логика понижения качества на клиенте?

>> Нет проблемы горячих видео, т.к. оно размазано по всем серверам.
она размазывается с уровня файлов до уровня кусочков:
т.е. это справедливо если горячий фаил 1, если из много (допустим 3), то равномерно распределив горячие файлы получим тот же результат.
Схема с размазыванием кусочков по серверам будет эффективнее только если 1 сервер не может эффективно отдавать этот один горячий ролик.

Идея в общем то может быть рабочей, но очень много привнесенной сложности:
для каждого кусочка файла надо помнить где он хранится (тк серверов сейчас 3, через месяц 4, размеры дисков могут быть не одинаковы, и т.п.), сложная логика добавления ( что делать со старыми роликами, заново перераспределять по серверам что ли?) и удаления нод.. И все это ради чего, не понятно..

Или использовать какую-н сетевую fs, они примерно такую же (и даже больше) логику реализуют, но уже написаны :) Из минусов правда падение производительности в сравнении с прямой отдачей файлов с диска.
А можно просто хранить каждый фаил в 2 копиях например. Или в n копиях (для более горячего контента). И помнить только лишь на каких серверах нужный фаил. Это мой выбор :)

Answer 2

[Дмитрий Энтелис]

От себя добавлю что на мой взгляд нужно более интеллектуально подходить к вопросу "горячих" и "холодных" видео. Хотя конечно от проекта зависит очень сильно.
Ребята из erlyvideo рассказывали что ~80% трафика на карамба.тв это трафик приходящийся на ролик в первые сутки после его выкладки. Т.е реально горячее видео расклыдавается полными дублями на N серверов для быстрой отдачи. Все остальное хранится условно с обычными резервированием.