Высокий уровень доступности и устойчивость для проектов и служб агента Microsoft Foundry

Важно

Элементы, помеченные (предварительная версия) в этой статье, в настоящее время находятся в общедоступной предварительной версии. Эта предварительная версия предоставляется без соглашения об уровне обслуживания, и мы не рекомендуем ее для рабочих нагрузок. Некоторые функции могут не поддерживаться или могут иметь ограниченные возможности. Дополнительные сведения см. в разделе Supplemental Terms of Use for Microsoft Azure Previews.

Планирование обеспечения непрерывности бизнес-процессов и подготовка к аварийному восстановлению с помощью Microsoft Foundry.

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

Важно

Система Foundry сама по себе не обеспечивает автоматический переход в случае отказа или аварийное восстановление.

Необходимые условия

  • Подписка Azure. Если у вас нет учетной записи, создайте бесплатную учетную запись.
  • Учетная запись и проект Microsoft Foundry. Дополнительные сведения см. в кратком руководстве Microsoft Foundry.
  • Azure CLI установлен (необязательно для применения блокировок ресурсов с помощью командной строки).
  • Соответствующие роли RBAC:
    • Владелец или участник группы ресурсов для развертывания и настройки ресурсов.
    • Администратор доступа пользователей для назначения ролей RBAC управляемым удостоверениям.
    • оператор Cosmos DB для настройки Azure Cosmos DB.
    • участник службы Search для настройки Поиск с использованием ИИ Azure.
    • участник учетной записи Storage для настройки служба хранилища Azure.

Важно

Microsoft и вы совместно управляете службой агента Foundry. Microsoft запускает уровень управления и платформу узла возможностей. Вы обеспечиваете устойчивость зависимостей с сохранением состояния (Azure Cosmos DB, Поиск с использованием ИИ Azure, служба хранилища Azure) при использовании режима развертывания агента Standard. В базовом режиме Microsoft управляет этими компонентами данных, и параметры восстановления ограничены. Эта модель общей ответственности означает, что проект высокого уровня доступности и аварийного восстановления должен охватывать каждый управляемый клиентом компонент по отдельности.

Определение служб Azure для Foundry

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

Категории служб включают:

  • Платформная инфраструктура (управляемая Microsoft): компоненты уровня управления и сервис метаданных проекта, которые эксплуатируются в регионе Microsoft.
  • Optional рабочая нагрузка и ресурсы интеграции (управляемые клиентом): служба хранилища Azure, Azure Key Vault, Реестр контейнеров Azure (ACR), Application Insights, Azure Logic Apps, Функции Azure, Поиск с использованием ИИ Azure, Azure Cosmos DB, Сетка событий Azure, SharePoint, Microsoft Purview (явное подключение) и другие целевые объекты подключения.
  • Connections: объекты конфигурации, ссылающиеся на внешние Azure или службы SaaS. Вы владеете конфигурацией высокого уровня доступности.

Ни один из этих необязательных ресурсов, таких как Key Vault, хранилище, ACR и Application Insights, не являются жесткими зависимостями самой модели ресурсов Foundry, хотя ваше решение может потребовать их. Проектируйте с учётом каждой рабочей нагрузки и избегайте предположений о фиксированном обязательном наборе.

Тип ресурса Примеры служб Управляется Заметки о доступности
Инфраструктура платформы Контрольная плоскость Foundry, метаданные проекта Microsoft Региональный; действия не требуются со стороны клиента для конфигурации зоны.
Хранилища состояний (стандартный режим агента) Azure Cosmos DB, Поиск с использованием ИИ Azure, служба хранилища Azure Вы Настройте избыточность, резервное копирование, репликацию.
Безопасность и секреты Azure Key Vault Вы Автоматическая избыточность зоны, если поддерживается; настройте RBAC и защиту от очистки.
Мониторинг Application Insights Вы Рассмотрим многорегиональные виртуальные машины или стратегию резервного переключения.
Реестр изображений и артефактов Реестр контейнеров Azure Вы При необходимости используйте георепликацию.
Интеграция и рабочий процесс Logic Apps, Функции, Сетка событий Вы Согласуйте стратегию региона и восстановления после аварий с зависимостями агента.
Соответствие требованиям и сопоставление данных Microsoft Purview (подключено) Вы Включите непрерывность для сценариев обнаружения электронных данных.
Другие источники знаний и инструментов SharePoint, пользовательские API Вы Настройте для каждой службы высокий уровень доступности.

В остальной части этой статьи объясняется, как сделать каждый компонент высокодоступным.

Предотвращение аварий и потери данных

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

