Google Cloud TCP LB позволяет работать RTMP и HTTP (S)

Question

У меня есть группа экземпляров вычислительного движка, и мне нужно иметь один статический ip (с прокси-сервером LB) и мне нужно получать запросы HTTP (S) и RTMP. Мне нужно прикрепить этот прокси к внешнему домену -> example.com

Я уже пытался использовать HTTP-фунты (не работает RTMP) и TCP-фунты (не могут работать HTTP-запросы), но, возможно, имеется некоторая неправильная конфигурация или мне нужно сделать HTTP-запрос каким-то конкретным способом, чтобы работать на балансировщике нагрузки TCP?

Идеальное решение заключается в том, что когда я отправляю запросы на example.com, запросы HTTP и RTMP должны работать, обходные пути тоже хороши. Теперь все работает, но example.com указывает на IP 1 управляемого экземпляра, поэтому, если масштаб управляемой группы и этот конкретный экземпляр «умрет», example.com указывает на бесполезный IP.

Мне нужно управлять обоими запросами (RTMP и HTTP) на одном и том же бэкэнде (экземпляре группы)

Answer 1

Насколько я понимаю, у вас есть следующие требования

1) Статический внешний IP с прокси LB

2) Необходимо получить запросы HTTP (S) и RTMP.

3) Прокси-сервер подключен к внешнему домену, например example.com

4) Бэкэнд должен быть группой управляемых экземпляров

На основе требований и с учетом Варианты балансировки нагрузки GCP :

1) Балансировщик нагрузки HTTP (S) не вариант, так как он не будет работать с RTMP

2) SSL Proxy LB не поддерживается, так как он не поддерживает порт 80 (пользователь упомянул о HTTP)

3) TCP Proxy LB не вариант, так как он не поддерживает порт 80, поэтому не будет поддерживать HTTP.

4) Сетевой TCP / UDP LB кажется возможным вариантом для этого сценария, поскольку он поддерживает любые внешние порты для балансировки нагрузки, но проблема в том, что у него нет прокси-функции, это просто пропуск ФУНТ.

Краткое описание порта, поддерживаемого GCP LB, можно найти по этой ссылке Поддерживаемые внешние порты для разных GCP LB и сводка балансировщиков нагрузки в облаке.

Google Cloud Platform не предлагает балансировщик нагрузки прокси-типа, который будет одновременно обрабатывать HTTP на порту 80 и другой обычный старый протокол TCP.

Учитывая всю информацию, лучшим вариантом для этого сценария является создание собственных прокси-виртуальных машин и добавление их в целевой пул за балансировщиком сетевой нагрузки. Таким образом, будет показан IP-адрес балансировщика сетевой нагрузки (запросы на example.com переведены на IP-адрес сетевого LB), а функция прокси будет предоставлена ​​пулом виртуальных машин, работающим в качестве целевого пула для этого балансировщика сетевой нагрузки. Причиной наличия нескольких прокси-виртуальных машин за сетевым LB является устранение единой точки отказа, а также избыточности.

Сетевые LB <----> Прокси-виртуальные машины <-> Бэкэнд-виртуальные машины

Или, если вам нужна группа управляемых экземпляров и автоматическое масштабирование,

Сетевой LB <-> Прокси-виртуальные машины <-> Внутренний LB <-> Группа управляемых экземпляров

В этой настройке прокси-виртуальные машины и ILB должны находиться в одном регионе, так как ILB являются региональными.

Кроме того, если вам нужны некоторые рекомендации по настройке прокси-виртуальной машины, документация GCP по « Настройка экземпляра в качестве сетевого прокси » может предоставить некоторые хорошие рекомендации.

Стоит отметить, что Stack Overflow обычно предназначен для разработчиков, а Server Fault предназначен для системных и сетевых администраторов.