Run Windows VMs for an N-tier application

This reference architecture shows a set of proven practices for running Windows virtual machines (VMs) for an N-tier application. Deploy this solution.

[0]

Architecture

There are many ways to implement an N-tier architecture. The diagram shows a typical 3-tier web application. This architecture builds on Run load-balanced VMs for scalability and availability. The web and business tiers use load-balanced VMs.

  • Availability sets. Create an availability set for each tier, and provision at least two VMs in each tier. This makes the VMs eligible for a higher service level agreement (SLA) for VMs.
  • Subnets. Create a separate subnet for each tier. Specify the address range and subnet mask using CIDR notation.
  • Load balancers. Use an Internet-facing load balancer to distribute incoming Internet traffic to the web tier, and an internal load balancer to distribute network traffic from the web tier to the business tier.
  • Jumpbox. Also called a bastion host. A secure VM on the network that administrators use to connect to the other VMs. The jumpbox has an NSG that allows remote traffic only from public IP addresses on a safe list. The NSG should permit remote desktop (RDP) traffic.
  • Monitoring. Monitoring software such as Nagios, Zabbix, or Icinga can give you insight into response time, VM uptime, and the overall health of your system. Install the monitoring software on a VM that's placed in a separate management subnet.
  • NSGs. Use network security groups (NSGs) to restrict network traffic within the VNet. For example, in the 3-tier architecture shown here, the database tier does not accept traffic from the web front end, only from the business tier and the management subnet.
  • SQL Server Always On Availability Group. Provides high availability at the data tier, by enabling replication and failover.
  • Active Directory Domain Services (AD DS) Servers. Prior to Windows Server 2016, SQL Server Always On Availability Groups must be joined to a domain. This is because Availability Groups depend on Windows Server Failover Cluster (WSFC) technology. Windows Server 2016 introduces the ability to create a Failover Cluster without Active Directory, in which case the AD DS servers are not required for this architecture. For more information, see What's new in Failover Clustering in Windows Server 2016.

You can download a Visio file of this architecture.

Note

Azure has two different deployment models: Resource Manager and classic. This article uses Resource Manager, which Microsoft recommends for new deployments.

Recommendations

Your requirements might differ from the architecture described here. Use these recommendations as a starting point.

VNet / Subnets

When you create the VNet, determine how many IP addresses your resources in each subnet require. Specify a subnet mask and a VNet address range large enough for the required IP addresses, using CIDR notation. Use an address space that falls within the standard private IP address blocks, which are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.

Choose an address range that does not overlap with your on-premises network, in case you need to set up a gateway between the VNet and your on-premise network later. Once you create the VNet, you can't change the address range.

Design subnets with functionality and security requirements in mind. All VMs within the same tier or role should go into the same subnet, which can be a security boundary. For more information about designing VNets and subnets, see Plan and design Azure Virtual Networks.

For each subnet, specify the address space for the subnet in CIDR notation. For example, '10.0.0.0/24' creates a range of 256 IP addresses. VMs can use 251 of these; five are reserved. Make sure the address ranges don't overlap across subnets. See the Virtual Network FAQ.

Network security groups

Use NSG rules to restrict traffic between tiers. For example, in the 3-tier architecture shown above, the web tier does not communicate directly with the database tier. To enforce this, the database tier should block incoming traffic from the web tier subnet.

  1. Create an NSG and associate it to the database tier subnet.
  2. Add a rule that denies all inbound traffic from the VNet. (Use the VIRTUAL_NETWORK tag in the rule.)
  3. Add a rule with a higher priority that allows inbound traffic from the business tier subnet. This rule overrides the previous rule, and allows the business tier to talk to the database tier.
  4. Add a rule that allows inbound traffic from within the database tier subnet itself. This rule allows communication between VMs in the database tier, which is needed for database replication and failover.
  5. Add a rule that allows RDP traffic from the jumpbox subnet. This rule lets administrators connect to the database tier from the jumpbox.

    Note

    An NSG has default rules that allow any inbound traffic from within the VNet. These rules can't be deleted, but you can override them by creating higher priority rules.

Load balancers

The external load balancer distributes Internet traffic to the web tier. Create a public IP address for this load balancer. See Creating an Internet-facing load balancer.

The internal load balancer distributes network traffic from the web tier to the business tier. To give this load balancer a private IP address, create a frontend IP configuration and associate it with the subnet for the business tier. See Get started creating an Internal load balancer.

SQL Server Always On Availability Groups

We recommend Always On Availability Groups for SQL Server high availability. Prior to Windows Server 2016, Always On Availability Groups require a domain controller, and all nodes in the availability group must be in the same AD domain.

Other tiers connect to the database through an availability group listener. The listener enables a SQL client to connect without knowing the name of the physical instance of SQL Server. VMs that access the database must be joined to the domain. The client (in this case, another tier) uses DNS to resolve the listener's virtual network name into IP addresses.

Configure the SQL Server Always On Availability Group as follows:

  1. Create a Windows Server Failover Clustering (WSFC) cluster, a SQL Server Always On Availability Group, and a primary replica. For more information, see Getting Started with Always On Availability Groups.
  2. Create an internal load balancer with a static private IP address.
  3. Create an availability group listener, and map the listener's DNS name to the IP address of an internal load balancer.
  4. Create a load balancer rule for the SQL Server listening port (TCP port 1433 by default). The load balancer rule must enable floating IP, also called Direct Server Return. This causes the VM to reply directly to the client, which enables a direct connection to the primary replica.

    Note

    When floating IP is enabled, the front-end port number must be the same as the back-end port number in the load balancer rule.

