Эта эталонная архитектура иллюстрирует проектирование гибридного решения системы доменных имен (DNS) для разрешения имен рабочих нагрузок, размещенных в локальной среде и в Microsoft Azure. Эта архитектура работает для пользователей и других систем, которые подключаются из локальной среды и общедоступного Интернета.
Архитектура
Скачайте файл Visio для этой архитектуры.
Workflow
Она состоит из следующих компонентов:
- Локальная сеть. Локальная сеть представляет единый центр обработки данных, подключенный к Azure через Azure ExpressRoute или vpn-подключение . В этом сценарии следующие компоненты составляют локальную сеть:
- DNS-серверы . Эти серверы представляют два сервера с установленной службой DNS, которая выступает в качестве сопоставителя или пересылки. Эти DNS-серверы используются для всех компьютеров в локальной сети в качестве DNS-серверов. Записи должны создаваться на этих серверах для всех конечных точек в Azure и локальной среде.
- Шлюз. Шлюз представляет VPN-устройство или подключение ExpressRoute, используемое для подключения к Azure.
- Подписка концентратора. Подписка концентратора представляет собой подписку Azure, используемую для размещения подключений, управления и сетевых ресурсов, совместно используемых для нескольких рабочих нагрузок, размещенных в Azure. Эти ресурсы можно разделить на несколько подписок, как описано в архитектуре корпоративного масштаба.
Примечание.
Виртуальная сеть концентратора может быть заменена концентратором виртуальной глобальной сети (WAN), в этом случае DNS-серверы должны размещаться в другой виртуальной сети Azure . В архитектуре корпоративного масштаба виртуальная сеть поддерживается в собственной подписке, которая имеет право на подписку Identity.
- Подсеть Бастиона Azure. Служба Бастиона Azure в виртуальной сети концентратора используется для удаленного взаимодействия с виртуальными машинами (виртуальными машинами) в концентраторе и периферийных виртуальных сетях из общедоступного Интернета в целях обслуживания.
- Подсеть частной конечной точки. Подсеть частной конечной точки размещает частные конечные точки для рабочих нагрузок, размещенных в Azure, в виртуальных сетями, которые не пиринговые в концентраторе. С помощью этого типа отключенной виртуальной сети его IP-адреса могут столкнуться с другими IP-адресами, которые используются в Azure и локальной среде.
- Подсеть шлюза. Подсеть шлюза размещает VPN Azure или ExpressRoute, шлюз, который используется для предоставления подключения к локальному центру обработки данных.
- Подсеть общих служб. Подсети общих служб размещаются службы, общие для нескольких рабочих нагрузок Azure. В этом сценарии эта подсеть размещает виртуальные машины подсети под управлением Windows или Linux, которые также используются в качестве DNS-серверов. Эти DNS-серверы размещают те же зоны DNS, что и локальные серверы.
- Подключение подписка. Подключенная подписка представляет коллекцию рабочих нагрузок, требующих виртуальной сети и подключения к локальной сети.
- Пиринговая связь между виртуальными сетями. Этот компонент является пиринговым подключением обратно к виртуальной сети концентратора. Это подключение позволяет подключаться из локальной сети к периферийной сети и обратно через виртуальную сеть концентратора.
- Подсеть по умолчанию. Подсеть по умолчанию содержит пример рабочей нагрузки.
- веб-виртуальные машины. Этот пример масштабируемого набора виртуальных машин содержит рабочую нагрузку в Azure, доступ к которым можно получить из локальной среды, Azure и общедоступного Интернета.
- Подсистема балансировки нагрузки. Подсистема балансировки нагрузки предоставляет доступ к рабочей нагрузке, которая является рядом узлов виртуальных машин. IP-адрес этой подсистемы балансировки нагрузки в подсети по умолчанию должен использоваться для доступа к рабочей нагрузке из Azure и из локального центра обработки данных.
- Подсеть AppGateway. Эта подсеть является обязательной подсетью для службы Шлюз приложений Azure.
- Отключенная подписка. Отключенная подписка представляет коллекцию рабочих нагрузок, которые не требуют подключения к локальному центру обработки данных и используют службу приватного канала.
- PLSubnet. Подсеть службы приватного канала (PLSSubnet) содержит один или несколько ресурсов службы приватного канала, которые обеспечивают подключение к рабочим нагрузкам, размещенным в Подключение подписке.
- Подсеть по умолчанию. Подсеть по умолчанию содержит пример рабочей нагрузки.
- веб-виртуальные машины. Этот пример масштабируемого набора виртуальных машин содержит рабочую нагрузку в Azure, доступ к которым можно получить из локальной среды, Azure и общедоступного Интернета.
- Подсистема балансировки нагрузки. Подсистема балансировки нагрузки предоставляет доступ к рабочей нагрузке, которая является рядом узлов виртуальных машин. Эта подсистема балансировки нагрузки подключена к службе приватного канала для предоставления доступа пользователям, поступающим из Azure и локального центра обработки данных.
- Подсеть AppGateway. Эта подсеть является обязательной подсетью для службы Шлюз приложений.
- AppGateway. Шлюз приложений предоставляет доступ к образцу рабочей нагрузки в подсети по умолчанию пользователям из общедоступного Интернета.
- wkld2-pip. Этот адрес — это общедоступный IP-адрес, используемый для доступа к примеру рабочей нагрузки из общедоступного Интернета.
- Подсеть Бастиона Azure. Служба Бастиона Azure в отключенной виртуальной сети используется для удаленного взаимодействия с виртуальными машинами в концентраторе и периферийных виртуальных сетях из общедоступного Интернета в целях обслуживания.
Компоненты
Виртуальная сеть. Виртуальная сеть (VNet) Azure — это ключевой компонент для построения в Azure вашей частной сети. Виртуальная сеть позволяет ресурсам Azure различных типов (например, виртуальным машинам Azure) обмениваться данными друг с другом через локальные сети и через Интернет.
Бастион Azure. Бастион Azure — это полностью управляемая служба, которая обеспечивает более безопасный и удобный доступ к виртуальным машинам по протоколам удаленного рабочего стола (RDP) и протоколам SSH без использования общедоступных IP-адресов.
VPN-шлюз. VPN-шлюз передает зашифрованный трафик между виртуальной сетью Azure и локальным расположением через общедоступный Интернет. Его также можно использовать для обмена зашифрованным трафиком между виртуальными сетями Azure через сеть Майкрософт. VPN-шлюз — это особый тип шлюза виртуальной сети.
Приватный канал. Приватный канал Azure обеспечивает частное подключение из виртуальной сети к Azure PaaS (платформа как услуга), а также к службам, принадлежащим клиентам или партнерам Майкрософт. Эта служба упрощает сетевую архитектуру и защищает подключение между конечными точками в Azure, устраняя проблему незащищенности данных в общедоступном Интернете.
Шлюз приложений. Шлюз приложений Azure — это подсистема балансировки нагрузки веб-трафика, предназначенная для управления трафиком веб-приложений. Традиционные подсистемы балансировки нагрузки работают на транспортном уровне (уровень 4 OSI — протоколы TCP и UDP) и маршрутизируют трафик к IP-адресу и порту назначения в зависимости от исходного IP-адреса и порта.
Рекомендации
Следующие рекомендации применимы для большинства ситуаций. Следуйте этим рекомендациям, если они не противоречат особым требованиям для вашего случая.
Примечание.
Для следующих рекомендаций мы рассмотрим рабочую нагрузку 1 как подключенную рабочую нагрузку и рабочую нагрузку 2 как отключенную рабочую нагрузку. Мы также будем ссылаться на пользователей и системы, которые обращаются к этим рабочим нагрузкам как локальные пользователи, интернет-пользователи и системы Azure.
Расширение AD DS в Azure (необязательно)
Используйте интегрированные зоны DNS в AD DS для размещения записей DNS для локального центра обработки данных и Azure. В этом сценарии существует два набора DNS-серверов AD DS: один локальный и один в центральной виртуальной сети.
Рекомендуется расширить домен AD DS в Azure. Мы также рекомендуем настроить центральные и периферийные виртуальные сети для использования DNS-серверов AD DS в центральной виртуальной сети для всех виртуальных машин в Azure.
Примечание.
Эта рекомендация применима только для организаций, использующих интегрированную зону DNS Active Directory для разрешения имен. Другие пользователи могут рассмотреть возможность реализации DNS-серверов, которые выполняют роль сопоставителя или пересылки.
Настройка DNS с разделением мозга
Убедитесь, что DNS с разделением мозга используется, чтобы разрешить системам Azure, локальным пользователям и интернет-пользователям доступ к рабочим нагрузкам в зависимости от того, откуда они подключаются.
Для подключенных и отключенных рабочих нагрузок рекомендуется использовать следующие компоненты для разрешения DNS:
- Зоны Azure DNS для пользователей Интернета.
- DNS-серверы для локальных пользователей и систем Azure.
- Частные зоны DNS Azure для разрешения между виртуальными сетями Azure.
Чтобы лучше понять эту рекомендацию по разделению мозга, рассмотрим рабочую нагрузку 1, для которой мы будем использовать полное доменное имя (FQDN) wkld1.contoso.com .
В этом сценарии пользователи Интернета должны разрешить это имя общедоступному IP-адресу, который Шлюз приложений предоставляет через Wkld1-pip. Это решение выполняется путем создания записи адресов (записи A) в Azure DNS для подключенной подписки.
Локальные пользователи должны разрешить то же имя внутреннему IP-адресу для подсистемы балансировки нагрузки в подключенной подписке. Это решение выполняется путем создания записи A на DNS-серверах в подписке концентратора.
Системы Azure могут разрешать то же имя внутреннему IP-адресу подсистемы балансировки нагрузки в подключенной подписке, создавая запись A на DNS-сервере в подписке концентратора или используя частные зоны DNS. При использовании частных зон DNS вручную создайте запись A в частной зоне DNS или включите авторегистрацию.
Использование частных зон DNS для приватного канала
В нашем сценарии рабочая нагрузка 2 размещается в отключенной подписке, а доступ к этой рабочей нагрузке для локальных пользователей и подключенных систем Azure возможен через частную конечную точку в виртуальной сети концентратора. Однако для этой рабочей нагрузки существует третья возможность подключения: системы Azure в той же виртуальной сети, что и 2.
Чтобы лучше понять рекомендации DNS для рабочей нагрузки 2, мы будем использовать полное доменное имя wkld2.contoso.com и обсудим отдельные рекомендации.
В этом сценарии пользователи Интернета должны разрешить это имя общедоступному IP-адресу, который Шлюз приложений предоставляет через Wkld2-pip. Это решение выполняется путем создания записи A в Azure DNS для подключенной подписки.
Локальные пользователи и системы Azure, подключенные к центральной виртуальной сети и периферийным виртуальным сетям, должны разрешать то же имя внутреннему IP-адресу для частной конечной точки в виртуальной сети Концентратора. Это решение выполняется путем создания записи A на DNS-серверах в подписке концентратора.
Системы Azure в той же виртуальной сети, что и рабочая нагрузка 2, должны разрешать имя IP-адреса подсистемы балансировки нагрузки в отключенной подписке. Это решение выполняется с помощью частной зоны DNS в Azure DNS в этой подписке.
Системы Azure в разных виртуальных сетям по-прежнему могут разрешать IP-адрес рабочей нагрузки 2 , если связать эти виртуальные сети с частной зоной DNS, в которую размещена запись A для рабочей нагрузки 2.
Включение авторегистрации
При настройке ссылки виртуальной сети с частной зоной DNS можно при необходимости настроить авторегистрацию авторегистрации для всех виртуальных машин.
Примечание.
Авторегистрация поддерживается только для виртуальных машин. Для всех остальных ресурсов, настроенных с IP-адресом из виртуальной сети, необходимо вручную создать записи DNS в частной зоне DNS.
Если вы используете DNS-сервер AD DS, настройте виртуальные машины Windows, которые могут использовать динамические обновления для компьютеров Windows, чтобы сохранить собственные записи DNS в DNS-серверах AD DS. Рекомендуется включить динамические обновления и настроить DNS-серверы, чтобы разрешить только безопасные обновления.
Виртуальные машины Linux не поддерживают безопасные динамические обновления. Для локальных компьютеров Linux используйте протокол DHCP для регистрации записей DNS на DNS-серверах AD DS.
Для виртуальных машин Linux в Azure используйте автоматизированный процесс.
Рекомендации
Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая является набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.
Масштабируемость
- Для каждого региона Azure или локальных центров обработки данных рекомендуется использовать по крайней мере два DNS-сервера.
- Обратите внимание, как это сделано в предыдущем сценарии с DNS-серверами локальной и в центральной виртуальной сети.
Доступность
- Рассмотрите возможность размещения DNS-серверов. Как описано в разделе о масштабируемости, DNS-серверы должны быть расположены близко к пользователям и системам, которым требуется доступ к ним.
- В каждом регионе Azure. Каждый регион Azure имеет собственную виртуальную сеть концентратора или концентратор виртуальной глобальной сети. Здесь необходимо развернуть DNS-серверы.
- Для локального центра обработки данных. Для пользователей и систем в этих расположениях также должна быть пара DNS-серверов на локальный центр обработки данных.
- Для изолированных (отключенных) рабочих нагрузок размещайте частную зону DNS и общедоступную зону DNS для каждой подписки для управления записями DNS с разделением мозга.
Управляемость
- Рассмотрите необходимость записей DNS для служб платформы как службы (PaaS).
- Кроме того, необходимо учитывать разрешение DNS для служб PaaS, использующих частную конечную точку. Используйте частную зону DNS для этого и используйте конвейер DevOps для создания записей на DNS-серверах.
Безопасность
Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".
- Если требуется использовать DNSSEC, рассмотрите, что Azure DNS в настоящее время не поддерживает его.
- Для проверки DNSSEC разверните пользовательский DNS-сервер и включите проверку DNSEC.
- Защита от атак DDoS Azure в сочетании с рекомендациями по проектированию приложений предоставляет расширенные функции защиты от атак DDoS. Необходимо включить защиту от атак DDOS Azure в любой виртуальной сети периметра.
DevOps
- Автоматизация конфигурации этой архитектуры путем объединения шаблонов Azure Resource Manager для настройки всех ресурсов. Частные и общедоступные зоны DNS поддерживают полное управление с помощью Azure CLI, PowerShell, .NET и REST API.
- Если вы используете конвейер непрерывной интеграции и непрерывной разработки (CI/CD) для развертывания и обслуживания рабочих нагрузок в Azure и локальной среде, можно также настроить автоматическую регистрацию записей DNS.
Оптимизация затрат
Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".
- Затраты на зону Azure DNS основаны на количестве зон DNS, размещенных в Azure, и количестве полученных ЗАПРОСОВ DNS.
- Для оценки затрат используйте калькулятор цен Azure. Здесь описаны модели ценообразования для Azure DNS.
- Модель выставления счетов для Azure ExpressRoute основана на данных с учетом лимита, которые взимается за гигабайт для передачи исходящих данных или неограниченных данных, которые взимает ежемесячную плату, включая все передачи данных.
- Если вы используете VPN, а не ExpressRoute, стоимость зависит от SKU шлюза виртуальной сети и взимается в час.
Следующие шаги
Дополнительные сведения о технологиях компонентов:
- Что такое Azure DNS?
- Что такое виртуальная сеть Azure?
- Что такое Azure ExpressRoute?
- Что такое Бастион Azure
Связанные ресурсы
Сведения о связанных архитектурах: