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

Note

Поиск с использованием ИИ Azure доступна через портал Azure, REST API и Azure SDKs. Он также лежит в основе Foundry IQ — управляемого слоя знаний, который преобразует корпоративный контент в многократно используемые базы знаний с учетом разрешений доступа для агентов на портале Microsoft Foundry.

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

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

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

Зачем использовать несколько регионов?

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

  • Устойчивость к отказам в регионах. Если произошел сбой, Azure ИИ Поиск не обеспечивает мгновенное переключение на резервный регион.

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

Архитектура с несколькими регионами

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

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

На следующей схеме показан географически распределенный набор служб поиска:

Диаграмма, показывающая перекрёстное представление служб по регионам.

Пример Bicep с несколькими регионами

Попробуйте запустить этот пример, чтобы развернуть службы поиска ИИ Azure в нескольких регионах с отработкой отказов, управляемой Azure Front Door: Azure-Samples/azure-search-multiple-regions.

Развертывание создает идентичные службы поиска ИИ Azure в двух регионах и предоставляет их через API функций Azure .

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

Синхронизация данных

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

  • Отправка содержимого в индекс с помощью Document — Index (REST API) или эквивалентного API в пакетах SDK Azure.
  • Извлечение содержимого в индекс с помощью индексатора.

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

Место расположения данных

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

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

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

Запрос на переключение и перенаправление

Для избыточности на уровне запроса Azure предоставляет несколько вариантов балансировки нагрузки:

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

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

При оценке этих параметров балансировки нагрузки рассмотрите следующие моменты:

  • Поиск ИИ Azure — это серверная служба, которая обрабатывает запросы на индексирование и запросы от клиента.

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

  • Поиск ИИ Azure принимает запросы, адресованные конечной точке <your-search-service-name>.search.windows.net . Если вы достигнете той же конечной точки, используя другое DNS-имя в заголовке узла, например CNAME, запрос отклоняется.

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