Документация Flussonic Media Server

Contents

Организация CDN

Если одного сервера для раздачи видео перестает хватать, небходимо организовывать сеть доставки контента (CDN).

Flussonic Media Server обладает рядом возможностей, позволяющих упростить эту задачу. В данной статье будем рассматривать небольшую сеть на 3-10 серверов, вещающих прямые эфиры.

Терминология

CDN — Content Delivery Network — сеть доставки контента. Это множество серверов с специализированным ПО, которые ускоряют доставку и отдачу контента конечному пользователю. Сервера расположены по всему миру таким образом, чтобы время ответа посетителям сайта было минимальным. Под «контентом» обычно подразумевают видео и статические элементы веб-сайтов (не требующие выполнения кода на сервере или запросов в базу данных, такие как css/js).

Региональное распределение

Будем рассматривать ситуацию, когда видео захватывается со спутника в России/Европе и потом передается в Европу/Америку для ретрансляции.

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

Схема организации:

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

На такой схеме продемонстрируем возможности Flussonic Media Server.

Захват

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

В самом простом варианте, если у вас видео приходит мультикастом по UDP, можно просто на разных серверах захвата (далее grabber1.cdn.tv и grabber2.cdn.tv) настроить захват одного и того же видео:

http 80;
cluster_key mysecretkey;

stream ort {
  url udp://239.0.0.1:1234;
  dvr /storage 3d;
}

Здесь и далее мы подразумеваем, что у серверов хостнеймы правильные и они все резолвятся.

Также важный момент с единым ключом кластера на всех серверах. Здесь мы выбрали mysecretkey, но его можно поменять.

В таком режиме сервера захвата работают абсолютно независимо, архив пишется на обоих серверах и оба сервера постоянно доступны. Но такая схема требует захвата из источника несколько раз, а это не всегда бывает удобно или возможно. Например, если пакет каналов, получаемый по HTTP, укладывается в 500-800 мегабит, то двойной захват может потребовать серьезного расширения входного канала выше гигабита.

Если вы не хотите брать видео из источника несколько раз, то можно настроить кластерный захват.

На серверах захвата добавляется одинаковый конфиг со стримами:

http 80;
cluster_key mysecretkey;

stream ort {
  url tshttp://origin/ort/mpegts;
  cluster_ingest capture_at=grabber1.cdn.tv;
  dvr /storage 3d;
}

С таким конфигом на обоих серверах захвата всё видео будет захватываться на одном сервере, второй будет работать в режиме горячего резерва. Опция capture_at указывает серверам, что grabber1 является более приоритетным для захвата. Если её не указать, то стримы равномерно распределятся между серверами, что тоже может быть неплохой идеей.

Если grabber1.cdn.tv упадет, то grabber2.cdn.tv отреагирует на это и автоматически добавит стримы себе.

При такой настройке второй сервер простаивает, архив на нём не пишется и появится на нем только при падении первого сервера.

Если хочется полностью срезервировать и архив, то нужна другая конфигурация.

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

На grabber1.cdn.tv будет такой конфиг:

http 80;
cluster_key mysecretkey;

stream ort {
  url tshttp://origin/ort/mpegts;
  dvr /storage 3d;
}

Видео захватывается из источника и пишется на диск.

На grabber2.cdn.tv будет немного другой конфиг:

http 80;
cluster_key mysecretkey;

stream ort {
  url hls://grabber1.cdn.tv/ort/mono.m3u8;
  url tshttp://origin/ort/mpegts;
  dvr /storage 3d;
}

grabber2 будет стараться забрать видео с первого сервера, но в случае его падения пойдет к источнику напрямую.

Транзит от захвата к стримингу

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

Однако нет необходимости прописывать все каналы руками и следить за ними, можно воспользоваться механизмом Flussonic для этого.

На сервере streamer1.cdn.tv, который занимается приёмом видео с захвата достаточно прописать в конфигурационный файл:

http 80;
cluster_key mysecretkey;

source grabber1.cdn.tv grabber2.cdn.tv {
  dvr /storage 7d replicate;
}

При такой конфигурации Flussonic Media Server будет забирать каналы с одного или с второго сервера, писать их локально в архив и при необходимости докачивать те данные, которые есть удаленно, но отсутствуют локально.

Если какие-то каналы не требуются для постоянной работы, можно пометить их как каналы по запросу:

http 80;
cluster_key mysecretkey;

source grabber1.cdn.tv grabber2.cdn.tv {
  except ort 2x2;
  dvr /storage 7d replicate;
}

Раздача

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

Оптимально, когда распределением занимается Middleware, это самая надежная схема с точки зрения клиентов (не все поддерживают редиректы), но можно воспользоваться и другими вариантами.

Сами стримеры имеет смысл организовывать также, как и транзит. Но только забирать с локальных серверов:

http 80;
cluster_key mysecretkey;

source streamer1.cdn.tv streamer2.cdn.tv {
  cache /cache 2d;
}

В этом случае мы включили не DVR, а сегментный кэш. Flussonic Media Server будет складывать сегменты в кэш и при необходимости отдавать их оттуда. Кэш, понятно, размещать на шпиндельных дисках не имеет никакого смысла, это только SSD.

Прямой эфир при этом всё равно обслуживается из памяти и без проблем забивает 10 гигабит, а вот кэш с одного SATA SSD упрется в 6 гигабит SATA шины. Можно это решить сборкой RAID 0 из нескольких SSD.

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