нужен балансировщик нагрузки ткани или нет?

Question

Большинство примеров, касающихся сервисной структуры, показывают, что после развертываний конечные точки кластера выглядят волшебно, как указано в сервисном манифесте eg: <cluster-url>:port/api/home

Некоторые люди на форумах упоминают о настройке балансировки нагрузки для обеспечения доступа к порту.

Почему разница во мнениях? Какой путь правильный? Когда я пытался, я никогда не мог получить доступ к развернутой точке доступа / конечной точке в кластере Azure (балансировщик нагрузки настроен или нет). OneBox работал, хотя.

Answer 1

Справка по настраиваемым конечным точкам гласит: «Настраиваемые конечные точки разрешают подключения к приложениям, работающим на этом типе узла. Введите конечные точки, разделенные запятой.». Его можно установить только при создании кластера.

Так что, очевидно, без установки здесь порта, внешний мир никогда не сможет получить доступ к этому порту. Или то, что этот пользователь почувствовал в 2016 году.

Поскольку впереди есть балансировщик нагрузки, и если мы поместим зонд с порта x (открытый) на порт y (backend-pool), и если мы откроем порт y в брандмауэре во всех узлах, он тоже должен работать. Как открыть порт.

Что произойдет, если мы упомянем порт (скажем, 2345) в servicemanifest? Затем SF открывает для нас порт в брандмауэре, и это выглядит так. И если в Loadbalancer есть датчик, указывающий на 2345, он должен работать.

Таким образом, если в балансировщике нагрузки не установлен датчик, установленный нами вручную, он не должен работать.

Answer 2

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

Он работает локально, потому что у вас есть одна конечная точка (localhost (127.0.0.1)> Service), и вы всегда найдете там свое приложение.

В SF вы попадаете в домен, который сопоставляется с балансировщиком нагрузки, который сопоставляется с набором компьютеров, и на одном из компьютеров ваше приложение может работать на нем. (домен> LB IP> Узлы> Сервис).

Первое, что вам нужно знать:

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

• Каждый NodeType имеет один балансировщик нагрузки перед ним, поэтому всегда устанавливайте ограничение размещения для сервиса, чтобы избежать его запуска на другом NodeType, не выставленном извне

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

Существует множество подходов для предоставления этих услуг, вы также можете попробовать:

• Пользователь ReverseProxy, такой как bulti-in , который будет проксировать вызовы ваших сервисов в кластере, не имеет значения, где они находятся.
• Используйте NGINX в качестве шлюза API или обратного прокси-сервера и настройте его для вызова только определенных служб, в этом случае вам необходимо предоставить ему адрес служб, поэтому вам нужно будет обновить список при запуске или остановке служб.
• Использование Управление API Azure для предоставления API, размещенных на SF