Планирование, масштабирование и обслуживание решения шлюза, критического для бизнеса

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

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

Терминология

В этой статье используются следующие важные термины:

• Шлюз: локальное приложение шлюза данных, установленное на компьютере.
• Сервер шлюза: компьютер Windows (виртуальная машина или физический компьютер или сервер), на котором установлено локальное приложение шлюза данных.
• Кластер шлюзов: набор шлюзов, которые работают вместе (и может производиться балансировка нагрузки).
• Член шлюза: шлюз, который является частью кластера шлюза.

На следующем рисунке показана связь между понятиями, определенными выше.

Рекомендации для критически важных для бизнеса шлюзов

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

Чтобы обеспечить оптимальную масштабируемость, производительность и пропускную способность, следуйте рекомендациям в следующих разделах.

Узнайте все ключи восстановления вашего шлюза

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

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

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

Рабочие нагрузки разработки и критически важные для бизнеса рабочие нагрузки

Отделите рабочие нагрузки разработки от критически важных для бизнеса, настроив один или несколько кластеров шлюзов разработки и один или несколько кластеров рабочих шлюзов.

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

Кроме того, используйте кластеры шлюза разработки для тестирования новых обновлений шлюза перед применением обновлений к кластерам шлюзов, критически важных для бизнеса. Новые обновления шлюза должны развертываться не менее 24 часов в кластерах шлюзов разработки, прежде чем использовать их в кластерах шлюзов, критически важных для бизнеса.

Используйте несколько кластеров шлюза

Если вы создаете кластер шлюза для большого количества пользователей в организации, необходимо создать несколько кластеров шлюзов на основе бизнес-единиц или меньше, чтобы ограничить любое потенциальное влияние на производительность небольшим подмножеством пользователей.

Мы не рекомендуем использовать один критически важный для бизнеса кластер шлюза для всей компании (если компания не небольшая). В сценарии с одним кластером шлюза один пользователь может предположительно отправить запрос, который приводит к значительному влиянию производительности на весь трафик через шлюз. Если шлюз используется во всей компании, влияние на производительность может повлиять на всю компанию. Кроме того, если кластер шлюза используется во всей компании, возможно, вам будет сложнее определить, какой запрос может вызвать проблему производительности при использовании функции мониторинга производительности шлюза .

Использование функций высокой доступности и балансировки нагрузки шлюза

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

• Высокий уровень доступности: устраняет одну точку сбоя.
• Балансировка нагрузки. Автоматически распределяет рабочую нагрузку по всем серверам шлюза в кластере.

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

Планирование и обслуживание масштабируемости кластера шлюза

Настройка кластера шлюза с помощью рекомендуемых рекомендаций по оборудованию и программному обеспечению гарантирует, что кластер работает с хорошей производительностью. Шлюзы, которые не масштабируются должным образом, могут привести к низкой производительности. Существует множество факторов, которые необходимо учитывать, чтобы обеспечить хорошую производительность в кластере шлюза.

Определение спецификаций оборудования сервера шлюза

Спецификации сервера шлюза (ЦП, память, диск и т. д.) являются важным фактором, так как в большинстве случаев преобразования Power Query применяются к данным на сервере шлюза. Таким образом, сервер шлюза должен иметь достаточно ресурсов, памяти и мощности обработки для обработки всех преобразований данных.

Если вам нужно выбрать размер сервера, существует две метрики, которые являются наиболее важными: память и ЦП. Для обработки шагов преобразования данных Power Query на шлюзе требуется достаточно памяти и ЦП. Важно, чтобы сервер шлюза был достаточно мощным, чтобы обработать самую высокую рабочую нагрузку. Если сервер шлюза не может обрабатывать рабочую нагрузку, прямой запрос или обновление данных завершится ошибкой. Важно также понять, сколько запросов выполняется одновременно.

Различные параметры запроса оказывают разное воздействие на сервер шлюза.

Тип запроса	Коэффициент ограничения
Импорт	Память
Прямой запрос	ЦП
LiveConnect	ЦП

