diff --git a/docs/reference-architectures/hybrid-networking/hub-spoke.md b/docs/reference-architectures/hybrid-networking/hub-spoke.md index 25e7b7085a4..85233c44166 100644 --- a/docs/reference-architectures/hybrid-networking/hub-spoke.md +++ b/docs/reference-architectures/hybrid-networking/hub-spoke.md @@ -3,7 +3,7 @@ title: Implementing a hub-spoke network topology in Azure description: >- How to implement a hub-spoke network topology in Azure. author: telmosampaio -ms.date: 02/14/2018 +ms.date: 02/23/2018 pnp.series.title: Implement a hub-spoke network topology in Azure pnp.series.prev: expressroute @@ -46,8 +46,6 @@ The architecture consists of the following components. * **Gateway subnet**. The virtual network gateways are held in the same subnet. -* **Shared services subnet**. A subnet in the hub VNet used to host services that can be shared among all spokes, such as DNS or AD DS. - * **Spoke VNets**. 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. Each workload might include multiple tiers, with multiple subnets connected through Azure load balancers. For more information about the application infrastructure, see [Running Windows VM workloads][windows-vm-ra] and [Running Linux VM workloads][linux-vm-ra]. * **VNet peering**. Two VNets in the same Azure region can be connected using a [peering connection][vnet-peering]. Peering connections are non-transitive, low latency connections between VNets. 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. @@ -55,7 +53,6 @@ The architecture consists of the following components. > [!NOTE] > This article only covers [Resource Manager](/azure/azure-resource-manager/resource-group-overview) 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 The following recommendations apply for most scenarios. Follow these recommendations unless you have a specific requirement that overrides them. @@ -117,231 +114,211 @@ Before you can deploy the reference architecture to your own subscription, you m 1. Clone, fork, or download the zip file for the [AzureCAT reference architectures][ref-arch-repo] GitHub repository. -2. If you prefer to use the Azure CLI, make sure you have the Azure CLI 2.0 installed on your computer. To install the CLI, follow the instructions in [Install Azure CLI 2.0][azure-cli-2]. +2. Make sure you have the Azure CLI 2.0 installed on your computer. For CLI installation instructions, see [Install Azure CLI 2.0][azure-cli-2]. -3. If you prefer to use PowerShell, make sure you have the latest PowerShell module for Azure installed on you computer. To install the latest Azure PowerShell module, follow the instructions in [Install PowerShell for Azure][azure-powershell]. +3. Install the [Azure buulding blocks][azbb] npm package. -4. From a command prompt, bash prompt, or PowerShell prompt, login to your Azure account by using one of the commands below, and follow the prompts. +4. From a command prompt, bash prompt, or PowerShell prompt, login to your Azure account by using the command below, and follow the prompts. ```bash az login ``` - ```powershell - Login-AzureRmAccount - ``` +### Deploy the simulated on-premises datacenter using azbb -### Deploy the simulated on-premises datacenter +To deploy the simulated on-premises datacenter as an Azure VNet, follow these steps: -To deploy the simulated on-premises datacenter as an Azure VNet, perform the following steps. +1. Navigate to the `hybrid-networking\hub-spoke\` folder for the repository you downloaded in the pre-requisites step above. -1. Navigate to the `hybrid-networking\hub-spoke\onprem` folder for the repository you downloaded in the pre-requisites step above. - -2. Open the `onprem.vm.parameters.json` file and enter a username and password between the quotes in line 11 and 12, as shown below, then save the file. +2. Open the `onprem.json` file and enter a username and password between the quotes in line 36 and 37, as shown below, then save the file. ```bash "adminUsername": "XXX", "adminPassword": "YYY", ``` -3. Run the bash or PowerShell command below to deploy the simulated on-premises environment as a VNet in Azure. Substitute the values with your subscription, resource group name, and Azure region. +3. On line 38, for `osType`, type `Windows` or `Linux` to install either Windows Server 2016 Datacenter, or Ubuntu 16.04 as the operating system for the jumpbox. - ```bash - sh ./onprem.deploy.sh --subscription xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \ - --resourcegroup ra-onprem-rg \ - --location westus - ``` +4. Run `azbb` to deploy the simulated onprem environment as shown below. - ```powershell - ./onprem.deploy.ps1 -Subscription xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ` - -ResourceGroup ra-onprem-rg ` - -Location westus + ```bash + azbb -s -g onprem-vnet-rg - l -p onoprem.json --deploy ``` > [!NOTE] - > If you decide to use a different resource group name (other than `ra-onprem-rg`), make sure to search for all parameter files that use that name and edit them to use your own resource group name. + > If you decide to use a different resource group name (other than `onprem-vnet-rg`), make sure to search for all parameter files that use that name and edit them to use your own resource group name. -4. Wait for the deployment to finish. This deployment creates a virtual network, a virtual machine running Ubuntu, and a VPN gateway. The VPN gateway creation can take more than 40 minutes to complete. +5. Wait for the deployment to finish. This deployment creates a virtual network, a virtual machine, and a VPN gateway. The VPN gateway creation can take more than 40 minutes to complete. ### Azure hub VNet To deploy the hub VNet, and connect to the simulated on-premises VNet created above, perform the following steps. -1. Navigate to the `hybrid-networking\hub-spoke\hub` folder for the repository you downloaded in the pre-requisites step above. - -2. Open the `hub.vm.parameters.json` file and enter a username and password between the quotes in line 11 and 12, as shown below, then save the file. +1. Open the `hub-vnet.json` file and enter a username and password between the quotes in line 39 and 40, as shown below. ```bash "adminUsername": "XXX", "adminPassword": "YYY", ``` -3. Open the `hub.gateway.parameters.json` file and enter a shared key between the quotes in line 23, as shown below, then save the file. Keep a note of this value, you will need to use it later in the deployment. +2. On line 41, for `osType`, type `Windows` or `Linux` to install either Windows Server 2016 Datacenter, or Ubuntu 16.04 as the operating system for the jumpbox. + +3. Enter a shared key between the quotes in line 72, as shown below, then save the file. ```bash "sharedKey": "", ``` -4. Run the bash or PowerShell command below to deploy the simulated on-premises environment as a VNet in Azure. Substitute the values with your subscription, resource group name, and Azure region. +4. Run `azbb` to deploy the simulated onprem environment as shown below. ```bash - sh ./hub.deploy.sh --subscription xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \ - --resourcegroup ra-hub-rg \ - --location westus + azbb -s -g hub-vnet-rg - l -p hub-vnet.json --deploy ``` + > [!NOTE] + > If you decide to use a different resource group name (other than `hub-vnet-rg`), make sure to search for all parameter files that use that name and edit them to use your own resource group name. + +5. Wait for the deployment to finish. This deployment creates a virtual network, a virtual machine, a VPN gateway, and a connection to the gateway created in the previous section. The VPN gateway creation can take more than 40 minutes to complete. + +### (Optional) Test connectivity from onprem to hub + +To test conectivity from the simulated on-premises environment to the hub VNet using Windows VMs, perform the following steps. + +1. From the Azure portal, navigate to the `onprem-jb-rg` resource group, then click on the `jb-vm1` virtual machine resource. + +2. On the top left hand corner of your VM blade in the portal, click `Connect`, and follow the prompts to use remote desktop to connect to the VM. Make sure to use the username and password you specified in lines 36 and 37 in the `onprem.json` file. + +3. Open a PowerShell console in the VM, and use the `Test-NetConnection` cmdlet to verify that you can connect to the hub jumpbox VM as shown below. ```powershell - ./hub.deploy.ps1 -Subscription xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ` - -ResourceGroup ra-hub-rg ` - -Location westus + Test-NetConnection 10.0.0.68 -CommonTCPPort RDP ``` > [!NOTE] - > If you decide to use a different resource group name (other than `ra-hub-rg`), make sure to search for all parameter files that use that name and edit them to use your own resource group name. + > By default, Windows Server VMs do not allow ICMP responses in Azure. If you want to use `ping` to test connectivity, you need to enable ICMP traffic in the Windows Advanced Firewall for each VM. -5. Wait for the deployment to finish. This deployment creates a virtual network, a virtual machine running Ubuntu, a VPN gateway, and a connection to the gateway created in the previous section. The VPN gateway creation can take more than 40 minutes to complete. +To test conectivity from the simulated on-premises environment to the hub VNet using Linux VMs, perform the following steps: -### Connection from on-premises to the hub +1. From the Azure portal, navigate to the `onprem-jb-rg` resource group, then click on the `jb-vm1` virtual machine resource. -To connect from the simulated on-premises datacenter to the hub VNet, perform the following steps. +2. On the top left hand corner of your VM blade in the portal, click `Connect`, and then copy the `ssh` command shown on the portal. -1. Navigate to the `hybrid-networking\hub-spoke\onprem` folder for the repository you downloaded in the pre-requisites step above. - -2. Open the `onprem.connection.parameters.json` file and enter a shared key between the quotes in line 9, as shown below, then save the file. This shared key value must be the same used in the on-premises gateway you deployed previously. +3. From a Linux prompt, run `ssh` to connect to the simulated on-premises environment jumpbox witht the information you copied in step 2 above, as shown below. ```bash - "sharedKey": "", + ssh @ ``` -3. Run the bash or PowerShell command below to deploy the simulated on-premises environment as a VNet in Azure. Substitute the values with your subscription, resource group name, and Azure region. +4. Use the password you specified in line 37 in the `onprem.json` file to the connect to the VM. - ```bash - sh ./onprem.connection.deploy.sh --subscription xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \ - --resourcegroup ra-onprem-rg \ - --location westus - ``` +5. Use the `ping` command to test connectivity to the hub jumpbox, as shown below. - ```powershell - ./onprem.connection.deploy.ps1 -Subscription xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ` - -ResourceGroup ra-onprem-rg ` - -Location westus + ```bash + ping 10.0.0.68 ``` - > [!NOTE] - > If you decide to use a different resource group name (other than `ra-onprem-rg`), make sure to search for all parameter files that use that name and edit them to use your own resource group name. - -4. Wait for the deployment to finish. This deployment creates a connection between the VNet used to simulate an on-premises datacenter, and the hub VNet. ### Azure spoke VNets -To deploy the spoke VNets, and connect to the hub VNet created above, perform the following steps. - -1. Switch to the `hybrid-networking\hub-spoke\spokes` folder for the repository you download in the pre-requisites step above. +To deploy the spoke VNets, perform the following steps. -2. Open the `spoke1.web.parameters.json` file and enter a username and password between the quotes in line 53 and 54, as shown below, then save the file. +1. Open the `spoke1.json` file and enter a username and password between the quotes in lines 47 and 48, as shown below, then save the file. ```bash "adminUsername": "XXX", "adminPassword": "YYY", ``` -3. Repeat the previous step for file `spoke2.web.parameters.json`. +2. On line 49, for `osType`, type `Windows` or `Linux` to install either Windows Server 2016 Datacenter, or Ubuntu 16.04 as the operating system for the jumpbox. -4. Run the bash or PowerShell command below to deploy the first spoke and connect it to the hub. Substitute the values with your subscription, resource group name, and Azure region. +3. Run `azbb` to deploy the first spoke VNet environment as shown below. ```bash - sh ./spoke.deploy.sh --subscription xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \ - --resourcegroup ra-spoke1-rg \ - --location westus \ - --spoke 1 - ``` - - ```powershell - ./spoke.deploy.ps1 -Subscription xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ` - -ResourceGroup ra-spoke1-rg ` - -Location westus ` - -Spoke 1 + azbb -s -g spoke1-vnet-rg - l -p spoke1.json --deploy ``` + > [!NOTE] - > If you decide to use a different resource group name (other than `ra-spoke1-rg`), make sure to search for all parameter files that use that name and edit them to use your own resource group name. + > If you decide to use a different resource group name (other than `spoke1-vnet-rg`), make sure to search for all parameter files that use that name and edit them to use your own resource group name. -5. Wait for the deployment to finish. This deployment creates a virtual network, a load balancer with three virtual machine running Ubuntu and Apache, and a VNet peering connection to the hub VNet created in the previous section. This deployment may take over 20 minutes. +3. Repeat step 1 above for file `spoke2.json`. -6. Run the bash or PowerShell command below to deploy the first spoke and connect it to the hub. Substitute the values with your subscription, resource group name, and Azure region. +4. Run `azbb` to deploy the second spoke VNet environment as shown below. ```bash - sh ./spoke.deploy.sh --subscription xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \ - --resourcegroup ra-spoke2-rg \ - --location westus \ - --spoke 2 - ``` - - ```powershell - ./spoke.deploy.ps1 -Subscription xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ` - -ResourceGroup ra-spoke2-rg ` - -Location westus ` - -Spoke 2 + azbb -s -g spoke2-vnet-rg - l -p spoke2.json --deploy ``` > [!NOTE] - > If you decide to use a different resource group name (other than `ra-spoke2-rg`), make sure to search for all parameter files that use that name and edit them to use your own resource group name. - -5. Wait for the deployment to finish. This deployment creates a virtual network, a load balancer with three virtual machine running Ubuntu and Apache, and a VNet peering connection to the hub VNet created in the previous section. This deployment may take over 20 minutes. + > If you decide to use a different resource group name (other than `spoke2-vnet-rg`), make sure to search for all parameter files that use that name and edit them to use your own resource group name. ### Azure hub VNet peering to spoke VNets -To deploy the VNet peering connections for the hub VNet, perform the following steps. +To create a peering connection from the hub VNet to the spoke VNets, perform the following steps. -1. Switch to the `hybrid-networking\hub-spoke\hub` folder for the repository you download in the pre-requisites step above. +1. Open the `hub-vnet-peering.json` file and verify that the resource group name, and virtual network name for each of the virtual network peerings starting in line 29 are correct. -2. Run the bash or PowerShell command below to deploy the peering connection to the first spoke. Substitute the values with your subscription, resource group name, and Azure region. +2. Run `azbb` to deploy the first spoke VNet environment as shown below. ```bash - sh ./hub.peering.deploy.sh --subscription xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \ - --resourcegroup ra-hub-rg \ - --location westus \ - --spoke 1 + azbb -s -g hub-vnet-rg - l -p hub-vnet-peering.json --deploy ``` + > [!NOTE] + > If you decide to use a different resource group name (other than `hub-vnet-rg`), make sure to search for all parameter files that use that name and edit them to use your own resource group name. + +### Test connectivity + +To test conectivity from the simulated on-premises environment to the spoke VNets using Windows VMs, perform the following steps. + +1. From the Azure portal, navigate to the `onprem-jb-rg` resource group, then click on the `jb-vm1` virtual machine resource. + +2. On the top left hand corner of your VM blade in the portal, click `Connect`, and follow the prompts to use remote desktop to connect to the VM. Make sure to use the username and password you specified in lines 36 and 37 in the `onprem.json` file. + +3. Open a PowerShell console in the VM, and use the `Test-NetConnection` cmdlet to verify that you can connect to the hub jumpbox VM as shown below. + ```powershell - ./hub.peering.deploy.ps1 -Subscription xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ` - -ResourceGroup ra-hub-rg ` - -Location westus ` - -Spoke 1 + Test-NetConnection 10.1.0.68 -CommonTCPPort RDP + Test-NetConnection 10.2.0.68 -CommonTCPPort RDP ``` -2. Run the bash or PowerShell command below to deploy the peering connection to the second spoke. Substitute the values with your subscription, resource group name, and Azure region. +To test conectivity from the simulated on-premises environment to the spoke VNets using Linux VMs, perform the following steps: + +1. From the Azure portal, navigate to the `onprem-jb-rg` resource group, then click on the `jb-vm1` virtual machine resource. + +2. On the top left hand corner of your VM blade in the portal, click `Connect`, and then copy the `ssh` command shown on the portal. + +3. From a Linux prompt, run `ssh` to connect to the simulated on-premises environment jumpbox witht the information you copied in step 2 above, as shown below. ```bash - sh ./hub.peering.deploy.sh --subscription xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \ - --resourcegroup ra-hub-rg \ - --location westus \ - --spoke 2 + ssh @ ``` - ```powershell - ./hub.peering.deploy.ps1 -Subscription xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ` - -ResourceGroup ra-hub-rg ` - -Location westus ` - -Spoke 2 - ``` +5. Use the password you specified in line 37 in the `onprem.json` file to the connect to the VM. -### Test connectivity +6. Use the `ping` command to test connectivity to the jumpbox VMs in each spoke, as shown below. -To verify that the hub-spoke topology connected to an on-premises datacenter deployment worked, follow these steps. + ```bash + ping 10.1.0.68 + ping 10.2.0.68 + ``` -1. From the [Azure portal][portal], connect to your subscription, and navigate to the `ra-onprem-vm1` virtual machine in the `ra-onprem-rg` resource group. +### Add connectivity between spokes -2. In the `Overview` blade, note the `Public IP address` for the VM. +If you want to allow spokes to connect to each other, you need to use a newtwork virtual appliance (NVA) as a router in the hub virtual netowrk, and force traffic from spokes to the router when trying to connect to another spoke. To deploy a basic sample NVA as a single VM, and the necessary uder defined routes to allow the two spoke VNets to connect, perform the following steps: -3. Use an SSH client to connect to the IP address you noted above using the user name and password you specified during deployment. +1. Open the `hub-nva.json` file and enter a username and password between the quotes in lines 13 and 14, as shown below, then save the file. -4. From the command prompt on the VM you connected to, run the command below to test connectivity from the on-premises VNet to the Spoke1 VNet. + ```bash + "adminUsername": "XXX", + "adminPassword": "YYY", + ``` +2. Run `azbb` to deploy the NVA VM and user defined routes. ```bash - ping 10.1.1.37 + azbb -s -g hub-nva-rg - l -p hub-nva.json --deploy ``` + > [!NOTE] + > If you decide to use a different resource group name (other than `hub-nva-rg`), make sure to search for all parameter files that use that name and edit them to use your own resource group name. [azure-cli-2]: /azure/install-azure-cli -[azure-powershell]: /powershell/azure/install-azure-ps?view=azuresmps-3.7.0 +[azbb]: https://github.com/mspnp/template-building-blocks/wiki/Install-Azure-Building-Blocks [azure-vpn-gateway]: /azure/vpn-gateway/vpn-gateway-about-vpngateways [best-practices-security]: /azure/best-practices-network-securit [connect-to-an-Azure-vnet]: https://technet.microsoft.com/library/dn786406.aspx diff --git a/docs/reference-architectures/hybrid-networking/images/hub-spoke.png b/docs/reference-architectures/hybrid-networking/images/hub-spoke.png index ba912d7dd40..50e67685f12 100644 Binary files a/docs/reference-architectures/hybrid-networking/images/hub-spoke.png and b/docs/reference-architectures/hybrid-networking/images/hub-spoke.png differ diff --git a/docs/reference-architectures/hybrid-networking/images/shared-services.png b/docs/reference-architectures/hybrid-networking/images/shared-services.png new file mode 100644 index 00000000000..7554779c68a Binary files /dev/null and b/docs/reference-architectures/hybrid-networking/images/shared-services.png differ diff --git a/docs/reference-architectures/hybrid-networking/shared-services.md b/docs/reference-architectures/hybrid-networking/shared-services.md new file mode 100644 index 00000000000..0b55ddb19f1 --- /dev/null +++ b/docs/reference-architectures/hybrid-networking/shared-services.md @@ -0,0 +1,273 @@ +--- +title: Implementing a hub-spoke network topology with shared services in Azure +description: >- + How to implement a hub-spoke network topology with shared services in Azure. +author: telmosampaio +ms.date: 02/25/2018 + +pnp.series.title: Implement a hub-spoke network topology with shared services in Azure +pnp.series.prev: hub-spoke +--- +# Implement a hub-spoke network topology with shared services in Azure + +This reference architecture builds on top of the [hub-spoke][guidance-hub-spoke] reference architecture to include shared servcices in the hub that can be consumed by all spokes. As a first step into migrating a datacenter to the cloud, and building a [virtual datacenter], the first services you need to share are identity, and security. This reference archiecture shows you how to extend your 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, in a hub-spoke topology. [**Deploy this solution**](#deploy-the-solution). + +![[0]][0] + +*Download a [Visio file][visio-download] of this architecture* + +The benefits of this toplogy include: + +* **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. +* **Separation of concerns** between central IT (SecOps, InfraOps) and workloads (DevOps). + +Typical uses for this architecture include: + +* 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. + +## Architecture + +The architecture consists of the following components. + +* **On-premises network**. A private local-area network running within an organization. + +* **VPN device**. A device or service that provides external connectivity to the on-premises network. 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. 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-appliance]. + +* **VPN virtual network gateway or ExpressRoute gateway**. The virtual network gateway enables the VNet to connect to the VPN device, or ExpressRoute circuit, used for connectivity with your on-premises network. For more information, see [Connect an on-premises network to a Microsoft Azure virtual network][connect-to-an-Azure-vnet]. + +> [!NOTE] +> 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 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**. 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**. 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. Each workload might include multiple tiers, with multiple subnets connected through Azure load balancers. For more information about the application infrastructure, see [Running Windows VM workloads][windows-vm-ra] and [Running Linux VM workloads][linux-vm-ra]. + +* **VNet peering**. Two VNets in the same Azure region can be connected using a [peering connection][vnet-peering]. Peering connections are non-transitive, low latency connections between VNets. 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. + +> [!NOTE] +> This article only covers [Resource Manager](/azure/azure-resource-manager/resource-group-overview) 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][guidance-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 + +Most enterprise organizations have an Active Directory Directory Services (ADDS) environment in their on-premises datacenter. To facilitate management of assets moved to Azure from your on-premises network that depend on ADDS, it is recommended to host ADDS domain controllers in Azure. + +If you make use of 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. And place your domain controllers in a central VNet (hub) that dependent workloads can access. + +### Security + +As you move workloads from your on-premises environment to Azure, some of these workloads will require to be hosted in VMs. And due to compliance you may need to enforce restrictions on traffic traversing those workloads. + +You can use network virtula appliances (NVAs) in Azure to host different types of security and performance services. 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. + +> [!NOTE] +> The deployment scripts for this reference architecture use an Ubuntu VM with IP forwarding enbaled to mimic a network virtual appliance. + +## Considerations + +### Overcoming VNet peering limits + +Make sure you consider the [limitation on number of VNets peerings per VNet][vnet-peering-limit] in Azure. If you decide you need more spokes than the limit will allow, consider creating a hub-spoke-hub-spoke topology, where the first level of spokes also act as hubs. The following diagram shows this approach. + +![[3]][3] + +Also consider what services are shared in the hub, to ensure the hub scales for a larger number of spokes. For instance, if your hub provides firewall services, consider the bandwidth limits of your firewall solution when adding multiple spokes. You might want to move some of these shared services to a second level of hubs. + +## Deploy the solution + +A deployment for this architecture is available on [GitHub][ref-arch-repo]. It uses Ubuntu VMs in each VNet to test connectivity. There are no actual services hosted in the **shared-services** subnet in the **hub VNet**. + +### Prerequisites + +Before you can deploy the reference architecture to your own subscription, you must perform the following steps. + +1. Clone, fork, or download the zip file for the [AzureCAT reference architectures][ref-arch-repo] GitHub repository. + +2. Make sure you have the Azure CLI 2.0 installed on your computer. For CLI installation instructions, see [Install Azure CLI 2.0][azure-cli-2]. + +3. Install the [Azure buulding blocks][azbb] npm package. + +4. From a command prompt, bash prompt, or PowerShell prompt, login to your Azure account by using the command below, and follow the prompts. + + ```bash + az login + ``` + +### Deploy the simulated on-premises datacenter using azbb + +To deploy the simulated on-premises datacenter as an Azure VNet, follow these steps: + +1. Navigate to the `hybrid-networking\shared-services-stack\` folder for the repository you downloaded in the pre-requisites step above. + +2. Open the `onprem.json` file and enter a username and password between the quotes in line 45 and 46, as shown below, then save the file. + + ```bash + "adminUsername": "XXX", + "adminPassword": "YYY", + ``` + +3. Run `azbb` to deploy the simulated onprem environment as shown below. + + ```bash + azbb -s -g onprem-vnet-rg - l -p onoprem.json --deploy + ``` + > [!NOTE] + > If you decide to use a different resource group name (other than `onprem-vnet-rg`), make sure to search for all parameter files that use that name and edit them to use your own resource group name. + +4. Wait for the deployment to finish. This deployment creates a virtual network, a virtual machine running Windows, and a VPN gateway. The VPN gateway creation can take more than 40 minutes to complete. + +### Azure hub VNet + +To deploy the hub VNet, and connect to the simulated on-premises VNet created above, perform the following steps. + +1. Open the `hub-vnet.json` file and enter a username and password between the quotes in line 50 and 51, as shown below. + + ```bash + "adminUsername": "XXX", + "adminPassword": "YYY", + ``` + +2. On line 52, for `osType`, type `Windows` or `Linux` to install either Windows Server 2016 Datacenter, or Ubuntu 16.04 as the operating system for the jumpbox. + +3. Enter a shared key between the quotes in line 83, as shown below, then save the file. + + ```bash + "sharedKey": "", + ``` + +4. Run `azbb` to deploy the simulated onprem environment as shown below. + + ```bash + azbb -s -g hub-vnet-rg - l -p hub-vnet.json --deploy + ``` + > [!NOTE] + > If you decide to use a different resource group name (other than `hub-vnet-rg`), make sure to search for all parameter files that use that name and edit them to use your own resource group name. + +5. Wait for the deployment to finish. This deployment creates a virtual network, a virtual machine, a VPN gateway, and a connection to the gateway created in the previous section. The VPN gateway creation can take more than 40 minutes to complete. + +### ADDS in Azure + +To deploy the ADDS domain controllers in Azure, perform the following steps. + +1. Open the `hub-adds.json` file and enter a username and password between the quotes in lines 14 and 15, as shown below, then save the file. + + ```bash + "adminUsername": "XXX", + "adminPassword": "YYY", + ``` + +2. Run `azbb` to deploy the ADDS domain controllers as shown below. + + ```bash + azbb -s -g hub-adds-rg - l -p hub-adds.json --deploy + ``` + + > [!NOTE] + > If you decide to use a different resource group name (other than `hub-adds-rg`), make sure to search for all parameter files that use that name and edit them to use your own resource group name. + + > [!NOTE] + > This part of the deployment may take several minutes, since it requires joining the two VMs to the domain hosted int he simulated on-premises datacenter, then installing AD DS on them. + +### NVA + +To deploy an NVA in the `dmz` subnet, perform the following steps: + +1. Open the `hub-nva.json` file and enter a username and password between the quotes in lines 13 and 14, as shown below, then save the file. + + ```bash + "adminUsername": "XXX", + "adminPassword": "YYY", + ``` +2. Run `azbb` to deploy the NVA VM and user defined routes. + + ```bash + azbb -s -g hub-nva-rg - l -p hub-nva.json --deploy + ``` + > [!NOTE] + > If you decide to use a different resource group name (other than `hub-nva-rg`), make sure to search for all parameter files that use that name and edit them to use your own resource group name. + +### Azure spoke VNets + +To deploy the spoke VNets, perform the following steps. + +1. Open the `spoke1.json` file and enter a username and password between the quotes in lines 52 and 53, as shown below, then save the file. + + ```bash + "adminUsername": "XXX", + "adminPassword": "YYY", + ``` + +2. On line 54, for `osType`, type `Windows` or `Linux` to install either Windows Server 2016 Datacenter, or Ubuntu 16.04 as the operating system for the jumpbox. + +3. Run `azbb` to deploy the first spoke VNet environment as shown below. + + ```bash + azbb -s -g spoke1-vnet-rg - l -p spoke1.json --deploy + ``` + + > [!NOTE] + > If you decide to use a different resource group name (other than `spoke1-vnet-rg`), make sure to search for all parameter files that use that name and edit them to use your own resource group name. + +3. Repeat step 1 above for file `spoke2.json`. + +4. Run `azbb` to deploy the second spoke VNet environment as shown below. + + ```bash + azbb -s -g spoke2-vnet-rg - l -p spoke2.json --deploy + ``` + > [!NOTE] + > If you decide to use a different resource group name (other than `spoke2-vnet-rg`), make sure to search for all parameter files that use that name and edit them to use your own resource group name. + +### Azure hub VNet peering to spoke VNets + +To create a peering connection from the hub VNet to the spoke VNets, perform the following steps. + +1. Open the `hub-vnet-peering.json` file and verify that the resource group name, and virtual network name for each of the virtual network peerings starting in line 29 are correct. + +2. Run `azbb` to deploy the first spoke VNet environment as shown below. + + ```bash + azbb -s -g hub-vnet-rg - l -p hub-vnet-peering.json --deploy + ``` + + > [!NOTE] + > If you decide to use a different resource group name (other than `hub-vnet-rg`), make sure to search for all parameter files that use that name and edit them to use your own resource group name. + + + +[azure-cli-2]: /azure/install-azure-cli +[azbb]: https://github.com/mspnp/template-building-blocks/wiki/Install-Azure-Building-Blocks +[guidance-hub-spoke]: ./hub-spoke.md +[azure-vpn-gateway]: /azure/vpn-gateway/vpn-gateway-about-vpngateways +[best-practices-security]: /azure/best-practices-network-securit +[connect-to-an-Azure-vnet]: https://technet.microsoft.com/library/dn786406.aspx +[guidance-expressroute]: ./expressroute.md +[guidance-vpn]: ./vpn.md +[linux-vm-ra]: ../virtual-machines-linux/index.md +[hybrid-ha]: ./expressroute-vpn-failover.md +[naming conventions]: /azure/guidance/guidance-naming-conventions +[resource-manager-overview]: /azure/azure-resource-manager/resource-group-overview +[vnet-peering]: /azure/virtual-network/virtual-network-peering-overview +[vnet-peering-limit]: /azure/azure-subscription-service-limits#networking-limits +[vpn-appliance]: /azure/vpn-gateway/vpn-gateway-about-vpn-devices +[windows-vm-ra]: ../virtual-machines-windows/index.md + +[visio-download]: https://archcenter.azureedge.net/cdn/hybrid-network-hub-spoke.vsdx +[ref-arch-repo]: https://github.com/mspnp/reference-architectures +[0]: ./images/shared-services.png "Shared services topology in Azure" +[3]: ./images/hub-spokehub-spoke.svg "Hub-spoke-hub-spoke topology in Azure" +[ARM-Templates]: https://azure.microsoft.com/documentation/articles/resource-group-authoring-templates/