Надежность в поиске ИИ Azure
В Azure надежность означает устойчивость и доступность при сбое или ухудшении работы службы. В службе "Поиск ИИ Azure" надежность может быть достигнута в одной службе или нескольких службах поиска в отдельных регионах.
Разверните одну службу поиска и масштабируйте масштаб для обеспечения высокой доступности. Можно добавить несколько реплика для обработки более высоких индексирования и запросов рабочих нагрузок. Если служба поиска поддерживает зоны доступности, реплика автоматически подготавливаются в разных физических центрах обработки данных для дополнительной устойчивости.
Разверните несколько служб поиска в разных географических регионах. Все рабочие нагрузки поиска полностью содержатся в одной службе, которая выполняется в одном географическом регионе, но в сценарии с несколькими службами можно синхронизировать содержимое таким образом, чтобы он был одинаковым во всех службах. Вы также можете настроить решение балансировки нагрузки для распространения запросов или отработки отказа при сбое службы.
Для обеспечения непрерывности бизнес-процессов и восстановления от аварий на региональном уровне планируйте межрегиональная топологию, состоящую из нескольких служб поиска, имеющих одинаковую конфигурацию и содержимое. Пользовательский скрипт или код предоставляет механизм отработки отказа альтернативной службе поиска, если он внезапно становится недоступным.
Высокая доступность
В службе "Поиск по искусственному интеллекту Azure" реплика копируются копии индекса. Служба поиска выполняется по крайней мере с одним реплика и может содержать до 12 реплика. Добавление реплика позволяет службе "Поиск ИИ Azure" выполнять перезагрузки и обслуживание компьютеров с одной реплика, а выполнение запросов продолжается в других реплика.
Для каждой отдельной службы поиска корпорация Майкрософт гарантирует доступность не менее 99,9% для конфигураций, удовлетворяющих перечисленным ниже критериям.
Две реплики для обеспечения высокой доступности рабочих нагрузок для чтения (запросов).
Три реплики или больше для обеспечения высокой доступности рабочих нагрузок чтения и записи (запросов и индексирования)
Система имеет внутренние механизмы мониторинга реплика работоспособности и целостности секций. Если вы подготавливаете определенную комбинацию реплика и секций, система гарантирует, что уровень емкости для вашей службы.
Для уровня "Бесплатный" Соглашение об уровне обслуживания отсутствует. Дополнительные сведения см. в статье об уровне обслуживания для поиска ИИ Azure.
Поддержка зоны доступности
Зоны доступности — это возможность платформы Azure, которая разделяет центры обработки данных региона на отдельные группы физических расположений для обеспечения высокой доступности в одном регионе. В поиске ИИ Azure отдельные реплика — это единицы назначения зоны. Служба поиска выполняется в одном регионе; его реплика выполняются в разных физических центрах обработки данных (или зонах) в этом регионе.
Зоны доступности используются при добавлении двух или более реплика в службу поиска. Каждая реплика помещается в другую зону доступности в пределах региона. Если у вас больше реплика, чем доступные зоны в регионе службы поиска, реплика распределяются по зонам как можно более равномерно. В вашей части нет конкретных действий, кроме создания службы поиска в регионе, который предоставляет зоны доступности, а затем настроить службу для использования нескольких реплика.
Необходимые компоненты
- Уровень служб должен быть стандартным или более высоким.
- Регион службы должен находиться в регионе с доступными зонами (перечисленными в следующем разделе).
- Конфигурация должна включать несколько реплика: два для рабочих нагрузок запросов только для чтения, три для рабочих нагрузок чтения и записи, которые включают индексирование.
Поддерживаемые регионы
Поддержка зон доступности зависит от инфраструктуры и хранилища. В настоящее время две зоны, объявленные в октябре 2023 года, имеют недостаточно хранилища и не предоставляют зону доступности для поиска ИИ Azure:
- Израиль, центральный регион
- Северная Италия
В противном случае зоны доступности для поиска ИИ Azure поддерживаются в следующих регионах:
| Регион | Развертывание |
|---|---|
| Восточная Австралия | 30 января 2021 г. или более поздней версии |
| Южная Бразилия | 2 мая 2021 г. или более поздней версии |
| Центральная Канада | 30 января 2021 г. или более поздней версии |
| Центральная Индия | 20 января 2022 г. или более поздней версии |
| Центральная часть США | 4 декабря 2020 г. или более поздней версии |
| Северный Китай 3 | 7 сентября 2022 г. или более поздней версии |
| Восточная Азия | 13 января 2022 г. или более поздней версии |
| Восточная часть США | 27 января 2021 г. или более поздней версии |
| Восточная часть США 2 | 30 января 2021 г. или более поздней версии |
| Центральная Франция | 23 октября 2020 г. или более поздней версии |
| Центрально-Западная Германия | 3 мая 2021 г. или более поздней версии |
| Восточная Япония | 30 января 2021 г. или более поздней версии |
| Республика Корея, центральный регион | 20 января 2022 г. или более поздней версии |
| Северная Европа | 28 января 2021 г. или более поздней версии |
| Восточная Норвегия; | 20 января 2022 г. или более поздней версии |
| Центральный Катар | 25 августа 2022 г. или более поздней версии |
| Северная часть ЮАР | 7 сентября 2022 г. или более поздней версии |
| Центрально-южная часть США | 30 апреля 2021 г. или более поздней версии |
| Юго-Восточная Азия | 31 января 2021 г. или более поздней версии |
| Центральная Швеция | 21 января 2022 г. или более поздней версии |
| Северная Швейцария | 7 сентября 2022 г. или более поздней версии |
| Северная часть ОАЭ; | 9 сентября 2022 г. или более поздней версии |
| Южная Часть Великобритании | 30 января 2021 г. или более поздней версии |
| US Gov (Вирджиния) | 30 апреля 2021 г. или более поздней версии |
| Западная Европа | 29 января 2021 г. или более поздней версии |
| Западная часть США 2 | 30 января 2021 г. или более поздней версии |
| Западная часть США 3 | 2 июня 2021 г. или более поздней версии |
Примечание.
Зоны доступности не изменяют условия соглашения об уровне обслуживания службы поиска ВИ Azure. Для обеспечения высокой доступности запросов по-прежнему требуется три или более реплика.
Несколько служб в разных географических регионах
Избыточность служб необходима, если к вашим операционным требованиям относятся:
Требования к непрерывности бизнес-процессов и аварийному восстановлению (BCDR) (поиск ИИ Azure не обеспечивает мгновенной отработки отказа при сбое).
Быстрая производительность для глобально распределенного приложения. Если запросы на запросы и индексирование приходят из всего мира, пользователи, которые ближе всего к хост-центру обработки данных, работают быстрее. Создание дополнительных служб в регионах с близкой близостью к этим пользователям может равенства производительности для всех пользователей.
Если вам нужны две или несколько служб поиска, создание их в разных регионах может соответствовать требованиям приложения к непрерывности и восстановлению, а также ускорить время отклика для глобальной базы пользователей.
Поиск по искусственному интеллекту Azure не предоставляет автоматизированный метод реплика индексов поиска в географических регионах, но существуют некоторые методы, которые могут упростить этот процесс для реализации и управления ими. Эти методы описаны в следующих нескольких разделах.
Цель геораспредездаемого набора служб поиска — иметь два или более индексов, доступных в двух или более регионах, где пользователь направляется в служба Azure AI, который обеспечивает наименьшую задержку:
Эту архитектуру можно реализовать, создав несколько служб и разрабатывая стратегию синхронизации данных. При необходимости можно включить ресурс, например Диспетчер трафика Azure, для маршрутизации запросов.
Совет
Сведения о развертывании нескольких служб поиска в нескольких регионах см. в этом примере Bicep на сайте GitHub , который развертывает полностью настроенное решение для поиска в нескольких регионах. В этом примере приведены два варианта синхронизации индексов и перенаправление запросов с помощью Диспетчер трафика.
Синхронизация данных между несколькими службами
Существует два варианта хранения двух или нескольких разных служб поиска в синхронизации:
- Извлечение обновлений содержимого в индекс поиска с помощью индексатора.
- Отправка содержимого в индекс с помощью API добавления или обновления документов (REST) или эквивалентного API пакета SDK Azure.
Чтобы настроить любой вариант, рекомендуется использовать пример скрипта Bicep в репозитории azure-search-multiple-region , измененных в ваших регионах и стратегиях индексирования.
Вариант 1. Использование индексаторов для обновления содержимого в нескольких службах
Если индексатор уже используется в одной службе, можно настроить второй индексатор во второй службе, чтобы использовать тот же объект источника данных, извлекая данные из того же расположения. Каждая служба в каждом регионе имеет собственный индексатор и целевой индекс (индекс поиска не является общим, что означает, что каждый индекс имеет собственную копию данных), но каждый индексатор ссылается на один источник данных.
Вот высокоуровневый визуальный элемент этой архитектуры.
Вариант 2. Использование REST API для отправки обновлений содержимого в несколько служб
Если вы используете REST API поиска Azure для отправки содержимого в индекс поиска, вы можете синхронизировать различные службы поиска, принудив изменения ко всем службам поиска всякий раз, когда требуется обновление. Убедитесь, что в коде обрабатываются ситуации, когда обновление одной службы поиска завершается сбоем, но для других служб оно выполняется успешно.
Запросы запросов на отработку отказа или перенаправление
Если требуется избыточность на уровне запроса, Azure предоставляет несколько вариантов балансировки нагрузки:
- Диспетчер трафика Azure, используемый для маршрутизации запросов на несколько географически расположенных веб-сайтов, которые затем поддерживаются несколькими службами поиска.
- Шлюз приложений, используемый для балансировки нагрузки между серверами в регионе на уровне приложения.
- Azure Front Door используется для оптимизации глобальной маршрутизации веб-трафика и обеспечения глобальной отработки отказа.
Некоторые моменты следует учитывать при оценке параметров балансировки нагрузки:
Поиск — это серверная служба, которая принимает запросы запросов и индексирования от клиента.
Запросы от клиента к службе поиска должны проходить проверку подлинности. Для доступа к операциям поиска вызывающий объект должен иметь разрешения на основе ролей или предоставить ключ API для запроса.
Конечные точки службы по умолчанию достигаются через общедоступное подключение к Интернету. Если вы настроили частную конечную точку для клиентских подключений, исходящих из виртуальной сети, используйте Шлюз приложений.
Поиск ИИ Azure принимает запросы, адресованные конечной точке
<your-search-service-name>.search.windows.net. Если вы достигнете той же конечной точки, используя другое DNS-имя в заголовке узла, например CNAME, запрос отклоняется.
Поиск ИИ Azure предоставляет пример развертывания с несколькими регионами, который использует Диспетчер трафика Azure для перенаправления запросов, если основная конечная точка завершается ошибкой. Это решение полезно при маршрутизации на клиент с поддержкой поиска, который вызывает только службу поиска в том же регионе.
Диспетчер трафика Azure в основном используется для маршрутизации сетевого трафика между разными конечными точками на основе определенных методов маршрутизации (таких как приоритет, производительность или географическое расположение). Он действует на уровне DNS для направления входящих запросов в соответствующую конечную точку. Если конечная точка, Диспетчер трафика начинает обслуживать запросы, трафик направляется в другую конечную точку.
Диспетчер трафика не предоставляет конечную точку для прямого подключения к поиску ИИ Azure, что означает, что вы не можете поместить службу поиска непосредственно за Диспетчер трафика. Вместо этого предполагается, что поток запросов к Диспетчер трафика, а затем к веб-клиенту с поддержкой поиска и, наконец, к службе поиска на серверной части. Клиент и служба находятся в одном регионе. Если одна служба поиска выходит из строя, клиент поиска запускает сбой и Диспетчер трафика перенаправляется на оставшийся клиент.
Сведения о местонахождении данных в развертывании с несколькими регионами
При развертывании нескольких служб поиска в различных географических регионах содержимое хранится в регионе, выбранном для каждой службы поиска.
Поиск ИИ Azure не будет хранить данные за пределами указанного региона без авторизации. Авторизация неявна при использовании функций, которые записываются в ресурс служба хранилища Azure: кэш обогащения, сеанс отладки, хранилище знаний. Во всех случаях учетная запись хранения — это учетная запись хранения, которую вы предоставляете в выбранном регионе.
Примечание.
Если учетная запись хранения и служба поиска находятся в одном регионе, сетевой трафик между поиском и хранилищем использует частный IP-адрес и происходит через магистральную сеть Майкрософт. Так как используются частные IP-адреса, нельзя настроить брандмауэры IP-адресов или частную конечную точку для безопасности сети. Вместо этого используйте исключение доверенной службы в качестве альтернативы, если обе службы находятся в одном регионе.
Сведения о сбоях служб и катастрофических событиях
Как указано в соглашении об уровне обслуживания (SLA), корпорация Майкрософт гарантирует высокий уровень доступности запросов на запросы индексов при настройке экземпляра Azure AI служба с двумя или более реплика, а также запросы на обновление индекса при настройке экземпляра служба Azure с тремя или более реплика. Однако встроенный механизм аварийного восстановления отсутствует. Если непрерывная служба требуется в случае катастрофического сбоя за пределами контроля Майкрософт, рекомендуется подготовить вторую службу в другом регионе и реализовать стратегию геоизбыточного реплика, чтобы обеспечить полное избыточность индексов во всех службах.
Клиенты, использующие индексаторы для заполнения и обновления индексов , могут обрабатывать аварийное восстановление с помощью индексаторов, которые извлекают данные из одного источника данных. Две службы в разных регионах, в каждой из которых выполняется индексатор, могут индексировать один источник данных для обеспечения географической избыточности. Если вы индексируете из источников данных, которые также являются геоизбыточными, помните, что индексаторы поиска Azure AI могут выполнять только добавочное индексирование (слияние обновлений из новых, измененных или удаленных документов) из первичных реплика. В событии отработки отказа обязательно перенаправьте индексатор на новый первичный реплика.
Если индексаторы не используются, вы будете использовать код приложения для отправки объектов и данных в разные службы поиска параллельно. Дополнительные сведения см. в разделе Поддержка синхронизации данных в нескольких службах.
Альтернативные варианты резервного копирования и восстановления
Стратегия непрерывности бизнес-процессов для уровня данных обычно включает шаг восстановления из резервного копирования. Так как поиск по искусственному интеллекту Azure не является основным решением для хранения данных, корпорация Майкрософт не предоставляет формальный механизм для самостоятельного резервного копирования и восстановления. Однако вы можете использовать пример кода для резервного копирования индекса в этом репозитории поиска .NET для поиска .NET azure для резервного копирования определения индекса и моментального снимка в ряд JSON-файлов, а затем использовать эти файлы для восстановления индекса при необходимости. Это средство также может перемещать индексы между уровнями служб.
Код приложения, используемый для создания и заполнения индекса, фактически предоставляет возможность восстановления на случай, если индекс будет удален по ошибке. Чтобы перестроить индекс, необходимо удалить его (если он существует), заново создать индекс в службе и перезагрузить, получив данные из основного хранилища данных.
Следующие шаги
- Ознакомьтесь с ограничениями служб, чтобы узнать больше о ценовых категориях и ограничениях служб для каждого из них.
- Ознакомьтесь с планом для получения дополнительных сведений о сочетаниях секций и реплика.
- Обзор примера. Использование когнитивного поиска для поддержки сложных сценариев ИИ для получения дополнительных рекомендаций по настройке.