Рекомендации по надежности для рабочих нагрузок Microsoft Fabric

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

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

Начните с ограничений: знайте свои границы

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

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

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

Fabric это SaaS, так что низкоуровневые настройки инфраструктуры не в ваших руках. У вас по-прежнему есть некоторые варианты. Рабочие нагрузки можно перемещать по емкостям, разделять критически важные конвейеры или использовать шаблоны с несколькими емкостями, чтобы обойти причуды платформы. Всегда сопоставлять зависимости и ограничения визуально, чтобы помочь вашей команде определить, где могут появляться сбои.

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

См.:

• Ограничения хранилища данных
• Ограничения блокнота для инженерии данных
• Основы рабочей области

Узнайте, где происходят сбои

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

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

Определение целей надежности для рабочих нагрузок

Измеряйте надежность по вашим целям. Начните с определения целей уровня обслуживания (SLOS), которые подходят для вашего бизнеса. Fabric гарантирует доступность на уровне 99,9 %, но для ваших конвейеров, заданий Spark и отчетов Power BI могут потребоваться более строгие эксплуатационные целевые показатели. Сосредоточьтесь на SLI, таких как показатели успешного выполнения конвейера, время выполнения заданий, задержка выполнения и использование ресурсов.

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

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

См.:

• Метрики надежности
• Microsoft соглашения об уровне обслуживания

Обеспечьте самовосстановление за счёт избыточности

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

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

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

Компромисс: избыточность на уровне зоны почти невидима, но стратегии между регионами требуют преднамеренной разработки.

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

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

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

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

Надежно масштабируйте вертикально и горизонтально

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

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

Мониторинг метрик и упреждающее наблюдение

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

Fabric предоставляет широкие возможности телеметрии, но сочетайте её с собственными проверками работоспособности и панелями мониторинга. Интеграция с Azure Monitor. Ранние оповещения дают команде время, прежде чем пользователи замечают что-либо. Сопоставляйте журналы и метрики между системами, чтобы определить первопричину, а не только симптом.

Дополнительные сведения о мониторинге рабочих областей см. в статье "Что такое мониторинг рабочей области"

Применение методов самосохранения

Встроенная отказоустойчивость Fabric и так высока, но вы можете еще больше повысить ее:

• Выделенные ресурсы: изолируйте критически важные рабочие нагрузки от "шумных соседей".
• Используйте автомасштабируемую тарификацию для высокоэластичных нагрузок, таких как Spark и хранилища данных.
• Применяйте защиту от скачков напряжения на уровне емкости и рабочей области.
• Включите функцию выставления счетов за превышение объема в качестве меры предосторожности на случай непредвиденных всплесков.
• Модульные рабочие нагрузки: разорвать большие конвейеры или наборы данных на небольшие независимые части. Если один из них завершается ошибкой, остальные продолжают работать.
• Идемпотентные операции: убедитесь, что повторные попытки не приводят к дублированию записей или ошибкам при обработке.
• Логика повторных попыток: сочетайте экспоненциальную задержку с оповещениями, чтобы корректно восстанавливаться после временных сбоев.
• Прерыватели цепи: приостанавливайте запросы к неисправной зависимости, чтобы предотвратить каскадные сбои.

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

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

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

Планирование аварийного восстановления

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

Резервные копии вручную по-прежнему необходимы для критически важных ресурсов за пределами OneLake, таких как конвейеры или архивные наборы данных. Георезервирование позволяет резервным средам быть готовыми взять на себя нагрузку, если основной регион выйдет из строя. Определите целевые показатели точки восстановления (RPO) и времени восстановления (RTO) и регулярно моделируйте переключение на резервную систему. Отрабатывайте восстановление в непродукционных средах, чтобы ваша команда могла уверенно действовать, когда это действительно потребуется.

Проверка надежности

Прямое хаос-тестирование в Fabric невозможно, но вы можете проверить свою среду и зависимости. Имитация неблагоприятных условий: прерывание подключения к источникам данных, внедрение нагрузки для активации регулирования или использование Azure Chaos Studio для задержки в сети или простоя в вспомогательных ресурсах.

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

Дальнейшие действия

Ознакомьтесь с рекомендациями, организованными по основным аспектам. Следуйте инструкциям в разделе "Безопасность".