Аварийное восстановление и высокий уровень доступности для чатботс в AzureDisaster recovery and high availability for chatbots in Azure

Чтобы настроить аварийное восстановление для постороннего объекта- робота корпоративного класса (чат-бот), сначала проверьте соглашение об уровне обслуживания (SLA), охватывающее целевую точку восстановления (RPO) и целевое время восстановления (RTO) для чат-бот.To set up disaster recovery for an enterprise-grade conversational bot (chatbot), first review the service level agreement (SLA) that cover the Recovery Point Objective (RPO) and Recovery Time Objective (RTO) for the chatbot. Реализуйте шаблоны аварийного восстановления в этой статье, чтобы создать высокодоступные и устойчивые к отказу решения чат-бот для удовлетворения соглашения об уровне обслуживания.Implement the disaster recovery patterns in this article to build highly available and disaster resistant chatbot solutions to meet the SLA.

Описание основных компонентов типичного решения корпоративного уровня чат-бот в Azure см. в разделе " беседа" в корпоративномклассе.For a description of the core components of a typical enterprise-grade chatbot solution in Azure, see Enterprise-grade conversational bot.

ArchitectureArchitecture

Корпоративная Оценка чат-бот в Azure

На этой схеме показано развертывание решения чат-бот в режиме " активный — пассивный отработка отказа" в двух разных регионах Azure для аварийного восстановления.This diagram shows deployment of a chatbot solution in active-passive failover mode in two different Azure regions for disaster recovery.

Скачайте файл Visio этой архитектуры.Download a Visio file of this architecture.

КомпонентыComponents

Решения для аварийного восстановления зависят от вашего соглашения об уровне обслуживания и используемых вами служб Azure.Disaster recovery solutions vary depending on your SLA and the Azure services you use.

Службы, не являющиеся региональнымиNon-regional services

Azure Active Directory (Azure AD), диспетчер трафика Azure, передняя дверца Azure и регистрация службы Azure Bot — это не региональные службы, которые всегда доступны в географических регионах Azure, независимо от доступности или сбоя в регионе.Azure Active Directory (Azure AD), Azure Traffic Manager, Azure Front Door, and Azure Bot Service registration are non-regional services that are always available in Azure geographies, regardless of specific region availability or outage.

Региональные службы с автоматическим переходом на другой ресурсRegional services with automatic failover

Хотя вы подготавливаем Azure Key Vault и Language Understanding Intelligent Service (LUIS) в определенном регионе Azure, эти службы обеспечивают автоматический переход на другой ресурс в другом регионе Azure.Although you provision Azure Key Vault and Language Understanding Intelligent Service (LUIS) in a specific Azure region, these services provide automatic failover to a different Azure region. Дополнительные сведения см. в разделе:For more information, see:

Региональные службы без автоматического перехода на другой ресурсRegional services without automatic failover

Эти службы могут потребовать вашего внимания для обеспечения высокой доступности и аварийного восстановления.These services may need your attention to ensure high availability and disaster recovery.

Разместите все артефакты развертывания и исходного кода в репозитории исходного кода и используйте парные регионы Azure для параллельного развертывания.Keep all deployment and source code artifacts in a source code repository, and use Azure paired regions to deploy them in parallel. Вы можете автоматизировать все следующие задачи развертывания и сохранить их в составе артефактов развертывания.You can automate all the following deployment tasks and save them as part of your deployment artifacts. При развертывании этих служб в двух парных регионах настройте переменные среды API-интерфейса Bot, чтобы они соответствовали конкретным службам в каждом регионе Azure.When you deploy these services in the two paired regions, configure your bot API's environment variables to match the specific services in each Azure region.

  • Обеспечьте синхронизацию основного и дополнительного индексов поиска Azure. Пример приложения для резервного копирования и восстановления индексов службы поиска Azure см. в разделе кнамакербаккупресторе на GitHub.Keep the primary and secondary Azure search indexes in sync. For a sample app to back up and restore Azure search indexes, see QnAMakerBackupRestore on GitHub.
  • Резервное копирование Application Insights с помощью непрерывного экспорта.Back up Application Insights by using continuous export. Хотя вы не можете импортировать экспортированные данные телеметрии в другой ресурс Application Insights, вы можете экспортировать их в учетную запись хранения для дальнейшего анализа.Although you can't currently import the exported telemetry to another Application Insights resource, you can export into a storage account for further analysis.
  • Сведения о настройке высокой доступности и аварийного восстановления учетных записей хранения Azure см. в статье Аварийное восстановление и отработка отказа учетной записи хранения.To set up high availability and disaster recovery for Azure Storage accounts, see Disaster recovery and storage account failover.
  • Разверните API-интерфейс Bot и QnA Maker в план службы приложений Azure в обоих регионах.Deploy the bot API and QnA Maker into an Azure App Service Plan in both regions.
  • После настройки основного и дополнительного стеков используйте диспетчер трафика Azure или переднюю дверцу Azure, чтобы настроить конечные точки и настроить метод маршрутизации как для QnA Maker, так и для API-интерфейса Bot.Once you set up the primary and secondary stacks, use Azure Traffic Manager or Azure Front Door to configure the endpoints and set up a routing method for both QnA Maker and the bot API.
  • Создайте сертификат SSL (SSL) для конечной точки диспетчера трафика и СВЯЖИТЕ SSL-сертификат в службах приложений.Create a Secure Sockets Layer (SSL) certificate for your traffic manager endpoint, and bind the SSL certificate in your App Services.
  • Наконец, используйте диспетчер трафика или конечную точку передней дверцы Azure QnA Maker в Bot и используйте конечную точку диспетчера трафика для API-интерфейса Bot в качестве конечной точки Bot в регистрации службы Azure Bot.Finally, use the Traffic Manager or Azure Front Door endpoint of QnA Maker in your bot, and use the traffic manager endpoint of the bot API as the bot endpoint in Azure Bot Service registration.

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