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

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

• Веб-уровень — это верхний слой, включающий пользовательский интерфейс. Этот слой анализирует взаимодействие пользователей и передает действия следующему уровню для обработки.

• Бизнес-уровень обрабатывает взаимодействие пользователей и принимает логические решения о следующих шагах. Этот уровень соединяет веб-уровень и уровень данных.

• Уровень данных хранит данные приложения с помощью базы данных, хранилища объектов или хранилища файлов.

Распространенные сценарии приложений включают любое критически важное приложение, работающее в Windows или Linux, например предварительно созданное приложение, например SAP или пользовательское бизнес-приложение (LOB).

Архитектура

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

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

Следующий рабочий процесс соответствует предыдущей схеме:

1. Пользователи получают доступ к переднему ASP.NET веб-уровню через Диспетчер трафика Azure. Диспетчер трафика перенаправляет трафик на основной общедоступный IP-адрес в основном исходном регионе. Общедоступный IP-адрес перенаправляет вызов на один из экземпляров виртуальной машины веб-уровня через общедоступную подсистему балансировки нагрузки.

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

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

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

4. В других регионах развёртывайте виртуальные машины на каждом уровне в пределах одной группы доступности.

5. Вы можете настроить уровень базы данных для использования групп доступности AlwaysOn. Эта конфигурация SQL Server использует одну первичную реплику чтения и записи в группе доступности и до восьми вторичных реплик только для чтения. Если первичная реплика завершается ошибкой, группа доступности переводит вторичную реплику в состояние первичной. Вторичная реплика выполняет действие чтения и записи и сохраняет доступ к приложению. Дополнительные сведения см. в статье Обзор групп доступности AlwaysOn (SQL Server).

6. В сценариях аварийного восстановления можно настроить асинхронную репликацию SQL Always On в целевой регион, используемый для DR. Вы также можете настроить репликацию Azure Site Recovery в целевом регионе, если скорость изменения данных находится в пределах поддерживаемых ограничений Site Recovery.

   Для вторичной конечной точки диспетчера трафика задан общедоступный IP-адрес в целевом регионе, используемом для аварийного восстановления. При возникновении сбоя в основном регионе активируется процесс отработки отказов Site Recovery, и приложение становится активным в целевом регионе. Конечная точка диспетчера трафика автоматически перенаправляет трафик клиента на общедоступный IP-адрес в целевом регионе.

Компоненты

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

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

• Azure Load Balancer — это подсистема балансировки нагрузки уровня 4, которая распределяет входящий трафик в соответствии с определенными правилами и пробами работоспособности для высокой пропускной способности и низкой задержки. В этой архитектуре общедоступная подсистема балансировки нагрузки распределяет входящий трафик клиента между виртуальными машинами веб-уровня. Внутренние подсистемы балансировки нагрузки направляют трафик из веб-уровня в бизнес-уровень и из бизнес-уровня в серверный кластер SQL Server.

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

• Site Recovery — это служба аварийного восстановления, которая реплицирует виртуальные машины в другой регион Azure для обеспечения непрерывности бизнес-процессов и аварийного восстановления (BC/DR). В этой архитектуре Site Recovery реплицирует виртуальные машины в целевой регион. Эта репликация восстанавливает приложения во время сбоев в исходном регионе и поддерживает требования к соответствию с помощью периодических учений по аварийному восстановлению.

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

• Вы можете использовать другие операционные системы вместо Windows. Инфраструктура не зависит от конкретной операционной системы.

• Вы можете заменить систему хранения данных на SQL Server для Linux.

• Хранилище данных можно заменить любым стандартным приложением базы данных.

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

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

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

• Azure Front Door (облачное сетевое решение от Microsoft)
• Traffic Manager

При выборе подсистемы балансировки нагрузки учитывайте требования и набор функций двух предложений. Учтите скорость переключения на резервные ресурсы, затраты на управление Transport Layer Security (TLS) и ограничения затрат организации.

Azure Front Door имеет возможности уровня 7. Он включает в себя, в частности: разгрузка Secure Sockets Layer (SSL), маршрутизация на основе путей, быстрый отказоустойчивый механизм и кэширование. Эти возможности повышают производительность и высокий уровень доступности приложения. Azure Front Door стоит больше, чем диспетчер трафика. Используйте полный набор функций в Azure Front Door, а не только функции отказоустойчивости, чтобы оправдать более высокую стоимость. Azure Front Door направляет трафик через сетевую инфраструктуру Azure ранее в пути, что снижает время перемещения пакетов.

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

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

Вы можете объединить оба балансировщика нагрузки. Например, используйте Диспетчер трафика для обеспечения отказоустойчивости на основе DNS и добавьте точки присутствия Azure Front Door (POP) для более быстрой пограничной маршрутизации.

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

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

Эту архитектуру можно использовать для:

• Развертывание высоконадежных приложений, таких как SAP и другие критически важные бизнес-приложения.
• Разработка плана BC/DR для приложений для управления бизнес-процессами.
• Настройте аварийное восстановление и проведите связанные учения в целях соблюдения требований.

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

Эти рекомендации реализуют основные принципы Azure Well-Architected Framework, которые являются набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Для получения дополнительной информации см. в руководстве Well-Architected Framework.

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

Безопасность обеспечивает гарантии от преднамеренного нападения и неправильного использования ценных данных и систем. Дополнительные сведения см. в контрольном списке проектных проверок по безопасности.

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

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

Оптимизация затрат

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

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

• Лицензирование Site Recovery на виртуальную машину.

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

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

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

Эффективность производительности

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

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

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основной автор:

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

Чтобы увидеть непубличные профили LinkedIn, войдите на сайт LinkedIn.

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

• Развертывание Диспетчера трафика в Azure
• Настройка аварийного восстановления для виртуальных машин Azure

Связанный ресурс

• Мультирегиональная архитектура балансировки нагрузки