When a SQL client tries to connect, the load balancer routes the connection request to the primary replica. If there is a failover to another replica, the load balancer automatically routes subsequent requests to a new primary replica. For more information, see Configure an ILB listener for SQL Server Always On Availability Groups.

During a failover, existing client connections are closed. After the failover completes, new connections will be routed to the new primary replica.

If your application makes significantly more reads than writes, you can offload some of the read-only queries to a secondary replica. See Using a Listener to Connect to a Read-Only Secondary Replica (Read-Only Routing).

Test your deployment by forcing a manual failover of the availability group.

Jumpbox

The jumpbox will have minimal performance requirements, so select a small VM size for the jumpbox such as Standard A1.

Create a public IP address for the jumpbox. Place the jumpbox in the same VNet as the other VMs, but in a separate management subnet.

Do not allow RDP access from the public Internet to the VMs that run the application workload. Instead, all RDP access to these VMs must come through the jumpbox. An administrator logs into the jumpbox, and then logs into the other VM from the jumpbox. The jumpbox allows RDP traffic from the Internet, but only from known, safe IP addresses.

To secure the jumpbox, create an NSG and apply it to the jumpbox subnet. Add an NSG rule that allows RDP connections only from a safe set of public IP addresses. The NSG can be attached either to the subnet or to the jumpbox NIC. In this case, we recommend attaching it to the NIC, so RDP traffic is permitted only to the jumpbox, even if you add other VMs to the same subnet.

Configure the NSGs for the other subnets to allow RDP traffic from the management subnet.

Availability considerations

At the database tier, having multiple VMs does not automatically translate into a highly available database. For a relational database, you will typically need to use replication and failover to achieve high availability. For SQL Server, we recommend using Always On Availability Groups.

If you need higher availability than the Azure SLA for VMs provides, replicate the application across two regions and use Azure Traffic Manager for failover. For more information, see Run Windows VMs in multiple regions for high availability.

Security considerations

Encrypt sensitive data at rest and use Azure Key Vault to manage the database encryption keys. Key Vault can store encryption keys in hardware security modules (HSMs). For more information, see Configure Azure Key Vault Integration for SQL Server on Azure VMs It's also recommended to store application secrets, such as database connection strings, in Key Vault.

Consider adding a network virtual appliance (NVA) to create a DMZ between the Internet and the Azure virtual network. NVA is a generic term for a virtual appliance that can perform network-related tasks, such as firewall, packet inspection, auditing, and custom routing. For more information, see Implementing a DMZ between Azure and the Internet.

Scalability considerations

The load balancers distribute network traffic to the web and business tiers. Scale horizontally by adding new VM instances. Note that you can scale the web and business tiers independently, based on load. To reduce possible complications caused by the need to maintain client affinity, the VMs in the web tier should be stateless. The VMs hosting the business logic should also be stateless.

Manageability considerations

Simplify management of the entire system by using centralized administration tools such as Azure Automation, Microsoft Operations Management Suite, Chef, or Puppet. These tools can consolidate diagnostic and health information captured from multiple VMs to provide an overall view of the system.

Deploy the solution

A deployment for this architecture is available on GitHub. The architecture is deployed in three stages. To deploy the architecture, follow these steps:

  1. Click the button below to begin the first stage of deployment:
  2. Once the link has opened in the Azure portal, enter the follow values:
    • The Resource group name is already defined in the parameter file, so select Create New and enter ra-ntier-sql-network-rg in the text box.
    • Select the region from the Location drop down box.
    • Do not edit the Template Root Uri or the Parameter Root Uri text boxes.
    • Review the terms and conditions, then click the I agree to the terms and conditions stated above checkbox.
    • Click on the Purchase button.
  3. Check Azure portal notification for a message that the first stage of the deployment is complete.
  4. Click the button below to begin the second stage of the deployment:
  5. Once the link has opened in the Azure portal, enter the follow values:
    • The Resource group name is already defined in the parameter file, so select Create New and enter ra-ntier-sql-workload-rg in the text box.
    • Select the region from the Location drop down box.
    • Do not edit the Template Root Uri or the Parameter Root Uri text boxes.
    • Review the terms and conditions, then click the I agree to the terms and conditions stated above checkbox.
    • Click on the Purchase button.
  6. Check Azure portal notification for a message that the second stage of deployment is complete.
  7. Click the button below to begin the third stage of the deployment:
  8. Once the link has opened in the Azure portal, enter the follow values:
    • The Resource group name is already defined in the parameter file, so select Use Existing and enter ra-ntier-sql-network-rg in the text box.
    • Select the region from the Location drop down box.
    • Do not edit the Template Root Uri or the Parameter Root Uri text boxes.
    • Review the terms and conditions, then click the I agree to the terms and conditions stated above checkbox.
    • Click on the Purchase button.
  9. Check Azure portal notification for a message that the third stage of the deployment is complete.
  10. The parameter files include a hard-coded administrator user names and passwords, and it is strongly recommended that you immediately change both on all the VMs. Click on each VM in the Azure portal then click on Reset password in the Support + troubleshooting blade. Select Reset password in the Mode dropdown box, then select a new User name and Password. Click the Update button to save the new user name and password.