Использование n-уровневого приложения с SQL Server в Azure Stack Hub

На примере этой эталонной архитектуры показано, как развернуть виртуальные машины и виртуальную сеть, настроенные для n-уровневого приложения, с использованием SQL Server на платформе Windows для уровня данных.

Architecture

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

The diagram shows a virtual network comprising six subnets: Application Gateway, Management, Web tier, Business tier, Data tier, and Active Directory. The Data tier subnet uses Cloud Witness. There are three load balancers.

Общее

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

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

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

  • Виртуальная сеть и подсети. Каждая виртуальная машина Azure развертывается в виртуальной сети, которую можно разделить на подсети. Создайте отдельные подсети для каждого уровня.

  • Подсистема балансировки нагрузки уровня 7. Так как Шлюз приложений пока недоступен в Azure Stack Hub, на рынке Azure Stack Hub доступны альтернативные варианты, например: KEMP LoadMaster Load Balancer коммутатор/ содержимого ADCf5 Big-IP Virtual Edition или A10 vThunder ADC

  • Подсистемы балансировки нагрузки. Azure Load Balancer позволяет распределять трафик с уровня Web на уровень Business, а также с уровня Business к SQL Server.

  • Группы безопасности сети (NSG). NSG позволяют ограничить трафик в виртуальной сети. Например, в приведенной здесь трехуровневой архитектуре уровень базы данных не принимает трафик из веб-интерфейса, а только с бизнес-уровня и из подсети управления.

  • DNS. Azure Stack Hub не предоставляет собственную службу размещения DNS, поэтому используйте DNS-сервер в ADDS.

Виртуальные машины

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

  • Серверы доменных служб Active Directory (AD DS). Объекты-компьютеры для отказоустойчивого кластера и связанные с ним кластерные роли создаются в доменных службах Active Directory (AD DS). Предпочтительным способом присоединения других виртуальных машин к AD DS является настройка серверов AD DS на виртуальных машинах в одной виртуальной сети. Вы также можете присоединить виртуальные машины к имеющимся корпоративным AD DS, подключив виртуальную сеть к корпоративной сети с помощью VPN-подключения. При использовании обоих подходов необходимо изменить DNS виртуальной сети на DNS-сервер AD DS (в виртуальной сети или имеющейся корпоративной сети), чтобы разрешить полное доменное имя домена AD DS.

  • Облачный свидетель. На отказоустойчивом кластере должны работать больше половины узлов. Это называется кворумом. Если кластер содержит всего два узла, сетевой раздел может привести к тому, что каждый узел считает, что это узел уровня управления. В этом случае требуется ресурс-свидетель, чтобы разорвать связи и создать кворум. Свидетель — это ресурс, например общий диск, который может использоваться в качестве средства разбиения связей для установления кворума. Облачный ресурс-свидетель — тип ресурса-свидетеля, в котором используется хранилище BLOB-объектов Azure. Дополнительные сведения о концепции кворума см. в статье, посвященной кворуму кластера и кворуму пула. Дополнительные сведения об облачном ресурсе-свидетеле см. в статье, посвященной развертыванию облачного ресурса-свидетеля для отказоустойчивого кластера. В Azure Stack Hub конечная точка облака-свидетеля отличается от глобальной службы Azure.

Она может выглядеть следующим образом:

  • Глобальная среда Azure:
    https://mywitness.blob.core.windows.net/

  • Azure Stack Hub:
    https://mywitness.blob.<region>.<FQDN>

  • Jumpbox. Он также называется узлом-бастионом. Безопасная виртуальная машина в сети, которую администраторы используют для подключения к другим виртуальным машинам. В jumpbox есть группа безопасности сети, обеспечивающая удаленный трафик только из общедоступных IP-адресов из списка надежных отправителей. NSG должна пропускать трафик с удаленного рабочего стола (RDP).

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

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

Виртуальные машины

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

Виртуальная сеть

При создании виртуальной сети определите, сколько 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-адрес, связанный с Load Balancer уровня 7.

