Перестаньте использовать шлюз как простую трубу: что он на самом деле делает
By Mirko Peters ·
Добро пожаловать обратно в блог-сопровождение к подкасту! Если вы когда-либо смотрели на вращающийся значок, пока обновление набора данных Power BI едва ползёт, или если ваши корпоративные панели постоянно прерываются по тайм-ауту именно тогда, когда руководство больше всего в них нуждается, вы, скорее всего, ищете причину не там. Слишком многие архитекторы и администраторы воспринимают шлюз данны
Automatically translated with AI from the original post. Read the English original

Добро пожаловать обратно в блог-сопровождение к подкасту! Если вы когда-либо смотрели на вращающийся значок, пока обновление набора данных Power BI едва ползёт, или если ваши корпоративные панели постоянно прерываются по тайм-ауту именно тогда, когда руководство больше всего в них нуждается, вы, скорее всего, ищете причину не там. Слишком многие архитекторы и администраторы воспринимают шлюз данных Power Platform как простую сантехническую деталь — пассивную трубу, которая лишь перекачивает данные между локальными базами данных и облаком. Это далеко от истины.
В этом посте мы подробно разберём архитектурную реальность шлюза. Мы рассмотрим, как он работает как мощный движок обработки и почему игнорирование его конфигурации буквально губит производительность отчётов. Если вы хотите глубже разобраться в этих архитектурных концепциях и послушать живой разбор реальных сценариев устранения неполадок, обязательно послушайте связанный эпизод подкаста: Configure the Power Platform Data Gateway for Reliable Connectivity.
Давайте заглянем под капот и посмотрим, как шлюз на самом деле работает, а также какие конкретные шаги помогут превратить его из узкого места в высокоскоростную магистраль.
Непонятый посредник: что на самом деле делает шлюз
Чтобы исправить производительность шлюза, сначала нужно понять, что происходит «под капотом», когда облачный сервис обращается к локальному источнику данных. На бумаге схема потока данных выглядит обманчиво простой: служба Power BI обращается к кластеру шлюзов, кластер обращается к хост-машине, хост-машина выполняет запрос к вашему источнику данных, а затем результаты проходят тот же путь в обратном направлении. Но это не пассивный ретранслятор.
Шлюз выполняет тяжёлую работу на каждом из этих этапов. Он обрабатывает процедуры аутентификации, завершает и заново устанавливает шифрование Transport Layer Security (TLS), преобразует полезную нагрузку запросов и управляет большими буферами памяти. Поскольку он отвечает за шифрование, преобразование запросов и буферизацию временных файлов, машина шлюза представляет собой полноценный движок обработки. Относиться к нему как к легковесному промежуточному ПО — верный путь к катастрофе.
Также внимательно посмотрите на режим развёртывания. Шлюз в персональном режиме строго предназначен для сценариев с одним пользователем и никогда не должен использоваться для общих корпоративных отчётов. Для производственных нагрузок необходимо развернуть стандартный шлюз данных — желательно в кластерной конфигурации из двух и более узлов для обеспечения высокой доступности и балансировки нагрузки. Кроме того, современные архитектуры могут использовать шлюзы данных Azure VNet, чтобы исключить входящий внешний доступ, что порадует службы безопасности и при этом обеспечит надёжную производительность.
Настройки по умолчанию и скрытые убийцы производительности
При установке нового экземпляра шлюза данных Power Platform установщик использует консервативные настройки по умолчанию, рассчитанные на то, чтобы он работал «из коробки» практически на любом оборудовании. К сожалению, в корпоративной среде эти настройки по умолчанию становятся незаметными убийцами производительности.
Возьмём, к примеру, параллелизм. По умолчанию шлюз часто работает с осторожной очередью, которая ограничивает количество параллельно выполняемых запросов. Если мощное оборудование простаивает, а обновления выстраиваются в очередь друг за другом, вы теряете ресурсы. Нужно увеличить лимиты параллельных запросов, чтобы они соответствовали реальной мощности вашего хоста.
Размер буферов — ещё одна серьёзная ловушка. Если буферы слишком малы, шлюз вынужден сбрасывать данные на диск, что создаёт серьёзные узкие места ввода-вывода. Дайте оперативной памяти немного пространства. Кроме того, убедитесь, что антивирусное ПО службы безопасности настроено с правильными исключениями. Сканирование в реальном времени каталогов установки, кэша и журналов шлюза может полностью остановить обработку запросов, ведь каждый временный файл будет тщательно проверяться.
Нам также нужно поговорить о настройке StreamBeforeRequestCompletes. Хотя она может значительно повысить производительность в локальных сетях с низкой задержкой, над высокоуровневыми VPN она создаёт серьёзные риски. И наконец, остерегайтесь эффекта «амнезии после обновления». Каждый раз, когда вы обновляете программное обеспечение шлюза, конфигурация по умолчанию может сбрасываться и стирать ваши пользовательские настройки. Всегда повторно применяйте свои настройки производительности сразу после обновления шлюза.
Сетевой фактор: маршрутизация, задержка и реальность «холодного картофеля»
Можно поставить на узел шлюза самое дорогое оборудование, но если сетевая маршрутизация изначально построена неправильно, производительность всё равно будет страдать. Задержка накапливается на каждом сетевом переходе, и плохая маршрутизация полностью нивелирует все остальные оптимизации.
Многие организации попадают в ловушку: весь трафик направляется через корпоративные VPN и централизованные веб-прокси «для контроля». На деле этот ненужный обходной путь добавляет сотни миль физического расстояния, дополнительные сетевые переходы и ресурсоёмкие задержки на проверку TLS. Вместо этого позвольте трафику как можно быстрее выходить локально к ближайшей точке присутствия Microsoft (POP). Попав в эту периферийную точку, трафик по оптимизированной глобальной магистральной сети Microsoft напрямую доходит до места назначения.
Для чувствительной и интерактивной аналитики настройте предпочтения сетевой маршрутизации Microsoft, чтобы обеспечить высший уровень производительности. Стандартные варианты маршрутизации через интернет оставьте только для массовых передач данных с низким приоритетом. Отказ от обходного пути через корпоративный VPN часто оказывается единственным самым эффективным изменением, которое может сделать организация, чтобы сократить время обновления отчётов.
Оборудование и размещение: как построить полноценный узел шлюза
Поскольку шлюз является мощным вычислительным механизмом, его запуск на слабой общей виртуальной машине с избыточным распределением ресурсов — верный путь к сбоям. Относитесь к узлу шлюза как к инфраструктуре корпоративного уровня «первого класса».
С точки зрения оборудования ориентируйтесь на базовую конфигурацию не менее 16 ГБ оперативной памяти, 8 и более физических ядер процессора и быстрые SSD или NVMe-накопители для кэша и файлов журналов. Виртуальные машины вполне допустимы, но необходимо строго резервировать ресурсы процессора и памяти и никогда не допускать их избыточного распределения.
Чтобы исключить единые точки отказа и масштабировать пропускную способность, развёртывайте кластеры шлюзов как минимум из двух узлов. Крайне важно, чтобы все узлы кластера имели одинаковые номера версий и согласованные конфигурации. Чтобы убедиться, что оборудование подобрано правильно, измеряйте то, что действительно важно, с помощью встроенного отчёта Gateway Performance и счётчиков Windows Performance Monitor (PerfMon), отслеживающих загрузку ЦП, потребление ОЗУ, private bytes и продолжительность выполнения запросов.
Проактивная оптимизация и рекомендации по обслуживанию
Инфраструктура требует постоянного внимания, и шлюзы данных не исключение. Одна из самых распространённых административных ошибок — включение автоматических обновлений на производственных шлюзах. Внезапное необработанное обновление программного обеспечения может изменить файлы конфигурации или вызвать проблемы совместимости, которые нарушат работу критически важных отчётов.
Вместо этого создайте тестовую среду, в которой обновления проверяются до переноса в производственную. Всегда поддерживайте резервные копии настроек кластера и источников данных, чтобы быстро восстановиться, если что-то пойдёт не так. Создавайте еженедельные панели мониторинга состояния, которые сопоставляют пики обновлений с расписанием, что позволит равномерно распределять ресурсоёмкие нагрузки во времени.
Используйте скрипты PowerShell для автоматических проверок состояния, которые отслеживают состояние службы, версии программного обеспечения и глубину очереди, и настройте плановые корректные перезапуски служб в периоды минимальной нагрузки. Документируйте версии сборок ОС, версии .NET Framework, открытые порты и исключения антивируса. Отношение к шлюзу как к реальной инфраструктуре означает применение дисциплинированного ИT-управления к его повседневной эксплуатации.
Контрольный список для надёжного подключения
Чтобы сразу применить эти концепции на практике, вот краткий практический контрольный список, который можно скопировать, вставить и обсудить с командой:
- Проверьте режим: убедитесь, что используется стандартный шлюз (никогда не личный), и что кластер состоит минимум из двух узлов.
- Настройте параллелизм: увеличьте количество параллельных запросов на источник данных и узел и размеры буферов, контролируя использование ОЗУ.
- Оптимизируйте хранилище: размещайте кэш и журналы шлюза на быстрых SSD или NVMe-дисках и настройте полноценные исключения антивируса.
- Оцените потоковую передачу: проверьте настройку StreamBeforeRequestCompletes с учётом реальной сетевой задержки.
- Исправьте маршрутизацию: направляйте исходящий трафик локально и обходите ненужные VPN или прокси для конечных точек Microsoft 365 и Power Platform.
- Приоритизируйте трафик: убедитесь, что для аналитического трафика включены предпочтения маршрутизации Microsoft Network.
- Подберите оборудование: убедитесь, что на хосте не меньше 16 ГБ ОЗУ и 8 и более физических ядер, а при виртуализации заранее зарезервированы ресурсы.
- Контролируйте производительность: включите отчёт Gateway Performance и подключите счётчики PerfMon.
- Автоматизируйте проверку состояния: внедрите проверки состояния на PowerShell и плановые корректные перезапуски служб.
- Управляйте обновлениями: устанавливайте обновления ПО сначала на вторичных узлах, храните резервные копии конфигурации и документируйте операционную базовую линию.
Заключение
Шлюз данных Power Platform — это гораздо больше, чем простой мост или «глупый канал». Это сложный обрабатывающий механизм, который находится в самом сердце вашей гибридной аналитической архитектуры. Отказавшись от настроек по умолчанию, оптимизировав маршрутизацию сети с использованием глобальной магистрали Microsoft, инвестировав в правильное аппаратное обеспечение хоста и поддерживая строгие операционные привычки, вы можете полностью устранить узкие места при обновлении данных и обеспечить молниеносную отчётность, которой требует ваша организация.
Если вы хотите глубже разобраться в этих архитектурных принципах и получить ещё больше практичных советов, которые помогут сэкономить драгоценные минуты в окнах обновления, обязательно послушайте подкаст-выпуск Configure the Power Platform Data Gateway for Reliable Connectivity. Слушайте, подписывайтесь и берите под контроль сетевое подключение вашей организации уже сегодня!