Топология сети "звезда" с общими службами в AzureHub-spoke network topology with shared services in Azure

Эта эталонная архитектура создана на основе звездообразной эталонной архитектуры. Это позволяет включить в концентраторе общие службы, которые можно использовать во всех периферийных зонах.This reference architecture builds on the hub-spoke reference architecture to include shared services in the hub that can be consumed by all spokes.

Первым этапом перехода центра обработки данных в облако является то, что первые службы, которым необходимо предоставить общий доступ, являются удостоверениями и безопасностью.As a first step toward migrating a datacenter to the cloud, the first services that need to be shared are identity and security. В этой эталонной архитектуре показано, как расширить службы Active Directory из локального центра обработки данных в Azure и как добавить сетевой виртуальный модуль (NVA), который может использоваться в качестве брандмауэра.This reference architecture shows how to extend Active Directory services from your on-premises datacenter to Azure, and how to add a network virtual appliance (NVA) that can act as a firewall. Функции брандмауэра также можно выполнить с помощью брандмауэра Azure, облачной службы безопасности сети.The firewall functionality can also be accomplished using Azure Firewall, a cloud-based network security service.

Топология общих служб в Azure

Скачать файл Visio этой архитектурыDownload a Visio file of this architecture

До преимуществ этой топологии можно отнести:The benefits of this topology include:

  • Сокращение затрат путем централизации служб, которые могут совместно использоваться несколькими рабочими нагрузками, такими как сетевые виртуальные устройства (NVA) и DNS-серверы в одном расположении.Cost savings by centralizing services that can be shared by multiple workloads, such as network virtual appliances (NVAs) and DNS servers, in a single location.
  • Превышение лимитов подписки путем пиринга виртуальных сетей из разных подписок к центральному концентратору.Overcome subscriptions limits by peering VNets from different subscriptions to the central hub.
  • Разделение областей ответственности между центральным ИТ-отделом (SecOps, InfraOps) и рабочими нагрузками (DevOps).Separation of concerns between central IT (SecOps, InfraOps) and workloads (DevOps).

Типичные способы использования этой архитектуры:Typical uses for this architecture include:

  • Рабочая нагрузка, развернутая в разных средах, например в среде для разработки, тестирования и в рабочей среде, для которых требуются общие службы, например DNS, IDS, NTP или AD DS.Workloads deployed in different environments, such as development, testing, and production, that require shared services such as DNS, IDS, NTP, or AD DS. Общие службы размещаются в виртуальной сети концентратора, в то время как каждая среда развертывается в периферийной зоне для обеспечения изоляции.Shared services are placed in the hub VNet, while each environment is deployed to a spoke to maintain isolation.
  • Рабочие нагрузки, которые не требуют подключения друг к другу, но требуют доступа к общим службам.Workloads that do not require connectivity to each other, but require access to shared services.
  • Предприятия, которые требуют централизованного контроля над аспектами безопасности, такими как брандмауэр в концентраторе, таком как сеть периметра, и отдельного управления для рабочих нагрузок в каждой периферийной зоне.Enterprises that require central control over security aspects, such as a firewall in the hub as a DMZ, and segregated management for the workloads in each spoke.

ArchitectureArchitecture

Архитектура состоит из следующих компонентов:The architecture consists of the following components.

  • Локальная сеть.On-premises network. Частная локальная сеть, работающая внутри организации.A private local-area network running within an organization.

  • VPN-устройство.VPN device. Устройство или служба, предоставляющая возможность внешнего подключения к локальной сети.A device or service that provides external connectivity to the on-premises network. VPN-устройство может быть аппаратным устройством или программным решением, таким как служба маршрутизации и удаленного доступа (RRAS) в Windows Server 2012.The VPN device may be a hardware device, or a software solution such as the Routing and Remote Access Service (RRAS) in Windows Server 2012. Список поддерживаемых VPN-устройств и информацию о настройке выбранных VPN-устройств для подключения к Azure см. в статье VPN-устройства и параметры IPsec/IKE для подключений типа "сеть — сеть" через VPN-шлюз.For a list of supported VPN appliances and information on configuring selected VPN appliances for connecting to Azure, see About VPN devices for Site-to-Site VPN Gateway connections.

  • Сетевой шлюз виртуальной сети VPN или шлюз ExpressRoute.VPN virtual network gateway or ExpressRoute gateway. Шлюз виртуальной сети позволяет виртуальной сети подключаться к VPN-устройству или к каналу ExpressRoute, которые используются для подключения к вашей локальной сети.The virtual network gateway enables the VNet to connect to the VPN device, or ExpressRoute circuit, used for connectivity with your on-premises network. Дополнительные сведения см. в статье Подключение локальной сети к виртуальной сети Microsoft Azure.For more information, see Connect an on-premises network to a Microsoft Azure virtual network.