Определите правила подсистемы балансировки нагрузки для направления трафика к виртуальным машинам. Например, чтобы включить трафик HTTP, сопоставьте порт 80 интерфейсной конфигурации с портом 80 серверного пула адресов. Когда клиент отправляет HTTP-запрос на порт 80, подсистема балансировки нагрузки выбирает IP-адрес серверной части с помощью хэш-алгоритма, который содержит исходный IP-адрес. Клиентские запросы распределяются между всеми виртуальными машинами в серверном пуле адресов.

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

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

  1. Запретите весь входящий трафик от виртуальной сети. (Используйте тег VIRTUAL_NETWORK в правиле.)

  2. Разрешите входящий трафик из подсети бизнес-уровня.

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

  4. Разрешите трафик RDP (порт 3389) из подсети jumpbox. Это правило позволяет администраторам подключаться к уровню базы данных из jumpbox.

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

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

Мы рекомендуем использовать группы доступности AlwaysOn для обеспечения высокого уровня доступности SQL Server. До Windows Server 2016 для групп доступности Always On требовался контроллер домена, а все узлы в группе доступности должны были находиться в одном домене AD.

Для обеспечения высокой доступности уровня виртуальной машины все виртуальные машины SQL должны находиться в группе доступности.

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

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

  1. Создайте кластер отказоустойчивой кластеризации Windows Server, группу доступности AlwaysOn SQL Server и первичную реплику. Дополнительные сведения см. в статье Начало работы с группами доступности AlwaysOn.

  2. Создайте внутреннюю подсистему балансировки нагрузки со статическим частным IP-адресом.

  3. Создайте прослушиватель группы доступности и сопоставьте его DNS-имя с IP-адресом внутренней подсистемы балансировки нагрузки.

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

Примечание

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

Если клиент SQL пытается выполнить подключение, подсистема балансировки нагрузки направляет запрос на подключение в первичную реплику. Если происходит отработка отказа с переходом на другую реплику, подсистема балансировки нагрузки автоматически направляет новые запросы в новую первичную реплику. Дополнительные сведения см. в статье Configure a load balancer for an Always On availability group in Azure (Настройка подсистемы балансировки нагрузки для группы доступности AlwaysOn в Azure).

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

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

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

Рекомендации по оптимизации производительности SQL Server в Azure Stack Hub см. в этой статье.

Jumpbox

Запретите доступ по протоколу RDP из общедоступного Интернета к виртуальным машинам, которые выполняют рабочую нагрузку приложения. Вместо этого все доступы по протоколу RDP к этим виртуальным машинам должны проходить через jumpbox. Администратор выполняет вход в jumpbox, а затем вход в другую виртуальную машину из jumpbox. jumpbox разрешает RDP трафик из Интернета, однако только из известных и безопасных IP-адресов.

Jumpbox имеет минимальные требования к производительности, поэтому выберите небольшой размер виртуальной машины. Создайте общедоступный IP-адрес для jumpbox. Поместите jumpbox в виртуальную сеть вместе с другими виртуальными машинами, однако в отдельную подсеть управления.

Чтобы защитить jumpbox, добавьте правило NSG, разрешающее подключения по протоколу RDP только из безопасного набора общедоступных IP-адресов. Настройте NSG для других подсетей, чтобы разрешить трафик RDP из подсети управления.

Вопросы масштабируемости

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

Рассмотрите возможность использования масштабируемых наборов виртуальных машин для уровня Web и Business вместо развертывания отдельных виртуальных машин. Масштабируемый набор позволяет развернуть и администрировать набор идентичных виртуальных машин. Подумайте об использовании масштабируемых наборов, если необходимо быстро развернуть виртуальные машины.

Настройку виртуальных машин, развернутых в масштабируемый набор, можно выполнить двумя основными способами:

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

  • Развернуть управляемый диск с помощью пользовательского образа диска. При этом развертывание выполняется быстрее. Но образ необходимо обновлять.

Дополнительные сведения см. в статье Рекомендации по проектированию масштабируемых наборов. В основном эти рекомендации по проектированию относятся к Azure Stack Hub, но есть некоторые предостережения:

  • Масштабируемые наборы виртуальных машин в Azure Stack Hub не поддерживают избыточную подготовку или последовательные обновления.

  • В Azure Stack Hub нельзя автоматически масштабировать масштабируемые наборы виртуальных машин.

  • Мы настоятельно рекомендуем использовать в Azure Stack Hub вместо неуправляемых управляемые диски для масштабируемого набора виртуальных машин

  • Сейчас в Azure Stack Hub действует ограничение в 700 виртуальных машин, к которым относятся все виртуальные машины инфраструктуры Azure Stack Hub, отдельные виртуальные машины и экземпляры масштабируемых наборов.

Ограничения подписки

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

Замечания по безопасности

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

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

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

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

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