diff --git a/docs/reference-architectures/n-tier/images/n-tier-sql-server.png b/docs/reference-architectures/n-tier/images/n-tier-sql-server.png index 6bc7ac41a9c..ab91ec62216 100644 Binary files a/docs/reference-architectures/n-tier/images/n-tier-sql-server.png and b/docs/reference-architectures/n-tier/images/n-tier-sql-server.png differ 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 05235b1a9ac..3c97070a30f 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: 08/19/2019 +ms.date: 08/21/2019 ms.topic: reference-architecture ms.service: architecture-center ms.subservice: reference-architecture @@ -11,35 +11,37 @@ ms.subservice: reference-architecture # Windows N-tier application on Azure with SQL Server -This reference architecture shows how to deploy VMs and a virtual network configured for an [N-tier](../../guide/architecture-styles/n-tier.md) application, using SQL Server on Windows for the data tier. [**Deploy this solution**](#deploy-the-solution). +This reference architecture shows how to deploy virtual machines (VMs) and a virtual network configured for an [N-tier](../../guide/architecture-styles/n-tier.md) application, using SQL Server on Windows for the data tier. [**Deploy this solution**](#deploy-the-solution). -![N-tier architecture using Microsoft Azure](./images/n-tier-sql-server.png) +[![N-tier architecture using Microsoft Azure](./images/n-tier-sql-server.png)](./images/n-tier-sql-server.png) *Download a [Visio file][visio-download] of this architecture.* ## Architecture -The architecture has the following components: +The architecture has the following components. -- **Resource group**. [Resource groups][resource-manager-overview] are used to group resources so they can be managed by lifetime, owner, or other criteria. +### General -- **Virtual network (VNet) and subnets**. Every Azure VM is deployed into a VNet that can be segmented into subnets. Create a separate subnet for each tier. +- **Resource group**. [Resource groups][resource-manager-overview] are used to group Azure resources so they can be managed by lifetime, owner, or other criteria. -- **Application gateway**. [Azure Application Gateway](/azure/application-gateway/) is a layer 7 load balancer. In this architecture, it routes HTTP requests to the web front end. Application Gateway also provides a [web application firewall](/azure/application-gateway/waf-overview) (WAF) that protects the application from common exploits and vulnerabilities. +- **Availability zones**. [Availability zones](/azure/availability-zones/az-overview) are physical locations within an Azure region. Each zone consists of one or more datacenters with independent power, cooling, and networking. By placing VMs across zones, the application becomes resilient to failures within a zone. -- **NSGs**. Use [network security groups][nsg] (NSGs) to restrict network traffic within the VNet. For example, in the three-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. +### Networking and load balancing -- **DDoS Protection**. Although the Azure platform provides basic protection against distributed denial of service (DDoS) attacks, we recommend using [DDoS Protection Standard][ddos], which has enhanced DDoS mitigation features. See [Security considerations](#security-considerations). +- **Virtual network and subnets**. Every Azure VM is deployed into a virtual network that can be segmented into subnets. Create a separate subnet for each tier. -- **Virtual machines**. For recommendations on configuring VMs, see [Run a Windows VM on Azure](./windows-vm.md) and [Run a Linux VM on Azure](./linux-vm.md). +- **Application gateway**. [Application Gateway](/azure/application-gateway/) is a layer 7 load balancer. In this architecture, it routes HTTP requests to the web front end. Application Gateway also provides a [web application firewall](/azure/application-gateway/waf-overview) (WAF) that protects the application from common exploits and vulnerabilities. -- **Availability sets**. Create an [availability set][azure-availability-sets] for each tier, and provision at least two VMs in each tier, which makes the VMs eligible for a higher [service level agreement (SLA)][vm-sla]. +- **Load balancers**. Use [Azure Standard Load Balancer][load-balancer] to distribute network traffic from the web tier to the business tier, and from the business tier to SQL Server. -- **Load balancers**. Use [Azure Load Balancer][load-balancer] to distribute network traffic from the web tier to the business tier, and from the business tier to SQL Server. +- **Network security groups** (NSGs). Use [NSGs][nsg] to restrict network traffic within the virtual network. For example, in the three-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. -- **Public IP address**. A public IP address is needed for the application to receive Internet traffic. +- **DDoS Protection**. Although the Azure platform provides basic protection against distributed denial of service (DDoS) attacks, we recommend using [DDoS Protection Standard][ddos], which has enhanced DDoS mitigation features. See [Security considerations](#security-considerations). -- **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. +- **Azure DNS**. [Azure DNS][azure-dns] is a hosting service for DNS domains. It provides name resolution using Microsoft Azure infrastructure. By hosting your domains in Azure, you can manage your DNS records using the same credentials, APIs, tools, and billing as your other Azure services. + +### Virtual machines - **SQL Server Always On Availability Group**. Provides high availability at the data tier, by enabling replication and failover. It uses Windows Server Failover Cluster (WSFC) technology for failover. @@ -47,19 +49,27 @@ The architecture has the following components: - **Cloud Witness**. A failover cluster requires more than half of its nodes to be running, which is known as having quorum. If the cluster has just two nodes, a network partition could cause each node to think it's the master node. In that case, you need a *witness* to break ties and establish quorum. A witness is a resource such as a shared disk that can act as a tie breaker to establish quorum. Cloud Witness is a type of witness that uses Azure Blob Storage. To learn more about the concept of quorum, see [Understanding cluster and pool quorum](/windows-server/storage/storage-spaces/understand-quorum). For more information about Cloud Witness, see [Deploy a Cloud Witness for a Failover Cluster](/windows-server/failover-clustering/deploy-cloud-witness). -- **Azure DNS**. [Azure DNS][azure-dns] is a hosting service for DNS domains. It provides name resolution using Microsoft Azure infrastructure. By hosting your domains in Azure, you can manage your DNS records using the same credentials, APIs, tools, and billing as your other Azure services. +- **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. ## Recommendations Your requirements might differ from the architecture described here. Use these recommendations as a starting point. -### VNet / Subnets +### Virtual machines + +For recommendations on configuring the VMs, see [Run a Windows VM on Azure](./windows-vm.md). + +### Virtual network -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][private-ip-space], which are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. +When you create the virtual network, determine how many IP addresses your resources in each subnet require. Specify a subnet mask and a network 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][private-ip-space], 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-premises network later. Once you create the VNet, you can't change the address range. +Choose an address range that does not overlap with your on-premises network, in case you need to set up a gateway between the virtual network and your on-premises network later. Once you create the virtual network, 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][plan-network]. +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 virtual networks and subnets, see [Plan and design Azure Virtual Networks][plan-network]. + +### Application Gateway + +For information about configuring Application Gateway, see [Application Gateway configuration overview](/azure/application-gateway/configuration-overview). ### Load balancers @@ -69,9 +79,9 @@ Define load balancer rules to direct network traffic to the VMs. For example, to ### Network security groups -Use NSG rules to restrict traffic between tiers. In the three-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. +Use NSG rules to restrict traffic between tiers. In the three-tier architecture shown above, the web tier does not communicate directly with the database tier. To enforce this rule, the database tier should block incoming traffic from the web tier subnet. -1. Deny all inbound traffic from the VNet. (Use the `VIRTUAL_NETWORK` tag in the rule.) +1. Deny all inbound traffic from the virtual network. (Use the `VIRTUAL_NETWORK` tag in the rule.) 2. Allow inbound traffic from the business tier subnet. 3. Allow inbound traffic from the database tier subnet itself. This rule allows communication between the database VMs, which is needed for database replication and failover. 4. Allow RDP traffic (port 3389) from the jumpbox subnet. This rule lets administrators connect to the database tier from the jumpbox. @@ -105,15 +115,17 @@ Test your deployment by [forcing a manual failover][sql-alwayson-force-failover] ### Jumpbox -Don't 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. +Don't allow RDP access from the public Internet to the VMs that run the application workload. Instead, all RDP access to these VMs should go 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. -The jumpbox has minimal performance requirements, so select a small VM size. 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. +The jumpbox has minimal performance requirements, so select a small VM size. Create a [public IP address] for the jumpbox. Place the jumpbox in the same virtual network as the other VMs, but in a separate management subnet. To secure the jumpbox, add an NSG rule that allows RDP connections only from a safe set of public IP addresses. Configure the NSGs for the other subnets to allow RDP traffic from the management subnet. ## Scalability considerations -For the web and business tiers, consider using [virtual machine scale sets][vmss], instead of deploying separate VMs into an availability set. A scale set makes it easy to deploy and manage a set of identical VMs, and autoscale the VMs based on performance metrics. As the load on the VMs increases, additional VMs are automatically added to the load balancer. Consider scale sets if you need to quickly scale out VMs, or need to autoscale. +### Scale sets + +For the web and business tiers, consider using [virtual machine scale sets][vmss] instead of deploying separate VMs. A scale set makes it easy to deploy and manage a set of identical VMs, and autoscale the VMs based on performance metrics. As the load on the VMs increases, additional VMs are automatically added to the load balancer. Consider scale sets if you need to quickly scale out VMs, or need to autoscale. There are two basic ways to configure VMs deployed in a scale set: @@ -126,26 +138,58 @@ For more information, see [Design considerations for scale sets][vmss-design]. > [!TIP] > When using any autoscale solution, test it with production-level workloads well in advance. +### Subscription limits + Each Azure subscription has default limits in place, including a maximum number of VMs per region. You can increase the limit by filing a support request. For more information, see [Azure subscription and service limits, quotas, and constraints][subscription-limits]. +### Application Gateway + +Application Gateway supports fixed capacity mode or autoscaling mode. Fixed capacity mode is useful for scenarios with consistent and predictable workloads. Consider using autoscaling mode for workloads with variable traffic. For more information, see [Autoscaling and Zone-redundant Application Gateway v2][app-gw-scaling] + ## Availability considerations -If you don't use virtual machine scale sets, put VMs for the same tier into an availability set. Create at least two VMs in the availability set to support the [availability SLA for Azure VMs][vm-sla]. For more information, see [Manage the availability of virtual machines][availability-set]. Scale sets automatically use *placement groups*, which act as an implicit availability set. +Availability zones provide the best resiliency within a single region. If you need even higher availability, consider replicating the application across two regions, using Azure Traffic Manager for failover. For more information, see [Multi-region N-tier application for high availability][multi-dc]. + +Not all regions support availability zones, and not all VM sizes are supported in all zones. Run the following Azure CLI command to find the supported zones for each VM size within a region: + +```bash +az vm list-skus --resource-type virtualMachines --zone false --location \ + --query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table +``` + +If you deploy this architecture to a region that does not support availability zones, put the VMs for each tier inside an *availability set*. VMs within the same availability are deployed across multiple physical servers, compute racks, storage units, and network switches for redundancy. Scale sets automatically use *placement groups*, which act as an implicit availability set. + +When deploying to availability zones, use the Standard SKU of Azure Load Balancer and the v2 SKU of Application Gateway. These SKUs support cross-zone redundancy. For more information, see: + +- [Standard Load Balancer and Availability Zones](/azure/load-balancer/load-balancer-standard-availability-zones) +- [Autoscaling and Zone-redundant Application Gateway v2][app-gw-scaling] +- [How does Application Gateway support high availability and scalability?](/azure/application-gateway/application-gateway-faq#how-does-application-gateway-support-high-availability-and-scalability) + +A single Application Gateway deployment can run multiple instances of the gateway. For production workloads, run at least two instances. + +### Health probes + +Application Gateway and Load Balancer both use health probes to monitor the availability of VM instances. -The load balancer uses [health probes][health-probes] to monitor the availability of VM instances. If a probe can't reach an instance within a timeout period, the load balancer stops sending traffic to that VM. However, the load balancer will continue to probe, and if the VM becomes available again, the load balancer resumes sending traffic to that VM. +- Application Gateway always uses an HTTP probe. +- Load Balancer can test either HTTP or TCP. Generally, if a VM runs an HTTP server, use an HTTP probe. Otherwise, use TCP. -Here are some recommendations on load balancer health probes: +If a probe can't reach an instance within a timeout period, the gateway or load balancer stops sending traffic to that VM. The probe continues to check and will return the VM to the back-end pool if the VM becomes available again. -- Probes can test either HTTP or TCP. If your VMs run an HTTP server, create an HTTP probe. Otherwise create a TCP probe. -- For an HTTP probe, specify the path to an HTTP endpoint. The probe checks for an HTTP 200 response from this path. This path can be the root path ("/"), or a health-monitoring endpoint that implements some custom logic to check the health of the application. The endpoint must allow anonymous HTTP requests. -- The probe is sent from a [known IP address][health-probe-ip], 168.63.129.16. Don't block traffic to or from this IP address in any firewall policies or NSG rules. -- Use [health probe logs][health-probe-log] to view the status of the health probes. Enable logging in the Azure portal for each load balancer. Logs are written to Azure Blob storage. The logs show how many VMs aren't getting network traffic because of failed probe responses. +HTTP probes send an HTTP GET request to a specified path and listen for an HTTP 200 response. This path can be the root path ("/"), or a health-monitoring endpoint that implements some custom logic to check the health of the application. The endpoint must allow anonymous HTTP requests. -If you need higher availability than the [Azure SLA for VMs][vm-sla] provides, consider replication the application across two regions, using Azure Traffic Manager for failover. For more information, see [Multi-region N-tier application for high availability][multi-dc]. +For more information about health probes, see: + +- [Load Balancer health probes](/azure/load-balancer/load-balancer-custom-probe-overview) +- [Application Gateway health monitoring overview](/azure/application-gateway/application-gateway-probe-overview) + +For considerations about designing a health probe endpoint, see [Health Endpoint Monitoring pattern](../../patterns/health-endpoint-monitoring.md). ## Security considerations -Virtual networks are a traffic isolation boundary in Azure. VMs in one VNet can't communicate directly with VMs in a different VNet. VMs within the same VNet can communicate, unless you create [network security groups][nsg] (NSGs) to restrict traffic. For more information, see [Microsoft cloud services and network security][network-security]. +Virtual networks are a traffic isolation boundary in Azure. By default, VMs in one virtual network can't communicate directly with VMs in a different virtual network. However, you can explicitly connect virtual networks by using [virtual network peering](/virtual-network/virtual-network-peering-overview). + +**NSGs**. Use [network security groups][nsg] (NSGs) to restrict traffic to and from the internet. For more information, see [Microsoft cloud services and network security][network-security]. **DMZ**. 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][dmz]. @@ -202,41 +246,33 @@ If you specify a region that supports availability zones, the VMs are deployed i - [Microsoft Learn module: Tour the N-tier architecture style](/learn/modules/n-tier-architecture/) -[dmz]: ../dmz/secure-vnet-dmz.md -[multi-dc]: multi-region-sql-server.md -[n-tier]: n-tier.md -[azure-availability-sets]: /azure/virtual-machines/virtual-machines-windows-manage-availability#configure-each-application-tier-into-separate-availability-sets +[app-gw-scaling]: /azure/application-gateway/application-gateway-autoscaling-zone-redundant [azure-dns]: /azure/dns/dns-overview [azure-key-vault]: https://azure.microsoft.com/services/key-vault [bastion host]: https://en.wikipedia.org/wiki/Bastion_host [cidr]: https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing -[ddos]: /azure/virtual-network/ddos-protection-overview [ddos-best-practices]: /azure/security/azure-ddos-best-practices -[git]: https://github.com/mspnp/template-building-blocks +[ddos]: /azure/virtual-network/ddos-protection-overview +[dmz]: ../dmz/secure-vnet-dmz.md [github-folder]: https://github.com/mspnp/reference-architectures/tree/master/virtual-machines/n-tier-windows +[load-balancer-hashing]: /azure/load-balancer/load-balancer-overview#fundamental-load-balancer-features +[load-balancer]: /azure/load-balancer/load-balancer-standard-overview +[multi-dc]: multi-region-sql-server.md +[n-tier]: n-tier.md +[network-security]: /azure/best-practices-network-security [nsg]: /azure/virtual-network/virtual-networks-nsg [plan-network]: /azure/virtual-network/virtual-network-vnet-plan-design-arm [private-ip-space]: https://en.wikipedia.org/wiki/Private_network#Private_IPv4_address_spaces [public IP address]: /azure/virtual-network/virtual-network-ip-addresses-overview-arm -[sql-alwayson]: https://msdn.microsoft.com/library/hh510230.aspx +[resource-manager-overview]: /azure/azure-resource-manager/resource-group-overview [sql-alwayson-force-failover]: https://msdn.microsoft.com/library/ff877957.aspx [sql-alwayson-getting-started]: https://msdn.microsoft.com/library/gg509118.aspx [sql-alwayson-ilb]: /azure/virtual-machines/windows/sql/virtual-machines-windows-portal-sql-alwayson-int-listener [sql-alwayson-listeners]: https://msdn.microsoft.com/library/hh213417.aspx [sql-alwayson-read-only-routing]: https://technet.microsoft.com/library/hh213417.aspx#ConnectToSecondary +[sql-alwayson]: https://msdn.microsoft.com/library/hh510230.aspx [sql-keyvault]: /azure/virtual-machines/virtual-machines-windows-ps-sql-keyvault -[vm-sla]: https://azure.microsoft.com/support/legal/sla/virtual-machines -[vnet faq]: /azure/virtual-network/virtual-networks-faq -[wsfc-whats-new]: https://technet.microsoft.com/windows-server-docs/failover-clustering/whats-new-in-failover-clustering +[subscription-limits]: /azure/azure-subscription-service-limits [visio-download]: https://archcenter.blob.core.windows.net/cdn/vm-reference-architectures.vsdx -[resource-manager-overview]: /azure/azure-resource-manager/resource-group-overview -[vmss]: /azure/virtual-machine-scale-sets/virtual-machine-scale-sets-overview -[load-balancer]: /azure/load-balancer/ -[load-balancer-hashing]: /azure/load-balancer/load-balancer-overview#fundamental-load-balancer-features [vmss-design]: /azure/virtual-machine-scale-sets/virtual-machine-scale-sets-design-overview -[subscription-limits]: /azure/azure-subscription-service-limits -[availability-set]: /azure/virtual-machines/virtual-machines-windows-manage-availability -[health-probes]: /azure/load-balancer/load-balancer-overview#fundamental-load-balancer-features -[health-probe-log]: /azure/load-balancer/load-balancer-monitor-log -[health-probe-ip]: /azure/virtual-network/security-overview#augmented-security-rules -[network-security]: /azure/best-practices-network-security +[vmss]: /azure/virtual-machine-scale-sets/virtual-machine-scale-sets-overview