Припиніть використовувати шлюз як просту трубу: що він насправді робить
By Mirko Peters ·
Ласкаво просимо назад до блог-супутника подкасту! Якщо ви колись дивилися на крутяще коло, поки оновлення набору даних Power BI тягнеться з льодовиковою повільністю, або якщо ваші корпоративні панелі постійно видають тайм-аут саме тоді, коли керівництво їх найбільше потребує, ймовірно, ви шукаєте причину не в тому місці. Занадто багато архітекторів і адміністраторів сприймають шлюз даних Power Pla
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 Service звертається до кластера шлюзів, той – до host-машини, яка виконує запит до вашого джерела даних, а потім результати повертаються тим самим шляхом. Але це не пасивна ретрансляція.
Шлюз виконує значну роботу на кожному кроці. Він обробляє рукостискання автентифікації, завершує і знову встановлює шифрування Transport Layer Security (TLS), перетворює корисні навантаження запитів і керує великими буферами пам’яті. Оскільки він відповідає за шифрування, перетворення запитів і тимчасову буферизацію файлів, машина шлюзу є повноцінним механізмом обробки. Ставитися до неї як до легковагового проміжного ПЗ – пряма дорога до катастрофи.
Також уважно перегляньте режим розгортання. Шлюз у персональному режимі призначений виключно для сценаріїв з одним користувачем і ніколи не повинен використовуватися для спільних корпоративних звітів. Для продуктивних навантажень слід розгортати стандартний шлюз даних (Standard Data Gateway), бажано в кластерній конфігурації з двома або більше вузлами, щоб забезпечити високу доступність і балансування навантаження. Крім того, сучасні архітектури можуть використовувати шлюзи даних Azure VNet, щоб досягти нульової вхідної відкритості: це тішить команди безпеки й водночас забезпечує надійну продуктивність.
Типові налаштування та приховані вбивці продуктивності
Коли ви встановлюєте новий екземпляр шлюзу даних Power Platform, інсталятор покладається на консервативні типові налаштування, розраховані на те, щоб він працював одразу на будь-якому обладнанні. На жаль, у корпоративному середовищі ці типові налаштування діють як приховані вбивці продуктивності.
Візьмімо, наприклад, паралелізм. «З коробки» шлюз часто працює в ввічливій черзі, яка обмежує паралельне виконання запитів. Якщо потужне обладнання простоює, поки ваші оновлення стоять у черзі одне за одним, ви марнуєте ресурси. Потрібно збільшити ліміти паралельних запитів, щоб вони відповідали реальній потужності вашого host-сервера.
Розмір буферів – ще один серйозний підводний камінь. Якщо буфери занадто малі, шлюз змушений скидати дані на диск, що створює значні вузькі місця вводу-виводу. Дайте вашій оперативній пам’яті трохи простору. Крім того, переконайтеся, що антивірусне ПЗ вашої команди безпеки налаштоване з належними винятками. Постійне сканування в реальному часі каталогів встановлення шлюзу, кешу та журналів може повністю загальмувати обробку запитів, адже кожен тимчасовий файл агресивно перевіряється.
Нам також варто поговорити про параметр StreamBeforeRequestCompletes. Хоча він може суттєво покращити продуктивність у локальних мережах із низькою затримкою, над VPN із високою затримкою він створює серйозні ризики. І наостанок, остерігайтеся ефекту «амнезії після оновлення». Щоразу, коли ви оновлюєте програмне забезпечення шлюзу, конфігурації за замовчуванням можуть скидатися й стирати ваші власні налаштування. Завжди повторно застосовуйте свої налаштування продуктивності одразу після оновлення шлюзу.
Мережевий фактор: маршрутизація, затримка і реальність «cold-potato»
Можна встановити на хост шлюзу найдорожче обладнання, але якщо мережева маршрутизація принципово хибна, продуктивність усе одно страждатиме. Затримка накопичується на кожному мережевому переході, і погана маршрутизація повністю нівелює всі інші оптимізації, які ви намагаєтеся зробити.
Багато організацій потрапляють у пастку, спрямовуючи весь трафік через корпоративні VPN і централізовані веб-проксі «для контролю». Насправді цей непотрібний обхідний шлях додає сотні миль фізичної відстані, зайві мережеві переходи та затримки на ресурсомісткій перевірці TLS. Натомість дозвольте трафіку виходити локально до найближчої точки присутності (POP) периферійної мережі Microsoft якомога швидше. Щойно трафік потрапляє на цю периферійну точку POP, він рухається оптимізованою глобальною магістральною мережею Microsoft безпосередньо до місця призначення.
Для чутливої та інтерактивної аналітики налаштуйте параметри маршрутизації мережі Microsoft, щоб забезпечити найвищу продуктивність. Стандартні варіанти маршрутизації через інтернет залишайте лише для масових передач даних із низьким пріоритетом. Вихід із обхідного шляху через корпоративний VPN часто є найвпливовішою зміною, яку може зробити організація, щоб прискорити оновлення звітів.
Обладнання та хостинг: як побудувати справжній хост шлюзу
Оскільки шлюз є потужним обчислювальним рушієм, запуск його на слабкій спільній віртуальній машині з перевантаженими ресурсами неминуче призведе до збоїв. Ставтеся до хоста шлюзу як до корпоративної інфраструктури першого рівня.
Щодо обладнання, орієнтуйтеся на базові характеристики щонайменше 16 ГБ оперативної пам'яті, 8 або більше фізичних ядер процесора та швидкі SSD- або NVMe-накопичувачі для кешу й журналів. Віртуальні машини цілком прийнятні, але ви маєте гарантувати, що ресурси ЦП і пам'яті строго зарезервовані та ніколи не перевантажуються.
Щоб усунути єдині точки відмови та масштабувати пропускну здатність, розгорніть кластери шлюзів щонайменше з двох вузлів. Дуже важливо, щоб усі вузли кластера мали однакові номери версій і відповідні конфігурації. Щоб перевірити, чи обладнання правильно підібрано, вимірюйте саме те, що справді важливо, використовуючи вбудований звіт Gateway Performance разом із лічильниками Windows Performance Monitor (PerfMon), які відстежують використання ЦП, споживання оперативної пам'яті, private bytes і тривалість виконання запитів.
Проактивна оптимізація та найкращі практики обслуговування
Інфраструктура потребує постійного догляду, і шлюзи даних не є винятком. Одна з найпоширеніших адміністративних помилок — увімкнення автоматичних оновлень на продуктивних шлюзах. Раптове неперевірене оновлення програмного забезпечення може змінити ваші файли конфігурації або спричинити проблеми сумісності, які зламають критично важливі звіти.
Натомість створіть середовище проміжного тестування, де перевіряйте оновлення, перш ніж переносити їх у продуктивне середовище. Завжди підтримуйте резервні копії налаштувань кластера та джерел даних, щоб швидко відновитися, якщо щось піде не так. Створюйте щотижневі панелі моніторингу стану, які співставляють стрибки оновлень із вашим розкладом, що дозволить рівномірно розподіляти ресурсомісткі навантаження в часі.
Використовуйте скрипти PowerShell для автоматичних перевірок стану, які відстежують стан служби, версії програмного забезпечення та глибину черги, і впроваджуйте заплановані плавні перезапуски служб у неробочі години. Документуйте збірки ОС, версії .NET Framework, відкриті порти та винятки для антивірусу. Ставлення до шлюзу як до справжньої інфраструктури означає дотримання дисциплінованого ІТ-врядування в його щоденній експлуатації.
Контрольний список для надійного підключення
Щоб одразу застосувати ці концепції на практиці, ось короткий практичний контрольний список, який можна скопіювати, вставити та переглянути з командою:
- Перевірте режим: переконайтеся, що ви використовуєте стандартний шлюз (ніколи не персональний) і що кластер складається щонайменше з двох вузлів.
- Налаштуйте паралелізм: збільште кількість паралельних запитів на джерело даних і вузол та розміри буферів, одночасно відстежуючи використання оперативної пам'яті.
- Оптимізуйте сховище: розмістіть кеш і журнали шлюзу на швидких SSD- або NVMe-дисках і налаштуйте повні винятки для антивірусу.
- Оцініть потокову передачу: перегляньте параметр StreamBeforeRequestCompletes з огляду на фактичну затримку мережі.
- Виправте маршрутизацію: спрямовуйте вихідний трафік локально та обходьте непотрібні VPN або проксі для кінцевих точок Microsoft 365 і Power Platform.
- Встановіть пріоритет трафіку: переконайтеся, що для аналітичного трафіку ввімкнено параметри маршрутизації Microsoft Network.
- Підберіть апаратне забезпечення: переконайтеся, що хост має щонайменше 16 ГБ оперативної пам'яті, 8+ фізичних ядер і зарезервовані ресурси, якщо він віртуалізований.
- Відстежуйте продуктивність: увімкніть звіт Gateway Performance і підключіть лічильники PerfMon.
- Автоматизуйте перевірку стану: впровадьте перевірки стану на PowerShell та плановані коректні перезапуски служб.
- Керуйте оновленнями: розгортайте оновлення ПЗ на вторинних вузлах, зберігайте резервні копії конфігурації та документуйте свою операційну базову конфігурацію.
Висновок
Power Platform Data Gateway — це значно більше, ніж простий міст або «тупа» труба: це складний обчислювальний механізм, що перебуває в самому серці вашої гібридної аналітичної архітектури. Відмовившись від типових параметрів, оптимізувавши маршрутизацію мережі з використанням глобальної магістралі Microsoft, інвестуючи в належне апаратне забезпечення хоста та дотримуючись суворих операційних практик, ви можете повністю усунути вузькі місця оновлення та забезпечити блискавично швидку звітність, якої потребує ваша організація.
Якщо ви хочете почути глибшу розмову про ці архітектурні принципи та отримати ще більше практичних порад, які дозволять заощадити дорогоцінні хвилини у вікнах оновлення, обов'язково перегляньте епізод подкасту Configure the Power Platform Data Gateway for Reliable Connectivity. Слухайте, підписуйтесь і беріть під контроль корпоративне з'єднання вже сьогодні!