Надежность поисковой системы Azure AI

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

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

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

Рекомендации по развертыванию в рабочей среде для обеспечения надежности

Мы рекомендуем для производственных рабочих нагрузок:

Обзор архитектуры надежности

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

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

Вы также настраиваете количество реплик для службы. В поиске ИИ реплика — это копия поисковой системы вашей службы. Вы можете представить себе реплику как представляющую собой одну виртуальную машину. Каждая служба поиска может иметь от 1 до 12 реплик.

Добавление нескольких реплик позволяет ИИ-поиску:

• Увеличьте доступность службы поиска.

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

• Обработка более высоких индексов и рабочих нагрузок запросов.

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

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

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

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

Важно понимать влияние добавления реплик и секций, так как они влияют на производительность чтения и записи по-разному. Дополнительные сведения о репликах и секциях см. в статье "Оцените и управляйте ёмкостью службы поиска".

Устойчивость к временным сбоям

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

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

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

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

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

Устойчивость к сбоям зоны доступности

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

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

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

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

Требования

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

• Поддержка региона: Поддержка зон доступности зависит от инфраструктуры и хранилища. Список поддерживаемых регионов см. в разделе "Выбор региона" для поиска ИИ.

• Ярус: Служба должна находиться на уровне "Базовый" или выше

• Количество реплик: Служба должна иметь по крайней мере две реплики

  Замечание

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

Распределение экземпляров между зонами

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

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

Себестоимость

Каждая служба поиска начинается с одной реплики. Для избыточности зоны требуется две или более реплики, что увеличивает затраты на запуск службы. Чтобы понять последствия выставления счетов реплик, используйте калькулятор цен.

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

Если служба поиска соответствует требованиям для избыточности зоны, дополнительная конфигурация не требуется. По возможности AI Search пытается разместить реплики в разных зонах доступности.

Планирование ресурсов и управление ими

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

Поведение, когда все зоны работоспособны

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

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

• Репликация данных между зонами: Изменения данных автоматически реплицируются между репликами в зонах доступности. Репликация выполняется асинхронно, что означает, что записи фиксируются в одной первичной реплике перед их репликацией в другие реплики.

Поведение во время сбоя зоны

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

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

• Уведомление: Microsoft не уведомляет вас автоматически об отключении зоны. Тем не менее

  • Вы можете использовать Azure Resource Health для отслеживания работоспособности отдельного ресурса и настроить оповещения о работоспособности ресурсов , чтобы уведомить вас о проблемах.

  • Вы можете использовать службу "Работоспособность служб Azure ", чтобы понять общую работоспособность службы, включая все сбои зоны, и вы можете настроить оповещения о работоспособности служб , чтобы уведомить вас о проблемах.

• Активные запросы: Запросы, которые обрабатываются репликами в зоне сбоя, завершаются. Клиенты должны повторить запросы, следуя инструкциям по обработке временных сбоев.

• Ожидаемая потеря данных: Если затронутая зона доступности содержит только реплики чтения, не ожидается потеря данных.

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

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

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

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

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

Восстановление зоны

Когда зона доступности восстанавливается, AI Search автоматически возобновляет нормальные операции и начинает маршрутизацию трафика к доступным репликам во всех зонах, включая восстановленную.

Тестирование на сбои в зоне

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

Устойчивость к сбоям на уровне региона

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

Индивидуальные решения для нескольких регионов для повышения устойчивости

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

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

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

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

Резервное копирование и восстановление

Так как поиск ИИ не является основным решением для хранения данных, он не предоставляет варианты самостоятельного резервного копирования и восстановления. Однако вы можете использовать index-backup-restore пример для .NET или Python для резервного копирования определения индекса и его документов в ряд JSON-файлов, которые затем используются для восстановления индекса.

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

Соглашение об уровне обслуживания

Соглашение об уровне обслуживания (SLA) для служб Azure описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Для получения дополнительной информации см. Соглашения об уровне обслуживания для онлайн-сервисов.

В ИИ-поиске применяется соглашение об уровне обслуживания доступности к поисковым службам, которые:

• Настроены на использование оплачиваемого уровня.
• Иметь как минимум две реплики для заданий только для чтения (запросы).
• Обеспечьте по крайней мере три реплики для нагрузок, связанных с чтением и записью (запросы и индексирование).

Связанный контент

• Надежность в Azure
• Ограничения служб в поиске ИИ
• Выбор региона для поиска ИИ
• Выбор ценовой категории для поиска ИИ
• Планирование или добавление ресурсов в поисковой системе искусственного интеллекта