Изменить

Многоуровневое веб-приложение для обеспечения высокой доступности и аварийного восстановления

Azure
Azure Arc
SQL Server
Windows

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

  • Веб-уровень. Верхний уровень, который включает пользовательский интерфейс. На этом уровне анализируются действия пользователя, которые затем передаются на следующий уровень для обработки.
  • Бизнес-уровень. Здесь действия пользователя обрабатываются, после чего принимаются логические решения о дальнейших шагах. Этот уровень соединяет веб-уровень и уровень данных.
  • Уровень данных. На этом уровне хранятся данные приложения. Для этого обычно используется база данных, хранилище объектов или хранилище файлов.

В распространенных сценариях все критически важные приложения выполняются в системах под управлением Windows или Linux. К таким приложениям могут относится готовые решения, например SAP и SharePoint, или пользовательские бизнес-приложения.

Потенциальные варианты использования

Другие варианты использования:

  • развертывание высокоустойчивых приложений, например SAP и SharePoint;
  • обеспечение непрерывности бизнес-процессов и аварийного восстановления для бизнес приложений;
  • настройка и отработка аварийного восстановления с соответствии с нормативными требованиями.

Архитектура

Diagram showing the architecture overview of a highly resilient multitier web application.

Скачайте файл Visio для этой архитектуры.

Рабочий процесс

  • Распределяйте виртуальные машины каждого уровня в пределах двух зон доступности в соответствующих регионах. В регионах, не поддерживающих зоны доступности, развертывайте виртуальные машины на каждом уровне в пределах одной группы доступности.
  • Уровень базы данных можно настроить для использования групп доступности Always On. С этой конфигурацией SQL Server одна основная реплика чтения и записи в группе доступности настроена с до восьми дополнительных реплика только для чтения. Если возникла проблема с основным реплика, группа доступности выполняет отработку отказа первичного действия чтения и записи в одну из дополнительных реплика, что позволяет приложению оставаться доступным. Дополнительные сведения см. в статье Обзор групп доступности AlwaysOn (SQL Server).
  • Для сценариев аварийного восстановления можно настроить собственный механизм асинхронной репликации SQL Always On в целевой регион, используемый для аварийного восстановления. Можно также настроить Azure Site Recovery для репликации в целевой регион, если частота изменения данных находится в пределах, заданных Azure Site Recovery.
  • Доступ пользователей к внешнему интерфейсу ASP.NET на веб-уровне осуществляется через конечную точку диспетчера трафика.
  • Диспетчер трафика перенаправляет трафик в основную общедоступную конечную точку (IP-адрес) в основном исходном регионе.
  • С общедоступного IP-адреса вызов перенаправляется в один из экземпляров виртуальной машины веб-уровня через общедоступную подсистему балансировки нагрузки. Все экземпляры виртуальной машины веб-уровня находятся в одной подсети.
  • От виртуальной машины веб-уровня вызов направляется на обработку в один из экземпляров виртуальной машины бизнес-уровня через внутреннюю подсистему балансировки нагрузки. Все виртуальные машины бизнес-уровня находятся в отдельной подсети.
  • На бизнес-уровне операция обрабатывается, и приложение ASP.NET подключается к кластеру Microsoft SQL Server на уровне сервера через внутреннюю подсистему балансировки нагрузки Azure. Эти экземпляры SQL Server уровня сервера находятся в отдельной подсети.
  • Дополнительная конечная точка диспетчера трафика настроена как общедоступный IP-адрес в целевом регионе, используемом для аварийного восстановления.
  • В случае сбоя в основном регионе Azure Site Recovery выполняет отработку отказа, обеспечивая доступность приложения в целевом регионе.
  • Конечная точка диспетчера трафика автоматически перенаправляет пользовательский трафик на общедоступный IP-адрес в целевом регионе.

