Как разместить шлюз приложений Azure в бэкэнд-пуле Azure Load Balancer
На следующей схеме показано, как балансировщик нагрузки Azure отправляет трафик на шлюз приложений Azure:
Как на самом деле настроить балансировщик нагрузки Azure для этого? При настройке внутреннего пула я могу выбирать только виртуальные машины в группе доступности - я не могу выбрать шлюз приложений.
Я думаю, что изображение вводит в заблуждение, конечные точки Azure Load Balancer - это либо «виртуальные машины Azure», либо «экземпляры ролей облачных служб» https://azure.microsoft.com/en-us / documentation / articles / load-balancer-overview /
Вместо вложения в подсистему балансировки нагрузки используйте диспетчер трафика, вы можете вложить профили диспетчера трафика Azure. https://azure.microsoft.com/en-us/documentation/articles/traffic-manager-endpoint-types/
Вышеприведенный рисунок был призван проиллюстрировать иерархию вариантов балансировки нагрузки в Лазурном веке. Это не то, как опции балансировки нагрузки взаимодействуют с точки зрения пути передачи данных. Это попытка показать, как они соотносятся и где играют. Вы можете смешивать и сопоставлять их в зависимости от того, что вам нужно для вашего приложения.
Пара моментов:
Azure Load Balancer - это многопользовательская платформа балансировки нагрузки 4-го уровня, которая является частью стека Azure SDN и обеспечивает балансировку нагрузки на поток для UDP и TCP служб.
Application Gateway - это балансировщик нагрузки HTTP/HTTPS и WAF, и использует Azure Load Balancer для фронтенда компонентов, из которых состоит шлюз приложений (Application Gateway). Это делается неявно за вас, как часть продукта шлюза приложений, а не то, что вам нужно настраивать в качестве клиента. По сути, мы используем Azure Load Balancer для настройки некоторых систем водопровода под шлюзом приложений. Вот почему фронтэндинг шлюза Azure Application Gateway с Azure Load Balancer - это уже нечто, это уже происходит.
Traffic Manager - это глобальная балансировка нагрузки DNS, где CNAME возвращается клиенту на основе профиля TM. Профиль TM, который вы определяете, управляет тем, как будет определяться CNAME, возвращаемый клиенту. А затем клиент использует свой преобразователь для определения места назначения для потока, который он создаст непосредственно для этого места назначения. Диспетчер трафика не находится в пути данных потока приложений. Вы можете установить фронтенд для всего, что имеет публичный IP адрес конечной точки, а не внутренние конечные точки внутри vnet (без публичного IP или ILPIP уровня инстанции).
Лучший подход заключается в том, чтобы подумать об архитектуре приложения и рассмотреть, какие уровни могут существовать и какие функции выполняет каждый из уровней, а также как он может взаимодействовать со следующим. Например, Вы можете поместить TM поверх конечных точек, подверженных воздействию шлюза приложений, чтобы иметь балансировку нагрузки HTTP и WAF (и неявно использовать балансировщик нагрузки для балансировки нагрузки шлюза приложений и обеспечения высокой доступности), а затем использовать балансировщик нагрузки на бэкэнде для обеспечения высокой доступности для кластера SQL AlwaysOn. Или вы можете использовать Load Balancer для балансировки нагрузки на собственный HTTP прокси-слой, возможно множество различных опций. Мы предоставляем набор инструментов для клиентов
.