Лазурный шлюз как диспетчер приоритетного трафика - PullRequest
Новая
       35

Лазурный шлюз как диспетчер приоритетного трафика

0 голосов
/ 19 ноября 2018

У нас настроен лазурный шлюз уровня WAF V2 (поэтому он будет избыточным по зонам).Он имеет внутренний пул, содержащий 2 WebApps -AppServices (предположительно, основной и дополнительный).

Идея заключалась в том, чтобы использовать шлюз аналогично диспетчеру приоритетного трафика: маршрутизация обычно к первичному WebApp и только маршрутизацияк вторичному WebApp в случае отказа первого.

Проблема заключается в том, что единственный способ, который я нашел, - это упорядочить правила, связанные со слушателями бэкэнд-пула (потому что я считаю, что Azure определяет их приоритетность).согласно порядку их перечисления).Но, учитывая, что оба приложения находятся в одном и том же бэкэнд-пуле, я не уверен, как это сделать.

Так что теперь шлюз случайным образом перенаправляет либо в первое, либо во второе WebApp.

Любые советы или предложениябудет очень признателен,

Спасибо

Примечание. Также мы попытались установить диспетчер трафика между шлюзом и веб-приложениями, но шлюз продолжает подключаться к основному веб-приложению, даже когда он не работает.и его зонд становится неизвестным.

1 Ответ

0 голосов
/ 20 ноября 2018

Application Gateway - это балансировщик нагрузки уровня 7, что означает, что он работает только с веб-трафиком (HTTP / HTTPS / WebSocket).Он поддерживает такие функции, как завершение SSL, схожесть сеансов на основе файлов cookie и циклический перебор для трафика с балансировкой нагрузки .Это указывало на то, что внешний интерфейс шлюза приложения случайным образом распределяет входящие потоки в конечную точку, если обе конечные точки исправны.Таким образом, вы можете видеть, как шлюз случайным образом направляется к первому или второму WebApp.См. Шлюз приложения FAQ .Шлюз приложения не работает как диспетчер трафика на основе приоритетов, который всегда запрашивает основное веб-приложение, если основное веб-приложение не работает.

При неизвестном состоянии работоспособности наиболее распространенной причиной является доступ к бэкэнду.блокируется NSG или пользовательским DNS.Ссылка: Устранение неисправных ошибок шлюза в Application Gateway

...