Компоненты

  • Группы доступности распределяют развернутые в Azure виртуальные машины между несколькими изолированными аппаратными узлами в кластере. В случае сбоя оборудования или программного обеспечения в Azure будет затронута только часть виртуальных машин, а само приложение останется доступным и работоспособным.
  • Зоны доступности защищают приложения и данные от сбоев на уровне центра обработки данных. Зоны доступности — это отдельные физические расположения в пределах одного региона Azure. Каждая зона состоит из одного или нескольких центров обработки данных, оснащенных независимыми системами электроснабжения, охлаждения и сетевого взаимодействия.
  • Azure Site Recovery позволяет реплицировать виртуальные машины в другой регион Azure, обеспечивая непрерывность бизнес-процессов и аварийное восстановление. Можно периодически проводить тестирование аварийного восстановления, чтобы обеспечить соответствие требованиям. Виртуальная машина будет реплицирована с указанными параметрами в выбранный регион, чтобы вы могли восстановить приложения в случае сбоев в исходном регионе.
  • Диспетчер трафика Azure — это подсистема балансировки нагрузки трафика на основе DNS, которая оптимально распределяет трафик между службами в глобальных регионах Azure, обеспечивая высокий уровень доступности и оперативности.
  • Azure Load Balancer распределяет входящий трафик в соответствии с определенными правилами и пробами работоспособности. Подсистема балансировки нагрузки обеспечивает низкую задержку и высокую пропускную способность, а также позволяет выполнять масштабирование до миллионов потоков для всех приложений, которые используют протоколы TCP и UDP. Общедоступная подсистема балансировки нагрузки используется в этом сценарии, чтобы перенаправлять входящий трафик клиента на веб-уровень. Внутренняя подсистема балансировки нагрузки используется в этом сценарии, чтобы перенаправлять трафик, поступающий с бизнес-уровня, в кластер SQL Server.

Альтернативные варианты

  • Windows это не единственная операционная система, поддерживаемая этой инфраструктурой.
  • SQL Server для Linux можно заменить серверным хранилищем данных.
  • Базу данных можно заменить любым стандартным приложением базы данных.

Подробности сценария

В этом сценарии рассматривается многоуровневое приложение, использующее ASP.NET и Microsoft SQL Server. Вы можете выбирать между регионами Azure с поддержкой и без поддержки зон доступности. В первом случае можно развернуть виртуальные машины в исходном регионе в пределах зон доступности, а затем реплицировать их в целевой регион, предназначенный для аварийного восстановления. В втором случае можно развернуть виртуальные машины в зоне доступности и затем реплицировать их в целевой регион.

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

  • Azure Front Door
  • Диспетчер трафика Azure

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

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

Так как Front Door добавляет новый прыжок, добавляются операции безопасности. Если архитектура соответствует нормативным требованиям, могут быть ограничения на дополнительную точку завершения TLS трафика. Наборы шифров TLS, выбранные Front Door, должны соответствовать требованиям безопасности вашей организации. Кроме того, служба Front Door ожидает, чтобы серверные службы использовали сертификаты, используемые корпорацией Майкрософт.

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

Диспетчер трафика — это служба балансировки нагрузки на основе DNS. Она распределяется и выполняет отработку отказа только на уровне DNS. По этой причине эта служба не может выполнять отработку отказа так же быстро, как Front Door. Это связано с распространенными проблемами с кэшированием DNS и системами, не поддерживающими значения срока жизни DNS.

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

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

Рекомендации

Масштабируемость

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

Ссылки на другие статьи о масштабируемости см. в контрольном списке для повышения уровня производительности в Центре архитектуры Azure.

Безопасность

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

Общие рекомендации по разработке безопасных сценариев см. в статье Документация по системе безопасности Azure.

Цены

За выполнение аварийного восстановления виртуальных машин Azure с помощью Azure Site Recovery предусмотрены такие регулярные платежи:

  • Плата за лицензию на Azure Site Recovery для каждой виртуальной машины.
  • Плата за исходящий сетевой трафик, связанный с репликацией изменений в данных с дисков исходной виртуальной машины в другой регион Azure. В Azure Site Recovery реализована функция сжатия данных, чтобы снизить использование ресурсов при передаче данных примерно на 50 %.
  • Плата за хранение данных в расположении восстановления. Размер этой платы обычно соответствует стоимости хранения данных в исходном регионе плюс плата за дополнительный объем, необходимый для хранения точек восстановления в качестве моментальных снимков для восстановления.

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

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.

Автор субъекта:

  • Sujay Talasila | Главный руководитель продукта

Следующие шаги

Дополнительные эталонные архитектуры HADR (высокая доступность и аварийное восстановление) см. в следующих статьях: