Назад | Перейти на главную страницу

Потоковая передача HTTPS и динамический балансировщик нагрузки с использованием Wowza и AWS

Мы используем Wowza экземпляры для выполнения прямой трансляции на AWS инфраструктура. У нас есть сценарий, который отслеживает балансировщик нагрузки и запускает / уничтожает экземпляры, когда это необходимо, в зависимости от количества подключений / средств просмотра на каждом пограничном сервере. Он хорошо работает для HTTP/RTMP/RTMPT потоковое. Сейчас мы пытаемся реализовать динамическую балансировку нагрузки для HTTPS потоковая передача и автоматизация процесса масштабирования. Для нас главный вопрос - как это лучше автоматизировать? Мы не знаем IP-адреса пограничных серверов, которые будут запущены, поэтому не можем заранее создавать записи DNS.

Одно из возможных решений - зарезервировать некоторое количество эластичных IP-адресов (например, 20) и такое же количество DNS-имен и использовать их во время масштабирования. Но это установит ограничение на количество серверов, которые мы можем запускать динамически.

Есть ли более элегантное решение, которое мы можем попробовать реализовать?

Наша инфраструктура LB находится внутри AWS VPC и у нас есть звездный сертификат, который мы можем использовать. Также, Wowza Load Balancer используется только для сообщения зрителю IP доступного пограничного сервера. После этого программа просмотра напрямую подключается к пограничному серверу.

Вы можете настроить экземпляры для обнаружения их идентичности при запуске, например, передав желаемое имя хоста в Интернете в теге экземпляра или через метаданные экземпляра, и каждый узел отправит запрос API на Route 53 для настройки своей собственной A-записи, по сути заявляя свою идентичность в Интернете при загрузке. Он может отправить второй запрос на удаление этой записи при постепенном завершении работы.

Это механизм, который я использую со спотовыми экземплярами.

Поскольку вы упомянули, что ваш домен не находится в Route 53, вам понадобится обходной путь для этого, если вы не можете переместить весь DNS-хостинг на Route 53, что нет причин не делать, кроме политических / корпоративных возражений. Вы можете сохранить свой домен постановка на учет с текущим регистратором и просто используйте Route 53 для хостинг DNS, конечно.

Вот несколько возможных обходных путей:

Вы можете получить новое доменное имя и поместить его в Route 53. Обратной стороной является то, что вам понадобится новый сертификат.

Вы можете создать поддомен своего домена, делегировав поддомен Route 53 на DNS-серверах вашего базового алмаза с помощью NS записей, но вам все равно понадобится новый сертификат, потому что *.example.com сертификат действителен только для одного уровня имен хостов: foo.example.com работает как положено, но foo.bar.example.com не. Для этого потребуется сертификат для *.bar.example.com.

Итак, обе эти альтернативы нуждаются в новом сертификате.

Другой вариант - использовать Давайте зашифровать и пусть каждый сервер отключится и получит бесплатный сертификат SSL для себя программно при запуске. Это позволит вам использовать любой домен или субдомен без дополнительных затрат на сертификат.

Наконец, вы можете использовать немного взлома DNS. Некоторым это покажется нелогичным, но поскольку Route 53 является авторитетной (не рекурсивной) службой DNS, она работает должным образом.

Создайте зону хостинга для вашего существующего домена в Route 53. Это действительно, даже если ваш DNS не размещен в Route 53.

В размещенной зоне будет назначено 4 сервера имен, обычно в следующем формате:

ns-aaaa.awsdns-bb.com.
ns-cccc.awsdns-dd.net.
ns-eeee.awsdns-ff.org.
nd-gggg.awsdns-hh.co.uk.

Буквы a, b, c и т. Д. - это числа, присвоенные системой.

Возьмите эти записи и используйте их для делегирования определенных имен хостов с существующего DNS-сервера на Route 53.

media-100 IN NS ns-aaaa.awsdns-bb.com.
media-100 IN NS ns-cccc.awsdns-dd.net.

Повторите процесс для каждого из имен хостов «пула» для каждого из четырех назначенных DNS-серверов AWS. Это все еще несколько ограничивает в том смысле, что он ограничивает ваш пул до конечного размера, но в отличие от зарезервированного эластичного IP-решения, этот подход не требует жестких затрат на обслуживание (эластичные IP-адреса оплачиваются по 0,005 доллара США за каждый адрес за каждый час, когда адрес не используется как первичный Эластичный IP работающего экземпляра).

Конечно, ваша основная служба DNS может поддерживать подстановочные знаки, и в этом случае вам понадобится только один набор записей:

media-* IN NS ns-aaaa.awsdns-bb.com ; etc., one for each of the 4 hostnames.

Эти записи NS работают, делегируя разрешение каждого из этих имен хостов Route 53. Поскольку ничто в Интернете не настроено для отправки запросов на эти конкретные 4 сервера имен Route 53 для любых других имен хостов в вашем домене, тот факт, что Route 53 не не знаю о твоем весь зона ничего не ломает.

Потенциально распространенное заблуждение состоит в том, что домен может быть подготовлен только один раз в Route 53 ... но на самом деле у вас может быть несколько размещенных зон для одного и того же доменного имени, в одной или даже в разных учетных записях AWS, потому что каждая из них на размещенные зоны будут отвечать конкретные 4 сервера имен, которые маршрутизируют 53 в эту зону ... Таким образом, даже если вы позже переместили весь свой DNS на Route 53, если вы скопировали другую зону из другого поставщика DNS, как есть, в новая зона размещения на трассе 53 и сделав ее авторитетной, это решение не приведет к конфликту.