Skip to content

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

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

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

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

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

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

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

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

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

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

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

Захват

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

Дублированный захват из источника

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

cluster_key mysecretkey;
stream tvchannel {
 url udp://239.0.0.1:1234;
 dvr /storage 3d;
}

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

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

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

Захват из источника с дорогим/медленным каналом

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

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

cluster_key mysecretkey;
stream tvchannel {
 url tshttp://EXAMPLE-IP/origin/mpegts;
 cluster_ingest capture_at=grabber1.example.com;
 dvr /storage 3d;
}

Также это можно настроить через веб-интефейс Flussonic UI:

  1. Перейдите во вкладку Media в раздел Streams, выберите необходимый поток и кликните на его название.
  2. Затем перейдите на вкладку Input и поставьте галочку в напротив Cluster ingest и укажите источник в поле Capture at:

Cluster ingest и capture at в UI

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

Если grabber1.example.com упадет, то grabber2.example.com автоматически добавит стримы себе.

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

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

Захват с резервированием архива

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

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

cluster_key mysecretkey;
stream tvchannel {
 url tshttp://EXAMPLE-IP/origin/mpegts;
 dvr /storage 3d;
}

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

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

cluster_key mysecretkey;
stream tvchannel {
 url m4f://grabber1.example.com/tvchannel;
 url tshttp://EXAMPLE-IP/origin/mpegts;
 dvr /storage 3d;
}

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

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

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

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

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

cluster_key mysecretkey;
source grabber1.example.com {
  dvr /storage 7d replicate;
}
source grabber2.example.com {
  dvr /storage 7d replicate;
}

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

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

cluster_key mysecretkey;
source grabber1.example.com {
  except tvchannel 2x2;
  dvr /storage 7d replicate;
}
source grabber2.example.com {
  except tvchannel 2x2;
  dvr /storage 7d replicate;
}

Раздача

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

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

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

cluster_key mysecretkey;
source streamer1.example.com streamer2.example.com {
 cache /cache 2d;
}

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

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

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