From 4cb1b0486e9a6d9e503f3047ae0346fa64406904 Mon Sep 17 00:00:00 2001 From: Andrew Oakley Date: Mon, 22 Jul 2019 17:13:21 -0700 Subject: [PATCH] Update deployment instructions --- .../hybrid-networking/hub-spoke.md | 215 +++++++----------- .../hybrid-networking/shared-services.md | 117 ++-------- .../n-tier/n-tier-cassandra.md | 4 +- .../n-tier/n-tier-sql-server.md | 71 ++---- 4 files changed, 124 insertions(+), 283 deletions(-) diff --git a/docs/reference-architectures/hybrid-networking/hub-spoke.md b/docs/reference-architectures/hybrid-networking/hub-spoke.md index 9272ceb575d..bf48c88cdcb 100644 --- a/docs/reference-architectures/hybrid-networking/hub-spoke.md +++ b/docs/reference-architectures/hybrid-networking/hub-spoke.md @@ -1,16 +1,16 @@ --- -title: Implement a hub-spoke network topology in Azure +title: Hub-spoke network topology in Azure titleSuffix: Azure Reference Architectures -description: Implement a hub-spoke network topology in Azure. -author: telmosampaio -ms.date: 06/05/2019 +description: This reference architecture deploys a hub-spoke network topology in Azure. +author: MikeWasson +ms.date: 08/19/2019 ms.topic: reference-architecture ms.service: architecture-center ms.subservice: reference-architecture ms.custom: seodec18, networking --- -# Implement a hub-spoke network topology in Azure +# Hub-spoke network topology in Azure This reference architecture shows how to implement a hub-spoke topology in Azure. The *hub* is a virtual network (VNet) in Azure that acts as a central point of connectivity to your on-premises network. The *spokes* are VNets that peer with the hub, and can be used to isolate workloads. Traffic flows between the on-premises datacenter and the hub through an ExpressRoute or VPN gateway connection. [**Deploy this solution**](#deploy-the-solution). @@ -101,7 +101,9 @@ Also consider what services are shared in the hub, to ensure the hub scales for ## Deploy the solution -A deployment for this architecture is available on [GitHub][ref-arch-repo]. It uses VMs in each VNet to test connectivity. There are no actual services hosted in the **shared-services** subnet in the **hub VNet**. +A deployment for this architecture is available on [GitHub][ref-arch-repo]. It uses VMs in each VNet to test connectivity. Two instances of each jumpbox are deployed — one Linux VM and one Windows VM. In a real deployment, you would deploy a single type. + +No shared services are deployed in the hub. For a version that includes shared services, see [Hub-spoke network topology with shared services in Azure](./shared-services.md). The deployment creates the following resource groups in your subscription: @@ -111,210 +113,161 @@ The deployment creates the following resource groups in your subscription: - spoke1-vnet-rg - spoke2-vnet-rg -The template parameter files refer to these names, so if you change them, update the parameter files to match. - ### Prerequisites [!INCLUDE [ref-arch-prerequisites.md](../../../includes/ref-arch-prerequisites.md)] -### Deploy the simulated on-premises datacenter +### Deploy the reference architecture -To deploy the simulated on-premises datacenter as an Azure VNet, follow these steps: +Follow these steps to deploy the architecture: 1. Navigate to the `hybrid-networking/hub-spoke` folder of the reference architectures repository. -2. Open the `onprem.json` file. Replace the values for `adminUsername` and `adminPassword`. - - ```json - "adminUsername": "", - "adminPassword": "", - ``` - -3. (Optional) For a Linux deployment, set `osType` to `Linux`. - -4. Run the following command: - - ```bash - azbb -s -g onprem-vnet-rg -l -p onprem.json --deploy - ``` - -5. Wait for the deployment to finish. This deployment creates a virtual network, a virtual machine, and a VPN gateway. It can take about 40 minutes to create the VPN gateway. - -### Deploy the hub VNet +1. Open the `hub-spoke.json` file. -To deploy the hub VNet, perform the following steps. - -1. Open the `hub-vnet.json` file. Replace the values for `adminUsername` and `adminPassword`. +1. Replace the values for all instances of `[replace-with-username]` and `[replace-with-password]`. ```json - "adminUsername": "", - "adminPassword": "", + "adminUsername": "[replace-with-username]", + "adminPassword": "[replace-with-password]", ``` -2. (Optional) For a Linux deployment, set `osType` to `Linux`. - -3. Find both instances of `sharedKey` and enter a shared key for the VPN connection. The values must match. +1. Find both instances of `[replace-with-shared-key]` and enter a shared key for the VPN connection. The values must match. ```json - "sharedKey": "", + "sharedKey": "[replace-with-shared-key]", ``` -4. Run the following command: +1. Save the file. + +1. Run the following command: ```bash - azbb -s -g hub-vnet-rg -l -p hub-vnet.json --deploy + azbb -s -g onprem-vnet-rg -l -p hub-spoke.json --deploy ``` -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. It can take about 40 minutes to create the VPN gateway. +1. Wait for the deployment to finish. This deployment creates four virtual networks, eight VMs, two VPN gateways, the connection between the two VPN gateways, and configures virtual network peering. It can take about 40 minutes to create the VPN gateways. -### Test connectivity to the hub VNet — Windows deployment +### Test connectivity — Windows -To test connectivity from the simulated on-premises environment to the hub VNet using Windows VMs, follow these steps: +To test connectivity from the simulated on-premises environment to the hub and spokes using Windows, follow these steps: 1. Use the Azure portal to find the VM named `jb-vm1` in the `onprem-jb-rg` resource group. -2. Click `Connect` to open a remote desktop session to the VM. Use the password that you specified in the `onprem.json` parameter file. +2. Click `Connect` to open a remote desktop session to the VM. Use the password that you specified in the `hub-spoke.json` parameter file. -3. 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. +3. 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. ```powershell - Test-NetConnection 10.0.0.68 -CommonTCPPort RDP + Test-NetConnection 10.0.0.36 -CommonTCPPort RDP ``` -The output should look similar to the following: + The output should look similar to the following: -```powershell -ComputerName : 10.0.0.68 -RemoteAddress : 10.0.0.68 -RemotePort : 3389 -InterfaceAlias : Ethernet 2 -SourceAddress : 192.168.1.000 -TcpTestSucceeded : True -``` + ```powershell + ComputerName : 10.0.0.36 + RemoteAddress : 10.0.0.36 + RemotePort : 3389 + InterfaceAlias : Ethernet 2 + SourceAddress : 192.168.1.000 + TcpTestSucceeded : True + ``` + +3. Use the `Test-NetConnection` cmdlet to verify that you can connect to the jumpbox VMs in the spokes. + + ```powershell + Test-NetConnection 10.1.0.36 -CommonTCPPort RDP + Test-NetConnection 10.2.0.36 -CommonTCPPort RDP + ``` > [!NOTE] -> 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. +> By default, Windows Server VMs do not allow ICMP responses in Azure. If you want to use `ping` to test connectivity, enable ICMP traffic in the Windows Advanced Firewall for each VM. -### Test connectivity to the hub VNet — Linux deployment +### Test connectivity — Linux -To test connectivity from the simulated on-premises environment to the hub VNet using Linux VMs, follow these steps: +To test connectivity from the simulated on-premises environment to the hub and spokes using Linux, follow these steps: -1. Use the Azure portal to find the VM named `jb-vm1` in the `onprem-jb-rg` resource group. +1. Use the Azure portal to find the VM named `jbl-vm1` in the `onprem-jb-rg` resource group. 2. Click `Connect` and copy the `ssh` command shown in the portal. -3. From a Linux prompt, run `ssh` to connect to the simulated on-premises environment. Use the password that you specified in the `onprem.json` parameter file. +3. Run `ssh` to connect to the simulated on-premises environment. Use the password that you specified in the `hub-spoke.json` parameter file. -4. Use the `nc` command to test connectivity to the jumpbox VM in the hub VNet: +4. Use the `nc` command to test connectivity to the jumpbox VM in the hub: ```shell - nc -vzw 1 10.0.0.68 22 + nc -vzw 1 10.0.0.37 22 ``` -### Deploy the spoke VNets - -To deploy the spoke VNets, perform the following steps. - -1. Open the `spoke1.json` file. Replace the values for `adminUsername` and `adminPassword`. + The output should look similar to the following: - ```json - "adminUsername": "", - "adminPassword": "", - ``` - -2. (Optional) For a Linux deployment, set `osType` to `Linux`. + ```shell + Connection to 10.0.0.37 22 port [tcp/ssh] succeeded! + ``` -3. Run the following command: +4. Use the `nc` command to test connectivity to the jumpbox VMs in each spoke: ```bash - azbb -s -g spoke1-vnet-rg -l -p spoke1.json --deploy + nc -vzw 1 10.1.0.37 22 + nc -vzw 1 10.2.0.37 22 ``` -4. Repeat steps 1-2 for the `spoke2.json` file. +### Add connectivity between spokes + +This step is optional. If you want to allow spokes to connect to each other, use [Azure Firewall](/azure/firewall/) to force traffic from spokes to the router when trying to connect to another spoke. Perform the following steps to deploy Azure Firewall, firewall rules to allow RDP and SSH, and user-defined routes (UDRs) to allow the two spoke VNets to connect: -5. Run the following command: +1. Navigate to the `hybrid-networking/hub-spoke` folder of the reference architectures repository. - ```bash - azbb -s -g spoke2-vnet-rg -l -p spoke2.json --deploy - ``` +2. Run the following command: -6. Run the following command: + ```bash + azbb -s -g hub-vnet-rg -l -p hub-firewall.json --deploy + ``` - ```bash - azbb -s -g hub-vnet-rg -l -p hub-vnet-peering.json --deploy - ``` +> [!NOTE] +> The private IP address of the Azure Firewall is set to 10.0.0.132. This will be the IP address for this deployment due to the way Azure allocates private IP addresses. Any modifications to this deployment may change this default address. In that situation, edit the `hub-firewall.json` route tables and replace all instances of `nextHop` in the routes to point to the correct private IP address of Azure Firewall. -### Test connectivity to the spoke VNets — Windows deployment +### Test connectivity between spokes — Windows -To test connectivity from the simulated on-premises environment to the spoke VNets using Windows VMs, perform the following steps: +If you connected the spokes, perform these steps to verify connectivity using Windows: 1. Use the Azure portal to find the VM named `jb-vm1` in the `onprem-jb-rg` resource group. -2. Click `Connect` to open a remote desktop session to the VM. Use the password that you specified in the `onprem.json` parameter file. +2. Click `Connect` to open a remote desktop session to the VM. Use the password that you specified in the `hub-spoke.json` parameter file. + +3. From inside this remote desktop session, open another remote desktop session to 10.1.0.36. That's the private IP address of the jumpbox in spoke 1. -3. Open a PowerShell console in the VM, and use the `Test-NetConnection` cmdlet to verify that you can connect to the jumpbox VMs in the spoke VNets. +4. From the second remote desktop session, open a PowerShell console. Use the `Test-NetConnection` cmdlet to verify that you can connect to the jumpbox VM in spoke 2. ```powershell - Test-NetConnection 10.1.0.68 -CommonTCPPort RDP - Test-NetConnection 10.2.0.68 -CommonTCPPort RDP + Test-NetConnection 10.2.0.36 -CommonTCPPort RDP ``` -### Test connectivity to the spoke VNets — Linux deployment +### Test connectivity between spokes — Linux -To test connectivity from the simulated on-premises environment to the spoke VNets using Linux VMs, perform the following steps: +If you connected the spokes, perform these steps to verify connectivity using Linux: -1. Use the Azure portal to find the VM named `jb-vm1` in the `onprem-jb-rg` resource group. +1. Use the Azure portal to find the VM named `jbl-vm1` in the `onprem-jb-rg` resource group. 2. Click `Connect` and copy the `ssh` command shown in the portal. -3. From a Linux prompt, run `ssh` to connect to the simulated on-premises environment. Use the password that you specified in the `onprem.json` parameter file. - -4. Use the `nc` command to test connectivity to the jumpbox VMs in each spoke: +3. From a Linux prompt, run `ssh` to connect to the simulated on-premises environment. Use the password that you specified in the `hub-spoke.json` parameter file. - ```bash - nc -vzw 1 10.1.0.68 22 - nc -vzw 1 10.2.0.68 22 - ``` +4. Use the Azure portal to find the VM named `s1jbl-vm1` in the `spoke1-vnet-rg` resource group. -### Add connectivity between spokes +5. Click `Connect` and copy the `ssh` command shown in the portal. -This step is optional. If you want to allow spokes to connect to each other, use [Azure Firewall](/azure/firewall/) to force traffic from spokes to the router when trying to connect to another spoke. To deploy Azure Firewall, along with user-defined routes (UDRs) to allow the two spoke VNets to connect, perform the following steps: +6. In the ssh session created in step 3, run `ssh` to connect to the spoke-1 jumpbox. Use the password that you specified in the `hub-spoke.json` parameter file. -1. Add a subnet for Azure Firewall to the hub virtual network. - - ```bash - az network vnet subnet create -g hub-vnet-rg --vnet-name hub-vnet -n AzureFirewallSubnet --address-prefixes 10.0.0.128/26 - ``` -2. Deploy Azure Firewall: - - ```bash - az group deployment create -g hub-vnet-rg --template-file hub-firewall.json - ``` -3. Run the following command to get the privateIPAddress of the firewall created in step 2: +7. Use the `nc` command to test connectivity to the jumpbox VM in spoke 2: ```bash - az resource show -g hub-vnet-rg -n hub-firewall --resource-type Microsoft.Network/azureFirewalls --query properties.ipConfigurations[0].properties.privateIPAddress + nc -vzw 1 10.2.0.37 22 ``` -4. Edit the hub-firewall-routes.json file and replace all occurrences of `` with the IP Address from the previous command. Save hub-firewall-routes.json and then run the following command. - - ```bash - azbb -s -g hub-vnet-rg -l -p hub-firewall-routes.json --deploy - ``` -5. Run the following command to disable BGP route propagation for the route tables associated with the spoke subnets: - - ```bash - az network route-table update -g hub-vnet-rg -n spoke1-rt --disable-bgp-route-propagation true - az network route-table update -g hub-vnet-rg -n spoke2-rt --disable-bgp-route-propagation true - ``` - -To verify connectivity, perform the following steps: - -1. Log into the VM named `jb-vm1` in the `onprem-jb-rg` resource group. - -1. From this login session, log into the jumpbox VM for spoke-1. The private IP address is 10.1.0.68. -1. Use the `Test-NetConnection` cmdlet (Windows) or `nc` command (Linux) to test connectivity to 10.2.0.68, which is the jumpbox VM for spoke-2. +## Next steps +For a version of this architecture that deploys shared identity and security services, see [Hub-spoke network topology with shared services in Azure](./shared-services.md). diff --git a/docs/reference-architectures/hybrid-networking/shared-services.md b/docs/reference-architectures/hybrid-networking/shared-services.md index 5f139cb0365..9b48349bde5 100644 --- a/docs/reference-architectures/hybrid-networking/shared-services.md +++ b/docs/reference-architectures/hybrid-networking/shared-services.md @@ -2,20 +2,19 @@ title: Implement a hub-spoke network topology titleSuffix: Azure Reference Architectures description: Implement a hub-spoke network topology with shared services in Azure. -author: telmosampaio -ms.date: 10/09/2018 +author: MikeWasson +ms.date: 08/19/2019 ms.topic: reference-architecture ms.service: architecture-center ms.subservice: reference-architecture ms.custom: seodec18, networking --- -# Implement a hub-spoke network topology with shared services in Azure +# Hub-spoke network topology with shared services in Azure -This reference architecture builds on the [hub-spoke][guidance-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, and building a [virtual datacenter], the first services you need to share are identity and security. This reference architecture 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). +This reference architecture builds on the [hub-spoke][guidance-hub-spoke] reference architecture to include shared services in the hub that can be consumed by all spokes. -> [!NOTE] -> This scenario can also be accomplished using [Azure Firewall](/azure/firewall/), a cloud-based network security service. +As a first step toward migrating a datacenter to the cloud, the first services that need to be shared are identity and security. 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. The firewall functionality can also be accomplished using [Azure Firewall](/azure/firewall/), a cloud-based network security service. ![Shared services topology in Azure](./images/shared-services.png) @@ -101,103 +100,25 @@ The template parameter files refer to these names, so if you change them, update ### Deploy the simulated on-premises datacenter using azbb -This step deploys the simulated on-premises datacenter as an Azure VNet. +Follow these steps to deploy the architecture: 1. Navigate to the `hybrid-networking\shared-services-stack\` folder of the GitHub repository. -2. Open the `onprem.json` file. - -3. Search for all instances of `UserName`, `adminUserName`,`Password`, and `adminPassword`. Enter values for the user name and password in the parameters and save the file. - -4. Run the following command: - - ```bash - azbb -s -g onprem-vnet-rg -l -p onprem.json --deploy - ``` - -5. 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. - -### Deploy the hub VNet - -This step deploys the hub VNet and connects it to the simulated on-premises VNet. +1. Open the `shared-services-stack.json` file. -1. Open the `hub-vnet.json` file. +1. 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. -2. Search for `adminPassword` and enter a user name and password in the parameters. +1. Search for all instances of `[replace-with-shared-key]` and enter a value for a shared key. The values must match. -3. Search for all instances of `sharedKey` and enter a value for a shared key. Save the file. +1. Save the file. - ```json - "sharedKey": "abc123", - ``` - -4. Run the following command: +1. Run the following command: ```bash - azbb -s -g hub-vnet-rg -l -p hub-vnet.json --deploy + azbb -s -g onprem-vnet-rg -l -p shared-services-stack.json --deploy ``` -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 can take more than 40 minutes to complete. - -### Deploy AD DS in Azure - -This step deploys AD DS domain controllers in Azure. - -1. Open the `hub-adds.json` file. - -2. Search for all instances of `Password` and `adminPassword`. Enter values for the user name and password in the parameters and save the file. - -3. Run the following command: - - ```bash - azbb -s -g hub-adds-rg -l -p hub-adds.json --deploy - ``` - -This deployment step may take several minutes, because it joins the two VMs to the domain hosted in the simulated on-premises datacenter, and installs AD DS on them. - -### Deploy the spoke VNets - -This step deploys the spoke VNets. - -1. Open the `spoke1.json` file. - -2. Search for `adminPassword` and enter a user name and password in the parameters. - -3. Run the following command: - - ```bash - azbb -s -g spoke1-vnet-rg -l -p spoke1.json --deploy - ``` - -4. Repeat steps 1 and 2 for the file `spoke2.json`. - -5. Run the following command: - - ```bash - azbb -s -g spoke2-vnet-rg -l -p spoke2.json --deploy - ``` - -### Peer the hub VNet to the spoke VNets - -To create a peering connection from the hub VNet to the spoke VNets, run the following command: - -```bash -azbb -s -g hub-vnet-rg -l -p hub-vnet-peering.json --deploy -``` - -### Deploy the NVA - -This step deploys an NVA in the `dmz` subnet. - -1. Open the `hub-nva.json` file. - -2. Search for `adminPassword` and enter a user name and password in the parameters. - -3. Run the following command: - - ```bash - azbb -s -g hub-nva-rg -l -p hub-nva.json --deploy - ``` +1. Wait for the deployment to finish. 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. The VPN gateway creation can take more than 40 minutes to complete. ### Test connectivity @@ -210,14 +131,14 @@ Test connectivity from the simulated on-premises environment to the hub VNet. 3. 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. ```powershell - Test-NetConnection 10.0.0.68 -CommonTCPPort RDP + Test-NetConnection 10.0.0.36 -CommonTCPPort RDP ``` The output should look similar to the following: ```powershell -ComputerName : 10.0.0.68 -RemoteAddress : 10.0.0.68 +ComputerName : 10.0.0.36 +RemoteAddress : 10.0.0.36 RemotePort : 3389 InterfaceAlias : Ethernet 2 SourceAddress : 192.168.1.000 @@ -227,11 +148,11 @@ TcpTestSucceeded : True > [!NOTE] > 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. -Repeat the sames steps to test connectivity to the spoke VNets: +Repeat the same steps to test connectivity to the spoke VNets: ```powershell -Test-NetConnection 10.1.0.68 -CommonTCPPort RDP -Test-NetConnection 10.2.0.68 -CommonTCPPort RDP +Test-NetConnection 10.1.0.36 -CommonTCPPort RDP +Test-NetConnection 10.2.0.36 -CommonTCPPort RDP ``` diff --git a/docs/reference-architectures/n-tier/n-tier-cassandra.md b/docs/reference-architectures/n-tier/n-tier-cassandra.md index 5b72073d436..2848400fe3e 100644 --- a/docs/reference-architectures/n-tier/n-tier-cassandra.md +++ b/docs/reference-architectures/n-tier/n-tier-cassandra.md @@ -3,7 +3,7 @@ title: N-tier application with Apache Cassandra titleSuffix: Azure Reference Architectures description: Run Linux virtual machines for an N-tier architecture with Apache Cassandra in Microsoft Azure. author: MikeWasson -ms.date: 11/12/2018 +ms.date: 08/19/2019 ms.topic: reference-architecture ms.service: architecture-center ms.subservice: reference-architecture @@ -143,6 +143,8 @@ For incoming Internet traffic, the load balancer rules define which traffic can A deployment for this reference architecture is available on [GitHub][github-folder]. +If you specify a region that supports availability zones, the VMs are deployed into availability zones. Otherwise, the VMs are deployed into availability sets. For a list of regions that support availability zones, see [Services support by region](/azure/availability-zones/az-overview#services-support-by-region). + ### Prerequisites [!INCLUDE [ref-arch-prerequisites.md](../../../includes/ref-arch-prerequisites.md)] diff --git a/docs/reference-architectures/n-tier/n-tier-sql-server.md b/docs/reference-architectures/n-tier/n-tier-sql-server.md index f4ebc14c5ad..05235b1a9ac 100644 --- a/docs/reference-architectures/n-tier/n-tier-sql-server.md +++ b/docs/reference-architectures/n-tier/n-tier-sql-server.md @@ -3,7 +3,7 @@ title: Windows N-tier application with SQL Server titleSuffix: Azure Reference Architectures description: Implement a multi-tier architecture on Azure for availability, security, scalability, and manageability. author: MikeWasson -ms.date: 11/12/2018 +ms.date: 08/19/2019 ms.topic: reference-architecture ms.service: architecture-center ms.subservice: reference-architecture @@ -155,7 +155,9 @@ Virtual networks are a traffic isolation boundary in Azure. VMs in one VNet can' ## Deploy the solution -A deployment for this reference architecture is available on [GitHub][github-folder]. The entire deployment can take up to two hours, which includes running the scripts to configure AD DS, the Windows Server failover cluster, and the SQL Server availability group. +A deployment for this reference architecture is available on [GitHub][github-folder]. The entire deployment can take up to an hour, which includes running the scripts to configure AD DS, the Windows Server failover cluster, and the SQL Server availability group. + +If you specify a region that supports availability zones, the VMs are deployed into availability zones. Otherwise, the VMs are deployed into availability sets. For a list of regions that support availability zones, see [Services support by region](/azure/availability-zones/az-overview#services-support-by-region). ### Prerequisites @@ -163,75 +165,38 @@ A deployment for this reference architecture is available on [GitHub][github-fol ### Deployment steps -1. Run the following command to create a resource group. - - ```azurecli - az group create --location --name - ``` - -2. Run the following command to create a Storage account for the Cloud Witness. +1. Navigate to the `virtual-machines\n-tier-windows` folder of the reference architectures GitHub repository. - ```azurecli - az storage account create --location \ - --name \ - --resource-group \ - --sku Standard_LRS - ``` - -3. Navigate to the `virtual-machines\n-tier-windows` folder of the reference architectures GitHub repository. +1. Open the `n-tier-windows.json` file. -4. Open the `n-tier-windows.json` file. +1. In the `n-tier-windows.json` file, search for all instances of `[replace-with-password]` and `[replace-with-safe-mode-password]` and replace them with a strong password. Save the file. -5. Search for all instances of "witnessStorageAccount" and replace the placeholder text with the name of the Storage account from step 2. - - ```json - "witnessStorageAccount": "[replace-with-storageaccountname]", - ``` + > [!NOTE] + > If you change the administrator user name, you must also update the `extensions` blocks in the JSON file. -6. Run the following command to list the account keys for the storage account. +1. Run the following command to deploy the architecture. ```azurecli - az storage account keys list \ - --account-name \ - --resource-group + azbb -s -g -l -p n-tier-windows.json --deploy ``` - The output should look like the following. Copy the value of `key1`. - - ```json - [ - { - "keyName": "key1", - "permissions": "Full", - "value": "..." - }, - { - "keyName": "key2", - "permissions": "Full", - "value": "..." - } - ] - ``` +1. When the deployment is complete, open the Azure portal and navigate to the resource group. Find the storage account that begins with 'sqlcw'. This is the storage account that will be used for the cluster's cloud witness. Navigate into the storage account, select **Access Keys**, and copy the value of `key1`. Also copy the name of the storage account. -7. In the `n-tier-windows.json` file, search for all instances of "witnessStorageAccountKey" and paste in the account key. +1. Open the `n-tier-windows-sqlao.json` file. - ```json - "witnessStorageAccountKey": "[replace-with-storagekey]" - ``` - -8. In the `n-tier-windows.json` file, search for all instances of `[replace-with-password]` and `[replace-with-sql-password]` replace them with a strong password. Save the file. +1. In the `n-tier-windows-sqlao.json` file, search for all instances of `[replace-with-password]` and `[replace-with-sql-password]` and replace them with a strong password. > [!NOTE] > If you change the administrator user name, you must also update the `extensions` blocks in the JSON file. -9. Run the following command to deploy the architecture. +1. In the `n-tier-windows-sqlao.json` file, search for all instances of `[replace-with-storageaccountname]` and `[replace-with-storagekey]` and replace them with the values from step 5. Save the file. + +1. Run the following command to configure SQL Server Always On. ```azurecli - azbb -s -g -l -p n-tier-windows.json --deploy + azbb -s -g -l -p n-tier-windows-sqlao.json --deploy ``` -For more information on deploying this sample reference architecture using Azure Building Blocks, visit the [GitHub repository][git]. - ## Next steps - [Microsoft Learn module: Tour the N-tier architecture style](/learn/modules/n-tier-architecture/)