IaaS — веб-приложение с реляционной базой данных

Шлюз приложений
Бастион
Load Balancer
Диспетчер трафика

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

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

Эта архитектура обеспечивает эффективное использование ресурсов, так как большинство ресурсов активно используются. Все ресурсы, кроме пассивного SQL Server, используются при обработке запросов. Пассивный SQL Server становится активным только в случае сбоя активного SQL Server.

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

Infographic of Availability Zones architecture.

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

Architecture

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

Если активный SQL Server становится недоступным из-за сбоя зоны или локального сбоя, пассивный SQL Server становится активным SQL Server. Подсистема балансировки нагрузки, избыточной между зонами, обнаруживает отработку отказа на новый активный SQL Server и направляет в нее трафик.

Ниже показан сбой зоны 1.

Infographic of a Zone 1 failure

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

Шлюз приложений является избыточным между зонами. Это не влияет на сбой зоны 1 и использует пробы работоспособности для определения доступных виртуальных машин. Если зона 1 недоступна, она направляет трафик только в оставшиеся две зоны. Подсистема балансировки нагрузки, избыточной между зонами, также не влияет на сбой зоны 1 и использует пробы работоспособности для определения расположения активного SQL Server. В этом примере подсистема балансировки нагрузки обнаруживает, что активный SQL Server находится в зоне 3 и направляет в него трафик.

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

Реплицируя виртуальные машины в Зоны доступности, вы можете защитить приложения и данные от сбоя зоны. Это то, как Azure соответствует соглашению об уровне обслуживания на уровне обслуживания (SLA) на уровне обслуживания (SLA) в отрасли, лучшему в отрасли. Сведения о создании решений для обеспечения высокой доступности с помощью Зоны доступности.

Архитектура состоит из следующих компонентов.

Общее

  • Группы ресурсов. Группы ресурсов используются для группирования ресурсов Azure по времени существования, владельцу и другим критериям для управления.

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

Сети и балансировка нагрузки

  • Виртуальная сеть и подсети. Каждая виртуальная машина Azure развертывается в виртуальной сети, которая может быть сегментирована в подсети, по одной подсети для каждого уровня.
  • Шлюз приложений. Azure Шлюз приложений — это подсистема балансировки нагрузки уровня 7. В этой архитектуре избыточное между зонами Шлюз приложений направляет HTTP-запросы в веб-интерфейс. Шлюз приложений также предоставляет Брандмауэр веб-приложений (WAF), который защищает приложение от распространенных эксплойтов и уязвимостей. Номер SKU версии 2 Шлюз приложений поддерживает избыточность между зонами. Одно развертывание Шлюз приложений может запускать несколько экземпляров шлюза. Для рабочих нагрузок запустите по крайней мере две. Дополнительные сведения см. в разделе "Автомасштабирование и избыточное между зонами" Шлюз приложений версии 2 и как Шлюз приложений поддерживает высокий уровень доступности и масштабируемость?.
  • Azure Load Balancer. Azure Load Balancer — это подсистема балансировки нагрузки четвертого уровня. В этой архитектуре избыточный между зонами Azure Load Balancer (цен. категория направляет сетевой трафик с веб-уровня в SQL Server. Так как подсистема балансировки нагрузки, избыточной между зонами, не закреплена в определенной зоне, приложение продолжает распространять сетевой трафик в случае сбоя зоны. Подсистема балансировки нагрузки, избыточной между зонами, используется для обеспечения доступности в случае недоступности активного SQL Server. Номер SKU уровня "Стандартный" Azure Load Balancer поддерживает избыточность между зонами. Дополнительные сведения см. в статье Load Balancer и Зоны доступности.
  • Группы безопасности сети. Группа безопасности сети используется для ограничения сетевого трафика в виртуальной сети. В этой архитектуре веб-уровень принимает только трафик из конечной точки общедоступного IP-адреса. Кроме того, уровень базы данных не принимает трафик из любой подсети, отличной от подсети веб-уровня.
  • Защита от атак DDoS. Платформа Azure обеспечивает защиту от распределенных атак типа "отказ в обслуживании" (DDoS). Для дополнительной защиты рекомендуется использовать Защиту от атак DDoS Azure уровня "Стандартный", в которой улучшены функции устранения рисков от атак DDoS. См. раздел Вопросы безопасности ниже.
  • Бастион Azure. Бастион Azure обеспечивает безопасный и удобный доступ к виртуальным машинам в виртуальной сети по протоколу удаленного рабочего стола (RDP) и Secure Shell (SSH). Это обеспечивает доступ при ограничении открытых общедоступных IP-адресов виртуальных машин в виртуальной сети. Бастион Azure предоставляет экономически эффективную альтернативу подготовленной виртуальной машине для предоставления доступа ко всем виртуальным машинам в одной виртуальной сети.

Microsoft SQL Server

  • SQL Server Always On группы доступности. Группа доступности SQL Server Always On обеспечивает высокий уровень доступности на уровне данных, включив репликацию и отработку отказа. Для отработки отказа используется технология отказоустойчивого кластера Windows Server (WSFC).

  • Облачный свидетель. Отказоустойчивый кластер требует, чтобы более половины его узлов выполнялись, условие, известное как кворум. Если кластер содержит всего два узла, сетевой раздел может привести к тому, что каждый узел считает его основным. В этом случае требуется ресурс-свидетель, чтобы разорвать связи и создать кворум. Свидетель — это ресурс, например общий диск, который может использоваться в качестве средства разбиения связей для установления кворума. Облачный ресурс-свидетель — тип ресурса-свидетеля, в котором используется хранилище BLOB-объектов Azure. Хранилище BLOB-объектов Azure должен использовать избыточные между зонами служба хранилища (ZRS), чтобы не пострадали от сбоя зоны.

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

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

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

Рекомендации по настройке виртуальных машин см. в статье "Запуск виртуальной машины Windows в Azure".

Дополнительные сведения о проектировании виртуальных сетей и подсетей см. в статье Plan virtual networks (Планирование виртуальных сетей Azure).

группы сетевой безопасности;

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

  • Запретите весь входящий трафик от виртуальной сети. (Используйте тег VIRTUAL_NETWORK в правиле.)
  • Разрешить входящий трафик из подсети веб-уровня.
  • Разрешите входящий трафик из самой подсети уровня базы данных. Это правило обеспечивает взаимодействие между виртуальными машинами баз данных, которое необходимо для репликации и отработки отказа базы данных.

Создайте правила 2–3 с более высоким приоритетом, чем первое правило, поэтому они переопределяют его.

Группы доступности SQL Server AlwaysOn

Мы рекомендуем Always On группы доступности для Microsoft SQL Server высокой доступности. Другие уровни подключаются к базе данных с помощью прослушивателя групп доступности. Прослушиватель позволяет клиенту SQL подключаться, не зная имени физического экземпляра SQL Server. Виртуальные машины, которые обращаются к базе данных, должны быть присоединены к домену. Клиент (в этом случае другой уровень) использует DNS для разрешения имени виртуальной сети прослушивателя в IP-адресах.

Настройте группу доступности SQL Server Always On следующим образом:

  • Создайте кластер отказоустойчивой кластеризации Windows сервера (WSFC), группу доступности SQL Server Always On и первичную реплику. Дополнительные сведения см. в разделе начало работы с группами доступности Always On.
  • Создайте внутреннюю подсистему балансировки нагрузки со статическим частным IP-адресом.
  • Создайте прослушиватель группы доступности и сопоставьте DNS-имя прослушивателя с IP-адресом внутренней подсистемы балансировки нагрузки.
  • Создайте правило подсистемы балансировки нагрузки для порта прослушивания SQL Server (по умолчанию используется TCP-порт 1433). Правило подсистемы балансировки нагрузки должно включать плавающий IP-адрес, также называемый прямым ответом от сервера. В результате виртуальная машина будет отправлять ответ клиенту напрямую, что позволяет использовать прямое соединение с первичной репликой.

Примечание

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

Если клиент SQL пытается выполнить подключение, подсистема балансировки нагрузки направляет запрос на подключение в первичную реплику. При отработке отказа на другую реплику подсистема балансировки нагрузки автоматически направляет новые запросы в новую первичную реплику. Дополнительные сведения см. в разделе "Настройка подсистемы балансировки нагрузки для группы доступности на виртуальных машинах сервера Azure SQL".

Отработка отказа закрывает существующие клиентские подключения. После завершения отработки отказа новые подключения направляются в новую первичную реплику.

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

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

Вопросы доступности

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

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

az vm list-skus --resource-type virtualMachines --zone false --location eastus -o table

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

Пробы работоспособности

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

  • Шлюз приложений всегда использует пробу HTTP.
  • Load Balancer может выполнять проверку с помощью ПРОТОКОЛА HTTP или TCP. Как правило, если виртуальная машина запускает HTTP-сервер, используйте пробу HTTP. В противном случае используйте ПРОТОКОЛ TCP.

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

Пробы HTTP отправляют HTTP-запрос GET по указанному пути и прослушивают ответ HTTP 200. Это может быть корневой путь ("/"), или конечная точка мониторинга работоспособности, реализующая пользовательскую логику для проверки работоспособности приложения. Конечная точка должна разрешать анонимные HTTP-запросы.

Дополнительные сведения о пробах работоспособности см. в следующем разделе:

Рекомендации по проектированию конечной точки пробы работоспособности см. в шаблоне мониторинга конечных точек работоспособности.

Рекомендации по затратам

Используйте калькулятор цен Azure для оценки затрат. Ниже приведены некоторые другие рекомендации.

Масштабируемые наборы виртуальных машин

Масштабируемые наборы виртуальных машин доступны для всех размеров виртуальных машин Windows. Плата взимается только за развернутые виртуальные машины Azure, а также за все дополнительные ресурсы базовой инфраструктуры, такие как хранилище и сеть. Для службы Масштабируемые наборы виртуальных машин плата не взимается.

Сведения о ценах на отдельные виртуальные машины см. в разделе Windows цен на виртуальные машины.

SQL Server

При выборе Azure SQL DBaaS можно снизить затраты, так как вам не нужно настраивать компьютеры группы доступности Always On и контроллера домена. Существует несколько вариантов развертывания, начиная с отдельной базы данных до управляемого экземпляра или эластичных пулов. Дополнительные сведения см. в разделе Azure SQL цен.

Сведения о ценах на виртуальные машины SQL Server см. на странице цен на виртуальные машины SQL.

Azure Load Balancer

Плата взимается только за количество настроенных правил балансировки нагрузки и исходящего трафика. За правила преобразования сетевых адресов (NAT) плата не взимается. Плата за Load Balancer (цен. категория не взимается, если правила не настроены.

См. сведения о затратах на платформу архитектуры Azure.

Шлюз приложений

Шлюз приложений должна быть подготовлена с помощью SKU версии 2 и может охватывать несколько Зоны доступности. С номером SKU версии 2 модель ценообразования определяется потреблением и имеет два компонента: почасовая фиксированная цена и затраты на основе потребления.

Дополнительные сведения см. в разделе цен на автомасштабирование и избыточное между зонами Шлюз приложений версии 2.

Вопросы безопасности

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

Ограничение трафика

Используйте группы безопасности сети (NSG), чтобы ограничить трафик и из Интернета. Дополнительные сведения см. в статье Virtual datacenters: A network perspective (Виртуальные центры обработки данных: перспектива сети).

DMZ

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

Encryption

Выполните шифрование конфиденциальных неактивных данных и используйте Azure Key Vault для управления ключами шифрования базы данных. Key Vault может хранить ключи шифрования в аппаратных модулях безопасности. Дополнительные сведения см. в статье Настройка интеграции хранилища ключей Azure для SQL Server на виртуальных машинах Azure (Resource Manager). В Key Vault также рекомендуется хранить секреты приложения, например строки подключения к базе данных.

Защита от атак DDoS

Платформа Azure по умолчанию предоставляет основные средства защиты от атак DDoS. Эта базовая защита нацелена на защиту инфраструктуры Azure. Хотя базовая защита от атак DDoS включена автоматически, рекомендуется использовать защиту от атак DDoS Azure уровня "Стандартный". Для ценовой категории "Стандартный" предусмотрена адаптивная настройка для обнаружения угроз на основе моделей сетевого трафика вашего приложения. Это позволяет устранять риски атак DDoS, которые могут остаться незамеченными для соответствующих политик уровня инфраструктуры. Для этой ценовой категории также включена поддержка оповещений, телеметрии и аналитики на основе Azure Monitor. Дополнительные сведения см. в статье Защита от атак DDoS Azure. Рекомендации и эталонные образцы архитектуры.

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