Надежность в поиске ИИ Azure
В Azure надежность означает устойчивость и доступность при сбое или ухудшении работы службы. В службе "Поиск ИИ Azure" надежность может быть достигнута в одной службе или нескольких службах поиска в отдельных регионах.
Разверните одну службу поиска и масштабируйте масштаб для обеспечения высокой доступности. Можно добавить несколько реплик для обработки более высоких индексов и рабочих нагрузок запросов. Если служба поиска поддерживает зоны доступности, реплики автоматически подготавливаются в разных физических центрах обработки данных для дополнительной устойчивости.
Разверните несколько служб поиска в разных географических регионах. Все рабочие нагрузки поиска полностью содержатся в одной службе, которая выполняется в одном географическом регионе, но в сценарии с несколькими службами можно синхронизировать содержимое таким образом, чтобы он был одинаковым во всех службах. Вы также можете настроить решение балансировки нагрузки для распространения запросов или отработки отказа при сбое службы.
Для обеспечения непрерывности бизнес-процессов и восстановления от аварий на региональном уровне планируйте межрегиональная топологию, состоящую из нескольких служб поиска, имеющих одинаковую конфигурацию и содержимое. Пользовательский скрипт или код предоставляет механизм отработки отказа альтернативной службе поиска, если он внезапно становится недоступным.
Высокая доступность
В поиске ИИ Azure реплики копируются в индексе. Служба поиска выполняется по крайней мере с одной репликой и может содержать до 12 реплик. Добавление реплик позволяет службе "Поиск ИИ Azure" выполнять перезагрузку компьютера и обслуживание для одной реплики, а выполнение запросов продолжается на других репликах.
Для каждой отдельной службы поиска корпорация Майкрософт гарантирует доступность не менее 99,9% для конфигураций, удовлетворяющих перечисленным ниже критериям.
Две реплики для обеспечения высокой доступности рабочих нагрузок только для чтения (запросы)
Три или более реплики для обеспечения высокой доступности рабочих нагрузок чтения и записи (запросы и индексирование)
Система имеет внутренние механизмы для мониторинга работоспособности реплики и целостности секций. Если вы подготавливаете определенную комбинацию реплик и секций, система гарантирует уровень емкости службы.
Соглашение об уровне обслуживания (SLA) не предоставляется для уровня "Бесплатный". Дополнительные сведения см. в разделе об уровне обслуживания для поиска ИИ Azure.
Поддержка зоны доступности
Зоны доступности — это возможность платформы Azure, которая разделяет центры обработки данных региона на отдельные группы физических расположений для обеспечения высокой доступности в одном регионе. В службе "Поиск ИИ Azure" отдельные реплики — это единицы назначения зоны. Служба поиска выполняется в одном регионе; ее реплики выполняются в разных физических центрах обработки данных (или зонах) в этом регионе.
Зоны доступности используются при добавлении двух или более реплик в службу поиска. Каждая реплика помещается в другую зону доступности в пределах региона. Если у вас есть больше реплик, чем доступные зоны в регионе службы поиска, реплики распределяются по зонам равномерно. В вашей части нет определенного действия, кроме создания службы поиска в регионе, который предоставляет зоны доступности, а затем настроить службу для использования нескольких реплик.
Необходимые компоненты
- Уровень служб должен быть стандартным или более высоким.
- Регион службы должен находиться в регионе с доступными зонами (перечислены в следующем разделе).
- Конфигурация должна включать несколько реплик: две для рабочих нагрузок запросов только для чтения, три для рабочих нагрузок чтения и записи, которые включают индексирование
Поддерживаемые регионы
Поддержка зон доступности зависит от инфраструктуры и хранилища. В настоящее время в следующей зоне недостаточно хранилища и не предоставляется зона доступности для поиска ИИ 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 г. или более поздней версии |
| Центральная Израиль | 1 апреля 2024 г. или более поздней версии |
| Италия Север | 1 апреля 2024 г. или более поздней версии |
| Восточная Япония | 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 не обеспечивает мгновенной отработки отказа, если произошел сбой.
Быстрая производительность для глобально распределенного приложения. Если запросы на запросы и индексирование приходят из всего мира, пользователи, которые ближе всего к хост-центру обработки данных, работают быстрее. Создание дополнительных служб в регионах с близкой близостью к этим пользователям может равенства производительности для всех пользователей.
Если вам нужны две или несколько служб поиска, создание их в разных регионах может соответствовать требованиям приложения к непрерывности и восстановлению, а также ускорить время отклика для глобальной базы пользователей.
Поиск по искусственному интеллекту 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-адресов или частную конечную точку для безопасности сети. Вместо этого используйте исключение доверенной службы в качестве альтернативы, если обе службы находятся в одном регионе.
Сведения о сбоях служб и катастрофических событиях
Как указано в соглашениях об уровне обслуживания, корпорация Майкрософт гарантирует высокий уровень доступности запросов на индекс, если экземпляр azure AI служба настроен с двумя или несколькими репликами, а также запросы на обновление индекса при настройке экземпляра azure AI служба с тремя или более репликами. Однако встроенный механизм аварийного восстановления отсутствует. Если непрерывная служба требуется в случае катастрофического сбоя за пределами контроля Майкрософт, рекомендуется подготовить вторую службу в другом регионе и реализовать стратегию георепликации, чтобы обеспечить полное избыточность индексов во всех службах.
Клиенты, использующие индексаторы для заполнения и обновления индексов , могут обрабатывать аварийное восстановление с помощью индексаторов, которые извлекают данные из одного источника данных. Две службы в разных регионах, в каждой из которых выполняется индексатор, могут индексировать один источник данных для обеспечения географической избыточности. Если вы индексируете из источников данных, которые также являются геоизбыточными, помните, что индексаторы поиска Azure AI могут выполнять только добавочное индексирование (слияние обновлений из новых, измененных или удаленных документов) из первичных реплик. В событии отработки отказа обязательно перенаправьте индексатор на новую первичную реплику.
Если индексаторы не используются, вы будете использовать код приложения для отправки объектов и данных в разные службы поиска параллельно. Дополнительные сведения см. в разделе "Синхронизация данных в нескольких службах".
Альтернативные варианты резервного копирования и восстановления
Стратегия непрерывности бизнес-процессов для уровня данных обычно включает шаг восстановления из резервного копирования. Так как поиск по искусственному интеллекту Azure не является основным решением для хранения данных, корпорация Майкрософт не предоставляет формальный механизм для самостоятельного резервного копирования и восстановления. Однако вы можете использовать пример кода для резервного копирования индекса в этом репозитории поиска .NET для поиска .NET azure для резервного копирования определения индекса и моментального снимка в ряд JSON-файлов, а затем использовать эти файлы для восстановления индекса при необходимости. Это средство также может перемещать индексы между уровнями служб.
Код приложения, используемый для создания и заполнения индекса, фактически предоставляет возможность восстановления на случай, если индекс будет удален по ошибке. Чтобы перестроить индекс, необходимо удалить его (если он существует), заново создать индекс в службе и перезагрузить, получив данные из основного хранилища данных.
Связанный контент
- Ознакомьтесь с ограничениями служб, чтобы узнать больше о ценовых категориях и ограничениях служб.
- Ознакомьтесь с планом для получения дополнительных сведений о сочетаниях секций и реплик.
- Обзор примера. Использование когнитивного поиска для поддержки сложных сценариев ИИ для получения дополнительных рекомендаций по настройке.