На примере этой эталонной архитектуры показано, как развернуть виртуальные машины и виртуальную сеть, настроенные для n-уровневого приложения, с использованием SQL Server на платформе Windows для уровня данных.
Архитектура
Скачайте файл Visio этой архитектуры.
Рабочий процесс
Архитектура состоит из следующих компонентов.
Общие сведения
Группа ресурсов. Группы ресурсов используются для группирования ресурсов Azure по времени существования, владельцу и другим критериям для управления.
Зоны доступности. Зоны доступности — это физические расположения в регионе Azure. Каждая зона состоит из одного или нескольких центров обработки данных с независимым питанием, охлаждением и сетью. Размещая виртуальные машины между зонами, приложение становится устойчивым к сбоям в пределах зоны.
Сети и балансировка нагрузки
Виртуальная сеть и подсети. Каждая виртуальная машина Azure развертывается в виртуальной сети, которую можно разделить на подсети. Создайте отдельные подсети для каждого уровня.
Шлюз приложений. Шлюз приложений — это подсистема балансировки нагрузки уровня 7. В этой архитектуре шлюз перенаправляет HTTP-запросы к внешнему веб-интерфейсу. Шлюз приложений также предоставляет брандмауэр веб-приложения (WAF), который защищает приложения от распространенных эксплойтов и уязвимостей.
Подсистемы балансировки нагрузки. Используйте azure Load Balancer (цен. категория для распределения сетевого трафика с веб-уровня на бизнес-уровень и с бизнес-уровня на SQL Server.
Группы безопасности сети (NSG). Используйте группы безопасности сети для ограничения сетевого трафика в виртуальной сети. Например, в приведенной здесь трехуровневой архитектуре уровень базы данных не принимает трафик из веб-интерфейса, а только с бизнес-уровня и из подсети управления.
Защита от атак DDoS. Хотя платформа Azure обеспечивает базовую защиту от распределенных атак типа "отказ в обслуживании" (DDoS), мы рекомендуем использовать защиту сети Azure от атак DDoS, которая обладает расширенными функциями защиты от атак DDoS. Ознакомьтесь с рекомендациями по безопасности.
Azure DNS. Azure DNS — это служба размещения для доменов DNS. Она осуществляет разрешение имен на базе инфраструктуры Microsoft Azure. Размещая домены в Azure, вы можете управлять своими записями DNS с помощью тех же учетных данных, API и инструментов и оплачивать использование, как и другие службы Azure.
Виртуальные машины
SQL Server Always On группы доступности. Обеспечивает высокий уровень доступности на уровне данных, включив репликацию и отработку отказа. Для отработки отказа используется технология отказоустойчивого кластера Windows Server (WSFC).
Серверы доменных служб Active Directory (AD DS). Объекты-компьютеры для отказоустойчивого кластера и связанные с ним кластерные роли создаются в доменных службах Active Directory (AD DS).
Облако-свидетель. На отказоустойчивом кластере должны работать больше половины узлов. Это называется кворумом. Если в кластере всего два узла, сетевой раздел может привести к тому, что каждый узел будет считать его основным. В этом случае требуется ресурс-свидетель, чтобы разорвать связи и создать кворум. Свидетель — это ресурс, например общий диск, который может использоваться в качестве средства разбиения связей для установления кворума. Облачный ресурс-свидетель — тип ресурса-свидетеля, в котором используется хранилище BLOB-объектов Azure. Дополнительные сведения о концепции кворума см. в статье, посвященной кворуму кластера и кворуму пула. Дополнительные сведения об облачном ресурсе-свидетеле см. в статье, посвященной развертыванию облачного ресурса-свидетеля для отказоустойчивого кластера.
Jumpbox. Он также называется узлом-бастионом. Традиционно это защищенная виртуальная машина в сети, которую администраторы используют для подключения к другим виртуальным машинам. В jumpbox есть группа безопасности сети, обеспечивающая удаленный трафик только из общедоступных IP-адресов из списка надежных отправителей. NSG должна разрешить трафик протокола удаленного рабочего стола (RDP). Azure предлагает управляемое решение Бастион Azure для удовлетворения этой потребности.
Рекомендации
Описанная здесь архитектура может не соответствовать вашим требованиям. Воспользуйтесь этими рекомендациями в качестве отправной точки.
Виртуальные машины
Рекомендации по настройке виртуальных машин см. в статье Запуск виртуальной машины Windows в Azure.
Виртуальная сеть
При создании виртуальной сети определите, сколько IP-адресов требуется для ресурсов в каждой подсети. Укажите маску подсети и достаточно большой диапазон адресов сети для требуемых IP-адресов с помощью нотации CIDR. Используйте адресное пространство, которое входит в диапазон стандартных блоков частных IP-адресов, например 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16.
Выберите диапазон адресов, который не перекрывает локальную сеть, если вам нужно позже настроить шлюз между виртуальной сетью и локальной сетью. После создания виртуальной сети невозможно изменить диапазон адресов.
Проектируйте подсети с учетом требований к функциональности и безопасности. Все виртуальные машины в пределах одного уровня или одной роли должны входить в одну и ту же подсеть, которая может быть надежным периметром безопасности. Дополнительные сведения о проектировании виртуальных сетей и подсетей см. в статье Plan virtual networks (Планирование виртуальных сетей Azure).
Шлюз приложений
Сведения о настройке Шлюз приложений см. в статье Общие сведения о конфигурации Шлюз приложений.
подсистемы балансировки нагрузки;
Не подключайте виртуальные машины напрямую к Интернету. Вместо этого предоставьте каждой из них частный IP-адрес. Клиент подключается через общедоступный IP-адрес, связанный со Шлюзом приложений.
Определите правила подсистемы балансировки нагрузки для направления трафика к виртуальным машинам. Например, чтобы включить трафик HTTP, сопоставьте порт 80 интерфейсной конфигурации с портом 80 серверного пула адресов. Когда клиент отправляет HTTP-запрос на порт 80, подсистема балансировки нагрузки выбирает IP-адрес серверной части с помощью хэш-алгоритма, который содержит исходный IP-адрес. Клиентские запросы распределяются между всеми виртуальными машинами в серверном пуле адресов.
Группы безопасности сети
С помощью правил NSG можно ограничить трафик между уровнями. В показанной выше трехуровневой архитектуре веб-уровень не взаимодействует напрямую с уровнем базы данных. Чтобы это правило соблюдалось, уровень базы данных должен блокировать входящий трафик из подсети веб-уровня.
- Запретите весь входящий трафик от виртуальной сети. (В правиле используйте тег
VIRTUAL_NETWORK.) - Разрешите входящий трафик из подсети бизнес-уровня.
- Разрешите входящий трафик из самой подсети уровня базы данных. Это правило обеспечивает взаимодействие между виртуальными машинами баз данных, которое необходимо для репликации и отработки отказа базы данных.
- Разрешите трафик RDP (порт 3389) из подсети jumpbox. Это правило позволяет администраторам подключаться к уровню базы данных из jumpbox.
Создайте правила 2–4 с более высоким приоритетом, чем у правила 1, чтобы они переопределяли его.
Группы доступности AlwaysOn SQL Server
Мы рекомендуем использовать группы доступности AlwaysOn для обеспечения высокого уровня доступности SQL Server. До Windows Server 2016 для групп доступности Always On требовался контроллер домена, а все узлы в группе доступности должны были находиться в одном домене AD.
Другие уровни подключаются к базе данных с помощью прослушивателя групп доступности. Прослушиватель позволяет клиенту SQL подключаться, не зная имени физического экземпляра SQL Server. Виртуальные машины, которые обращаются к базе данных, должны быть присоединены к домену. Клиент (в этом случае другой уровень) использует DNS для разрешения имени виртуальной сети прослушивателя в IP-адресах.
Настройте группы доступности AlwaysOn SQL Server следующим образом:
Создайте кластер отказоустойчивой кластеризации Windows Server, группу доступности AlwaysOn SQL Server и первичную реплику. Дополнительные сведения см. в статье Начало работы с группами доступности AlwaysOn.
Создайте внутреннюю подсистему балансировки нагрузки со статическим частным IP-адресом.
Создайте прослушиватель группы доступности и сопоставьте его DNS-имя с IP-адресом внутренней подсистемы балансировки нагрузки.
Создайте правило подсистемы балансировки нагрузки для порта прослушивания SQL Server (по умолчанию используется TCP-порт 1433). Правило подсистемы балансировки нагрузки должно включать плавающий IP-адрес, также называемый прямым ответом от сервера. В результате виртуальная машина будет отправлять ответ клиенту напрямую, что позволяет использовать прямое соединение с первичной репликой.
Примечание
Если плавающий IP-адрес включен, номер внешнего порта должен совпадать с номером внутреннего порта в правиле подсистемы балансировки нагрузки.
Если клиент SQL пытается выполнить подключение, подсистема балансировки нагрузки направляет запрос на подключение в первичную реплику. Если происходит отработка отказа с переходом на другую реплику, подсистема балансировки нагрузки автоматически направляет новые запросы в новую первичную реплику. Дополнительные сведения см. в статье Configure a load balancer for an Always On availability group in Azure (Настройка подсистемы балансировки нагрузки для группы доступности AlwaysOn в Azure).
Во время отработки отказа имеющиеся клиентские подключения закрыты. После отработки отказа новые соединения направляются в новую первичную реплику.
Если приложение выполняет значительно больше операций чтения, чем записи, вы можете разгрузить некоторые запросы только для чтения во вторичную реплику. Ознакомьтесь с разделом Соединение с помощью прослушивателя со вторичной репликой только для чтения (маршрутизация только для чтения).
Протестируйте развертывание, принудительно выполнив отработку отказа группы доступности вручную.
Jumpbox
При запуске виртуальных машин в частной виртуальной сети, как в этой архитектуре, необходимо получить доступ к виртуальным машинам для установки программного обеспечения, установки исправлений и т. д. Но сделать эти компьютеры доступными для общедоступного Интернета не рекомендуется, так как это значительно увеличивает уязвимую зону. Вместо этого jumpbox используется в качестве среднего уровня доступа.
В прошлом виртуальная машина, управляемая клиентом, могла использоваться в качестве jumpbox. В этом сценарии применяются следующие рекомендации:
- Не разрешайте доступ по протоколу RDP из общедоступного Интернета к виртуальным машинам, на которые выполняется рабочая нагрузка приложения. Вместо этого все доступы по протоколу RDP к этим виртуальным машинам должны проходить через jumpbox. Администратор входит в jumpbox, а затем входит в другую виртуальную машину из jumpbox. Jumpbox разрешает трафик RDP из Интернета, но только с известных безопасных IP-адресов.
- Jumpbox имеет минимальные требования к производительности, поэтому выберите небольшой размер виртуальной машины. Создайте общедоступный IP-адрес для jumpbox. Поместите jumpbox в виртуальную сеть вместе с другими виртуальными машинами, однако в отдельную подсеть управления.
- Чтобы защитить jumpbox, добавьте правило NSG, разрешающее подключения по протоколу RDP только из безопасного набора общедоступных IP-адресов. Настройте NSG для других подсетей, чтобы разрешить трафик RDP из подсети управления.
Для виртуальной машины, управляемой клиентом, применяются все эти правила. Однако в настоящее время рекомендуется использовать Бастион Azure, управляемое решение jumpbox, которое обеспечивает доступ HTML5 к RDP или SSH за Azure AD защиты. Это гораздо более простое решение, которое в конечном итоге имеет более низкую совокупную стоимость владения (TCO) для клиента.
Рекомендации
Масштабируемость
Масштабируемые наборы
Для веб- и бизнес-уровней рекомендуется использовать Масштабируемые наборы виртуальных машин вместо развертывания отдельных виртуальных машин. Масштабируемый набор упрощает процессы развертывания и администрирования набора идентичных виртуальных машин, а также автоматического масштабирования виртуальных машин на основе метрик производительности. По мере увеличения нагрузки на виртуальные машины в подсистему балансировки нагрузки автоматически добавляются дополнительные виртуальные машины. Подумайте об использовании масштабируемых наборов, если необходимо быстро развернуть виртуальные машины или выполнить автомасштабирование.
Настройку виртуальных машин, развернутых в масштабируемый набор, можно выполнить двумя основными способами:
Используйте расширения для настройки виртуальной машины после ее развертывания. В этом случае новые экземпляры виртуальной машины могут дольше запускаться, чем виртуальные машины без расширений.
Развернуть управляемый диск с помощью пользовательского образа диска. При этом развертывание выполняется быстрее. Но образ необходимо обновлять.
Дополнительные сведения см. в статье Рекомендации по проектированию масштабируемых наборов.
Совет
При использовании любого решения автоматического масштабирования заблаговременно протестируйте его с рабочими нагрузками производственного уровня.
Ограничения подписки
В каждой подписке Azure настроены ограничения по умолчанию, включая максимальное количество виртуальных машин в каждом регионе. Их лимит можно увеличить, создав запрос на поддержку. Дополнительные сведения см. в статье Подписка Azure, границы, квоты и ограничения службы.
Шлюз приложений
Шлюз приложений поддерживает режим фиксированной емкости или режим автомасштабирования. Режим фиксированной емкости подходит для сценариев с постоянной, предсказуемой рабочей нагрузкой. Рассмотрите возможность использования режима автомасштабирования для рабочих нагрузок с переменным трафиком. Дополнительные сведения см. в статье Автомасштабирование и избыточность между зонами Шлюз приложений версии 2
Доступность
Зоны доступности обеспечивают наилучшую устойчивость в одном регионе. Если вам требуется еще более высокая доступность, рассмотрите возможность репликации приложения в двух регионах с помощью диспетчера трафика Azure для отработки отказа. Дополнительные сведения см. в статье Высокодоступное N-уровневое приложение с поддержкой нескольких регионов.
Не все регионы поддерживают зоны доступности, и не все размеры виртуальных машин поддерживаются во всех зонах. Выполните следующую команду Azure CLI, чтобы найти поддерживаемые зоны для каждого размера виртуальной машины в регионе:
az vm list-skus --resource-type virtualMachines --zone false --location <location> \
--query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table
Если вы развертываете эту архитектуру в регионе, который не поддерживает зоны доступности, поместите виртуальные машины для каждого уровня в группу доступности. Виртуальные машины в одной группе доступности развертываются на нескольких физических серверах, вычислительных стойках, единицах хранения и сетевых коммутаторах для обеспечения избыточности. Масштабируемые наборы автоматически используют группы размещения, которые функционируют как неявная группа доступности.
При развертывании в зонах доступности используйте номер SKU "Стандартный" Azure Load Balancer и номер SKU версии 2 Шлюз приложений. Эти номера SKU поддерживают избыточность между зонами. Дополнительные сведения см. в разделе:
- Azure Load Balancer ценовой категории "Стандартный" и зоны доступности
- Автоматическое масштабирование и Шлюз приложений, избыточный между зонами, версии 2
- Каким образом Шлюз приложений поддерживает высокий уровень доступности и масштабируемость?
Одно развертывание Шлюз приложений может запускать несколько экземпляров шлюза. Для рабочих нагрузок запустите по крайней мере два экземпляра.
Пробы работоспособности
Шлюз приложений и 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.
подсистемы балансировки нагрузки;
Плата взимается только за количество настроенных правил балансировки нагрузки и исходящего трафика. За правила преобразования сетевых адресов (NAT) плата не взимается. Если правила не настроены, плата за Load Balancer (цен. категория не взимается.
См. сведения о затратах на платформу Microsoft Azure с продуманной архитектурой.
Безопасность
Виртуальные сети являются границей, изолирующей трафик в Azure. По умолчанию виртуальные машины в одной виртуальной сети не могут напрямую обращаться к виртуальным машинам в другой виртуальной сети. Однако можно явно подключить виртуальные сети с помощью пиринга виртуальных сетей.
Группы безопасности сети. NSG позволяют ограничить трафик, поступающий из Интернета и обратно. Дополнительные сведения см. в статье Virtual datacenters: A network perspective (Виртуальные центры обработки данных: перспектива сети).
DMZ. Попробуйте добавить сетевой виртуальный модуль (NVA), чтобы создать сеть периметра между Интернетом и виртуальною сетью Azure. Сетевой виртуальный модуль — это универсальный термин для виртуального модуля, который может выполнять сетевые задачи, например брандмауэра, проверки пакетов, аудита и пользовательской маршрутизации. Дополнительные сведения см. в статье Сеть периметра между Azure и Интернетом.
Шифрование. Выполните шифрование конфиденциальных неактивных данных и используйте 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. Рекомендации и эталонные образцы архитектуры.
эффективность работы;
Так как все main ресурсы и их зависимости находятся в одной виртуальной сети в этой архитектуре, они изолированы в одной и той же базовой рабочей нагрузке. Этот факт упрощает связывание конкретных ресурсов рабочей нагрузки с командой, чтобы команда самостоятельно управляла всеми аспектами этих ресурсов. Такая изоляция позволяет выполнять непрерывную поставку и непрерывную интеграцию (CI/CD) в DevOps.
Кроме того, вы можете использовать различные шаблоны развертывания и интегрировать их с Azure DevOps Services для подготовки разных сред за считанные минуты, например для репликации рабочих сценариев или сред нагрузочного тестирования только при необходимости, что экономит затраты.
В этом сценарии виртуальные машины настраиваются с помощью расширений виртуальных машин, так как они предлагают возможность установки некоторых дополнительных программ, таких как антивредоносные программы и агенты безопасности. Расширения виртуальной машины устанавливаются и выполняются только во время создания виртуальной машины. Это означает, что если операционная система будет неправильно настроена на более позднем этапе, ей потребуется вмешательство вручную, чтобы вернуть ее в правильное состояние.
Средства управления конфигурацией, в частности Desired State Configuration (DSC), используются в этой архитектуре для настройки Active Directory и группы доступности SQL Server Always On.
Мы рекомендуем использовать Azure Monitor для анализа и оптимизации производительности инфраструктуры, отслеживания и диагностики проблем с сетью без входа на виртуальные машины. Фактически Application Insights — это один из компонентов платформы Azure Monitor, которая предоставляет разнообразные метрики и журналы, отображающие состояние всего ландшафта Azure. Azure Monitor поможет отслеживать состояние инфраструктуры.
Не забудьте отслеживать не только вычислительные элементы, поддерживающие код приложения, но и платформу данных, в частности базы данных, так как низкая производительность уровня данных приложения может иметь серьезные последствия.
Чтобы протестировать среду Azure, в которой выполняются приложения, она должна управляться версиями и развертываться с помощью тех же механизмов, что и код приложения, а затем ее можно протестировать и проверить с помощью парадигм тестирования DevOps.
Дополнительные сведения см. в разделе "Эффективность работы" в Azure Well-Architected Framework.