Доступность и непрерывность бизнес-процессов в Когнитивном поиске Azure

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

Высокий уровень доступности

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

Для каждой отдельной службы поиска корпорация Майкрософт гарантирует доступность не менее 99,9% для конфигураций, удовлетворяющих перечисленным ниже критериям.

  • Две реплики для обеспечения высокой доступности рабочих нагрузок для чтения (запросов).

  • Три реплики или больше для обеспечения высокой доступности рабочих нагрузок чтения и записи (запросов и индексирования)

Для уровня "Бесплатный" Соглашение об уровне обслуживания отсутствует. Дополнительные сведения см. в статье Соглашение об уровне обслуживания для Когнитивного поиска Azure.

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

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

зоны доступности;

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

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

В настоящее время Когнитивный поиск Azure поддерживает Зоны доступности для служб поиска уровня "Стандартный" или выше, которые были созданы в одном из следующих регионов:

Регион Развертывание
Восточная Австралия 30 января 2021 г. или более поздней версии
Южная Бразилия 2 мая 2021 г. или более поздней версии
Центральная Канада 30 января 2021 г. или более поздней версии
Центральная Индия 20 января 2022 г. или более поздней версии
Центральная часть США 4 декабря 2020 г. или более поздней версии
Восточная Азия 13 января 2022 г. или более поздней версии
Восточная часть США 27 января 2021 г. или более поздней версии
восточная часть США 2 30 января 2021 г. или более поздней версии
Центральная Франция 23 октября 2020 г. или более поздней версии
Центрально-Западная Германия 3 мая 2021 г. или более поздней версии
Восточная Япония 30 января 2021 г. или более поздней версии
Республика Корея, центральный регион 20 января 2022 г. или более поздней версии
Северная Европа 28 января 2021 г. или более поздней версии
Восточная Норвегия; 20 января 2022 г. или более поздней версии
Центрально-южная часть США 30 апреля 2021 г. или более поздней версии
Юго-Восточная Азия 31 января 2021 г. или более поздней версии
Центральная Швеция 21 января 2022 г. или более поздней версии
южная часть Соединенного Королевства 30 января 2021 г. или более поздней версии
US Gov (Вирджиния) 30 апреля 2021 г. или более поздней версии
Западная Европа 29 января 2021 г. или более поздней версии
западная часть США 2 30 января 2021 г. или более поздней версии
Западная часть США — 3 2 июня 2021 г. или более поздней версии

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

Несколько служб в разных географических регионах

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

  • Непрерывность бизнес-процессов и аварийное восстановление (BCDR) (Когнитивный поиск не обеспечивает мгновенную отработку отказа в случае сбоя).
  • Глобально развернутые приложения. Если запросы и индексирование приходят со всего мира, у пользователей, ближайших к центру обработки данных узла, будет более высокая производительность. Создание дополнительных служб в регионах близко к этим пользователям может выровнять производительность для всех пользователей.
  • Многоклиентские архитектуры иногда вызывают две или более служб.

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

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

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

Cross-tab of services by region

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

Поддержка синхронизации данных в нескольких службах

Существует два варианта, позволяющих обеспечить синхронизацию двух или более распределенных служб поиска: использовать либо индексатор службы Когнитивного поиска Azure, либо API Push (называемый также REST API Когнитивного поиска Azure).

Вариант 1. Использование индексаторов для обновления содержимого в нескольких службах

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

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

Single data source with distributed indexer and service combinations

Вариант 2. Использование REST API для отправки обновлений содержимого в несколько служб

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

Использование Диспетчера трафика Azure для координации запросов

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

Cross-tab of services by region, with central Traffic Manager

Аварийное восстановление и простои службы

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

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

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

Альтернативные варианты резервного копирования и восстановления

Так как Когнитивный поиск Azure не является основным решением для хранения данных, корпорация Майкрософт не предоставляет формальный механизм для самостоятельного резервного копирования и восстановления. Тем не менее вы можете использовать пример кода для резервного копирования и восстановления индекса из этого репозитория примеров, созданных на основе платформы .NET для службы Когнитивного поиска Azure, чтобы создать резервную копию определения индекса и моментального снимка в виде последовательности JSON-файлов, а затем при необходимости использовать эти файлы для восстановления индекса. Это средство также может перемещать индексы между уровнями служб.

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

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

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