Azure Websites provides various mechanisms to scale your websites up and down by adjusting the number of VM instances serving requests and by adjusting the instance size. You can, for example, increase (scale up, or more precisely, scale out) the number of instances to support the load you experience during business hours, but then decrease (scale down, or more pre- cisely, scale in) the number of instances during less busy hours to save costs. Websites enables you to scale the instance count manually, automatically via a schedule, or automatically according to key performance metrics. Within a datacenter, Azure will load balance traffic between all of your website instances using a round-robin approach.
You can also scale up a website by deploying to multiple regions around the world and then utilizing Microsoft Azure Traffic Manager to direct website traffic to the appropriate region based on a round robin strategy or according to performance (approximating the latency perceived by clients of your website). Alternately, you can configure Traffic Manager to use the alternate regions as targets for failover if the primary region becomes unavailable.
In addition to scaling instance counts, you can manually adjust your instance size. For example, you can scale up your website to utilize more powerful VMs that have more RAM memory and more CPU cores to serve applications that are more demanding of memory consumption or CPU utilization, or scale down your VMs if you later discover your require- ments are not as great.
This objective covers how to:
■
■ Configure auto-scale using built-in and custom schedules
■
■ Configure auto-scale by metric
■
■ Change the size of an instance
■
■ Configure Traffic Manager
EXAM TIP
Unlike other Azure compute services, Websites provides a high availability SLA of 99.9 percent using only a single standard instance. You do not need to provision more than one instance to benefit from this SLA.
Objective 1.5: Configure websites for scale and resilience CHAPTER 1 63
Configuring auto-scale using built-in and custom schedules
Scheduling is enabled via the Auto-Scale feature and requires that your website is in Standard web hosting plan mode. You can use one of the predefined recurring schedules (for example, day/night or weekdays/weekends) or define your own custom schedules (for example, accord- ing to a set of non-overlapping date ranges) to control the instance count of your website.
Configuring auto-scale by schedule (existing portal)
To configure auto-scale by schedule in the management portal, complete the following steps:
1. Navigate to the Scale tab of your website on the management portal accessed via https://manage.windowsazure.com.
2. Scroll down to Capacity.
3. Click Set Up Schedule Times.
4. In the dialog box that appears, define the schedule:
■
■ To enable a day/night recurring schedule, under Recurring Schedules, select Different Scale Settings For Day And Night, and then, under Time, specify what hours are considered daytime. (Azure will infer the remaining hours are nighttime.)
■
■ To enable a weekdays and weekends recurring schedule, under Recurring Sched- ules, select Different Scale Settings For Weekdays And Weekends (where weekdays are defined as Monday morning through Friday evening and weekends are Friday evening through Monday morning). Under Time, adjust the time for morning and evenings.
■
■ To enable usage of specific date ranges, under Specific Dates, fill in the grid. Specify a user-friendly name for the date range, a start date and time, and an end date and time. You can add multiple date ranges as long as they do not overlap.
5. When you finish defining schedules, click the check mark to make these schedules configurable on the Scale tab.
6. Return to the Scale tab and select one of your newly defined schedules from the Edit Scale Settings For Schedule.
7. Use the Instance Count slider to adjust the target number of instances for your website during that schedule.
8. Repeat the previous two steps as necessary for any other schedules you have defined.
9. Click Save to save both the newly defined schedules and your instance count configurations for each schedule.
Configuring auto-scale by schedule (Preview portal)
It is not currently possible to configure auto-scale using a schedule with the Preview portal.
Configuring auto-scale by metric
Auto-scale by metric enables Azure to automatically adjust the number of instances provi- sioned to your web hosting plan based on one or more configured rules, where each rule has a condition, a metric, and an action to take in response to the threshold being exceeded.
The performance-related metrics currently available include the following:
■
■ CPU Percentage Percent of CPU utilization
■
■ Memory Percentage Percent of RAM memory utilization
■
■ Disk Queue Length Count of pending disk operations
■
■ Http Queue Length Count of pending HTTP operations
■
■ Data In Amount of traffic ingress in kilobytes
■
■ Data Out Amount of traffic egress in kilobytes
Objective 1.5: Configure websites for scale and resilience CHAPTER 1 65 Each metric is measured as an aggregate (typically an average) across all of your website
instances over a period of time. For example, if you choose CPU Percentage as a metric, your condition will evaluate a threshold against the average CPU utilization percentage for all of your website VMs over a period of time and not the CPU percentage of a single VM.
For each rule, you choose a metric and then define a condition for it. This condition compares against a threshold. Above this threshold, a scale up action (adding instances) occurs, and below this threshold, a scale down action (removing instances) occurs. You also specify the number of instances by which to scale up or down.
You can specify both scale up and scale down actions for the same metric by using differ- ent rules. You can also specify multiple rules, using different conditions, metrics, and actions.
The frequency with which these rules are triggered is important to manage—you do not want to constantly add and remove instances because adding instances always takes some amount of time (no matter how little). As a practical approach, it is better to scale up aggres- sively (to better address your applications’ demands) and scale down conservatively (so your application performance is more stable). Scaling frequency and how you choose to stabilize it is within your control. You stabilize scaling by specifying the period of time over which the threshold is computed and setting a cool-down period that follows a scaling operation, during which, scaling will not be triggered again.
This is all best explained by example. Consider a scenario where you start with one instance and you configure the following rule:
■
■ Metric CPU Percentage
■
■ Threshold Greater than 80 percent
■
■ Over Past 20 minutes
■
■ Scale Up By 1 instance
■
■ Cool Down 20 minutes
Over a 20-minute period, your website experiences an average CPU utilization of 85 percent. Auto-scale adds one instance, increasing your total scale to two instances. However, assume that the CPU utilization remains at 85 percent for the next 5 minutes, even with the additional instance helping to reduce the average CPU load. Auto-scale will not trigger again for another 15 minutes because it is within the cool-down period for the scaling rule.
NOTE NON-CONTIGUOUS THRESHOLDS
It is important to note that the scale-up threshold and the scale-down threshold do not have to be contiguous. For example, you can specify that one instance should be added every time the CPU utilization exceeds 80 percent, and only begin to remove one instance when the CPU utilization drops below 50 percent. This is another way to control the frequency of scaling operations.
Configuring auto-scale by metric (existing portal)
The existing portal allows you to define only a single pair of scale-up and scale-down rules based on the CPU percentage metric. You do not have control over the Over Past period, the step (or number of instances added/removed), or the cool-down period used each time a scaling rule is triggered—these default to 20 minutes, one instance, and 20 minutes, respectively. To specify this pair of rules, complete the following steps:
1. Navigate to the Scale tab of your website on the management portal accessed via https://manage.windowsazure.com.
2. Scroll down to Capacity.
3. For Scale By Metric, click CPU. This is the only metric supported by the existing portal.
4. Adjust the Target CPU slider to specify the threshold below which scale down actions will be taken. Do this by entering a value in the left-most text box or by dragging the left-most slider handler.
5. Repeat the previous step to define the threshold for the scale up action, using the right-most text box or slider handle to adjust the threshold.
6. Using the Instance Count slider, define the minimum and maximum number of instances that auto-scale can reach at any point in time.
7. Click Save to apply your auto-scale by metric rules.
Objective 1.5: Configure websites for scale and resilience CHAPTER 1 67
Configuring auto-scale by metric (Preview portal)
The Preview portal enables you to define multiple scaling rules, using all the metrics previously introduced in this section, and provides granular control over scaling frequency.
To configure your rules, complete the following steps:
1. Navigate to the blade of your website in the portal accessed via https://portal.azure.com.
2. Scroll down to Usage and click Scale.
3. In the Scale blade that appears, under Choose Scale, click Performance.
4. By default, one pair of rules for CPU percentage is already present. To quickly set scale up and scale down thresholds for the CPU percentage metric, leave the over past period and cool down period at their defaults.
5. Adjust the left and right control knobs on the Target Metrics slider to the desired threshold values.
6. To change the metric used or to add rules using different metrics, click the “>” button to the right of the Target Metrics slider and then do the following:
A. Choose a metric from the Metric drop-down list.
B. Specify the condition (greater or less), threshold, over past, scale up/down by, and cool down values.
C. To add another rule, click Add Scale Up Rule or Add Scale Down Rule and then repeat step 6 for the new rule.
D. Click Save on the command bar.
7. On the Scale blade for your web hosting plan, using the Instance Count slider, define the minimum and maximum number of instances that auto-scale can reach at any point in time.
8. To remove any undesired rules, click the X button to the right of its slider.
9. Click Save to apply your auto-scale rules.
NOTE SCOPE OF AUTO-SCALE
Auto-scale affects the instance count of your web hosting plan and therefore affects all websites hosted within that plan. It does not apply directly to an individual website.
Changing the size of an instance
You can adjust the number of CPU cores and the amount of RAM memory available to your Websites VMs by adjusting the instance size (in the existing portal) or the by changing your pricing tier (in the Preview portal). In either case, you are adjusting the size of the instances used for your web hosting plan and therefore for all websites that are a part of it.
Changing the size of an instance (existing portal)
The existing portal allows you to change the instance size for your web hosting plan by selecting an instance size from the Scale tab of your website. To do so, your website must be in the Basic or Standard web hosting plan tier.
1. Navigate to the Scale tab of your website on the management portal accessed via https://manage.windowsazure.com.
2. Scroll down to Capacity.
3. From Instance Size, choose the desired instance size.
4. Click Save on the command bar.
Changing the size of an instance (Preview portal)
The Preview portal allows you to change the instance size for your web hosting plan by selecting a new pricing tier for it.
1. Navigate to the blade of your website in the portal accessed via https://portal.azure.com.
2. Scroll down to Usage and click Pricing Tier.
3. In the new blade, click on a pricing tier, and then click Select.
Objective 1.5: Configure websites for scale and resilience CHAPTER 1 69
Configuring Traffic Manager
Traffic Manager combines endpoint monitoring of your website with DNS so that client traffic is always directed toward a viable endpoint. It is important to understand that traffic does not flow through Traffic Manager to your website endpoint, but rather it is guided to your website endpoint as a result of DNS resolution.
To understand this better, assume you have a website at www.contoso.com. You would configure your DNS for contoso.com to have a CNAME record with a key of “www” pointing to contoso.trafficmanager.net. When a client, such as a browser, first tries to browse to www.
contoso.com, it does a domain name lookup that ultimately leads it to Traffic Manager. Traffic Manager evaluates its configuration for a viable endpoint (effectively evaluating rules and choosing from a list of endpoints you configured) and then Traffic Manager replies with the domain name of the viable endpoint for your website, such as contoso-west.azurewebsites.
net. This domain name is then resolved to the IP address of your website endpoint by DNS.
The browser actually sends its request to this IP address. For a period of time, the IP address to which www.contoso.com ultimately resolves is cached by the browser (to avoid the DNS lookup for every request). This period is referred to as the time-to-live, or TTL, for the local DNS cache entry, and it controls how long the client will continue to use a resolved end- point—basically, until the TTL expires. When it expires, the client may perform another DNS lookup and, at this point, may learn of a new endpoint domain name (and by extension, a new IP address) from Traffic Manager.
NOTE CUSTOM DOMAIN NAMES AND TRAFFIC MANAGER
If you plan to use a custom domain name with Traffic Manager, you must configure the DNS settings for the custom domain to use a CNAME record that maps to the <yourprefix>.
trafficmanager.net address. You cannot use an A record to map to an IP address exposed by Traffic Manager. This means that you can only use Traffic Manager for subdomains, such as www.contoso.com and not for contoso.com.
The fact that the resolution is time-based has a very important implication—at a given point in time, individual clients may resolve to different endpoints for load balancing or failover, but when resolved, clients may not become aware they need to be communicating with a different endpoint until the TTL expires.
NOTE CHOOSING A TTL VALUE
The default TTL used by Traffic Manager in response to DNS queries is 300 seconds (5 min- utes). If you are using Traffic Manager primarily for failover, you might be tempted to set the TTL to a very low value to ensure clients who had been communicating with a now unreachable endpoint can quickly start communicating with a functioning endpoint. The minimum TTL allowed is 30 seconds, and you can use this value, but be aware you are cre- ating additional DNS traffic as well as incurring additional Traffic Manager costs to handle the increased load of DNS queries.
Traffic Manager load balancing methods
Traffic Manager provides three different load balancing methods to guide traffic to a viable website endpoint. Each load balancing method can define its own TTL, list of endpoints, and monitoring configuration. The difference between them is primarily in how Traffic Manager chooses the endpoint from the list of endpoints when responding to a DNS query.
■
■ Failover When a DNS query comes in from a client, Traffic Manager picks the first endpoint from the ordered list of endpoints that it determines is healthy based on periodic monitoring of the endpoints.
■
■ Round robin Traffic Manager treats each active endpoint in its list of endpoints equally and tries to evenly distribute traffic among the endpoints in a round-robin fashion.
■
■ Performance Traffic Manager picks the “closest” endpoint from the configured list of endpoints that should have the lowest latency for the client. To do this, Traffic Manager maintains a lookup table (called the Internet Latency Table) of DNS server IP address ranges, and for each IP range, it periodically collects the round-trip latency from serv- ers in that range to an Azure datacenter region. It locates the entry in the table that contains the IP address of the DNS server where the DNS query originated and then selects the website endpoint whose datacenter had the lowest latency.
You can think of these methods as all having a failover element because if Traffic Manager monitoring detects an endpoint as unhealthy, it is removed from the rotation and traffic is not guided to it.
NOTE AVOIDING CASCADING FAILURES
When using the performance load balancing method, be aware that if all the endpoints in the closest datacenter are not available, then Traffic Manager will switch to a round-robin method, distributing traffic to endpoints located in other datacenters to avoid overwhelm- ing the endpoints in the next closest datacenter and potentially causing a chain of failures.
Configuring Traffic Manager (existing portal)
You configure Traffic Manager by creating profiles. Each profile contains a DNS prefix (of the form <yourhost>.trafficmanager.net), the load balancing method and configuration, and a list of endpoints. To configure Traffic Manager in the management portal, complete the following steps.
1. Navigate to the management portal accessed via https://manage.windowsazure.com.
2. On the command bar, click New, and then click Network Services, Traffic Manager, Quick Create.
Objective 1.5: Configure websites for scale and resilience CHAPTER 1 71 3. Provide a DNS prefix for your Traffic Manager endpoint.
4. Choose a load balancing method (Performance, Round Robin, or Failover).
5. Click Create to create the basic Traffic Manager profile.
6. Click the name of the profile in the list of profiles.
7. Click the Endpoints tab.
8. Click Add Endpoints.
9. In the dialog box that appears, under Service Type, select Web Site.
10. In the Service Endpoints list, select the website endpoints you want to include in this Traffic Manager profile.
11. Click the check mark to complete selecting the endpoints.
12. Click the Configure tab.
13. Under General, in the DNS Time To Live (TTL) text box, enter a value in seconds.
14. Optionally, under Load Balancing Method Settings, change the load balancing method.
If you choose the Failover method, modify the order of the endpoints by using the up and down arrows that appear when you hover over a website.
15. Under Monitoring Settings, choose the protocol (http or https) to use for monitoring your website endpoints, and specify the port number.
16. If desired, provide a relative path to monitor.
17. Click Save on the command bar.
Configuring Traffic Manager (Preview portal)
Currently, Traffic Manager cannot be configured using the Preview portal.