diff --git a/docs/guide/images/load-balancing-choices.png b/docs/guide/images/load-balancing-choices.png deleted file mode 100644 index 24780e73ed5..00000000000 Binary files a/docs/guide/images/load-balancing-choices.png and /dev/null differ diff --git a/docs/guide/images/load-balancing-decision-tree.png b/docs/guide/images/load-balancing-decision-tree.png deleted file mode 100644 index 8f5070a8231..00000000000 Binary files a/docs/guide/images/load-balancing-decision-tree.png and /dev/null differ diff --git a/docs/guide/index.md b/docs/guide/index.md index 36a48627bda..d988dcf16f8 100644 --- a/docs/guide/index.md +++ b/docs/guide/index.md @@ -32,7 +32,7 @@ Relational database
Strong consistency
Serial and synchronized processing
Design to avoid failures (MTBF)
-Occasional large updates
+Occasional big updates
Manual management
Snowflake servers @@ -67,18 +67,16 @@ Learn more: ### Technology choices -Two technology choices should be decided early on, because they affect the entire architecture. These are the choice of compute service and data stores. *Compute* refers to the hosting model for the computing resources that your applications run on. *Data stores include databases but also storage for message queues, caches, logs, and anything else that an application might persist to storage. +Two technology choices should be decided early on, because they affect the entire architecture. These are the choice of compute service and data stores. *Compute* refers to the hosting model for the computing resources that your applications runs on. *Data stores* includes databases but also storage for message queues, caches, logs, and anything else that an application might persist to storage. Learn more: - [Choosing a compute service](./technology-choices/compute-overview.md) - [Choosing a data store](./technology-choices/data-store-overview.md) -While it depends on your application's requirements, there is a high likelihood that you will also need to choose the right load-balancing services for your application early on in the architectural discussions. *Load balancing* defines how the traffic for your application will be distributed to your compute service. Learn more at [Choosing a load balancing service](./technology-choices/load-balancing-overview.md) - ### Design principles -We have identified ten high-level design principles that will make your application more scalable, resilient, and manageable. These design principles apply to any architecture styles. Throughout the design process, keep these ten high-level design principles in mind. Then consider the set of best practices for specific aspects of the architecture, such as autoscaling, caching, data partitioning, API design, and others. +We have identified ten high-level design principles that will make your application more scalable, resilient, and manageable. These design principles apply to any architecture styles. Throughout the design process, keep these ten high-level design principles in mind. Then consider the set of best practices for specific aspects of the architecture, such as auto-scaling, caching, data partitioning, API design, and others. Learn more: diff --git a/docs/guide/technology-choices/compute-comparison.md b/docs/guide/technology-choices/compute-comparison.md index bfd897e5f0a..8ff1cd0bc99 100644 --- a/docs/guide/technology-choices/compute-comparison.md +++ b/docs/guide/technology-choices/compute-comparison.md @@ -12,7 +12,7 @@ ms.custom: seojan19 # Criteria for choosing an Azure compute service -The term *compute* refers to the hosting model for the computing resources that your applications run on. The following tables compare Azure compute services across several axes. Refer to these tables when selecting a compute option for your application. +The term *compute* refers to the hosting model for the computing resources that your applications runs on. The following tables compare Azure compute services across several axes. Refer to these tables when selecting a compute option for your application. ## Hosting model @@ -43,7 +43,7 @@ Notes | Criteria | Virtual Machines | App Service | Service Fabric | Azure Functions | Azure Kubernetes Service | Container Instances | Azure Batch | |----------|-----------------|-------------|----------------|-----------------|-------------------------|----------------|-------------| | Local debugging | Agnostic | IIS Express, others 1 | Local node cluster | Visual Studio or Azure Functions CLI | Minikube, others | Local container runtime | Not supported | -| Programming model | Agnostic | Web and API applications, WebJobs for background tasks | Guest executable, Service model, Actor model, Containers | Functions with triggers | Agnostic | Agnostic | Command-line application | +| Programming model | Agnostic | Web and API applications, WebJobs for background tasks | Guest executable, Service model, Actor model, Containers | Functions with triggers | Agnostic | Agnostic | Command line application | | Application update | No built-in support | Deployment slots | Rolling upgrade (per service) | Deployment slots | Rolling update | Not applicable | Notes @@ -57,7 +57,7 @@ Notes |----------|-----------------|-------------|----------------|-----------------|-------------------------|----------------|-------------| | Autoscaling | Virtual machine scale sets | Built-in service | Virtual machine scale sets | Built-in service | Not supported | Not supported | N/A | | Load balancer | Azure Load Balancer | Integrated | Azure Load Balancer | Integrated | Integrated | No built-in support | Azure Load Balancer | -| Scale limit1 | Platform image: 1000 nodes per virtual machine scale set, Custom image: 100 nodes per virtual machine scale set | 20 instances, 100 with App Service Environment | 100 nodes per virtual machine scale set | 200 instances per Function app | 100 nodes per cluster (default limit) |20 container groups per subscription (default limit). | 20 core limit (default limit). | +| Scale limit1 | Platform image: 1000 nodes per VMSS, Custom image: 100 nodes per VMSS | 20 instances, 100 with App Service Environment | 100 nodes per VMSS | 200 instances per Function app | 100 nodes per cluster (default limit) |20 container groups per subscription (default limit). | 20 core limit (default limit). | Notes @@ -68,7 +68,7 @@ Notes | Criteria | Virtual Machines | App Service | Service Fabric | Azure Functions | Azure Kubernetes Service | Container Instances | Azure Batch | |----------|-----------------|-------------|----------------|-----------------|-------------------------|----------------|-------------| | SLA | [SLA for Virtual Machines][sla-vm] | [SLA for App Service][sla-app-service] | [SLA for Service Fabric][sla-sf] | [SLA for Functions][sla-functions] | [SLA for AKS][sla-acs] | [SLA for Container Instances](https://azure.microsoft.com/support/legal/sla/container-instances/) | [SLA for Azure Batch][sla-batch] | -| Multi region failover | Azure Front Door (HTTP/HTTPS)
Traffic manager (Other) | Azure Front Door | Azure Front Door (HTTP/HTTPS)
Traffic manager (Other), Multi-Region Cluster | Azure Front Door | Azure Front Door (HTTP/HTTPS)
Traffic manager (Other) | Not supported | Not Supported | +| Multi region failover | Traffic manager | Traffic manager | Traffic manager, Multi-Region Cluster | Not supported | Traffic manager | Not supported | Not Supported | For guided learning on Service Guarantees, review [Core Cloud Services - Azure architecture and service guarantees](/learn/modules/explore-azure-infrastructure). diff --git a/docs/guide/technology-choices/load-balancing-decision-tree.md b/docs/guide/technology-choices/load-balancing-decision-tree.md deleted file mode 100644 index 755c70331b5..00000000000 --- a/docs/guide/technology-choices/load-balancing-decision-tree.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: Decision tree for load balancing in Azure -titleSuffix: Azure Application Architecture Guide -description: A flowchart for selecting load-balancing services in Azure. -author: sharadag -ms.date: 05/25/2019 -ms.topic: guide -ms.service: architecture-center -ms.subservice: reference-architecture -ms.custom: sharad4u ---- - -# Decision tree for load balancing in Azure - -Azure provides you with a variety of different load-balancing solutions that you can leverage to distribute traffic between your different application endpoints. This distribution of traffic could be across your virtual machines, containers, Kubernetes clusters, App Services, in-region within a virtual network or across different Azure regions. The following flowchart will help you to choose a load-balancing solution for your application. The flowchart guides you through a set of key decision criteria to reach a recommendation. - -**Treat this flowchart as a starting point.** Every application has unique requirements, so use the recommendation as a starting point. Then perform a more detailed evaluation, looking at aspects such as: - -- Feature set -- [Service limits](/azure/azure-subscription-service-limits) -- [Cost](https://azure.microsoft.com/pricing/) -- [SLA](https://azure.microsoft.com/support/legal/sla/) -- [Regional availability](https://azure.microsoft.com/global-infrastructure/services/) - -If your application consists of multiple workloads, evaluate each workload separately. A complete solution may incorporate two or more load-balancing solutions. - -## Flowchart - -![Decision tree for load balancing in Azure](../images/load-balancing-decision-tree.png) - -## Definitions - -- **"Internet facing"** applications are the ones that are publicly accessible from the internet. This is an application architecture choice that is common for consumer as well as business applications. As a best practice, application owners apply restrictive access policies or protect the application by setting up offerings like web application firewall and DDoS protection. - -- **PaaS** Platform as a service (PaaS) is a complete development and deployment environment in the cloud, with resources that enable you to deliver everything from simple cloud-based apps to sophisticated, cloud-enabled enterprise applications. PaaS is designed to support the complete web application lifecycle: building, testing, deploying, managing, and updating. PaaS allows you to avoid the expense and complexity of buying and managing software licenses, the underlying application infrastructure and middleware or the development tools and other resources. You manage the applications and services you develop, and the cloud service provider typically manages everything else. - -- **IaaS** Infrastructure as a service (IaaS) is an instant computing infrastructure, provisioned and managed over the internet. IaaS quickly scales up and down with demand, letting you pay only for what you use. It helps you avoid the expense and complexity of buying and managing your own physical servers and other datacenter infrastructure. Azure, manages the infrastructure, while you purchase, install, configure, and manage your own software—operating systems, middleware, and applications. - - -## Next steps - -For additional context on these different load-balancing services, see [Overview of load balancing options in Azure](./load-balancing-overview.md). diff --git a/docs/guide/technology-choices/load-balancing-overview.md b/docs/guide/technology-choices/load-balancing-overview.md deleted file mode 100644 index 2259c5ea4d4..00000000000 --- a/docs/guide/technology-choices/load-balancing-overview.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: Overview of Azure load-balancing options -titleSuffix: Azure Application Architecture Guide -description: An overview of Azure load-balancing options. -author: sharad4u -ms.date: 08/03/2019 -ms.topic: guide -ms.service: architecture-center -ms.subservice: reference-architecture -ms.custom: seojan19 ---- - -# Overview of load-balancing options in Azure - -The term *load balancing* refers to the distribution of workloads across multiple computing resources that your application runs on. Load balancing aims to optimize resource use, maximize throughput, minimize response time, and avoid overload of any single resource. - -## Overview - -Azure provides multiple global and regional services for managing how your application's traffic is distributed and load balanced: **Traffic Manager**, **Azure Front Door**, **Application Gateway**, and **Azure Load Balancer**. Along with Azure’s many regions and zonal architecture, using these services together enable you to build robust, scalable high-performance applications. - -![Load-balancing choices in Azure](../images/load-balancing-choices.png) - -These services are broken into two categories: - -- **Global load-balancing services** such as Traffic Manager and Front Door distribute traffic from your end users across your regional backends, across clouds or even your hybrid on-premises services. Global load balancing routes your traffic to your closest service backend and reacts to changes in service reliability or performance to maintain always-on, maximal performance for your users. You can think of global load-balancing services as systems that load balance between your application stamps or endpoints or scale-units hosted across different regions/geographies. - -- **Regional load-balancing services** such as Standard Load Balancer or Application Gateway provide the ability to distribute traffic within virtual networks (VNETs) across your virtual machines (VMs) or zonal and zone-redundant service endpoints within a region. You can think of regional load balancers as systems that load balance between your virtual machines or containers or clusters within a region in a virtual network. - -Correspondingly, there is another way of pivoting these different load balancers based on the application workload type that they can handle: - -- **HTTP/HTTPS load-balancing services** such as Front Door and Application Gateway are load balancers for web applications, that is, can only cater to HTTP/HTTPS traffic. Front Door and Application Gateway offer key layer 7 benefits like SSL offload, web application firewall, path-based load balancing, session affinity and so on. - -- **Non-HTTP/S load-balancing services** such as Traffic Manager and Load Balancer that are recommended for non-web workloads, that is, non-HTTP/HTTPS traffic. Traffic Manager is a DNS-based load-balancing service and so is limited to load balancing only at domain level. Also, being at the DNS level, Traffic Manager cannot perform as fast fail-over as Front Door because of common challenges around DNS caching and systems not honoring DNS TTLs. Azure Load Balancer operates for TCP and UDP traffic and offers in-region load balancing with low latency and high throughput for TCP/UDP workloads. - -Combining global and regional services in your application provides an end-to-end reliable, performant, and secure way to route traffic to and from your users to your IaaS, PaaS, or on-premises services. In the next section, we describe each of these services in a nutshell to understand the key differences. - -## Load-balancing services in Azure - -Here are the main load-balancing services currently available in Azure: - -- [Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview) provides application delivery controller (ADC) as a service, offering various Layer 7 load-balancing capabilities for your application. It allows customers to optimize web farm productivity by offloading CPU-intensive SSL termination to the application gateway. -- [Azure Front Door Service](https://docs.microsoft.com/azure/frontdoor/front-door-overview) is an application delivery network providing global load balancing and site acceleration service for web applications. It offers various Layer 7 capabilities for your application like SSL offload, path-based routing, fast failover, caching, etc. to improve performance and high-availability of your applications. -- [Azure Load Balancer](https://docs.microsoft.com/azure/load-balancer/load-balancer-overview) is an integral part of the Azure SDN stack, providing high-performance, low-latency Layer 4 load-balancing services for all UDP and TCP protocols. -- [Traffic Manager](https://docs.microsoft.com/azure/traffic-manager/traffic-manager-overview) is a DNS-based traffic load balancer that enables you to distribute traffic optimally to services across global Azure regions, while providing high availability and responsiveness. - -When selecting the load-balancing options, here are some factors to consider: - -- **Traffic type**: Is it a web (HTTP/HTTPS) application? Is it public facing or a private application? -- **Global vs. regional**: Are you looking at load balancing your VMs or containers within a VNET, or your scale unit/deployments across regions, or both? -- **Scalability**: How does the service handle adding or removing instances? Can it autoscale based on load and other metrics? -- **Availability** What is the service SLA? -- **Cost** In addition to the cost of the service itself, consider the operations cost for managing a solution built on that service. For example, IaaS solutions might have a higher operations cost. -- What are the overall limitations of each service? -- What kind of application architectures are appropriate for this service? - -## Next steps - -To help select the right set of load-balancing services for your application, use the [Decision tree for load balancing applications](./load-balancing-decision-tree.md) diff --git a/docs/reference-architectures/app-service-web-app/images/multi-region-web-app-diagram.png b/docs/reference-architectures/app-service-web-app/images/multi-region-web-app-diagram.png index 0e664fd7241..5e8d6fa10b8 100644 Binary files a/docs/reference-architectures/app-service-web-app/images/multi-region-web-app-diagram.png and b/docs/reference-architectures/app-service-web-app/images/multi-region-web-app-diagram.png differ diff --git a/docs/reference-architectures/app-service-web-app/images/scalable-web-app.png b/docs/reference-architectures/app-service-web-app/images/scalable-web-app.png index 7d4495a924d..d77aa9b7344 100644 Binary files a/docs/reference-architectures/app-service-web-app/images/scalable-web-app.png and b/docs/reference-architectures/app-service-web-app/images/scalable-web-app.png differ diff --git a/docs/reference-architectures/app-service-web-app/multi-region.md b/docs/reference-architectures/app-service-web-app/multi-region.md index ecd086c2e5b..2bd7272c1f2 100644 --- a/docs/reference-architectures/app-service-web-app/multi-region.md +++ b/docs/reference-architectures/app-service-web-app/multi-region.md @@ -3,7 +3,7 @@ title: Highly available multi-region web application titleSuffix: Azure Reference Architectures description: Recommended architecture for a highly available web application running in multiple regions in Azure. author: MikeWasson -ms.date: 08/01/2019 +ms.date: 10/25/2018 ms.topic: reference-architecture ms.service: architecture-center ms.subservice: reference-architecture @@ -24,10 +24,10 @@ This architecture builds on the one shown in [Improve scalability in a web appli - **Primary and secondary regions**. This architecture uses two regions to achieve higher availability. The application is deployed to each region. During normal operations, network traffic is routed to the primary region. If the primary region becomes unavailable, traffic is routed to the secondary region. - **Azure DNS**. [Azure DNS][azure-dns] is a hosting service for DNS domains, providing 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. -- **Front Door**. [Front Door](/azure/frontdoor/) routes incoming requests to the primary region. If the application running that region becomes unavailable, Front Door fails over to the secondary region. +- **Azure Traffic Manager**. [Traffic Manager][traffic-manager] routes incoming requests to the primary region. If the application running that region becomes unavailable, Traffic Manager fails over to the secondary region. - **Geo-replication** of SQL Database and Cosmos DB. -A multi-region architecture can provide higher availability than deploying to a single region. If a regional outage affects the primary region, you can use [Front Door](/azure/frontdoor/) to fail over to the secondary region. This architecture can also help if an individual subsystem of the application fails. +A multi-region architecture can provide higher availability than deploying to a single region. If a regional outage affects the primary region, you can use [Traffic Manager][traffic-manager] to fail over to the secondary region. This architecture can also help if an individual subsystem of the application fails. There are several general approaches to achieving high availability across regions: @@ -35,7 +35,7 @@ There are several general approaches to achieving high availability across regio - Active/passive with cold standby. Traffic goes to one region, while the other waits on cold standby. Cold standby means the VMs in the secondary region are not allocated until needed for failover. This approach costs less to run, but will generally take longer to come online during a failure. - Active/active. Both regions are active, and requests are load balanced between them. If one region becomes unavailable, it is taken out of rotation. -This reference architecture focuses on active/passive with hot standby, using Front Door for failover. +This reference architecture focuses on active/passive with hot standby, using Traffic Manager for failover. ## Recommendations @@ -47,27 +47,27 @@ Each Azure region is paired with another region within the same geography. In ge - If there is a broad outage, recovery of at least one region out of every pair is prioritized. - Planned Azure system updates are rolled out to paired regions sequentially to minimize possible downtime. -- In every case except Brazil South, regional pairs reside within the same geography to meet data residency requirements. +- In most cases, regional pairs reside within the same geography to meet data residency requirements. However, make sure that both regions support all of the Azure services needed for your application. See [Services by region][services-by-region]. For more information about regional pairs, see [Business continuity and disaster recovery (BCDR): Azure Paired Regions][regional-pairs]. ### Resource groups -Consider placing the primary region, secondary region, and Traffic Manager into separate [resource groups][resource groups]. This placement allows you manage the resources deployed to each region as a single collection. +Consider placing the primary region, secondary region, and Traffic Manager into separate [resource groups][resource groups]. This lets you manage the resources deployed to each region as a single collection. ### Traffic Manager configuration -**Routing**. Front Door supports several [routing mechanisms](/azure/frontdoor/front-door-routing-methods#priority-based-traffic-routing). For the scenario described in this article, we'll use *priority* routing. With this setting, Front Door sends all requests to the primary region unless the endpoint for that region becomes unreachable. At that point, it automatically fails over to the secondary region. All you need to do is mark the different back ends in the backend pool for your Front Door with different priority values - 1 for the active region and 2 or lower for the standby or passive region. +**Routing**. Traffic Manager supports several [routing algorithms][tm-routing]. For the scenario described in this article, use *priority* routing (formerly called *failover* routing). With this setting, Traffic Manager sends all requests to the primary region unless the endpoint for that region becomes unreachable. At that point, it automatically fails over to the secondary region. See [Configure Failover routing method][tm-configure-failover]. -**Health probe**. Front Door uses an HTTP (or HTTPS) probe to monitor the availability of each backend. The probe gives Front Door a pass/fail test for failing over to the secondary region. It works by sending a request to a specified URL path. If it gets a non-200 response within a timeout period, the probe fails. You can configure the health probe frequency, number of samples required for evaluation, and the number of successful samples required to call the backend as healthy. Based on the health probe configuration, Front Door marks the backend as degraded and fails over to the other backend. For details, see [Health Probes](/azure/frontdoor/front-door-health-probes). +**Health probe**. Traffic Manager uses an HTTP (or HTTPS) probe to monitor the availability of each endpoint. The probe gives Traffic Manager a pass/fail test for failing over to the secondary region. It works by sending a request to a specified URL path. If it gets a non-200 response within a timeout period, the probe fails. After four failed requests, Traffic Manager marks the endpoint as degraded and fails over to the other endpoint. For details, see [Traffic Manager endpoint monitoring and failover][tm-monitoring]. -As a best practice, create a health probe path in your application backend that reports the overall health of the application and use the configuration for the health probe. The backend should check critical dependencies such as the App Service apps, storage queue, and SQL Database. If you don't follow this pattern, the probe might report a healthy backend when critical parts of the application are actually failing. +As a best practice, create a health probe endpoint that reports the overall health of the application and use this endpoint for the health probe. The endpoint should check critical dependencies such as the App Service apps, storage queue, and SQL Database. Otherwise, the probe might report a healthy endpoint when critical parts of the application are actually failing. -Don't use the health probe to check lower priority services. For example, if an email service goes down the application can switch to a second provider or just send emails later. This alone is not a high enough priority to cause the application to fail over. +On the other hand, don't use the health probe to check lower priority services. For example, if an email service goes down the application can switch to a second provider or just send emails later. This is not a high enough priority to cause the application to fail over. For more information, see the [Health Endpoint Monitoring pattern][health-endpoint-monitoring-pattern]. ### SQL Database -Use [Active Geo-Replication][sql-replication] to create a readable secondary replica in a different region. You can have up to four readable secondary replicas. Failover to a secondary database if your primary database fails or needs to be taken offline. Active Geo-Replication can be configured for any database in any elastic database pool. +Use [Active Geo-Replication][sql-replication] to create a readable secondary replica in a different region. You can have up to four readable secondary replicas. Fail over to a secondary database if your primary database fails or needs to be taken offline. Active Geo-Replication can be configured for any database in any elastic database pool. ### Cosmos DB @@ -79,18 +79,20 @@ Cosmos DB supports geo-replication across regions with multi-master (multiple wr ### Storage -For Azure Storage, use [read-access geo-redundant storage][ra-grs] (RA-GRS). With RA-GRS storage, the data is replicated to a secondary region. You have read-only access to the data in the secondary region through a separate endpoint. If there is a regional outage or disaster, the Azure Storage team might decide to perform a geo failover to the secondary region. There is no customer action required for this failover. +For Azure Storage, use [read-access geo-redundant storage][ra-grs] (RA-GRS). With RA-GRS storage, the data is replicated to a secondary region. You have read-only access to the data in the secondary region through a separate endpoint. If there is a regional outage or disaster, the Azure Storage team might decide to perform a geo-failover to the secondary region. There is no customer action required for this failover. For Queue storage, create a backup queue in the secondary region. During failover, the app can use the backup queue until the primary region becomes available again. That way, the application can still process new requests. -## Availability considerations - Front Door +## Availability considerations - Traffic Manager -Front Door automatically fails over if the primary region becomes unavailable. When Front Door fails over, there is a period of time (usually about 20-60 seconds) when clients cannot reach the application. The duration is affected by the following factors: +Traffic Manager automatically fails over if the primary region becomes unavailable. When Traffic Manager fails over, there is a period of time when clients cannot reach the application. The duration is affected by the following factors: -- The frequency of health probes: The more frequent the health probes are sent, the faster Front Door can detect downtime or the backend coming back healthy. -- The sample size configuration for the health probe to correctly detect that the primary data center has become unreachable and that the same is not an intermittent issue. +- The health probe must detect that the primary datacenter has become unreachable. +- Domain name service (DNS) servers must update the cached DNS records for the IP address, which depends on the DNS time-to-live (TTL). The default TTL is 300 seconds (5 minutes), but you can configure this value when you create the Traffic Manager profile. -Front Door is a possible failure point in the system. If the service fails, clients cannot access your application during the downtime. Review the [Front Door service level agreement (SLA)](https://azure.microsoft.com/support/legal/sla/frontdoor)) and determine whether using Front Door alone meets your business requirements for high availability. If not, consider adding another traffic management solution as a fallback such as Azure Traffic Manager. If the Front Door service fails, change your canonical name (CNAME) records in DNS to point to the other traffic management service. This step must be performed manually, and your application will be unavailable until the DNS changes are propagated. +For details, see [About Traffic Manager Monitoring][tm-monitoring]. + +Traffic Manager is a possible failure point in the system. If the service fails, clients cannot access your application during the downtime. Review the [Traffic Manager service level agreement (SLA)][tm-sla] and determine whether using Traffic Manager alone meets your business requirements for high availability. If not, consider adding another traffic management solution as a fallback. If the Azure Traffic Manager service fails, change your canonical name (CNAME) records in DNS to point to the other traffic management service. This step must be performed manually, and your application will be unavailable until the DNS changes are propagated. ## Availability Considerations - SQL Database @@ -101,8 +103,8 @@ The recovery point objective (RPO) and estimated recovery time (ERT) for SQL Dat RA-GRS storage provides durable storage, but it's important to understand what can happen during an outage: - If a storage outage occurs, there will be a period of time when you don't have write-access to the data. You can still read from the secondary endpoint during the outage. -- If a regional outage or disaster affects the primary location and the data there cannot be recovered, the Azure Storage team may decide to perform a geo failover to the secondary region. -- Data replication to the secondary region is performed asynchronously. Therefore, if a geo failover is performed, some data loss is possible if the data can't be recovered from the primary region. +- If a regional outage or disaster affects the primary location and the data there cannot be recovered, the Azure Storage team may decide to perform a geo-failover to the secondary region. +- Data replication to the secondary region is performed asynchronously. Therefore, if a geo-failover is performed, some data loss is possible if the data can't be recovered from the primary region. - Transient failures, such as a network outage, will not trigger a storage failover. Design your application to be resilient to transient failures. Possible mitigations: - Read from the secondary region. @@ -112,9 +114,34 @@ RA-GRS storage provides durable storage, but it's important to understand what c For more information, see [What to do if an Azure Storage outage occurs][storage-outage]. +## Manageability Considerations - Traffic Manager + +If Traffic Manager fails over, we recommend performing a manual failback rather than implementing an automatic failback. Otherwise, you can create a situation where the application flips back and forth between regions. Verify that all application subsystems are healthy before failing back. + +Note that Traffic Manager automatically fails back by default. To prevent this, manually lower the priority of the primary region after a failover event. For example, suppose the primary region is priority 1 and the secondary is priority 2. After a failover, set the primary region to priority 3, to prevent automatic failback. When you are ready to switch back, update the priority to 1. + +The following commands update the priority. + +### PowerShell + +```powershell +$endpoint = Get-AzureRmTrafficManagerEndpoint -Name -ProfileName -ResourceGroupName -Type AzureEndpoints +$endpoint.Priority = 3 +Set-AzureRmTrafficManagerEndpoint -TrafficManagerEndpoint $endpoint +``` + +For more information, see [Azure Traffic Manager Cmdlets][tm-ps]. + +### Azure CLI + +```azurecli +az network traffic-manager endpoint update --resource-group --profile-name \ + --name --type azureEndpoints --priority 3 +``` + ## Manageability Considerations - SQL Database -If the primary database fails, perform a manual fail over to the secondary database. See [Restore an Azure SQL Database or fail over to a secondary][sql-failover]. The secondary database remains read-only until you fail over. +If the primary database fails, perform a manual failover to the secondary database. See [Restore an Azure SQL Database or failover to a secondary][sql-failover]. The secondary database remains read-only until you fail over. @@ -131,4 +158,10 @@ If the primary database fails, perform a manual fail over to the secondary datab [sql-replication]: /azure/sql-database/sql-database-geo-replication-overview [sql-rpo]: /azure/sql-database/sql-database-business-continuity#sql-database-features-that-you-can-use-to-provide-business-continuity [storage-outage]: /azure/storage/storage-disaster-recovery-guidance +[tm-configure-failover]: /azure/traffic-manager/traffic-manager-configure-failover-routing-method +[tm-monitoring]: /azure/traffic-manager/traffic-manager-monitoring +[tm-ps]: /powershell/module/azurerm.trafficmanager +[tm-routing]: /azure/traffic-manager/traffic-manager-routing-methods +[tm-sla]: https://azure.microsoft.com/support/legal/sla/traffic-manager +[traffic-manager]: https://azure.microsoft.com/services/traffic-manager [visio-download]: https://archcenter.blob.core.windows.net/cdn/app-service-reference-architectures.vsdx diff --git a/docs/reference-architectures/app-service-web-app/scalable-web-app.md b/docs/reference-architectures/app-service-web-app/scalable-web-app.md index 7aa983491e2..00f30590206 100644 --- a/docs/reference-architectures/app-service-web-app/scalable-web-app.md +++ b/docs/reference-architectures/app-service-web-app/scalable-web-app.md @@ -1,18 +1,18 @@ --- title: Scalable web application titleSuffix: Azure Reference Architectures -description: Improve Scalability in a web application running in Microsoft Azure. +description: Improve scalability in a web application running in Microsoft Azure. author: MikeWasson -ms.date: 08/01/2019 +ms.date: 10/25/2018 ms.topic: reference-architecture ms.service: architecture-center ms.subservice: reference-architecture ms.custom: seodec18 --- -# Improve Scalability in an Azure web application +# Improve scalability in an Azure web application -This Reference Architecture shows proven practices for improving scalability and performance in an Azure App Service web application. +This reference architecture shows proven practices for improving scalability and performance in an Azure App Service web application. ![GitHub logo](../../_images/github.png) A reference implementation for this architecture is available on [GitHub][github]. @@ -33,7 +33,7 @@ This architecture builds on the one shown in [Basic web application][basic-web-a - **Data storage**. Use [Azure SQL Database][sql-db] for relational data. For non-relational data, consider [Cosmos DB][cosmosdb]. - **Azure Search**. Use [Azure Search][azure-search] to add search functionality such as search suggestions, fuzzy search, and language-specific search. Azure Search is typically used in conjunction with another data store, especially if the primary data store requires strict consistency. In this approach, store authoritative data in the other data store and the search index in Azure Search. Azure Search can also be used to consolidate a single search index from multiple data stores. - **Azure DNS**. [Azure DNS][azure-dns] is a hosting service for DNS domains, providing 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. -- **Front Door**. [Front Door](/azure/frontdoor/) is a layer 7 load balancer and a site acceleration platform to improve your application's performance. In this architecture, it routes HTTP requests to the web front end. Front Door also provides a [web application firewall](/azure/frontdoor/waf-overview) (WAF) that protects the application from common exploits and vulnerabilities. +- **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. ## Recommendations @@ -100,12 +100,6 @@ Increase scalability of a SQL database by *sharding* the database. Sharding refe - Better transaction throughput. - Queries can run faster over a subset of the data. -### Azure Front Door - -Front Door allows you to perform SSL offload at Front Door layer and also reduces the overall set of connections that your backend (App Service) will have to maintain. - -Since the TCP and SSL connections get terminated at Front Door, and even if you forward the requests as HTTPS to your application deployment, due to high level of connection reuse, there is a lot lesser percentage of SSL handshakes and TCP connections that your application will have to support. - ### Azure Search Azure Search removes the overhead of performing complex data searches from the primary data store, and it can scale to handle load. See [Scale resource levels for query and indexing workloads in Azure Search][azure-search-scaling]. @@ -114,16 +108,6 @@ Azure Search removes the overhead of performing complex data searches from the p This section lists security considerations that are specific to the Azure services described in this article. It's not a complete list of security best practices. For some additional security considerations, see [Secure an app in Azure App Service][app-service-security]. -### Locking down App Service for access from Front Door only - -Since your application is fronted with Front Door, and you will have your web application firewall policies setup, it is necessary that you lock down your application to accept traffic from your Front Door only. See [how to lock down your backend to accept traffic from Front Door only](/azure/frontdoor/front-door-faq#how-do-i-lock-down-the-access-to-my-backend-to-only-azure-front-door) - -### Web application firewall - -Web application firewall that helps protect your web applications from common threats such as SQL injection, cross-site scripting and other web exploits. You can define a WAF policy with Front Door, consisting of a combination of custom and managed rules to control access to your web applications. - -Azure WAF, when integrated with Front Door, stops denial-of-service and targeted application attacks at the edge of Microsoft's network, close to attack sources before they enter your application, and offers protection without sacrificing performance. - ### Cross-Origin Resource Sharing (CORS) If you create a website and web API as separate apps, the website cannot make client-side AJAX calls to the API unless you enable CORS. @@ -169,5 +153,6 @@ Use [Transparent Data Encryption][sql-encryption] if you need to encrypt data at [sql-db]: /azure/sql-database/ [sql-elastic]: /azure/sql-database/sql-database-elastic-scale-introduction [sql-encryption]: https://msdn.microsoft.com/library/dn948096.aspx +[tm]: https://azure.microsoft.com/services/traffic-manager/ [visio-download]: https://archcenter.blob.core.windows.net/cdn/app-service-reference-architectures.vsdx [web-app-multi-region]: ./multi-region.md diff --git a/docs/toc.yml b/docs/toc.yml index c2ff4c2e111..f432d0beb0d 100644 --- a/docs/toc.yml +++ b/docs/toc.yml @@ -54,12 +54,6 @@ items: href: guide/technology-choices/compute-decision-tree.md - name: Compute comparison href: guide/technology-choices/compute-comparison.md - - name: Choosing a load balancing service - items: - - name: Overview - href: guide/technology-choices/load-balancing-overview.md - - name: Decision tree - href: guide/technology-choices/load-balancing-decision-tree.md - name: Best Practices items: - name: API design @@ -1418,4 +1412,4 @@ items: - name: Virtual Datacenter (VDC) href: vdc/index.md - name: How does Azure work? - href: cloud-adoption/getting-started/what-is-azure.md + href: cloud-adoption/getting-started/what-is-azure.md \ No newline at end of file