Предотвращение удаления ресурсов

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

В следующей таблице описываются защиты и ограничения для каждого ресурса:

Ресурс Защита, предоставленная Ограничения
Учетная запись Foundry Запрещает удаление учетных записей, проектов, моделей, подключений и узлов возможностей агента. Не защищает отдельные агенты или потоки.
учетная запись Azure Cosmos DB Запрещает удаление учетной записи, enterprise_memory базы данных и контейнеров. Не защищает данные в контейнерах.
служба Поиск с использованием ИИ Azure Запрещает удаление экземпляра службы поиска. Не защищает индексы или данные в индексах.
учетная запись служба хранилища Azure Запрещает удаление контейнеров учетных записей и BLOB-объектов. Не защищает отдельные BLOB'ы. Пользователи с ролью владельца могут удалить блокировку перед удалением контейнера.

Для обеспечения глубокой устойчивости можно объединить блокировки ресурсов с эффектом Политика Azure для предотвращения запросов на удаление ресурсного поставщика. Этот многоуровневый подход повышает защиту независимо от возможностей восстановления каждого ресурса.

Следующая команда Azure CLI применяет блокировку удаления к учетной записи Foundry:

az lock create \
  --name "FoundryAccountLock" \
  --lock-type CanNotDelete \
  --resource-group "<your-resource-group>" \
  --resource-name "<your-foundry-account>" \
  --resource-type "Microsoft.CognitiveServices/accounts"

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

az lock list --resource-group "<your-resource-group>" --output table

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

Reference:az lock create

Реализация минимального доступа к привилегиям

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

В рабочей среде не предоставляйте постоянные разрешения на удаление этих ресурсов какому-либо участнику. Для доступа к хранилищам состояний в рамках канала передачи данных только управляемое удостоверение проекта должно иметь длительные разрешения на запись.