Примечание

В сценариях развертывания для этой эталонной архитектуры используется VPN-шлюз для подключения, а виртуальная сеть в Azure используется для имитации вашей локальной сети.The deployment scripts for this reference architecture use a VPN gateway for connectivity, and a VNet in Azure to simulate your on-premises network.

  • Виртуальная сеть концентратора.Hub VNet. Виртуальная сеть Azure используется в качестве концентратора в звездообразной топологии.Azure VNet used as the hub in the hub-spoke topology. Концентратор является центральной точкой подключения к вашей локальной сети и местом для размещения служб, которые могут использоваться различными рабочими нагрузками, размещенными в виртуальных сетях.The hub is the central point of connectivity to your on-premises network, and a place to host services that can be consumed by the different workloads hosted in the spoke VNets.

  • Подсеть шлюза.Gateway subnet. Шлюзы виртуальных сетей хранятся в одной подсети.The virtual network gateways are held in the same subnet.

  • Подсеть общих служб.Shared services subnet. Подсеть в концентраторе виртуальной сети используется для размещения служб, которые могут использоваться совместно во всех периферийных зонах, например DNS или AD DS.A subnet in the hub VNet used to host services that can be shared among all spokes, such as DNS or AD DS.

  • Подсеть сети периметра.DMZ subnet. Подсеть в виртуальной сети концентратора, используемая для размещения виртуальных сетевых модулей, которые могут действовать как устройства безопасности, например как брандмауэры.A subnet in the hub VNet used to host NVAs that can act as security appliances, such as firewalls.

  • Лучевой виртуальных сетей.Spoke VNets. Одна или несколько виртуальных сетей Azure, которые используются в качестве периферийных зон в звездообразной топологии.One or more Azure VNets that are used as spokes in the hub-spoke topology. Периферийные зоны можно использовать для изоляции рабочих нагрузок в их виртуальных сетях, управляемых отдельно от других периферийных зон.Spokes can be used to isolate workloads in their own VNets, managed separately from other spokes. Каждая рабочая нагрузка может содержать несколько уровней с несколькими подсетями, подключенными через подсистемы балансировки нагрузки Azure.Each workload might include multiple tiers, with multiple subnets connected through Azure load balancers. Дополнительные сведения об инфраструктуре приложений см. в статьях Запуск рабочих нагрузок на виртуальных машинах Windows и Запуск рабочих нагрузок на виртуальной машине Linux.For more information about the application infrastructure, see Running Windows VM workloads and Running Linux VM workloads.

  • Пиринг виртуальной сети.VNet peering. Две виртуальные сети можно подключить между собой с помощью пирингового подключения.Two VNets can be connected using a peering connection. Пиринговые подключения представляют собой нетранзитивные подключения между виртуальными подсетями с низкой задержкой.Peering connections are non-transitive, low latency connections between VNets. После установки пирингового подключения виртуальные сети обмениваются трафиком по магистрали Azure без необходимости использования маршрутизатора.Once peered, the VNets exchange traffic by using the Azure backbone, without the need for a router. В звездообразной топологии сети пиринг виртуальной сети используется для подключения концентратора к каждой периферийной зоне.In a hub-spoke network topology, you use VNet peering to connect the hub to each spoke. Можно выполнять пиринг между виртуальными сетями в одном регионе или в разных регионах (в глобальной виртуальной сети).You can peer virtual networks in the same region, or different regions (Global VNet Peering). Дополнительные сведения см. в разделе Требования и ограничения.For more information, see Requirements and constraints.

Примечание

В этой статье рассматриваются только развертывания Resource Manager, но вы также можете подключить классическую виртуальную сеть к виртуальной сети Resource Manager в той же подписке.This article only covers Resource Manager deployments, but you can also connect a classic VNet to a Resource Manager VNet in the same subscription. Таким образом, ваши периферийные зоны могут размещать классические развертывания и по-прежнему пользоваться преимуществами общих служб в концентраторе.That way, your spokes can host classic deployments and still benefit from services shared in the hub.

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

Все рекомендации для звездообразной эталонной архитектуры также можно применить к эталонной архитектуре общих служб.All the recommendations for the hub-spoke reference architecture also apply to the shared services reference architecture.

Кроме того, следующие рекомендации применимы для большинства сценариев с общими службами.Also, the following recommendations apply for most scenarios under shared services. Следуйте этим рекомендациям, если они не противоречат особым требованиям для вашего случая.Follow these recommendations unless you have a specific requirement that overrides them.

ИдентификацияIdentity

