HTTPS потоковая и динамическая балансировка нагрузки с использованием Wowza и AWS
Мы используем Wowza экземпляры для выполнения прямой трансляции на AWS инфраструктуры. У нас есть скрипт, который отслеживает балансировщик нагрузки и запускает / убивает экземпляры, когда это требуется, в зависимости от количества соединений / просмотрщиков на пограничный сервер. Хорошо просыпается для HTTP/RTMP/RTMPT потоковое видео. Сейчас мы пытаемся реализовать динамическое распределение нагрузки для HTTPS потоковая передача и автоматизация процесса масштабирования. Главный вопрос для нас - как это автоматизировать наилучшим образом? Мы не знаем IP-адресов пограничных серверов, которые будут запущены, поэтому не можем заранее создать записи DNS.
Одним из возможных решений было бы зарезервировать некоторое количество эластичных IP-адресов (т. Е. 20) и такое же количество DNS-имен и использовать их во время масштабирования. Но это установит ограничение на количество серверов, которые мы можем запустить динамически.
Есть ли более элегантное решение, которое мы можем попробовать реализовать?
Наша инфраструктура LB находится внутри AWS VPC и у нас есть звездный сертификат, который мы можем использовать. Также, Wowza Load Balancer используется только для того, чтобы сообщить зрителю IP доступного пограничного сервера. После этого зритель подключается к пограничному серверу напрямую.
1 ответ
Вы можете настроить экземпляры так, чтобы они обнаруживали их идентичность при запуске, например, передавая желаемое имя хоста Интернета в экземпляре в теге экземпляра или через метаданные экземпляра, и каждый узел отправлял запрос API на маршрут 53 для настройки своей собственной A-записи, по существу утверждая свою интернет-идентичность, когда он загружается. Он может отправить второй запрос на удаление этой записи при корректном завершении работы.
Это механизм, который я использую с точечными экземплярами.
Поскольку вы упомянули, что вашего домена нет в Route 53, вам понадобится обходной путь для этого, если только вы не сможете переместить весь DNS-хостинг на Route 53, что не является основанием для того, чтобы не делать ничего, кроме политических / корпоративных возражений. Вы можете сохранить регистрацию своего домена у текущего регистратора и просто использовать Route 53 для размещения DNS, конечно.
Вот некоторые возможные обходные пути:
Вы можете получить новое доменное имя и поместить его в маршрут 53. Недостатком здесь является то, что вам потребуется новый сертификат.
Вы можете создать поддомен своего домена, делегировав поддомен для маршрута 53 на DNS-серверах вашего базового алмаза с помощью NS записи, но вам все равно нужен новый сертификат, потому что *.example.com Сертификат действителен только для одного уровня имен хостов: foo.example.com работает как положено, но foo.bar.example.com не. Это потребует сертификат для *.bar.example.com,
Итак, обе эти альтернативы нуждаются в новом сертификате.
Другой вариант - использовать Let's Encrypt, чтобы каждый сервер выходил и получал бесплатный сертификат SSL для себя программно при запуске. Это позволит вам использовать любой домен или поддомен без дополнительных затрат на сертификат.
Наконец, вы можете использовать немного DNS-хакеров. Некоторым это покажется нелогичным, но, поскольку Маршрут 53 является только авторитетной (не рекурсивной) службой DNS, он работает как положено.
Создайте размещенную зону для своего существующего домена на маршруте 53. Это допустимо, даже если ваш DNS не размещен на маршруте 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-сервера на маршрут 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 долл. США за каждый адрес за каждый час, в течение которого адрес является не используется в качестве основного Elastic IP запущенного экземпляра).
Конечно, ваш основной DNS-сервис может поддерживать подстановочные знаки, и в этом случае все, что вам нужно, это один набор записей:
media-* IN NS ns-aaaa.awsdns-bb.com ; etc., one for each of the 4 hostnames.
Эти записи NS работают путем делегирования разрешения каждого из этих имен хостов на Маршрут 53. Поскольку в Интернете ничего не настроено для отправки запросов этим конкретным 4 серверам имен Маршрута 53 на любые другие имена хостов в вашем домене, тот факт, что Маршрут 53 не ' Знание о всей вашей зоне ничего не нарушает.
Потенциально распространенное заблуждение заключается в том, что домен может быть подготовлен только один раз в Route 53... но на самом деле вы можете иметь несколько размещенных зон для одного и того же доменного имени, в одной или даже в разных учетных записях AWS, поскольку каждая из этих на обслуживаемые зоны будут отвечать конкретные 4 сервера имен, которые маршрутизируют 53 в эту зону... Таким образом, даже если впоследствии вы переместили весь свой DNS на маршрут 53, если вы скопировали другую зону из другого поставщика DNS, как есть, в Новая размещенная зона на трассе 53 и сделав это авторитетным, это решение не представит конфликта.