Подключение к кластеру Service Premise Service Fabric

Question

Я выполнил шаги от Microsoft для создания многоузлового локального кластера Service Fabric.Я развернул приложение без сохранения состояния в кластере, и оно, кажется, работает нормально.Когда я подключался к кластеру, я использовал IP-адрес одного из узлов.После этого я могу подключиться через Powershell с помощью Connect-ServiceFabricCluster nodename:19000 и подключиться к веб-сайту Service Fabric Explorer (http://nodename:19080/explorer/index.html).

). Примеры в Интернете показывают, что если я размещаюсь в Azure, я могу подключиться к http://mycluster.eastus.cloudapp.azure.com:19000 и он разрешается, однако я не могу понять, какой эквивалент у меня на локальном компьютере. Я попытался подключиться к моему образцу кластера: Connect-ServiceFabricCluster sampleCluster.domain.local:19000, но это возвращает:

ПРЕДУПРЕЖДЕНИЕ: не удалось связатьсяСлужба имен. Попытка связаться со службой Failover Manager ... ПРЕДУПРЕЖДЕНИЕ: Не удалось связаться со службой Failover Manager, попытка связаться с FMM ... Ложь ПРЕДУПРЕЖДЕНИЕ: такой хост не известен

Connect-ServiceFabricCluster: Конечная точка кластера не являетсядостижимо, проверьте, есть ли проблема с подключением / брандмауэром / DNS.

Я что-то упустил в моей настройке? Должна ли быть где-то центральная запись DNS, которая позволяет мне подключаться к кластеру? ИлиЯ пытаюсь сделать что-то, что не поддерживается в помещении?

Answer 1

Да, вам не хватает балансировщика нагрузки.

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

Обратный прокси-сервер. При подготовке кластера Service Fabric у вас есть возможность установить Обратный прокси-сервер на каждом из узлов кластера.Он выполняет разрешение службы от имени клиента и перенаправляет запрос на правильный узел, который содержит приложение.В большинстве случаев службы, работающие в Service Fabric, работают только на подмножестве узлов.Поскольку подсистема балансировки нагрузки не будет знать, какие узлы содержат запрошенную службу, клиентским библиотекам придется обернуть запросы в повторный цикл, чтобы разрешить конечные точки службы.Использование обратного прокси-сервера решит проблему, так как он работает на каждом узле и точно знает, на каких узлах работает служба.Клиенты вне кластера могут обращаться к службам, работающим внутри кластера, через обратный прокси-сервер без дополнительной настройки.

Источник: AzureService Fabric потрясающий

У меня запущен ресурс Azure Service Fabric, но применяются те же правила.Как говорится в статье, вам понадобится обратный прокси-сервер / балансировщик нагрузки, чтобы решить не только те узлы, на которых запущен API, но и сбалансировать нагрузку между узлами, на которых работает этот API.Таким образом, проверки работоспособности также необходимы, чтобы балансировщик нагрузки знал, какие узлы являются жизнеспособными вариантами для отправки трафика.

Например, Azure создает 2 правила: 1. LBHttpRule на TCP / 19080 сПроверка TCP на порту 19080 каждые 5 секунд с порогом ошибки 2 счета.2. LBRule на TCP / 19000 с TCP-зондом на порту 19000 каждые 5 секунд с порогом ошибки подсчета 2.

Что нужно добавить, чтобы сделать это прямое обращение, это правило, при котором порт 80 следует перенаправлять наваш сервис http порт.Тогда зондом работоспособности может быть зонд http, который находит путь для проверки возврата 200.

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

В Azure-land это снова абстрагировано от использования чего-то вроде API Management для дальнейшей обратной передачи его через прокси-сервер в SSL.Какой беспорядок, но он работает.

Как только ваш балансировщик нагрузки настроен, у вас будет один IP-адрес для управления, публикации и регулярного трафика.