New Features in SharePoint 2013 – Part 4 (Request Management Functionality)

SharePoint Server 2013 Preview provides unparalleled levels of availability and site resilience, while also reducing the cost and complexity of deployment to environments of diverse sizes. Building on the native capabilities introduced in SharePoint Server 2010, improvements in SharePoint Server 2013 Preview provide a simplified, unified solution for high availability, disaster recovery, and backup.

Because of the length of this article, I am dividing this article into 2 blog posts. The 1st section deals with Request Management functionality, the 2nd section deals with Request Management Configuration.

Request Management Functionality:

Request Management in SharePoint Server 2013 Preview enables IT to prioritize and route incoming requests through a rules engine that applies logic to determine the nature of the request and the appropriate response.

Request Management can be used to:

  • Route requests to servers with good health characteristics based on a new weighting schema.
  • Prioritize requests by throttling lower priority requests to preserve resources for those of higher priority.
  • RM can prioritize requests by throttling lower-priority ones (bots) to serve higher-priority ones (end-users).
  • Route specific request types to other servers, either within or outside of the farm handling the request.
  • RM can send all requests of specific type, like search for example, to specific machines.
  • RM can route to WFEs with better health, keeping low-health WFEs alive.
  • RM can send heavy requests to more powerful WFEs.
  • RM can identify harmful requests and deny them immediately.
  • Identify and block known bad requests such as web robot.
  • Isolated traffic can help troubleshoot errors on one machine.

This is a really exciting functionality as it will help us in large deployments by routing appropriate traffic to the server. The purpose of the Request Management feature is to give SharePoint knowledge of and more control over incoming requests. Having knowledge over the nature of incoming requests – for example, the user agent, requested URL, or source IP – allows SharePoint to customize the response to each request. RM is applied per web application, just like throttling is done in SharePoint 2010.

How does Request Management work (Functionality)?

Request Manager is comprised of 3 primary components and it follows them step by step to get to the WFE (Web Front End).

  1. Request Throttling and Routing Component
    1. Request manager check for throttling rules for every request and if a matching rule is found, then the request is throttled. If the Throttling Rule is not found, then the request manager looks for routing rules.
    2. If a routing rule is identified then the request managers, looks for a list of WFEs to send the request to.
  2. Request Prioritization
    1. Request manager filters WFEs to only ones healthy enough for the request
  3. Request Load Balancing
    1. Request manger will then load balance the WFE’s and select a single WFE to route to, based on weighting schemes like health

How are Routing Rules Identified?

Routing Rules are defined for every request and Routing rules are associated with Machine Pools. Machine Pools contain servers (Single or Multiple) and servers use weights (static, health) for routing. So, whenever there is a new request, it will be mapped against a routing rule and then will be sent to appropriate machine pool, which will be again sent to a server depending upon the weights.

Weights can be divided into 2 categories

  1. Static weights are constant for WFEs (these are default values for all the WFE’s and Admins can change those static weights)
  2. Health weights change dynamically based on health scores (a server with less health score is less likely that a request will be routed to it)

RM Routing Rules and Execution Groups:

To summarize, routing to a server in a Machine Pool is based on matching a “Routing Rule”. Just like the way servers are present in a Machine Pool, Routing Rules are placed in Execution Groups (numbered 0-Default, 1, 2). Rules are evaluated in each Execution Group (Execution Groups are executed in order form 0 to 2). As soon as a match is found no more Execution Groups are evaluated. All machines from pools that match any routing rules are grouped together to determine possible target servers. This means that you create your most important rules in Execution Group 0 (default).

RM Routing Rules Continued:

There are some important caveats to remember about routing rules

  • If no rules are matched, then the request will be sent to any server that is NOT in any machine pool for any rule (THIS MAY CHANGE AFTER RTM)
  • In a one server farm that means nothing will route if no rules match, so the alternative is to create a “catch all” rule that matches everything. Just put it in Execution Group 1 or 2 so it’s the last match

RM – Why not throttling?

SharePoint 2010 has throttling but there is room for improvement. It uses a health score system in which WFEs attach their health info to all responses that go back to clients

The drawbacks from this approach were:

  • It was the clients’ responsibility to honor the health scores, so clients would get health score and it was up to them to honor them or not.
  • It did not preclude WFE failure; it did no good because Client doesn’t have any way of knowing about it. It could get a server response back, but it doesn’t know that subsequently went down.
  • Clients could be shown server busy messages from a poor-health WFE when other better-health WFEs were available to service those requests

RM – Throttling Rules:

Request Management builds on the throttling features of SharePoint 2010 and implements it on server side using rules. Routing rules process requests; throttling rules stop requests. It’s much like throttling in SharePoint 2010, only more sophisticated, you create criteria for the throttling rule, and if the criterion is met the request is throttled (discarded). The process and PowerShell for creating throttling rules is very similar to routing rules

What Criteria can you use for Throttling and Routing?

When creating a routing rule or throttling rules, Rules can match on these properties:

  • What’s the URL that has been requested?
  • Who is the UrlReferrer?
  • What’s the UserAgent?
  • What’s the Host that has been requested?
  • What’s IP address that request was submitted from?
  • What HttpMethod is requested?
  • What SoapAction is requested?
  • You can also add a CustomHeader that request management will evaluate?

You can evaluate values using these methods to see if a rule matches?

  • StartsWith
  • EndsWith
  • Equals
  • Custom RegEx

RM – Heavy Client Application:

You have a heavy load on the system with many browser requests. Notebook sync requests start coming in from OneNote, the OneNote requests start adversely affecting the browser requests so you can add a throttling rule is added to deny OneNote requests: Here is an example where you can create a throttling rule and the criteria would be based on UserAgent Property and we are going evaluate the property is by using a Regex to check for OneNote.

Rule: Deny requests with UserAgent of regex = “.*Microsoft Office OneNote 2010*”

Based on this rule RM denies OneNote requests. When system load dies down, the admin can remove the throttling rule

Other Options:

  • Rule could use an expiration to automatically deactivate the rule at a certain time. (Example: A throttle rule can be activated at a certain time and deactivated at a certain time)
  • Rule could use a health score threshold to activate. (Example: A throttle rule can be activated when my health score gets above 7 or 8, where the health has adversely impacted)

RM – Routing Weights:

RM uses static weights and health weights to help determine which servers are going to get the request.

  • Static weights are associated with WFEs so certain ones will always be favored when selecting. This gives added weight to more powerful WFEs and less to weaker machines. (Example: When we add hardware to the farm, we can increase the static weight to be higher than existing servers in the farm)
  • Health weights are used to even out load and keep “sick” WFEs going. So health scores run from 0 to 10 where 0 is the healthiest and therefore will get the most requests; this score is used to derive the health weight. So WFEs start with a healthy weight; the Policy Engine health rule updates health weights dynamically – you cannot change it manually

RM Scenario – Health Based Routing:

A series of requests come in; one WFE is in poor health, while two others are in good health.

RM evaluates the following:

Health information: { [WFE1, sick], [WFE2, healthy], [WFE3, healthy] }

Based on this RM routes most of the requests among WFE2 and WFE3. It is still random routing, but greater weight is given to healthier machines. Alternatively the admin could remove WFE1 from the routing pool, allow it to complete its requests then return it back to the pool

Please check 2nd section for Request Management Configuration in SharePoint 2013 – Part 4.


About Vamshideep

SharePoint Architect
This entry was posted in SharePoint 2013. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s