Во время импорта весь набор данных должен запрашиваться и обрабатываться, что является задачей с большим объемом памяти. Этот импорт часто занимает больше времени. DirectQueries и LiveConnections обычно являются тяжелыми для ЦП. В большинстве случаев прямые запросы выполняются многократно для обработки только небольшой части данных. Так как обрабатывается только небольшая часть данных, эти прямые запросы обычно не являются тяжелой задачей памяти. Однако, так как запросы выполняются многократно по мере необходимости, это может быть требовательным к ресурсам ЦП.

В зависимости от рабочей нагрузки рекомендуется оптимизировать сервер шлюза для памяти или ЦП.

Когда масштабировать кластер шлюза

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

Масштабирование и распределение нагрузки трафика между отдельными узлами в кластере — это сложный процесс, который зависит от каждого отдельного сценария. Хотя не существует окончательной модели, чтобы гарантировать, что весь трафик шлюза прогнозируемо обслуживается, ограничения, перечисленные ниже, указывают на необходимость масштабирования. Как правило, мы рекомендуем масштабировать кластер, добавляя узлы (масштабирование вширь), предпочтительно увеличению ресурсов ЦП, ОЗУ или дискового пространства на отдельных узлах (масштабирование вверх). Масштабирование, как правило, более эффективно в целом в способности всей системы обрабатывать дополнительный трафик. Масштабирование вширь также оказывает положительное влияние на общую пропускную способность кластера, в то время как масштабирование вверх, как правило, на это не влияет. Если один или несколько узлов шлюза указывают на достижение следующих пороговых значений, следует настоятельно учитывать масштабирование кластера.

• ЦП: Температура ЦП превышает 80% в течение длительного времени, однако случайные кратковременные (менее 5 минут) пики, которые полностью загружают ЦП, не являются ненормальными.

• ОЗУ: объем доступной памяти регулярно опускается ниже 20%.

• Диск: Свободное место на диске часто опускается ниже 5 ГБ. Этот спад также может указывать на необходимость более стратегической настройки каталогов кэширования или буферизации.

• Параллелизм: выполнение более 40 запросов одновременно на одном узле.

Поскольку обновления и запросы, распределенные между узлами шлюза, могут иметь сильно разные профили, мы также рекомендуем уделять дополнительное внимание задачам, которые являются длительными или требуют большого объема памяти. Оптимизация запросов в таких случаях может оказать огромное влияние на производительность и масштабируемость, а не только для отдельных отчетов и обновлений, но и на систему в целом. Мы рекомендуем изолировать рассматриваемые обновления на одном выделенном кластере шлюза, чтобы оценить характеристики производительности и провести оптимизацию с помощью диагностики плана запросов, индикаторов сворачивания и всех других опубликованных рекомендаций по производительности. Эта изоляция сводит к минимуму объем извлеченных данных и объем необходимой последующей обработки. Эта изоляция также может использоваться как долгосрочная стратегия для изоляции длительных задач ETL в кластер выделенного шлюза, чтобы уменьшить возникновение конфликтов с другими типичными обновлениями в организации.

Масштабирование кластера шлюза

Увеличение масштаба происходит при увеличении спецификаций (ЦП, памяти, диска и т. д.) серверов шлюза.

Масштабирование может потребоваться, если максимальный объем ЦП или памяти достигается при выполнении одного или нескольких запросов шлюза. Запрос может выполняться только на одном сервере шлюза, поэтому сервер шлюза должен иметь достаточно ресурсов для обработки всего запроса вместе с результирующей данными.

Расширение кластера шлюза

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

Масштабирование путем создания кластеров шлюзов

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

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

Мониторинг и устранение неполадок производительности шлюза

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

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

Если корпорация Майкрософт определяет низкую производительность, вызванную шлюзом или компонентом, связанным с шлюзом, например перегруженной емкостью Power BI Premium, перегруженный компонент необходимо устранить путем масштабирования или снижения нагрузки. Корпорация Майкрософт не изучает низкую производительность при перегрузке шлюза или компонента, связанного с шлюзом.