Большинство корпоративных организаций имеют среду домен Active Directory Services (AD DS) в локальном центре обработки данных.Most enterprise organizations have an Active Directory Domain Services (AD DS) environment in their on-premises datacenter. Чтобы упростить управление активами, перемещаемыми в Azure из локальной сети, которая зависит от AD DS, рекомендуется размещать в Azure контроллеры домена AD DS.To facilitate management of assets moved to Azure from your on-premises network that depend on AD DS, it is recommended to host AD DS domain controllers in Azure.

Если вы используете групповая политика объекты, которые вы хотите контролировать отдельно для Azure и локальной среды, используйте другой сайт AD для каждого региона Azure.If you use Group Policy Objects, that you want to control separately for Azure and your on-premises environment, use a different AD site for each Azure region. Разместите контроллеры домена в центральной виртуальной сети (концентраторе), доступ к которой могут получить зависимые рабочие нагрузки.Place your domain controllers in a central VNet (hub) that dependent workloads can access.

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

При перемещении рабочих нагрузок из локальной среды в Azure некоторые из них потребуется разместить на виртуальных машинах.As you move workloads from your on-premises environment to Azure, some of these workloads will require to be hosted in VMs. В целях обеспечения соответствия может потребоваться наложить ограничения на передачу трафика этих рабочих нагрузок.For compliance reasons, you may need to enforce restrictions on traffic traversing those workloads.

Вы можете использовать виртуальные сетевые модули в Azure для размещения разных типов служб безопасности и производительности.You can use network virtual appliances (NVAs) in Azure to host different types of security and performance services. Если вы знакомы с заданным набором устройств в локальной среде, рекомендуется использовать те же виртуальные модули в Azure, где это применимо.If you are familiar with a given set of appliances on-premises today, it is recommended to use the same virtualized appliances in Azure, where applicable.

Примечание

В скриптах развертывания этой эталонной архитектуры используется виртуальная машина Ubuntu с IP-пересылкой, которая позволяет сымитировать виртуальный сетевой модуль.The deployment scripts for this reference architecture use an Ubuntu VM with IP forwarding enabled to mimic a network virtual appliance.

Рекомендации для DevOpsDevOps considerations

Эта Эталонная архитектура строится на эталонной архитектуре HUB и включает в себя общие службы, которые можно использовать на всех периферийных ресурсах. Дополнительные сведения см. в разделе DevOps рекомендации по этой архитектуре.This reference architecture builds on the hub-spoke reference architecture and includes shared services in the hub that can be consumed by all spokes, see the DevOps considerations on that architecture, for more information.

Рекомендации по стоимостиCost considerations

Эта Эталонная архитектура основана на эталонной архитектуре"звезда".This reference architecture builds on the hub-spoke reference architecture. Она включает в себя общие службы в концентраторе, которые могут использоваться всеми периферийными серверами.It includes shared services in the hub that can be consumed by all spokes. Например, использование служб домен Active Directory в качестве общей службы, потребляемой несколькими рабочими нагрузками, является экономичным.For example, having Active Directory Domain services as a shared service consumed by multiple workloads is cost effective. Сведения о ценах см. на AD DS .See AD DS pricing for pricing info.

Дополнительные сведения о других затратах см. в разделе топология сети уровня звезды — рекомендации по затратам.For other cost considerations, see Hub-spoke network topology - cost considerations.

Развертывание решенияDeploy the solution

Внимание!

"Не используйте AZbb — он находится в режиме устойчивых обновлений, а пакет NPM устарел"."Don't use azbb - it is in sustain mode and the npm package is out of date". В качестве альтернативы можно использовать шаблон ARM: 101-HUB-и-спицная Песочница или использовать terraform: Hub-лучевой — введение .Alternatively use: ARM Template: 101-hub-and-spoke-sandbox or use Terraform: hub-spoke-introduction

Пример развертывания для этой архитектуры можно найти на портале GitHub.A deployment for this architecture is available on GitHub. Развертывание создает в вашей подписке следующие группы ресурсов:The deployment creates the following resource groups in your subscription:

  • hub-adds-rghub-adds-rg
  • hub-nva-rghub-nva-rg
  • hub-vnet-rghub-vnet-rg
  • onprem-vnet-rgonprem-vnet-rg
  • spoke1-vnet-rgspoke1-vnet-rg
  • spoke2-vnet-rgspoke2-vnet-rg

Файлы параметров шаблона ссылаются на эти имена, поэтому, если вы их изменяете, соответствующим образом обновите файлы параметров.The template parameter files refer to these names, so if you change them, update the parameter files to match.