Кроме того, можно уничтожить данные с помощью службы агента и REST API. Встроенные роли ИИ, например Пользователь Azure ИИ, могут удалять операционные данные с помощью этих API или портала Foundry. Несчастные случаи или злоупотребление этими API-интерфейсами могут создавать потребности восстановления. Встроенная роль ИИ не считывается только для этих операций плоскости данных. Дополнительные сведения см. в справочнике по REST API Azure AI Foundry. Создайте пользовательские роли, чтобы ограничить доступ к этим действиям данных Microsoft.CognitiveServices/*/write.

Реализация единого принципа ответственности

Посвятите учетную запись Azure Cosmos DB, службу Поиск с использованием ИИ Azure и учетную запись служба хранилища Azure исключительно службе агента ИИ для вашей рабочей нагрузки. Совместное использование этих ресурсов с другими учетными записями Foundry или компонентами рабочей нагрузки повышает риск с помощью более широких поверхностей разрешений и более крупного радиуса взрыва. Несвязанные операции в одной рабочей нагрузке никогда не должны удалять или повреждать состояние агента в другой рабочей нагрузке. Это разделение также позволяет принимать решения по восстановлению отдельных рабочих нагрузок без необходимости следовать подходу по принципу «всё или ничего».

Использование зонально-избыточных конфигураций

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

Настройка ресурсов для поддержки восстановления

Настройте эти ресурсы перед инцидентом. Действия по восстановлению в этом руководстве предполагают применение следующих параметров.

Ресурс Рекомендуемые конфигурации Цель
Учетная запись Foundry Установите явное подключение к Microsoft Purview. Поддерживает непрерывность данных для сценариев соблюдения нормативных требований, таких как запросы eDiscovery после потери данных потока обработки.
Проект Foundry Используйте управляемое удостоверение, назначаемое пользователем, а не управляемое удостоверение, назначаемое системой. Поддерживает восстановление доступа к зависимостям агента без повторного применения назначений ролей.
Служба агента Foundry Используйте режим развертывания агента "Стандартный". Предоставляет больше возможностей восстановления, чем режим "Базовый", который практически не имеет параметров восстановления для потери ресурсов.
Azure Cosmos DB Включите непрерывное резервное копирование с точечным восстановлением во времени. Выберите уровень хранения в течение 7 дней или 30 дней в зависимости от требований восстановления. Справьтесь с последствиями случайного enterprise_memory удаления базы данных, ее контейнеров или всей учетной записи.
Azure Cosmos DB Используйте уникальное, конкретное название организации (например, contoso-agents-cosmosdb). Во время восстановления на заданный момент времени Cosmos DB создает новую учетную запись с исходным именем. Если это имя уже занято, процесс восстановления завершается ошибкой.
Azure Cosmos DB Включите репликацию чтения в назначенный регион отказа и включите отказоустойчивость с управлением службой. Позволяет службе Cosmos DB переключить регион записи из основного региона в дополнительный регион во время длительного сбоя региона.
Поиск с использованием ИИ Azure Используйте уникальное, конкретное название организации (например, contoso-agents-search). Во время восстановления создается новая служба с исходным именем. Если это имя уже занято, процесс восстановления завершается ошибкой.
учетная запись служба хранилища Azure Используйте геоизбыточное хранилище данных (GZRS). Регион восстановления рабочей нагрузки может быть дополнительным регионом для этой учетной записи хранения, но это не обязательно. Позволяет инициировать управляемую клиентом отработку отказа в заранее определённый регион.

Ссылки:

Режимы развертывания и последствия восстановления

В режиме развертывания Standard состояние агента размещается в собственных учетных записях Azure Cosmos DB, Поиск с использованием ИИ Azure и служба хранилища Azure. Эта топология повышает риск инцидентов (например, прямое удаление данных), но обеспечивает контроль над процедурами восстановления. Базовый режим практически не обеспечивает возможности восстановления при потере ресурсов, вызванной действиями человека или автоматизацией.

Совет

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

Использование управляемых удостоверений, назначенных пользователем

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

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

Важно

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

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

Использование методов повторяемого развертывания

Определите учетную запись, проекты, хост возможностей и зависимости в инфраструктуре как код (IaC), например Bicep или Terraform. Для некоторых шагов восстановления требуется повторное развертывание ресурсов точно так же, как они были. IaC рассматривается как источник истины для быстрого воспроизведения конфигурации и назначений ролей. Создайте модульный модуль IaC, чтобы можно было независимо развертывать каждый проект.

Сделайте агенты развертываемыми. Для эфемерных агентов существующий код приложения обычно достаточен. Для долго живущих агентов храните их определения JSON и привязки инструментов или знаний в системе управления версиями и автоматизируйте развертывание с помощью вызовов конвейера к API Foundry. Автоматическое обновление конфигурации клиента для новых идентификаторов агента. Этот процесс восстанавливает определения агентов, файлы знаний и подключения инструментов.

Избегайте неотслеживаемых изменений, внесенных непосредственно на портале Foundry или на портале Azure. Неотслеженные изменения в производственном процессе делают восстановление более медленным и более склонным к ошибкам.

Если вы всё ещё предпочитаете удостоверения, назначаемые системой (вопреки рекомендации по использованию управляемых удостоверений, назначенных пользователем), настройте систему IaC так, чтобы она воссоздавала каждое назначение роли, ссылающееся на главный идентификатор проекта, а не изменяла его. Идентификатор субъекта для назначений ролей неизменяем и не может быть обновлен до нового значения. guid() Используйте выражение, включающее идентификатор субъекта, поэтому повторно созданное удостоверение создает отдельное имя назначения ролей.

В следующем фрагменте кода Bicep показан минимальный шаблон для Cosmos DB с непрерывным резервным копированием и блокировкой ресурсов. Расширьте этот шаблон, используя Поиск с использованием ИИ Azure, служба хранилища Azure (GZRS) и назначения ролей для управляемой учетной записи.

param location string = resourceGroup().location
param cosmosDbName string

resource cosmosDb 'Microsoft.DocumentDB/databaseAccounts@2024-05-15' = {
  name: cosmosDbName
  location: location
  properties: {
    databaseAccountOfferType: 'Standard'
    locations: [
      { locationName: location, failoverPriority: 0, isZoneRedundant: true }
    ]
    backupPolicy: {
      type: 'Continuous'
      continuousModeProperties: { tier: 'Continuous7Days' }
    }
  }
}

resource lock 'Microsoft.Authorization/locks@2020-05-01' = {
  name: '${cosmosDbName}-lock'
  scope: cosmosDb
  properties: {
    level: 'CanNotDelete'
    notes: 'Protect Cosmos DB from accidental deletion.'
  }
}

Минимизация обработки Поиск с использованием ИИ Azure в качестве основного хранилища данных

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

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

Резервное копирование и восстановление данных агента

Устойчивость истории цепочки сообщений зависит от базовых хранилищ состояния режима Standard: базы данных Cosmos DB enterprise_memory, индексов Поиск с использованием ИИ Azure и хранилища двоичных объектов для вложений. Встроенная функция экспорта или импорта для полных историй бесед отсутствует.

Резервное копирование определений агента

Хранение определений JSON агента и ссылок на источники знаний в системе управления версиями. Используйте REST API Foundry для периодического экспорта конфигураций агента:

  1. Перечислите своих агентов, путем вызова API агент для получения идентификаторов агентов, имен, связи с инструментами и настроек источников знаний.
  2. Сохраните каждое определение агента в виде JSON-файла в системе управления версиями.
  3. Включите привязки инструментов, ссылки на файлы знаний и конфигурации подключений вместе с каждым определением агента.
  4. Автоматизируйте этот процесс в конвейере CI/CD по регулярному расписанию (например, ежедневно или после каждого развертывания).

Совет

Вы можете автоматизировать экспорт агента с помощью пакета SDK Azure AI Projects для Python или API REST. Пакет SDK предоставляет методы для перечисления агентов, получения конфигураций и сериализации их в JSON для управления версиями.

Восстановление из резервной копии Cosmos DB на определённый момент времени.

enterprise_memory Если база данных или ее контейнеры случайно удалены:

  1. Откройте портал Azure и перейдите к учетной записи Cosmos DB.
  2. Выберите точку во времени восстановления и выберите метку времени восстановления перед удалением.
  3. Укажите новое имя целевой учетной записи для восстановленных данных.
  4. После завершения восстановления обновите подключение службы Foundry Agent, чтобы указать восстановленную учетную запись Cosmos DB.
  5. Проверьте функциональные возможности агента, выполнив тестовую беседу в восстановленной среде.

Вы также можете инициировать восстановление с помощью Azure CLI:

az cosmosdb restore \
  --account-name <source-account-name> \
  --target-database-account-name <restored-account-name> \
  --restore-timestamp "2026-01-15T10:00:00Z" \
  --location <region> \
  --resource-group <resource-group>

Примечание

Восстановление Cosmos DB методом точечного восстановления по времени создает новую учетную запись базы данных. При использовании управляемых удостоверений, назначенных системой, необходимо обновить строку подключения Agent Service и повторно применить назначения ролей. Назначаемые пользователем управляемые удостоверения снижают эту нагрузку.

Сохранение данных соответствия

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

Перестроение индексов Поиск с использованием ИИ Azure

Если служба Поиск с использованием ИИ Azure потеряна или повреждена, перестройте индексы из надежных источников данных:

  1. Создайте новую службу Поиск с использованием ИИ Azure в регионе восстановления или используйте вторичную службу, подготовленную в многорегиональном развертывании.
  2. Повторное создание определений индекса из шаблонов IaC или файлов схемы, управляемых источником.
  3. Повторное заполнение индексов путем выполнения конвейера приема данных в исходных источниках данных (например, Хранилище BLOB-объектов Azure, База данных SQL Azure или Cosmos DB).
  4. Обновите ссылки на источник знаний агента, чтобы указать новую конечную точку службы поиска.
  5. Проверьте полноту индекса, выполнив репрезентативные поисковые запросы и сравнивая результаты с известными базовыми показателями.

Планирование многорегионального развертывания

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

  • Региональная доступность: если это возможно, используйте регион в той же географической области, а не обязательно ближайший. Чтобы проверить доступность регионов для Foundry, см. статью Azure продукты по регионам.

  • Azure парные регионы: парные регионы координируют обновления платформы и обеспечивают приоритетное восстановление. Однако не все регионы сопряжены. Дополнительные сведения см. в разделе парные регионы Azure.

  • Доступность службы: Решите, следует ли использовать горячий/горячий, горячий/тёплый или горячий/холодный для ресурсов решения.

    • Горячий/горячий: оба региона активны одновременно, и любой регион готов к немедленному использованию.
    • Горячий/Тёплый: основной регион активен. Дополнительный регион имеет критически важные ресурсы (например, развернутые модели), готовые к запуску. Разверните некритические ресурсы вручную в дополнительном регионе.
    • Горячий или холодный: основной регион активен. В дополнительном регионе развернуты Foundry и другие ресурсы, а также необходимые данные. Развертывайте ресурсы, такие как модели, развернутые модели и конвейеры, вручную.

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

Стратегия Приблизительное время восстановления (RTO) Приблизительное RPO Относительные затраты Лучше всего для
Горячий/горячий Минуты Почти нулю Максимальный уровень: полное дублирование ресурсов, работающих в обоих регионах Рабочие нагрузки с требованиями нулевого простоя
Горячий/теплый 30 минут до 2 часов Минуты в часах в зависимости от задержки репликации Умеренный: критически важные ресурсы, работающие, другие в режиме ожидания Критически важные для бизнеса рабочие нагрузки, допускающие кратковременные перебои.
Горячее/холодное От 2 до 8 часов Часы в зависимости от частоты резервного копирования Наименьшее: ресурсы подготовлены, но не активны Разработка, промежуточные или чувствительные к затратам рабочие нагрузки со сниженными целевыми показателями восстановления.

Совет

В зависимости от бизнес-требований, вы можете по-разному управлять службами Foundry.

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

служба Azure Географическая репликация с использованием Конфигурации
Проекты литейного производства Вы Создайте проекты в выбранных регионах.
Хранилище ключей Microsoft Используйте один и тот же экземпляр Azure Key Vault с проектом и ресурсами Foundry в обоих регионах. Azure Key Vault автоматически переключается на вторичный регион. Дополнительные сведения см. в разделе доступность и избыточность Azure Key Vault.
Учетная запись хранения Вы Проекты Foundry не поддерживают отказоустойчивость учетной записи хранения по умолчанию с помощью гео-избыточного хранилища (GRS), гео-зоновое-избыточное хранилище (GZRS), гео-избыточное хранилище для чтения (RA-GRS) или гео-зоновое-избыточное хранилище для чтения (RA-GZRS). Настройте учетную запись хранения в соответствии с вашими потребностями и используйте ее для проекта. Все последующие проекты используют учетную запись хранения проекта. Дополнительные сведения см. в статье Резервирование служба хранилища Azure.
Реестр контейнеров Azure Вы Включите георепликацию в экземпляре Реестр контейнеров Azure на связанный регион. Используйте один и тот же экземпляр для обоих проектов. Дополнительные сведения см. в разделе Geo-replication in Реестр контейнеров Azure.
Application Insights Вы Создайте Application Insights для проекта в обоих регионах. Для настройки периода удержания данных и сведений см. раздел "Сбор данных, удержание и хранение данных в Application Insights".

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

  1. Используйте шаблоны Azure Resource Manager. Шаблоны — это инфраструктура как код, и они позволяют быстро развертывать службы в обоих регионах.
  2. Чтобы избежать смещения между двумя регионами, обновите конвейеры непрерывной интеграции и развертывания для развертывания в обоих регионах.
  3. Создайте назначения ролей для пользователей в обоих регионах.
  4. Создайте сетевые ресурсы, такие как Azure виртуальные сети и частные конечные точки для обоих регионов. Убедитесь, что пользователи могут получить доступ к обеим сетевым средам. Например, настройте VPN и DNS для обеих виртуальных сетей.

Проектирование высокого уровня доступности

Настройка зон доступности

Некоторые службы Azure поддерживают зоны доступности. В регионах, поддерживающих зоны доступности, если одна зона выходит из строя, службы, настроенные для зональной резервности, продолжают работать. Службы, которые не обеспечивают избыточность в зонах, могут испытывать перебои. Компоненты службы агента, размещенные Microsoft, имеют зоновую избыточность. Убедитесь, что управляемые клиентом зависимости (Cosmos DB, поиск на основе ИИ, хранилище) также настроены для зональной резервированности.

Дополнительные сведения см. в разделе "Поддержка службы зоны доступности".

Развертывание критически важных компонентов в нескольких регионах

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

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

Для подключений, необходимых для обеспечения непрерывности бизнес-процессов:

  1. Создайте два отдельных ресурса в двух разных регионах (например, два ресурса служб ИИ).
  2. Создайте два подключения проекта, по одному для каждого регионального ресурса.
  3. Убедитесь, что оба подключения активны и доступны в приложении.
  4. Развертывание ресурсов для любых критически важных для бизнеса проектов в обоих регионах.

Изоляция хранилища для больших наборов данных

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

  1. Создайте выделенную учетную запись хранения для больших наборов данных, отдельно от основного хранилища проекта.
  2. Оцените стратегию репликации данных (LRS, GRS, GZRS), которая лучше всего подходит для ваших требований к восстановлению.
  3. На портале Foundry создайте подключение к учетной записи хранения данных. Если у вас несколько экземпляров Foundry в разных регионах, можно указать одну и ту же учетную запись хранения. Подключения работают в различных регионах.

Мониторинг раннего обнаружения сбоев

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

  1. Включите оповещения Работоспособность служб Azure для всех служб Azure в рабочей нагрузке Foundry. Работоспособность служб предоставляет предварительное уведомление о плановом обслуживании и раннем предупреждении незапланированных сбоев.
  2. Настройте оповещения о работоспособности resource для Cosmos DB, Azure OpenAI и учетных записей хранения для обнаружения отдельных сбоев ресурсов.
  3. Настройте тесты доступности Application Insights для непрерывной проверки конечных точек агента из нескольких географических расположений.
  4. Определите группы действий оповещений, которые уведомляют операционную команду по электронной почте, SMS или через систему управления инцидентами для быстрого принятия решений о проведении отработки отказа.

Настройка устойчивости развертывания модели

Развертывание моделей Azure OpenAI является важной составляющей большинства рабочих процессов Foundry. Создайте топологию развертывания для обеспечения устойчивости, чтобы региональный сбой или ограничение ресурсов не приводили к отключению вашего приложения. В этом разделе рассматриваются стратегии развертывания "Стандартный" и "Подготовленный", "Шаблоны шлюза API" и вспомогательные инфраструктуры, которые связывают их друг с другом.

Настройка стандартных развертываний

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

Примечание

Если требования к месту размещения данных позволяют это, предпочитайте развертывания Global Standard. Развертывания зоны данных (США/ЕС) — это следующий лучший вариант для организаций, которым требуется обработка данных в пределах географической границы.

Используйте следующий подход для развертываний уровня "Стандартный".

  1. По умолчанию развертывание производится в зонах данных, с возможностью выбора между США и ЕС.
  2. Разверните два ресурса Azure OpenAI в одной подписке Azure. Разместите один ресурс в предпочитаемом регионе, а другой в резервном (для отработки отказа) регионе. Azure OpenAI выделяет квоту на уровне подписки плюс региона, чтобы оба ресурса могли совместно использовать подписку, не влияя на квоту.
  3. Создайте одно развертывание для каждой модели, используемой в основном регионе, и дублируйте эти развертывания модели в дополнительном регионе. Выделите полную доступную квоту в каждом развертывании уровня "Стандартный". Полное выделение обеспечивает более высокую пропускную способность по сравнению с разделением квот по нескольким развертываниям.
  4. Выберите регион развертывания на основе топологии сети. Вы можете развернуть ресурс Azure OpenAI в любом поддерживаемом регионе, а затем создать частную конечную точку для этого ресурса в ближайшем к вашему приложению регионе.
    • После входа трафика в границу Azure OpenAI служба оптимизирует маршрутизацию и обработку по доступным вычислительным мощностям в зоне данных.
    • Маршрутизация между зонами данных более эффективна и проще, чем самоуправляемая балансировка нагрузки в нескольких региональных развертываниях.
  5. Если региональный сбой делает основное развертывание недоступным, перенаправьте трафик на дополнительное развертывание в режиме ожидания в той же подписке.
    • Поскольку как первичное, так и вторичное являются развертываниями в зоне, они используют общий пул емкости зоны для всех доступных регионов зоны. Дополнительное развертывание защищает от недоступности основной конечной точки Azure OpenAI.
    • Используйте шлюз генеративного искусственного интеллекта, поддерживающий балансировку нагрузки и паттерн размыкателя цепи, например Azure API Management, перед конечными точками Azure OpenAI, чтобы свести к минимуму нарушения во время регионального сбоя.
    • Если квота в данной подписке исчерпана, разверните новую подписку таким же образом и поместите ее конечную точку за шлюзом создания искусственного интеллекта.

Настройка подготовленных развертываний

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

Создание пула PTU предприятия

  1. Для подготовленных развертываний создайте одно развертывание PTU зоны данных, которое служит в качестве корпоративного пула PTU. Используйте Azure API Management для управления трафиком из нескольких приложений и настройки ограничений пропускной способности, ведения журнала, приоритета и логики отработки отказа.
    • Думайте о пуле PTU предприятия как о "частном стандартном развертывании", которое защищает от шумно-соседской проблемы. При высоком спросе на стандартные развертывания ваша организация имеет гарантированный, выделенный доступ к пулу емкостей, которым можете пользоваться только вы.
    • Этот подход позволяет контролировать, какие приложения сначала повышают задержку, что позволяет определять приоритет трафика в критически важных приложениях.
    • Подготовленные развертывания поддерживаются соглашениями об уровне обслуживания (SLA) по задержке, которые делают их более предпочтительными по сравнению со стандартными развертываниями для рабочих нагрузок, чувствительных к задержке.
    • Развертывания PTU в корпоративной среде также обеспечивают более высокие показатели использования, поскольку трафик распределяется по рабочим нагрузкам приложений, в отличие от отдельных нагрузок, которые обычно создают больше пиков.
  2. Разместите основное развертывание PTU вашего предприятия в регионе, отличном от региона развертывания основной стандартной зоны. При возникновении регионального сбоя вы не теряете доступ к развертыванию PTU и развертыванию стандартной зоны одновременно.

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

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

  1. Создайте выделенное развертывание PTU для этого приложения.
  2. Поместите пул PTU рабочей нагрузки в другой регион, отличный от пула PTU предприятия, чтобы защититься от региональных сбоев. Например, поместите пул PTU для рабочей нагрузки в регион A, а пул PTU для предприятия — в регион B.
  3. Настройте цепочку обработки отказа, чтобы развертывание, предназначенное для обработки рабочих нагрузок, сначала переключилось на корпоративный пул PTU, а затем на стандартное развертывание. Если использование развертывания PTU рабочей нагрузки превышает 100%, запросы по-прежнему обслуживаются конечными точками PTU, при этом поддерживается более высокий SLA на задержку для этого приложения.

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

Трафик направляется от приложения к развертыванию PTU, специально предназначенному для обработки определенной рабочей нагрузки. Если данное развертывание перегружено (использование превышает 100%), трафик переполняется в корпоративный пул PTU. Если корпоративный пул недоступен, трафик переходит к развертыванию уровня "Стандартный".

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

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

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

Настройка шлюза генеративного ИИ

Шлюз Generative AI Gateway — это обратный прокси-сервер, обычно Azure API Management, который располагается перед конечными точками Azure OpenAI и предоставляет:

  • Балансировка нагрузки между несколькими конечными точками OpenAI Azure.
  • Шаблон разбиения каналов для автоматического обнаружения и маршрутизации между неработоспособными конечными точками.
  • Ограничение скорости и контроль нагрузки для защиты серверной части от всплесков трафика.
  • Централизованное ведение журнала и наблюдаемость во всех конечных точках модели.
  • Приоритетная маршрутизация , поэтому критически важные приложения получают емкость в первую очередь во время конфликтов.

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

Поддержка инфраструктуры для конечных точек модели

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

Потребление через общедоступную инфраструктуру Microsoft

Организации, использующие службу через общедоступную магистраль Microsoft, должны рассмотреть следующие элементы дизайна:

  1. Разверните Генеративный ИИ шлюз таким образом, чтобы обеспечить доступность во время регионального сбоя в Azure. При использовании Azure API Management разверните отдельные экземпляры APIM в нескольких регионах или используйте функцию шлюза multi-region.
  2. Используйте публичный глобальный балансировщик нагрузки для серверов для распределения трафика между несколькими экземплярами шлюза генеративного ИИ в активном/активном или активном/пассивном режиме. Azure Front Door может выполнять эту роль.

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

Azure Front Door распределяет трафик между экземплярами управления API в нескольких регионах. Каждый экземпляр APIM направляет запросы к конечным точкам Azure OpenAI в своем регионе и обеспечивает автоматическое переключение при недоступности региона.

Использование ресурсов через частную сеть

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

  1. Разверните гибридное подключение, чтобы защититься от сбоя Azure региона. Компоненты гибридного подключения включают локальную сетевую инфраструктуру и Microsoft ExpressRoute или VPN.
  2. Разверните гейтуэй генеративного ИИ для обеспечения доступности во время региональных сбоев. При использовании Azure API Management разверните отдельные экземпляры APIM в нескольких регионах или используйте функцию шлюза multi-region.
  3. Разверните частные конечные точки Приватный канал Azure для каждого экземпляра Azure OpenAI в каждом регионе Azure. Для Azure Частная зона DNS используйте подход DNS с разделением мозга, если весь трафик приложений передается через шлюз создания искусственного интеллекта. Этот подход обеспечивает дополнительную защиту от регионального сбоя. Если требуется прямой доступ за пределами шлюза, обновите записи "Частная зона DNS" вручную в случае потери региона Azure.
  4. Используйте частный глобальный балансировщик нагрузки для распределения трафика между экземплярами шлюза генеративного ИИ в активном/активном или активном/пассивном режиме. Azure не предоставляет подсистему балансировки нагрузки собственного глобального сервера для рабочих нагрузок, требующих частного разрешения DNS. Вместо глобальной подсистемы балансировки нагрузки сервера организации могут достичь активно-пассивной схемы, переключив записи DNS для конечной точки шлюза Generative AI.

Инициировать отказоустойчивость

Переключение на резервный проект

Если основной проект недоступен, переключитесь на вторичный проект:

  1. Определите конечную точку вторичного проекта и сведения о подключении из документации по конфигурации или развертыванию IaC.

  2. Обновите конфигурацию приложения, чтобы указать на вторичный проект. Используйте переменные среды или централизованную конфигурацию (например, Конфигурация приложений Azure), а не жестко закодированные ссылки на проекты, чтобы переключение регионов требует только изменения конфигурации:

    • Обновите URL-адрес конечной точки проекта Foundry для вторичного региона.
    • Если вы используете шлюз генеративного ИИ, убедитесь, что автоматический выключатель уже перенаправил трафик на вторичные конечные точки Azure OpenAI.
    • Обновите любые прямые подключения к службам (Cosmos DB, поиск искусственного интеллекта, хранилище), если они не используются совместно в разных регионах.
    # Example: switch to secondary region endpoints
export FOUNDRY_ENDPOINT="https://<secondary-project>.cognitiveservices.azure.com"
export AZURE_OPENAI_ENDPOINT="https://<secondary-aoai>.openai.azure.com"

  3. Проверьте подключение, выполнив тестовый запрос к конечной точке вторичного проекта.

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

Foundry не синхронизирует или не восстанавливает артефакты или метаданные между проектами. Если вы настроите первичные и вторичные проекты, для совместного использования связанных ресурсов с поддержкой георепликации, некоторые объекты будут доступны в проекте аварийного переключения. Например, оба проекта используют одинаковые образы Docker, конфигурируемые хранилища данных и ресурсы Key Vault для Azure.

Проверка готовности переключения при отказе

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

  1. Убедитесь, что проект Foundry в дополнительном регионе, развернутые модели и подключения актуальны и соответствуют конфигурации основного региона.
  2. Запустите репрезентативное задание агента или конвейера во вторичном проекте, чтобы проверить сквозную функциональность, включая доступ к Azure Cosmos DB, Поиск с использованием ИИ Azure и служба хранилища Azure.
  3. Убедитесь, что все назначения ролей RBAC для управляемых удостоверений, пользователей и субъектов-служб находятся в вторичном регионе.
  4. Проверьте разрешение DNS и сетевое подключение, включая частные конечные точки и пути VPN, из клиентских сред в дополнительный регион.
  5. Задокументируйте все пробелы и обновите шаблоны IaC или конвейеры развертывания, чтобы закрыть их до следующего цикла проверки.

Восстановление удаленных ресурсов

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

Сервис Мягкое удаление включено
Проект Foundry Нет
служба хранилища Azure См. статью "Восстановление удаленной учетной записи хранения"
Azure Key Vault Да

Сведения о восстановлении других ресурсов Foundry (учетных записей, проектов) после удаления или очистки сценариев см. в разделе "Восстановление или очистка удаленных ресурсов Foundry".

Устранение распространенных проблем

Проблема Возможная причина Разрешение
Блокировка ресурсов не предотвращает удаление Блокировка, примененная в неправильной области Убедитесь, что блокировка применяется непосредственно к ресурсу, а не только к группе ресурсов. Используется az lock list --resource-group <rg> для подтверждения.
Разрешение RBAC запрещено при настройке Cosmos DB Отсутствующее назначение ролей Убедитесь, что у вас есть роль оператора Cosmos DB или участника в учетной записи Cosmos DB.
Проект переключения на резерв не может получить доступ к общим ресурсам Несоответствие управляемой идентификации При использовании системной назначенной идентификации повторно примените назначение роли. Рассмотрите возможность переключения на управляемое удостоверение, назначаемое пользователем.
Точечное восстановление завершается сбоем для Cosmos DB Непрерывное резервное копирование не включено Включите непрерывную резервную копию перед инцидентом. Этот параметр нельзя применить ретроактивно.
Восстановление Cosmos DB завершается сбоем из-за конфликта именования Имя учетной записи уже используется При создании учетной записи используйте уникальное имя для конкретной организации. При возникновении конфликта восстановите имя учетной записи и обновите подключения службы агента.
Дополнительное развертывание возвращает ошибки квоты Квота не выделена в регионе аварийного переключения Убедитесь, что вы выделили полную квоту как для первичных, так и для вторичных развертываний Azure OpenAI. Проверьте квоту с az cognitiveservices account list-usage --name <account-name> --resource-group <resource-group>.
Разрешение DNS завершается сбоем после аварийного переключения региона. Частные DNS-записи не обновлены Если вы используете Приватный канал без шлюза генеративного ИИ, вручную обновите записи Частная зона DNS, чтобы указать на частные конечные точки вторичного региона.
Агент не может подключиться после переключения Cosmos DB Строка подключения указывает на старую конечную точку Обновите подключение службы агента для ссылки на новую конечную точку учетной записи Cosmos DB. Проверка с помощью тестовой беседы.
Шлюз APIM возвращает 503 во время регионального сбоя Средство разбиения цепи не настроено Настройте шаблон прерывателя цепи в шлюзе генеративного ИИ для автоматической маршрутизации в обход неисправных серверов.

Связанное содержимое

  • Last updated on