Skip to content

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

Из этой статьи вы узнаете, как оптимизировать доставку видеоконтента на другие континенты. Видеоконтент — это и живое видео, ретранслируемое с сервера захвата, и видео, хранящееся на диске origin-сервера (например, DVR или VOD).

При передаче такого контента на большие расстояния по публичному интернету могут возникнуть следующие проблемы:

  • Нестабильность. Сигналу нужно пройти много маршрутизаторов, чтобы попасть с сервера захвата/origin-сервера к конечному пользователю, при этом стабильность передачи данных никем не гарантируется. Могут пройти десятки секунд, прежде чем пользователь получит запрошенное видео.
  • Стоимость. Каналы между континентами, странами, регионами обычно дороже местных/городских каналов, поэтому обращение отдаленных пользователей напрямую к серверам захвата и origin-серверам нерентабельно.
  • Нагрузка. Одновременный запрос видео большим количеством пользователей может вызвать перегрузку сервера.

Для решения этих проблем обычно применяют CDN (Content Delivery Network) — сеть доставки контента. Это множество серверов со специализированным ПО, физически расположенных в тех регионах, где пользователи будут получать контент. На местных серверах CDN можно либо полностью дублировать, либо кешировать наиболее часто запрашиваемое содержимое DVR, а также распределять между этими серверами запросы на проигрывание живого видео. Это значительно ускоряет доставку и отдачу контента конечному пользователю, а также позволяет снизить затраты на каналы связи и оптимизировать нагрузку на сервера.

Flussonic Media Server обладает рядом возможностей, позволяющих без труда организовать CDN необходимого масштаба для доставки видео. Использование Flussonic Media Server как специализированного ПО на серверах CDN дает ряд преимуществ, например:

  • Встроенный механизм кеширования, специализированный под задачи доставки видео с персонализированной рекламой (см. Монетизация контента через врезку рекламы).
  • Отсутствие необходимости отправлять на edge-сервера сразу несколько протоколов по дорогим каналам, ведь Flussonic на edge-сервере сам упакует видео в нужный формат.

В данной статье рассмотрим пример построения небольшой сети CDN из серверов, вещающих прямые эфиры.

Далее будут приведены конфигурации всех серверов в пайплайне видео от захвата до edge-серверов (CDN). Если вас интересуют только сервера CDN, переходите в раздел Раздача.

Пайплайн

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

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

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

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

См. также подробную статью в нашем блоге о пайплайне видео.

Захват и транскодирование

Можно сделать разные конфигурации захвата потоков в сеть доставки в зависимости от того, можно ли брать видео из источника несколько раз или нет. В самом простом варианте, если видео приходит с головной станции мультикастом по UDP, и можно просто на разных серверах захвата настроить захват одного и того же видео (см. Прием мультикаста). Мы же рассмотрим пример с кластерным захватом, который подойдет для захвата из источника с дорогим/медленным каналом.

Чтобы клиенты с разной пропускной способностью каналов могли стабильно получать видео, нужно транскодировать его в мультибитрейтный поток. Тогда пользователь может выбрать тот битрейт (качество), который будет для него комфортен. Вы можете выполнять транскодирование на тех же серверах, где происходит захват, или выделить для этого отдельный пул серверов. Все зависит о доступных ресурсов, ведь транскодирование — очень ресурсоемкий процесс. В нашем примере транскодирование будет происходить на тех же серверах, что и захват.

Рассмотрим пул из двух транскодеров (transcoder1.example.com и transcoder2.example.com), которые резервируют друг друга посредством кластерного захвата.

Транскодер 1

cluster_key mysecretkey;

# Remote sources:
peer transcoder1.example.com {}
peer transcoder2.example.com {}

# Ingest streams:
stream tvchannel1 {
  input udp://239.0.1.1:5500;
  transcoder vb=2048k preset=veryfast ab=128k vb=1024k preset=veryfast ab=64k;
  cluster_ingest;
}
stream tvchannel2 {
  input udp://239.0.1.2:5500;
  transcoder vb=2048k preset=veryfast ab=128k vb=1024k preset=veryfast ab=64k;
  cluster_ingest;
}

Транскодер 2

cluster_key mysecretkey;

# Remote sources:
peer transcoder1.example.com {}
peer transcoder2.example.com {}

# Ingest streams:
stream tvchannel1 {
  input udp://239.0.1.1:5500;
  transcoder vb=2048k preset=veryfast ab=128k;
  cluster_ingest;
}
stream tvchannel2 {
  input udp://239.0.1.2:5500;
  transcoder vb=2048k preset=veryfast ab=128k;
  cluster_ingest;
}

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

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

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

Запись архива

Серверы, на которых будет храниться архив — это origin-серверы (origin1.example.com и origin2.example.com). В нашем примере они будут выполнять ретрансляцию потоков от транскодера к edge-серверам CDN, одновременно записывая идентичный архив, чтобы в случае отказа одного из серверов сохранилась резервная копия на втором.

DVR 1

cluster_key mysecretkey;

# Remote sources:
source transcoder1.example.com {
  dvr dvr/origin1 2d;
}
source transcoder2.example.com {
  dvr dvr/origin1 2d;
}

DVR 2

cluster_key mysecretkey;

# Remote sources:
source origin1.example.com {
}
source transcoder1.example.com {
  dvr dvr/origin2 2d;
}
source transcoder2.example.com {
  dvr dvr/origin2 2d;
}

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

Раздача

Сервера в CDN будут выступать в роли рестримеров, ретранслируя все потоки с предыдущего звена пайплайна (в нашем случае серверов DVR) и кешируя недавние запросы к DVR:

Сервер CDN 1

cluster_key mysecretkey;

source origin1.example.com {
  cache /storage/cache 2d;
}

source origin2.example.com {
  cache /storage/cache 2d;
}

Сервер CDN 2

cluster_key mysecretkey;

source origin1.example.com {
  cache /storage/cache 2d;
}

source origin2.example.com {
  cache /storage/cache 2d;
}

Реализуемый Flussonic Media Server механизм рестриминга гарантирует, что каждый поток будет передаваться на каждый edge-сервер только один раз.

Запросы к архиву будут прозрачно проксироваться на соответствующий сервер DVR, и полученное видео будет кешироваться на edge-сервере. Благодаря кешу последующие запросы к тому же содержимому будут выполняться быстрее. Подробнее о кешировании читайте здесь. См. также Кластеризация DVR об особенностях доступа к архиву в распределенной среде видеодоставки.

Поскольку CDN — последний узел пайплайна перед отдачей потока клиентам, здесь можно добавить авторизацию и/или определить список стран, из которых разрешен просмотр.

Масштабирование CDN

При раздаче большого количества видео у вас скорее всего будет несколько серверов CDN в каждом регионе, и нужно будет решать вопрос с распределением нагрузки. Для этого можно настроить балансировщик нагрузки для каждого из регионов, например по такой схеме:

На схеме показано, что с сервера DVR идет ретрансляция живого видео, а когда пользователь обращается к незакешированному архиву, то отправляется и архив. Клиент получает все видео с edge-серверов и не знает о существовании DVR и других звеньев пайплайна, а балансировщик только выполняет редиректы, т.е. видео через него не передается.