Предварительные условияPrerequisites

  1. Клонируйте или скачайте ZIP-файл с эталонными архитектурами в репозитории GitHub либо создайте для него вилку.Clone, fork, or download the zip file for the reference architectures GitHub repository.

  2. Установите Azure CLI 2.0.Install Azure CLI 2.0.

  3. Установите Node.js и NPMInstall Node and NPM

  4. Установите пакет npm стандартных блоков Azure.Install the Azure building blocks npm package.

    npm install -g @mspnp/azure-building-blocks
    
  5. Из командной строки, строки bash или строки PowerShell войдите в свою учетную запись Azure, как показано ниже:From a command prompt, bash prompt, or PowerShell prompt, sign into your Azure account as follows:

    az login
    

Развертывание имитации локального центра обработки данных с помощью azbbDeploy the simulated on-premises datacenter using azbb

Чтобы развернуть архитектуру, выполните следующие действия.Follow these steps to deploy the architecture:

  1. Перейдите в папку hybrid-networking\shared-services-stack\ в репозитории GitHub.Navigate to the hybrid-networking\shared-services-stack\ folder of the GitHub repository.

  2. Откройте файл shared-services-stack.json .Open the shared-services-stack.json file.

  3. Найдите все экземпляры [replace-with-username], [replace-with-safe-mode-username],[replace-with-password] и [replace-with-safe-mode-password].Search for all instances of [replace-with-username], [replace-with-safe-mode-username],[replace-with-password], and [replace-with-safe-mode-password]. Введите значения для имени пользователя и пароля в параметрах и сохраните файл.Enter values for the user name and password in the parameters and save the file.

  4. Найдите все экземпляры [replace-with-shared-key] и введите значение для общего ключа.Search for all instances of [replace-with-shared-key] and enter a value for a shared key. Значения должны совпадать.The values must match.

  5. Сохраните файл.Save the file.

  6. Выполните следующую команду:Run the following command:

    azbb -s <subscription_id> -g onprem-vnet-rg -l <location> -p shared-services-stack.json --deploy
    
  7. Дождитесь завершения развертывания.Wait for the deployment to finish. Это развертывание создает четыре виртуальные сети, четыре виртуальных машины для работы в качестве Active Directory контроллеров домена, два VPN-шлюза и брандмауэр Azure.This deployment creates four virtual networks, four virtual machines to function as jumpboxes, four virtual machines to act as Active Directory domain controllers, two VPN Gateways, and Azure Firewall. Создание VPN-шлюза может занять более 40 минут.The VPN gateway creation can take more than 40 minutes to complete.

Проверка подключенияTest connectivity

Проверьте возможность подключения из моделируемой локальной среды к виртуальной сети концентратора.Test connectivity from the simulated on-premises environment to the hub VNet.

  1. Используйте портал Azure для поиска в группе ресурсов onprem-jb-rg виртуальной машины с именем jb-vm1.Use the Azure portal to find the VM named jb-vm1 in the onprem-jb-rg resource group.

  2. Нажмите Connect, чтобы открыть сеанс удаленного рабочего стола для виртуальной машины.Click Connect to open a remote desktop session to the VM. Используйте пароль, указанный в файле параметров onprem.json.Use the password that you specified in the onprem.json parameter file.

  3. Откройте консоль PowerShell в виртуальной машине и используйте командлет Test-NetConnection, чтобы убедиться, что вы можете подключиться к виртуальной машине Jumpbox в виртуальной сети концентратора.Open a PowerShell console in the VM, and use the Test-NetConnection cmdlet to verify that you can connect to the jumpbox VM in the hub VNet.

    Test-NetConnection 10.0.0.36 -CommonTCPPort RDP
    

Результат должен выглядеть следующим образом.The output should look similar to the following:

ComputerName     : 10.0.0.36
RemoteAddress    : 10.0.0.36
RemotePort       : 3389
InterfaceAlias   : Ethernet 2
SourceAddress    : 192.168.1.000
TcpTestSucceeded : True

Примечание

По умолчанию виртуальные машины Windows Server не разрешают трафик ICMP в Azure.By default, Windows Server VMs do not allow ICMP responses in Azure. Если вы хотите использовать команду ping для проверки возможности подключения, включите трафик ICMP в расширенном брандмауэре Windows для каждой виртуальной машины.If you want to use ping to test connectivity, you need to enable ICMP traffic in the Windows Advanced Firewall for each VM.

Повторите те же действия, чтобы проверить возможность подключения к периферийной виртуальных сетей:Repeat the same steps to test connectivity to the spoke VNets:

Test-NetConnection 10.1.0.36 -CommonTCPPort RDP
Test-NetConnection 10.2.0.36 -CommonTCPPort RDP